軟件評價與測試論文

1、軟件評價與測試論文課程名稱：軟件評價與測試教師：楚燕婷專業(yè)：軟件工程班級：051 班姓名：付欣欣學號：01軟件測試技術 摘要 ： 軟件測試是軟件開發(fā)過程的重要組成部分，是用來確認一個程序的品質或性能是否符合開發(fā)之前所提出的一些要求。軟件測試總的目的是確保軟件的質量。前后要經(jīng)過以下一些主要環(huán)節(jié)：需求分析測試計劃測試設計測試環(huán)境搭建測試執(zhí)行測試記錄缺陷管理軟件評估RTM. 黑盒測試顧名思義就是將被測系統(tǒng)看成一個黑盒，從外界取得輸入，然后再輸出。白盒測試是通過程序的源代碼進行測試而不使用用戶界面。白盒測試是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進行， 按照程序

2、內(nèi)部的結構測試檢查程序?；液袦y試，是介于白盒測試和黑盒測試二者之間的，灰盒測試關注輸出對于輸入的正確性，同時也關注內(nèi)部表現(xiàn)。 關鍵字 ： 測試 軟件測試測試方法測試流程白盒測試黑盒測試灰盒測試軟件開發(fā)。Abstract ： Software testing software development process is animportant part of a procedure is used to confirm the quality or performance is in line with the proposed development before some of the r

3、equirements. The purpose of software testing is to ensure that the quality of software.Before and after to go through the following major components: needsanalysis test plan design test test test the implementation ofenvironmental structures test records defectmanagement software assessment RTM. Bla

4、ck Box Testing will be tested as its name suggests is the system as a black box from the outside world to enter, and thenoutput. Baiheceshi through the programs source code for testing without the use of user interface. Baiheceshi Products are aware of the internal work processes, products pass the

5、test to detect whether internal action in accordance with the provisions of the normal specification, in accordance with the internal structure of the testing procedures. Greybox testing, and Black Box Testing is between Baiheceshi between the two, gray box test of concern for the importation of the

6、 correctness of output, but also concerned about internal performance.Keywords: testing software testing testing method testing process white Box Testing Black Box Testing gray box testing software development.一、 軟件測試概述( 一 ) 、定義軟件測試是軟件開發(fā)過程的重要組成部分，是用來確認一個程序的品質或性能是否符合開發(fā)之前所提出的一些要求。軟件測試的目的，第一是確認軟件的質量，其一

7、方面是確認軟件做了你所期望的事情(Do the right thing )，另一方面是確認軟件以正確的方式來做了這個事件(Do it right )。第二是提供信息，比如提供給開發(fā)人員或程序經(jīng)理的反饋信息，為風險評估所準備的信息。第三軟件測試不僅是在測試軟件產(chǎn)品的本身，而且還包括軟件開發(fā)的過程。如果一個軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題，這說明此軟件開發(fā)過程很可能是有缺陷的。因此軟件測試的第三個目的是保證整個軟件開發(fā)過程是高質量的。軟件質量是由幾個方面來衡量的：1、在正確的時間用正確的的方法把一個工作做正確(Doing the right things rightat the right ti

8、me. )。2、符合一些應用標準的要求，比如不同國家的用戶不同的操作習慣和要求，項目工程中的可維護性、可測試性等要求。3、質量本身就是軟件達到了最開始所設定的要求，而代碼的優(yōu)美或精巧的技巧并不代表軟件的高質量(Quality is defined as conformance to requirements, not as“ goodness” or “ elegance ” . ) 。 四、 質量也代表著它符合客戶的需要( Quality also means“ meet customer needs” . )。作為軟件測試這個行業(yè)，最重要的一件事就是從客戶的需求出發(fā)， 從客戶的角度去看產(chǎn)品

