Anatomy of a test script
This section investigates all important parts of a typical Python test script used on the BBT platform.
Introduction Go to top
In this section, we will explain the structure of a typical BBT Python test script based on a test case. Test case is a set of conditions or variables on which tester determines whether an application, software system or one of its features is working as expected. Test case can be Manual, Semi-automatic or Automatic. Automatic test cases are represented by test scripts.
Python is often used as a scripting language or script language. It is a programming language that supports scripts, programs written for a special run-time environment that can interpret (rather than compile) and automate the execution of tasks that could alternatively be executed one-by-one by a human operator.
Each python test script is preceded by the test case description, equipment, preconditions, steps and expected results. Test script is usually a sequence of commands which must be carried out in order to test the correct behavior of some functionality of a system.
Main elements of every python test script are divided into following parts:
- Header which contains information about the test case
- Imports of main librairies and constants used in the test script
- Main function runTest()
Script header Go to top
Header contains the name of the script, test case and test case description.
## @package name_of_test_script # The test case description. # # test_name = name_of_test_case # ID = Unique test case identifier # copyright = 2014 RT-RK. All rights reserved.
Information about test name (test_name) and ID (path) is optional and is given mostly in case if we want to relate it to the external test management system.
Imports and constants Go to top
Functions that are used in test scripts are parts of different Python libraries. At the beginning of each test script, those libraries are included in the script using the
import function. Constants, if required, should be declared after import block. Typical import of an Python test script would be the following:
import time import TEST_CREATION_API import CUSTOMER_TC_API
One of standard Python libraries used in tests is the
time library. Typical function of this library used in tests is
time.sleep(DURATION), which pauses test execution for specified
DURATION. Two BBT specific libraries appearing in our example are
CUSTOMER_TC_API. See the Testing APIs section for details.
TEST_CREATION_API library contains general BBT framework functions for:
- Device control
- Log output
- Storing results
CUSTOMER_TC_API library contais project specific functionalities, which are typicaly related to the DUT control.
After imports, typical test script usually contains definitions of constants used in script. Constants are usually named using all capital letters. The code snippet below demonstrates initialization of two constants used in script.
## Time in seconds required to switch to next channel MAX_SWITCH_TIME = 2 DURATION = 4000
Function runTest Go to top
def runTest(): try: ## Set initial result of test execution test_result = "FALSE"
## Initialise devices for the test (example of grabber device) TEST_CREATION_API.initialize_grabber()
## Continue with test if DUT is properly initialized CUSTOMER_TC_API.check_initial_DUT_state()
## Check the test result (one example is a comparison of reference and grabbed pictures) if (TEST_CREATION_API.compare_pictures("reference_picture", "grabbed_picture", "[REGION]")): ## set the test result test_result = "PASS"
## Catch exception if something was wrong except Exception as error: test_result = "INCONCLUSIVE" TEST_CREATION_API.write_log_to_file(error)
## Update test result TEST_CREATION_API.update_test_result(test_result) ## Return DUT to initial state and de-initialize grabber device CUSTOMER_TC_API.deinitialize()
Detailed description of runTest() main function and it’s content follows:
- It is a good practice to place the body of the runTest function into the try/except block in order to handle exceptions and errors. When a Python script raises an exception it should be handled internally, otherwise the script would terminate and come out from execution without providing explanation of failure reason for later analysis. If exception is handled by script, it is possible to store exception information directly into the database by calling the TEST_CREATION_API.write_log_to_file().
The first step of execution is setting the initial test result. In the example above, the initial value is set to FALSE.
After setting the initial result, the next step is to initialize the devices used in the test (e.g. DUT and grabber device). If all devices are initialized properly, test execution can continue forward, otherwise exiting the test is the next step.
In case when an exception is raised, test result is set to INCONCLUSIVE which means that the test is not completely executed due to device or command error.
If there is no error and all test steps have been executed successfully, the test result is being checked. If method or algorithm (used for result checking) gives positive result (condition is met), initial test result is set (changed) to the value of PASS.
At the end of every test script , DUT and grabber device should be returned to it’s default initial state by calling functions for deinitialisation of DUT and grabber device.
Codding Rules and Consistency Go to top
One of the important things is consistency in writing scripts code. By following coding guide rules and accepted internal coding style, we can achive readability, reusability and best consistency of scripts, which also means that occurrence of errors is reduced to minimum. To learn more about coding rules refer to page Best practices.