Essentials of Spirent TestCenter Automation

Essentials of Spirent TestCenter Automation

Introduction

Spirent Communications

Course Description

� The Essentials of Spirent TestCenter Automation Web-based

course is designed to present an overview of Spirent TestCenter

Automation to all Beginning, Intermediate and Advanced Users.

� Since it is a web-based course, you can choose to view only the

topics of interest or the entire course.

� Viewing all the topics within the course will take about 2.5 hours.

Introduction


Course Objectives

� After completing this course, participants will be able to:

� Identify and describe the key elements of Spirent TestCenter Automation API.

� Identify and describe the flow for a basic Spirent TestCenter API test.

� Identify and describe the purpose of Spirent iTest and Spirent Velocity.

� Identify and describe how Spirent Services can help you Automate your

Network Testing.

� Form an opinion on the level of commitment required to automate your Network

Testing.

Introduction


Course Topics

� Automation Advantages

� Spirent TestCenter Automation Overview

� Spirent Test Center API Installation/Environment

� Spirent TestCenter Automation Architecture Overview

� Basic Flow of Spirent TestCenter Automation

� iTest Overview

� Professional Services

Introduction


© Spirent Communications, Inc. All of the company names and/or brand names and/or product names and/or logos referred to in this document, in particular the name “Spirent” and its logo device, are either registered trademarks or trademarks pending registration in accordance with relevant national laws. All rights reserved.

Specifications subject to change without notice.

spirent.com

Thank You

Essentials of Spirent TestCenter Automation

Automation Advantages







� iTest Overview


Course Topics Overview


Networking Environment


� Scalability

� Reliability

� Performance

� Speed


Network Testing Process Goals


� Quality

� Accurate

� Complete

� Time to Market

� Time is money

� Comprehensive

� Detailed

� Functional/Conformance/Performance

� Interoperability


Network Testing Challenges


� Smaller budget, fewer people, more testing

� No time to train inexperienced staff on test methodologies

� Repetitive test cycles taking up too much time in front of a test GUI

� Scalability testing takes hours to configure

� Simple configuration errors wastes finite testing time.


Manual / Automated Testing



Automation Benefits


� Quality

� Run more tests in less time with fewer resources to identify more system issues.

� Long Term Cost Reduction

� Running automated test scripts for each release almost at zero extra cost.

� Comprehensive

� Easy to build test suite that covers every aspects of the requirement specification.

� Consistency

� Automated test performs the same steps every time avoiding manual errors.


Automation Benefits


� Speed

� Automated test runs faster than GUI generated test.

� Large scale test are faster to create in a script.

� Re-use/Re-engineer

� You can re-use scripts or if required re-engineer scripts written for one build or feature for other builds with minimal rework.

� Customization

� You can create customized actions such as resetting the DUT in the middle of test runs.

� You can create custom GUIs.

� Integration with 3rd Party Lab Test Tools, i.e., Cisco ATS, Juniper JT etc.


Automation Concerns


� Resources

� Requires skilled programmer to structure the automation properly.

� Requires skilled test methodology individual when creating scripts.

� Time

� Creation of automated test suites typically longer than GUI versions.

� Maintainability

� Scripts may require updating in order to support changes to system or testing environment.

� Small changes in script may lead to large changes in the output.


Manual vs. Automated testing


Manual Testing Automated testing

Requires test engineers presence Not required

Verification of result done manually Results are verified with predefined pass criteria.

Tester should have complete knowledge on topology, technology and expected result.

Running the automated test suites does not require complete understanding on topology and technology.

Cost for running manual test is fixed. Initial investment to create automation suite is heavy. Further regression run will be almost at zero cost.

Prone for manual errors No manual errors.


Commitment to Automation


� Do you have the available resources to develop scripts? Maintainscripts?

� How much time will it take to develop automated test scripts?

� What is your ROI?

� Do you have a budget for outside development resources?

� Are your test cases common or specific?

� Are there products that let you live in both worlds?




spirent.com

Thank You

Essentials of Spirent TestCenter AutomationSpirent TestCenter Automation

Overview







� iTest Overview




Spirent Test Center Automation

Spirent TestCenter Automation Overview

� Spirent TestCenter allows you to configure and run tests from

the GUI or from a script.


Spirent TestCenter Automation Benefits


� Quality

� Accurate

� Complete

