Software Testing
Table Of Contents
1 Introduction. 3
2 Basic Questions on Testing. 3
2.1 Why to test?. 3
2.2 What to test?. 3
2.3 How often to test?. 4
2.4 Who tests?. 4
3 Unit Testing. 4
4 Integration Testing. 5
5 System Testing. 5
5.1 Special Testing Methods. 5
6 Test Cases. 5
6.1 Unit Test Case (UTC) 6
6.2 Integration Test Case (ITC) 8
6.2.1 Internal Interface. 8
6.2.2 External Interface. 10
6.3 System Test Case (STC) 11
7 Test Execution and Fault Reports. 12
7.1 Test Case Distribution. 12
7.2 Test Environment Set-up. 12
7.3 Test Data Preparation. 12
7.4 Actual Test Execution. 13
7.5 Test Problem Report or Fault Report 13
8 Testing Tools. 15
8.1 Test Script Preparation. 15
9 WinRunner – an Introduction. 16
9.1 Recording Modes. 16
10 WinRunner Functions. 17
11 TSL Language elements. 17
11.1 TSL Example. 19
12 Database Connections. 21
13 Batch Testing and Debugging. 21
14 GUI Functions. 22
14.1 Button Object Functions. 23
14.2 Menu Object functions. 23
14.3 Static text object functions. 23
14.4 List Object Functions. 23
14.5 Scroll object functions. 24
14.6 Edit Object functions. 24
14.7 Window Object Functions. 25
15 Checkpoints. 25
1 Introduction
Computer software is meant to perform the tasks at high speed with high accuracy, that exceeds the human limitations. These programs are designed and developed by human beings and hence are prone to errors. Unchecked, they can lead to a lot of problems, including social implications. So, testing the software becomes an essential part of the software development lifecycle.
Testing, has to be practiced as an art. Carrying out the testing activities for projects has to be practiced with proper planning and must be implemented correctly
2 Basic Questions on Testing
2.1 Why to test?
The very basic question that arises in everyone’s mind about testing is “Why to test?”. Talking in terms of real life situations, we “check” any vegetables before we buy, we “check” the television before we buy and we “check” the car before we buy and so on. So, we check or inspect the article/object, before we start using that. This applies to software also and software is no exception to this.
To better understand the important of testing, let us take a typical banking application, which uses software. If the application is going to wrongly post the transaction, and the balance is not shown correctly, the bank will start losing its business. In a nuclear reactor, the control mechanism of nuclear explosion is taken care by a sophisticated software; and if that does not work properly, the reactor may act as a super atom bomb. Since the software can perform 100000 correct operations in one second, it has the same ability to perform 100000 wrong operations in one second, if not tested properly.
So, testing becomes absolutely essential to make sure that the software works properly and does the work that it is meant to perform.
2.2 What to test?
Any working product which forms part of the software application has to be tested. This includes any programs and the associated data. The program may be an exe file or a servlet or an active server page etc. The data also must be tested for accuracy. Data includes the database information and any stored procedures or triggers that act on the data.
Among the programs and data, the programs need more attention and must be tested rigorously. If the programs are tested right, there is a higher probability that the data will also be correct, but not necessarily.
2.3 How often to test?
Since the programs and data are tested, testing has to be performed, whenever they change. When a program (source code) is modified or newly developed, it has to be tested. Also, whenever the nature and volume of data changes, the application has to be tested.
As an analogy, when we buy a new television, we test it before taking it home. At the same time, in case of any repair work, we re-check or re-test the television unit, before we take it. This is applicable to software also.
2.4 Who tests?
When a programmer initially codes a program, he/she himself/herself tests it. This is similar to a student who writes an exam, checking the answers by self. This is to make sure that the piece developed by the programmer meets the expectations of the programmer. This is the first round of test, that the software piece undergoes.
After the programmer makes sure that the software piece works fine, there is a separate team that ensures that the software product works as per the requirements. It is typically the testing team that does this round of testing. This way, the software is observed by different pairs of eyes. This is similar to a teacher evaluating the answer papers of the student, for correctness.
Finally the software is tested by the customer/client/end-user. Because the software is going to be used ultimately by the client, in his/her place. This is similar to a person, buying a car, is actually doing a test drive of the car, before buying the car.
3 Unit Testing
In this, normally the basic input/output of the units along with their basic functionality will be tested.
Most of the times, the input units will be tested for the data types, data formats, valid values and boundary conditions. The outputs will be tested for their format, alignment, accuracy and the totals. The UTP will clearly give the rules of what data types are present in the system, their format and their boundary conditions. This list may not be exhaustive; but it is better to have a complete list of these details.
4 Integration Testing
In this the interfaces and the interprocess communications are tested mainly. This way the program units are ensured that they communicate to each other. Internal, external interfaces, with request and response are to be tested.
5 System Testing
Normally, the system testing is based on the requirements. All requirements are to be verified in the scope of system testing. This covers the functionality of the product. Apart from this the special testing are also part of this phase. The main purpose of this testing is to test the system, as though a user tests it and always the system itself is used to check the results of its inputs and logic.
5.1 Special Testing Methods
This covers the different special tests like load/volume testing, stress testing, interoperability testing etc. These testing are to be done based on the nature of the product and it is not mandatory that every one of these special tests must be performed for every product.
6 Test Cases
The individual testers are given the test plan document and the plan will be clearly explained by the lead tester and he will inform the testers about how the activities for that test level are to be carried out. The next process is that the individual testers are to come up with test cases. Depending upon the test level, the test cases will differ in their objectives.
The test cases will have a generic format as below.
Test Case Id
Test Case Description
Test Pre-requisite
Test Inputs
Test Steps
Expected Results
Actual Results
Pass/Fail
The test case id has to be unique across the application. There are several naming conventions about the test case ids, but we will stick on to the standard practice in our examples. The test case description must be very brief, may be 2 or 3 lines. The test pre-requisite clearly describes what should be present in the system, before the test can be executed. The test input is nothing but the test data, that is prepared to be fed to the system. The test steps are the step by step instructions on how to carry out the test. The expected results are the ones, that say what the system must give as output or how the system must react based on the test steps. The actual results and the pass/fail sections are initially blank and they will get filled only when the test is executed and the results are recorded.
The 2 big classifications in the test cases are the positive and negative test cases. Positive test cases are meant to prove that the system accepts valid inputs and then processes them correct. The negative test cases are meant to prove that the system rejects bad inputs and does not process them.
While writing the test cases, the testers must keep in mind that the test cases will be executed later by totally different testers. So, the test case details must be very clearly specified, so that a new person, can go thru the test cases step by step and is able to execute it.
The test cases will be explained with specific examples in the following sections.
6.1 Unit Test Case (UTC)
These are very specific to a particular program unit. The basic functionality of the unit are to be understood based on the requirements and the design documents. In most of the cases, the LLD will provide a lot of information about the functionality of a unit. The test case id normally starts with a prefix UT, then it is followed by the unit name and then a running sequence number. The following example will clearly explain how the UTC will look like.
The StuRegScr is the program unit that displays a screen and gets the students information and then after proper validation, it stores the details in the database.
Name
Date Of birth
Address
Phone Number
OK
Cancel
The LLD has to be referred before UTC is written, because it provides the actual functionality of how the system must behave, for given inputs. In the above, if the user enters valid values, let us assume that the LLD says, that the system must display a message saying that the student is registered and it will display the roll number of the student and the information is stored in STUDENTS database table. If any values are in error, then the system will display appropriate error message and will not store it in database. The test case will look like:
Test Case ID
UT_StuRegScr_001
Description
To test that the system rejects invalid month.
Test Prerequisite
The user should have access to register thru StuRegScr screen
Test Input
Name = “John”
DOB = “17/23/2000”
Address = “1235, Nick St, San Jose, CA-95014”
Phone = “408-713-2356”
Test Steps
Give the values to the fields in the screen as per test inputs.
Click OK
Expected results
The system must say “Month must be between 1 and 12. Check the values and resubmit”
Actual Results
Pass/Fail
The above was a negative test case. As a positive test case, we can give correct values and make sure that it gives proper results.
Test Case ID
UT_StuRegScr_002
Description
To test that the system accepts valid values and registers the student.
Test Prerequisite
The user should have access to register thru StuRegScr screen
Test Input
Name = “John”
DOB = “17/10/2000”
Address = “1235, Nick St, San Jose, CA-95014”
Phone = “408-713-2356”
Test Steps
Give the values to the fields in the screen as per test inputs.
Click OK
Expected results
The system must display a message “Thanks for registering. Your roll number is 4774”.
The information is stored in STUDENTS table with roll number equal to 4774.
Actual Results
Pass/Fail
In the test case described above, there are two pints verified; one is the screen message and the other is the database value that is being stored. There may be multiple such expected results for the same test case, because, it may be storing information on multiple tables.
6.2 Integration Test Case (ITC)
The main aim of integration test case is that it has to trigger the programs so that the program communicates to other program(s) via the APIs. The integration test plans will give the complete idea of how to write an integration test case, by triggering the interfaces. Unit testing may be relatively simple, because, it focuses only on the basic inputs of the unit and the elementary functionality. While writing the unit test cases, one need not think of what happens in the rest of the units. Whereas in the integration test cases, the tester must think of different ways of triggering APIs. For this, the tester must know the functionality of both the units which communicate to each other. This make integration test a little bit harder than the unit tests.
The test case format is exactly the same, but the content that goes in this varies. The following examples, show clearly how an integration test case will look like.
6.2.1 Internal Interface
This goes with the stock market application. In stock market, there will be investors, who go thru brokers to the exchange for trading. The broker will set the financial limits for the investors to control their trading activities, based on their financial stability and pay back capacity. Same way, the exchange will set limits for the brokers. The hierarchy looks like this.
Exchange
Broker 1
Broker 2
Broker 3
Investors Investors Investors
In a typical internet trading system, the individual investors send their orders via net. There is a central Order Collection and Management Server (OCMS) which receives the orders from the net. This is there on the broker’s office, in broker’s machine. There is a separate process or server, Risk Management Server (RMS), which checks whether the investor exceeds his financial limits when he trades. This establishes an internal interface between the servers.
OCMS
Internet
RmsS
RMS Database
As an example, let us assume that the customer’s limit is 4 lakhs rupees and he files 4 orders, with the order values being 1 lakh, 2 lakhs, 50,000 rupees and 1.5 lakhs. When the first 3 orders are received by OCMS, the total amount the investor has exhausted is 3.5 lakhs and RMS will allow the orders to get stored in the database and a reference number will be generated. When the 4th order comes in, the investor is exceeding the limits (3.5 lakhs + 1 lak = 4.5 lakhs, which is greater than 4 lakhs), the RMS will not allow to file that order and the system will reject the order and no reference number is generated. The RMS knows the limits for each investor from the database.
The screen in which, the investor enters the order, will look like this.
Buy/Sell
Stock Code
Quantity
Price
OK
Cancel
The integration test case will look like this.
Test Case ID
IT_OCMS/RMS_002
Description
To test that the RMS validates and passes the orders, when the limit is not exhausted by the customer.
Test Prerequisite
The user should have access to buy stocks and the user must be logged on. The investor limit must be 4 lakhs.
Test Input
Buy/Sell = Buy
Stock Code = SoftDan
Quantity = 100
Price = 7800.00
Test Steps
Give the values to the fields in the screen as per test inputs.
Click OK
Expected results
The system will display a message saying that “Your order is received. The reference number is 875200011”. The information is stored in the STOCK_BUY table with the same reference number.
Actual Results
Pass/Fail
When the user clicks OK, the order is received by OCMS and it communicates to the RMS to validate the investor limits. RMS validates and replies back to OCMS that the order is valid and within the limits and then OCMS stores the information in the database. The whole test case, triggers the interface between OCMS and RMS and hence the test case id says IT_OCMS/RMS_002.
6.2.2 External Interface
Brokers receive multiple orders from investors. When the stock exchange opens, all the successfully stored orders must be sent to the exchange and there the orders will get matched. So, from the broker’s application, there has to be a process or program that sends the orders to exchange. Exchange will have the limits for the brokers, which is the cumulative total for all the individual orders submitted by the investors. In order to send the orders from broker’s database to the exchange, there is an exchange adaptor (EA), which takes records from the broker’s office and communicates with the exchange servers. In this process, orders are going from one system to another system viz. broker to exchange. This is an external interface.
EA
Broker’s side Exchange side
The exchange opens is certain hours only and only during those hours, the trading happens. During the start of trading session, the EA starts reading the orders from broker’s database, and then it sends them to the exchange. In exchange also, there will be an OCMS to receive orders and then an RMS to check the limits of brokers. The following test case will describe the external interface testing i.e the integration of broker side process and exchange side process. (this does not check the limits and checks only whether the communication works between broker and exchange)
Test Case ID
IT_EA/XCHG_007
Description
To test that the orders are sent to exchange by the exchange adaptor.
Test Prerequisite
The exchange process must be up and running to receive the orders.
There must be valid orders stored in the broker’s database.
Test Input
Valid orders being present in the broker’s database. The status of orders = “NP” (Not Processed)
Test Steps
Start the exchange adaptor program thru administrator screen.
Expected results
The valid orders are sent to the exchange and at the end of the session, the status in the order database is updated as “SE” (Sent to Exchange) and each order having a valid 12 digit reference number, which are unique across the system.
Actual Results
Pass/Fail
6.3 System Test Case (STC)
The system test cases are meant to test the system as per the requirements, end-to-end. This is basically to make sure that the application works as per SRS. In the system test cases, (generally in system testing itself), the tester is supposed to act as an end-user and see whether the system works as per the expectation of the user. So, system test cases normally do concentrate on the functionality of the system, inputs are fed thru the system and each and every checks are performed using the system itself. Normally, the verifications done by checking the database tables directly or running programs manually are not encouraged in the system test.
The system test must focus on functional groups, rather than identifying the program units. When it comes to system testing, it is assumed that the interfaces between modules are working fine (integration testing passed).
Ideally the test cases are nothing but a union of the functionalities tested in the unit testing and the integration testing. Instead of testing the system’s input outputs thru databases or external programs, everything is tested thru the system itself. For example, in a typical banking application, the deposit, withdrawal and account balance screens (program units) would have been independently unit tested and the test results would be verified thru the database. In system testing, the tester will mimic as an end-user and hence checks the account balance before and after deposits or withdrawals, thus testing the output of the system, thru the application itself.
There are occasions, where some/many of the integration and unit test cases are repeated in system testing also. Especially when the units are tested with test stubs before and not actually tested with other real modules, during system testing those cases will be re-performed with real modules/data interacting to them.
The system testing focuses not only on testing the functionality against requirements, but also, some special tests like load/volume testing, stress testing etc. The number of users, the volume of data, the number of concurrent users etc are predicted over the forthcoming period, and such kind of environment is setup and then the application is tested in that environment. This ensures that the application will be capable of handling growing database and users, not only at the time of testing, and also on a future date.
Special tests are described in detail in the test types section.
7 Test Execution and Fault Reports
The test cases are prepared and collected and stored in a central location, from where all team members can read and share the test case details. These test cases are reviewed by team members and/or the lead tester and are approved by the lead tester. The next action item is to execute the test cases. The program unit(s) that are to be tested, using these test cases must be ready; otherwise we can not test.
In unit testing, as and when the units are coded completely, the testing starts. When the related units are coded and unit tested, then the integration test starts. When all units are unit tested and integration tested, then only the system test starts. Please remember the ETVX criteria for all test levels and phases.
7.1 Test Case Distribution
Before the test cases are executed, the lead tester will allocate the test cases to different individual testers, depending upon the test groups and availability of testers. Also, the lead tester will fix the target dates for executing the test cases, for individual testers. This comes under the work distribution and scheduling part of the lead tester.
7.2 Test Environment Set-up
Before any one can start testing, the test environment must be ready. It is always advised to use a separate test environment, which is different from the development environment. It may be a different machine altogether or a different set of drives/directories from which the test cases are executed. The entire set of program files, database objects etc are to be copied (or installed) in the test environment, before the test execution begins. The testing tools must also be installed.
By doing this kind of different setup for the testing, the integrity of the software components are ensured and at the same time, the programs and software are prevented from getting overwritten when developers fix some bugs and recompile.
7.3 Test Data Preparation
The test input section of the test cases, define what are the actual values that are to be fed to the application programs/screens. This data can be identified either at the time of writing the test case itself or just before executing the test cases. Data that are very much static can be identified while writing the test case itself (for example, name field or amount field in a banking deposit screen). Data which are dynamic and configurable need more analysis before preparation. For example, if a shop provides various percentage discounts to the articles being sold, depending upon the season, the data is not static and it changes for every season. To test such functionalities, multiple sets of data values are to be prepared. Again, the values may not be fixed, but they may be configurable.
So, just before executing the test cases, these kinds of data are to be prepared. Preparation of test data depends upon the functionality that is being tested.
7.4 Actual Test Execution
Once the data is ready, the tester’s job is to go thru the test pre-requisites and to make sure that they exist. For example, if the test case is to withdraw some money from the account, the user must have access rights to perform that operation and the account should have enough money to be withdrawn. The tester will have make these pre-requisites to exist before starting the test case. This may include, going into a separate screen and then feeding data or going to the database and then populating it manually etc.
The next job is to go thru the test steps one by one and then actually performing the steps on the software product. This involves feeding the values to the program as per the test inputs and then performing the other actions (like clicking specific buttons or function keys etc) in the sequence as given in the test steps. When the inputs are fed, the system is supposed to react (to give outputs in terms of screen displays, update databases etc.) according to the design. Whatever happens after the actions are performed on the system, the tester will have to record the results in the actual results section of the test case.
Ideally, the expected results and the actual results must match, if the program is correctly designed and coded. When they match, the test case is treated as passed. If any one part of the expected and actual results are not matching, then it is treated as failed. The testing achieves its goal by identifying such failures in the software.
After the actual results are recorded and the pass/fail criteria is determined by the individual testers, the test case sheets are reviewed (mostly by peers and the lead tester) and it is ensured that the pass/fail criteria is correctly determined. Sometimes, because of inexperience, testers may think a failure as a pass and vice versa. But the lead tester must ultimately approve the pass or fail criteria on a test case.
7.5 Test Problem Report or Fault Report
When a particular test case fails, it is verified by the lead tester and a Test Problem Report (TPR) will be generated. This is the evidence that the testing is carried out and a problem has been identified. This TPR serves as the correspondence between the testing team and the development team, in terms of tracking the problem. The TPR will contain the following information.
TPR Id
A unique identifier across the company
TPR Description
A brief description of the problem
Date
The date on which the TPR is raised
Author
The tester who raised the TPR
Test Case Id
The test case that caused this TPR to be raised
Software version
The version number of the software that was tested and found faulty
Problem severity
High/medium/Low. This will be agreed by the lead tester and the development project manager
Problem description
A description of what was tested and what happened. This will be filled by the tester.
Problem resolution
After fixing the problem, the developer fills this section, with details about the fix.
Assigned to
To whom the TPR is assigned to be fixed
Expected closure date
When the problem to be closed
Actual closure date
When the problem is actually rectified and closed
TPR status
This is a changing field to reflect the status of the TPR.
When the TPR is initially raised, it will be in Open status. The tester will then send it to the lead tester. The severity and expected closure dates will be finalized by the lead tester. When a particular developer is assigned to fix the problem, the status changes to Assigned. When the developer acknowledges that, the status changes to WIP (Work in Progress). When the developer fixes the problem, the status must be changed to Fixed. It will go thru the testing cycle again. When the re-unit testing is being done, the status will be In-UT. When re-unit testing is finished, the status will become UT-Complete. Same way for integration testing and system testing stages, the status will be In-IT, IT-Complete, In-St and ST-Complete respectively. It depends upon when the TPR is raised. When that particular stage is reached (e.g. integration test), when the problem does not appear again, the tester will change the status as Retest-Complete. Then the lead tester will verify that and change the status to Closed.
If the problem is not fixed or some other problem is introduced again, the TPR will go thru the above cycle, until the problem is completely fixed and the expected and actual results match.
Test Executed
TPR raised or re-raised
TPR tracked
Retested
TPR closed Problem reappears
In the industry, many companies use an automated Problem Reporting System or Bug Tracking System, thru which we can track the TPRs and close them.
When the problem reappears in re-testing, the same TPR is tracked again and in the problem description section, multiple paragraphs will be added with dates of execution. In the same way, the problem resolution section will also be updated accordingly with fix details and the dates.
Some TPRs are specially termed as release stoppers. If those TPRs are not fixed, the product can not be released to the customers. In some situation, the developers may not be able to reproduce the problem. If the developers are not able to reproduce the problem at all, then they may close the TPR with a special status as “Irreproducible”.
8 Testing Tools
Testing applications manually is inevitable. But when test cases are to be repeated again and again, as part of the regression testing, it is impossible to repeat them manually every now and then. It takes a lot of time and needs more manpower. To avoid this, the testing tools are developed and they can mimic the data entry to screens and the mouse clicks on the buttons. By doing so, they can actually do the test, as though some user is doing the test. This way, the tests can be stored in special files and can be re-run any number of times. The other advantage is that, even if the tester who developed the test is not available, but the automated test is available, it is as good as having the tester there.
During stress testing, if we want to generate requests from 2000 users, we can not have 2000 testers to do that. Instead, the tools are now capable of generating concurrent requests as though there are so many number of users. So, testing tools have now got a dominant role in automating the test cases.
8.1 Test Script Preparation
The testing tools have their own language in which the tests are stored. They invariably use, capture-playback mechanism to generate automated test scripts. In this, the user first does the test, by giving the test inputs thru the right screen or program, with the recorded in the testing tool on. This records every letters typed and every mouse clicks, with details like, on which window, on which control field the action happens. Once the test is over, we can stop recording. Then the tool automatically generates a special source code, which is called test script, which is a programming language that the tool can identify. If we want to do the test again, it is enough if we execute the test script using the test tool and it will replay whatever action that was performed during recording.
Some tools have really good object oriented programming for the test scripts. It is easy and English-like to write code in the language. For example, to do some operations on a window, it may read like,
StudentRegistrationScreen.NameBox.Fill(“John”);
StudentRegistrationScreen.OKButton.Click();
It is very clear what the operations are performed, right by seeing the scripting language. We can write the code in the test scripts, and then execute them directly, which is no different from capture and playback. Sample tools are SilkTest, Rational SQA Robot, WinRunner etc.
9 WinRunner – an Introduction
WinRunner is a functional regression testing tool developed by Mercury Interactive Inc. It has all the features of the testing tools and the test script is called TSL (Test Script Language) and it is very easy as it is English like. The following sections will describe the essential features of WinRunner with references to TSL.
This document does not cover each and every statement and function available in WinRunner, but gives a generic idea on the tool. For reference, please go thru the WinRunner Tutorial (wr_tut.pdf) and the user guide (wr_ug.pdf).
9.1 Recording Modes
WinRunner has 2 recording modes which are analog and context sensitive. In analog mode, the mouse movements are physically tracked and the coordinates thru which it moves are recorded. When played back, the tool retraces the same paths taken by the mouse while recording. This is a very crude method of recording as any resizing or repositioning of windows will make the recorded script to fail.
The other mode of recording is context sensitive mode, where each GUI element is identified as an object and wherever they are, the tool locates them. The tool uses Object Oriented definition of these GUI objects in terms of classes and these classes are to be “learnt” by the tool before they are accessed. This is not affected by resizing or repositioning of windows and even the controls.
10 WinRunner Functions
WinRunner supports 4 types of functions; analog, context sensitive, standard and custom functions. Analog functions are hardly used in current day scenario. Context sensitive functions are the ones which act on the GUI controls. Standard functions are the mathematical, string, file, array and other functions. Custom functions are the functions defined by the user.
11 TSL Language elements
TSL (Test Script Language) is a full fledged programming language, which provides variables, arithmetic and string operations, arrays, file operations, decision and looping structures, and database connects. Using TSL is inevitable in order to create test cases. The TSL can be used in a typical interpreted mode or compiled mode.
TSL, in general, follows the syntax of C language.
Comments are given by starting the line with a pound sign.
# This is a comment.
Variables are automatically declared, implicitly, if they are not explicitly declared. The qualifiers for the variables to define their scope are auto, static, public and extern. The first 2 have local scopes and the rest have global scope. There is no type specifications like string or numeric etc. It is automatically decided by the system, depending upon the values loaded. Usually all variable names are typed in lowercase letters.
Constants are declared by explicitly saying “const”. All constant names are typed in uppercase letters.
The control characters are defined with a backslash.
\b backspace
\r carriage return
\f form feed
\t tab
\v vertical tab
\n end of line
Normally any hardcoded backslash is to be represented by two backslashes as “\\”.
Arithmetic operations are denoted by the symbols +, -, *, /. Exponentiation is denoted by both ^ and **. Modulus is denoted by %. ++ and -- are also used as increment and decrement operators.
String concatenation is denoted by & sign. String constants are embedded within double quotes. Substr, length are the most used functions on string operations.
Relational operators are <, <=, >, >=, ==, !=.
Logical operators to denote AND, OR and NOT are &&, and !.
Assignments are denoted by =, +=, -=, *=, /=.
Statement delimiter is semicolon.
Group of statements under the same scope are embedded within curly braces. { }.
TSL supports if conditions, while loops, do-while loops, for loops and switch-case statements, exactly with the syntax of C language. The break and continue statements have the same meaning as in C.
Arrays are also declared in the same way as in C, with the subscripts placed within square brackets. []. Elements can be deleted from the arrays, and the array elements can be searched using “in” statement.
Functions can be declared with the keyword “function”. Parameters fall under 3 types, in, out and inout. Return statements are also available as in C to return values.
File operations are available by use of file_open, file_close, file_getline, file_printf commands. These are only for flat files which are sequential files. Read, write and append modes are supported.
When tests span across more than one test script file or when test scripts are called from a batch file, “call” statements are used. These call statements can be used along with the parameters for the tests. There is another command “call_close” which calls another test within a test and closes the called test when it completes and the control comes back to caller. “treturn” and “texit” are used to exit out of the called tests. “call” is commonly used. The parameters for the test are defined thru the Test Properties option of the File menu.
Load and unload commands are used to load and unload compiled modules to memory.
Load_GUI is used to load the GUI declarations which are created via the GUI Map Editor into memory. Unless this is performed for the tests, the tests may not understand the GUI controls.
To get inputs interactively from a test script, we can create dialog boxes and lists from TSL, using create_input_dialog and create_list_dialog.
11.1TSL Example
The following example gives a complete picture of the usage of commonly used statements in TSL.
# numeric assignment
i = 100;
print ("i =", i);
# arithmetic
print ("i + 10 = ", i + 10);
print ("i - 10 = ", i - 10);
print ("i * 10 = ", i * 10);
print ("i / 10 = ", i / 10);
print ("i % 10 = ", i % 10);
# string assignment
str1 = "hello";
str2 = "world";
print (str1 & str2); # concatenation
print ("length = ", length(str1));
# for loop
for (i = 0; i < 10; i++)
{ print (i);
}
# while loop
i = 1;
while (i <= 10)
{ print (i);
i++;
}
# do while loop
i = 10;
do
{ print (i);
i--;
} while (i > 0);
# interactive inputs
inp_string = create_input_dialog("Give your name");
print (inp_string);
# if statement
if (inp_string == "Nagarajan")
print ("You are the man! ");
# switch statement
switch (inp_string)
{ case "John" : print ("Hello John! how r u?"); break;
case "Frank" : print ("Hello Frank! how r u?"); break;
case "Nehru" : print ("Hello Nehru! how r u?"); break;
case "Gandhi" : print ("Hello Gandhi! how r u?"); break;
default : print ("hello stranger! get out!"); break;
}
inp_string = to_caps(inp_string);
print ("Converted to uppercase ", inp_string);
# interactive list
create_list_dialog("MyList", "Select an item", "Green, Amber, Red");
# file operations - 0 in read mode, 1 in write mode, 2 in append mode
file_open("c:\wr.txt", 0);
while (file_getline("C:\wr.txt",line) == 0)
{ print (line);
}
file_close("C:\wr.txt");
public week_days[] = {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"};
for (i = 0; i < 7; i++) print (week_days[i]);
# function declaration
public function to_caps(in istr)
{ return (toupper(istr));
}
12 Database Connections
From WinRunner we can connect to database and do queries, count rows and verify the results. First we need to connect to the database, then execute a query. Based on the query execution we can get the rows one by one or the column headers etc. Finally we need to close the connection.
First we need to define an ODBC connection to connect to the database.
Example
Db_connect(“con1”, “DSN=MyTest”);
Db_execute_query(“con1”, “select * from employee”, number_of_records);
Print (“Total number of rows returned = “, number_of_records”);
Db_get_headers(“Con1”, number_of_fields, headers); # gets a tab separated list
Print (“The columns fetched are : “, headers);
For (I=0; I < number_of_records; I++)
{ db_get_row(“con1”, I, row_content); # this returns a tab separated list
print(row_content);
}
db_disconnect(“con1”);
13 Batch Testing and Debugging
Since WinRunner uses the modular approach in creating individual test scripts, batching of a test is nothing but creating a caller script, that calls tests from it. To run it, we need to specify “Run in batch mode” in the generic options of the tool.
Example
Call “c:\\testdir\\ABC_DepScreen_001” ();
Call “c:\\testdir\\ABC_DepScreen_002” ();
Call “c:\\testdir\\ABC_DepScreen_003” ();
Call “c:\\testdir\\ABC_DepScreen_004” ();
WinRunner can be run from command line mode also, but this is not at all used in current day scenario.
When we run the tests, we can either run the tests or debug the tests in debug mode. In debug mode we can step over a line or step inside a function. We can set breakpoints and we can have watch lists to have variables being monitored. All these options are available from Run menu.
14 GUI Functions
In general, every GUI application has got the following items in it.
Windows
Push buttons
Radio buttons
Check boxes
Edit boxes
Horizontal scroll bars
Vertical scroll bars
Menu bars
Menu items
List boxes
Combo boxes
Bitmaps
As a first step, we may have to open the application. This is achieved thru “invoke_application” command. In this we need to give the path of the program file to be executed, working directory, runtime parameters and a specifier that says whether the application must be started as maximized or minimized etc.
For all the controls that are mentioned above, we need to first create the GUI map of the objects. WinRunner understands everything as an object and WinRunner has predefined classes for all types of GUI controls. This is achieved by running the GUI Map editor from Tools option. Using this we can learn every window control and then store the GUI map in a file and in the test scripts, this GUI map has to be loaded using GUI_load command.
Every one of these controls have 2 types of commands: set properties and get properties. What we want to act on a control is set property i.e. selecting an item from a list box or clicking on a push button. To know what is the state/value of a control is get property; i.e. the state of a checkbox whether ON or OFF or to know what value is typed in a text box.
Using these properties we can feed the inputs to these controls and we can find what is the result that comes out of the actions.
The following sections describe only commonly used GUI functions of WinRunner. For exact syntax, please refer to the TSL reference manual.
To activate a window and set the window into focus, win_activate and set_window commands are used.
To click the mouse the commands are click and dbl_click.
14.1Button Object Functions
Button_check_info Checks the value of a button property.
Button_check_state Checks the state of a radio or check button.
Button_get_info Returns the value of a button property.
Button_get_state Returns the state of a radio or check button.
Button_press Clicks a push button.
Button_set Sets the state of a radio or check button.
14.2Menu Object functions
Menu_get_info Returns the value of a menu property.
Menu_get_item Returns the contents of an item.
Menu_get_item_num Returns the position of an item.
Menu_select_item Selects an item.
14.3Static text object functions
Static_check_info Checks the value of a static text object property.
Static_check_text Checks the contents of a static text object.
Static_get_info Returns the value of a static text property.
Static_get_text Returns the contents of a static text object.
14.4List Object Functions
List_check_info Checks the value of a list property.
List_check_item Checks the content of an item in a list.
List_check_selected Checks that the specified item is selected.
List_get_checked_items Returns the value of items marked as checked.
List_get_info Returns the value of a list property.
List_get_item Returns the contents of an item.
List_get_item_info Returns the state of a list item.
List_get_item_num Returns the position of an item.
List_get_selected Returns the currently selected item.
List_get_subitem Returns the value of the ListView subitem.
List_select_item Selects an item in a list.
List_select_multi_items Selects items in a multiple-selection container object.
List_select_range Selects all items between two specified items.
14.5Scroll object functions
Scroll_check_info Checks the value of a scroll property.
Scroll_check_pos Checks the current position of a scroll.
Scroll_get_info Returns the value of a scroll property.
Scroll_get_max Returns the value of a scroll at its maximum (end) position.
Scroll_get_min Returns the value of the scroll at its minimum (start) position.
Scroll_get_selected Returns the minimum and maximum values of the selected range on a slider.
Scroll_get_pos Returns the current scroll position.
Scroll_line Scrolls the specified number of lines.
Scroll_max Sets a scroll to the maximum (end) position.
Scroll_min Sets a scroll to the minimum (start) position.
Scroll_page Moves a scroll the specified number of pages.
14.6Edit Object functions
Edit_check_info Checks the value of an edit object property.
Edit_check_selection Checks that a string is selected.
Edit_check_text Checks the contents of an edit object.
Edit_delete Deletes the contents of an edit object.
Edit_delete_block Deletes a text block from an edit object.
Edit_get_block Returns a block of text from an edit object.
Edit_get_info Returns the value of an edit object property.
Edit_get_row_length Returns the length of a row in an edit object.
Edit_get_rows count Returns the number of rows written in an edit object.
Edit_get_selection Returns the selected string in an edit object.
Edit_get_selection_pos Returns the position at which the selected block starts and ends.
Edit_get_text Returns the text in an edit object.
Edit_insert Inserts text in an edit object.
Edit_insert_block Inserts text in a multi-line edit object.
Edit_replace Replaces part of the contents of an edit object.
Edit_replace_block Replaces a block of text in a multi-line edit object.
Edit_set Replaces the entire contents of an edit object.
Edit_set_insert_pos Places the cursor at the specified point in an edit object.
Edit_set_selection Selects text in an edit object.
Edit_type Types a string in an edit object.
14.7Window Object Functions
Set_window Specifies the window to receive input, according to the window's logical name.
Win_activate Activates a window.
Win_check_info Checks the requested window property.
Win_click_help Clicks the help button in a window title bar.
Win_close Closes a window.
Win_drag Drags an object from a source window.
Win_drop Drops an object on a target window.
Win_exists Checks whether a window is displayed.
Win_get_info Returns the value of a window property.
Win_get_text Reads text from a window.
Win_highlight Highlights a window.
Win_max Maximizes a window.
Win_min Minimizes a window to an icon.
Win_mouse_click Clicks in a window.
Win_mouse_dbl_click Double-clicks in a window.
Win_move Moves a window to a new absolute location.
Win_open Opens a window.
Win_resize Resizes a window.
Win_restore Restores a window from a minimized or maximized state to its previous size.
Win_type Sends keyboard input to a window.
15 Checkpoints
The most commonly used bitmap checkpoint is the context sensitive function. It compares a window bitmap to an expected bitmap.
win_check_bitmap takes the window and a comparison bitmap. This compares the appearance of the window. To check the objects with bitmaps, we use obj_check_bitmap.
We can check any object with checkpoints. obj_check_gui compares current GUI object data to expected data. Same way for windows, we use win_check_gui command.
Checkpoints may be added thru Create menu options.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment