Ch 8 Software Testing

validation

Confirmation the software does what the user really requires.

verification

Confirmation the software conforms to its specification.

verification and validation planning

Defining objectives, resources, schedule, responsibilities, required evidence across stages.

code author/owner

Original creator responsible for the artifact under inspection.

code inspectors

Peers examining artifacts to detect defects.

inspection checklist

Structured list of common faults (data, control, I/O, interface, storage, exceptions).

inspection moderator

Facilitates the session, pacing, and objectivity.

reader/scribe

Reads the artifact aloud and records issues found.

software inspection

Non-execution examination to discover anomalies/defects in any system representation.

automated static analysis

Tool-based parsing of source to flag suspicious conditions; supplements inspections.

LINT

Analyzer detecting undefined uses, type issues, portability problems.

static analyser

Software that processes source text to discover potential errors.

certification team

Designs statistical tests and applies reliability growth models.

cleanroom software development

Defect-avoidance process using formal specs, static verification, statistical testing.

correctness arguments

Static verification justifying code against specification.

development team

Develops and verifies without executing or compiling code.

formal specification

Precise specification basis for verification and testing focus.

incremental development

Delivering verified increments with measurable reliability growth.

reliability growth models

Models used to judge when reliability is acceptable.

specification team

Develops and maintains the system specification.

statistical testing

Usage-profiled testing to estimate operational reliability.

black-box testing

Testing vs. specification without code knowledge; used in release testing.

component testing

Defect testing of individual components in isolation.

integration testing

Test as components are integrated with source access.

release testing

Black-box testing of the complete system for requirement conformance.

stress testing

Exercising beyond max load to reveal defects and ensure safe failure behavior.

system testing

Validating integrated component interactions and emergent behavior.

equivalence partition

Input/output class with equivalent behavior; select tests per partition.

partition testing

Choosing test cases from each equivalence partition/domain.

path testing

Ensuring each path through the program executes at least once.

program flow graph

Nodes=decisions; arcs=control flow; basis for path testing.

requirements-based testing

Tracing test cases to requirements.

structural testing

White-box tests designed from program structure to exercise statements.

test case design

Designing inputs/outputs for effective validation and defect testing.

dynamic program analyser

Tool to check which paths executed at runtime.

JUnit (as example system)

A system supporting automatic execution of tests.

testing workbench

Tool suite reducing testing time/cost; often open to fit org-specific needs.