Module8_Conditional_Logic

BASIC USER TRAINING PROGRAM Module 8: Conditional Logic

Objective

The objective on this module is to gain the understanding of how to use iTest to allow test cases to apply to a broader range of conditions

Outline

• Looping with for, foreach and while constructs • Conditional flow with if-then-else construct • Wrapping steps in control logic • Adding control manually • Lab • Quiz LOOPING LOGIC

The action column in the Test Case editor steps grid contains actions that are organized into three different sections:

• Session-specific actions • General open and close actions • Executive (Exec) actions

Session-specific actions are always listed at the top of the list values. These actions change depending on the type of session that is started by the open step. The open and close actions are used to manage opening sessions and closing them. They are listed below the session-specific commands in the list. Lastly, iTest contains a number of executive (Exec) actions that are not associated with sessions at all. These actions include comments, conditional logic, calls, etc.

The looping logic actions are part of the executive actions. For looping you can use a For, ForEach or While loop. This module assumes the student understands the differences between these types of loops. This section will focus on how to add these types of loops into your test cases.

1. Go to Home page. Click Manage Workspace. Create a lab folder under test_cases folder called Module8--Conditional Logic.

2. Hi-light the folder Module8--Conditional Logic.

3. Select file-> new >test case.

It’s already selected my conditional logic folder, and just call this module8_testcase.fftc

2. On the General page, specify the Topology to use,

Go to my_project >topologies > ff_device_topology. Click “OK”.

3. We will create a test case with some steps in it that we can practice using the different conditional logic and looping. Drag the tab for Module8_testcase to all the way to the right, until you see the split screen. 4. Just copy the comments steps from Module7_testcase by ctrl-c to Module8_testcase by ctrl-v for the following commands

• open step • show version

• show flash • show arp

Remove the analysis rules from the show version command

Look at the comment. Since you copied the parent comment, the children come with it.

Save the test case and drag the module8_testcase back. 5. You have a very simple Test Case. Let's remove all the analysis rules and some of the other tests because we are just going to use this as an example of how to use some of the other conditional logic.

6. Let’s add in one more series of commands that we did have in our other test case. Use Ctrl-Enter as a short cut key to add a step, there we can select the comment action and type the following comment text: check the 5 fast Ethernet interfaces. 7. Now, add another step. Specify a Session of \"Router\" and enter the command show ip int fast Ethernet 0. There happens to be 5 interfaces, so use Ctrl+C and Ctrl+V and then replace the 0 with 1, 2, 3, and 4.

8. Highlight all the show ip int fast Ethernet commands and indent them under the comment.

9. Add a close command for the Router session. Now we have a test case that logs in to the router, executes the show commands, and then the closes. 10. Go back to the Home page. Click Develop a test case. Select module8_testcase. Now execute module8_testcase.

Making the test mode flexible-

FOR LOOP

1. Open the test report by clicking the execution message. The report tells us that the test case is sending the show ip int FastEthernet command 5 times. This is just fine. What if we wanted to make this a little more efficient and a little more flexible? The way to do that is to use a for loop. A for loop iterates a command the number of times that you specify.

2. Let’s remove the last four show commands, and now we just have just one.

3. Right click the command, select Wrap In, and then select for loop

The loop will use a variable i, and set it to 0 to start. If you run this now, it would execute the show command 10 times.

4. Now we do not really want to send the IP address \"0\" ten times. What we really want is iterate through and have the loop set the show IP address as 1, 2, 3 and 4. (These parameters or variables are just examples so you can edit this so what you can do is for set i 0 and for ‘i’ less than 5.)

5. Substitute 0 in show ip int FastEthernet with $i. 6. Execute the test case and for the first time it will be Show int FastEthernet 0 and then 0 will be replaced here because we have field substitution available to us in this line and it will increase up to 4 because this is not inclusive of 5, and then exit out.

7. Take a look at the Test Report; you can see that is exactly what happened. The command is executed multiple times and here we have our events, there are no response maps here so it is just saying no maps found but, so in our test case itself it will always show us our last iteration.

If I click the step, the variable has the value 4 — the Response view always shows the last executed iteration of a loop.

In the example, we combined looping with substitution. You were able to loop through a series of numbered interfaces by leveraging the loop counter variable (i in the example) in the executed step. A for loop is great for sequential looping or hop looping, where the increment value is something other than 1.

FOREACH LOOPS

To use a series of non-sequential integers or a series of strings as the basis of the looping logic than you will most likely use a foreach loop. The syntax of a foreach loop is different from that of a for loop (remember that iTest can insert the syntax for you). Let’s loop through the ping command using a foreach loop. Instead of adding the loop manually by inserting a step, we will instead use a shortcut: 1. Let’s insert another comment: “Check interfaces 0 1 3”

2. Add another step. Select the Router session and enter the command show ip int fast Ethernet 0.

3. Copy/paste the step and replace 0 with 2 and 3. 4. Execute the test case and you will notice that command executed for the interface 0, 1, and 3 5. Let’s indent the commands under the comment.

6. Remove the last two show commands — now we just have just one left 7. Right-click the command, select Wrap In, and then select foreach loop

The show step is automatically indented under the foreach loop, and the syntax of the foreach loop is inserted. 8. Let’s edit this just a little bit. Replace 1, 3, and 5 within curly braces to 0, 1, and 3. 9. Replace 0 in the show ip int FastEthernet command with $i.

This is a much faster method for adding looping logic to your test cases. We only selected one step, but you can also select multiple contiguous steps and accomplish the same result. The default looping variable is i and in this case the loop will iterate three times while setting the looping variable to first 0, then 1, and lastly 3. 10. Execute the test case