� Time to Market

� Time is money

� Comprehensive

� Detailed

� Functional/Conformance/Performance

� Interoperability


Automation Categories


� As a user of Spirent TestCenter Automation you most likely will fall into one of the three automation categories.

� Beginning Automation Users:

• possess limited programming and/or test automation experience.

• will benefit from the GUI to Script option.

• could utilize Command Sequencer and Save as Script to aid with test creation.


Automation Categories


� Intermediate Automation Users:

• possess some automation experience including basic Tcl skills.

• will need to know enough about the Spirent TestCenter API in order to customize test attributes and results.

• could utilize iTest with test creation.

� Advanced Automation Users:

• advanced users typically have in-house scripting experts and utilize their own framework and script libraries.

• advanced users need to know how to incorporate Spirent TestCenter automation into their own framework and libraries.

• could utilize iTest to aid with test creation.


GUI to Script


� GUI to Script option is designed to ease Spirent TestCenter Automation for non-programmers.

� Configure the test within the Spirent TestCenter GUI, create a Command Sequence and then with the click of a button, generate two Tcl scripts that contain all necessary test information.

� User can easily execute this automated Tcl test from a standard Tcl shell.


Save as Script (GUI to Script)



Executing Saved Script



Save as Script Advantages


� Ease of Use

� Automation skills NOT required

� Reduce time for writing a test case

� Minimizing errors in writing test script manually.


Spirent TestCenter Automation API


� The Spirent TestCenter Automation Application Program Interface (API):

� allows scripts created using Tcl to configure and control the Spirent TestCenter.

� provides access to a complete Data Model that aids in Spirent TestCenter script creation.

Generic tclsh or wish

set… unset… puts… if..

Built-in Tcl Commands

tclsh or wish with API Loaded

stc::perform…

Spirent TestCenter API Tcl Commands

stc::create …


Spirent TestCenter API Command Objects


System

Project

Port

Host Router Stream Block AnalyzerGenerator

CommandSequencer

Results

Capture


STC Automation Online Help


� The Spirent TestCenter Automation API provides Online help that the user can use to

obtain more information on the API syntax.

� stc::help commands is used to retrieve the syntax of the given object/command in Tcl

console after STC Library is loaded.% stc::help commands

apply: -Applies a test configuration to the Spirent TestCenter firmware

config: -Sets or modifies the value of an attribute

connect: -Establishes a connection with a Spirent TestCenter chassis

create: -Creates an object in a test hierarchy

delete: -Deletes an object in a test hierarchy

destroy: -Cleans up the project, disconnects from all the chassis, and unloads the BLL.

disconnect: -Removes a connection with a Spirent TestCenter chassis

get: -Retrieves the value of an attribute

log: -Writes a diagnostic message to the log file

perform: -Invokes an operation

release: -Releases a port group

reserve: -Reserves a port group

sleep: -Suspends application execution

subscribe: -Directs result output to a file or to standard output

unsubscribe: -Removes a subscription

waitUntilComplete: -Suspends your application until the test has finished


Automation Documentation


� There are several Spirent TestCenter Automation documents:




� Spirent TestCenter Automation Overview Manual is a good start for a beginner. It provides an overview of Spirent TestCenterAutomation and how to use the Spirent TestCenter API to create a test configuration, run the test, and retrieve test results.

� Spirent TestCenter Automation Programmer’s Reference provides more information about the Spirent TestCenter Automation API syntax and functions. It also provides descriptions of how to use the API along with examples of creating and running test configurations.

� Spirent TestCenter Automation Object Reference documentation contains API Object syntax. There is a PDF format and a HTML format. A user can choose a format which he likes.




� You can download all of the Automation Documentation in one installation from http://support.spirent.com website after you request an account and login.




� In Windows, after the documentation is installed to your PC, you can access the documentation through Start->All Programs->Spirent Communications->Spirent TestCenter x.xx->Documentation.

� In Windows, there is also a list of sample scripts installed once the Spirent TestCenter application software is installed.


Supported Environment


� The Spirent TestCenter Automation API will run on Windows, Unix and Linux platforms.

� Tcl 8.4/8.5, Python 2.6/2.7, Perl 5.8/5.14 are supported in addition to C/C++, C#, Java, and Ruby. Refer to Spirent TestCenter x.xxSoftware and Hardware Release Notes for more details on supported computer OS, 32-bit or 64 bit, programming languages and their versions.

