Software Testing Part 3.pptx or black box tsting
- 1. Software testing White box testing
- 2. White box (structural) testing White box testing concept requires verification of every program statement and comment White box testing includes: Software qualification tests Reusability tests Maintainability tests Data processing and calculations correctness tests
- 3. Software Qualification Tests To quickly review, software that qualifies is coded and documented according to standards, procedures and work instructions. It facilitates the followings: The team leader to check the software The replacement programmer to comprehend the code and continue coding tasks The maintenance programmer to correct bugs and/or update or change the program upon request
- 4. Software Qualification Tests It answers the following questions: Does the code fulfil the code structure instructions and procedures, such as module size, application of reused code, etc.? Does the coding style fulfil coding style procedures? Do the internal program documentation and “help” sections fulfil coding style procedures? Specialized software packages (called code auditors) can now perform a portion of the qualification tests
- 5. Reusability Test Software reusability substantially reduces project resources requirements It improves the quality of new software systems Reusability shortens the development period Reusability testing is used to determine whether the packaging and documentation of the programs and modules to be reused conform to the standards and procedures demanded for inclusion in the reusable software library.
- 6. Data processing and calculation correctness tests In order to perform data processing and calculation correctness tests (“white box correctness test”), every computational operation in the sequence of operations created by each test case (“path”) must be examined This type of verification allows us to decide whether the processing operations and their sequences were programmed correctly for the path in question Raises the question of coverage of a vast number of possible processing paths and the multitudes of lines of code.
- 7. Data processing and calculation correctness tests Two alternative approaches have emerged: “Path Coverage” – to plan our test to cover all the possible paths, where coverage is measured by percentage of paths covered. “Line/Statement Coverage” – to plan our tests to cover all the program code lines, where coverage is measured by percentage of lines covered.
- 8. Correctness tests and path coverage Different paths in a software module are created by the choice in conditional statements, such as IF–THEN–ELSE or DO WHILE.. Path testing is motivated by the aspiration to achieve complete coverage of a program by testing all its possible paths. Path test’s completeness is defined as the percentage of the program paths executed during the test. It is impractical in most of the cases because of the vast resources required for its performance
- 9. Correctness tests and path coverage Example: Let us calculate the number of possible paths created by a module containing 10 conditional statements, each allowing for only two options (e.g., IF–THEN–ELSE and DO WHILE). This simple module contains 1024 different paths To obtain full path coverage for this module (probably 25–50 lines of code) one should prepare at least 1024 test cases This indicates the impracticality of wide use of path testing Its application is directed mainly to high risk software modules, where the costs of failure resulting from software error fully warrant the costs of path testing
- 10. Correctness tests and line coverage Weaker coverage concept as compared to path coverage The line coverage concept requires far fewer test cases but, as expected, leaves most of the possible paths untested Every line of code be executed at least once during the process of testing. The line coverage metrics for completeness of a line-testing (“basic path testing”) plan are defined as the percentage of lines indeed executed – that is, covered – during the tests.
- 11. Correctness tests and line coverage Flow chart and a program flow graph can be helpful In a flow chart, diamonds present the options covered by conditional statements (decisions) Rectangles represent the software sections connecting those conditional statements.
- 12. Correctness tests and line coverage In program flow graphs, nodes represent software sections and thus replace one or more flow chart rectangles. The edges indicate the sequence of software sections. Nodes having two or more leaving edges represent conditional statements
- 13. Example – the Imperial Taxi Services (ITS) taximeter Imperial Taxi Services (ITS) serves one-time passengers and regular clients (identified by a taxi card). The ITS taxi fares for one-time passengers are calculated as follows: 1. Minimal fare: $2. This fare covers the distance traveled up to 1000 yards and waiting time (stopping for traffic lights or traffic jams, etc.) of up to 3 minutes. 2. For every additional 250 yards or part of it: 25 cents. 3. For every additional 2 minutes of stopping or waiting or part thereof: 20 cents. 4. One suitcase: no charge; each additional suitcase: $1. 5. Night supplement: 25%, effective for journeys between 21.00 and 06.00. Regular clients are entitled to a 10% discount and are not charged the night supplement.
- 14. Example – the Imperial Taxi Services (ITS) taximeter When planning the basic path testing plan of the new taximeter module Prepare a flow chart and a program flow graph for the taxi fare calculation process Figure represents a calculation process that includes five decisions Full path coverage requires that all the possible paths be executed at least once
- 15. ITS flow chart
- 16. ITS :Program flow graph of the module
- 18. Line Coverage of ITS flow graph The program flow graph allows us to observe that full line coverage of the ITS software module can be reached by inspecting the minimum number of paths – a total of three
- 19. Line Coverage of ITS flow graph The proportion of test cases required to test the system by full line coverage of three test cases versus full path coverage of 24 test cases is 1:8! This ratio grows rapidly with program complexity.
- 20. McCabe’s cyclomatic complexity metrics Cyclomatic complexity is a software metric (measurement). It is used to indicate the complexity of a program. It directly measures the number of linearly independent paths through a program's source code. Independent Path: Any path on the program flow graph that includes at least one edge that is not included in any of the former independent paths Cyclomatic complexity is computed using the control flow graph of the program Cyclomatic complexity may also be applied to individual functions, modules, methods or classes within a program. Called Basis Path Testing by McCabe who first proposed it
- 22. McCabe’s cyclomatic complexity metrics If the source code contained no decision points such as IF statements or FOR loops, the complexity would be 1. Since there is only a single path through the code. If the code had a single IF statement containing a single condition there would be two paths through the code, one path where the IF statement is evaluated as TRUE and one path where the IF statement is evaluated as FALSE.
- 23. McCabe’s cyclomatic complexity metrics The cyclomatic complexity metric (V(G)) is expressed in three different ways, all of which are based on the program flow graph (1) V(G) = ER + 1 (2) V(G) = E – N + 2 (3) V(G) = P + 1 Compute the Cyclomatic complexity of ITS flow graph and identify the maximum number of independent paths
- 24. Formula: V(G) = E – N + 2 E = 21, N = 17 V(G) = E – N + 2 = 21 – 17 + 2 = 6
- 25. Decision Coverage With Decision coverage the possible outcomes of each condition and of the decision are tested at least once. In other words we cover that all conditions are one time TRUE and one time FALSE and we cover one time the THEN and one time the ELSE.
- 26. Brach Coverage and Multiple Condition Coverage Branch Coverage: This guarantees that, during testing, every decision point (branch) in the program is evaluated as true or false at least once. Multiple condition testing: It involves testing both simple and complicated condition combinations inside decision points.