9、，客戶會怎么去使用這個產(chǎn)品，使用過程中會遇到什么樣的問題。只有這些問題都解決了，軟件產(chǎn)品的質量才可以說是上去了。(二)、測試任務測試人員在軟件開發(fā)過程中的任務：1、尋找 Bug；2、避免軟件開發(fā)過程中的缺陷；3、衡量軟件的品質；4、關注用戶的需求。（三）、軟件測試的目的軟件測試是程序的一種執(zhí)行過程，目的是盡可能發(fā)現(xiàn)并改正被測試軟件中的錯誤，提高軟件的可靠性。它是軟件生命周期中一項非常重要且非常復雜的工作，對軟件可靠性保證具有極其重要的意義。在目前形式化方法和程序正確性證明技術還無望成為實用性方法的情況下， 軟件測試在將來相當一段時間內(nèi)仍然是軟件可靠性保證的有效方法。軟件工程的總目標是充分利用有

10、限的人力和物力資源，高效率、高質量地完成軟件開發(fā)項目。不足的測試勢必使軟件帶著一些未揭露的隱藏錯誤投入運行，這將意味著更大的危險讓用戶承擔。過度測試則會浪費許多寶貴的資源。到測試后期，即使找到了錯誤，然而付出了過高的代價。E.W.Dijkstra 的一句名言說明了這一道理：“程序測試只能表明錯誤的存在，而不能表明錯誤不存在?！笨梢?，測試是為了使軟件中蘊涵的缺陷低于某一特定值，使產(chǎn)出、 投入比達到最大?？偟哪繕耸牵捍_保軟件的質量。二、軟件測試流程一般而言，軟件測試從項目確立時就開始了，前后要經(jīng)過以下一些主要環(huán)節(jié)：需求分析測試計劃測試設計測試環(huán)境搭建測試執(zhí)行測試記錄缺陷管理軟件評估RTM.在進行有

11、關問題闡述前，需要先明確下分工，一般而言，需求分析、測試用例編寫、測試環(huán)境搭建、測試執(zhí)行等屬于測試開發(fā)人員工作范疇，而測試執(zhí)行以及缺陷提交等屬于普通測試人員的工作范疇，測試負責人負責整個測試各個環(huán)節(jié)的跟蹤、實施、管理等。測試流程就是指從軟件測試開始到軟件測試結束經(jīng)過的一系列準備、執(zhí)行、 分析的過程。測試流程并不是只存在于有完整測試團隊的公司，它分布在每一個對軟件執(zhí)行測試的公司中，哪怕這個公司只有一個測試人員。制定合理的測試流程需要考慮的因素很多，畢竟它是大家進行測試工作的依據(jù)，又需要理清和需求人員、開發(fā)人員、市場人員等多方人員的關系，而且公司不同側重點又有所不同。制定測試流程首先要清楚自己所在

12、的公司正處在什么發(fā)展階段，是處在最初的創(chuàng)業(yè)期還是已經(jīng)度過了創(chuàng)業(yè)期希望通過測試來提高產(chǎn)品質量，以便取得更多的業(yè)務創(chuàng)造更大的效益。為什么制定流程時要這么重視公司的發(fā)展情況呢。其實公司的情況和制定測試流程有非常大的聯(lián)系， 公司的情況直接決定著公司對產(chǎn)品的要求，而測試部門一般來說是產(chǎn)品投入市場的最后一個關口，這也就等于公司的發(fā)展情況決定了公司對測試部門的要求。開發(fā)軟件前要先了解軟件的需求，制定測試流程前當然也要了解清楚公司對測試部門的需求。了解了公司的情況和要求后，就要根據(jù)這些要求結合制定者的測試知識和經(jīng)驗，制定即符合公司要求又能起到軟件測試目的的軟件測試流程。當然這樣做并不是說讓軟件測試向公司的一些

13、不利于開展軟件測試工作的現(xiàn)實情況妥協(xié)，只是根據(jù)公司的實際情況制定一些可以馬上改變公司測試工作現(xiàn)狀的流程。制定軟件測試流程要明確測試部門的職責。經(jīng)常會有測試人員抱怨自己在公司里就是一個打雜的，什么工作都要做，其實這就是職責不明確引起的問題，這樣會很大程度打擊測試人員的工作積極性影響工作情況進而影響大家對軟件測試工作的看法。制定軟件測試流程不光要制定軟件測試部門內(nèi)部的工作流程，更要制定與開發(fā)部門、需求部門等外部部門的接口工作的流程，一旦項目在進度、功能上有了變化要及時和測試部門溝通，不要讓測試部門成為最后一個知情人。制定合理的軟件測試流程是一門很深的學問，它需要制定者有豐富的軟件測試理論知還需要許

