Software Testing Techniques

Fundamental Thoughts About Testing

Testing Goal

The number one goal of testing is to find errors in your software. Goods tests:Have a high probability of finding an errorUncover a class of errors (without

redundancy) i.e., a well-designed test exhibits any of several

types of errors (perhaps using different test case data)

Find errors with little effort

White-Box Testing

A.k.a: Glass-box testing Any of a type of test that uses knowledge of a modules control

structures to derive test cases. Generally applied during unit testing. Types

Basis-Path Testing: i.e., test all independent paths in the program Condition Testing: i.e., test T/F results of a condition Data Flow Testing: i.e., test path in program based on affect on

given variable or variables Loop Testing: i.e., test iteration (and non-iteration of loops) Fault-Based Testing: i.e., test that code where it is plausible that

there are faults. For example, complex code (difficult equations, recursion, nested loops, pointer manipulations, storage allocation) or long interaction sequences.

Black-Box Testing

Any of a type of tests that restrict test cases to that which can be derived from examining a modules interface specifications

Generally applied during integration and system testing Types

Equivalence Partitioning: i.e., attempts to classify the input domain of test cases into equivalence classes based on how the module is perceived to act on that input

Boundary Value Analysis: i.e., builds test cases from boundary conditions in specification

Orthogonal Array Testing: i.e., builds test cases by varying all input parameters simultaneously to cover a “wide” a spectrum of the input domain as possible in a few test cases.

Scenario-based Testing: i.e., builds test cases based on an expected user profile.

Random Sequence Testing: i.e., builds test cases from random (likely in-allowable) sequences of operations.

Testing Addendum

Test GUIs using a profile of your users Expect novice users to hit buttons out of sequence or fill in

forms with erroneous data Expect advanced users to move quickly through the UI, get

impatient with slow response, and test shortcuts and macros Test Documentation

Operate your application based on documentation in the User’s or Installation Manual. Make sure the application and documentation are in agreement

Test Help Facilities As the writer of the application, you typically don’t need help;

however, your users will. Test that your instructions work. Test the help facilities with novice users to see if the

instructions communicate what you intend to communicate

Conventional vs. OO Testing

Similarities White- and black-box techniques apply for both conventional

and OO development. Differences

Conventional mindset tends to be to test function OO mindset tends to be to test interoperability

Keep in mind, the set of interoperable objects may change according to the thread of use.

OO methods may be inherited, so they may need to be tested again in their new context.

OO testing needs to recognize that objects typically have an internal state that can influence the operation of a member function.

Additional Points of Emphasis

Quote in sidebar pg 492 7/e (at bottom of pg 399 6/e)

Key point pg 498 7/e, pg 406 6/eTesting client/server architectures---

isolate test conditions as much a possible (pgs 503-504 7/e, pgs 420-421 6/e)

Errors in a WebApp Environment, new for 7/e (pg 531 7/e)