TEST CASE DESIGN The design of tests for software and other engineered products can be as challeng-
17.2 TEST CASE DESIGN The design of tests for software and other engineered products can be as challeng-
ing as the initial design of the product itself. Yet, for reasons that we have already “There is only one
rule in designing test discussed, software engineers often treat testing as an afterthought, developing test cases: cover all
cases that may "feel right" but have little assurance of being complete. Recalling the features, but do not
objectives of testing, we must design tests that have the highest likelihood of finding make too many test
the most errors with a minimum amount of time and effort. cases.”
A rich variety of test case design methods have evolved for software. These meth-
Tsuneo Yamaura
ods provide the developer with a systematic approach to testing. More important, methods provide a mechanism that can help to ensure the completeness of tests and provide the highest likelihood for uncovering errors in software.
Any engineered product (and most other things) can be tested in one of two ways: (1) Knowing the specified function that a product has been designed to perform, tests
WebRef
can be conducted that demonstrate each function is fully operational while at the The Testing Techniques
same time searching for errors in each function; (2) knowing the internal workings Newsletter is an excellent
of a product, tests can be conducted to ensure that "all gears mesh," that is, internal source of information on
testing methods: operations are performed according to specifications and all internal components
www.testworks.
have been adequately exercised. The first test approach is called black-box testing
com/News/TTN-
and the second, white-box testing.
Online/
When computer software is considered, black-box testing alludes to tests that are conducted at the software interface. Although they are designed to uncover errors, black-box tests are used to demonstrate that software functions are operational, that input is properly accepted and output is correctly produced, and that the integrity of
PA R T T H R E E C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G
external information (e.g., a database) is maintained. A black-box test examines some fundamental aspect of a system with little regard for the internal logical structure of the software.
White-box testing of software is predicated on close examination of procedural White-box tests can be
detail. Logical paths through the software are tested by providing test cases that exer- designed only after a
cise specific sets of conditions and/or loops. The "status of the program" may be component-level design
(or source code) examined at various points to determine if the expected or asserted status corre- exists. The logical
sponds to the actual status. details of the program
At first glance it would seem that very thorough white-box testing would lead to must be available.
"100 percent correct programs." All we need do is define all logical paths, develop test cases to exercise them, and evaluate results, that is, generate test cases to exer- cise program logic exhaustively. Unfortunately, exhaustive testing presents certain logistical problems. For even small programs, the number of possible logical paths can be very large. For example, consider the 100 line program in the language C. After some basic data declaration, the program contains two nested loops that execute from 1 to 20 times each, depending on conditions specified at input. Inside the inte-
rior loop, four if-then-else constructs are required. There are approximately 10 14 pos- sible paths that may be executed in this program! To put this number in perspective, we assume that a magic test processor ("magic" because no such processor exists) has been developed for exhaustive testing. The processor can develop a test case, execute it, and evaluate the results in one mil- lisecond. Working 24 hours a day, 365 days a year, the processor would work for 3170
It is not possible to years to test the program. This would, undeniably, cause havoc in most development exhaustively test every schedules. Exhaustive testing is impossible for large software systems.
program path because the number of paths is
White-box testing should not, however, be dismissed as impractical. A limited simply too large.
number of important logical paths can be selected and exercised. Important data structures can be probed for validity. The attributes of both black- and white-box test- ing can be combined to provide an approach that validates the software interface and selectively ensures that the internal workings of the software are correct.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more