14、多測試人識， 軟件測試執(zhí)行經(jīng)驗、管理經(jīng)驗以及溝通能力等等多方面的經(jīng)驗能力，還需要許多測試人員經(jīng)過長時間的實踐來驗證完善。三、常用的軟件測試方法軟件測試方法之所以沒能完全標準化和統(tǒng)一化，主要原因是因為軟件產(chǎn)業(yè)產(chǎn)品到軟件測試有各式各樣的軟件。但是目前仍有很多各樣軟件測試方法都基本可用的常用概念和方法。因此，這里只討論幾種常用的軟件測試方法：( 一 ) 、 黑盒測試1、黑盒測試的定義黑盒測試顧名思義就是將被測系統(tǒng)看成一個黑盒，從外界取得輸入，然后再輸出。整個測試基于需求文檔，看是否能滿足需求文檔中的所有要求。黑盒測試要求測試者在測試時不能使用與被測系統(tǒng)內(nèi)部結構相關的知識或經(jīng)驗，它適用于對系統(tǒng)的功能進

15、行測試。黑盒測試也稱功能測試或數(shù)據(jù)驅動測試，它是在已知產(chǎn)品所應具有的功能，通過使用整個軟件或某種軟件功能來嚴格地測試來檢測每個功能是否都能正常使用，而并沒有通過檢查程序的源代碼或者很清楚地了解該軟件或某種軟件功能的源代碼程序具體是怎樣設計的。測試人員通過輸入他們的數(shù)據(jù)然后看輸出的結果從而了解軟件怎樣工作。在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內(nèi)部結構和內(nèi)部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息(如數(shù)據(jù)庫或文件)的完整性。黑盒測試方法主要有等價類劃分、邊值

16、分析、因果圖、錯誤推測等，主要用于軟件確認測試。 “黑盒”法著眼于程序外部結構、不考慮內(nèi)部邏輯結構、針對軟件界面和軟件功能進行測試。 “黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入， 而且還要對那些不合法但是可能的輸入進行測試。通常測試者在進行測試時不僅使用肯定出正確結果的輸入數(shù)據(jù)，而且還會使用有挑戰(zhàn)性的輸入數(shù)據(jù)以及可能結果會出錯的輸入數(shù)據(jù)以便了解軟件怎樣處理各種類型的數(shù)據(jù)。2、分類側重于軟件功能的黑箱測試方法主要有：功能測試(Functionality Test )，可接受性測試(

17、Acceptance Test )，用戶界面(User interface 或 UI) 測試， Ad hoc 一般指探討或開放型測試，邊界條件測試( Boundary Condition )，性能測試(Performance Test)，回歸測試 ( Regression Test) ， 強力測試 ( Stress Test) ， 配置和安裝測試( Configurationand Setup Test )，兼容性測試(Comparability Test )，國際化支持測試(InternationalSufficiency )以及本地化語言測試(Localization )。功能測試：驗證測

18、試軟件功能能否正常按照它的設計工作?？催\行軟件時的期望行為是否符合原設計。比如，測試Microsoft Excel 插入 - 符號的功能包括測試能夠在MicrosoftExcel 所選單元格中正確地插入符號并且顯示正確符號？能否正確顯示使用不同的字體的符號？可接受性測試：是在把測試的版本交付測試部門大范圍測試以前進行的對最基本功能的簡單測試。因為在把測試的版本交付測試部門大范圍測試以前應該先驗證該版本對于所測試的功能基本上比較穩(wěn)定。必須滿足一些最低要求。比如不會很容易程序就掛起或崩潰。如果一個新版本沒通過可測試性的驗證，就應該阻攔測試部門花時間在該測試版本上測試。同時 還要找到造成該版本不穩(wěn)定

