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

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 TEST_CREATION_API and 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

Function runTest Go to top

Every python test script should implement the runTest() main function. Test execution of every test script is started by calling this function. In this section, we will describe how this function is typically structured,

def runTest():
        ## Set initial result of test execution
	test_result = "FALSE"
        ## Initialise devices for the test (example of grabber device)
        ## Continue with test if DUT is properly initialized
        ## 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"
    ## Update test result

    ## Return DUT to initial state and de-initialize grabber device

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.