Prepared by : 1.Mohammed Siddig Ahmed. 2.Mohammed Zeinelabdeen. 3.Omer Salih Dawood.
Introduction to Testing. Verification and validation. Black & White-box testing. Types of testing that involve both black & white-box techniques. Strategies for writing test cases. Using a template for writing repeatable, defined test cases.
Software testing  is 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. Software testing is an activity that should be done throughout the whole development process . Software testing is one of the V&V, software practices.
Verification  is  the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. Validation   is the  process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements. Verification: Are we building the product right? Validation : Are we building the right product?
Standard or specification to measure or identify correct results from incorrect results must define some terms: Mistake  . Fault [or Defect]  . Failure  . Error .   Specification .
In software development, there are costs associated with testing our programs. Quality is much more important for safety- or mission critical software e.g. aviation software. Goal of testing covering many defects as possible with a little testing.
There are two basic classes of software testing definitions below: Black box testing   (also called functional testing) is  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 . White box testing   (also called structural testing and glass box testing) is  testing that takes into account the internal mechanism of a system or component .
1. Unit Testing Opacity: White box testing. Specification: Low-level design and/or code structure. ( Unit testing is the testing of individual hardware or software units or groups of related units). 2. Integration testing Opacity: Black- and white-box testing. Specification: Low- and high-level design. ( Integration test is testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them ).
3 .  Functional and system testing Opacity: Black-box testing Specification: high-level design, requirements specification. (  Functional testing involves ensuring that the functionality specified in the requirement specification works,& System testing is testing conducted on a complete, integrated system to evaluate the system compliance with its specified requirements). Stress testing Performance testing  Usability testing
4. Acceptance testing Opacity: Black-box testing Specification: requirements specification. ( Acceptance testing is formal testing conducted to determine whether or not a system satisfies its acceptance criteria (the criteria the system must satisfy to be accepted by a customer) and to enable the customer to determine whether or not to accept the system ).
5. Regression testing Opacity: Black- and white-box testing Specification: Any changed documentation, high-level design ( Regression testing is selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified Requirements). A subset of the regression test cases can be set aside as smoke tests.
6. Beta testing Opacity: Black-box testing. Specification: None. The advantages of beta test: Identification of unexpected errors A wider population search for errors Low costs The disadvantages Lack of systematic testing Low quality error reports Much effort is necessary to examine error reports
(  Document describing the scope, approach, resources, and schedule of intended test activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency plans). Test case  (  set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement).
The earlier testing is planned at all levels, the better. Very important to consider test planning and test execution as iterative processes. It is best to begin to write functional and system test cases. When requirements change, revise the test cases. When code changes, run the test cases again. All in all, testing should be considered an iterative and essential part of the entire development process.
Black-Box Testing
Called : functional testing  behavioral testing focuses on: whether or not a program does what it is supposed to do based on its functional requirements.
incorrect or missing functionality. interface errors . errors in data structures used by interfaces. behavior or performance errors. initialization and termination errors. But : no amount of testing can demonstrate the absence of errors.
blackbox tester is not the programmer of  the code (it is best). Programmer: If  the program does what they programmed it to do?. Needed: If The program does what the customer wants it to do?.
Focus on input and output of the software without regard to the internal code of the program
test case a unique identifier. describe the set of steps and/or input for the particular condition. the expected results for an input/output oracle. the actual results.
Why test Strategies?:- test every possible thing (Cost). find  many defects  in  few test cases . avoid writing redundant test cases. design the simplest test cases .
Tests of Customer Requirements. Equivalence Partitioning. Boundary Value Analysis. Decision Table Testing. Failure (“Dirty”) Test Cases.
Black box test cases are based on customer requirements Have two paths: success path. failure path. risky requirements should  tested first.
don’t want to write several test cases that test the same aspect of our program(cost). A good test case uncovers a different class of errors. Equivalence partitioning is  used to reduce the number of test cases . divides the input of a program into classes
For each of these  classes :- the set of data should be treated the same by the module under test . And should produce the same answer.
When creating BVA test cases, consider the following :   If input conditions have a range from a to b (such as a=100 to b=300), create test cases:  immediately below a (99)  at a (100)  immediately above a (101)  immediately below b (299)  at b (300)  immediately above b (301)
If input conditions specify a number of values that are allowed, test these limits.
record complex business rules that must be implemented in the program, and therefore tested. conditions  represent possible input. actions  are the events that should trigger. Each column in the table is a unique combination of input conditions  that result in triggering the action(s) associated with the rule.
every possible thing a user could possibly do with your system to demolish the software.
White-Box Testing
White-box testing is a verification technique software engineers can use to examine if their   code works as expected. White-box testing is testing that takes into account the internal mechanism of a system or component . It also known as structural testing, clear box   testing, and glass box testing (Beizer, 1995).
types of testing: There are six basic types of testing: Unit Testing. Integration Testing. Regression Testing. function/system Testing. Acceptance Testing.  Beta Testing. White-box testing is used for 1,2,and 3 respectively.
white-box testing techniques : White-Box Testing by Stubs and Drivers. Deriving Test Cases. Control-flow/Coverage Testing. Data Flow Testing. Failure (“Dirty”) Test Cases. Flow Graphs Revisited.
With white-box testing, you must run the code with predetermined input and check to make sure that the code produces predetermined outputs. Often programmers write stubs and drivers for white-box testing. A  driver:  is a software module used to invoke a module under test and, often, provide test inputs, control and monitor execution, and report test results A  stub:  is a computer program statement substituting for the body of a software module that is or will be defined elsewhere.
A  driver: movePlayer(Player1, 2); A  stub: public void movePlayer(Player player, int diceValue)  { player.setPosition(1); }
statistics show that the act of careful, complete, systematic test design will catch as many bugs as the act of testing .  The test design process, at all levels, is at least as effective at catching bugs as is running the test case designed by that process.
Basis Path Testing : A testing mechanism proposed by McCabe. is a means for ensuring that all independent paths through a code module have been tested. An  independent path is any path through the code that  introduces at least one new set of processing statements or a new condition .
 
