Lec4_white_black

Views:
 
     
 

Presentation Description

software Quality Assurance

Comments

Presentation Transcript

Slide1:

Chapter 4 Software Testing-Strategies

Slide2:

Objective: Explain testing objectives. Discuss the differences between the various testing strategies, their advantages and disadvantages. Describe the concepts of black box testing and white box testing, as well as discuss their advantages and disadvantages. Define path coverage vs. line coverage. Describe various types of black box tests.

Definition:

Definition According to Myers’ classic definition: “Testing is the process of executing a program with intention of finding errors.”

Definition:

Definition Two definitions for testing suggested by IEEE Std 610.12 (IEEE, 1990) are as below: “(1)The process of operating a system, or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component. (2) The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features of the software item.”

Objectives of Testing:

Objectives of Testing Direct objectives InDirect objectives To identify and reveal as many errors To bring the tested software to an acceptable quality level To perform the required testing in an efficient and effective way, within budget and schedule To supply records of software errors to be used for error prevention ( indirect objective)

2 Basic Testing strategies:

2 Basic Testing strategies Big bang testing Test the software as a whole, once the complete package is available Incremental testing Software module are tested as they are completed ( unit tests) Then integration testing is followed Once the entire package is completed, do system test. Is performed according to 2 basic strategies: bottom-up and top-down

Incremental testing :

Incremental testing Top-down Bottom –up Unit/module

Incremental testing: Bottom-up :

Incremental testing: Bottom-up M11 M10 M4 M3 M9 M5 M8 M2 M1 M7 M6 Integration A Integration B Integration C Stage 4 Stage 3 Stage 2 Stage 1

Incremental testing: Bottom-up :

Incremental testing: Bottom-up Stage 1 : Unit tests of modules 1 to 7. Stage 2 : Integration test A of modules 1 and 2, developed and tested in Stage 1, and integrated with module 8, developed in the current stage. Stage 3 : Two separate integration tests, B, on modules 3,4,5 and 8, integrated with module 9, and C, for modules 6 and 7, integrated with module 10. Stage 4 : System test is performed after B and C have been integrated with module 11, developed in the current stage.

Incremental testing: Top-down :

Incremental testing: Top-down M11 M10 M4 M3 M9 M5 M8 M2 M1 M7 M6 Integration A I-B I-C I-D I-E Stage 1 Stage 2 Stage 3 Stage 4 Stage 5 Stage 6

Incremental testing: Top-down :

Incremental testing: Top-down Stage 1 : Unit tests of modules 11. Stage 2 : Integration test A of modules 11 integrated with modules 9 and 10, developed in the current stage. Stage 3 : Integration test B of A integrated with module 8, developed in the current stage. Stage 4 : Integration test C of B integrated with modules 6 and 7, developed in the current stage. Stage 5 : Integration test D of C integrated with modules 1 and 2, developed in the current stage. Stage 6 : System test of D integrated with modules 3,4 and 5, developed in the current stage.

Incremental testing: Stubs and drivers:

Incremental testing: Stubs and drivers Stubs and drivers are software replacement simulators required for modules not available when performing a unit or an integration test. A stub (often termed a “dummy module”) replaces an unavailable lower level module, subordinate to the module tested. Stubs are required for top-down testing of incomplete systems. Like a stub, a driver is a substitute module, but of the upper level module that activates the module tested. The driver is passing the test data on to the tested module, and accepting the results calculated by it.

Incremental testing: Stubs and drivers - example:

Incremental testing: Stubs and drivers - example Top-down Driver of M9 M8 M9 M2 M1 M8 Bottom –up Stub of M2 Stub of M1

While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers. Stubs and drivers used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing. For EX : If we have Modules x,y,z . X module is ready and Need to Test it , But i calls functions from y and z.(Which is not ready)To test at a particular module we write a Small Dummy piece a code which Simulates Y and Z Whch will return values for X, These pice of Dummy code is Called Stubs in a Top Down Integration So Stubs are called Functions in Top Down Integration. Similar to the above ex: If we have Y and Z modules get ready and x module is not ready, and we need to test y and z modules Which return values from X,So to get the values from X We write a Small Pice of Dummy code for x which returns values for Y and Z,So these piece of code is called Drivers in Botton Up Integration So Drivers are calling Functions in Bottom Up Inegration. :

