外文翻譯---軟件測(cè)試策略

1、<p><b>　　附 錄</b></p><p><b>　　英文文獻(xiàn)</b></p><p>　　SOFTWARE TESTING STEATEGIES</p><p>　　A strategy for software testing integrates software test case de

2、sign 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 quality assurance org

3、anization ,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. Therefo<

4、/p><p>　　一 INTEGRATION TESTING</p><p>　　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 yo

5、u doubt that they’ll work when we put them together?”The problem, of course, is“putting them together”—interfacing . Data can be lost across an interface; one module can have an inadvertent, adverse affect on another; su

6、bfunctions, when combiner, may not produce the desired major function; individually acceptable imprecision may be magnified t</p><p>　　Integration testing is a systematic technique for constructing the progr

7、am structure while conducting tests to uncover errors associated with interfacing. The objective is to take unit tested modules and build a program structure that has been dictated by design.</p><p>　　There

8、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 r

9、esults! A set of errors 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 cont

10、inues in a seemingly endless, loop.</p><p>　　Incremental integration is the antithesis of the big bang approach. The program is constructed and tested in small segments, where errors are easier to isolate an

11、d 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 discussed.</p>

12、<p>　　1.1 Top-Down Integration</p><p>　　Top-Down Integration is an incremental approach to construction of program structure. Modules are integrated by moving downward through the control hierarchy, b

13、eginning with the main control module (main program). Modules subordinate (and ultimately subordinate) to the main control module are incorporated into the structure in either a depth-first or breadth-first manner.</p

14、><p>　　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. For exam

15、ple, 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

16、. Breadth-first integration incorporates all modules directly subordinate at </p><p>　　The integration process is performed in a series of steps:</p><p>　　（1）The main control module is used as a

17、 test driver, and stubs are substituted for all modules directly subordinate to the main control module.</p><p>　?。?）Depending on the integration approach selected (i.e., depth- or breadth-first), subordinat

18、e stubs are replaced one at a time with actual modules.</p><p>　?。?）Tests are conducted as each module is integrated.</p><p>　?。?）On completion of each set of tests, another stub is replaced wit

19、h the real module.</p><p>　　（5）Regression testing may be conducted to ensure that new errors have not been introduced.</p><p>　　The process continues from step 2 until the program structure is b

20、uilt. </p><p>　　The top-down integration strategy verifies major control or decision points early in the test process. In a well-factored program structure, decision making occurs at upper levels in the hier

21、archy and is therefore encountered first. If major control program do exist, early recognition is essential. If depth-first integration is selected, a complete function of the software may be implemented and demonstrated

22、. For example, consider a classic transaction structure in which a complex series of inte</p><p>　　Top-down strategy sounds relatively uncomplicated, but in practice, logistical problems can arise. The most

23、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 d

