If your structural tests are exhaustive - that is, they cover all possible cases - then you could argue that system doesn't need module Y because your tests show that it functions properly without it. In this case you would not have to retest the new system.
If your structural tests are not exhaustive, then there's a chance that your tests didn't cover a section of the code that, had it been executed, would have used the missing module. In this case you would have to test the new system (although it would probably be a smart move on your part to retest the old system in an attempt to discover how to drive the system into using the missing module).
Because regression tests are long-lived, they need to be kept up to date as the system they apply to evolves. The more stable regression tests are with respect to change, the less effort required to keep them up to date. In this regard, functional tests are more stable than are structural tests because a system's function, assuming it meets client requirements, is kept constant, while a system's structure may be undergoing continuous change as new faults are found and fixed.
explain how to construct a set of test data consistent with the equivalence-class criterion. You may assume the events are unique.
The equivalence-class criterion divides the input into sets such that each member of a set results in the same output behavior, and members of different sets result in different output behavior. Because the events are unique, we can deal with each event in independently of the other events.
From the cause-effect graph, the input-output relations are
Picking one element from each input set gives the test-data set {{C1, C2}, {C2}, {C2, C4}}; there are others.
Output Input sets E1 {{C1, C2}} E2 {{C2}, {C3}, {C2, C3}} E3 {{C2, C4} {C3, C4}, {C2, C3, C4}}
Each test-case specification describes the details for carrying out a test described in the test plan. Starting from the beginning of the waterfall model and working forwards:
- Requirements: The requirements document describes the functional behavior of the system. At the end of the requirements phase, you can start writing the test-case specifications for the functional parts of the system test.
- Design: The design document describes the architectural and logical structure of the system. At the end of the design phase, you can start writing the test-case specifications for the structural parts of the system test, the integration test, and the functional parts of the unit tests.
- Implementation: The implementation describes how the system is built. At the end of the implementation phase, you can start writing the test-case specifications for structural parts of the unit tests.