Software Testing Tools Question:
Comparing SilkTest and WinRunner Part 1
Answer:
• SilkTest derives its initial startup configuration settings from its partner.ini file. This though is not important because SilkTest can be reconfigured at any point in the session by either changing any setting in the Options menu or loading an Option Set. An Option Set file (*.opt) permits customized configuration settings to be established for each test project. The project specific Option Set is then be loaded [either interactively, or under program control] prior to the execution of the project’s testcases. The Options menu or an Option Set can also be used to load an include file (*.inc) containing the project’s GUI Declarations [discussed in section 2.6 on page 5], along with any number of other include files containing library functions, methods, and variables shared by all testcases.
• WinRunner derives its initial startup configuration from a wrun.ini file of settings. During startup the user is normally polled [this can be disabled] for the type of addins they want to use during the session [refer to section 2.3 on page 3 for more information about addins]. The default wrun.ini file is used when starting WinRunner directly, while project specific initializations can be established by creating desktop shortcuts which reference a project specific wrun.ini file. The use of customized wrun.ini files is important because once WinRunner is started with a selected set of addins you must terminate WinRunner and restart it to use a different set of addins. The startup implementation supports the notion of a startup test which can be executed during WinRunner initialization. This allows project-specific compiled modules [memory resident libraries] and GUI Maps [discussed in section 2.6 on page 5] to be loaded. The functions and variables contained in these modules can then be used by all tests that are run during that WinRunner session.
Both tools allow most of the configuration setup established in these files to be over-ridden with runtime code in library functions or the test scripts.
Test Termination
• SilkTest tests terminate on exceptions which are not explicitly trapped in the testcase. For example if a window fails to appear during the setup phase of testing [i.e. the phase driving the application to a verification point], a test would terminate on the first object or window timeout exception that is thrown after the errant window fails to appear.
• WinRunner tests run to termination [in unattended Batch mode] unless an explicit action is taken to terminate the test early. Therefore tests which ignore this termination model will continue running for long periods of time after a fatal error is encountered. For example if a window fails to appear during the setup phase of testing, subsequent context sensitive statements [i.e. clicking on a button, performing a menu pick, etc.] will fail—but this failure occurs after a multi-second object/window “is not present” timeout expires for each missing window and object. [When executing tests in non-Batch mode, that is in Debug, Verify, or Update modes, WinRunner normally presents an interactive dialog box when implicit errors such as missing objects and windows are encountered].
• WinRunner derives its initial startup configuration from a wrun.ini file of settings. During startup the user is normally polled [this can be disabled] for the type of addins they want to use during the session [refer to section 2.3 on page 3 for more information about addins]. The default wrun.ini file is used when starting WinRunner directly, while project specific initializations can be established by creating desktop shortcuts which reference a project specific wrun.ini file. The use of customized wrun.ini files is important because once WinRunner is started with a selected set of addins you must terminate WinRunner and restart it to use a different set of addins. The startup implementation supports the notion of a startup test which can be executed during WinRunner initialization. This allows project-specific compiled modules [memory resident libraries] and GUI Maps [discussed in section 2.6 on page 5] to be loaded. The functions and variables contained in these modules can then be used by all tests that are run during that WinRunner session.
Both tools allow most of the configuration setup established in these files to be over-ridden with runtime code in library functions or the test scripts.
Test Termination
• SilkTest tests terminate on exceptions which are not explicitly trapped in the testcase. For example if a window fails to appear during the setup phase of testing [i.e. the phase driving the application to a verification point], a test would terminate on the first object or window timeout exception that is thrown after the errant window fails to appear.
• WinRunner tests run to termination [in unattended Batch mode] unless an explicit action is taken to terminate the test early. Therefore tests which ignore this termination model will continue running for long periods of time after a fatal error is encountered. For example if a window fails to appear during the setup phase of testing, subsequent context sensitive statements [i.e. clicking on a button, performing a menu pick, etc.] will fail—but this failure occurs after a multi-second object/window “is not present” timeout expires for each missing window and object. [When executing tests in non-Batch mode, that is in Debug, Verify, or Update modes, WinRunner normally presents an interactive dialog box when implicit errors such as missing objects and windows are encountered].
| Previous Question | Next Question |
| Software Test Automation Tool Evaluation Criteria Part 2 | Comparing SilkTest and WinRunner Part 2 |