24、ata can flow upward in the program structure. The tester is left with three choices: 1 delay many tests until stubs are replaced with actual modules, 2 develop stubs that p</p><p>　　The first approach (delay

25、 tests until stubs 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

26、errors and tends to violate the highly constrained nature of top-down approach. The second approach is workable, but can lead to significant overhead, as stubs become more and more complex. The third approach is called b

27、ottom-up testing.</p><p>　　1.2 Bottom-Up Integration</p><p>　　Bottom-up integration testing, as its name implies, begins construction and testing with atomic modules (i.e., modules at the lowest

28、 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.</p><p

29、>　　A bottom-up integration strategy may be implemented with the following steps:</p><p>　　1 Low-level modules are combined into clusters (sometimes called builds) that perform a specific software subfunct

30、ion.</p><p>　　1. A driver (a control program for testing) is written to coordinate test case input and output.</p><p>　　2 .The cluster is tested.</p><p>　　3.Drivers are removed and

31、clusters are combined moving upward in the program structure.</p><p>　　Modules are combined to form clusters 1,2, and 3. Each of the clusters is tested using a driver (shown as a dashed block) Modules in clu

32、sters 1 and 2 are subordinate to M1. Drivers D1 and D2 are removed, and the clusters are interfaced directly to M1. Similarly, driver D3 for cluster 3 is removed prior to integration with module M2. Both M1 and M2 will u

33、ltimately be integrated with M3, and so forth. </p><p>　　As integration moves upward, the need for separate test drivers lessens, In fact, if the top tow levels of program structure are integrated top-down,

34、the number of drivers can be reduced substantially and integration of clusters is greatly simplified.</p><p>　　1.3 Regression Testing </p><p>　　Each time a new module is added as part of integ

35、ration testing, the software changes. New data flow paths are established, new I/O may occur, and new control logic is invoked. These changes may cause problems functions that regression testing is the re-execution of so

36、me subset of tests that have already been conducted to ensure that changes have not propagated unintended side effects.</p><p>　　In a broader context, successful tests (of any kind) result in the discovery o

37、f errors, and errors must be corrected. Whenever software is corrected, some aspect of the software configuration (the program, its documentation, or the data that support it) is changes. Regression testing is the activi

38、ty that helps to ensure that changes (due to testing or for other reasons) do not introduce unintended behavior or additional errors.</p><p>　　Regression testing maybe conducted manually, be re-executing a s

39、ubset of all test cases or using automated capture playback tools. Capture-playback tools enable the software engineer to capture test cases and results for subsequent playback and comparison. The regression test suite (

40、the subset of tests to be executed) contains three different classes of test cases:</p><p>　　1.A representative sample of tests that will exercise all software functions.</p><p>　　2.Additional t

41、ests that focus on software functions that are likely to be affected by the change.</p><p>　　3.Tests that focus on the software components that have been changed.</p><p>　　As integration testing

42、 proceeds, the number of regression tests can grow quite large. Therefore, the regression test suite should be designed to include only those tests that address one or more classes of errors in each of the major program

43、functions. It is impractical and inefficient to re-execute every test for every program function once a change has occurred.</p><p>　　1.4 Comments on Integration Testing </p><p>　　There has bee

44、n much discussion of the relative advantages and disadvantages of top-down versus bottom-up integration testing. In general, the advantages of one strategy tend to result in disadvantages for the other strategy. The majo

45、r disadvantage of the top-down approach is the need for stubs and the attendant testing difficulties that can be associated with them. Problems associated with stubs maybe offset by the advantage of testing major control

46、 functions early. The major disadvantage of bot</p><p>　　Selection of an integration strategy depends upon software characteristics and sometimes, project schedule. In general, a combined approach (sometimes

47、 called sandwich testing) that uses a top-down strategy for upper levels of the program structure, coupled with a bottom-up strategy for subordinate levels maybe the best compromise.</p><p>　　As integration

48、testing is conducted, the tester should identify critical modules. A critical module has one or more of following characteristics: 1 addresses several software requirements;2 has a high level of control (resides relative

49、ly high in the program structure); 3 is complex or error-prone(cyclomatic complexity maybe used as an indicator ); or 4 has definite performance requirements. Critical modules should be tested as early as is possible. In

50、 addition, regression tests should focus on c</p><p>　　二 SYSTEM TESTING</p><p>　　2.1 Recovery Testing</p><p>　　Many computer-based systems must recover from faults and resume proce

51、ssing within a prespecified time. In some cases, a system must be fault tolerant; that is, processing fault must not cause overall system function to cease. In other cases, a system failure must be corrected whining a s

52、pecified period of time or severe economic damage will occur.</p><p>　　Recovery testing is a system test that forces the software to fail in variety of ways and recovery is properly performed. If recovery is

53、 automatic (performed by the system itself), re-initialization, checkpointing mechrequires human intervention, the mean time to repair is evaluated to determine whether it is within acceptable limits.</p><p>

54、;　　2.2 Security Testing</p><p>　　Any computer-based system that manages sensitive information or cause actions that can improperly harm (or benefit) individuals is a target for improper or illegal penetrati

55、on.Penetration spans a broad range of activities: hackers who attempt to penetrate systems for sport; disgruntled employees who attempt to penetrate for revenge; and dishonest individuals who attempt to penetrate for ill

56、icit personal gain.</p><p>　　Security testing attempts to verify that protection mechanisms built into a system will in fact protect it from improper penetration. To quote Beizer:“The system’s security must,

57、 of course, be tested for invulnerability from frontal attack—but must also be tested for invulnerability from flank or rear attack.”</p><p>　　During security testing, the tester plays the role of the indivi

58、dual who desires to penetrate the system. Anything goes! The tester may attempt to acquires passwords through external clerical means, may attack the system with custom software designed to break down any defenses that h

59、ave been constructed; may overwhelm the errors, hoping to penetrate during recovery; may browse through insecure data, hoping to find the key to system entry; and so on.</p><p>　　Given enough time and resour

60、ces, good security testing will ultimately penetrate a system. The role of the system designer is to make penetration cost greater than the value of the information that will be obtained.</p><p>　　2.3 Stress

61、 Testing</p><p>　　During earlier software testing steps, while-box techniques resulted in through evaluation of normal program functions and performance. Stress tests are designed to confront programs with a

62、bnormal situations. In essence, the tester who performs stress testing asks:“How high can we crank this up before it fail?”</p><p>　　Stress testing executes a system in a manner that demands resources in abn

63、ormal quantity, frequency, or volume. For example, 1 special tests maybe designed that generate 10 interrupts per second, when one or two is the average rate; 2 input data rates maybe increased by an order of magnitude t

64、o determine how input functions will respond; 3 test cases that require maximum memory or other resources maybe executed;4 test cases that may cause thrashing in a virtual operating system maybe designed; o</p>&l

65、t;p>　　A variation of stress testing is a technique called sensitivity testing. In some situations (the most common occur in mathematical algorithms) a very small rang of data contained within the bounds of valid data

66、for a program may cause extreme and even erroneous processing or profound performance degradation. This situation is analogous to a singularity in a mathematical function. Sensitivity testing attempts to uncover data com

67、binations within valid input classes that may cause instability or im</p><p>　　2.4 Performance Testing</p><p>　　For real-time and embedded systems, software that provides required function but

68、does not conform to performance requirements is unacceptable. Performance testing is designed to test run-time performance of software within the context of an integrated system. Performance testing occurs throughout all

69、 steps in the testing process. Even at the unit level, the performance of an individual module maybe assessed as while-box test are conducted. H0owever, it is not until all system elements are fully </p><p>

70、<b>　　軟件測(cè)試策略</b></p><p>　　軟件測(cè)試策略把軟件測(cè)試案例的設(shè)計(jì)方法集成到一系列已經(jīng)周密計(jì)劃的步驟中去，從而使軟件的開發(fā)得以成功地完成。同樣重要的事，軟件測(cè)試策略為軟件開發(fā)人員、質(zhì)量保證組織和客戶提供了一個(gè)路線圖，這個(gè)路線圖描述了測(cè)試的步驟，以及當(dāng)這些步驟在計(jì)劃和實(shí)施的過(guò)程中，需要多少工作量、時(shí)間和資源。因此，任何測(cè)試策略都必須和測(cè)試計(jì)劃、測(cè)試案例設(shè)計(jì)、測(cè)試執(zhí)行和測(cè)試結(jié)

71、果數(shù)據(jù)的收集與分析結(jié)合在一起。</p><p><b>　　一 集成測(cè)試</b></p><p>　　一個(gè)在軟件世界里初出茅廬的年輕人可能在所有的模塊都已經(jīng)完成單元測(cè)試之后會(huì)問(wèn)這樣一個(gè)似乎很合理的問(wèn)題：“如果他們每一個(gè)都能單獨(dú)工作的很好，那么你為什么要懷疑把它們放在一起就不能正常工作呢？”當(dāng)然，這個(gè)問(wèn)題就在于“把它們放在一起”----接口相連。數(shù)據(jù)可能在通過(guò)接口的

72、時(shí)候丟失；一個(gè)模塊可能對(duì)另一個(gè)模塊產(chǎn)生無(wú)法預(yù)料的副作用；當(dāng)子函數(shù)被連到一起的時(shí)候，可能不能達(dá)到預(yù)期的功能；在單個(gè)模塊中可以接受的不精確性在連起來(lái)之后可能會(huì)擴(kuò)大到無(wú)法接受的程度；全局?jǐn)?shù)據(jù)結(jié)構(gòu)可能也會(huì)存在問(wèn)題。不幸的事，還有很多很多。</p><p>　　集成測(cè)試是通過(guò)測(cè)試發(fā)現(xiàn)和接口有關(guān)的問(wèn)題來(lái)構(gòu)造程序的系統(tǒng)化技術(shù)，他的目標(biāo)是把通過(guò)了單元測(cè)試的模塊拿來(lái)，構(gòu)造一個(gè)設(shè)計(jì)總所描述的程序結(jié)構(gòu)。</p><

