13-Testing-1
Upcoming SlideShare
Loading in...5
×
 

13-Testing-1

on

  • 3,101 views

 

Statistics

Views

Total Views
3,101
Slideshare-icon Views on SlideShare
3,100
Embed Views
1

Actions

Likes
0
Downloads
216
Comments
0

1 Embed 1

http://www.slideshare.net 1

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

    13-Testing-1 13-Testing-1 Presentation Transcript

    • Testing—Part 1 Lecture #13 Software Engineering and Project Management Instructed by Steven Choy on Jan 29, 2007
    • Software Testing Overview
    • What’s your view on Testing?
      • Testing is dirty work
      • Testing is boring (so, boring tutorial too?)
      • Testing is non-technical
      • Testing is tedious
      • Testing is for those less-talented developers
    • But the fact is …
      • Testing is a creative, systematic kind of work
      • Highly talented people are required to work on testing
      • Highly skilled programmers develop innovative test tools and strategies (e.g. JUnit and Test-Driven Development)
    • What’s our target for Testing? Expected System = Actual System Are the expected behaviour (specified in requirement specification and system models) the same as the observed behaviour of the actual system? ?
    • So … what qualities do we measure?
      • Correctness
      • Reliability
      • Robustness
      • Security
      • Performance
      • Usability
      Non-functional Requirements Functional Requirements
    • Strategies for Improving Software Qualities
      • Detective Approach (Our Focus)
        • Find out the potential bugs and fix it
        • Testing & Debugging
      • Preventive Approach
        • Avoid the bug to come out
          • An well-established development methodologies such as design & code review, configuration management
          • Use well-practiced design such as design pattern
      • Recovery Approach
        • Admit it’s impossible to test the system completely that there may be faults in the system
        • But even the system fails, it can recover itself at runtime without affecting the user
    • Test Development Lifecycle
    • How do you do the Testing?
    • Test Development Lifecycle Test Planning Unit Test Integration Test Performance Test Acceptance Test Functional Test Alpha Test Installation Test Beta Test Developer Client End User Usability Test
    • Testing Activities
      • Component Inspection
        • Discover fault by code review
        • Carried out during design/coding stage
      • Test Planning (Plan what to test)
        • What features to be tested
        • What features not to be tested
        • The Test Approach
        • The Test Deliverable
        • The Test Schedule and Resource Allocation
      • Usability Testing
        • Test users’ understanding of the system
        • Usually performed during product prototype stage by client/end-user
    • Testing Activities…
      • Unit Testing
        • Focus testing on unit level (e.g. object & subsystem)
      • Integration Testing
        • Perform tests on a group of components/subsystems
      • System Testing
        • Functional Testing
        • Performance Testing
        • Pilot Testing
        • Acceptance Testing
    • Tested Subsystem Subsystem Code Functional Integration Unit Tested Subsystem Requirements Analysis Document System Design Document Tested Subsystem Test Test T est Unit T est Unit T est User Manual Requirements Analysis Document Subsystem Code Subsystem Code All tests by developer Functioning System Integrated Subsystems
    • Global Requirements User’s understanding Tests by developer Performance Acceptance Client’s Understanding of Requirements Test Functioning System Test Installation User Environment Test System in Use Usable System Validated System Accepted System Tests (?) by user Tests by client
    • Fault Handling Techniques Testing Fault Handling Fault Avoidance Fault Tolerance Fault Detection Debugging Unit Testing Integration Testing System Testing Verification Configuration Management Atomic Transactions Modular Redundancy Correctness Debugging Performance Debugging Reviews Design Methodology
    • Quality Assurance encompasses Testing Usability Testing Quality Assurance Testing Prototype Testing Scenario Testing Product Testing Fault Avoidance Fault Tolerance Fault Detection Debugging Unit Testing Integration Testing System Testing Verification Configuration Management Atomic Transactions Modular Redundancy Correctness Debugging Performance Debugging Reviews Walkthrough Inspection
    • Testing Vocabulary
      • Component
        • An object, groups of objects or subsystem that can be isolated for testing
      • Fault / Bug / Defect
        • A design or coding mistake that contributes to the failure of a component
      • Failure
        • Deviation of the observed behaviour from the specified/expected behaviour
      • Test Case
        • Detailed instructions (with a set of input data & expected results) on exercising a component with the purpose to detecting faults
    • Developing Test Case
      • We develop test case to exercise a component with the purpose of causing failures and detecting faults
      • A test case normally includes:
        • Name
        • Component/Feature to be tested
        • Detailed test procedures
        • Input Data
        • Pass/Fail Criteria, Expected Result
    • Unit Testing
    • Unit Testing
      • Focus on components (i.e. objects/subsystem) testing, rather than the whole system
      • Responsible by developer (usually by the developer who actually write the component)
      • Why Unit Testing?
        • Reduce complexity of testing
        • Ease to locate faults/bugs in a specific component
      • Current Development Trend
        • Automated Unit Testing e.g. JUnit Framework
          • Encourage developers to write test
          • Make testing fun!
    • Test Stubs & Driver
      • Test Stub
        • A partial implementation of components on which the tested component depends
        • A stub consists of interfaces that are identical to the actual component but with simpler implementation (It can be as simple as a return statement)
      • Test Driver
        • Simulates the part of the system that controls (drives) the component under test
        • Passes in the test inputs to the component under test and displays the result
    • Test Stub & Driver in Action
      • If you are the developer of the Login component, how do you unit-test it?
      UI Component Login Component Data Access Component UI Layer Business Layer Database Layer call login() call getPassword()
    • Example of Login Component
      • class LoginComponent {
      • public boolean login(String userId, String password) {
      • DataAccessComponent dac = new DataAccessComponent();
      • String originPassword = dac.getPassword(userId);
      • if (password.equals(originPassword)) {
      • return true;
      • } else {
      • return false;
      • }
      • }
      • }
    • Test Driver & Stub Samples
      • class TestDriver {
      • public static void main(String[] args) {
      • LoginComponent lc = new LoginComponent();
      • boolean result = lc.login("tester", "1234");
      • System.out.println("Login result: " + result);
      • }
      • }
      • class DataAccessComponent {
      • public String getPassword(String userId) {
      • return "1234";
      • }
      • }
    • Test Stub & Driver in Action
      • We develop a Test Driver to invoke the Login component
      • As the Data Access Component is not in place, we develop a Test Stub to emulate the function it provides (Only those functions that Login Component needs during testing)
      Test Driver Login Component Test Stub UI Layer Business Layer Database Layer call login() call getPassword()
    • Black-box Testing
      • Test how well the code meets the requirement
      • Know nothing about the internal logic of the component/module (Treat it as a Blackbox )
      • Focus on the input/output behaviour
      Module Feed in input Observe output We focus on: Is the output the same as what we expected?
    • White-box Testing
      • Performed to reveal the internal structure of a program
      • Covers every statement of the component (Each statement is executed once)
      • Derive test cases from the code
      • Types of white-box testing:
        • Statement Testing
        • Loop Testing
        • Path Testing
        • Branch Testing
    • /*Read in and sum the scores*/ FindMean(float Mean, FILE ScoreFile) { SumOfScores = 0.0; NumberOfScores = 0; Mean = 0; Read(Scor eFile, Score); while (! EOF(ScoreFile) { if ( Score > 0.0 ) { SumOfScores = SumOfScores + Score; NumberOfScores++; } Read(ScoreFile, Score); } /* Compute the mean and print the result */ if (NumberOfScores > 0 ) { Mean = SumOfScores/NumberOfScores; printf("The mean score is %f ", Mean); } else printf("No scores found in file "); }
      • FindMean (FILE ScoreFile)
      • { float SumOfScores = 0.0;
        • int NumberOfScores = 0;
        • float Mean=0.0; float Score;
        • Read(ScoreFile, Score);
        • while (! EOF(ScoreFile) {
          • if (Score > 0.0 ) {
              • SumOfScores = SumOfScores + Score;
              • NumberOfScores++;
              • }
          • Read(ScoreFile, Score);
        • }
        • /* Compute the mean and print the result */
        • if (NumberOfScores > 0) {
            • Mean = SumOfScores / NumberOfScores;
            • printf(“ The mean score is %f ”, Mean);
        • } else
            • printf (“No scores found in file ”);
      • }
      1 2 3 4 5 7 6 8 9
    • Constructing the Logic Flow Diagram
    • Finding the Test Cases Start 2 3 4 5 6 7 8 9 Exit 1 b d e g f i j h c k l a (Covered by any data) (Data set must (Data set must contain at least one value) be empty) (Total score > 0.0) (Total score < 0.0) (Positive score) (Negative score) (Reached if either f or e is reached)
    • Comparison of White & Black-box Testing
      • White-box Testing:
        • Potentially infinite number of paths have to be tested
        • White-box testing often tests what is done, instead of what should be done
        • Cannot detect missing use cases
      • Black-box Testing:
        • Potential combinatorical explosion of test cases (valid & invalid data)
        • Often not clear whether the selected test cases uncover a particular error
        • Does not discover extraneous use cases (&quot;features&quot;)
      • Both types of testing are needed
      • White-box testing and black box testing are the extreme ends of a testing continuum.
      • Any choice of test case lies in between and depends on the following:
        • Number of possible logical paths
        • Nature of input data
        • Amount of computation
        • Complexity of algorithms and data structures
    • Integration Testing
    • Integration Testing
      • Focus on testing groups of components
      • Two or more components are integrated for testing. When they are tested okay, more components are added for testing
      • Test Strategies:
        • Big Bang Testing
        • Bottom-up Testing
        • Top-down Testing
    • Integration Test Strategies
      • Big-bang Testing
        • After each component are tested individually, all components are then tested together as a single system
    • Integration Test Strategies
      • Bottom-up Testing
        • Designed for layered system
        • The bottom layer is tested first, and then integrates with components of the next layer up
        • Repeat until all layers are combined and tested
        • Test Drivers are needed to do the testing
          • A routine that calls a subsystem and passes a test case to it
    • Integration Test Strategies
      • Top-down Testing
        • A reversed of Bottom-up Testing
        • The components of top layer is tested first, then integrates with components of the next layer down
        • Repeat until all layers are tested
        • Test stub is needed to do the testing
          • A program or a method that simulates the activity of a missing subsystem by answering to the calling sequence of the calling subsystem and returning back fake data.
    • Example: Three Layer Call Hierarchy A B C D G F E Layer I Layer II Layer III
    • Big-Bang Approach Unit Test F Unit Test E Unit Test D Unit Test C Unit Test B Unit Test A System Test
    • Bottom-up Integration Test F Test E Test G Test C A B C D G F E Layer I Layer II Layer III Test D,G Test B, E, F Test A, B, C, D, E, F, G
    • Pros and Cons of bottom up integration testing
      • Bad for functionally decomposed systems:
        • Tests the most important subsystem (UI) last
      • Useful for integrating the following systems
        • Object-oriented systems
        • real-time systems
        • systems with strict performance requirements
    • Top-down Integration Testing Test A Layer I A B C D G F E Layer I Layer II Layer III Test A, B, C, D Layer I + II Test A, B, C, D, E, F, G All Layers
    • Pros and Cons of top-down integration testing
      • Test cases can be defined in terms of the functionality of the system (functional requirements)
      • Writing stubs can be difficult: Stubs must allow all possible conditions to be tested.
      • Possibly a very large number of stubs may be required, especially if the lowest level of the system contains many methods.
      • One solution to avoid too many stubs: Modified top-down testing strategy
        • Test each layer of the system decomposition individually before merging the layers
        • Disadvantage of modified top-down testing: Both, stubs and drivers are needed
    • Sandwich Testing Strategy
      • Combines top-down strategy with bottom-up strategy
      • The system is view as having three layers
        • A target layer in the middle
        • A layer above the target
        • A layer below the target
        • Testing converges at the target layer
      • How do you select the target layer if there are more than 3 layers?
        • Heuristic: Try to minimize the number of stubs and drivers
    • Sandwich Testing Strategy
      • Test in parallel:
        • Middle layer with drivers and stubs
        • Top layer with stubs
        • Bottom layer with drivers
      • Test in parallel:
        • Top layer accessing middle layer (top layer replaces drivers)
        • Bottom accessed by middle layer (bottom layer replaces stubs)
    • Modified Sandwich Testing Strategy A B C D G F E Layer I Layer II Layer III Test F Test E Test B Test G Test D Test A Test C Test B, E, F Triple Test I Triple Test I Test D,G Double Test II Double Test II Double Test I Double Test I Test A,C Test A, B, C, D, E, F, G
    • To be continue…
      • System Testing
      • Regression Testing
      • Automate Unit Testing
      • Document Your Testing
      • Acknowledgement
      • Part of the slides
      • were originally authored
      • by Simon Ng .