Software Testing

Context sensitive mode

A] Recording test in analog and context sensitive mode

B] Choosing a Record Mode

By recording, you can quickly create automated test scripts. You work with your application as usual, clicking objects with the mouse and entering keyboard input. WinRunner records your operations and generates statements in TSL, Mercury Interactive’s Test Script Language. These statements appear as a script in a WinRunner test window. Before you begin recording a test, you should plan the main stages of the test and select the appropriate record mode. Two record modes are available: Context Sensitive and Analog.

Context Sensitive mode records your operations in terms of the GUI objects in your application. WinRunner identifies each object you click (such as a window, menu, list, or button), and the type of operation you perform (such as press, enable, move, or select).For example, if you record a mouse click on the OK button in the Flight Reservation Login window, WinRunner records the following TSL statement in your test script: button_press (“OK”);

When you run the script, WinRunner reads the command, looks for the OK button, and presses it.

In Analog mode, WinRunner records the exact coordinates traveled by the mouse, as well as mouse clicks and keyboard input. For example, if you click the OK button in the Login window, WinRunner records statements that look like this:

When this statement is recorded… ………. it really means:

move_locator_track (1); mouse track

mtype (““)

; left mouse button press

mtype (“+”); left mouse button release

When you run the test, WinRunner retraces the recorded movements using absolute screen coordinates. If your application is located in a different position on the desktop, or the user interface has changed, WinRunner is not able to execute the test correctly. In this exercise you will create a script that tests the process of opening an order in the Flight Reservation application. You will create the script by recording in

Context Sensitive mode.

If WinRunner is not already open, choose Programs > WinRunner > WinRunner on the Start menu.

If the Welcome window is open, click the New Test button. Otherwise, choose File > New. A new test window opens in WinRunner.

Choose Programs > WinRunner > Sample Applications > Flight 1A on the Start menu. In the Login window, type your name and the password mercury, and click OK. The name you type must be at least four characters long.Position the Flight Reservation application and WinRunner so that they are both clearly visible on your desktop

4. Start recording in Context Sensitive mode.

In WinRunner, choose Create > Record—Context Sensitive or click the Record button on the toolbar. From this point on, WinRunner records all mouse clicks and keyboard input. Note that the text, “Rec” appears in blue above the recording button. This indicates that you are recording in Context Sensitive mode. The status bar also informs you of your current recording mode.

In the Flight Reservation application, choose File > Open Order. In the Open Order dialog box, select the Order No. check box. Type 3 in the adjacent box, and click OK.Watch how WinRunner generates a test script in the test window as you work.

In WinRunner, choose Create > Stop Recording or click the Stop button on the  toolbar.

box.Note that WinRunner saves the lesson3 test in the file system as a folder, and not as an individual file. This folder contains the test script and the results that are generated when you run the test.

Output: WinRunner Test Results window is open and displays the test results.

Recording in ContextSensitive mode is cleared and test results are also seen.

 

•         Looking at the internal structure of a program and deriving test cases based on the logic or control flow.

•         Test cases can be designed to reach every branch in the code and to exercise each condition

•         Typically done during unit testing

•         Also known as:

–        Structural Testing

–        Glass-Box Testing

•         Looking at the program from an external point of view and deriving test cases based on the specification.

•         The only criteria upon which the program is judged is if it produces the correct output for a given input.

Directly measures the number of linearly independent paths through a program’s source code, taking into account the various decision points

     1.   E-N+2

            Where

E – Number of Eges

            N – Number of Nodes

     2. # regions + 1

What is Software Testing?

Manual testing

Test

• An activity in which a system or component is executed under specified conditions, the result are observed or recorded, and an evaluation is made of some aspect of the system or component.

Test Case

• A set of test inputs, execution conditions, and expected results developed for a particular objective

• The smallest entity that is always executed as unit, from beginning to end

• A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly

• Test case may also include prerequisites

Test Case Components

• The structure of test cases is one of the things that stays remarkably the same regardless of the technology being tested. The conditions to be tested may differ greatly from one technology to the next, but you still need to know three basic things about what you plan to test:

• ID #: This is a unique identifier for the test case. The identifier does not imply a sequential order of test execution in most cases. The test case ID can also be intelligent. For example, the test case ID of ORD001 could indicate a test case for the ordering process on the first web page.

• Condition: This is an event that should produce an observable result. For example, in an e-commerce application, if the user selects an overnight shipping option, the correct charge should be added to the total of the transaction. A test designer would want to test all shipping options, with each option giving a different amount added to the transaction total.

• Procedure: This is the process a tester needs to perform to invoke the condition and observe the results. A test case procedure should be limited to the steps needed to perform a single test case.

• Expected Result: This is the observable result from invoking a test condition. If you can’t observe a result, you can’t determine if a test passes or fails. In the previous example of an e-commerce shipping option, the expected results would be specifically defined according to the type of shipping the user selects.

• Pass/Fail: This is where the tester indicates the outcome of the test case. For the purpose of space, I typically use the same column to indicate both “pass” (P) and “fail” (F). In some situations, such as the regulated environment, simply indicating pass or fail is not enough information about the outcome of a test case to provide adequate documentation. For this reason, some people choose to also add a column for “Observed Results.”

• Defect Number Cross-reference: If you identify a defect in the execution of a test case, this component of the test case gives you a way to link the test case to a specific defect report.

Specifying Testing Requirements

Defining Requirements

To define a requirement:

1 Open the TestDirector_Demo project.

2 Display the Requirements module.

3 Display the requirement tree in Document View.

4 Create a new requirement.

Click the New Requirement button on the Requirements module toolbar. Alternatively, choose Requirements > New Requirement. The New Requirement dialog box opens.

In the Name box, type Cruise Reservation.

5 Add a sub-requirement.

6 Add an additional sub-requirement.

 

Viewing Requirements

To view requirements:

1 Display the Requirements module.

2 Zoom in and out of the requirement.

Click the Zoom In button on the toolbar. Alternatively, right-click the requirement and choose Zoom In. The requirements tree only displays the Cruise Reservation requirement, including its two sub-requirements.

 

3 Display numeration in the requirements tree.

 

4 Refresh the data in the Requirements module.

5 Expand and collapse the requirements.

19

Modifying Requirements

To modify requirements:

1 Display the Requirements module.

2 Copy a requirement.

3 Rename the Cruise Reservation_Copy_ requirement.

4 Move the Hotel Reservation requirement to a different location in the requirements tree.

To paste the Hotel Reservation requirement underneath the selected requirement, click the Paste arrow and choose Paste as Child.

5 Delete the Hotel Reservation requirement.

Converting Requirements

To convert a requirement:

1 Display the Requirements module.

2 Select a requirement.

3 Open the Convert to Tests wizard.

 

4 Choose an automatic conversion method.

5 Start the conversion process.

 

Select Cruise Booking, and click the Test button.

7 Choose the destination subject path.

 

 

8 Finalize the conversion process.

9 View the converted requirements in the test plan tree.