73、p>　　通常存在進(jìn)行非增量集成的傾向，也就是說(shuō)，使用“一步到位”的方法來(lái)構(gòu)造程序。所有的構(gòu)件都預(yù)先結(jié)合在一起，整個(gè)程序作為一個(gè)整體來(lái)進(jìn)行測(cè)試，其后的結(jié)果通常是混亂不看！會(huì)遇到許許多多的錯(cuò)誤，錯(cuò)誤的修正也是非常困難的，因?yàn)樵谡麄€(gè)程序的龐大區(qū)域中要分離出一個(gè)錯(cuò)誤是很復(fù)雜的。一旦這些錯(cuò)誤被修正之后，就馬上會(huì)有新的錯(cuò)誤出現(xiàn)，這個(gè)過(guò)程會(huì)繼續(xù)下去，而且看上去似乎是個(gè)無(wú)限循環(huán)。 </p><p>　　增量集成是一步到位的

74、方法的對(duì)立面。程序先分成小的部分進(jìn)行構(gòu)造和測(cè)試，這個(gè)時(shí)候錯(cuò)誤比較容易分離和修正，接口也更容易進(jìn)行徹底地測(cè)試，而且也可以使用一種系統(tǒng)化的測(cè)試方法。</p><p>　　1.1 自頂向下集成</p><p>　　自頂向下集成測(cè)試時(shí)一直構(gòu)造結(jié)構(gòu)的增量方法。模塊集成的順序是首先集成主控模塊（主程序），然后按照控制層次結(jié)構(gòu)向下進(jìn)行集成。從屬于(和間接從屬于)主控模塊的模塊按照深度優(yōu)先或者寬度優(yōu)先的

