Samra Siddiqui

 Introduction to static testing

 Approach of static testing

 Unit and Integration Testing

 Dry run testing, authors manually read their own
documents/code to find any errors.

 Not detailed testing, but syntax checking of the code/document

 “Static” means “not while running” or “not while executing”

 Objective of static analysis

 To reveal defects or parts that are defect-prone in a
document
 Two-step approach to static testing.
 Clean up the cosmetic appearance of the document:
check spelling, check grammar, check punctuation
If the document is not cosmetically clean, the readers will surely

stop reading the document for meaning and start proofreading.

For the second step, use whatever techniques seem

appropriate to focus expert review on document contents.
 Some software artifacts are small enough to be inspected by
one or two inspectors

 Such reduced size inspection teams can be used to inspect

software artifacts of limited size, scope or complexity

 Economical and more suitable for smaller scale programs

 A typical implementation of two-person inspection is the

reversible author-inspector pair
 Informal code review technique

 Reviewer standing over the author’s workstation while the

author walks the reviewer through a set of code changes.

 Typically the author “drives” the review

 The author can present the changes

 "Spot pair programming”

 Can be made to work over long distances.

 This complicates the process

 Standing over a shoulder allows people to point, write

examples
 A one-person inspection or walkthrough.

 Desk checking is the least formal and least time-consuming

static testing technique.

 Author test his or her own document.

 For most people, desk checking is relatively unproductive.

 Undisciplined process.

Runs counter to a testing principle.

Solution?
 Black box implementation is "opaque" (black).

 Also known as functional testing. Internal workings are not

known by the tester.

 For example, in a black box test, tester only knows the inputs
and what the expected outcomes should be and not how the
program arrives at those outputs.
 Unit testing, which is testing of individual hardware or software
units or groups of related units (IEEE, 1990). A unit is a software
component that cannot be subdivided into other components
(IEEE, 1990).

 White-box test cases to examine whether the unit is coded

correctly.

 Unit testing is important for ensuring the code is solid before it is

integrated with other code.

 Approximately 65% of all bugs can be caught in unit testing

(Beizer, 1990).
 Dynamic unit testing is execution based testing
For more complex programs
 Losing strategy: Write each function and execute them all

together.
 It is difficult to debug all the functions at once

 Multiple errors interact

 Winning strategy: Test each function separately.

 Each function works before you test it with other functions.

 Saves testing and debugging time.

 How can you test a function that depends on other functions?

 The caller unit is known as a test driver, and dummy units called by
the unit under test are called stubs
 Test Driver is a software module used to invoke a module under test and,
often, provide test inputs, control and monitor execution, and report test results
(IEEE, 1990)
 The unit under test executes with input values received from the driver
and, upon termination, returns a value to the driver.
 It compares the actual outcome, that is, the actual value returned by
the unit under test with the expected outcome from the unit and reports
the test result.
 For example, to move a Player instance,Player1, two spaces on the board,
the driver code would be
 movePlayer(Player1, 2);
 Stub is a “dummy subprogram” that replaces
a unit that is called by the unit under test.

 A piece of code that simulates the activity of

missing components.

 If the function A you are testing calls another

function B, then use a simplified version of
function B, called a stub.
void function_under_test(int &x, int &y) {
...
p = price(x);
... Stub
}
double price(int x) {return 10.00;}
 The value returned by function price is good enough for testing.

 The real price() function may not yet have been tested, or even written.

 Stubs and drivers are often viewed as throwaway code (Kaner, Falk et al.,
1999). However, they do not have to be thrown away: Stubs can be “filled
in” to form the actual method. Drivers can become automated test cases.