� Full release (Windows PC only) will include both Tcl/Python and automatic installation.

� Linux and Unix Automation only release will NOT include any version of Tcl/Python and requires manual installation.


Spirent TestCenter Automation API Benefits


� The ability to use Tcl and other programming languages to configure and control the Spirent TestCenter.

� The ability to take advantage of GUI based tools within an automated environment.

� The ability to control the DUT between test iterations.

� The ability to create complex Tcl scripts that will perform Conditional Processing such as reporting test case Pass/Fail.


Spirent TestCenter Extreme Automation


� GUI to Script (Save as Script)

� Command Sequencer

� Results Reporter


Command Sequencer


� The Command Sequencer is a Spirent TestCenter GUI tool that:

� allows you to create complex Command Sequences.

� allows you to quickly and easily create loops, for example increase the test load by 10% on each test iteration.

� allows you to create the associated API syntax using the GUI to Script feature.

� allows you to alter the test configuration without stopping the test.

� The Command Sequencer is not used to Configure the test traffic.


Creating a Command Sequencer



Spirent TestCenter Results Reporter


� Spirent TestCenter Results Reporter is a reporting tool used to analyze and display data generated by either a Spirent TestCenter GUI or a Spirent TestCenter Automation API test.

� Results Reporter runs on Windows platforms.

� Spirent TestCenter stores results (statistics, configuration, and views) generated both during and after a test.

� All results saved in an SQLite database.

� The Results Reporter can open, display, and analyze any number of SQLite databases.


Displaying Results with Results Reporter





spirent.com

Thank You

Essentials of Spirent TestCenter AutomationSpirent TestCenter API

Installation/Environment







� iTest Overview




Spirent TestCenter Automation API

Spirent Test Center API Installation/Environment

� The Spirent TestCenter Automation Application Program Interface (API):

Generic tclsh or wish

set… unset… puts… if..

Built-in Tcl Commands

tclsh or wish with API Loaded

stc::perform…

Spirent TestCenter API Tcl Commands

stc::create …

� allows scripts created using Tcl to configure and control the Spirent TestCenter.

� provides access to a complete Data Model that aids in Spirent TestCenter script creation.


Supported Environment


� The Spirent TestCenter Automation API will run on Windows, Unixand Linux platforms.

� Tcl 8.4/8.5 is supported.

� Full release (PC only) will include both Tcl and automaticinstallation.

� Automation only release will NOT include any version of Tcl.

� Automation only release will require manual installation.


Full Install (PC/Windows Only)



STC Automation API Access


� Once installed, there are three methods of gaining access to theSpirent TestCenter Automation API from Tcl:

� Create a link to the Spirent TestCenter Application folder to the Tcl lib folder(Not recommended).

� Copy the entire Spirent TestCenter Application folder to the Tcl lib folder (Notrecommended).

� Create TCLLIBPATH Environment Variables statement from Windows ControlPanel to include access to the Spirent TestCenter Application folder(Recommended).


Key STC Automation API Tcl Scripts



Loading Automation API Library


� There are two methods to load the Spirent TestCenter Automation API within Tcl:

� Using “package require” command

% package require SpirentTestCenter

� Using “source” command

% source SpirentTestCenter.tcl


TCLLIBPATH Environment Variable



Setting TCLLIBPATH



Verifying TCLLIBPATH


Correct TCLLIBPATH Result

If TCLLIBPATH is set incorrectly, the command “package require SpirentTestCenter” will fail


Loaded Automation API



Alternate Edits to pkgIndex.tcl Help



Using source Command


� When you use the source command, you must ensure that youhave access to the Spirent TestCenter Application directory.


Linux Install


� Unzip the Spirent_TestCenter_Auto_Linux_x.x.tar.gz file.


Linux Automation API Directory



Setting Environment Variables


� Set TCLLIBPATH and LD_LIBRARY_PATH environment variables.


Setting Environment Variables


� Set “auto_path” using “lappend” in Tclsh or Tcl script.

o Alternately, user can set “auto_path” using “lappend” in Tclsh or Tcl script ifhe doesn’t set TCLLIBPATH and LD_LIBRARY_PATH environment variables.




spirent.com

Thank You

Essentials of Spirent

TestCenter AutomationSTC Automation Architecture Overview