While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers. Stubs and drivers used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing. For EX : If we have Modules x,y,z . X module is ready and Need to Test it , But i calls functions from y and z.(Which is not ready)To test at a particular module we write a Small Dummy piece a code which Simulates Y and Z Whch will return values for X, These pice of Dummy code is Called Stubs in a Top Down Integration So Stubs are called Functions in Top Down Integration. Similar to the above ex: If we have Y and Z modules get ready and x module is not ready, and we need to test y and z modules Which return values from X,So to get the values from X We write a Small Pice of Dummy code for x which returns values for Y and Z,So these piece of code is called Drivers in Botton Up Integration So Drivers are calling Functions in Bottom Up Inegration .

Big-bang vs. incremental testing:

Big-bang vs. incremental testing Big -bang Error identification is difficult Less effective Correction is hard Resources and schedule - fuzzy Incremental Error identification is higher More effective Correction is faster- within unit Resources and schedule - more planned

Bottom-up vs. top-down:

Bottom-up vs. top-down Bottom-up Lateness at which the program as a whole can be observed Ease of performance Top-down Difficulty of its performance Demonstrate the entire program functions shortly after activation of the upper-level modules has been completed.

Slide17:

White box testing

Definition:

Definition As defined by IEEE (1990), a White box (structural) testing is: “Testing that takes into account the internal mechanism of a system or component .”

Data Processing and calculation correctness tests :

Data Processing and calculation correctness tests Path coverage = to plan our test to cover all the possible paths, where coverage is measured by % of paths covered. Line coverage = to plan our tests to cover all the program code lines, where coverage is measured by % of lines covered.

Correctness tests and path coverage :

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 or DO UNTIL. Path testing is motivated by the aspiration to achieve complete coverage of a program by testing all its possible paths. Is impractical in most cases due to the vast resources required for its performance.

Correctness tests and line coverage :

Correctness tests and line coverage For full line coverage, every line of code is executed at least once during the process of testing.

White box testing: Path coverage -Example:

White box testing: Path coverage -Example 1 7 6 5 4 2 3 8 Different paths in a software module are created by the choice in conditional statements, such as IF-THEN-ELSE, or DO WHILE, or DO UNTIL. E.g. minimum number of paths: 1-2-3-5-6-8 1-2-4-5-7-8 Full coverage of the path include: 1-2-3-5-7-8 1-2-4-5-6-8

Slide23:

Example 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: n0 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. The Imperial Taxi Services (ITS) taximeter

Slide24:

S ≤ 1 S >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 9 10 D > 1000 7 No No Yes ITS - Flow chart

Slide25:

3 6 9 12 5 2 1 8 11 15 4 17 7 16 10 13 14 R1 R2 R3 R5 R4 R6 ITS - Program flow graph

Slide26:

3 6 9 12 5 2 1 8 11 15 4 17 7 16 10 13 14 R1 R2 R3 R5 R4 R6 ITS - The minimum number of paths for full line coverage

Slide27:

3 6 9 12 5 2 1 8 11 15 4 17 7 16 10 13 14 R1 R2 R3 R5 R4 R6 V(G)=R=6 V(G)=E-N+2=21-17+2=6 V(G)=P+1=5+1=6 R=Regions N=Nodes E=Edges P=Decisions McCabe’s cyclomatic complexity metrics ITS - The maximum set of independent paths

Slide28:

McCabe’s cyclomatic complexity metrics Measures the complexity of a program or module at the same time as it determines the maximum number of independent paths needed to achieve full line coverage of the program. Based on graph theory and calculated according to the program characteristics as captured by its program flow graph. An independent path is defined with reference to the succession of independent paths accumulated, that is: “Any path on the program flow graph that includes at least one edge that is not included in any of the former independent paths”.

Slide29:

Examines the internal paths of calculations in order to identify bugs. Enables performance of data processing and calculations correctness tests, software qualification tests, maintainability tests and reusability tests. Allows direct checking – paths and algorithms Provides line coverage follow-up – LOC that not yet been checked Testing quality of coding Disadvantages: Requires vast resources Cannot test the performance of software in terms of availability, reliability, stress etc. White box: Advantages & disadvantages

Black Box Testing:

Black Box Testing As defined by IEEE (1990), a Black box (functionality) testing is: “(1)Testing that ignores the internal mechanism of a system, or component, and focuses solely on the outputs generated in response to selected inputs and execution conditions. (2) Testing conducted to evaluate the compliance of a system, or component with specified functional requirements.”

Slide31:

A black box method aimed at increasing the efficiency of testing and, at the same time, improving coverage of potential error conditions. Equivalence class partitioning (EC)

