 |
 |
 |
Interoperability testing has become a requirement for companies that deploy multi-vendor networks. To satisfy this requirement, network and storage providers and managers have three options.
1. Set up an interoperability lab, an expensive and time-consuming project.
2. Use a third-party interoperability lab, such as ISOCORE or the University of New Hampshire.
3. Create a proof-of-concept lab, such as the labs at Cisco or Spirent Communications.
1. Set up an interoperability lab, an expensive and time-consuming project.
2. Use a third-party interoperability lab, such as ISOCORE or the University of New Hampshire.
3. Create a proof-of-concept lab, such as the labs at Cisco or Spirent Communications.
These labs typically connect the devices with a copper or fiber-optic patch cable and run the tests. Such testing reflects a best-case scenario that is useful for base-line interoperability testing but doesn’t represent how the devices will interoperate in an actual network.
It is analogous to testing the auto-pilot system of an airplane to see if it could land the plane in ideal weather conditions. While the test proves the plane can land itself on a perfect day, it is not a predictor of how the system will behave in wide range of weather conditions under which a plane will have to operate.
It is analogous to testing the auto-pilot system of an airplane to see if it could land the plane in ideal weather conditions. While the test proves the plane can land itself on a perfect day, it is not a predictor of how the system will behave in wide range of weather conditions under which a plane will have to operate.
Sometimes spools of fiber are used to create the delay found in wide area networks. While this is an improvement over patch cables, there are three major limitations to proof of concept and interoperability testing with spools of fiber:
1. Spools of fiber cannot provide dynamic tests. The tests must be manually stopped and restarted to change out the spool of fiber for one with a different length.
2. Spools of fiber are expensive and impractical. Imagine the cost associated with moving an 50,000 km spool of fiber to another lab.
3. Spools of fiber only provide delay. They do not address the various other impairments that exist in a network.
It is as if we improved our auto-pilot system testing to include fixed amounts of wind from a single direction. Factors such as fog, rain, snow and wind sheers are still ignored in the testing. Weather conditions are dynamic and multifaceted. Testing under a single condition is not a realistic test. As with weather, so it is with networks. Impairments in real networks do not limit themselves to a single issue.
Anue Network Emulators allow you to land your plane under any combination of adverse weather conditions.
Anue Network Emulators enable savvy network and storage providers to characterize and validate applications performance based upon multiple factors. These factors include dynamic delay representing distances up to 50,000 km, jitter, bit errors, packet sequencing and loss.
1. Spools of fiber cannot provide dynamic tests. The tests must be manually stopped and restarted to change out the spool of fiber for one with a different length.
2. Spools of fiber are expensive and impractical. Imagine the cost associated with moving an 50,000 km spool of fiber to another lab.
3. Spools of fiber only provide delay. They do not address the various other impairments that exist in a network.
It is as if we improved our auto-pilot system testing to include fixed amounts of wind from a single direction. Factors such as fog, rain, snow and wind sheers are still ignored in the testing. Weather conditions are dynamic and multifaceted. Testing under a single condition is not a realistic test. As with weather, so it is with networks. Impairments in real networks do not limit themselves to a single issue.
Anue Network Emulators allow you to land your plane under any combination of adverse weather conditions.
Anue Network Emulators enable savvy network and storage providers to characterize and validate applications performance based upon multiple factors. These factors include dynamic delay representing distances up to 50,000 km, jitter, bit errors, packet sequencing and loss.
Interoperability Testing
Related Articles:
| ■ | Load Testing |
| ■ | Stress Testing |
| ■ | Domain Testing |
| ■ | Exploratory Testing |
| ■ | Recovery Testing |
| ■ | User Acceptance Testing |
| ■ | Alpha Testing |
| ■ | Beta Testing |
| ■ | Unit Testing |
| ■ | Static & Dynamic Analysis Testing |
| ■ | Functional Testing |
| ■ | Ad-hoc Testing |
| ■ | Load Testing |
| ■ | Stress Testing |
| ■ | Domain Testing |
| ■ | Exploratory Testing |
| ■ | Recovery Testing |
| ■ | User Acceptance Testing |
| ■ | Alpha Testing |
| ■ | Beta Testing |
| ■ | Unit Testing |
| ■ | Static & Dynamic Analysis Testing |
| ■ | Functional Testing |
| ■ | Ad-hoc Testing |
| ■ | Volume Testing |
 |
 |
 |
 |