� iTest Overview




Spirent TestCenter Automation API Elements

Spirent TestCenter Automation Architecture Overview

� The Spirent TestCenter Automation API elements are supported by Tcl, Python, Perl, C/C++, C#, Java, and Ruby.

� A Spirent TestCenter Automation API script consists of:

� Objects

• Test Configuration Objects

• Protocol Data Unit Objects

• Command Objects

� Functions


Object Handles and Attributes


� Spirent TestCenter Automation API Objects:

� are identified via Handles.

� posses Attributes that describe the properties of the Object.

� An Object Handle is an entity that uniquely identifies a Spirent TestCenter Automation Object.

� Object Handles are the links between your application and the Spirent TestCenter Automation Object hierarchy.

� Object Attributes specify the characteristics of an Object. For example, fixedFrameLength is an Attribute of the StreamBlockObject and it will specify the number of bytes in a frame.


Test Configuration Objects


� Within a script using the Spirent TestCenter Automation API, you will configure Test Configuration Objects.

� Streamblock

� Vlan

� Router

� Test Configuration Objects:

� describe the components of your test configuration.

� provide the data that Spirent TestCenter needs to create and run a test.

� Test Configuration Objects include:

� Project

� Host

� Port


Test Configuration Object Descriptions


� Test Configuration Object descriptions are located within the Test Configuration Object Index of the Spirent TestCenter Automation Object Reference document.


Partial Test Configuration Object Hierarchy



Port Object Example



Protocol Data Unit Objects


� Within a script using the Spirent TestCenter Automation API, you may configure Protocol Data Unit Objects.

� Protocol Data Unit Objects:

� are a single collection of attributes that define protocol traffic format.

� Protocol Data Unit Objects include:

� EthernetII

� IP

� TCP


Protocol Data Unit Object Descriptions


� Protocol Data Unit Object descriptions are located within the Protocol Data Unit Object Index of the Spirent TestCenter Automation Object Reference document.


TCP Object Example



Command Objects


� Within a script using the Spirent TestCenter Automation API, you may configure Command Objects.

� Command Objects:

� define test actions.

� Command Objects include:

� StartProtocolCommand

� CaptureStartCommand

� L2LearningStartCommand


Command Object Descriptions


� Command Object descriptions are located within the Command Objects Index of the Spirent TestCenter Automation Object Reference document.


GeneratorStartCommand Object Example



Data Model Manipulation Commands


� The Spirent TestCenter Automation API contains 17 Functions to manipulate the data model.

� apply, config, connect, create delete, disconnect, get, help, helplist, log, perform, release, reserve, sleep, subscribe, unsubscribe, waituntilcomplete

� The 17 Spirent TestCenter Automation API Functions support the following operations:

� Object Creation

� Object Configuration

� Object Retrieval

� Performing Operations (Command execution)

� Object Deletion


Automation API Functions


Sends a test config to the Spirent TestCenter Chassis� apply:

� config:

� connect:

� create:

� delete:

� disconnect:

Set or change the Attributes of an Object

Connect to a Chassis

Creates new Objects within the Data Model

Removes Objects from the Data

Disconnect from the chassis


Automation API Functions Continued


Retrieve the value of an Object’s Attribute� get:

� help:

� helplist:

� log:

� perform:

� release:

Displays help about STC Automation API and Data

Extends help functionality to list and search Commands

Writes diagnostic message to log file or to standard output

Perform an action on an Object

Release a Port


Automation API Functions Continued


Reserve a port� reserve:

� sleep:

� subscribe:

� unsubscribe:

� waitUntilComplete:

Suspends the test execution

Enables real-time result

Removes a previously established subscription

Blocks your application until the test has finished


API Functions Documentation


� You must use the Spirent TestCenter Automation Programmers Guide to retrieve the exact syntax for each API Function.


Automation API Syntax


Spirent TestCenter Automation Programmers Guide


Automation API stc namespace


� The Spirent TestCenter Automation API is referenced through the namespace “stc.”

Command

Return Value (Handle)

� The supported method of identifying Spirent TestCenter Automation API Functions in a script is to use the “stc” namespace.

% stc::create project

project1


Online Help


� You can also obtain information about the API Functions by using the help command.

� stc::help - Displays help about the Spirent TestCenter Automation API and data model

% stc::help connect


