Software Testing Techniques “How to find bugs in the software? ” TCS 2411 Software Engineering 1
Lecture Objectives z. To understand the role of testing in ensuring software quality z. To discuss issues relevant to software testing z. To describe the different techniques used for testing software TCS 2411 Software Engineering 2
Validation & Verification z. Validation y“Are we building the product right? ” y. Ensure software meets customer’s needs z. Verification y“Are we building the right product? ” y. Ensure software meet specification (errorfree) TCS 2411 Software Engineering 3
Testing Terminology z Failure y Incorrect or unexpected output y Symptom of at fault z Fault y Invalid execution state y Symptom of an error y May or may not produce failure z Error y Defect or anomaly in source code y Commonly referred as bug y May or may not produce fault TCS 2411 Software Engineering 4
What is Software Testing z Software Testing is a process of executing a program with the intent of finding an error. z A good test case is one that has a high probability of finding an as yet undiscovered error z A successful test is one that uncovers an as yet undiscovered error TCS 2411 Software Engineering 5
Testing Objective z. To design tests that systematically uncover different classes of errors and to do so with a minimum amount of time and effort TCS 2411 Software Engineering 6
Why We Need Software Testing? z Reveal faults/failures/errors z Locate faults/failures/errors z Show system correctness z Improved confidence that system performs as specified (verification) z Improved confidence that system performs as desired (validation) z Indicator of system reliability and system quality TCS 2411 Software Engineering 7
Importance of Testing z. Critical Element of Software Quality Assurance z. Well-planned and thorough testing are important in reducing the high cost of software failure z. Can take up to 40% of development effort z. In systems that require high reliability, testing can be 3 to 5 times of all the other steps combined TCS 2411 Software Engineering 8
Testing Principles z All test should be traceable to customer requirements. z Tests should be planned before testing begins. z Testing should begin with individual components and move towards to integrated cluster of components. z The most effective testing should be conducted by an independent third party. TCS 2411 Software Engineering 9
Pre-requisites For Good Testing z. Adequate staff z. Adequate support facilities (tools) z. Adequate time TCS 2411 Software Engineering 10
Who Should Test The Software? z. Developer (individual units) z. Independent test group (ITG) yremoves conflict of interest yreports to SQA team TCS 2411 Software Engineering 11
Successful Testing z. Uncover errors in the software z. Demonstrates that the software functions appear to be working according to specification z. Data collected as testing is conducted provide a good indication of software reliability and software quality TCS 2411 Software Engineering 12
Testing Guidelines z. Testing a system’s capabilities is more important than testing its components z. Testing old capabilities is more important than testing new capabilities z. Testing typical situations is more important than testing boundary value cases TCS 2411 Software Engineering 13
Test Cases z Test case : unit of testing activity z Test cases have 3 parts : y. Goal x. Aspect of the system being tested y. Input and system state x. Data provided to the system under stated condition y. Expected behavior x. The output or action the system should take according to its requirements TCS 2411 Software Engineering 14
Test Cases (Cont) z. Test cases are derived during all phase of development cycle z. Determine the expected result before running the test case z. Record test cases and its results z. Allocate time TCS 2411 Software Engineering money people resources 15
Type Of Test Cases z. Test cases are derived for y. Valid and expected input y. Invalid and unexpected input y. Test if the system does less than specified requirement y. Test if the system does more than specified requirement TCS 2411 Software Engineering 16
White Box Testing z. Derived from knowledge of program’s structure & implementation z. Structural testing - analyse code & use knowledge of the structure of a component to derive test data z. Logical paths are tested by providing test cases that exercise specific sets of conditions and/or loops TCS 2411 Software Engineering 17
White Box Testing (Continued) z. Thorough white box testing would lead to “ 100 percent correct programs” z. Exhaustive testing are impractical - too many tests! z. A limited number of logical paths can be selected and exercised z. Important data structures can be probed for validity TCS 2411 Software Engineering 18
White Box Test Cases z. Guarantee that all independent paths have been exercised at least once z. Exercise all logical decisions on their true and false sides z. Execute all loops at their boundaries and within their operational bounds z. Exercise internal data structures to ensure their validity TCS 2411 Software Engineering 19
White Box Testing Techniques z Basis path testing y. Flow graph notation y. Cyclomatic complexity y. Derived test cases y. Graph metrics z Control structure testing y. Condition testing y. Data Flow testing y. Loop testing TCS 2411 Software Engineering 20
Flow Graph Notation 1 Edge Node 1 2, 3 2 6 3 4 6 7 8 5 9 11 10 7 R 3 R 2 4, 5 R 1 8 Region 9 10 R 4 11 TCS 2411 Software Engineering 21
Cyclomatic Complexity z Provide quantitative measure for program logical complexity. z Defined number of independent path y. Any path that introduce one ser of processing statements or new condition z Eg : y. Path 1 2 3 4 : : 1 -11 1 -2 -3 -4 -5 -10 -1 -11 1 -2 -3 -6 -8 -9 -10 -1 -11 1 -2 -3 -6 -7 -9 -10 -1 -11 TCS 2411 Software Engineering 22
How Is Cyclomatic Complexity Computed? 1. Number of regions l The flow graph has 4 regions 2. V(G) = E – N + 2 l E : Number of flow graph edges l N : Number of flow graph nodes x V(G) = 11 edges – 9 nodes + 2 = 4 3. V(G) = P + 1 l P : Number of predicate nodes x V(G) = 3 predicate nodes + 1 = 4 TCS 2411 Software Engineering 23
Deriving Test Cases 1. Draw flow graph from design/code as foundation. 1 8 … i=1; 2 total. input = total. valid=0; sum=0; do while value[i] <> -999 and total. input<100 3 4 increment total. input by 1; if value[i] >= minimum AND value[i] <= maximum 5 then increment total. valid by 1; sum = sum + value[i] 7 else skip end if increment i by 1 9 End do If total. valid > 0 10 11 then average = sum / total valid; 12 else average = -999; 13 End if … 1 2 3 6 4 10 12 11 5 13 6 8 7 9 TCS 2411 Software Engineering 24
Deriving Test Cases (cont) 2. Determine cyclomatic complexity l l l 3. Determine a basis set of linearly independent graph l l l 4. V(G) = 6 regions V(G) = 17 edges – 13 nodes + 2 = 6 V(G) = 5 predicates nodes + 1 = 6 Path 1 = 1 -2 -10 -11 -13 Path 2 = 1 -2 -10 -12 -13 …. Prepare test cases l Path 1 test case : x value(k) = valid input where k < i defined below x value(i) = -999 where 2 <= i <= 100 x Expected result : Correct average based on k value and proper totals TCS 2411 Software Engineering 25
Discussion on White Box Testing z Advantages y. Find errors on code level y. Typically based on a very systematic approach, covering the complete internal module structure z Constraints y. Does not find missing or additional functionality y. Does not really check the interface y. Difficult for large and complex module TCS 2411 Software Engineering 26
Black Box Testing z. Derived from program specification z. Functional testing of a component of a system z. Examine behaviour through inputs & the corresponding outputs z. Input is properly accepted, output is correctly produced z. Disregard internal logical structure TCS 2411 Software Engineering 27
Black Box Testing (Continued) Attempts to find the following errors: z. Incorrect or missing functions z. Interface errors z. Errors in data structures or external database access z. Performance errors z. Initialisation and termination errors TCS 2411 Software Engineering 28
Black Box Testing Techniques z. Graph Based Testing Methods z. Equivalence Partitioning z. Boundary Value Analysis z. Comparison Testing z. Orthogonal Array Testing TCS 2411 Software Engineering 29
Equivalence Partitioning z Divide input domain into classes of data z Based on an evaluation of equivalence classes for an input condition z Guidelines to define equivalence classes y. Range input : One valid and two invalid equivalence y. Specific value : One valid and two invalid equivalence y. A member of a set : One valid and one invalid equivalence y. Boolean : One valid and one invalid equivalence TCS 2411 Software Engineering 30
Example – Data for Automated Banking Application The use can access the bank using his personal computer, provide a six digit password, and follow with a series of typed commands that trigger various banking function. During the log on sequence the software supplied for the banking application accepts data in the form: area code – blank or 3 digit numbers prefix – 3 digit numbers, nor beginning with 0 or 1 suffix – 4 digit numbers password – 6 digits alphanumeric strings commands – “check”, “deposit”, “bill pay” etc Input condition area code : Input condition : Boolean – area code may or may not present Input condition : Range – 200 – 999 with specific exception prefix : Input condition : Range – specified value > 200 with no 0 digits suffix : Input condition : Value – 4 digit length password : Input condition : Boolean – password may or may not present Input condition : Value – six character string command : Input condition : Set – containing command TCS 2411 Software Engineering 31
Boundary Value Analysis z. Complement equivalence partitioning z. Test both sides of each boundary z. Look at output boundaries for test cases z. Test min, min-1, max+1, typical values z. Example : 1 <= x <=100 y Valid : 1, 2, 99, 100 y. Invalid : 0 and 101 TCS 2411 Software Engineering 32
Discussion on Black Box Testing z. Advantages y. Find missing functionality y. Independent from code size and functionality y. Find some coding errors z. Constraints y. No systematic search for low level errors y. Specification errors not found TCS 2411 Software Engineering 33
References z“Software Engineering: A Practitioner’s Approach” 5 th Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001 z“Software Engineering” by Ian Sommerville, Addison-Wesley, 2001 TCS 2411 Software Engineering 34
Скачать презентацию Software Testing Techniques How to find bugs in
1c575e28a3cc5d961873123e70828f5a.ppt