19、的主要缺陷并督促盡快加以修正。用戶界面測試：分析軟件用戶界面的設計是否合乎用戶期望或要求。它常常包括菜單，對話框及對話框上所有按鈕，文字，出錯提示，幫助信息(Menu 和 Help content )等方面的測試。比如，測試Microsoft Excel 中插入符號功能所用的對話框的大小，所有按鈕是否對齊，字符串字體大小，出錯信息內(nèi)容和字體大小，工具欄位置/ 圖標等等。探索或開放型的測試：不是按部就班的按照一個又一個正式的測試用例來進行，也不局限于測試用例特定的步驟。這種測試是測試人員在理解該軟件功能的基礎上運用靈活多樣的想象力和創(chuàng)造力去模擬用戶的需求來使用該軟件的多種功能。通常涉及很多的測試

20、用例或者通過更復雜的步驟來使用該軟件。邊界條件測試：是環(huán)繞邊界值的測試。通常意味著測試軟件各功能是否能正確處理最大值，最小值或者所設計軟件能夠處理的最長的字符串等等。性能測試是：通常驗證軟件的性能在正常環(huán)境和系統(tǒng)條件下重復使用是否還能滿足性能指標。 或者執(zhí)行同樣任務時新版本不比舊版本慢。一般還檢查系統(tǒng)記憶容量在運行程序時會不會流失(memory leak )。比如，驗證程序保存一個巨大的文件新版本不比舊版本慢?；貧w測試：根據(jù)修復好了的缺陷再重新進行的測試。目的在于驗證以前出現(xiàn)過但已經(jīng)修復好的缺陷不再重新出現(xiàn)。一般指對某已知修正的缺陷再次圍繞它原來出現(xiàn)時的步驟重新測試。 通常確定所需的再測試的范

21、圍時是比較困難的，特別當臨近產(chǎn)品發(fā)布日期時。因為為了修正某缺陷時必需更改源代碼，因而就有可能影響這部分源代碼所控制的功能。所以在驗證修好的缺陷時不僅要服從缺陷原來出現(xiàn)時的步驟重新測試，而且還要測試有可能受影響的所有功能。因此應當鼓勵對所有回歸測試用例進行自動化。強力測試：它通常驗證軟件的性能在各種極端的環(huán)境和系統(tǒng)條件下是否還能正常工作。或者說是驗證軟件的性能在各種極端環(huán)境和系統(tǒng)條件下的承受能力。比如， 在最低的硬盤驅動器空間或系統(tǒng)記憶容量條件下，驗證程序重復執(zhí)行打開和保存一個巨大的文件1000 次后也不會崩潰或死機。集成與兼容性測試：驗證該功能能夠如預期的那樣與其他程序或者構件協(xié)調工作。兼容性

22、經(jīng)常意味著新舊版本之間的協(xié)調，也包括測試的產(chǎn)品與其它產(chǎn)品的兼容使用。比如用同樣產(chǎn)品的新版本時不影響與用舊版本用戶之間保存文件，格式，和其他數(shù)據(jù)等操作。裝配/安裝/配置測試：驗證軟件程序在不同廠家的硬件上，所支持的不同語言的新舊版本平臺上，和不同方式安裝的軟件都能夠如預期的那樣正確運行。比如，把英文版的Microsoft Office 2003 安裝在韓文版的 Windows Me 上，再驗證所有功能都正常運行。國際化支持測試：驗證軟件程序在不同國家或區(qū)域的平臺上也能夠如預期的那樣運行，而且還可以按照原設計尊重和支持使用當?shù)爻Ｓ玫娜掌冢煮w，文字表示，特殊格式等等。比如，用英文版的Windows

23、 XP 和 Microsoft Word 能否展示阿拉伯字符串？用阿拉伯版的Windows XP 和 阿拉伯版的Microsoft Word 能否展示阿拉伯字符串？又比如，日文版的Microsoft Excel 對話框是否顯示正確翻譯的日語？一旦來說執(zhí)行國際化支持測試的測試人員往往需要基本上了解這些國家或地區(qū)的語言要求和期望行為是什么。本地化語言測試：要驗證所有已計劃要發(fā)布的不同語言版本軟件如預期的那樣被正確地翻譯成當?shù)卣Z言。這類測試一般包括驗證菜單，對話框，出錯信息，幫助內(nèi)容等所有用戶界面上的文字都能夠顯示正確翻譯好的當?shù)匚淖帧?、黑盒測試的優(yōu)點有：1)比較簡單，不需要了解程序內(nèi)部的代碼及實

