Testplan Element/en: Unterschied zwischen den Versionen
Cg (Diskussion | Beiträge) |
Cg (Diskussion | Beiträge) |
||
Zeile 14: | Zeile 14: | ||
So the execution of the remaining test plan can be both aborted or continued even if an individual test case fails. |
So the execution of the remaining test plan can be both aborted or continued even if an individual test case fails. |
||
Test cases for which followup tests make no sense should be marked as required (for example, if the initial connection setup to the SUT fails or an initial login fails). |
Test cases for which followup tests make no sense should be marked as required (for example, if the initial connection setup to the SUT fails or an initial login fails). |
||
All attributes and behavior are described in detail in the "[[Testplan Editor-TestplanListView Editor/en|testplan editor documentation]]. |
|||
[[Category:Tree Elements]] |
[[Category:Tree Elements]] |
Version vom 17. Oktober 2016, 15:40 Uhr
A testplan element is used to organize and execute individual test cases. It is a collection of references to either blocks or other test plans, to be processed as nested sub sequences of a superordinate test plan. Test case items within a test plan are executed sequentially, however, because each test case is implemented by an action block, parallel operations can be and are usually implemented on the block level. It is also possible, to execute multiple testplans in parallel or to place a comple testplan inside an action block.
Test plans are created, modified and executed in the testplan editor.
For execution, individual test cases can be skipped or selectively re-executed. Also, it is possible to execute a test plan in a loop for a fixed or variable number of runs or until a particular condition arrises. For example, it is possible to execute a test plan in a loop until a FAIL condition arises.
Furthermore items can be assigned to a test group, or given individual priorities/risk levels and executed conditionally (eg. to run smoke tests vs. full tests).
Also, test cases can be flagged as being either required or optional. If a required test case fails, the whole test plan execution is abandoned, whereas the failure of an optional test case is only remembered and the remaining tests are still executed. So the execution of the remaining test plan can be both aborted or continued even if an individual test case fails. Test cases for which followup tests make no sense should be marked as required (for example, if the initial connection setup to the SUT fails or an initial login fails).
All attributes and behavior are described in detail in the "testplan editor documentation.