|
A Practitioner's Guide to Software Test Design Authors: Copeland L. Published year: 2003 Pages: 83-87/161 |
 |
Applicability and Limitations
Data flow testing builds on and expands control flow testing techniques. As with control flow testing, it should be used for all modules of code that cannot be tested sufficiently through reviews and inspections. Its limitations are that the tester must have sufficient programming skill to understand the code, its control flow, and its variables. Like control flow testing, data flow testing can be very time consuming because of all the modules, paths, and variables that comprise a system.
Summary
-
A common programming mistake is referencing the value of a variable without first assigning a value to it.
-
A data flow graph is similar to a control flow graph in that it shows the processing flow through a module. In addition, it details the definition, use, and destruction of each of the module's variables . We will use these diagrams to verify that the define-use-kill patterns are appropriate.
-
Enumerate the paths through the module. Then, for every variable, create at least one test case to cover every define-use pair.
Practice
-
The following module of code computes n! (n factorial) given a value for n. Create data flow test cases covering each variable in this module. Remember, a single test case can cover a number of variables .
int factorial (int n) { int answer, counter; answer = 1; counter = 1; loop: if (counter > n) return answer; answer = answer * counter; counter = counter + 1; goto loop; } -
Diagram the control flow paths and derive the data flow test cases for the following module:
int module( int selector) { int foo, bar; switch selector { case SELECT-1: foo = calc_foo_method_1(); break; case SELECT-2: foo = calc_foo_method_2(); break; case SELECT-3: foo = calc_foo_method_3(); break; } switch foo { case FOO-1: bar = calc_bar_method_1(); break; case FOO-2: bar = calc_bar_method_2(); break; } return foo/bar; }Do you have any concerns with this code? How would you deal with them?
References
( 1990 ). Software Testing Techniques . Van Nostrand Reinhold.
( 2000 ). Testing Object-Oriented Systems: Models, Patterns, and Tools . Addison-Wesley.
( 1995 ). The Craft of Software Testing: Subsystem Testing Including Object-Based and Object-Oriented Testing . Prentice-Hall.
"Data Flow Analysis Techniques for Test Data Selection." Sixth International Conference on Software Engineering, Tokyo, Japan, September 13–16, 1982 .
Section III: Testing Paradigms
Chapter List
- Chapter 12: Scripted Testing
- Chapter 13: Exploratory Testing
- Chapter 14: Test Planning
Part Overview
Paradigms
In his book, Paradigms: The Business of Discovering the Future , Joel Barker defines a paradigm as "a set of rules and regulations (written or unwritten) that does two things: (1) it establishes or defines boundaries, and (2) it tells you how to behave inside the boundaries in order to be successful." Futurist Marilyn Ferguson sees a paradigm as "a framework of thought ... a scheme for understanding and explaining certain aspects of reality."
Paradigms are useful because they help us make sense of the complexities of the world around us. In this way, paradigms sharpen our vision. But paradigms can blind us to realities. Paradigms act as psychological filters. Data that does not match our paradigms is blocked. In this way, paradigms cloud our vision.
In software testing today, two very different paradigms are battling for adherents—scripted testing and exploratory testing.
Scripted testing is based on the sequential examination of requirements, followed by the design and documentation of test cases, followed by the execution of those test cases. The scripted tester's motto is, "Plan your work, work your plan."
Exploratory testing is a very different paradigm. Rather than a sequential approach, exploratory testing emphasizes simultaneous learning, test design, and test execution. The tester designs and executes tests while exploring the product.
| Word Of Warning ! |
In the following chapters the scripted and exploratory paradigms are defined at the extreme ends of the spectrum. Rarely will either be used as inflexibly as described. |
The next two chapters describe these paradigms. A word of warning though—each paradigm is described at the extreme end of the process spectrum. Rarely will either paradigm be used as inflexibly as described. More often, scripted testing may be somewhat exploratory and exploratory testing may be somewhat scripted.
Test Planning
Planning has been defined as simply "figuring out what to do next." To be most effective and efficient, planning is important. But when and how should that planning be done? Scripted testing emphasizes the value of early test design as a method of detecting requirements and design defects before the code is written and the system put into production. Its focus is on accountability and repeatability . Exploratory testing challenges the idea that tests must be designed so very early in the project, when our knowledge is typically at its minimum. Its focus is on learning and adaptability.
References
( 1992 ). Paradigms: The Business of Discovering the Future . HarperCollins.
( 1980 ). The Aquarian Conspiracy: Personal and Social Transformation in Our Time . Putnam Publishing Group.
|
A Practitioner's Guide to Software Test Design Authors: Copeland L. Published year: 2003 Pages: 83-87/161 |
|