Object Handles


� Objects are identified within the script by Handles.

� You must create certain Objects and their Handles using the stc::create API Function. Other Objects and their Handles are automatically created.

� You can save the Handle for later reference:% set hProject [ stc::create project ]


Object Attributes


� All the Spirent TestCenter Objects have Attributes which represent the Object properties. If you do not specify a value, a default value is inserted for you.

� You can set the Attributes while creating the object

% set hProject [ stc::create project -Name “Main”]

� You can retrieve Attributes values using the stc::get API Function.


Setting Object Attributes


� You can also set Object attributes at a later time by using the stc::config API Function.

% stc::config $hProject –Name “MainProject”


Objects Parent/Child Relationships


� For all non-automatically created Objects, you must create the Object under the appropriate Parent Object. The parent name is mentioned by using the -under option of the stc::create API Function.% stc::create port –under $hProject


Retrieving Child Handles


� You can retrieve the Handles of Children Objects of a Parent Object by using the Parent’s Object Handle:%stc::get $port1 -children

� You can also filter the Children Handles, by specifying an Object type:%stc::get $port1 -children-analyzer


Advanced Attribute Notation


� You can also identify an Object’s Attribute in two additional ways without retrieving the Object handle using the parent/child relationship:

� DDN – Direct Descendant Notation

� DAN – Dotted Attribute Notation

� DDN – identify an object without having to retrieve its handle

� handle.type[.type...]

%stc::get $hProject.port -Layer3Type


Advanced Attribute Notation Continued


� DAN – attributes of descendant objects

� -type[.type...].attribute

%stc::get $hProject -Port.Layer3Type

� Both examples retrieve the Layer 3 Type from the first child port of “$hProject”




� DAN

� -type[.type...].attribute

%stc::config $hProject –port.location "mychassis1/1/2“




� Indexing allows changes to children Objects other than the first child Object.

%stc::config $hProject.Port(2) -location “mychassis1/1/2”

%stc::config $hProject –Port(2).location "mychassis1/1/2“

� Indexing starts at 1.


Other Relationships between Objects


� Parent/Child relationships are usually handled automatically.

� Certain Objects require an explicit relationship to be establishedwith other Objects other than the parent/child type of relationship.

� For example, you must associate a Router Object with a PortObject, however, there is no parent/child relation betweenRouters and Ports.


Relation Reference


� A relation reference specification can be one the following:

� -relationType-side[-objectType]

� -DANPath-relationType-side[-objectType]

� -sideName[-objectType]

� A relation definition:

� specifies two sides to the connection between Objects, identifying the Objecttypes that can be used as “sources” and “targets”.

� specifies side names. You can use a side name as a shortened form of arelation reference to access the objects in a relation. For the parent-childrelation, the side names are “parents” and “children”.


© Spirent Communications, Inc. All of the company names and/or brand names and/or product names and/or logos referred to in this document, in particular the name “Spirent” and its logo device, are either registered trademarks or trademarks pending registration in accordance with relevant national laws. All rights reserved. Specifications subject to change without notice.

spirent.com

Thank You


TestCenter AutomationBasic Flow of Spirent TestCenter Automation







� iTest Overview




Sample Script Topology

Basic Flow of Spirent TestCenter Automation


Partial Test Configuration Object Hierarchy



Required Documents



Basic Spirent TestCenter Automation Test Flow


� Initialization� Connect to the Spirent TestCenter chassis and reserve Ports.

� Create the Object hierarchy

� Establish a Subscription for test results

� Apply the Configuration

� Start Analyzer/Generator/Capture

� Transmit Traffic

� Stop Analyzer/Generator/Capture

� Gather Results

� Release the Ports and disconnect from the chassis


Initialization


� Load in the Spirent TestCenter Automation API.

� Create any equipment/system variables.


Connection


� The stc::connect API Function establishes the connection between the script and a Spirent TestCenter chassis.

stc::connect chassisIP

� You can find the syntax for the connect API Function in the Spirent TestCenter Automation Programmers Guide.


Reservation


� The stc::reserve API Function reserves one or more Ports on one or more Spirent TestCenter chassis.

� When you reserve a Port, your test session has exclusive access to that Port for the purpose of running a test.

stc::reserve “Chassis/Slot/Port”


Create/Configure Project


� The test must contain a Project Object.