75、方式集成到整個(gè)結(jié)構(gòu)中去。</p><p>　　深度優(yōu)先集成首先集成結(jié)構(gòu)中的一個(gè)主控路徑下的所有模塊。主控路徑的選擇是有些隨意的，它依賴于應(yīng)用程序的特性，例如，選擇最左邊的路徑，模塊M1、M2和M5將首先進(jìn)行集成，然后是M8或者M(jìn)6（如果對(duì)M2的適當(dāng)?shù)墓δ苁潜匾模?，然后，開始構(gòu)造中間的右邊的控制路徑。寬度優(yōu)先集成首先沿著水平方向，把每一層中的所有直接從屬于上一層模塊的模塊集成起來(lái)，模塊M2、M3和M4首先進(jìn)行集成

76、，然后是下層的M5和M6，然后繼續(xù)。</p><p>　　集成的整個(gè)過(guò)程有下列5個(gè)步驟來(lái)完成：</p><p>　　1主控模塊被利用作測(cè)試驅(qū)動(dòng)程序，所有的樁模塊替換為直接從屬于主控模塊的模塊。</p><p>　　2根據(jù)集成的實(shí)現(xiàn)方法（如深度或?qū)挾葍?yōu)先），下層的樁模塊一次一個(gè)地被替換為真正的模塊。</p><p>　　3在每一個(gè)模塊集成的時(shí)候

