Testing Object-Oriented Systems
What is software testing ?
According to Robert V. Binder [1]
The design and implementation of a special kind of software system: one that exercises another software system with the intend of finding bugs. This system automatically applies and evaluates the tests.
Manual testing, of course still plays a role. But testing is mainly about the development of an automated system to implement an application specific test design.
Test design:
1. Analyze the responsibilities of the (sub)system under test.
2. Design test cases based on this external view.
3. Add test cases based on code analysis, suspicions, and heuristics
4. Develop expected result for each test case, choose approach to evaluate the pass/no pass status of each test case
Test automation
Test execution:
- minimal operational implementation under test
- execute testsuite, each test pass/no pass
- use coverage tool, evaluate reported coverage
- if needed, develop additional tests to test uncovered code
- stop testing: coverage goal met + all tests pass
Test design is best seen as gray box hybrid testing, primary focus is on
responsibility based testing: spec-oriented, behavioral, functional (black box)
and a secondary focus on
implementation based testing: structural, statement or branch coverage based (white box)
This is to be done at different scopes (bottom-up): method, class, cluster, subsystem, system. Skipping testing at smaller scopes is a common to schedule pressure. Unfortunately, testing at broader scope is subsequently often hampered by inoperable parts. A good remedy is applying test-driven development, where the tests are written before implementation of the functionality.
Integration Test: when testing at a particular scope is complete you integrate with other tested elements into the next scope level: a complete system or subsystem of software units. Exercise the interfaces among the units to demonstrate that the units are collectively operable.
A major goal is to stabilize the system so that responsibility-based testing may proceed smoothly.
Integration testing is a process, rather than an event or phase. It begins early, takes place at all scopes, and is repeated in each development increment. The process of integration test design often reveals errors, omissions, and ambiguities in the requirements and architecture. Make testability a design goal!
System Test: functional testing, performance testing, stress + load testing
Typically unit and integration testing are fault-directed, while system testing is conformance directed.
[1] Read more on object-oriented testing & patterns in the book: Testing Object-Oriented Systems: Models, Patterns, and Tools, by Robert V Binder (2000), which provides an in-depth coverage of testing. An authoritative guide to designing and automating test suites for OO applications.
According to Robert V. Binder [1]
The design and implementation of a special kind of software system: one that exercises another software system with the intend of finding bugs. This system automatically applies and evaluates the tests.
Manual testing, of course still plays a role. But testing is mainly about the development of an automated system to implement an application specific test design.
Test design:
1. Analyze the responsibilities of the (sub)system under test.
2. Design test cases based on this external view.
3. Add test cases based on code analysis, suspicions, and heuristics
4. Develop expected result for each test case, choose approach to evaluate the pass/no pass status of each test case
Test automation
Test execution:
- minimal operational implementation under test
- execute testsuite, each test pass/no pass
- use coverage tool, evaluate reported coverage
- if needed, develop additional tests to test uncovered code
- stop testing: coverage goal met + all tests pass
Test design is best seen as gray box hybrid testing, primary focus is on
responsibility based testing: spec-oriented, behavioral, functional (black box)
and a secondary focus on
implementation based testing: structural, statement or branch coverage based (white box)
This is to be done at different scopes (bottom-up): method, class, cluster, subsystem, system. Skipping testing at smaller scopes is a common to schedule pressure. Unfortunately, testing at broader scope is subsequently often hampered by inoperable parts. A good remedy is applying test-driven development, where the tests are written before implementation of the functionality.
Integration Test: when testing at a particular scope is complete you integrate with other tested elements into the next scope level: a complete system or subsystem of software units. Exercise the interfaces among the units to demonstrate that the units are collectively operable.
A major goal is to stabilize the system so that responsibility-based testing may proceed smoothly.
Integration testing is a process, rather than an event or phase. It begins early, takes place at all scopes, and is repeated in each development increment. The process of integration test design often reveals errors, omissions, and ambiguities in the requirements and architecture. Make testability a design goal!
System Test: functional testing, performance testing, stress + load testing
Typically unit and integration testing are fault-directed, while system testing is conformance directed.
[1] Read more on object-oriented testing & patterns in the book: Testing Object-Oriented Systems: Models, Patterns, and Tools, by Robert V Binder (2000), which provides an in-depth coverage of testing. An authoritative guide to designing and automating test suites for OO applications.
posted by Ronny De Winter at Friday, May 13, 2005
2 Comments:
I just wish that more companies considered testing in the development phase. Too often I've seen test plans and cases written from the nearly completed project, almost as if testing was an afterthought.
And also, too many times, automation would be a great way to test the particular application, but no one is willing to invest the time required to program the automation. As the development schedule inevitably gets stretched, the testing schedule inevitably gets squashed, and management would rather time is spent on testing rather that on tools for testing.
Anyway, good blog, Ronny. I'll be revisiting from time to time.
HelenWheels, breaking software since 1981.
This comment has been removed by a blog administrator.
Post a Comment
Read more about Software Quality at the <<Software Quality Weblog Home