� You will use the stc::create API Function to create the Project Object.

� When created, the Project Object is automatically placed under the System Object.

� You will create Port Objects as well as other Objects under the Project Object.


Create/Configure Ports


� The next step of the script is to create test Port Objects for generating/receiving traffic.

� You will use the stc::create API Function and the Port Object to create the (logical) Ports.

� You will create the Port Object under the Project Object.

� You must map these (logical) Ports with the (physical) Ports that you reserved on the Spirent TestCenter Chassis.


Default Port Attributes



Map Ports/Apply Configuration


� You will use the stc::perfrom API Function to call the SetupPortMappingsCommand Object to map the (logical) Ports to the (physical) Ports.

� You can find the syntax for the SetupPortMappingsCommandin the Spirent TestCenter Automation Object Reference document.

� You must send the configuration to the hardware using the stc::apply API Function.


Create/Configure StreamBlocks


� In Spirent TestCenter, you will configure the traffic Stream Blocks under Port Objects using the stc::create API Function and the StreamBlock Object.

� A Stream Block is a template that describes the definition of the stream.

� The Stream Block Configuration Object template provides the options for configuring Stream Blocks containing Source Addresses, Destination Addresses, etc.

� If you are not configuring a Stream Block from scratch then you must specify -frameConfig “ ” within the configuration.


Creating a Stream Block Script



Configure Generator


� The Generator Object will transmit the traffic created by the StreamBlocks.

� You will specify Traffic properties such as Load, Duration, and Scheduling Mode within the GeneratorConfig Object.

� When you created the Port Object, the Automation API automatically created a Generator Object and a GeneratorConfigObject.

� You will retrieve the Generator Object Handle using the stc::getAPI Function first and then the GeneratorConfig Object Handle before setting the Generator configuration.

� Before you configure the Generator it is good practice to stop it using the stc:perform API Function and the Stop Object.


GeneratorConfig Object Documentation


Spirent TestCenter Automation Object Reference Document


Configuring Generator



Configure Analyzer


� The Generator Object will transmit the traffic created by the StreamBlocks.

� The Analyzer Object is used to analyze the results based on the options provided. Each port has independent analyzer filter settings.

� You can select customizable histograms that display in real-time:

� Inter-arrival time

� Latency

� Frame length

� Sequence run length� Sequence difference check� Jitter

� You can create custom 16 or 32-bit filters by specifying a specific location in the frame.

� Just as with the Generator Object, the script must retrieve the Analyzer Object Handle, initialize the Analyzer Object and then retrieve the AnalyzerConfig Handle before setting the Analyzer configuration.


Configuring Analyzer


Spirent TestCenter Automation Object Reference document


Subscribe to Results


� The Spirent TestCenter Automation API has two types of results:

� Run-Time

� End-of-Test

� Run-time results are available while connected and the Object is active.

� End-of-test results are written to the results DataBase and are available after the script has completed.

� End-of-test results not written to the DataBase are lost upon disconnection/release.

� The script must Subscribe to any requested result.


Real-time Result Subscription


� The Spirent TestCenter Automation API maintains a set of real-time counters that are updated periodically.

� Use the subscribe API Function to enable result collection.

% stc::subscribe -Parent $hProject1

� A few of the available Real-time Results:

� Port Statistics

� CPU Statistics

� DiffServ Statistics

� Overflow Statistics

� Stream Groups


Identifying Result Subscription


Spirent TestCenter Automation Object Reference document

Spirent TestCenter Automation Programmers Guide


Subscribing to Results



get Option


� The Spirent TestCenter Automation API also provides the option to get the Port results using the stc::get API Function.

%stc::get AnalyzerPortResults1

� This statement will return an array, which will have counters for the attributes such as Frame Count, Bytes received, etc.


Apply the Configuration


� The subscribe API Function automatically will apply the subscription to the Spirent TestCenter Hardware.

� You can still use the stc::apply API Function to manually upload any additional configuration changes if you would like.


Starting the Test


� Start the Analyzer first using the stc::perform API Function.

� Start the Generator after the Analyzer.

� The stc::sleep API Function suspends your application for the specified duration (in seconds).


Stopping the Generator/Analyzer


� Once all of the traffic has been sent or after a period of timedefined by the script, you will want to stop the Generator and thenthe Analyzer using the stc::perform command.

