datasheets.com EBN.com EDN.com EETimes.com Embedded.com PlanetAnalog.com TechOnline.com  
Events
UBM Tech
UBM Tech

Design Article

Comment


Embd SW netwk

4/26/2012 4:00 PM EDT

One comment about remote testing. The IPv6 test equipment should be connected to ...

More...



Luis Sanchez

4/26/2012 2:45 PM EDT

This article lets me see that testing can be done with different tools but ...

More...

IPv6 testing: Tips you need to know

Assaf Lev, QualiSystems

4/23/2012 10:22 AM EDT

Executing a Test Plan
Now that you have described a foundation for building a test plan the next step is considering how to execute that plan and manage your test resources. There are three components that you should strongly consider:
  1. Repeatability
  2. Measurement and reporting
  3. Resource Management

Repeatability
With IPv6 vendor code today, it is almost certain that you will find bugs or performance problems in your systems and you'll be submitting them to vendor support. When the vendor responds with the patch you will need to repeat the test for the bug itself, but also to test that no other bugs have been introduced (it happens far too often, right?). So make sure that you have built a test bed and management system that can repeat the test easily, and lets you compare the results with confidence.

For example, testing systems such as QualiSystems TestShell build a single software environment that can configure, deploy and execute the Test Plan. It has a drag/drop editor for building tests and live topology diagrams during execution.

For complex testing, you are likely to have many testing tools present such as IXIA, Spirent, Breaking Point, or even Java scripts and a test management platform that ensures that the test can be recalled from a program store, configured exactly the same parameters and perform the tests again. In effect, a testing suite for your network devices is being built.

Measurement and Report
If you are testing for performance of various devices, you need to compare and analyze the results of each product and each test run. But using many different tools, e.g., Traffic Generators, SNMP for device status, and scripts in Perl or TcL, means that reports will come from many platforms. Test systems like the QualiSystems TestShell framework can solve that by bringing the device reports into a single summary report that can be compared for all test runs and store it for future checking and validation.

Resource Management
A final consideration in larger organizations is the sharing of test resources. Traffic Generators and Test Servers aren't cheap to purchase, support or to keep the power on. Therefore the ability to share and manage those resources within a team needs more than sticky notes on a whiteboard or a spreadsheet on a shared drive.

Remote users should be able to run tests around the clock to increase utilization and allow test engineers to access resources remotely. Project teams need to book access to resources in advance while Test Managers resolve scheduling conflicts.

Again, a test system can be extended to provide a lifecycle management of the test lab – switches, servers, generators can scheduled and managed from a simple user interface.

Testing works best with Management Tools
The process of validating and testing can look complex and time consuming but the solution lies in automating the testing process. An automated testing process can be repeated quickly and easily. Testing for IPv6 compliance and stability isn't done once, it needs to be repeated until the products are stable and vendors have reached low defect levels and your confidence is high.

Testing should be performed during the procurement cycle to validate vendor claims and then repeated during the operational lifecycle to validate that the vendor software is meeting performance and quality targets. This will provide hard data and facts that can be used to improve your network and improve vendor value.

An automated testing environment provides tools that can make it possible to build test plans and then execute them from a single tool. It should combine test reports from multiple devices, and store them for future reference so that the validation process can be repeated in the future. Testing doesn't have to be hard if you can do it smart.

About the author
Assaf Lev is Director of Account Managemen at QualiSystems. QualiSystems is a leading provider of enterprise software solutions for lab management, device provisioning and test automation.





Luis Sanchez

4/26/2012 2:45 PM EDT

This article lets me see that testing can be done with different tools but nowadays seem to be concentrating in using some kind of scripting language for automating tests. Also its necessary to use source code management to handle the set of scripts and an issue tracking system to follow up on bugs. But most importantly, a good test management system which simplifies and orders the test plan and execution. It also eases the reporting tasks. I once worked without a test management system and yikes... it sucks! Mostly at the time of gathering the results and preparing a report.
Ideally all these systems should be linked so that if there's a failure or bug found in a certain test case, the test plan should link with the issue tracking system where a bug for that defect should reside. Prove of the failure in the form of log files should also be linked with the bug and the issue tracking system. Ideally perhaps through good old fashion hyperlinks. Testing is good when you have the right tools!

Sign in to Reply



Embd SW netwk

4/26/2012 4:00 PM EDT

One comment about remote testing. The IPv6 test equipment should be connected to the system(s)-under-test by a L2 network. Using a router can prevent some of the malformed packets from making it to the system under test.

Sign in to Reply



Please sign in to post comment

Navigate to related information

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)