外文翻译---软件测试策略

《外文翻译---软件测试策略》由会员分享，可在线阅读，更多相关《外文翻译---软件测试策略（12页珍藏版）》请在毕设资料网上搜索。

1、 附录 英文文献 SOFTWARE TESTING STEATEGIES A strategy for software testing integrates software test case design methods into a well-planned series of steps that result in the successful construction of software .As important ,a software testing strategy provides a rode map for the software developer, the

2、quality assurance organization ,and the customer a rode map that describes the steps to be conducted as part of testing, when these steps are planned and then undertaken, and how much effort, time, and resources will be required. Therefore , any testing strategy must incorporate test planning, test

3、case design, test execution, and resultant data collection . 一 INTEGRATION TESTING A neophyte in the software world might ask a seemingly legitimate question once all modules have been unit tested:“ IF they all work individually, why do you doubt that theyll work when we put them together?” The prob

4、lem, of course, is“ putting them together” interfacing . Data can be lost across an interface； one module can have an inadvertent, adverse affect on another； subfunctions, when combiner, may not produce the desired major function； individually acceptable imprecision may be magnified to unacceptable

5、levels； global data structures can present problems sadly, the list goes on and on . Integration testing is a systematic technique for constructing the program structure while conducting tests to uncover errors associated with interfacing. The objective is to take unit tested modules and build a pro

6、gram structure that has been dictated by design. There is often a tendency to attempt non-incremental integration； that is, to construct the program using a :“ big bang” approach. All modules are combined in advance .the entire program in tested as a whole. And chaos usually results! A set of errors

7、 are encountered. Correction is difficult because isolation of causes is complicated by the vast expanse of the entire program. Once these errors are corrected, new ones appear and the process continues in a seemingly endless, loop. Incremental integration is the antithesis of the big bang approach.

8、 The program is constructed and tested in small segments, where errors are easier to isolate and correct； interfaces are more likely to be tested completely； and a systematic test approach may be applied. In the sections that follow, a number of different incremental integration strategies are discu

9、ssed. 1.1 Top-Down Integration Top-Down Integration is an incremental approach to construction of program structure. Modules are integrated by moving downward through the control hierarchy, beginning with the main control module (main program). Modules subordinate (and ultimately subordinate) to the

10、 main control module are incorporated into the structure in either a depth-first or breadth-first manner. Depth-first integration would integrate all modules on a major control path of the structure. Selection of a major path is somewhat arbitrary and depends on application-specific characteristics.

11、 For example, selecting the left hand path, modules M1,M2, and M5 would be integrated first. Next, M8 or (if necessary for proper functioning of M2) M6 would be integrated. Then, the central and right hand control paths are built. Breadth-first integration incorporates all modules directly subordina

12、te at each level, moving across the structure horizontally. From the figure, modules M2, M3, and M4 would be integrated first. The next control level, M5, M6, and so on, follows. The integration process is performed in a series of steps: （ 1） The main control module is used as a test driver, and stu

13、bs are substituted for all modules directly subordinate to the main control module. （ 2） Depending on the integration approach selected (i.e., depth- or breadth-first), subordinate stubs are replaced one at a time with actual modules. （ 3） Tests are conducted as each module is integrated. （ 4） On co

14、mpletion of each set of tests, another stub is replaced with the real module. （ 5） Regression testing may be conducted to ensure that new errors have not been introduced. The process continues from step 2 until the program structure is built. The top-down integration strategy verifies major control

15、or decision points early in the test process. In a well-factored program structure, decision making occurs at upper levels in the hierarchy and is therefore encountered first. If major control program do exist, early recognition is essential. If depth-first integration is selected, a complete functi

16、on of the software may be implemented and demonstrated. For example, consider a classic transaction structure in which a complex series of interactive inputs path are requested, acquired, and validated via an incoming path. The incoming path may be integrated in a top-down manner. All input processi

17、ng (for subsequent transaction dispatching) maybe demonstrated before other elements of the structure have been integrated. Early demonstration of functional capability is a confidence builder for both the developer and the customer. Top-down strategy sounds relatively uncomplicated, but in practice

18、, logistical problems can arise. The most common of these problems occurs when processing at low levels in the hierarchy is required to adequately test upper levels, Stubs replace low-level modules at the beginning of top-down testing； therefore no significant data can flow upward in the program str

19、ucture. The tester is left with three choices: 1 delay many tests until stubs are replaced with actual modules, 2 develop stubs that perform limited functions that simulate the actual module, or 3 integrate the software from the bottom of the hierarchy upward. The first approach (delay tests until s

20、tubs are replaced by actual modules) causes us to lose some control over correspondence between specific tests and incorporation of specific modules. This can lead to difficulty in determining the cause of errors and tends to violate the highly constrained nature of top-down approach. The second app

21、roach is workable, but can lead to significant overhead, as stubs become more and more complex. The third approach is called bottom-up testing. 1.2 Bottom-Up Integration Bottom-up integration testing, as its name implies, begins construction and testing with atomic modules (i.e., modules at the lowe

22、st level in the program structure). Because modules are integrated from the bottom up, processing required for modules subordinate to a given level is always available and the need for stubs is eliminated. A bottom-up integration strategy may be implemented with the following steps: 1 Low-level modules are combined into clusters (sometimes called builds) that perform a specific software subfunction. 1. A driver (a control program for testing) is written to coordinate test case input and output. 2 .The cluster is tested.