About Us


  Process Models

  SE Resources


  Contact us

Breaking News!

A new blog ... visit OnCenter, Roger Pressman's running commentary on the world at large

A new edition ... the 6th edition of Software Engineering is available now

A first novel ... Roger Pressman's first novel is a technothriller -- The Aymara Bridge

A new training curriculum! RSP&A has partnered with QAI to develop a comprehensive Internet-based software engineering curriculum.

A redesigned Web site ... we've done a major redesign and added many new features

Adaptable Process Model
Conducting Unit Tests

IMPORTANT NOTICE: The complete Adaptable Process Model (APM) is provided for informational purposes and for assessment by potential users. The APM is copyrighted material and may not be downloaded, copied, or extracted for use in actual project work. The full hypertext (html) version of the APM may be licensed for use and customization within your organization. Contact R.S. Pressman & Associates, Inc. for complete licensing information.

Conducting Unit Tests

    In his text on software testing (The Art of Software Testing, Wiley, 1979), Myers proposes a checklist for interface tests:

    • Is the number of input parameters equal to number of arguments?
    • Do parameter and argument attributes match?
    • Do parameter and argument units system match?
    • Is the number of arguments transmitted to called modules equal to number of parameters?
    • Are the attributes of arguments transmitted to called modules equal to attributes of parameters?
    • Is the units system of arguments transmitted to called modules equal to units system of parameters?
    • Are the number of attributes and the order of arguments to built-in functions correct?
    • Are any references to parameters not associated with current point of entry?
    • Have input only arguments altered?
    • Are global variable definitions consistent across modules?
    • Are constraints passed as arguments?
    • When a module performs external I/O, additional interface tests must be conducted.

      Again, from Myers:

    • File attributes correct?
    • OPEN/CLOSE statements correct?
    • Format specification matches I/O statement?
    • Buffer size matches record size?
    • Files opened before use?
    • End-of-file conditions handled?
    • I/O errors handled?
    • Any textual errors in output information?

    The local data structure for a module is a common source of errors. Test cases should be designed to uncover errors in the following categories:

    • improper or inconsistent typing
    • erroneous initialization or default values
    • incorrect (misspelled or truncated) variable names
    • inconsistent data types
    • underflow, overflow and addressing exceptions

    From a strategic point of view, the following questions should be addressed:

    • Has the component interface been fully tested?
    • Have local data structured been exercised at their boundaries?
    • Has the cyclomatic complexity of the module been determined?
    • Have all independent basis paths been tested?
    • Have all loops been tested appropriately?
    • Have data flow paths been tested?
    • Have all error handling paths been tested?

      Return to Checklist Table of Contents

Site search! We've added links to a search engine that will enable you to search our entire site for information you need. Enter the appropriate word or phrase below.


Home About us Products Product Models SE Resources Commentary Contact us

Web site and all contents R.S. Pressman & Associates, Inc. 2001 - 2006, All rights reserved.
Free website templates