Slide32:

A n equivalence class (EC) is a set of input variable values that produce the same output results or that are processed identically. E C boundaries are defined by a single numeric or alphabetic value, a group of numeric or alphabetic values, a range of values, and so on. A n EC that contains only valid states is defined as a "valid EC," whereas an EC that contains only invalid states is defined as the "invalid EC." I n cases where a program's input is provided by several variables, valid and invalid ECs should be defined for each variable. Equivalence class partitioning (EC)

Slide33:

According to the equivalence class partitioning method: E ach valid EC and each invalid EC are included in at least one test case. D efinition of test cases is done separately for the valid and invalid ECs. I n defining a test case for the valid ECs, we try to cover as many as possible “new” ECs in that same test case. I n defining invalid ECs, we must assign one test case to each “new” invalid EC, as a test case that includes more than one invalid EC may not allow the tester to distinguish between the program’s separate reactions to each of the invalid ECs. T est cases are added as long as there are uncovered ECs. Equivalence class partitioning (EC)

Slide34:

Entrance ticket price table - The Pool

Slide35:

Test cases - The ticket price module

Black box: Advantages & disadvantages:

Identifies bugs only according to malfunctioning of the software as revealed from its outputs. Disregards the internal paths of calculation performed by the software. Allows the tester to carry out almost all test classes For test classes that can be carried out by both white and black testing, black testing required less resources Lacks control of line coverage Lacks possibilities to test the quality of coding work Less error detection Black box: Advantages & disadvantages

Operation Factor Testing Classes Revision Factor Testing Classes Transition Factor Testing Classes:

Operation Factor Testing Classes Revision Factor Testing Classes Transition Factor Testing Classes

Operation Factor Testing Classes -Documentation Tests:

Operation Factor Testing Classes - Documentation Tests Common Components of documentation, supplied by the developer, are: Functional descriptions of the software system Installation manual User manual Programmer manual Document testing plans should include the following three components: Document completeness check Document correctness tests Document style and editing inspection

Operation Factor Testing Classes - Availability Tests:

Operation Factor Testing Classes - Availability Tests Defined as reaction time-the time needed to obtain the requested information or the time required for firmware installed in computerized equipment to react. Availability is of highest importance in on-line applications of frequently used information systems. The failure of firmware software to meet availability requirements (i.e, retarded reaction time) can make the equipment useless. Relatively difficult to test

Operation Factor Testing Classes - Reliability Tests:

Operation Factor Testing Classes - Reliability Tests The software system reliability requirement deals with features that can be translated as events occurring over time, i.e . average time between failures(e.g., 500 hours), or average time for recovery after system failure (e.g., 15 minutes). Reliability requirements are to be in effect during regular full-capacity operation of the system. Difficult as it requires operation of the full range of software applications conducted under regular workload conditions.

Operation Factor Testing Classes - Stress Tests:

Operation Factor Testing Classes - Stress Tests Load Tests Related to the functional performance of the system under maximal operational load: maximal transactions per minute, hits per minute to an Internet site and the like. Durability Tests Carried out in physically extreme operating conditions such as high temperatures, humidity, and high-speed driving along unpaved rural roads. Issues for firmware include firmware responses to climatic effects such as extreme hot and cold temperatures, dust, etc. IS software durability tests focus on operation failures resulting from sudden electrical failures.

Operation Factor Testing Classes - Software System Security Tests:

Operation Factor Testing Classes - Software System Security Tests Access control To control multi-level access (using password). Firewall systems Backup of databases and software files and recovery in cases of system failure. Logging of transactions, system usage, and access trials.

Operation Factor Testing Classes - Training Usability Tests:

Operation Factor Testing Classes - Training Usability Tests Added when large numbers of users are involved in operating a system. The scope is defined by the resources needed to train a new employee. The result of the tests should inspire a sophisticated plan of training courses and follow-up as well as improved directions for software system operation.

Operation Factor Testing Classes - Operational Usability Tests:

Operation Factor Testing Classes - Operational Usability Tests Deals mainly with the productivity ,quantitatively and qualitatively whereby these aspects are highly important for systems that serve as the main vocational tools for a large group of users.

Revision Factor Testing Classes:

Revision Factor Testing Classes Maintainability tests Flexibility tests Testability tests

Transition Factor Testing Classes:

Transition Factor Testing Classes Portability tests Reusability tests Software interfacing tests (for interoperability) Equipment interfacing tests (for interoperability)

authorStream Live Help