ÁùºÏ²ÊÖ±²¥¿ª½±

It might sound trivial: The central goal of testing is to check whether a system does what it was designed for. How that goal is achieved, however, is already a bit less obvious. Ideally, you run tests that result from an analysis of your requirements. As a result, requirements-based testing is a central testing method for testing with TPT.

¡°Requirements ¡­ are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. Requirements may be a constraint on the development process of the system¡±
(Sommerville and Sawyer, 1997)

¡°A requirement is a stakeholder-desired or needed target or constraint.¡±
(T. Gilb, 2002)

The requirements for a certain system are specified at the corresponding integration level and are written in such a way that they can be verified individually. Next, you create test cases that stimulate the respective requirement and provoke a certain behaviour in the system under test. This implies that there should be at least one test case per requirement, although multiple test cases per requirement are also possible.

Provided the requirement is specific, it will serve as a reliable test exit criterion and metric as to when sufficient testing has been done.

Writing Requirements Well

Writing good requirements is extremely complex. However, there are certain techniques to be employed and other to be avoided.

Your requirements become more specific the more you use:

• Context diagrams
• Use cases/ user stories
• Feature lists

However, requirements are unsuitable or even ineffective if they contain pseudocode, for example.

The Early Tester Catches the Bug

The biggest advantage of first specifying your requirements is that you can start creating test cases even before you start implementing.

Though what¡¯s preached in theory, is not always common practice. Sometimes the test case is relatively straightforward and the software requirements are self-evident, as applies to, say, a window lifter.

More often than not, however, the software or ECU to be tested is associated with multiple test cases, implies safety-relevant functionalities and has a high level of complexity, such as a clutch control, for example. Therefore, first taking the time to write down requirements as concretely as possible can serve as a time-saving analytical tool in the long run. It goes without saying that by structuring your testing in such a way you also minimize the risk to make mistakes.

Start Testing Early

Specifying your high-level requirements early-on in the testing process has one big advantage: they can be easily refined as the development of your software proceeds. Simultaneously, ambiguous or unclear requirements in earlier development phases are handed down and can lead to more work, more cost and, not unimportantly, frustration.

It is advisable to start testing units and modules and proceed accordingly with the consecutive integration levels. Ultimately, early testing is also cost-effective: catch the bugs, save the bucks.

TPT leads the easier path: Once you specify your requirements, the remaining testing with TPT is straightforward and automated.