Download presentation
Presentation is loading. Please wait.
Published byMarsha Thornton Modified over 8 years ago
2
Unit IV 1
3
TCS2411 Software Engineering2 Testing “How to find bugs in the software?” zTesting is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user.
4
TCS2411 Software Engineering3 Lecture Objectives zTo understand the role of testing in ensuring software quality zTo discuss issues relevant to software testing zTo describe the different techniques used for testing software
5
TCS2411 Software Engineering4 Validation & Verification zTesting is part of V&V zValidation y“Are we building the product right?” yEnsure software meets customer’s needs. zVerification y“Are we building the right product?” yEnsure software meet specification.
6
TCS2411 Software Engineering5 Testing Terminology zFailure yIncorrect or unexpected output ySymptom of at fault zFault yInvalid execution state ySymptom of an error yMay or may not produce failure zError yDefect or anomaly in source code yCommonly referred as bug yMay or may not produce fault
7
TCS2411 Software Engineering6 Testing Objectives zSoftware Testing is a process of executing a program with the intent of finding an error. zA good test case is one that has a high probability of finding an as yet undiscovered error zA successful test is one that uncovers an as yet undiscovered error
8
TCS2411 Software Engineering7 Testing Objective zTo design tests that systematically uncover different classes of errors and to do so with a minimum amount of time and effort
9
TCS2411 Software Engineering8 Why We Need Software Testing? zReveal faults/failures/errors zLocate faults/failures/errors zShow system correctness zImproved confidence that system performs as specified (verification) zImproved confidence that system performs as desired (validation) zIndicator of system reliability and system quality
10
TCS2411 Software Engineering9 Importance of Testing zCritical Element of Software Quality Assurance zWell-planned and thorough testing are important in reducing the high cost of software failure zCan take up to 40% of development effort zIn systems that require high reliability, testing can be 3 to 5 times of all the other steps combined
11
TCS2411 Software Engineering10 Testing Principles zAll test should be traceable to customer requirements. zTests should be planned before testing begins.
12
Charecteristics of testable software zOperability. zObservability zControllability zDecomposability zSimplicity zStability zUnderstandability TCS2411 Software Engineering11
13
Attributes of good test: zA good test has a high probability of finding an error. zA good test is not redundant. zA good test should be “best of breed”. zA good test should be neither too simple nor too complex. TCS2411 Software Engineering12
14
TCS2411 Software Engineering13 Pre-requisites For Good Testing zAdequate staff zAdequate support facilities (tools) zAdequate time
15
TCS2411 Software Engineering14 Who Should Test The Software? zDeveloper (individual units) zIndependent test group (ITG) yremoves conflict of interest yreports to SQA team
16
TCS2411 Software Engineering15 Successful Testing zUncover errors in the software zDemonstrates that the software functions appear to be working according to specification zData collected as testing is conducted provide a good indication of software reliability and software quality
17
TCS2411 Software Engineering16 Testing Guidelines zTesting a system’s capabilities is more important than testing its components zTesting old capabilities is more important than testing new capabilities zTesting typical situations is more important than testing boundary value cases
18
TCS2411 Software Engineering17 Test Cases zTest case : unit of testing activity zTest cases have 3 parts :- yGoal xAspect of the system being tested yInput and system state xData provided to the system under stated condition yExpected behavior xThe output or action the system should take according to its requirements
19
TCS2411 Software Engineering18 Test Cases (Cont) zTest cases are derived during all phase of development cycle zDetermine the expected result before running the test case zRecord test cases and its results zAllocate money people resources time
20
TCS2411 Software Engineering19 Type Of Test Cases zTest cases are derived for yValid and expected input yInvalid and unexpected input yTest if the system does less than specified requirement yTest if the system does more than specified requirement
21
TCS2411 Software Engineering20 White Box Testing zDerived from knowledge of program’s structure & implementation zStructural testing - analyse code & use knowledge of the structure of a component to derive test data zLogical paths are tested by providing test cases that exercise specific sets of conditions and/or loops
22
TCS2411 Software Engineering21 White Box Testing (Continued) zThorough white box testing would lead to “100 percent correct programs” zExhaustive testing are impractical - too many tests! zA limited number of logical paths can be selected and exercised zImportant data structures can be probed for validity
23
TCS2411 Software Engineering22 White Box Test Cases zGuarantee that all independent paths have been exercised at least once zExercise all logical decisions on their true and false sides zExecute all loops at their boundaries and within their operational bounds zExercise internal data structures to ensure their validity
24
TCS2411 Software Engineering23 White Box Testing Techniques zBasis path testing yFlow graph notation yCyclomatic complexity yDerived test cases yGraph metrics zControl structure testing yCondition testing yData Flow testing yLoop testing
25
TCS2411 Software Engineering24 Flow Graph Notation 1 2 3 6 78 4 5 9 10 11 1 2,3 6 78 9 10 11 4,5 Node Edge R3 R2 R1 R4 Region
26
TCS2411 Software Engineering25 Cyclomatic Complexity zProvide quantitative measure for program logical complexity. zDefined number of independent path yAny path that introduce one set of processing statements or new condition zEg :- yPath 1 : 1-11 yPath 2 : 1-2-3-4-5-10-1-11 yPath 3 : 1-2-3-6-8-9-10-1-11 yPath 4 : 1-2-3-6-7-9-10-1-11
27
TCS2411 Software Engineering26 How Is Cyclomatic Complexity Computed? ( Refer 24 slide ) 1.Number of regions The flow graph has 4 regions 2.V(G) = E – N + 2 E : Number of flow graph edges N : Number of flow graph nodes xV(G) = 11 edges – 9 nodes + 2 = 4 3.V(G) = P + 1 P : Number of predicate nodes xV(G) = 3 predicate nodes + 1 = 4
28
TCS2411 Software Engineering27 Deriving Test Cases 1.Draw flow graph from design/code as foundation. … i=1; total.input = total.valid=0; sum=0; do while value[i] <> -999 and total.input<100 increment total.input by 1; if value[i] >= minimum AND value[i] <= maximum then increment total.valid by 1; sum = sum + value[i] else skip end if increment i by 1 End do If total.valid > 0 then average = sum / total valid; else average = -999; End if … 1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4 5 6 78 9 10 1112 13
29
TCS2411 Software Engineering28 Deriving Test Cases (cont) 2.Determine cyclomatic complexity V(G) = 6 regions V(G) = 17 edges – 13 nodes + 2 = 6 V(G) = 5 predicates nodes + 1 = 6 3.Determine a basis set of linearly independent graph Path 1 = 1-2-10-11-13 Path 2 = 1-2-10-12-13 …. 4.Prepare test cases Path 1 test case : xvalue(k) = valid input where k < i defined below xvalue(i) = -999 where 2 <= i <= 100 xExpected result : Correct average based on k value and proper totals
30
TCS2411 Software Engineering29 Discussion on White Box Testing zAdvantages yFind errors on code level yTypically based on a very systematic approach, covering the complete internal module structure zConstraints yDoes not find missing or additional functionality yDoes not really check the interface yDifficult for large and complex module
31
TCS2411 Software Engineering30 Black Box Testing zDerived from program specification zFunctional testing of a component of a system zExamine behaviour through inputs & the corresponding outputs zInput is properly accepted, output is correctly produced zDisregard internal logical structure
32
TCS2411 Software Engineering31 Black Box Testing (Continued) Attempts to find the following errors: zIncorrect or missing functions zInterface errors zErrors in data structures or external database access zPerformance errors zInitialisation and termination errors
33
TCS2411 Software Engineering32 Black Box Testing Techniques zGraph Based Testing Methods zEquivalence Partitioning zBoundary Value Analysis zComparison Testing zOrthogonal Array Testing
34
TCS2411 Software Engineering33 Equivalence Partitioning zDivide input domain into classes of data zBased on an evaluation of equivalence classes for an input condition zGuidelines to define equivalence classes yRange input : One valid and two invalid equivalence ySpecific value : One valid and two invalid equivalence yA member of a set : One valid and one invalid equivalence yBoolean : One valid and one invalid equivalence
35
TCS2411 Software Engineering34 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
36
TCS2411 Software Engineering35 Boundary Value Analysis zComplement equivalence partitioning zTest both sides of each boundary zLook at output boundaries for test cases zTest min, min-1, max, max+1, typical values zExample : 1 <= x <=100 y Valid : 1, 2, 99, 100 yInvalid : 0 and 101
37
TCS2411 Software Engineering36 Discussion on Black Box Testing zAdvantages yFind missing functionality yIndependent from code size and functionality yFind some coding errors zConstraints yNo systematic search for low level errors ySpecification errors not found
38
TCS2411 Software Engineering37 References z“Software Engineering: A Practitioner’s Approach” 5th Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001 z“Software Engineering” by Ian Sommerville, Addison-Wesley, 2001
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.