Black box testing - SYSC3020-Winter2016/SYSC3020LectureNotes GitHub Wiki

Black-box testing is the practice of testing without knowing the code. The functionality of the system is tested against the specifications.

It should not be done by the developer, who is inherently biased towards testing that the code does what he/she thought it should do. If the developer misinterpreted the specifications, this will not be caught. Black-box testing is often done by the person who writes the specifications.

An important technique in black-box testing is Input Space Partitioning.

The idea of input space partitioning is that fior a given function, we cannot test every possible input. For example, adequately testing the javac compiler would require compiling every possible java program. Testing the function abs() that returns the absolute value of an interger would require trying every possible integer.

A solution to this problem is identifying equivalence classes within these inputs, i.e. classes of inputs for which the program behaves the same way. We then only need to test one input per equivalence class.

However, one problem is that the theoretical equivalence classes do not matcvh the actual equivalence classes of the implemented program (due to bugs). For example, if the abs() function is implemented as follows: if (x<-1) return x*(-1) else return x Then the equivalence classes are [MIN_INT,-2] and [-1,MAX_INT] instead of the expected [MIN_INT,-1] and [0,MAX_INT]

For this reason it is recommended to test several values per equivalence class, and also test boundary cases, i.e. values at the limits of the equivalence classes. In addition to these, values considered boundary cases are extreme values, special values like 0, empty lists, null pointers, etc.