24、現(xiàn)；2)與軟件的內(nèi)部實現(xiàn)無關；3)從用戶角度出發(fā)，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；4)基于軟件開發(fā)文檔，所以也能知道軟件實現(xiàn)了文檔中的哪些功能；5)在做軟件自動化測試時較為方便。4、黑盒測試的缺點有：1)不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的30%；2)自動化測試的復用性較低。( 二 ) 、白盒測試1、定義白箱測試或白盒測試(White-box testing 或 glass-box testing )也稱結構測試或邏輯驅動測試，它是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進行，按照程序內(nèi)部的結構測試程序，檢驗程序中的每

25、條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用于軟件驗證。“白盒”法全面了解程序內(nèi)部邏輯結構、對所有邏輯路徑進行測試。 “白盒”法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內(nèi)部結構，從檢查程序的邏輯著手，得出測試數(shù)據(jù)。貫穿程序的獨立路徑數(shù)是天文數(shù)字。但即使每條路徑都測試了仍然可能有錯誤：1)窮舉路徑測試決不能查出程序違反了設計規(guī)范，即程序本身是個錯誤的程序。窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。窮舉路徑測試可能發(fā)現(xiàn)不了一些與數(shù)據(jù)相關的錯誤。白盒測試是通過程序的源代碼進行測試而不使用用戶界面。這種類型的測試需要從代碼句法發(fā)

26、現(xiàn)內(nèi)部代碼在算法，溢出，路徑，條件等等中的缺點或者錯誤，進而加以修正。它在測試時能夠了解被測對象的結構，可以查閱被測代碼內(nèi)容的測試工作。它需要知道程序內(nèi)部的設計結構及具體的代碼實現(xiàn)，并以此為基礎來設計測試用例。如下例程序代碼：HRESULT Play( char* pszFileName )if ( NULL = pszFileName ) return;if ( STATE_OPENED = currentState )PlayTheFile();return;讀了代碼之后可以知道，先要檢查一個字符串是否為空，然后再根據(jù)播放器當前的狀態(tài)來執(zhí)行相應的動作?？梢赃@樣設計一些測試用例：比如字符串(

27、文件)為空的話會出現(xiàn)什么情況； 如果此時播放器的狀態(tài)是文件剛打開，會是什么情況；如果文件已經(jīng)在播放，再調用這個函數(shù)會是什么情況。也就是說，根據(jù)播放器內(nèi)部狀態(tài)的不同，可以設計很多不同的測試用例。這些是在純粹做黑盒測試時不一定能做到的事情。白盒測試的直接好處就是知道所設計的測試用例在代碼級上哪些地方被忽略掉，它的優(yōu)點是幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發(fā)現(xiàn)代碼中隱藏的問題。2、白盒測試的缺點有：1)程序運行會有很多不同的路徑，不可能測試所有的運行路徑；2)測試基于代碼，只能測試開發(fā)人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；3)系統(tǒng)龐大時，測試開銷會非常大。3

28、、測試軟件人員使用白盒測試方法，主要想對程序模塊進行如下的檢查： 對程序模塊的所有獨立的執(zhí)行路徑至少測試一次； 對所有的邏輯判定，取“ 真 ” 與取 “ 假 ” 的兩種情況都至少測試一次； 在循環(huán)的邊界和運行界限內(nèi)執(zhí)行循環(huán)體； 測試內(nèi)部數(shù)據(jù)結構的有效性，等。具體包含的邏輯覆蓋有： 語句覆蓋 判定覆蓋 條件覆蓋 判定條件覆蓋條件組合覆蓋 路徑覆蓋。“我們應該更注重于保證程序需求的實現(xiàn)， 為什么要花費時間和精力來擔心（和測試）邏輯細節(jié)？”答案在于軟件自身的缺陷：1）邏輯錯誤和不正確假設與一條程序路徑被運行的可能性成反比。當我們設計和實現(xiàn)主流之外的功能、條件或控制時，錯誤往往開始出現(xiàn)在我們工作中。日