77、都要進(jìn)行測(cè)試。</p><p>　　4在完成了每一次測(cè)試之后，又一個(gè)樁模塊被用真正的模塊替換。</p><p>　　5可以用回歸測(cè)試來(lái)保證沒有引進(jìn)新的錯(cuò)誤。</p><p>　　整個(gè)過(guò)程號(hào)第2步循環(huán)繼續(xù)進(jìn)行，直至這個(gè)系統(tǒng)結(jié)構(gòu)被構(gòu)造完成。</p><p>　　自頂向下集成策略在測(cè)試過(guò)程中的早期驗(yàn)證主要的控制和決策點(diǎn)。在一個(gè)好的因子化的程序結(jié)構(gòu)中

78、，決策的確定性往往發(fā)生在層次結(jié)構(gòu)中的高層，因此首先會(huì)被逮到。如果主控制的確存在問(wèn)題，盡早地發(fā)現(xiàn)它是很重要的。如果選擇了深度優(yōu)先集成，軟件的某個(gè)完整的功能會(huì)被實(shí)現(xiàn)和證明，例如，考慮一個(gè)經(jīng)典的事務(wù)性結(jié)構(gòu)，在這個(gè)結(jié)構(gòu)中，有一系列復(fù)雜的交互式輸入要通過(guò)一條輸入路徑請(qǐng)求、獲得和驗(yàn)證，這條輸入路徑就可以用自頂向下的方式來(lái)進(jìn)行集成。所有輸入處理（為了后續(xù)的事務(wù)分派）可以在其他結(jié)構(gòu)元素被集成前展示出來(lái)。早期的對(duì)功能性的戰(zhàn)士對(duì)開發(fā)人員和客戶來(lái)說(shuō)都是會(huì)增加

79、信心的。</p><p>　　自頂向下策略似乎相對(duì)來(lái)說(shuō)不是很復(fù)雜，但是在實(shí)踐過(guò)程中，可能會(huì)出現(xiàn)邏輯上的問(wèn)題。最普通的這類問(wèn)題出現(xiàn)在當(dāng)高層測(cè)試需要首先對(duì)較低層次的足夠測(cè)試后才能完成的時(shí)候。在自頂向下測(cè)試開始的時(shí)候，樁模塊代替了底層的模塊，因此，在程序結(jié)構(gòu)中就不會(huì)有重要的數(shù)據(jù)項(xiàng)上傳遞，測(cè)試者只有下面的三種選擇：一是把測(cè)試推辭到樁模塊被換成實(shí)際的模塊之后再進(jìn)行，而是開發(fā)能夠?qū)崿F(xiàn)有限功能的用來(lái)模擬實(shí)際模塊的樁模塊，三是從

80、層次結(jié)構(gòu)的最高底部向上來(lái)對(duì)軟件進(jìn)行集成。</p><p>　　第一種實(shí)現(xiàn)方法（把測(cè)試推遲到樁模塊被換成實(shí)際的模塊之后再進(jìn)行）使我們失去了對(duì)許多在特定測(cè)試和特定模塊組合之間的對(duì)應(yīng)性的控制，這樣可能導(dǎo)致在確定錯(cuò)誤發(fā)生原因是的困難性，并且會(huì)違背自頂向下方法的高度受限的本質(zhì)。第二種方法是可行的，但是會(huì)導(dǎo)致很大的額外開銷，因?yàn)闃赌K會(huì)變得越來(lái)越復(fù)雜。第三種方法，也就是自底向上測(cè)試。</p><p>

81、　　1.2 自底向上集成</p><p>　　顧名思義，自底向上集成測(cè)試是從原子模塊（比如在程序結(jié)構(gòu)的最低層的模塊）開始來(lái)進(jìn)行構(gòu)造和測(cè)試的，因?yàn)槟K時(shí)自底向上集成的，在進(jìn)行時(shí)要求所有從屬于某個(gè)給定層次的模塊總是存在的，而且也不再有使用樁模塊的必要。</p><p>　　自底向上集成策略可以使用下列步驟來(lái)實(shí)現(xiàn)：</p><p>　　1低層構(gòu)件被組合成能夠?qū)崿F(xiàn)軟件特