stc::perform AnalayzerStop –AnalyzerList $hAnalyzer

stc::perform GeneratorStop –GeneratorList $hGenerator


Gather Results


� Gather the results from the Results Subscription specified previously using the stc::get API Function.

� You can retrieve any value that is stored within the Subscribed value (in our example, AnalyzerPortResults).


Results from the SQLite DataBase


� You can also gather End-of-Test results from the SQLite DataBase using the stc::perform API Function.


Clear Results


� You can also clear the Protocol / Traffic or the results using Automation API Clear commands.

Example:

stc::perform ResultsClearAll


Clean up the Script


� Release any reserved Port Groups using the stc::release API Function. A Port Group may contain more than one Port, any attempt to use a Port Handle after it has been released will result in an error.

� Disconnect from the chassis using the stc::perform API Function.

� Delete the Project Object to release any resources accumulated through use of the API using the stc::delete API Function.


Cleaning up the Script



AutomationOptions


� The Spirent TestCenter Automation API allows you to specify system logging functions by using the stc:config API Function to configure the AutomationOptions Object.

� You can specify the message type as well as display the messages to the screen or to a file.

� There is also an advanced attribute (SuppressTcl) that allows you to suppress Tcl errors.

% stc::config AutomationOptions \

-LogLevel DEBUG \

-LogTo Debug.log


AutomationOptions



Issues running in Tcl Interactive Mode



Deleting the Project with catch


� Use the Tcl catch command to delete the Project if required:

% catch {stc::delete $hProject} err


Sample Script Topology



Partial Object Hierarchy



Create/Configure Hosts


� A Host Object is a logical entity that you can use to define endpoints for many different traffic types and topologies.

� Host Objects are created using the stc::create API Function.

� The Spirent TestCenter Automation API provides methods to configure the properties of the Host Objects.

� Hosts are created under the Project Object and should be bound with a Port to act as a simulated Device.


Creating/Configuring a Host Object



Create/Configure Routers


� Similar to Hosts, the Automation API can also emulate one or more Routers.

� Router Objects are created using the stc::create API Function.

� The Spirent TestCenter Automation API provides methods to configure the properties of the Router Objects.

� Routers are created under the Project Object and should be bound with a Port to act as a simulated Device.


Configure Capture (Optional)


� The Spirent TestCenter Automation API supports the CaptureObject option that allows you to capture packets on a receivingport.

� When you created the Port Object, the Automation APIautomatically created a Capture Object, therefore, the script mustretrieve the Capture Object Handle before setting the Captureconfiguration.

� You will use the stc:config API Function and the Capture Objectdescription to specify the Capture configuration.

� You will use the stc::perform API Function to Start/Stop andSave the Captured Data.


Configuring Capture



© Spirent Communications, Inc. All of the company names and/or brand names and/or product names and/or logos referred to in this document, in particular the name “Spirent” and its logo device, are either registered trademarks or trademarks pending registration in accordance with relevant national laws. All rights reserved. Specifications subject to change without notice.

spirent.com

Thank You


TestCenter Automation

iTest Overview







� iTest Overview




iTest Overview

� Different Versions of Software

� Responses Change

� Must Test Current and Past Versions

� Different Devices Under Test (DUTs)

� Prompts May Be Different

� Commands May Be Different

� Different Programmer Skillsets

� Manual Testers may not have scripting or coding capabilities

� Scripters/Programmers may have different language expertise (Java, C++, Perl, Python, TCL, etc.)

Automation Issues


� Spirent iTest ® is an interactive test development environment that seamlessly interacts with a wide range of devices, API’s, languages and environments.

iTest Overview

iTest Description

� Spirent iTest ® is tightly integrated with Spirent’s Velocity ®solution to further extend and empower the automation capabilities of iTest, including the management and automation of the setup and cleanup of the testbed itself.

� The user experience provides programmers and non-programmers a simple way to rapidly create test cases for a wide variety of uses.


iTest Overview

iTest Application


� iTest sessions provide a simple way to interact with almost any device, software API, physical or virtual environment.

� From command line, to Web interfaces, creating a sophisticated test script can be as simple as opening the session and interacting with the DUT just like during manual testing.

� The interactions along with the responses are automatically captured and stored for later use.

� Each session profile can be inherited from another session profile, making test maintenance extremely easy.

iTest Overview

iTest Session