cyclomatic number : Number of conditions (diamonds) and add 1. 1-2-3-4-5-10 (property owned by others, no money for rent) 1-2-3-4-6-10 (property owned by others, pay rent) 1-2-3-10 (property owned by the player) 1-2-7-10 (property available, don’t have enough money) 1-2-7-8-10 (property available, have money, don’t want to buy it) 1-2-7-8-9-10 (property available, have money, and buy it)
Equivalence Partitioning/Boundary Value Analysis : Equivalence partitioning (EP) and boundary value analysis (BVA) provide a strategy for writing white-box test cases. Undoubtedly, whenever you encounter any kind of number or limit in a requirement, you should be alert for EP/BVA issues. then we will check the object by giving boundary values as :min,min-1,min+1,max,max-1,max+1
Equivalence Partitioning/Boundary Value Analysis : 1. property costs $100, have $200 (equivalence class “have enough money”). 2. property costs $100, have $50 (equivalence class, “don’t have enough money”). 3. property costs $100, have $100 (boundary value). 4. property costs $100, have $99 (boundary value). 5. property costs $100, have $101 (boundary value).
Coverage:  is a measure of the completeness of the set of test cases
Statement Coverage Decision/Branch Coverage Condition Coverage Decision/Condition Coverage Path Coverage
If ((A>1) & (B=0)) then Do; X=X/A; END; If ((A==2) | (X>1)) then Do; X=X+1; END; END;   Source:  The Art of Software Testing  – Glenford Myers
Statement Coverage Exercise all statements at least once How many test cases? A=2 and B=0 (ace) Source:  The Art of Software Testing  – Glenford Myers
Decision/Branch Coverage Each decision has a true and a false outcome at least once How many test cases? A=2 and B=0 (ace) A=1 and X=1 (abd) Source:  The Art of Software Testing  – Glenford Myers
Condition Coverage Each condition in a decision takes on all possible outcomes at least once Conditions:  A>1, B=0, A=2, X>1 How many test cases? A=2, B=0, and X=4 (ace) A=1, B=1, and X=1 (abd) Source:  The Art of Software Testing  – Glenford Myers
Decision/Condition Coverage Each condition in a decision takes on all possible outcomes at least once, and each decision takes on all possible outcomes at least once How many test cases? A=2, B=0, and X=4 (ace) A=1, B=1, and X=1 (abd) What about these? A=1, B=0, and X=3  A=2, B=1, and X=1 (abe) (abe)
Multiple Condition Coverage Exercise all possible combinations of condition outcomes in each decision Conditions: Source:  The Art of Software Testing  – Glenford Myers A>1, B=0 A>1, B<>0 A<=1, B=0 A<=1, B<>0 A=2, X>1 A=2, X<=1 A<>2, X>1 A<>2, X<=1
Multiple Condition Coverage How many test cases? A=2, B=0, X=4 A=2, B=1, X=1 A=1, B=0, X=2 A=1, B=1, X=1 Source:  The Art of Software Testing  – Glenford Myers (ace) (abe) (abe) (abd)
Path Coverage Every unique path through the program is executed at least once How many test cases? A=2, B=0, X=4 (ace) A=2, B=1, X=1 (abe) A=3, B=0, X=1 (acd) A=1, B=1, X=1 (abd) Source:  The Art of Software Testing  – Glenford Myers
the control flowgraph is annotated with information about how the   program variables are defined and used .
 
