外文翻譯---軟件測試策略

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

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

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

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

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

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

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

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

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

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

80、層次結構的最高底部向上來對軟件進行集成。</p><p>　　第一種實現(xiàn)方法（把測試推遲到樁模塊被換成實際的模塊之后再進行）使我們失去了對許多在特定測試和特定模塊組合之間的對應性的控制，這樣可能導致在確定錯誤發(fā)生原因是的困難性，并且會違背自頂向下方法的高度受限的本質。第二種方法是可行的，但是會導致很大的額外開銷，因為樁模塊會變得越來越復雜。第三種方法，也就是自底向上測試。</p><p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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