� iTest integrates with almost any test tool and has a wide range of integrated test tools from Spirent and third-party vendors.

� Spirent Avalanche

� Spirent Landslide

� Spirent TestCenter

� Ixia IxExplorer

� Ixia IxNetwork

� Ixia IxLoad

iTest Overview

iTest Test Tool Support


� One workspace, multiple projects.

Automation Projects

Device Projects

Resource Project

iTest Overview

iTest Projects

� Three Main Types of Projects

� Device Projects (many)

� Automation Projects (1 or more)

� Resource Project (1)


� One Project Per Device/Device Type

� d_JunOS, d_Cisco d_IOS, etc.

� No dependencies on Automation Projects

� Consistent naming convention:

� Session profile filenames:

<deviceIdentifier_sessiontype.ffsp>

� Quickcall filenames:

<device_sessiontype_Quickcalls.fftc>

iTest Overview

iTest Device Projects


� One Project Per Automation Focus

� a_regression, a_sanity, a_basicTests

� Consistent naming convention:

� Test case filenames:

<testtype.fftc>

� Topology Filenames:

<testtype.tbml>

� No Device Specific Assets

iTest Overview

iTest Automation Projects


iTest Overview

� Special Project for iTest Resources

� Contains Export Templates for:

� Test Reports

� Test Scripts

� Capture Reports

� Contains SNMP MIBS

iTest Resource Projects


� Using iTest, it is extremely easy to:

� Create a test case using Capture

� Adding/modifying steps to test case

� Adding analysis as well as pass/fail criteria

� Execute the test case

� Create the HTML test report

iTest Overview

Sample Test Case Usage


iTest Overview

Create a Test Case using Capture


iTest Overview

Adding/Modifying Steps to Test Case


� Ease of Use – iTest has a simple user-interface that allows forcapture/replay as well as advanced test automation

� Common Toolkit – Standardizing automation using iTest simplifiestraining of new team members and makes it easier to share testassets amongst team members

� Best Practices – Spirent provides a set of naming and workspaceorganization guidelines to make sharing and porting of assetsstraightforward

� Common Automation Standards – Spirent iTest standards ensurethat the team is developing test assets in a consistent andreusable format

iTest Overview

iTest - Getting The Whole Team Automating




spirent.com

Thank You


TestCenter Automation

Professional Services







� iTest Overview




Testing Challenges

� Effective testing in cutting edge networks demands a steep learning curve.

� Time to Market

� Budget and ROI

� Quality Improvements

� Process Visibility



Implementation Services

� 1-3 days of installation, configuration, and/or mentoring to jumpstart the user

experience for generally 1 to 4 people

� Rack & Stack plus hand-holding

� technician in the box

� 1-on-1 training

� two headed monitor monster

� Small group training

� projector party

� Assistance in the lab

� Informal Test Case development



Education Services� Options range from short video demonstrations delivered over the Web, to

multiple-day hands-on classes

� Instructor-led Training (ILT) classes are accomplished through a combination of

lecture, demonstrations, and hands-on exercises; the highest level of interaction

� Computer-based training (CBT) provides our customers the flexibility to learn any

time from anywhere

� Certification programs are designed to provide our customers with the necessary

education, experience, and subsequent validation of their skills




� Discover, Design, Develop, Deliver, Debrief

� Customized Test Methodologies

� Spirent Provides Statement Of Work (SOW)

� Captures and defines the work activities, deliverables, and timeline that Spirent must execute in performance of specified work for a client

� Includes tests matching customer's exacting requirements

� Deliverables can include:

� Test Report

� Test Configurations

� Test Scripts



Resident Engineer

� Customer requires ongoing assistance operating Spirent gear

� Could be a combination on onsite and remote

� Engagement last a minimum of 6 months; typically 1+ year

� Spirent allocates a dedicated engineer(s) to the project

� Services bring an on-site and immediate presence to facilitate a variety of

functions such as:

� Informal Training and Mentoring

� Test Case Development / Execution

� Facilitate Support Issues

� Single PoC within Spirent



Spirent Sales Representative

� Contact your Spirent Sales Representative to receive additional information

regarding your Professional Service





spirent.com

Thank You




spirent.com

This Page Left Intentionally Blank.

Essentials of Spirent TestCenter Automation

Documents

Transcript of Essentials of Spirent TestCenter Automation