I am working with the topology of three switches.sw1---sw2---sw3
I have created the testcases with sw1 and sw2.Now i want to run the same testcases on sw1 and sw3.Is there a way i can parametrize the sessions so that before running the testcase i can decide whether to run it on sw2 or sw3.Thanks
There are dozens of ways of doing this in iTest and it all depends on how your testcases/testbeds/session profiles are organized.
Simplest way would be:
1. Create a testcase (a.fftc) which uses opens a session using a testbed (a.fftb) which has a device named "foo". In a.fftb, you set the IP address of foo to 1.1.1.1.
2. Create b.fftb which inherits from a.fftb and only thing you change is the IP address to 2.2.2.2.
Now you can run a.fftc using a.fftb or b.fftb.
This is the ideal way of thinking about running a single testcase against multiple testbed files. This way will give you the best "iTest Editing/Debugging" experience!
Some people do not like this approach because they have to create multiple testbed files. These people create a single testbed file a.fftb - but set the IP address in the testbed to "[param ipaddr]" or any other fields one wants to configure.
Now when one runs a.fftc against this a.fftb, the parameter ipaddr has to come from somewhere. You can add a default value in a.fftc or a.fftb - but as in your case, you want to dynamically change this value based on "sw1" or "sw2" or "sw3". So now you have create parameter files.
If you create parameter files "a.ffpt" and"b.ffpt" with two different values for parameter "ipaddr", you can right click on the parameter file in ITestGUI's iTest Explorer and make the appropriate file Global parameter file and run the testcase. The testcase will run using the parameters from the global parameter file.
If you do not want to create parameter files and want to provide parameters directly, you can do it using iTest's commandline program called "itestcli" or "itestrt".
itestcli -param ipaddr=2.2.2.2 -tb a.fftb project://your_project/a.fftc
will run the testcase with ipaddress of "foo" set to 2.2.2.2.
There are many other solutions which people have come up with - but the main ideas remain the same. I have given this as a single device example - but you can extend it to as many devices in your testbed as you want. I still like the first solution because it keeps things clean and lets you run testcases from within iTest GUI.
One point is especially important to understand:
Each test case in iTest has a property that identifies the testbed appropriate for that test case. But you should really think of this as a "prototypical testbed suitable for this test case". In other words, this testbed represents an example of a testbed that can be used with this test case. But you can run your test case with any other testbed -- as long as that other testbed has appropriate devices with the same names. (Remember that the name of a testbed device is not meant to be its host id or whatever. It's name is meant to be an abstract name for the device as viewed by this test case. For example, you might name each router in a three-router configuration as "router1", "router2", and "router3". The testbed contains the assignments of those abstract device names into solid addressing (and other) information.
While developing a test case (i.e., inside iTest itself), Kumar's first suggestion is the best practice: create a spearate testbed file for each different variant that you want to work with inside iTest. When you want to run a test case (or multiple) against a different testbed, just right-click on that testbed in iTest Explorer and set it to be the "global testbed". When you next execute, iTest will use that testbed instead of the one in the test case. (Actually, iTest will ask you to confirm this choice the first time.)
When running your tests in regression, you may reasonably not want to keep creating new testbed files. In that case, depending on your situation, you may be selecting an appropriate testbed file from a pool, or your regression system can generate a suitable testbed file on the fly. (Testbed files can be very simple -- in many cases they just refer to session profile URIs and provide an IP address for each device, for example.)
Hi
I found this post prior to posting an issue I'm experiencing.
I am using itestcli to do exactly what you have described here. I have a number of test cases that I can execute on a number of devices by passing a different TBML file (using -b <tbml file>) along with other - test case specific - parameters (using -p). Each TBML file has a device called CPE defined but each TBML has a different session profile for the corresponding CPE. One device is a switch (3560) & the other is a router (2911). I've actually got a 2921 also which works fine.
I was having trouble with one of the test cases whereby it worked when 'pointed' at one device but not when pointed at another. The test case applies configuration to the device. When I run it from CLI it hangs at opening the session to the switch but not when opening to the router.
The only way I could resolve this was to copy the TBML file AND the sesssion (ffsp) profile from the router and then make the necessary changes for the switch. I then had to manually connect to the switch & run some commands so that it would learn the prompts. When I did this it worked !!
Have you experience this? I think it's a bug.
Would appreciate your comments before I post this as an issue.