82、定子功能的簇（又使也稱為結(jié)構(gòu)）。</p><p>　　2寫一個(gè)驅(qū)動(dòng)程序（一個(gè)供測(cè)試用的控制程序）來(lái)協(xié)調(diào)測(cè)試案例的輸入和輸出。</p><p><b>　　3對(duì)簇進(jìn)行測(cè)試。</b></p><p>　　4移走驅(qū)動(dòng)程序，沿著程序結(jié)構(gòu)的層次向上對(duì)簇進(jìn)行組合。</p><p>　　這樣的集成首先把所有的構(gòu)件舉集成三個(gè)簇1，2，3

83、，然后用對(duì)每一個(gè)促使用驅(qū)動(dòng)程序進(jìn)行測(cè)試，在簇1和簇2中的構(gòu)件從屬于M1,把驅(qū)動(dòng)程序中的D1和D2去掉，然后把這兩個(gè)簇和M1直接連在一起。類似地，驅(qū)動(dòng)程序D3也在模塊M2集成之前去掉，M1和M2最后都要和模塊M3一起進(jìn)行集成，依此類推。</p><p>　　當(dāng)集成在向上進(jìn)行的過(guò)程中，對(duì)單獨(dú)的測(cè)試驅(qū)動(dòng)程序的需求減少了，事實(shí)上，如果程序結(jié)構(gòu)的最上兩層時(shí)自頂向下集成的，那么所需的驅(qū)動(dòng)程序樹木就會(huì)明顯的減少，而且簇的集成也

84、會(huì)明顯簡(jiǎn)化。</p><p>　　1.3 回歸測(cè)試</p><p>　　每當(dāng)一個(gè)新的模塊被當(dāng)作集成測(cè)試的一部分加進(jìn)來(lái)的時(shí)候，軟件就發(fā)生了改變。新的數(shù)據(jù)流路徑被建立起來(lái)，薪的I/O操作可能也會(huì)出現(xiàn)，還有可能激活了新的控制邏輯。這些改變可能會(huì)使原本工作得很正常的功能產(chǎn)生錯(cuò)誤。在集成測(cè)試策略的環(huán)境中，回歸測(cè)試是對(duì)某些已經(jīng)進(jìn)行過(guò)的測(cè)試的子集的重新執(zhí)行，以保證上述改變不會(huì)傳播無(wú)法預(yù)料的副作用。&

85、lt;/p><p>　　在更廣闊的環(huán)境里，（任何種類的）成功測(cè)試結(jié)果都是發(fā)現(xiàn)錯(cuò)誤，而錯(cuò)誤是要被修改的，每當(dāng)軟件被修改時(shí)，軟件配置的某些方面（程序、文檔、或者數(shù)據(jù)）也被修改了，回歸測(cè)試就是用來(lái)保證（由于測(cè)試或者其他原因的）改動(dòng)不會(huì)帶來(lái)不可預(yù)料的行為或者附加的錯(cuò)誤。</p><p>　　回歸測(cè)試可以通過(guò)重新執(zhí)行所有的測(cè)試案例的一個(gè)子集人工地進(jìn)行，也可以使用自動(dòng)化的捕獲/回放工具來(lái)進(jìn)行。捕獲/回訪工

86、具是軟件工程師能夠不活到測(cè)試案例，然后可以進(jìn)行回放和比較。</p><p>　　回歸測(cè)試集（要進(jìn)行的測(cè)試的子集）包括三種不同類型的測(cè)試案例：</p><p>　　1.能夠測(cè)試軟件的所有功能的代表性測(cè)試案例。</p><p>　　2.專門針對(duì)可能被修改影響的軟件功能的附加測(cè)試。</p><p>　　3.注重于修改過(guò)的軟件構(gòu)件的測(cè)試。</p

87、><p>　　在集成測(cè)試進(jìn)行的 ，就對(duì)每一個(gè)程序功能都重新執(zhí)行所有的測(cè)試是不實(shí)際的而且也是效率很低的。</p><p>　　1.4 關(guān)于集成測(cè)試的討論</p><p>　　關(guān)于自頂向下和自底向上的集成測(cè)試的相對(duì)優(yōu)缺點(diǎn)由許多的討論，總的來(lái)說(shuō)，一種策略的優(yōu)點(diǎn)差不多就是另一種策略的缺點(diǎn)。自頂向下的方法的胡耀缺點(diǎn)是需要樁模塊和與樁模塊有關(guān)的附加測(cè)試?yán)щy。和樁模塊有關(guān)的問(wèn)題

