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

2、內部的結構測試檢查程序。灰盒測試，是介于白盒測試和黑盒測試二者之間的，灰盒測試關注輸出對于輸入的正確性，同時也關注內部表現。 關鍵字 ： 測試 軟件測試測試方法測試流程白盒測試黑盒測試灰盒測試軟件開發。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.一、 軟件測試概述( 一 ) 、定義軟件測試是軟件開發過程的重要組成部分，是用來確認一個程序的品質或性能是否符合開發之前所提出的一些要求。軟件測試的目的，第一是確認軟件的質量，其一

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

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

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

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

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

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

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

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

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

16、分析、因果圖、錯誤推測等，主要用于軟件確認測試。 “黑盒”法著眼于程序外部結構、不考慮內部邏輯結構、針對軟件界面和軟件功能進行測試。 “黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入， 而且還要對那些不合法但是可能的輸入進行測試。通常測試者在進行測試時不僅使用肯定出正確結果的輸入數據，而且還會使用有挑戰性的輸入數據以及可能結果會出錯的輸入數據以便了解軟件怎樣處理各種類型的數據。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 所選單元格中正確地插入符號并且顯示正確符號？能否正確顯示使用不同的字體的符號？可接受性測試：是在把測試的版本交付測試部門大范圍測試以前進行的對最基本功能的簡單測試。因為在把測試的版本交付測試部門大范圍測試以前應該先驗證該版本對于所測試的功能基本上比較穩定。必須滿足一些最低要求。比如不會很容易程序就掛起或崩潰。如果一個新版本沒通過可測試性的驗證，就應該阻攔測試部門花時間在該測試版本上測試。同時 還要找到造成該版本不穩定

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

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

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

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

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

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

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

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

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

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

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

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

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

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