軟體測驗的分類
精通軟體性能測驗與LoadRunner最佳實戰
軟體測驗按照測驗階段、是否運行程式、是否查看源代碼以及其他方式，可以用圖1-1所示來描述軟體測驗的各種分類，
黑盒測驗、白盒測驗與灰盒測驗
1．黑盒測驗
黑盒測驗（Black-box
Testing）是軟體測驗的主要方法之一，也可以稱為功能測驗、資料驅動測驗或基于規格說明的測驗，測驗者不了解程式的內部情況，只知道程式的輸入、輸出和系統的功能，這是從用戶的角度對程式進行的測驗，軟體的黑盒測驗意味著測驗要在軟體的介面處進行，這種方法是把測驗物件看做一個黑盒子，測驗人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能說明，
黑盒測驗的隨機性比較大，在大部分案例執行完成以后，大概能夠測驗40%的功能，據美國一個官方的資料說，20%的問題是在開發程序中發現的；80%的問題是在系統測驗和集成測驗程序中發現的，其中80%的比例我們還是需要再細分，20%的是使用的問題，20%是程式的問題，5%邏輯問題，剩下的都是莫名其妙的問題，這樣的資料對測驗的一個引導是：要想發現更多的問題，需要更多的思考，更多的組合，這樣增加了很多作業量，人們在疲憊地執行著測驗用例，渴望從中發現新的問題，
這樣的用例設計思想使得我們在開發一個大型的產品或者延續性產品的時候，整個測驗用例的延續性很差，重用性也很差，所以我們在這里需要糾正一個概念，黑盒測驗不是簡單地使用，用例設計也不是無謂地組合，
那么如何設計好的測驗用例呢？如何在開發程序中很好地結合2/8原則呢？不可能出現一個完美無瑕的產品，但是作為軟體工程師和軟體測驗工程師，肯定希望自己參與開發的產品穩定、易用并且能夠受到用戶的好評；希望自己參與的產品能夠滿足當前大多數人的需求，是否更合理呢？我相信通過軟體工程師、測驗工程師以及質量保證人員等的不斷努力，我們的軟體產品會讓用戶感到滿意的，
2．白盒測驗
白盒測驗（White-box
Testing）是另一種軟體測驗的主要方法，又稱為結構測驗、邏輯驅動測驗或基于程式本身的測驗，它著重于程式的內部結構及演算法，通常不關心功能與性能指標，軟體的白盒測驗是對軟體的程序性細節做細致的檢查，這種方法是把測驗物件看做一個打開的盒子，它允許白盒測驗人員利用程式內部的邏輯結構及有關資訊，設計或選擇測驗用例，對程式所有邏輯路徑進行測驗，通過在不同點檢查程式狀態，確定實際狀態是否與預期的狀態一致，
白盒測驗是一種基于對源代碼中的控制結構、處理程序等進行分析，檢查程式內部處理是否正確、包括例外處理、陳述句結構、分支、回圈結構等，很多控制軟體，還要考慮有無冗余的代碼，因為程式運行時，可能進入這些代碼而無法再進行正常的執行（如進入了死回圈狀態，程式永遠無法終止），這種測驗要求測驗人員對程式的理解能力和編碼能力很高，需要了解程式的構架、具體需求，以及一些撰寫程式的技巧，能夠檢查一些程式規范，以及指標、變數、陣列越界等問題，使得問題在前期就暴露出來，
白盒測驗一般是以單元或者模塊為基礎的，目前的做法是把它歸結為開發的范疇，通常由資深的程式員、專職的白盒測驗人員或利用專業的代碼分析工具，如Boundchecker、JtestC++ Test等工具，這些工具可以幫助開發人員發現變數沒有初始化、空指標、記憶體泄露以及代碼不規范等問題，
白盒測驗的主要方法包括以下幾種，
1.陳述句覆寫：使得程式中每個陳述句至少都能被執行一次，
2.判定覆寫：使得程式中每個判定至少為真或假各一次，
3.條件覆寫：使得判定中的每個條件獲得各種可能的結果，
4.判定/條件覆寫：同時滿足判斷覆寫和條件覆寫，
5.條件組合覆寫：使得每個判定中條件的各種可能組合都至少出現一次，
3．灰盒測驗
灰盒測驗（Gray-box
Testing）是基于程式運行時刻的外部表現同時又結合程式內部邏輯結構來設計用例，執行程式并采集程式路徑執行資訊和外部用戶介面結果的測驗技術，這種測驗技術介于白盒測驗與黑盒測驗之間，可以這樣理解，灰盒測驗關注輸出對于輸入的正確性，同時也關注內部表現，但這種關注不像白盒那樣詳細、完整，只是通過一些表征性的現象、事件、標志來判斷內部的運行狀態，有時候輸出是正確的，但內部其實已經錯誤了，這種情況非常多，如果每次都通過白盒測驗來操作，效率會很低，因此需要采取這樣的一種灰盒的方法，
灰盒測驗結合了白盒測驗和黑盒測驗的要素，它考慮了用戶端、特定的系統知識和操作環境，
灰盒測驗由方法和工具組成，這些方法和工具取材于應用程式的內部知識和與之互動的環境，能夠用于黑盒測驗以增強測驗效率、錯誤發現和錯誤分析的效率，
灰盒測驗涉及輸入和輸出，但使用關于代碼和程式操作等通常在測驗人員視野之外的資訊設計測驗，
靜態測驗與動態測驗
靜態測驗和動態測驗的概念在很多書中被提到，在這里也給大家介紹一下這兩個概念，
1．靜態測驗
所謂靜態測驗（Static Testing），是指不運行被測驗的軟體，而只是靜態地檢查程式代碼、界面或者檔案中可能存在的錯誤的程序，
從概念中，大家不難發現靜態測驗主要包括三個方面內容的測驗作業，即程式代碼、界面和檔案，
（1）程式代碼測驗：主要是程式員通過代碼檢查、代碼評審等方式，對程式中是否存在編碼不規范、代碼撰寫是否和業務實作不一致，以及代碼中是否有記憶體泄露、空指標等問題的測驗，
（2）界面測驗：主要是指測驗人員從用戶角度出發，根據公司的UI（User Interface，用戶界面）設計規范檢查被測驗軟體的界面是否符合用戶的要求，在這里，非常贊同在開發軟體產品之前，提供一個界面原型給用戶參考，聽取用戶意見，而后不斷完善原型，最后依照通過的原型實作軟體的做法，
（3）檔案測驗：主要是測驗人員對需求規格說明書、用戶手冊是否符合用戶要求的檢查程序，
為了能夠說明靜態測驗是如果進行的，我們現在僅以對程式代碼測驗為例，給大家介紹一下，
首先，請大家看一段由C語言實作的小程式，代碼如下所示：
不知道您看到問題了嗎？如果您對C語言有一定了解的話，應該清楚記憶體申請完成以后，在完成任務后，必須要把申請的記憶體回收，否則就會造成記憶體的泄露發生，從上面的代碼我們不難發現，每次應用msg()函式都會泄露100位元組的記憶體，在記憶體充裕的情況下，一二次泄露是微不足道的，但是連續運算元小時后，特別是在多用戶并發的情況下，持續運行一段時間之后，則即使如此小的泄露也會削弱應用程式的處理能力，最后的結果必將是記憶體資源耗盡！
在實際的C、C++編程中，您在代碼中對記憶體malloc()（分配）以后，在完成任務以后一定要記得把那部分申請的記憶體通過free()給釋放掉，當然您還需要注意應用檔案操作的時候，也要把檔案給關閉，建立一個連接以后也要把連接給關掉等問題，上面提及的情況，如果沒有及時關閉申請的資源同樣是會出現記憶體泄露情況的，
除了上面說到的代碼方面的問題以外，檔案中缺少注釋資訊也是一個問題，大家知道一個軟體在撰寫程序中，通常都是多個人相互協作，每個人撰寫一部分功能模塊，每個人可能都非常清楚自己撰寫模塊的內容，但是有時候難免會碰到您去修改別人代碼的時候（如某個研發人員離職了，您需要維護他撰寫的那部分代碼），這時如果沒有注釋資訊，您可能理解幾十萬、上百萬行的代碼是極其困難的，但是在有注釋的情況下，您就能很快了解作者的意圖，方便后期代碼的維護，
2．動態測驗
與靜態測驗相對應的就是動態測驗，所謂動態測驗（Dynamic
Testing），是指實際運行被測驗的軟體，輸入相應的測驗資料，檢查實際輸出結果是否和預期結果相一致的程序，從靜態測驗和動態測驗的概念我們不難發現，靜態測驗和動態測驗的唯一區別就是是否運行程式，
為了能夠說明動態測驗是如何進行的，我們現在也舉一個具體的實體，給大家介紹一下，以Windows自帶的計算器程式為例，如我們輸入“5＋50＝”，在設計用例的時候，預期結果應該為“，如果結果不等于“則說明程式是錯誤的，請大家參見圖1-2，
單元測驗、集成測驗、系統測驗與驗收測驗
1．單元測驗
單元測驗是測驗程序中的最小粒度，它在執行的程序中緊密地依照程式框架對產品的函式和模塊進行測驗，包含入口和出口的引數，輸入和輸出資訊，錯誤處理資訊，部分邊界數值測驗，
這個部分的測驗作業，目前，在國內大多數情況下是由開發人員進行的，我相信未來的發展應該是測驗工程師來做這個事情，這和目前國內軟體測驗剛剛起步的階段是有密切關系的，隨著軟體行業的蓬勃發展，越來越多的軟體企業已經意識到白盒測驗的重要程度，特別是在軍工、航天以及一些對人身、財產安全影響重大的專案中，白盒測驗的重要意義不言而喻，當然，這樣意義重大的事情，對白盒測驗人員的綜合能力也提出了更高的要求，從業人員必須對需求、系統框架、代碼以及測驗技術等方面都要有深刻的理解，這樣才能發現問題，
還有一種大家坐在一起討論評審的方法，就是當一個模塊給某個開發工程師以后，需要他給大家講解，他要完成這個模塊或者函式的整體流程和思路，進行統一評審，使得問題能夠暴露得更充分些，這樣做的目的有以下幾個原因，第一，使得大家對設計者思路明晰的理解，以便以后呼叫或者配合的時候能夠真切地提出需求或者相對完美配合，第二，在評審的程序中，如果發現問題，那么大家可能沒有遇見過，這樣就會更加提高警惕，如果遇見過，就會回想當時自己怎么解決的或者規避的，使得大家能夠避免錯誤的發生，減少解決問題的周期，第三，可以對平常所犯錯誤進行一個積累，這是生動的教科書，可以使得新的人員在上手的時候就借鑒前人的一些經驗，遇到這樣的問題以后，可以給他們一個解決問題的方法或者方向，
上面給大家介紹了兩種方法，第一種就是通過在開發的程序中進行測驗，由開發（白盒測驗）工程師寫測驗代碼，對所撰寫的函式或者模塊進行測驗；第二種就是通過代碼互評發現問題，將問題進行積累，形成知識積累庫，以便使得其他開發人員在遇到同樣問題時不至于再犯錯誤，
單元測驗非常重要，因為它影響的范圍和寬度比較大，也許由于一個函式或者引數問題，造成后面暴露出很多表象問題出現，而且如果單元測驗做不好，使得集成測驗或者后面系統測驗的壓力很大，這樣專案的費用和進度可能就會受到影響，
對單元測驗，有很多工具可以應用，現在主流是Xunit系列（即針對Java的單元測驗主要用Junit，.Net則有Nunit，Delphi有Dunit等工具），當然，除了Xunit系列的單元測驗工具，也有其他的工具，如Cppunit、Comunit、ParaSoft的Jtest等，測驗人員應該在單元測驗作業中不斷積累作業經驗，不斷加強、改進作業方法，增強單元測驗力度，
保證單元測驗順利進行，需要滲透軟體工程的很多思想，把CMM和跟蹤機制建立起來，把問題進行分類與跟蹤，如果把軟體環節整個活動都滲透了，那么產品質量的意識自然就增強了，
單元測驗做什么呢？
單元測驗主要任務包括：
A.模塊介面測驗；
B.模塊區域資料結構測驗；
C.模塊中所有獨立執行路徑測驗；
D. 模塊的各條錯誤處理路徑測驗；
E. 模塊邊界條件測驗，
（1）模塊介面測驗，
模塊介面測驗是單元測驗的基礎，主要檢查資料能否正確地通過模塊，只有在資料能正確流入、流出模塊的前提下，其他測驗才有意義，
測驗介面正確與否應該考慮下列因素：
A.輸入的實際引數與形式引數的個數是否相同；
B. 輸入的實際引數與形式引數的屬性是否匹配；
C. 輸入的實際引數與形式引數的量綱是否一致；
D. 呼叫其他模塊時所給實際引數的個數是否與被調模塊的形參個數相同；
E. 呼叫其他模塊時所給實際引數的屬性是否與被調模塊的形參屬性匹配；
F.呼叫其他模塊時所給實際引數的量綱是否與被調模塊的形參量綱一致；
G. 呼叫預定義函式時所用引數的個數、屬性和次序是否正確；
H.是否存在與當前入口點無關的引數參考；
I.是否修改了只讀型引數；
對全程變數的定義各模塊是否一致；
是否把某些約束作為引數傳遞，
如果模塊內包括外部輸入輸出，還應該考慮下列因素：
A.檔案屬性是否正確；
B.打開或關閉陳述句是否正確；
C. 格式說明與輸入輸出陳述句是否匹配；
D.緩沖區大小與記錄長度是否匹配；
E. 檔案使用前是否已經打開；
F.是否處理了檔案尾；
.G是否處理了輸入/輸出錯誤；
H. 輸出資訊中是否有文字性錯誤，
（2）區域資料結構測驗，
檢查區域資料結構是為了保證臨時存盤在模塊內的資料在程式執行程序中完整、正確，區域資料結構往往是錯誤的根源，應仔細設計測驗用例，力求發現下面幾類錯誤：
A.不合適或不相容的型別說明；
B.變數無初值；
C. 變數初始化或默認值有錯；
D. 不正確的變數名（拼錯或不正確地截斷）；
F.出現上溢、下溢和地址例外；
G. 除了區域資料結構外，如果可能，單元測驗時還應該查清全域資料（如Fortran的公用區）對模塊的影響，
（3）獨立執行路徑測驗，
在模塊中應對每一條獨立執行路徑進行測驗，單元測驗的基本任務是保證模塊中每條陳述句至少執行一次，此時設計測驗用例是為了發現因錯誤計算、不正確的比較和不適當的控制流造成的錯誤，其中基本路徑測驗和回圈測驗是最常用且最有效的測驗技術，常見的錯誤包括：
A. 誤解或用錯算符優先級；
B. 混合型別運算；
C.變數初值錯；
D.精度不夠；
F.運算式符號錯，
比較判斷與控制流常常緊密相關，測驗用例還應致力于發現下列錯誤：
A. 不同資料型別的物件之間進行比較；
B.錯誤地使用邏輯運算子或優先級；
C. 因計算機表示的局限性，期望理論上相等而實際上不相等的兩個量相等；
D.比較運算或變數出錯；
F. 回圈終止條件或不可能出現；
H. 錯誤地修改了回圈變數，
（4）錯誤處理路徑測驗，
一個好的設計應能預見各種出錯情況，并對這些出錯的情況預設各種出錯處理路徑，出錯處理路徑同樣需要認真測驗，在測驗時應著重檢查下列問題：
A .輸出的出錯資訊難以理解；
B. 記錄的錯誤與實際遇到的錯誤不相符；
C. 在程式自定義的出錯處理段運行之前，系統已介入進行處理；
D.例外處理不當，導致資料不一致等情況發生；
E. 錯誤陳述中未能提供足夠的定位出錯資訊，
（5）邊界條件測驗，
邊界條件測驗是單元測驗中重要的一項任務，眾所周知，軟體經常在邊界上失效，采用邊界值分析技術，針對邊界值及其邊界值的左、右設計測驗用例，很有可能發現新的錯誤，
（6）單元測驗方法，
一般認為單元測驗應緊接在編碼之后，當源程式編制完成并通過復審和編譯檢查，便可開始單元測驗，測驗用例的設計應與復審作業相結合，根據設計資訊選取測驗資料，將增大發現上述各類錯誤的可能性，在確定測驗用例的同時，應給出期望結果，
由于被測驗的模塊往往不是獨立的程式，它處于整個軟體結構的某一層上，被其他模塊呼叫或呼叫其他模塊，其本身不能單獨運行，因此在單元測驗時，應為測驗模塊開發一個驅動（Driver）模塊和（或）若干個樁（Stub）模塊，圖1-3顯示了一般單元測驗的環境，
驅動模塊的作用是用來模擬被測模塊的上級呼叫模塊，功能要比真正的上級模塊簡單得多，它接收測驗資料并將這些資料傳遞到被測驗模塊，被測驗模塊被呼叫后，可以列印“進入-退出”訊息，樁模塊用來代替被測模塊所呼叫的模塊，用以回傳被測模塊所需的資訊，
驅動模塊和樁模塊是測驗使用的軟體，而不是軟體產品的組成部分，其撰寫需要一定的開發費用，若驅動和樁模塊比較簡單，實際開發成本相對低些，遺憾的是，僅用簡單的驅動模塊和樁模塊不能完成某些模塊的測驗任務，這些模塊的單元測驗只能采用后面討論的集成測驗方法，
2．集成測驗
時常有這樣的情況發生，每個模塊都能單獨作業，但這些模塊集成在一起之后卻不能正常作業，其主要原因是模塊相互呼叫時介面會引入許多新問題，例如，資料經過介面可能丟失；一個模塊對另一模塊可能造成不應有的影響；幾個子功能組合起來不能實作主功能；誤差不斷積累，最后，則達到不可接受的程度；全域資料結構出現錯誤等，集成測驗是組裝軟體的系統測驗技術，按設計要求把通過單元測驗的各個模塊組裝在一起之后，進行綜合測驗以便發現與介面有關的各種錯誤，
**集成測驗包括兩種不同方法：非增量式集成和增量式集成，
**研發人員習慣于把所有模塊按設計要求一次全部組裝起來，然后進行整體測驗，這稱為非增量式集成，這種方法容易出現混亂，因為測驗時可能發現一大堆錯誤，為每個錯誤定位和糾正非常困難，并且在改正一個錯誤的同時又可能引入新的錯誤，新舊錯誤混雜，更難斷定出錯的原因和位置，與之相反的是增量式集成方法，程式一段一段地擴展，測驗的范圍一步一步地加強，錯誤易于定位和糾正，界面的測驗也可做到完全徹底，
（1）增量式集成方法的兩種型別，
增量式集成方法主要包括自頂向下集成和自底向上集成兩種型別，
自頂向下增量式測驗表示逐步集成和逐步測驗是按結構圖自上而下進行的，即模塊集成的順序是首先集成主控模塊（主程式），然后按照軟體控制層次結構向下進行集成，
自底向上增量式測驗是從最底層的模塊開始，按結構圖自下而上逐步進行集成和測驗，
集成測驗主要測驗軟體的結構問題，因為測驗建立在模塊的介面上，所以多為黑盒測驗，適當輔以白盒測驗，
執行集成測驗應遵循下面的方法：
A. 確認組成一個完整系統的模塊之間的關系；
B.評審模塊之間的互動和通信需求，確認出模塊間的介面；
C. 使用上述資訊產生一套測驗用例；
D .采用增量式測驗，依次將模塊加入到系統，并測驗新合并后的系統，這個程序以一個邏輯/功能順序重復進行，直至所有模塊被功能集成進來形成完整的系統為止，
此外，在測驗程序中尤其要注意關鍵模塊，所謂關鍵模塊一般都具有下述一個或多個特征：
A. 對應幾條需求；
B.具有高層控制功能；
C. 復雜，易出錯；
D. 有特殊的性能要求，
因為集成測驗的主要目的是驗證組成軟體系統的各模塊的介面和互動作用，因此集成測驗對資料的要求無論從難度和內容來說一般不是很高，集成測驗一般也不使用真實資料，測驗人員可以使用手工制作一部分代表性的測驗資料，在創建測驗資料時，應保證資料充分測驗軟體系統的邊界條件，
在單元測驗時，根據需要生成了一些測驗資料，在集成測驗時可適當地重用這些資料，這樣可節省時間和人力，
（2）集成測驗遵循的原則，
集成測驗很不好把握，應針對總體設計盡早開始籌劃，為了做好集成測驗，需要遵循以下原則：
A. 所有公共介面都要被測驗到；
B.關鍵模塊必須進行充分的測驗；
C.集成測驗應當按一定的層次進行；
D. 集成測驗的策略選擇應當綜合考慮質量、成本和進度之間的關系；
E. 集成測驗應當盡早開始，并以總體設計為基礎；
F. 在模塊與介面的劃分上，測驗人員應當和開發人員進行充分的溝通；
G. 當介面發生修改時，涉及的相關介面必須進行再測驗；
H.測驗執行結果應當如實記錄，
3．系統測驗
集成測驗通過以后，軟體已經組裝成一個完整的軟體包，這時就要進行系統測驗，系統測驗完全采用黑盒測驗技術，因為這時已不需要考慮組件模塊的實作細節，而主要是根據需求分析時確定的標準檢驗軟體是否滿足功能、性能等方面的要求，系統測驗所用的資料必須盡可能地像真實資料一樣準確和有代表性，也必須和真實資料的大小和復雜性相當，滿足上述測驗資料需求的一個方法是使用真實資料，在不使用真實資料的情況下應該考慮使用真實資料的一個復制，復制資料的質量、精度和資料量必須盡可能地代表真實的資料，當使用真實資料或使用真實資料的復制時，仍然有必要引入一些手工資料，在創建手工資料時，測驗人員必須采用正規的設計技術，使得提供的資料真正代表正規和例外的測驗資料，確保軟體系統能充分地測驗，
系統測驗需要有廣泛的知識面，對測驗工程師的要求需要了解和掌握很多方面的知識，需要了解問題可能出現的原因，已經出現這個問題可能是由于什么原因造成的，以便我們能夠及時地補充測驗用例，保證或者降低產品發行后的風險，
系統測驗階段是測驗發現問題的主要階段，系統測驗重復的作業量比較大，如果是一個大型的專案，涉及的內容相對比較多，測驗本身是一件重復性的作業，很多時候我們要部署同樣的測驗環境，測驗同樣的模塊功能，反反復復地輸入相同的測驗資料，這是十分枯燥和乏味的作業，很容易讓人厭煩，所以如果能夠將部分有規律的重復性作業使用自動化測驗工具來進行，會使得我們的作業量減少，提高作業效率，
4．驗收測驗
系統測驗完成之后，軟體已完全組裝起來，介面方面的錯誤也已排除，這時可以開始對軟體進行最后的確認測驗，確認測驗主要檢查軟體能否按合同要求進行作業，即是否滿足軟體需求規格說明書中的要求，
軟體確認要通過一系列黑盒測驗，確認測驗同樣需要制訂測驗計劃和程序，測驗計劃應規定測驗的種類和測驗進度，測驗程序則定義一些特殊的測驗用例，旨在說明軟體與需求是否一致，無論是計劃還是程序，都應該著重考慮軟體是否滿足合同規定的所有功能和性能，檔案資料是否完整、準確，人機界面和其他方面（例如，可移植性、兼容性、錯誤恢復能力和可維護性等）是否滿足客戶要求，
確認測驗的結果有兩種可能：一種是功能和性能指標滿足軟體需求說明的要求，用戶可以接受；另一種是軟體不滿足軟體需求說明的要求，用戶無法接受，專案進行到這個階段才發現嚴重錯誤和偏差一般很難在預定的工期內改正，因此必須與用戶協商，尋求一個妥善解決問題的方法，
事實上，軟體開發人員不可能完全預見用戶實際使用程式的情況，例如，用戶可能錯誤地理解命令，或提供一些奇怪的資料組合，也可能對系統給出的提示資訊迷惑不解等，因此，軟體是否真正滿足最終用戶的要求，應由用戶進行一系列“驗收測驗”，驗收測驗既可以是非正式的測驗，也可以有計劃有系統的測驗，有時，驗收測驗長達數周甚至數月，不斷暴露錯誤，導致開發延期，一個軟體產品可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為、 測驗的程序，以期發現那些似乎只有最終用戶才能發現的問題，
測驗是指軟體開發公司組織內部人員模擬各類用戶行為對即將面市軟體產品（稱為版本）進行測驗，試圖發現錯誤并修正，測驗的關鍵在于盡可能地模擬實際運行環境和用戶對軟體產品的操作，并盡最大努力涵蓋所有可能的用戶操作方式，經過測驗調整的軟體產品稱為 版本，緊隨其后的 測驗是指軟體開發公司組織各方面的典型用戶（如放到互聯網上供用戶免費下載，并可以試用一定期限，或者以光碟等形式免費發放給部分期待試用的未來潛在客戶群用戶，也可以使用一定的期限，這個期限通常可能是幾天也可能是幾個月）在日常作業中實際使用__版本，并要求用戶報告例外情況、提出改進意見，然后軟體開發公司再對 版本進行改錯和完善，
其他測驗
1．回歸測驗
無論是進行黑盒測驗還是白盒測驗都會涉及回歸測驗，那么什么是回歸測驗呢？回歸測驗是指對軟體新的版本測驗時，重復執行上一個版本測驗時使用的測驗用例，
在軟體生命周期中的任何一個階段，只要軟體發生了改變，就可能給該軟體帶來問題，軟體的改變可能是源于發現了錯誤并做了修改，也有可能是因為在集成或維護階段加入了新的模塊，當軟體中所含錯誤被發現時，如果錯誤跟蹤與管理系統不夠完善，就可能會遺漏對這些錯誤的修改；而開發者對錯誤理解得不夠透徹，也可能導致所做的修改只修正了錯誤的外在表現，而沒有修復錯誤本身，從而造成修改失敗；修改還有可能產生副作用從而導致軟體未被修改的部分產生新的問題，使本來作業正常的功能產生錯誤，同樣，在有新代碼加入軟體的時候，除了新加入的代碼中有可能含有錯誤外，新代碼還有可能對原有的代碼帶來影響，因此，每當軟體發生變化時，我們就必須重新測驗現有的功能，以便確定修改是否達到了預期的目的，檢查修改是否損害了原有的正常功能，同時，還需要補充新的測驗用例來測驗新的或被修改了的功能，為了驗證修改的正確性及其影響就需要進行回歸測驗，
回歸測驗在軟體生命周期中扮演著重要的角色，因忽視回歸測驗而造成嚴重后果的例子不計其數，導致阿里亞娜V形火箭發射失敗的軟體缺陷就是由于復用的代碼沒有經過充分的回歸測驗造成的，我們平時也經常會聽到一些客戶的抱怨，說：“以前應用沒有問題的功能，現在怎么有問題了？”這些通常是因為鑒于商機、實施等部門對軟體開發周期的限制因素，開發人員對軟體系統增加或者改動部分系統功能，由于時間緊迫的原因，明確與測驗部門說明只進行新增或者變更的模塊進行測驗，而對其他未修改的模塊不需要進行測驗或者干脆說不需要測驗，由于軟體系統各個模塊之間存在著或多或少的聯系，很有可能因為新增加的功能變化，而引起其他模塊不能進行正常的作業，所以只測驗新增模塊，不對系統進行完整功能的測驗，導致以前應用沒有問題的功能，現在出現了問題，
2．冒煙測驗
冒煙測驗的名稱可以理解為該種測驗耗時短，僅用一袋煙功夫足夠了，也有人認為是形象地類比新電路板基本功能檢查，任何新電路板焊好后，先通電檢查，如果存在設計缺陷，電路板可能會短路，板子冒煙了，
冒煙測驗的物件是每一個新編譯的需要正式測驗的軟體版本，目的是確認軟體基本功能正常，可以進行后續的正式測驗作業，冒煙測驗的執行者是版本編譯人員或其他研發人員，
在一般軟體公司，軟體在撰寫程序中，內部需要編譯多個版本，但是只有有限的幾個版本需要執行正式測驗（根據專案開發計劃），這些需要執行的中間測驗版本，在剛剛編譯出來后，軟體編譯人員需要進行常規的測驗，例如，是否可以正確安裝/卸載，主要功能是否實作了，資料嚴重丟失等，如果通過了該測驗，則可以根據正式測驗檔案進行正式測驗，否則，就需要重新編譯版本，再次執行版本構建、打包和測驗，直到成功為止，冒煙測驗的好處是可以節省大量的時間成本和人力、物力成本，避免由于打包失誤、功能嚴重缺失、硬體部件損壞導致軟體運行失敗等嚴重問題而引起大量測驗人員從事沒有意義的測驗勞動，
3．隨機測驗
隨機測驗是這樣一種測驗，在測驗中，測驗資料是隨機產生的，例如，我們測驗一個系統的姓名欄位，姓名長度可達12個字符，那么可能隨機輸入以下12個字符：“ay5%，，i567aj”，顯然，沒有人叫這樣一個名字，并且可能該欄位不允許出現%等一些字符，所以對隨機產生的輸入集合我們要進行提煉，省略掉一些不符合要求的測驗集，并且這樣隨機產生的用例可能還只覆寫了一部分等價類，大量的情況無法覆寫到，這樣的測驗有時又叫猴子測驗（Monkey
Testing)，
隨機測驗有這樣一些缺點：
A.測驗往往不太真實；
B.不能達到一定的覆寫率；
C.許多測驗都是冗余的；
D.需要使用同樣的亂數種子才能重建測驗，
這種隨機測驗在很多時候沒有多大的用處，往往被用來作為“防崩潰”的手段，或者被用來驗證系統在遭受不利影響時是否能保持正常，作者覺得隨機測驗在面向網路，特別是因特網、不確定群體時還是非常有用的，因為不僅僅是真正想使用系統的用戶，也有很多樂于攻擊系統和制造垃圾資料的人，這是考察一個系統健壯性、防止生成大量垃圾資料的情況時非常有用的，有很多系統就因為前期不注重控制垃圾資料的輸入，導致資料量急速增長，后來又不得不做一個資料校驗程式來限制或洗掉垃圾資料，無形中又增加了作業量，
在這里推薦一個軟體測驗交流群，QQ：642830685，群中會不定期的分享軟體測驗資源，測驗面試題以及行業資訊，小伙伴們可以在群中積極交流和探討相關技術問題，群中還有技術大佬為你解答，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/250490.html
標籤：其他