88、可以被主要控制功能的盡早測(cè)試來(lái)抵消。吱地向上集成的主要缺點(diǎn)就是“直到最后一個(gè)模塊倍加進(jìn)去之后才能看到整個(gè)的程序框架”該缺點(diǎn)又簡(jiǎn)單的測(cè)試案例設(shè)計(jì)和不用樁模塊來(lái)彌補(bǔ)的。</p><p>　　集成策略的選擇依賴于軟件的特性，有的時(shí)候還依賴于項(xiàng)目的進(jìn)度安排。總的來(lái)說(shuō)，一種組合策略（有的時(shí)候被稱是三明治測(cè)試）可能是最好的折衷：在程序結(jié)構(gòu)的高層使用自頂向下策略，而在下面的較低層中使用自底向上策略。</p>&l

89、t;p>　　當(dāng)集成測(cè)試進(jìn)行時(shí)，測(cè)試人員應(yīng)當(dāng)能夠識(shí)別關(guān)鍵模塊。關(guān)鍵模塊具有一個(gè)或多個(gè)下列特性：1 和好幾個(gè)軟件需求有關(guān)；2 含有高層控制（位于程序結(jié)構(gòu)的高層）；3 本身是復(fù)雜的或者時(shí)容易出錯(cuò)的；4 含有確定性的性能需求。關(guān)鍵模塊應(yīng)當(dāng)盡可能早地進(jìn)行測(cè)試，另外，回歸測(cè)試也應(yīng)當(dāng)集中在關(guān)鍵模塊的功能上。</p><p><b>　　二 系統(tǒng)測(cè)試</b></p><p&g

90、t;　　系統(tǒng)測(cè)試事實(shí)上時(shí)對(duì)整個(gè)給予計(jì)算機(jī)的系統(tǒng)進(jìn)行考驗(yàn)的一系列不同測(cè)試。雖然每一個(gè)測(cè)試都有不同的目的，但所有測(cè)試都是為了整個(gè)系統(tǒng)成分能正常地集成到一起并且完成分配的功能。</p><p><b>　　2.1 恢復(fù)測(cè)試</b></p><p>　　許多基于計(jì)算機(jī)的系統(tǒng)必須在一定的時(shí)間內(nèi)從錯(cuò)誤中恢復(fù)歸來(lái)，然后繼續(xù)運(yùn)行。在有些情況下，一個(gè)系統(tǒng)必須是可以容錯(cuò)的，這就是說(shuō)，運(yùn)

91、行過(guò)程中錯(cuò)誤必須不能使整個(gè)系統(tǒng)的功能都停止。在其他情況下，一個(gè)系統(tǒng)錯(cuò)誤必須在一個(gè)特定的時(shí)間段之內(nèi)改正，否則就會(huì)產(chǎn)生嚴(yán)重的經(jīng)濟(jì)損失。</p><p>　　恢復(fù)測(cè)試是通過(guò)各種手段，讓軟件強(qiáng)制性地以一系列不同方式發(fā)生故障，然后來(lái)驗(yàn)證恢復(fù)是否能正常進(jìn)行的一種系統(tǒng)測(cè)試方法。如果恢復(fù)時(shí)自懂得（由系統(tǒng)本身來(lái)進(jìn)行的），重新初始化、檢查點(diǎn)機(jī)制、數(shù)據(jù)恢復(fù)和重啟動(dòng)都要進(jìn)行正確驗(yàn)證。如果恢復(fù)是需要人工干預(yù)的，那么要估計(jì)平均修復(fù)時(shí)間是否在

