 |
 |
 |
|
 |
|||
| SQA14 - Generation of Test Cases |
LQS14 - Prüffälle generieren
1 Allocation to V-Model and Methods Allocation
V-Model
QA2.3 - Definition of Test Cases
Method
BBTD - Black Box Test Case Design
WBTD - White Box Test Case Design
2 Brief Characteristics
This service unit defines the requirements for tools used for the generation and administration of test cases.
3 Requirements
3.1 Requirements for Interfaces
| SQA14.I.1 | Granularity | The exchange of control parameters with SWFM01 - Workflow Management is possible for individual closed function packages of the tool by means of a disclosed, documented interface. |
| SQA14.I.2 | Input interface to SSD02 - Supporting Specification of User Interfaces | It is possible to analyze specifications for interfaces generated with SSD02 without further transformation from the object management in order to generate test cases. |
| SQA14.I.3 | Input interfaces to SSD04 - Supporting Process Modeling | It is possible to analyze process models generated with SSD04 without further transformation from the object management in order to generate test cases. |
| SQA14.I.4 | Input interface to SSD06 - Supporting Function Specification | It is possible to analyze specifications for functions generated with SSD06 without further transformation from the object management in order to generate test cases. |
| SQA14.I.5 | Input interfaces to SSD07 - Supporting Modeling of Information Flows | It is possible to analyze information flow diagrams generated with SSD07 without further transformation from the object management in order to generate test cases. |
| SQA14.I.6 | Input interface to SSD08 - Supporting Modeling of Function Dynamics | It is possible to analyze sequence models generated with SSD08 without further transformation from the object management in order to generate test cases. |
| SQA14.I.7 | Input interface to SSD10 - Supporting Component and Module Specification | It is possible to analyze specifications for Components and Modules generated with SSD10 without further transformation from the object management in order to generate test cases. |
| SQA14.I.8 | Input interface to SSD11 - Supporting Database Specification | It is possible to analyze logical schema specifications for Databases generated with SSD11 without further transformation from the object management in order to generate test cases. |
| SQA14.I.9 | Input interface to SSD12 - Generating Components and Modules | It is possible to analyze source code for Components and Module generated with SSD12 without further transformation from the object management in order to generate test cases. |
3.2 Requirements for the Methods Support
| SQA14.M.1 | BBTD - Black Box Test Case Design | |
| SQA14.M.1.1 | Valid input data | |
| SQA14.M.1.1.1 | Normal values from control information |
It is possible to generate normal values for valid input data from control information. Control information of the process models are events, conditions, states, signals, and chronological sequences of events, conditions, states and signals. Control information of data flow diagrams are data flow triggers. Control information for the sequence models are events, conditions and chronological sequences of events and conditions. |
| SQA14.M.1.1.2 | Marginal values from control information |
It is possible to generate marginal values for valid input data from control information. The term marginal values refers to boundary and extreme values. |
| SQA14.M.1.1.3 | Normal values from data declarations |
It is possible to generate normal values for valid input data from data declarations. In this connection, data types and value ranges of the data elements from the data declarations will be analyzed. |
| SQA14.M.1.1.4 | Marginal values from data declarations |
It is possible to generate marginal values for valid input data from data declarations. The term marginal values refers to boundary and extreme values. |
| SQA14.M.1.2 | Formally invalid input data | |
| SQA14.M.1.2.1 | Control information |
It is possible to generate formally invalid input data from control information. Formally invalid data must be recognized and processed by the object to be assessed by means of plausibility checks. |
| SQA14.M.1.2.2 | Data declarations |
It is possible to generate formally invalid input data from data declarations. Formally invalid data must be recognized and processed by the object to be assessed by means of plausibility checks. |
| SQA14.M.1.3 | Technically invalid input data | (In this connection, the term "technically" has to be interpreted with regard to the user-level requirements.) |
| SQA14.M.1.3.1 | Normal values from control information |
It is possible to generate normal values for technically invalid input data from control information. Technically invalid normal values must be detected and processed by the object to be assessed by means of plausibility checks. |
| SQA14.M.1.3.2 | Marginal values from control information |
It is possible to generate marginal values for technically invalid input data from control information. The term "marginal values" refers to boundary and extreme values. Technically invalid marginal values must be detected and processed by the object to be assessed by means of plausibility checks. |
| SQA14.M.1.3.3 | Normal values from data declarations |
It is possible to generate normal values for technically invalid input data from data declarations. Technically invalid normal values must be detected and processed by the object to be assessed by means of plausibility checks. |
| SQA14.M.1.3.4 | Marginal values from data declarations |
It is possible to generate marginal values for technically invalid input data from data declarations. The term marginal values refers to boundary and extreme values. Technically invalid marginal values must be detected and processed by the object to be assessed by means of plausibility checks. |
| SQA14.M.1.4 | Intuitive test case definition | It is possible to manually add test cases intuitively generated by the assessor to the generated test cases. |
| SQA14.M.1.5 | Test case combinations | |
| SQA14.M.1.5.1 | Valid input data | It is possible to generate combinations of valid input data. |
| SQA14.M.1.5.2 | Invalid input data | It is possible to generate combinations of invalid input data. |
| SQA14.M.1.5.3 | Valid and invalid input data | It is possible to generate combinations of valid and invalid input data. |
| SQA14.M.1.6 | Expected output data | It is possible to enter the expected output data or reactions for the input data. |
| SQA14.M.1.7 | Assessment data |
It is possible to generate data for assessment files or assessment databases from the logical schema specifications for databases and data structures. In this connection, data types and value ranges of the data elements from the logical schema specifications for databases and data structures will be analyzed. |
| SQA14.M.2 | WBTD - White Box Test Case Design | |
| SQA14.M.2.1 | Path coverage | It is possible to define input data in order to get a requested minimum number of paths executed in the object to be assessed at least once. |
| SQA14.M.2.2 | Statement coverage | It is possible to define input data in order to get a requested minimum number of statements executed in the object to be assessed at least once. |
| SQA14.M.2.3 | Branch coverage | It is possible to define input data in order to get a requested minimum number of branches executed in the object to be assessed at least once. |
| SQA14.M.2.4 | Condition coverage | It is possible to define input data in order to get a requested minimum number of conditions executed in the object to be assessed at least once. |
| SQA14.M.2.5 | Branch/condition coverage | It is possible to define input data in order to get a requested minimum number of branches and conditions executed in the object to be assessed at least once. |
| SQA14.M.2.6 | Coverage of all multiple conditions | It is possible to define input data in order to get a requested minimum number of all possible combinations of the conditions of a decision executed in the object to be assessed at least once. |
| SQA14.M.2.7 | Expected output data | It is possible to manually enter the expected output data for the input data. |
3.3 Requirements for Functions
| SQA14.F.1 | Administration of test cases | |
| SQA14.F.1.1 | Command file |
It is possible to store test cases in a command file. A test case comprises the input data and the expected output data. |
| SQA14.F.1.2 | Additions to the command file | |
| SQA14.F.1.2.1 | Addition of test cases | It is possible to add further test cases to a command file, beginning at a definable position. |
| SQA14.F.1.2.2 | Addition of comments | It is possible to add comments with explanations about test cases to a command file. |
| SQA14.F.1.2.3 | Utilization of the comments | It is possible to maintain the comments in a command file in such a manner that they can be superimposed as explanations for test cases during the test run. |
| SQA14.F.1.3 | Combination of command files | It is possible to combine command files for test runs. |
| SQA14.F.2 | Recording of test cases | |
| SQA14.F.2.1 | Key strokes | It is possible to log key strokes. |
| SQA14.F.2.2 | Mouse movements | It is possible to log mouse movements. |
| SQA14.F.2.3 | Pressing the mouse button | It is possible to log clicks of the different mouse buttons. |
3.4 Other Requirements
| SQA14.O.1 | Procedural command language | The tool has a procedural command language that can be applied by the user to generate and run macros or procedures. |
| SQA14.O.2 | Complexity | There is no limitation of the complexity caused by the tool itself. |
|
|
|
GDPA Online
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster
|