11. When execution is complete, expand the foreach loop step in the Test Report and you should see three entries of the show ip int FastEthernet step.

12. Close the Test Report view and return to the Test Case editor.

So that’s an example of a ‘foreach’, you don’t have to do it actually put the hardcoded list, you can put a variable that has a hardcoded list.

WHILE LOOPS

The last type of loop is called a while loop and a while that variable is set to a certain value execute the loop. If you want to continue looping through a series of steps until a certain condition is met than you will most likely use a while loop. Let’s add a while loop to the last show ip traffic command. The major difference to be aware of with a while loop is that the completion of the loop is deterministic, in this example based on the value of a variable. Though iTest inserts the syntax of the while loop for the user it is up to the user to properly manage the looping variable.

Now you should be careful with while loops. The problem is that if you do not enter it correctly then it becomes an infinite loop where it never breaks out of the loop and then your test cases will have to be

aborted. A few cases where you might want to use while loops are when you get a little more advanced and maybe need to sync up something. So for instance if you are running traffic, and you want the test case to do something when the traffic stops or you want the traffic to do something when it starts. Etc. then you could set up a variable to set when its stops and then set up a while loop to do something else while that is happening. It does have uses, but you have to know what you are going to do. So use caution. As an example, do the following:

1. Let’s insert another comment: “Check interfaces 0-3”

2. Then add another step and select session router and enter the command show ip int fast Ethernet 0. 3. Substitute 0 in show ip int FastEthernet command with $i

4. Indent the “show ip int FastEtherner$i underneath the comment 5. Select the show ip int FastEthernet$i command step. 6. Right-click to open the popup menu.

7. Select Wrap In > while loop from the context menu.

Notice that the step is indented under the loop and the syntax of the while loop is set. Additionally, iTest creates an eval step (an executive command for accessing the iTest interpreter) that sets the value of the looping variable. Also, the looping variable is incremented by another eval step that is indented under the while loop after all the steps that were selected to be wrapped.

8. This loop will exit after 5 iterations based on the default looping variable management added by iTest. So we can simply change it to <= 3.

9. Execute the test case. When execution is complete, expand the while loop step in the test report and you should see 3 entries of the show ip int FastEthernet command step as well as the eval step that increments the looping variable.

We have been using the wrap menu, but you can also add this manually. If I type in 4 I get for and foreach. iTest automatically puts in the example here and insert steps here. Typically, we use the wrap menu but adding the loop manually can result in the same loop. You can get the list of available actions in the drop down menu

IF-AND IF-THEN

Decision logic — if and if-then

Not all conditional logic is based on looping. The if statement is a type of conditional logic that makes decisions during test case execution. If statements can alter the execution flow of the test case, set variables based on responses, call procedures, monitor device activity, and so on. The majority of the time, an if loop will make decisions based on the results of analysis or the value of a particular variable. An if statement will evaluate to either true or false based on the input.

If isn’t a loop and it doesn’t repeat things, it makes decisions based on critical things that we give it.

Example:

What if the version we give it is 12.3 and if the response is not 12.3 then to the test case should not execute the show flash step and should execute a different command instead.

1. Highlight 12.3 in the response to the show version command. Store it in a variable: right click and select Quick Analysis Rule > Query against the structure response data > Store the extracted data in a variable Alternatively, you could use the Add Analysis Rule wizard

2. Select Store data from the response in a variable and click Next. 3. Be sure to select Regular expression 4. Name the variable version and then click Next and Finish. The version number will now be stored in a variable.

5. Right-click the show flash step, select Wrap, and then select if statement. 6. Notice now we have another statement if $i is less than 10 then run the show flash command, else insert a comment step where the expression evaluates to false.

Let's add the analysis that acts on the version in the response.

7. Change $i < 10 to $version == 12.3. Use the double equals notation. If the version is 12.3 then we will

execute the show flash step. Else we will use an eval step to output a message that says that the version is not 12.3. 8. Save the test case and execute. Now we should get the show flash step to execute because the statement is true. Check the report. You notice that it actually executed the show version command. 9. Change the equal statement to $version == 12.4. which we know is not true. And execute again and notice the massage in the test report.

You don’t have to have an else, let’s change the version back to $version == 12.3 and remove the else. So now this will simply execute if this is true or skip it all together if it is not.

ELSE IF

iTest also has an action called else if else if lets you create a hierarchal statement.

Note that the if, for and foreach statements become parents and the things before them become children. For example, if we deleted the if then statement, then the editor would also delete the show flash with it.

Another thing to note is that if you are going to do any kind of comparison, if you wanted to test 12.3, we recommend doing it in an analysis rule. That’s what analysis rules are meant to do.

The if then logic determines the branching in your test case, so in this example you are checking against the version only to determine whether or not to send the command. But I don’t really want to use this to test my device. You really want to use these to branch in your test case.

One of the things we will talk about in the advanced modules is that we can use analysis rules to do these tasks Instead of using an if then, you can actually use an analysis rule. If you think about an assertion, as we saw in the previous module, it really is an if then statement. You can attach analysis rules to comments.

Note: You do not actually have to associate analysis rules in a step that is going to a device. You can use analysis rules for branching. The advantage is that analysis rules execute faster because they do not have to be interpreted, whereas the Exec action statements do.

We will get to that later, for now just get comfortable with looping and logic and we will look at the different things that they can do. Lab

1. Get comfortable with adding/editing loops and if then else statements 2. Add a step to ping 71.131.155.238 if it exists in the ARP Table

• HINT: Use a contains Analysis Rule (store result in a variable)

• HINT: You can ping right from the router (syntax ping 71.313.155.238) or add steps to open up the Linux session