92、可以接受的范圍內(nèi)。</p><p><b>　　2.2 安全測(cè)試</b></p><p>　　任何管理敏感信息或者能夠?qū)€(gè)人造成不正當(dāng)傷害（或好處）的計(jì)算機(jī)系統(tǒng)都是不正當(dāng)或非法侵入的目標(biāo)。侵入包括了范圍很廣的活動(dòng)：只是為了練習(xí)而試圖侵入系統(tǒng)的黑客，是為了報(bào)復(fù)而試圖攻破系統(tǒng)的由怨言的雇員，還有為了得到非法利益而試圖侵入系統(tǒng)的不誠(chéng)實(shí)的個(gè)人。</p><

93、p>　　安全測(cè)試用來(lái)驗(yàn)證集成在系統(tǒng)內(nèi)的保護(hù)機(jī)制是否能夠?qū)嶋H保護(hù)系統(tǒng)不受非法侵入。在安</p><p>　　全測(cè)試過(guò)程中，測(cè)試者扮演著一個(gè)試圖攻擊系統(tǒng)的個(gè)人角色。就是這樣！測(cè)試者可以場(chǎng)失去通過(guò)外部的手段來(lái)獲取系統(tǒng)的密碼，可以使用可以瓦解任何防守的客戶軟件來(lái)攻擊系統(tǒng)；可以通過(guò)瀏覽非保密的數(shù)據(jù)，從中找到進(jìn)入系統(tǒng)的鑰匙；等等。</p><p>　　只要有足夠的時(shí)間和資源，好的安全測(cè)試就一定能

94、夠侵入一個(gè)系統(tǒng)。系統(tǒng)設(shè)計(jì)者的任務(wù)就是要把系統(tǒng)設(shè)計(jì)為要攻破系統(tǒng)而付出的代價(jià)大于攻破系統(tǒng)后得到信息的價(jià)值。</p><p><b>　　2.3壓力測(cè)試</b></p><p>　　在較早的軟件測(cè)試步驟中，百盒和黑盒技術(shù)對(duì)正常的程序功能和性能進(jìn)行了詳盡的查應(yīng)力測(cè)試的目的是要處理正常的情形。在本質(zhì)上說(shuō)，進(jìn)行壓力測(cè)試的人會(huì)這樣問(wèn)：“我們能夠?qū)⑾到y(tǒng)折騰到什么程度而又不會(huì)出錯(cuò)呢？”

95、</p><p>　　壓力測(cè)試是在一種需要反常數(shù)量、頻率或容量的方式下執(zhí)行系統(tǒng)。例如：1 當(dāng)平均每秒1個(gè)或2個(gè)中斷的情形下，應(yīng)當(dāng)對(duì)每秒10個(gè)中斷的情形來(lái)進(jìn)行特殊測(cè)試；2 把輸入數(shù)據(jù)的量提高一個(gè)量級(jí)來(lái)測(cè)試輸入功能會(huì)如何響應(yīng)；3 應(yīng)當(dāng)執(zhí)行需要最大的內(nèi)存或其他資源的測(cè)試實(shí)例；4 實(shí)用在一個(gè)虛擬的操作系統(tǒng)中會(huì)引起顛簸的測(cè)試實(shí)例；5 可能會(huì)引起大量的磁盤駐留數(shù)據(jù)的測(cè)試實(shí)例。從本質(zhì)上說(shuō)，測(cè)試這是想要破壞程序。</p&g

96、t;<p>　　壓力測(cè)試的一個(gè)變體是一種被稱為敏感性測(cè)的技術(shù)。在有些情況下（最常見的是在數(shù)學(xué)算法中），在有效數(shù)據(jù)界限之內(nèi)的一個(gè)很小的范圍的數(shù)據(jù)可能會(huì)引起極端的甚至是錯(cuò)誤的運(yùn)行或者引起性能的急劇下降。敏感性測(cè)試就是要發(fā)現(xiàn)在有效數(shù)據(jù)輸入類中的可能會(huì)引起不穩(wěn)定或者錯(cuò)誤處理的數(shù)據(jù)組合。</p><p>　　2.4 性能測(cè)試</p><p>　　在實(shí)時(shí)系統(tǒng)和嵌入系統(tǒng)中，提高符合功能