Gigabit Ethernet Products Test Scheme

When my company decided to develop a line of Gigabit Ethernet transport products for use in cable systems, I was asked to handle the Ethernet testing for the entire development process.  The test scheme that I designed needed to be very flexible because it was going to be used for many types of tests from quick ad-hoc tests to final product qualification tests.

The scheme that I designed is different than what many other people use.  I created a library of tests and configuration options that can be used as building blocks for designing tests.  Each individual building block is assigned a reference number consisting of a string of integers separated by decimals.  A person requesting a test can quickly piece together the particulars for a test by using these references.

Our optical transport products have a local interface that can be configured a number of different ways, a number of different parameters that can be changed in software, and can connect using a variety of long haul fiber networks.  Configuration documents completely describe multiple ways that each one of these can be configured.  For example, the reference �2.1.1.2� completely describes one type of configuration of the local interface on the product.  The reference �2.2.2� completely describes one particular configuration of the software settings on the product and �2.3.1.1.3� describes one option for the long-haul configuration.  These descriptions were carefully categorized and numbered so that a group of configurations could be referenced easily by including a generic placeholder in the reference number.  This allows someone to reference �2.1.1.x� and imply that any of this group could be used for that test.  This method also simplifies the process for making additions to this library without affecting any of the other references.  Had they simply been numbered serially, any new addition would have been given the next number available with no categorization or organization.

Procedure documentation completely describes how individual tests are run.  They list the test equipment used, test equipment configurations, test procedures, and analysis in great detail.  This information is often relevant to more than one product.  Procedure documentation never describes a passing or failing unit, as these requirements may be different for different applications or types of units.

Procedures are categorized into Module Test Procedures, Product Test Procedures, Platform Test Procedures, System Test Procedures, and Unexpected Failure Procedures.  Module tests are tests that concentrate on board level or component level problems such as electrical shorts or electrical interfaces to components.  Product tests are used to detect other problems that wouldn�t be obvious at the application level, such as the optical power of a laser or analysis of a proprietary signaling channel.  Platform Tests analyze the primary functions of a DUT such as traffic throughput or monitoring.  System tests are used to demonstrate interoperability with other components in a larger system.  Unexpected failure procedures are used to analyze obvious failures that occur during tests that were not designed to find that type of failure such as user interface problems.  Once again, references consist of a string of integers separated by decimals.

The following is an example test plan that could be written to confirm the functionality of �Interface 1� after each engineering change to that interface.  The reference numbers are meaningless to the reader other than to understand that they are described in detail elsewhere.  In the first batch, four tests are run to check the functionality of the interface over different configurations (�2.1.1.1� through �2.1.1.4�).  Notice that the same test procedure is used for each test (�5.4.1.2�).  The next batch tests the traffic monitoring functionality with two different tests (�5.10.1� and �5.10.2�).  In each case, the person writing the test plan has focused on what is most important for the test and has only specified reference groups when there is no need to specify it further.  The person running the test would most likely run what is most convenient and would note the exact reference in the test report.