29、常處理往往被很好地了解，而“特殊情況”的處理則難于發(fā)現(xiàn)。2）我們經(jīng)常相信某邏輯路徑不可能被執(zhí)行，而事實上，它可能在正常的基礎上被執(zhí)行。程序的邏輯流有時是違反直覺的，這意味著我們關于控制流和數(shù)據(jù)流的一些無意識的假設可能導致設計錯誤，只有路徑測試才能發(fā)現(xiàn)這些錯誤。3）筆誤是隨機的。當一個程序被翻譯為程序設計語言源代碼時，有可能產(chǎn)生某些筆誤，很多將被語法檢查機制發(fā)現(xiàn)，但是， 其他的會在測試開始時才會被發(fā)現(xiàn)。筆誤出現(xiàn)在主流上和不明顯的邏輯路徑上的機率是一樣的。正如Beizer 所說的：“錯誤潛伏在角落里，聚集在邊界上”，而白盒測試更可能發(fā)現(xiàn)它。（三）、灰盒測試灰箱測試或灰盒測試（Gray-box te

30、sting ）：灰箱測試就像黑箱測試一樣是通過用戶界面測試，但是測試人員已經(jīng)有所了解該軟件或某種軟件功能的源代碼程序具體是怎樣設計的。 甚至于還讀過部分源代碼。因此測試人員可以有的放矢地進行某種確定的條件/ 功能的測試。 這樣做的意義在于：如果你知道產(chǎn)品內(nèi)部的設計和對產(chǎn)品有透過用戶界面的深入了解，你就能夠更有效和深入地從用戶界面來測試它的各項性能。灰盒測試，是介于白盒測試和黑盒測試二者之間的，可以這樣理解，灰盒測試關注輸出對于輸入的正確性，同時也關注內(nèi)部表現(xiàn)，但這種關注不象白盒那樣詳細、完整， 只是通過一些表征性的現(xiàn)象、事件、標志來判斷內(nèi)部的運行狀態(tài)，有時候輸出是正確的，但內(nèi)部其實已經(jīng)錯誤了，

31、這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要采取這樣的一種灰盒的方法。灰盒測試結合了白盒測試盒黑盒測試的要素. 它考慮了用戶端、特定的系統(tǒng)知識和操作環(huán)境。它在系統(tǒng)組件的協(xié)同性環(huán)境中評價應用軟件的設計?；液袦y試由方法和工具組成，這些方法和工具取材于應用程序的內(nèi)部知識盒與之交互的環(huán)境，能夠用于黑盒測試以增強測試效率、錯誤發(fā)現(xiàn)和錯誤分析的效率?；液袦y試涉及輸入和輸出，但使用關于代碼和程序操作等通常在測試人員視野之外的信息設計測試。（四）、基于風險的測試基于風險的測試是指評估測試的優(yōu)先級，先做高優(yōu)先級的測試，如果時間或精力不夠，低優(yōu)先級的測試可以暫時先不做。有如下一個圖，橫軸代表

32、影響，豎軸代表概率，根據(jù)一個軟件的特點來確定：如果一個功能出了問題，它對整個產(chǎn)品的影響有多大，這個功能出問題的概率有多大？如果出問題的概率很大，出了問題對整個產(chǎn)品的影響也很大，那么在測試時就一定要覆蓋到。對于一個用戶很少用到的功能，出問題的概率很小，就算出了問題的影響也不是很大，那么如果時間比較緊的話，就可以考慮不測試。基于風險測試的兩個決定因素就是：該功能出問題對用戶的影響有多大，出問題的概率基于模型的測試模型實際上就是用語言把一個系統(tǒng)的行為描述出來，定義出它可能的各種狀態(tài)，以及它即狀態(tài)轉換圖。模型是系統(tǒng)的抽象?；谀Ｐ偷臏y試是利用模型來生成然后根據(jù)實際結果和原先預想的結果的差異來測試系統(tǒng)，過程如下圖所示。（ 一 ） 、 BVT （Build Verification Test）BVT是在所有開發(fā)工程師都已經(jīng)檢入自己的代碼，項目組編譯生成當天的版本之后進行，主要目的是BVT優(yōu)點是時間短，驗證了軟件