1 / 64

Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 11

Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 11. Review of Last Lecture. Implementing a Statechart Review of Java programming concepts Inheritance Polymorphism Type Casting Interface. Overview of This Lecture. Software Testing Overview Test Phases Unit Testing

jola
Télécharger la présentation

Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 11

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 11 CPSC-4360-01, CPSC-5360-01, Lecture 11

  2. Review of Last Lecture • Implementing a Statechart • Review of Java programming concepts • Inheritance • Polymorphism • Type Casting • Interface CPSC-4360-01, CPSC-5360-01, Lecture 11

  3. Overview of This Lecture • Software Testing • Overview • Test Phases • Unit Testing • Integration Testing • OO Specific Testing • Automated Test Driver • Overview • Example CPSC-4360-01, CPSC-5360-01, Lecture 11

  4. Requirement Analysis Design Implement Test Where are we now? • Evaluating the System CPSC-4360-01, CPSC-5360-01, Lecture 11

  5. Testing – Famous Quotes • “Testing is the process of comparing the invisible to the ambiguous, so as to avoid the unthinkable happening to the anonymous.”, James Bach • "Testing is organised skepticism.“, James Bach • "Program testing can be used to show the presence of bugs, but never to show their absence!“, Edgar Dijkstra • "Beware of bugs in the above code; I have only proved it correct, not tried it.“, Donald Knuth CPSC-4360-01, CPSC-5360-01, Lecture 11

  6. Testing: Definitions • “Testing is the process of establishing confidence that a program or system does what it is supposed to.” • “Testing is the process of executing a program or system with the intent of finding errors.” • “Testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results.” CPSC-4360-01, CPSC-5360-01, Lecture 11

  7. Testing: Overview • A software test process is based on well-defined software quality control and testing standards, testing methods, strategy, test criteria, and tools. • Engineers perform all types of software testing activities to perform a software test process. • The last quality checking point for software is on its production line. CPSC-4360-01, CPSC-5360-01, Lecture 11

  8. Testing: Objectives • Uncover as many errors (or bugs) as possible in a given time. • Demonstrate that a given software product matches its requirement specifications. • Generate high quality test cases, perform effective tests, and issue correct and helpful problem reports. CPSC-4360-01, CPSC-5360-01, Lecture 11

  9. Testing: Objectives • Uncover the errors (defects) in the software, including errors in: • requirements from requirement analysis. • design documented in design specifications. • coding (implementation). • system resources and system environment. • hardware problems and their interfaces to software. CPSC-4360-01, CPSC-5360-01, Lecture 11

  10. Testing: Personnel • Test Manager: • Manage, supervise, and control a software test project. • Define and specify a test plan. • Software Test Engineers and Testers: • Define test cases, write test specifications, run tests. • Development Engineers: • Only perform unit tests and integration tests. • Quality Assurance Group and Engineers: • Perform system testing. • Define software testing standards and quality control process. • Independent Test Group. CPSC-4360-01, CPSC-5360-01, Lecture 11

  11. Testing: Activities • Test Planning: • a test schedule for a test process and its activities, as well as assignments. • test requirements and items. • test strategy and supporting tools. • Test Design and Specification: • conduct software design based on well-defined test generation methods. • specify test cases to achieve a targeted test coverage. CPSC-4360-01, CPSC-5360-01, Lecture 11

  12. Testing: Activities • Test Set up: • Testing Tools and Environment Set-up. • Test Suite Set-up. • Test Operation and Execution: • Run test cases manually or automatically. • Test Result Analysis and Reporting: • Report software testing results and conduct test result analysis. • Problem Reporting: • Report program errors using a systematic solution. CPSC-4360-01, CPSC-5360-01, Lecture 11

  13. Testing: Activities • Test Management and Measurement: • Manage software testing activities, control testing schedule, measure testing complexity and cost. • Test Automation: • Define and develop software test tools. • Adopt and use software test tools. • Write software test scripts. • Test Configuration Management: • Manage and maintain different versions of software test suites, test environment and tools, and documents for various product versions. CPSC-4360-01, CPSC-5360-01, Lecture 11

  14. TestCases TestResults Specification Design Error Repair PerformTest LocateError RepairError retest Testing: Cycle of Activities • Testing usually involves repetition of testing activities. • Example: CPSC-4360-01, CPSC-5360-01, Lecture 11

  15. Test Organization • In a large software system, testing has to be carried out in multiple stages. • The test stages are linked to the various software development stages. • Example: • The Acceptance Test is linked to the Requirement and the Specification stages. • Also known as the V-Model, it refers to the next slide to see the alphabet ‘V’ in the diagram. CPSC-4360-01, CPSC-5360-01, Lecture 11

  16. Testing Organization (V-Model) Requirements specification UserSpecification Acceptance Testing Produce Validate System Specification SystemSpecification System Testing Produce Validate System Design ModuleSpecification IntegrationTesting Produce Validate Module Design SoftwareSpecification UnitTesting Validate Produce Coding CPSC-4360-01, CPSC-5360-01, Lecture 11

  17. Test Stage: Unit Test • Testing individual modules: • Methods or Functions. • Classes. • Sometimes class clusters. • It is based on the information about the structure of a code fragment. • Carried out by the Development Engineer. • The objective is to test that the unit performs the function for which it is designed. • Unit tests can be designed before coding begins, or just after the source code is generated. CPSC-4360-01, CPSC-5360-01, Lecture 11

  18. Unit Test: Check List • Interface: • To ensure information properly flows in and out. • Data structure: • To ensure the stored data maintains integrity. • Boundary conditions: • Module operates properly at boundaries. • Independent paths: • All paths through the control structure are exercised. • Error handling paths: • paths that handle errors are exercised. CPSC-4360-01, CPSC-5360-01, Lecture 11

  19. Unit Test: Test Setup • Test case: • Test data; should be coupled with expected results. • Often lists Test identifier; Test objectives; Test resources; Test procedure. • Driver: • A module that has the test case data, passes it to component under testing, and logs the results. • Stub: • A dummy module that is called by the component under testing. CPSC-4360-01, CPSC-5360-01, Lecture 11

  20. Example (Stub) Module A Stub B Stub C Stub D Module A Call Stub B Call Stub C Call Stub D Module Under Test Stub B Print “in B” Return Stub C Print “in C” Return Stub D Print “in D” Return Temporary Implementation CPSC-4360-01, CPSC-5360-01, Lecture 11

  21. Generating Unit Test Cases • Statement coverage. • Graph based: • Branch coverage. • Condition coverage. • Path coverage. • These are also applicable to testing methods within a class. CPSC-4360-01, CPSC-5360-01, Lecture 11

  22. Unit Testing: Object Oriented Code • Class level testing: • Operations in the class are smallest testable units. • Testing single operation in isolation is difficult. • Unit test is generally driven by structure of methods of the class and the state behavior of class. • Recall - the state-transition model and the state of an object. CPSC-4360-01, CPSC-5360-01, Lecture 11

  23. Unit Testing: Object Oriented Code • A public method in a class can be tested using a black-box approach. • Start from the specification - class interface. • Consider each parameter in the method signature, and identify its possible data range(s): • Equivalence Classes - a black box test approach. • Incorporate pre-conditions and post-conditions in the test of a method. • Test exceptions. • For complex logic, also use white-box testing or static testing. CPSC-4360-01, CPSC-5360-01, Lecture 11

  24. Unit Testing: Object Oriented Code • For private methods, • either modify the class (temporarily) so that it can be tested externally: • change the access to public. • or incorporate a test driver within the class. • or use static test methods, such as program tracing. CPSC-4360-01, CPSC-5360-01, Lecture 11

  25. Using Statechart • Create test cases corresponding to each transition path that represent a full object life cycle. • Make sure each transition is exercised at least once. CPSC-4360-01, CPSC-5360-01, Lecture 11

  26. deposit [amt < -bal]/bal += amt statechart Example (Account from Lecture 10) CPSC-4360-01, CPSC-5360-01, Lecture 11

  27. Example (cont) • Possible Test Cases: • init, deposit(500), withdraw(500): • Should be in InCredit state. • init, deposit(10), withdraw(20), deposit(5): • Should be in OverDrawn state. • init, deposit(10), withDraw(20), deposit(50), suspend(), unsuspend(): • Should be in InCredit state. • The above test cases exercised each transition at least once. CPSC-4360-01, CPSC-5360-01, Lecture 11

  28. Test Stage: Integration Testing • The entire system is viewed as a collection of subsystems (sets of classes) determined during the system and object design. • The order in which the subsystems are selected for testing and integration determines the testing strategy. • It is carried out by the Development Engineer. • A test that leads to construction of the complete software architecture. CPSC-4360-01, CPSC-5360-01, Lecture 11

  29. Integration Testing • Big bang integration: • all components together. • Bottom up integration: • from lower levels. • no test stubs needed. • Top down integration: • from higher levels. • no test drivers needed. • Sandwich testing: • combination of bottom-up and top-down. • top layer with stubs and bottom layer with drivers. CPSC-4360-01, CPSC-5360-01, Lecture 11

  30. A Layer I D C B Layer II G F E Layer III Example CPSC-4360-01, CPSC-5360-01, Lecture 11

  31. General Observations • Low level components usually perform more common tasks: • Input/Output. • Repetitive calculations. • Object Oriented: usually entity classes. • High level components usually direct the system activities: • Controller. • Summary on functionality: • Low Level : More specific (Utility Modules). • High Level: More general (Controller Modules). CPSC-4360-01, CPSC-5360-01, Lecture 11

  32. System Test Big-Bang Integration Unit Test A Unit Test B Unit Test C Unit Test D Unit Test E Unit Test F Unit Test G CPSC-4360-01, CPSC-5360-01, Lecture 11

  33. A Layer I D C B Layer II G F E Layer III Test B, E, F Test A, B, C, D, E, F, G Test D,G Bottom-Up Integration Test E Test F Test C Test G CPSC-4360-01, CPSC-5360-01, Lecture 11

  34. A Layer I D C B Layer II G F E Layer III Test A, B, C, D Top-Down Integration Test A, B, C, D, E, F, G Test A Layer I Layer I + II All Layers CPSC-4360-01, CPSC-5360-01, Lecture 11

  35. A Layer I D C B Layer II G F E Layer III Sandwich Integration Test B Test E Test B, E, F Test F Test A, B, C, D, E, F, G Test D Test D,G Test G Test A,C Test A CPSC-4360-01, CPSC-5360-01, Lecture 11

  36. Sandwich Integration • Combination of Top-Down and Bottom-Up approaches. • Select a target level (e.g., Layer II in slide 35): • For level above the target level, perform Top-Down integration. • For level below the target level, perform Bottom-Up Integration. • Exercise both Controller modules and Utility modules at the same time. CPSC-4360-01, CPSC-5360-01, Lecture 11

  37. Integration Test: Object Oriented Code • Class Clusters: • Classes that are tightly coupled are good candidates for an increment integration. • Candidate class clusters: • Classes in a package. • Classes in a class hierarchy. • Classes associated with the interaction diagram for a use case. • Use based testing: • group the classes – independent / dependent. • Begin by testing independent classes. • Then, test dependent classes which use independent classes. CPSC-4360-01, CPSC-5360-01, Lecture 11

  38. Class Cluster: Using Interaction Diagram :UI :Controller :X :Y request(r) methodX() methodY() Method to test: request ( ) Input: r Expected output: a report with specific information. report CPSC-4360-01, CPSC-5360-01, Lecture 11

  39. Class Cluster: Using Use Cases • ATM: Use Cases: • Withdraw Money. • Deposit funds. • Transfer funds. • Change PIN. Actor: • Bank customer. WithdrawMoney DepositFunds Bank Customer TransferFunds Change PIN Use Case Diagram CPSC-4360-01, CPSC-5360-01, Lecture 11

  40. Summary for Object Oriented Testing Use CaseAnalysis Use Case Testing Integration Testing Cluster Testing Class Design Class Testing Unit Testing Method Design Method Testing Method Coding CPSC-4360-01, CPSC-5360-01, Lecture 11

  41. Test Stage: System Testing • Performed exclusively in terms of inputs and outputs of the system. • Performed mostly on the target platform. • Thread-based: • The behavior that results from a system level input. • An interleaved sequence of system inputs (stimuli) and outputs (responses). • Depicts a possible scenario of using the system. CPSC-4360-01, CPSC-5360-01, Lecture 11

  42. Test Stage: Testing that Involves Users • Alpha testing: • In-house testing. • By a test team or end users. • Beta testing: • By users or selected subset of actual customers in a normal work environment. • Product is very close to completion. • Open beta release: Let public carry out the beta testing. • Acceptance testing: • By users to check that system satisfies requirements to decide whether to accept the system based on the test result. CPSC-4360-01, CPSC-5360-01, Lecture 11

  43. Test Case Design: Overview • Black box versus White box approach: • Black box testing: • Knowing the specified function a component has been designed for. • Tests conducted at the interface of the component. • White box testing: • Knowing the internal workings of a component. • Test cases exercise specific sets of condition, loops, etc. CPSC-4360-01, CPSC-5360-01, Lecture 11

  44. Test Case Design: Overview • Another way to classify the test cases: • Test to specifications: • Also known as black-box, data-driven, functional, or input/output driven testing. • Ignore the code — use the specifications to select test cases. • Test to code: • Also known as glass-box, logic-driven, structured, or path-oriented testing. • Ignore the specifications — use the code to select test cases. • Neither exhaustive testing to specifications nor exhaustive testing to code is feasible. CPSC-4360-01, CPSC-5360-01, Lecture 11

  45. Project: Test Phase CPSC-4360-01, CPSC-5360-01, Lecture 11

  46. Requirements for Test Phase • Automated Test Driver: • Read test cases from a file. • Put them through the system. • Capture and validate output. • Test Case Documentation: • Based on Use Cases (Black Box). • Three Tests per Use Case: • One Valid, Two Invalid. • Validity should be based on functionality. CPSC-4360-01, CPSC-5360-01, Lecture 11

  47. Automated Test Driver • In essence, an Automated Test Driver replaces the Boundary Classes in your system: • Read directly from a file instead of reading input from an actual user. • Get output directly from the system and place them into a file instead of showing on screen. Input File ApplicationLayer AutomatedTestDriver Output File CPSC-4360-01, CPSC-5360-01, Lecture 11

  48. Automated Test Driver: Input File • The input file: • Text base: Facilitate modification of test cases. • Contains a number of test cases. • Each of the test cases contains: • The method to be tested. • Parameter(s) for the method. • The expected output. • Comments (optional). CPSC-4360-01, CPSC-5360-01, Lecture 11

  49. Automated Test Driver: Output File • The output file: • Text base: Easy for human inspection. • Test case result. • Each test case result contains: • Output of method (if any). • Common Categories of Test Result: • Pass: Test result == Expected result. • Failed: Test result != Expected result. • Human Check: For more complicated cases where the expected result is hard/impossible to be defined. CPSC-4360-01, CPSC-5360-01, Lecture 11

  50. Test Case Design • The Automated Test Driver can be used to test in different test phases: • Unit Testing. • Integration Testing. • Etc. • For your project, test cases should be derived from Use Cases. CPSC-4360-01, CPSC-5360-01, Lecture 11

More Related