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 error Uncover 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/e Testing client/server architectures--- isolate test conditions as much a possible (pgs /e, pgs /e) Errors in a WebApp Environment, new for 7/e (pg 531 7/e)