Article Written by Dr. Todd Law
Automation,
APIs, virtual, virtualization, containers, containerization
In my role at Spirent as a senior product manager for
automation, much of my time is concerned with our traffic generator products,
their APIs, the surrounding languages and operating systems, and various pieces
of supporting software. However, a new angle has recently come into focus
for many customers who are exploring new ways to increase their efficiency in
testing, specifically the use of virtual.
Traditionally, test beds are comprised of physical devices under
test (DUT) connected to physical test tools such as a Spirent TestCenter
chassis loaded with hardware ports. Recently, however, more and more of
our customers are setting up test beds where both the DUT and Spirent
TestCenter exist in virtual form only. Some of the advantages to such a
strategy are the obvious ones, such as a clear reduction in cost, and the
ability to run many tests in parallel.
A less obvious advantage (but one that might ultimately bring
higher value) is the ability to package up the entire automation environment,
including virtual DUT, virtual traffic generator, and test scripts, etc. to be
handed off to other stakeholders. Those stakeholders maybe be internal,
such as colleagues who are testing implementations before physical versions of
chipsets arrive; they may also be external, such as customers who need to
run acceptance tests for each major purchase or new release of DUT
software. While automation simply makes sense for these repetitive tasks,
what might be more important is defining a consistent environment across the
various users of such automation. When customers are the stakeholders
running standardized tests, this acceleration of testing can also mean speeding
up the sales process - something SEs and sales teams in general tend to be very
happy about.
Fortunately, Spirent TestCenter is far and away the leader in
offering virtualized, and now containerized, incarnations of test ports.
Spirent TestCenter Virtual (shown as STCv in diagram) and Spirent TestCenter
Container ports are available at 1G, 10G and 40G rates, and are also supported
on the most commonly used hypervisors. Our customers can also take
advantage of our virtualized LabServer to run the Spirent TestCenter
application for a completely virtualized deployment. The diagram below
shows how these virtualized components could be used together in a test bed
topology.
Furthermore, from an automation perspective, the exact
same APIs that are used to drive the hardware versions of Spirent TestCenter
can also be used to drive the virtual and containerized versions of Spirent
TestCenter. This brings yet another efficiency for test engineers who are
developing scripts - they no longer need to hog valuable and expensive hardware
ports while they are getting their scripts working.
Please check out the following resources to learn more:
##
About the Author
Dr. Todd Law's professional experience includes
over 18 years in the networking industries, with leading employers such as
Hewlett-Packard, Agilent Technologies, Nortel Networks, and now Spirent
Communications. Network test has been his focus for the past 14 years,
and he has specialized in automation aspects of network test for the past five
years. During that time, he has driven automation strategies that span
from traditional script-based techniques, to next-generation automation tools
which bring orders of magnitude in automation efficiency. Most recently,
Dr. Law has also been instrumental in the formation of the Network Test
Automation Forum, or NTAF, whose mission is to standardize the mechanism by
which various test solutions communicate with one another.
