• Save
Quality Assurance
Upcoming SlideShare
Loading in...5
×
 

Quality Assurance

on

  • 16,853 views

Learn more about Quality Assurance & Software Testing

Learn more about Quality Assurance & Software Testing

Statistics

Views

Total Views
16,853
Views on SlideShare
16,586
Embed Views
267

Actions

Likes
53
Downloads
0
Comments
1

8 Embeds 267

http://shortcourses.ca 107
http://www.shortcourses.ca 84
http://www.slideshare.net 55
http://www.minosegdoktorok.hu 10
http://www.brijj.com 8
http://betore.blogspot.com 1
http://static.slidesharecdn.com 1
https://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Quality Assurance Quality Assurance Presentation Transcript

  • Where are we? Specification Design Testing Code & Test Quality Assurance
    • Is SWTesting important?
    • Why SW errors are inevitable?
    • Is it sufficient to test the code alone?
    • What is Quality Assurance?
    • Why SWT need planning?
    • Who test well? Independent Tester?
    • What are the good qualities of a test case?
    • What are the attributes of testable software?
    What are we going to discuss today?
    • To show a system works correctly
    • OR
    • To identify errors and deficiencies
    • Which SW company gives Money Back Guarantee?
    Which is the aim of SW Testing ?
  • What Testing Shows? errors requirements conformance performance an indication of quality © SEPA
  • SW Testing starts with coding But, Quality Assurance is a continuous process Testing is an incremental process. Starts from small modules and integrated to higher level modules. But, planning the testing process should be started early in system engineering state. When Testing Starts?
  • When Testing Starts? SystemEngineering Requirement Analysis Design Coding Test Plan Unit Test Integration Test ValidationTest SystemTest plans plans System test plan. SW+HW Function performance etc. BB some GB BB GB Acceptance Test Developer Tester Developer Tester Tester User
  • Quality Assurance: monitoring and improving the whole SW development process. Includes, Verification : Are we building right SW? and Validation : Did we build the SW right? Requirement Specification SW Verify Validate walkthrough, inspection static, dynamic Testing is part of SW Quality Assurance essential
  • Testing is the process of exercising a program with the intent of finding errors within set time and effort prior to delivery to the end user. Not to show that a SW is working correctly! OK! Why Testing such Essential? Testing not only executing
    • 1999 Oct - Missing in Action (125 Million US$)
    • NASA Spacecraft
    • Cause- missing initialization
    • 1996 July- Lost in Action (500 Million US$)
    • Ariane 5 Spacecraft
    • Cause - 64 bit real to 16 bit integer
    • 1992 Oct- Ambulance Crash (20 people’s live)
    • London Ambulance Service
    • Cause- not fully tested under full load
    Simple Errors may Cause Terrible Disasters
    • NO ! To err is human.
    • Errors not only occur in code- it may originate from specification
    • Why errors introduced in SW?
    • Communication errors (different situation)
    • may be due to problem complexity
    • Programmer’s errors ( normal- 1 per 10 lines)
    • ego may play a role
    Can’t we avoid errors if we program carefully?
  • Testing should be planned well
    • For safety-critical SW testing costs 80%
    • For commercial application about 40%
    • Pareto Principle: 80% of errors are likely to be found in 20% of code- How to isolate?
    • Exhaustive testing is not possible (e.p.?)
    • Need to find suitable representatives ( test cases ] for the whole input domain
  • Exhaustive Testing There are 10 14 possible paths! If we execute one test per millisecond, it would take 3,170 years to test this program!! © SEPA loop < 20 X
  • Test Cases
    • Quality, not quantity, matters (example?)
    • What are good qualities of test cases?
    • - has a high probability of finding a new bug
    • - not redundant
    • - covers variety of error types
    • - not complex and not simple
  • Test Cases (Example)
    • Module: doubleDigit
    • Purpose: To print all integers between 0-99 in double digits
    • Input : integer X
    • Precondition: 0 <= X <= 99
    • Output: X printed on screen
    • Post condition: If 0<=X<=9, ‘0X’ printed o/w ‘X’ printed
    • Implementation ( wrong! )
      • if x < 9 Exhaustive Testing : try all 0-99 numbers , or all numbers
      • print ‘0’; Or use random number generator, Test case quality?
      • else But, what are the best test cases?
      • print x; -1,0,1,5,8,9,10,50,98,99,100 why?
  • Testing is a ‘destructive’ process?
    • A test is successful if it reveals a new error
    • Testing is best done by independent testers
    • Developers, if you test your own code, change to ‘destructive’ mood!
    • Developers should help testers.
    • Pay now or pay much later!
  • Why need independent tester? Developer Independent tester Advantage : Already knew the system. but, will test &quot;gently&quot; and, is driven by &quot;delivery&quot; Disadvantage : Must learn the system but, will attempt to break it and, is driven by quality © SEPA
  • Testability
    • Operability —it operates cleanly
    • Visibility / Observability —the results of each test case are readily observed
    • Controllability —the degree to which testing can be automated and optimized
    • Decomposability —testing can be targeted
    • Simplicity —reduce complex architecture and logic to simplify tests
    • Stability —few changes are requested during testing
    • Understandability —of the design
    A set of good characteristics of a SW that has a high degree of testability
  • What we learned ?
    • Can’t avoid bugs- testing is essential
    • Testing is a part of whole QA process
    • Independent Testers test better
    • Testing should be planned well
    • Planning starts from beginning
    • Testing is incremental
    • Test case Qualities (?) matter
    • Testability - easy to test - A SW quality (?)
    • A set of good characteristics of a SW that has a high degree of testability
  • What are we going to discuss now?
    • A SW may be tested for different purposes
    • Black box and White box are two important techniques used to identify suitable test cases
    • WB and BB are complementary, not alternate
    • WB is a sort of ‘coverage’ test - e.g. path coverage
    • Basis-path test : representing a module’s logic in flow-graph and identifying linearly independent path and determining test cases
    • Other WB tests - Loop, Conditional, Dataflow
  • SW Testing and Purposes
    • A module may be tested for different purposes
    • To check functionality against requirements
    • To ensure efficiency / performance
    • To evaluate userfriendliness
    • To ensure security
    • To check compatibility
    • To compare it with its rival algo or SW
    • etc.
  • Two Important Testing Techniques Black-Box : To test the functionality, behavior and performance against its specification. Implementation logic is not necessary White-Box : To test the correctness of the internal logic of a module. Therefore, Implementation detail is necessary © SEPA boundary-value equivalent Partition white-box methods black-box methods basis-path control structure
  • Black-Box Testing Functional, Behavior, Performance, requirements (expected output) events input output Internal logic not required © SEPA
  • White-Box Testing Based on “coverage” : goal is to ensure that all the statements and conditions have been executed at least once … statement edge path To test the internal logic © SEPA
  • Why Cover? logic errors and incorrect assumptions are inversely proportional to a path's execution probability we often believe that a path is not likely to be executed; in fact, reality is often counter intuitive typographical errors are random; it's likely that untested paths will contain some © SEPA
  • PATH coverage not feasible There are 10 14 possible paths! If we execute one test per millisecond, it would take 3,170 years to test this program!! © SEPA loop < 20 X
  • Select Most Suitable Paths - but how? Linearly Independent Paths : each new path introduces at least one different executable or simple conditional statement OR a new edge © SEPA This also ensures statement and edge coverage : every statement (and edge) is executed at least once loop < 20 X
  • Basis-Path Testing - A White-Box test
          • STEPS
          • Start with the internal logic of the module
          • Draw flow-graph for the program logic
          • Identify a set of linearly independent paths
          • Prepare test cases that will force execution
          • of each path- check for redundancy
  • Flow Graph  Basic Structures
    • SEQUENCE
    • IF-ELSE
    • CASE
    A; B; if ( C ) D; else E; F; case G { g1 : H; g2 : I; else : J; } K; A B C E F D G J K I H
  • Flow Graph  Basic Structures
    • WHILE
    • REPEAT
    while (L) M; N; do { O; } while (P); Q; NODE REGION EDGE L M N O P Q
  • Flow Graph  Basic Structures
    • AND
    • OR
    if R AND S T; else U; V; if R OR S T; else U; V; R S T U V R S U T V
  • Flow Graph  Basic Structures
    • AND
    • OR
    While R AND S T; V; While R OR S T; V; S T V R S T V R
  • BASIS-PATH example Module : search
        • Description : To search a ‘target’ value in an array of integers (which is in ascending order) and, if the ‘target’ is found returns 'TRUE' otherwise returns 'FALSE'.
        • input : array of integers A, integer maxInA
        • integer N (stands for the number of records in A),
        • integer target
        • Pre-condition : maxInA > N >= 0,
        • A[j] <= A[j+1] for all integer j, 0 < j < N.
        • Output : boolean found
        • Post-condition :
        • ((  j, 0 < j < N+1. A[j] = target ) AND (found = TRUE) )
        • OR
        • (( V j, 0 < j < N+1. A[j] < > target ) AND (found = FALSE) )
  • BASIS-PATH example Module : search ( An Implementation)
        • Processing
    • j  1;
    • A[N+1]  target;
    • while ( A[j] < target )
    • j  j + 1;
    • if (j <= N) AND (A[j] == target)
        • found = TRUE;
    • else
    • found = FALSE;
    • return ( found );
    6 1 2 3 4 5 7 8 5 2 1 3 4 8 6 7
  • Coverage
    • Statement coverage:
    • 1 2 3 2 4 5 6 8 1 2 4 7 8
    • Edge Coverage:
    • 1 2 3 2 4 5 6 8 1 2 4 7 8 1 2 4 5 7 8
    • Path Coverage:
    • 1 2 3 2 4 5 6 8 1 2 4 7 8 1 2 4 5 7 8
    • 1 2 3 2 4 5 7 8 1 2 4 5 6 8 1 2 3 2 4 7 8
    • But, not possible for complex programs ==> Basis-PATH
    5 2 1 3 4 8 6 7
  • Cyclomatic Complexity ( V(G) ) Number of simple conditions + 1 OR Number of enclosed areas + 1 OR Edges - Nodes + 2 In this case, V(G) = 4
    • Gives the number of paths in the flow-graph or BASIS-PATH
    • This is a metric of logic complexity of a program
    5 2 1 3 4 8 6 7
  • Cyclomatic Complexity A number of industry studies have indicated that the higher V(G), the higher the probability or errors. V(G) modules modules in this range are more error prone © SEPA
  • Basis Path Testing- Independent Paths Next, we derive the independent paths: Since V(G) = 4, there are four paths Path 1: 1,2,4,7,8 Path 2: 1,2,4,5,7,8 Path 3: 1,2,4,5,6,8 Path 4: 1,2,3,2,4,.….,8 Finally, we derive test cases to exercise these paths. 5 2 1 3 4 8 6 7
  • Basis Path Testing- TEST CASES Path 1: 1,2,4,7,8 N=0 , target=2 ,( A is empty ) Path 2: 1,2,4,5,7,8 N=1, target =2, A[1]= 4( any number > 2) Path 3: 1,2,4,5,6,8 N=1, target =2, A[1]= 2 Path 4: 1,2,3, 2, 4,.….,8 N=1, target =2, A[1]= 1 ( any number <2) But, more general cases are better; FALSE FALSE TRUE FALSE 5 2 1 3 4 8 6 7
  • BASIS-PATH another example ( Module: GCD )
    • Purpose: To get GCD of two non-zero positive integers
    • Input : integer X, Y
    • Precondition: 0 < X , 0 < Y
    • Output: gcd
    • Post condition: gcd = GCD ( X, Y]
    • Implementation (wrong)
    • do {
    • if X > Y
    • X = X - Y;
    • else
    • Y = Y - X;
    • } while ( X ! = Y]
    Statement coverage : (X=4, Y=3) (X=3, Y=4) Edge coverage : same BASIS-PATH DRAW Flow-Graph!! FIND independent paths CHOOSE test cases
  • Graph Matrices - a SW tool
    • Is a graphical version of flow-graph
    • May also be used for automating SW testing and code optimization.
    Weight - shows just a link available or some other measures like execution probability 2 1 3 4 1 2 3 4 1 2 3 4 from to 1 1 1 1
  • Some Other White-Box Testing Methods
    • Loop Testing
    • Condition Testing
    • Data Flow Testing
  • Loop Testing Nested Loops Concatenated Loops Unstructured Loops Simple loop © SEPA
  • Loop Testing: Simple Loops © SEPA Minimum conditions—Simple Loops 1. skip the loop entirely 2. only one pass through the loop 3. two passes through the loop 4. m passes through the loop m < n 5. (n-1), n, and (n+1) passes through the loop where n is the maximum number of allowable passes
  • Loop Testing- for module Search
    • Skip the loop
    • One pass
    • Two passes
    • m passes, m<N
    • N-1 passes
    • N passes
    • N+1 passes
    N=2, target =2 A[1]=1, A[2]=3 N=1, target =2 A[1]=4  ? Check for redundancy with already selected test cases
  • Loop Testing: Nested Loops © SEPA Start at the innermost loop. Set all outer loops to their minimum iteration parameter values. Test the min+1, typical, max-1 and max for the innermost loop, while holding the outer loops at their minimum values. Move out one loop and set it up as in step 2, holding all other loops at typical values. Continue this step until the outermost loop has been tested. If the loops are independent of one another then treat each as a simple loop else* treat as nested loops for example, the final loop counter value of loop 1 is used to initialize loop 2. Nested Loops Concatenated Loops
  • Conditional Testing
    • Focus on each logical condition
    • Conditions are usually complex
    • e.g. If ( (month==12] && (day + d > daysInMonth] ]
    • Error may be in, arithmetic expression, relational operator, boolean operator, parenthesis etc.
    • Branch testing : To test both side of a complex condition and both side of its constitutes
    • Domain testing- not feasible for complex cases
    • BRO - Branch and Relational Operator testing
  • Data-Flow Tesing
    • Track the usage of a variable from its definition
    • For each variable, determine test cases to execute along with these links
    • Coverage is not possible
  • What are we going to discuss now?
    • What is tested in Black-box testing?
    • Two important techniques used to identify suitable test cases : Equivalence Partitioning, and Boundary Value Analysis
    • In EP, input domain is divided into groups depending on pre and post conditions
    • It is found that the SW fails usually at boundary values- so test at boundary values
    • Other BB tests - Graph-based, Orthogonal, Comparison, Special cases
  • Black-Box Testing
    • To test functionality, performance and behavior of a module against its specification
    • Test cases may be developed in early stages based on specification document - logic is not necessary
    • Only indicates presence or absence of errors- needs logic for debugging
  • Black-Box Testing
    • Incorrect or missing functions are identified
    • Efficiency is measured
    • Usability is tested
    • Initialization/Termination is monitored
    • Interfacing requirements are tested
    • Data structure links are tested
    • External database access are monitored
  • Black-Box Testing Methods
    • TWO MAIN B-B METHODS
    • Equivalence Partitioning – input domain is partitioned into several classes
    • Boundary Value Analysis - Boundary values are assigned to the data elements
    • OTHER B-B METHODS
    • Orthogonal Array Testing - for small input domain
    • Graph based testing - for integrated portions
    • Comparison tests (back-to-back)- for critical systems
    • Special tests - for Real time, GUI, Client/Server, User- Guide , Help etc.
  • Equivalence Partitioning user queries mouse picks output formats prompts FK input data © SEPA
  • Sample Equivalence Classes user supplied commands responses to system prompts file names computational data physical parameters bounding values initiation values output data formatting responses to error messages graphical data (e.g., mouse picks) data outside bounds of the program physically impossible data proper value supplied in wrong place Valid data Invalid data © SEPA
  • Equivalence Partitioning { doubleDigit}
    • Partition Input domain into classes of data such that ideal test case could detect a class of errors
    • Purpose: To print all integers between 0-99 in
        • double digits
    • (example: ‘9’ printed as ‘09’ and ‘99’ printed as ‘99’ )
    • Input : integer X
    • Precondition: 0 <= X <= 99
    • Output: X printed on screen
    • Post condition: If 0<=X<=9, ‘0X’ printed o/w ‘X’
  • Equivalence Partitioning (e.g doubleDigit )
          • 0 99
    VALID INVALID INVALID d < 10 105 - 5 7 22 d > 10 leap leap
  • Equivalence Partitioning for Typical input
    • A specific value , one VALID and two INVALID
    • eg. password- 4 character string
    • VALID = all four character strings
    • INVALID1 = all three or less character strings
    • INVALID2 = all five or greater character strings
    • A specific member of a set , one VALID and one INVALID
    • eg. digit - any digit between 0 and 9
    • VALID = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
    • INVALID = set of all the other characters
  • Equivalence Partitioning for Typical input
        • A specific range , one VALID and two INVALID sets
    • eg. month - any number between 1 and 12
    • VALID = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12}
    • INVALID1 = set of all numbers less than 1
    • INVALID2 = set of all numbers greater than 12
        • A specific boolean value, one VALID and one INVALID set
    • eg. username: any valid string
    • VALID = something entered
    • INVALID = nothing given
  • Equivalence Partitioning (e.g leap )
    • module: leap
    • description: to determine whether a given year is leap
    • input : integer year
    • precondition: 1800<=year<=2200
    • output: boolean leap
    • post condition:
    • leap = ((400/year) or ( (4/year) and (100 / year))
  • Equivalence Partitioning (e.g leap )
          • 1800 2200
    VALID INVALID INVALID 400/year 2205 1750 1903 1904 1900 2000 leap leap 4 / year 4 / year but 100 / year 100/year but 400 / year
  • Equivalence Partitioning (e.g SEARCH )
        • Description : To search a ‘target’ value in an array of integers (which is in ascending order) and, if the ‘target’ is found returns 'TRUE' otherwise returns 'FALSE'.
        • input : array of integers A, integer maxInA
        • integer N (stands for the number of records in A),
        • integer target
        • Pre-condition : maxInA > N >=0,
        • A[j] <= A[j+1] for all integer j, 0 < j < N.
        • Output : boolean found
        • Post-condition :
        • ((  j, 0 < j < N+1. A[j] = target ) AND (found = TRUE) )
        • OR
        • (( V j, 0 < j < N+1. A[j] < > target ) AND (found = FALSE) )
  • Equivalence Partitioning (e.g SEARCH )
    • Three Input values
    • For N : N is an integer, N is a value but it is restricted by precondition. However it can be tested. ( N < 0 , maxInA > N >= 0 , N >= maxInA )
    • For A : A is also restricted by precondition(values of A are valid integers in ascending order)- and also it is not independent- depends on N (number of elements in the Array A)- but testing this precondition is not feasible
    • For target : It is an integer (member of a set) from post condition we may derive two cases, target in A and target not in A
    • We may get two BB test class here
    • A valid array A with the corresponding integer N with some integer value as target, where target in A and target not in A.
    • (eg. A= 4,6,8,10 N=4 and target= 7 and 8).
    • White Box test cases should be checked with BB test cases for redundancy
  • Boundary Value Analysis &quot;Bugs lurk in corners and congregate at boundaries ...&quot; Boris Beizer WHY ? - unknown Select test cases to cover all the boundary values of input and output data elements and data structures © SEPA
  • Boundary Value Analysis user queries mouse picks output formats prompts FK input data output domain input domain © SEPA
  • Boundary Value Analysis { doubleDigit }
    • Module: doubleDigit
    • Purpose: To print all integers between 0-99 in
        • double digits
    • (example: ‘9’ printed as ‘09’ and ‘99’ printed as ‘99’ )
    • Input : integer X
    • Precondition: 0 <= X <= 99
    • Output: X printed on screen
    • Post condition: If 0<=X<=9, ‘0X’ printed o/w ‘X’
    -5 0 6 9 30 99 105 -1 0 1 8 9 10 98 99 100
  • Boundary Value Analysis e.g [ SEARCH )
        • Description : To search a ‘target’ value in an array of integers (which is in ascending order) and, if the ‘target’ is found returns 'TRUE' otherwise returns 'FALSE'.
        • input : array of integers A, integer maxInA
        • integer N (stands for the number of records in A),
        • integer target
        • Pre-condition : maxInA > N >=0,
        • A[j] <= A[j+1] for all integer j, 0 < j < N.
        • Output : boolean found
        • Post-condition :
        • ((  j, 0 < j < N+1. A[j] = target ) AND (found = TRUE) )
        • OR
        • (( V j, 0 < j < N+1. A[j] < > target ) AND (found = FALSE) )
  • Boundary Value Analysis { SEARCH }
            • Input Domain
            • For N: N= 0, 1, maxInA -1, maxInA, maxInA+1
            • For target : target < A[1], = A[1], A[2], A[N-1], A[N], >A[N]
    • Data Structure:
    • For A: No elt, 1 elt, maxInA-1 elts and MaxInA elts
    • (already covered through N’s boundary values )
    • Output Domain
    • For found: found= TRUE/FALSE (target in A and not in A)
    Ex: If the SEARCH module also need to return a suitable location (say ‘pos’) for a non existing target in A, modify the specification and find suitable WB and BB test cases
  • Other Black Box Techniques
    • Orthogonal Array Testing - for small input domain
    • Graph based testing - for integrated portions
    • Comparison tests (back-to-back)- for critical systems
    • Special type of tests necessary for - for Real time, GUI, Client/Server, User- Guide , Help etc.
  • Testing is an incremental process SystemEngineering Requirement Analysis Design Coding Test Plan Unit Test Integration Test ValidationTest SystemTest plans plans System test plan. SW+HW Function performance etc. BB some GB BB GB Acceptance Test Developer Tester Developer Tester Tester User
  • Unit Testing module to be tested test cases results software engineer interface local data structures boundary conditions error handling paths global data effects independent paths loops, conditions ©SEPA
  • Unit Test Environment Module stub stub driver RESULTS test cases not stand-alone Stubs and drivers are overheads and should be small enough to throw away after their use ©SEPA
  • DRIVER- example from case-study
    • A lower level module is ready for testing!
    • A stub to test the module ‘leap’
    • void leapDriver ( ){
    • int year; cout>> ‘give year 1800 -2200’;
    • cin<< year;
    • if leap(year)
    • cout << ‘LEAP’
    • else
        • cout << ‘NOT A LEAP’;
    • }
  • STUB- example from case-study
    • A higher level module is ready for testing!
    • void processReporter( ) {
    • struct date {
    • Int day,month,year; }
    • struct time {
    • Int hour,min,sec;]
    • struct instance {
    • d : date; t : time; }
    • GetProcessDetail(instance startInst, int duration);
    • ProcessEndDetail(instance startInst, &instance endInst, int duration);
    • displayProcessReport(instance startInst, instance , endInst);
    • }
    void getProcessDetail (instance SI, int duration ) { cout >> “in the getProcessDetail”; }
  • SW Integration Strategies
    • Options:
      • • the “big bang” approach
      • • an incremental construction strategy
    • “ big bang” approach- disadvantages
      • • cannot isolate cause of an error
      • correcting an error may trigger further errors
    ©SEPA
  • Top Down Integration top module is tested with stubs stubs are replaced one at a time, &quot;depth first&quot; as new modules are integrated, some subset of tests is re-run A B C D E F G Regression test ©SEPA
  • Bottom-Up Integration drivers are replaced one at a time, &quot;depth first&quot; A B C D E F G as new modules are integrated, Regression test some subset of tests is re-run. May be automated ©SEPA
  • Cluster-based Integration Worker modules are grouped into builds and integrated A B C D E F G cluster ©SEPA
  • Integration Example- Case study processDetail ProcessReporter getProcessDetail determineEndDetail displayProcessRepor t getStartDetail getDuration addTime addDate getStartTime leap getStartDate daysInMonth processReport A cluster for validation
  • Integration Strategies- A comparison
    • In Top down integration, program may be felt as an entity at the very early stages, but In Bottom up integration, the whole program is available in the final stage
    • In Top down integration, major control structures may be tested effectively
    • In Bottom up integration, the critical lower modules may be tested effectively
    • In Cluster-based integration, if important functional modules are selected as clusters, it gives advantages of both approaches
  • High Order Testing validation test system test Acceptance tests alpha and beta test other specialized testing ©SEPA
  • Validation Testing
    • Done on fully assembled SW, but yet to integrate with other elements such as HW, DB etc.
    • already tested and corrected for logic, interface and functionality
    • Test SW based on Requirement Specification
    • - Overall functionality
      • Performance and Behavioral aspects
      • On-line help and other help facilities
      • Documentation, User-Guide sufficiency ,consistency etc.
      • Error recovery and maintainability
  • System Testing
    • Now SW is incorporated with other system elements such as HW, DB, people etc.
    • Further level of integration and validation test are to be conducted
    • Some system tests
    • Recovery Testing – fail it and recover
    • Security Testing – penetrate and attack
    • Stress Testing - demand abnormal resources
    • Performance Testing – reasonable time?
  • Acceptance Tests Developer’s site customer Alpha Test Beta Test Customer’s site ©SEPA By customers in their normal environment developer customer
  • Debugging: A Diagnostic Process ©SEPA
  • The Debugging Process test cases results Debugging suspected causes identified causes corrections regression tests new test cases ©SEPA
  • Debugging Effort time required to diagnose the symptom and determine the cause time required to correct the error and conduct regression tests ©SEPA
  • Symptoms & Causes symptom cause symptom and cause may be geographically separated symptom may disappear when another problem is fixed cause may be due to a combination of non-errors cause may be due to a system or compiler error cause may be due to assumptions that everyone believes symptom may be intermittent/irregular ©SEPA
  • Consequences of Bugs damage mild annoying disturbing serious extreme catastrophic infectious Bug Type Bug Categories: function-related bugs, system-related bugs, data bugs, coding bugs, design bugs, documentation bugs, standards violations, etc. ©SEPA
  • Debugging Techniques brute force / testing Backtracking Cause elimination by Binary partition induction deduction deduction deduction ©SEPA
  • Debugging: Final Thoughts Don't run off half-cocked, think about the symptom you're seeing. Use tools (e.g., dynamic debugger) to gain more insight. If at an impasse, get help from someone else. Be absolutely sure to conduct regression tests when you do &quot;fix&quot; the bug. 1. 2. 3. 4. ©SEPA
  • Object Oriented Testing
    • OOTesting begins at OOAnalysis stage
    • Minimum Testable Component is a CLASS, not modules. Unit Testing is a Class Testing
    • Integrating CLASSES- use based, cluster based (why not Top and Bottom integration?]
    • Validity Testing- based on use cases
    • Class level testing - Partition, Random
    • Inter-Class testing - Random, Scenario
  • Why wait until classes are coded?
    • When can OOTesting begin?
    OOTesting begins by Evaluating OOAnalysis and OODesign models Seamless transition- everything is class and requests Analysis level model ==> Design level model ==> code Class1 Class2 request1 Class1 Class2 request1 Class1 Class2 request1
  • public class Date { private int day, month, year; public Date( ) { day=0; month=0;year=0; } public Date(int day, int month, int year) { this.day = day; this.month = month; this.year = year; } public boolean leap( ) { // should change to private return ((year % 400 == 0)|| ((year % 100 > 0) && (year % 4 ==0))); } } public class Instance { private Date date; private Time time; public Instance(Date date, Time time){ this.date = date; this.time = time; } public void getInstance() { date.getDate(); time.getTime(); } } getDate( ) Date day month year getDate( ) displDate( ) addDate( ) dInMonth( ) leap( ) Instance date time getInstance( ) displInstance( ) addInstance( ) Date Day : integer month : integer year : integer getDate( ) displDate( ) addDate(d: integer, nD:Date) -dInMonth( ) -leap( ) Instance date:Date time:Time getInstance( ) displInstance( ) addInstance( )
  • Minimum testable component is a class
    • A module alone of a class is meaningless. It has meaning only as an operation of an encapsulated object.
    • If leap(year) -->
    • The function call leap(year] is meaningless in OO.
    • Date StartDate(10,12,2000];
    • if StartDate.leap( ) // not possible, if ‘leap’ is private
        • System.out.println (“‘Leap”];
        • Encapsulation may give trouble while testing
    Unit Testing is Class Testing in OO
    • public class Date {
    • private int day, month, year;
    • public Date( ) {
    • day=0; month=0;year=0;
    • }
    • public Date(int day, int month, int year) {
    • this.day = day; this.month = month; this.year = year;
    • }
    • public boolean leap( ) { // should change it to private
    • return ((year % 400 == 0)||
    • ((year % 100 > 0) && (year % 4 ==0)));
    • }
    BlueJ - Java implementation Minimum testable component is a class
  • Integrating Classes
    • Classes are connected like a network, not hierarchical as in a structure chart
    • Top / Bottom classes are meaningless, so does the Top down/Bottom up integration
    • Classes are integrated according to
    • the usage scenario - use based OR
    • collaboration - cluster based
  • Structure Chart: hierarchical Class Collaborations: network ProcessReporter getProcessDetail getStartDetail getDuration getStartTime getStartDate Process: Instance:Start Date:Start Time:Start 1.disInst( ) 2. disDate( ) 6. addDate( ) 3.disTime( ) 4. addTime( ) Instance:End 8.Instance( ) Date:End Time:End 9. disDate( ) 10. disTime( ) 5. Time( )
  • Use Based Integration
    • Inspect sequence diagrams- independent classes are coded and tested first.
    • Then the classes that send requests only to those independent classes are integrated
    • Continue until you get the final integration
    • In Case Study
    • start with, Time and Date
    • then Instance and Process etc.
  • CASE STUDY - SEQUENCE DIAGRAM
  • Cluster Based Integration
    • Start with an important collaboration diagram- classes necessary for the collaboration are coded and tested first.
    • Then another collaboration is automated
    • Continue until you get the final integration
    • In Case-Study
    • Major collaboration is ‘addInst’ ,
    • again start with Date and Time then
    • complete Instance
  • Cluster : A group of classes that collaborate to perform a particular request Start with receiver classes Instance:Start Date:Start Time:Start 1. addInst( ) 4. addDate( ) 2. addTime( ) Instance:End 8.Instance( ) Date:End Time:End 10. disDate( ) 9. disTime( ) 7. Date( ) 3. Time( ) 5. dInMon( ) 6. leap( )
  • Unit Testing - Class Level Testing
    • Operations within a class is tested
    • State behavior of the class is tested
    • There are three important methods
      • Random Testing
      • Scenario based Testing
      • Partition testing (attribute
  • Partition Testing
    • Reduces the number of test cases required to test a class [ in much the same way as equivalence partitioning for conventional software]
      • state-based partitioning
        • based on their ability to change the state of a class
      • attribute-based partitioning
        • based on the attributes that they use
      • category-based partitioning
        • based on the generic function each performs
    One representative for each partition
  • State-Based Partitioning
    • TWO Partitions
    • Operations that can change the state
    • that cannot change the state
    • Test sequences are designed for each
    • Partitions
    • Example for first case
    • < open, setup, deposit, withdraw, deposit , close >
    • Example for second case
    • < Open, setup, viewBalance, viewLimit , close >
    number limit balance open( ) setup( ) close( ) viewbalance( ) viewLimit( ) deposit( ) withdraw( ) Account
  • Attribute -Based Partitioning
    • For each attribute THREE Partitions
    • Operations that use it
    • that modify it
    • that do not use it
    • Example: for the attribute ‘balance’
    • viewBalance( ) uses it
    • deposit( ) modifies it
    • viewLimit( ) does not use it
    number limit balance open( ) setup( ) close( ) viewbalance( ) viewLimit( ) deposit( ) withdraw( ) Account
  • Category - Based Partitioning
    • Many Partitions depend on the type of operations
    • that used for initialization (open, setup)
    • that used for termination (close)
    • that used for query (viewBalance)
    • that used for computation (withDraw)
    • etc
    number limit balance open( ) setup( ) close( ) viewbalance( ) viewLimit( ) deposit( ) withdraw( ) Account
  • Random Testing - Class Level
    • Identify operations applicable to a class
    • Define constraints on their use
    • Identify a minimum test sequence
      • an operation sequence that defines the minimum life history of the class
      • e.g < open, setup, deposit, withdraw, close >
      • generate a variety of random (but valid) test sequence
      • < open, setup, deposit, withdraw, - - - , close >
    • Look for more complex life histories
  • Scenario Based Testing
    • Based on use cases create user interaction scenarios
    • Black Box test cases created for this interaction
    • Final SW is same for all (conventional or OO)
    • Used in Validity Testing extensively