Presentation is loading. Please wait.

Presentation is loading. Please wait.

CHAPTER 9 - PART 2 Software Testing Strategies. Lesson Outlines ■ White box testing – Data processing and calculation correctness tests – Correctness.

Similar presentations


Presentation on theme: "CHAPTER 9 - PART 2 Software Testing Strategies. Lesson Outlines ■ White box testing – Data processing and calculation correctness tests – Correctness."— Presentation transcript:

1 CHAPTER 9 - PART 2 Software Testing Strategies

2 Lesson Outlines ■ White box testing – Data processing and calculation correctness tests – Correctness tests and path coverage – Correctness tests and line coverage – McCabe’s cyclomatic complexity metrics – Software qualification and reusability testing – Advantages and disadvantages of white box testing

3 Classification According to Testing Concept Two main philosophies of testing: –One deals with internal structure of the software –The other deals with produced outputs given inputs. –IMHO, you definitely need both because they test the software from two entirely different perspectives!

4 Definitions Black Box (Functionality) testing: Identifies bugs only according to software malfunctioning as they are revealed in its erroneous outputs. –If outputs okay, BB Testing disregards internal paths taken, calculations and any processing. –This is somewhat of an oversimplification, but it is still essentially true.

5 Definitions White Box (Structural) testing: Examines internal paths program execution follows in order to identify bugs. –Often called ‘glass box testing’. –Investigates the correctness of the code structure. –Checks out the application in considerable detail – but with a cost.

6 White Box and Black Box Testing for classes of tests Black Box testing : * We will look at these. –* Output correctness tests –* Documentation tests –* Availability (reaction time) tests –* Reliability tests –* Stress tests (load tests and durability tests) –* Software system security tests –Training usability tests –Operational usability tests –Flexibility tests –Testability tests –Portability tests –Software interoperability tests –Equipment interoperability tests

7 White Box and Black Box Testing for classes of tests White Box Testing : –* Data processing and calculations correctness tests –* Software qualification tests –* Reusability tests Both white box and black box testing: –* Maintainability tests

8 White Box Testing - Overview White box testing requires verification of every program statement / comment in your code –Can be very long and painstaking ( دقيق ) ! Calculation Correctness Test Cases are developed to test each computation and the path to the computation. –Used to determine the proper path sequence of steps that compute. Software Qualification Checks out compliance and standards. Maintainability checks out internal structure for maintenance Reusability tests the reuse ability in a local software library.

9 White Box Testing: In more Detail: Data Processing and Calculation Correctness ■Path coverage Path coverage is measured as percentage of all possible program paths included in planned testing. ■Line coverage Line coverage is measured by the percentage of program code lines included in planned testing.

10 Correctness Tests and Path Coverage Note: every path (if-then-else; do-while, etc.) is a ‘different’ path with different values. We’d like to tests all paths. Total number of paths is countably infinite. If one calculates the number of paths in a non-trivial routine, the number of test cases required is huge and very impractical ( غير عملي ). Except for some special security applications, we will use alternative strategies: line coverage.

11 Correctness Tests and Line Coverage Desirable to test every line of code at least once during testing. Define degree of coverage as the number of lines executed over the number of executable lines available. Let’s consider a program flow chart to make our point. –a diamond is a decision; –a rectangle consists of imperatives and connections to conditional statements. –Edges represent sequences of sections Let’s consider a program flow graph, with sections of code to replace one or more flow chart rectangles.

12 Imperial Taxi Service Computations ■ 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: 0 change; each additional suitcase: $1. 5. Night supplement: 25%, effective for journeys between 9pm - 6am. ■ Regular clients are entitled to a 10% discount and are not charged the night supplement.

13 S ≤ 1S >1 Yes WT ≤ 3 WT > 3 D ≤ 1000 1 Charge the minimal fare 2 Distance 5 Waiting time 14 Night journey? 11 Regular client? 3 6 4 12 13 16 15 17 Print receipt. 8 No.of suitcases 910 D > 1000 7 No Yes Taxi Service - Flow chart - Path Coverage In planning, a flowchart and a flow graph were developed. Note: five decisions enter into planning for path testing… Twenty-four different paths may be executed to have full coverage. Means we need to prepare 24 different test cases.

14 3 6 9 12 5 2 1 8 11 15 4 17 7 16 10 13 14 Program flow graph But, if we only insist on ‘line coverage,’ we can get full line coverage with three tests: 1 2 3 5 6 8 9 11 12 17 1 2 4 5 7 8 10 11 13 14 15 17 1 2 4 5 7 8 10 11 13 14 16 17 So, we have three test cases compared with 24! Savings goes up exponentially with programs of greater complexity.

15 Program Flow Graph McCabe’s cyclomatic complexity metrics also give an upper limit to the number of test cases needed for full line coverage. McCabe used graph theory to arrive at a minimum number of tests to ensure full line coverage based on a program flow graph. Any path must have at least one edge not in another path. McCabe developed his cyclomatic complexity based on ‘regions’ in the graph. 3 6 9 12 5 2 1 8 11 15 4 7 16 10 13 14 R1 R2 R3 R5 R4

16 3 6 9 12 5 2 1 8 11 15 4 17 7 16 10 13 14 R1 R2 R3 R5 R4 R6 for full line coverage According to McCabe, the V(G) can be computed in any of three ways each of which is based on the program’s flow graph: V(G) = R // nbr of regions V(G) = E – N + 2 edges – nodes (21-17 + 2 = 6) V(G) = P + 1 (nbr of decisions + 1) (5 + 1 = 6) Result: max nbr of independent paths Number of paths has been used to indicate overall program complexity McCabe – Maximum Number of Independent Paths for Full Line Coverage.

17

18 Advantages of White Box Testing ■Direct determination of software correctness as expressed in the processing paths statement by statement, including algorithms. Were they correctly defined and coded?? Logic errors?? Must carefully design test cases!! ■Allows performance of line coverage follow up. We have software that identifies lines not yet executed are available. percent execute, phantom paths… ■Ascertains quality of coding work and its adherence to coding standards.

19 Disadvantages of White Box Testing ■The vast resources utilized, much more those required for black box testing of the same software package. ■The inability to test software performance in terms of availability (response time), reliability, load durability, etc. ■Book cites that white box testing should be limited to modules of high risk and high cost of failure – whatever that means! ■After programs have been maintained over the years, these general testing strategies are too simplistic.


Download ppt "CHAPTER 9 - PART 2 Software Testing Strategies. Lesson Outlines ■ White box testing – Data processing and calculation correctness tests – Correctness."

Similar presentations


Ads by Google