Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Software Testing and Quality Assurance Lecture 21 – Class Testing Basics (Chapter 5, A Practical Guide to Testing Object- Oriented Software)

Similar presentations


Presentation on theme: "1 Software Testing and Quality Assurance Lecture 21 – Class Testing Basics (Chapter 5, A Practical Guide to Testing Object- Oriented Software)"— Presentation transcript:

1 1 Software Testing and Quality Assurance Lecture 21 – Class Testing Basics (Chapter 5, A Practical Guide to Testing Object- Oriented Software)

2 2 Lecture Outline Dimensions of Class Testing Construction of Test Cases Adequacy of Test Suites for a Class

3 3 Class testing: dimensions of class testing (cont...) Who — developer What — code implements the specification exactly When — A test plan should be developed soon after the specification of the class is ready for coding

4 4 Class testing: dimensions of class testing (cont...) Class testing should be done prior to its use in other portion of the software Regression class testing should be performed whenever the class implementation is changed

5 5 Class testing: dimensions of class testing (cont...) How — develop a test driver that creates instances of the class and sets up a suitable environment around these instances to run a test case How much — Test operations and state transitions in all sorts of combinations Exhaustive or selective with combination with risk analysis.

6 6 Constructing test cases Possible ways for identifying test cases Class specification Pre- and post-conditions (OCL) State transition diagram Class implementation

7 7 Constructing test cases Test case construction from Pre- and Post-conditions Programming style: defensive vs. contract Steps in generating test cases from Pre- and Post-conditions Identify a list of pre-condition contributions Identify a list of post-condition contributions

8 8 Constructing test cases Form test case requirements by making all possible combinations of entries from the contributions lists Eliminate any conditions generated that are not meaningful For example, a precondition, say (color = red) or (color = blue) will generate a test case in which (color = red) and (color = blue), which cannot satisfied.

9 9 Constructing test cases Test case construction from state transition diagram: Each transition on the diagram represents a requirement for one or more test cases When testing based on state transition diagrams, make sure you investigate the boundaries and results of each transitions

10 10 Constructing test cases: adequacy of test suites for a class Common ways used measures of adequacy: State-based coverage: how many of the transitions in a state transition diagram are covered by the test suite. Constraint-based coverage: how many pairs of pre- and postconditions have been covered. Code-based coverage: how much of the code that implements the class is executed across all test cases in the suite.

11 11 Constructing test cases Boundary conditions: Boundary is the input value on which a large change occurs and must be identified when test cases are identified. Example: sorting an array the boundary values can be An array with zero elements An array with one element An array with two elements An array with many elements

12 12 Constructing test cases We need implementation-based testing, test cases derived from the specifications may not be enough: Example: the size of the array is used to choose the sorting algorithm for sorting an array

13 13 Constructing a test driver A test driver is a program that runs test cases and collects the results. Two approaches to build a test driver Embed the testing into the class under test itself Implement a separate class Keep relationship between CUT and its tester class through name, like a tester for Velocity class as VelocityTester.

14 14 Constructing a test driver: test driver requirements Test driver should have relatively simple design. Test driver must be easy to maintain and adapt in response to changes. Test driver should be reusable to create new drivers.

15 15 Constructing a test driver: test driver requirements (cont...) A class model for requirements for a tester class: Public interface Tester is an abstract class.

16 16 Constructing a test driver: test driver requirements (cont...) Test case suites: Functional (specification-based)— if derived from specification. Structural (implementation-based)— if identified from code. Interaction — if derived from sequence of events on an object such as pairs of input/output transitions.

17 17 Constructing a test driver: tester class design Tester class example

18 18 Constructing a test driver The main responsibility of the tester class is to run test cases and report results. Test case methods: one method per test case or group of closely related test cases: Execute a test case by creating the input state, generating a sequence of events, and checking the output state. Provide traceability to the test plan.

19 19 Constructing a test driver (cont...) Baseline testing: a baseline test suite is a set of test cases that tests the operations of the CUT that are needed for the other test cases to verify their outcome. This suite includes testing constructors and accessors. Two basic approaches to baseline testing: specification-based and implementation-based: Check that all the constructors and accessors are self-consistent. Create a test case for each constructor and verify that all attributes are correct by invoking accessors. Check that all the constructors and accessors use the variables in an object correctly.

20 20 Constructing a test driver (cont...) Running test suites: The abstract Tester class includes in its protocol some operations to run all test cases or selected test suites. Each calls a sequence of test case methods. Make sure that the baseline test suite is executed before any of these other suites are executed.

21 21 Constructing a test driver (cont...) Reporting test results: A test case method determines the success of a test case. The test case should report results to the tester instance.

22 22 Key points Possible ways for identifying test cases Pre- and post-conditions (OCL) State transition diagram Common ways used measures of adequacy: state-based coverage, constraint-based coverage and code-based coverage. Boundary conditions is the input value on which a large change occurs.

23 23 Key points (cont...) Test driver should have relatively simple design, easy to maintain and reusable to create new drivers. Test case suites: functional, structural, and interaction Test case methods: one method per test case or group of closely related test cases: Baseline — checking test cases results and accessor and modifier methods.


Download ppt "1 Software Testing and Quality Assurance Lecture 21 – Class Testing Basics (Chapter 5, A Practical Guide to Testing Object- Oriented Software)"

Similar presentations


Ads by Google