Look at the structure of your code and think about every   possible way a user might break it . Some suggestions follow: Look at every input into the code you are  testing. Look at every calculation
When you encounter a compound predicate, such as in, you must   break the expression up so that each Boolean sub-expression is evaluated on its own .
Why Do Both? Black-box Impossible to write a test case for every possible set of inputs and outputs Some of the code may not be reachable without extraordinary measures Specifications are not always complete White-box Does not address the question of whether or not the program matches the specification Does not tell you if all of the functionality has been implemented Does not discover missing program logic
References : Cem Kaner, Testing Computer Software. http://www.win.tue.nl/~mousavi/testing/7.pdf . www.sisqa.com/Training/ White_Box_Testing - 200709 . ppt
Questions ?

Testing

  • 1.
    Prepared by :1.Mohammed Siddig Ahmed. 2.Mohammed Zeinelabdeen. 3.Omer Salih Dawood.
  • 2.
    Introduction to Testing.Verification and validation. Black & White-box testing. Types of testing that involve both black & white-box techniques. Strategies for writing test cases. Using a template for writing repeatable, defined test cases.
  • 3.
    Software testing is 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. Software testing is an activity that should be done throughout the whole development process . Software testing is one of the V&V, software practices.
  • 4.
    Verification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. Validation is the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements. Verification: Are we building the product right? Validation : Are we building the right product?
  • 5.
    Standard or specificationto measure or identify correct results from incorrect results must define some terms: Mistake . Fault [or Defect] . Failure . Error . Specification .
  • 6.
    In software development,there are costs associated with testing our programs. Quality is much more important for safety- or mission critical software e.g. aviation software. Goal of testing covering many defects as possible with a little testing.
  • 7.
    There are twobasic classes of software testing definitions below: Black box testing (also called functional testing) is 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 . White box testing (also called structural testing and glass box testing) is testing that takes into account the internal mechanism of a system or component .
  • 8.
    1. Unit TestingOpacity: White box testing. Specification: Low-level design and/or code structure. ( Unit testing is the testing of individual hardware or software units or groups of related units). 2. Integration testing Opacity: Black- and white-box testing. Specification: Low- and high-level design. ( Integration test is testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them ).
  • 9.
    3 . Functional and system testing Opacity: Black-box testing Specification: high-level design, requirements specification. ( Functional testing involves ensuring that the functionality specified in the requirement specification works,& System testing is testing conducted on a complete, integrated system to evaluate the system compliance with its specified requirements). Stress testing Performance testing Usability testing
  • 10.
    4. Acceptance testingOpacity: Black-box testing Specification: requirements specification. ( Acceptance testing is formal testing conducted to determine whether or not a system satisfies its acceptance criteria (the criteria the system must satisfy to be accepted by a customer) and to enable the customer to determine whether or not to accept the system ).
  • 11.
    5. Regression testingOpacity: Black- and white-box testing Specification: Any changed documentation, high-level design ( Regression testing is selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified Requirements). A subset of the regression test cases can be set aside as smoke tests.
  • 12.
    6. Beta testingOpacity: Black-box testing. Specification: None. The advantages of beta test: Identification of unexpected errors A wider population search for errors Low costs The disadvantages Lack of systematic testing Low quality error reports Much effort is necessary to examine error reports
  • 14.
    ( Documentdescribing the scope, approach, resources, and schedule of intended test activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency plans). Test case ( set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement).
  • 15.
    The earlier testingis planned at all levels, the better. Very important to consider test planning and test execution as iterative processes. It is best to begin to write functional and system test cases. When requirements change, revise the test cases. When code changes, run the test cases again. All in all, testing should be considered an iterative and essential part of the entire development process.
  • 18.
  • 19.
    Called : functionaltesting behavioral testing focuses on: whether or not a program does what it is supposed to do based on its functional requirements.
  • 20.
    incorrect or missingfunctionality. interface errors . errors in data structures used by interfaces. behavior or performance errors. initialization and termination errors. But : no amount of testing can demonstrate the absence of errors.
  • 21.
    blackbox tester isnot the programmer of the code (it is best). Programmer: If the program does what they programmed it to do?. Needed: If The program does what the customer wants it to do?.
  • 22.
    Focus on inputand output of the software without regard to the internal code of the program
  • 23.
    test case aunique identifier. describe the set of steps and/or input for the particular condition. the expected results for an input/output oracle. the actual results.
  • 25.
    Why test Strategies?:-test every possible thing (Cost). find many defects in few test cases . avoid writing redundant test cases. design the simplest test cases .
  • 26.
    Tests of CustomerRequirements. Equivalence Partitioning. Boundary Value Analysis. Decision Table Testing. Failure (“Dirty”) Test Cases.
  • 27.
    Black box testcases are based on customer requirements Have two paths: success path. failure path. risky requirements should tested first.
  • 28.
    don’t want towrite several test cases that test the same aspect of our program(cost). A good test case uncovers a different class of errors. Equivalence partitioning is used to reduce the number of test cases . divides the input of a program into classes
  • 29.
    For each ofthese classes :- the set of data should be treated the same by the module under test . And should produce the same answer.
  • 31.
    When creating BVAtest cases, consider the following : If input conditions have a range from a to b (such as a=100 to b=300), create test cases: immediately below a (99) at a (100) immediately above a (101) immediately below b (299) at b (300) immediately above b (301)
  • 32.
    If input conditionsspecify a number of values that are allowed, test these limits.
  • 33.
    record complex businessrules that must be implemented in the program, and therefore tested. conditions represent possible input. actions are the events that should trigger. Each column in the table is a unique combination of input conditions that result in triggering the action(s) associated with the rule.
  • 35.
    every possible thinga user could possibly do with your system to demolish the software.
  • 36.
  • 37.
    White-box testing isa verification technique software engineers can use to examine if their code works as expected. White-box testing is testing that takes into account the internal mechanism of a system or component . It also known as structural testing, clear box testing, and glass box testing (Beizer, 1995).
  • 38.
    types of testing:There are six basic types of testing: Unit Testing. Integration Testing. Regression Testing. function/system Testing. Acceptance Testing. Beta Testing. White-box testing is used for 1,2,and 3 respectively.
  • 39.
    white-box testing techniques: White-Box Testing by Stubs and Drivers. Deriving Test Cases. Control-flow/Coverage Testing. Data Flow Testing. Failure (“Dirty”) Test Cases. Flow Graphs Revisited.
  • 40.
    With white-box testing,you must run the code with predetermined input and check to make sure that the code produces predetermined outputs. Often programmers write stubs and drivers for white-box testing. A driver: is a software module used to invoke a module under test and, often, provide test inputs, control and monitor execution, and report test results A stub: is a computer program statement substituting for the body of a software module that is or will be defined elsewhere.
  • 41.
    A driver:movePlayer(Player1, 2); A stub: public void movePlayer(Player player, int diceValue) { player.setPosition(1); }
  • 42.
    statistics show thatthe act of careful, complete, systematic test design will catch as many bugs as the act of testing . The test design process, at all levels, is at least as effective at catching bugs as is running the test case designed by that process.
  • 43.
    Basis Path Testing: A testing mechanism proposed by McCabe. is a means for ensuring that all independent paths through a code module have been tested. An independent path is any path through the code that introduces at least one new set of processing statements or a new condition .
  • 44.
  • 45.
    cyclomatic number :Number of conditions (diamonds) and add 1. 1-2-3-4-5-10 (property owned by others, no money for rent) 1-2-3-4-6-10 (property owned by others, pay rent) 1-2-3-10 (property owned by the player) 1-2-7-10 (property available, don’t have enough money) 1-2-7-8-10 (property available, have money, don’t want to buy it) 1-2-7-8-9-10 (property available, have money, and buy it)
  • 46.
    Equivalence Partitioning/Boundary ValueAnalysis : Equivalence partitioning (EP) and boundary value analysis (BVA) provide a strategy for writing white-box test cases. Undoubtedly, whenever you encounter any kind of number or limit in a requirement, you should be alert for EP/BVA issues. then we will check the object by giving boundary values as :min,min-1,min+1,max,max-1,max+1
  • 47.
    Equivalence Partitioning/Boundary ValueAnalysis : 1. property costs $100, have $200 (equivalence class “have enough money”). 2. property costs $100, have $50 (equivalence class, “don’t have enough money”). 3. property costs $100, have $100 (boundary value). 4. property costs $100, have $99 (boundary value). 5. property costs $100, have $101 (boundary value).
  • 48.
    Coverage: isa measure of the completeness of the set of test cases
  • 49.
    Statement Coverage Decision/BranchCoverage Condition Coverage Decision/Condition Coverage Path Coverage
  • 50.
    If ((A>1) &(B=0)) then Do; X=X/A; END; If ((A==2) | (X>1)) then Do; X=X+1; END; END; Source: The Art of Software Testing – Glenford Myers
  • 51.
    Statement Coverage Exerciseall statements at least once How many test cases? A=2 and B=0 (ace) Source: The Art of Software Testing – Glenford Myers
  • 52.
    Decision/Branch Coverage Eachdecision has a true and a false outcome at least once How many test cases? A=2 and B=0 (ace) A=1 and X=1 (abd) Source: The Art of Software Testing – Glenford Myers
  • 53.
    Condition Coverage Eachcondition in a decision takes on all possible outcomes at least once Conditions: A>1, B=0, A=2, X>1 How many test cases? A=2, B=0, and X=4 (ace) A=1, B=1, and X=1 (abd) Source: The Art of Software Testing – Glenford Myers
  • 54.
    Decision/Condition Coverage Eachcondition in a decision takes on all possible outcomes at least once, and each decision takes on all possible outcomes at least once How many test cases? A=2, B=0, and X=4 (ace) A=1, B=1, and X=1 (abd) What about these? A=1, B=0, and X=3 A=2, B=1, and X=1 (abe) (abe)
  • 55.
    Multiple Condition CoverageExercise all possible combinations of condition outcomes in each decision Conditions: Source: The Art of Software Testing – Glenford Myers A>1, B=0 A>1, B<>0 A<=1, B=0 A<=1, B<>0 A=2, X>1 A=2, X<=1 A<>2, X>1 A<>2, X<=1
  • 56.
    Multiple Condition CoverageHow many test cases? A=2, B=0, X=4 A=2, B=1, X=1 A=1, B=0, X=2 A=1, B=1, X=1 Source: The Art of Software Testing – Glenford Myers (ace) (abe) (abe) (abd)
  • 57.
    Path Coverage Everyunique path through the program is executed at least once How many test cases? A=2, B=0, X=4 (ace) A=2, B=1, X=1 (abe) A=3, B=0, X=1 (acd) A=1, B=1, X=1 (abd) Source: The Art of Software Testing – Glenford Myers
  • 58.
    the control flowgraphis annotated with information about how the program variables are defined and used .
  • 59.
  • 60.
    Look at thestructure of your code and think about every possible way a user might break it . Some suggestions follow: Look at every input into the code you are testing. Look at every calculation
  • 61.
    When you encountera compound predicate, such as in, you must break the expression up so that each Boolean sub-expression is evaluated on its own .
  • 62.
    Why Do Both?Black-box Impossible to write a test case for every possible set of inputs and outputs Some of the code may not be reachable without extraordinary measures Specifications are not always complete White-box Does not address the question of whether or not the program matches the specification Does not tell you if all of the functionality has been implemented Does not discover missing program logic
  • 63.
    References : CemKaner, Testing Computer Software. http://www.win.tue.nl/~mousavi/testing/7.pdf . www.sisqa.com/Training/ White_Box_Testing - 200709 . ppt
  • 64.