軟件測試的目的，第壹是確認軟件的質量，其壹方面是確認軟件做了妳所期望的事情（Do the right thing），另壹方面是確認軟件以正確的方式來做了這個事件（Do it right）。
第二是提供信息，比如提供給開發人員或程序經理的反饋信息，為風險評估所準備的信息。
第三軟件測試不僅是在測試軟件產品的本身，而且還包括軟件開發的過程。如果壹個軟件產品開發完成之後發現了很多問題，這說明此軟件開發過程很可能是有缺陷的。因此軟件測試的第三個目的是保證整個軟件開發過程是高質量的。
軟件質量是由幾個方面來衡量的：壹、在正確的時間用正確的的方法把壹個工作做正確（Doing the right things right at the right time.）。二、符合壹些應用標準的要求，比如不同國家的用戶不同的操作習慣和要求，項目工程中的可維護性、可測試性等要求。三、質量本身就是軟件達到了最開始所設定的要求，而代碼的優美或精巧的技巧並不代表軟件的高質量（Quality is defined as conformance to requirements, not as “goodness” or “elegance”.）。四、質量也代表著它符合客戶的需要（Quality also means “meet customer needs”.）。作為軟件測試這個行業，最重要的壹件事就是從客戶的需求出發，從客戶的角度去看產品，客戶會怎麽去使用這個產品，使用過程中會遇到什麽樣的問題。只有這些問題都解決了，軟件產品的質量才可以說是上去了。
測試人員在軟件開發過程中的任務：
1、尋找Bug；
2、避免軟件開發過程中的缺陷；
3、衡量軟件的品質；
4、關註用戶的需求。
總的目標是：確保軟件的質量。
二、軟件測試的原則
軟件測試從不同的角度出發會派生出兩種不同的測試原則，從用戶的角度出發，就是希望通過軟件測試能充分暴露軟件中存在的問題和缺陷，從而考慮是否可以接受該產品，從開發者的角度出發，就是希望測試能表明軟件產品不存在錯誤，已經正確地實現了用戶的需求，確立人們對軟件質量的信心。
為了達到上述的原則，那麽需要註意以下幾點：
1．應當把“盡早和不斷的測試”作為開發者的座右銘
2．程序員應該避免檢查自己的程序，測試工作應該由獨立的專業的軟件測試機構來完。
3．設計測試用例時應該考慮到合法的輸入和不合法的輸入以及各種邊界條件，特殊情況要制造極端狀態和意外狀態，比如網絡異常中斷、電源斷電等情況。
4．壹定要註意測試中的錯誤集中發生現象，這和程序員的編程水平和習慣有很大的關系。
5．對測試錯誤結果壹定要有壹個確認的過程，壹般有A測試出來的錯誤，壹定要有壹個B來確認，嚴重的錯誤可以召開評審會進行討論和分析。
6．制定嚴格的測試計劃，並把測試時間安排的盡量寬松，不要希望在極短的時間內完成壹個高水平的測試。
7．回歸測試的關聯性壹定要引起充分的註意，修改壹個錯誤而引起更多的錯誤出現的現象並不少見。
8．妥善保存壹切測試過程文檔，意義是不言而喻的，測試的重現性往往要靠測試文檔。
三、軟件測試的對象
軟件測試並不等於程序測試。軟件測試應該貫穿整個軟件定義與開發整個期間。因此需求分析、概要設計、詳細設計以及程序編碼等各階段所得到的文檔，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程序，都應該是軟件測試的對象。
在對需求理解與表達的正確性、設計與表達的正確性、實現的正確性以及運行的正確性的驗證中，任何壹個環節發生了問題都可能在軟件測試中表現出來。
四、軟件測試方法
軟件測試的基本方法
單元測試的基本方法
綜合測試的基本方法
確認測試的基本方法
系統測試的基本方法
軟件測試的基本方法
軟件測試的方法和技術是多種多樣的。
對於軟件測試技術，可以從不同的角度加以分類：
從是否需要執行被測軟件的角度，可分為靜態測試和動態測試。
從測試是否針對系統的內部結構和具體實現算法的角度來看，可分為白盒測試和黑盒測試；
1、黑盒測試
黑盒測試也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作壹個不能打開的黑盆子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數鋸而產生正確的輸出信息，並且保持外部信息（如數據庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因果圖、錯誤推測等，主要用於軟件確認測試。 “黑盒”法著眼於程序外部結構、不考慮內部邏輯結構、針對軟件界面和軟件功能進行測試。“黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。
2、白盒測試
白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟件驗證。
“白盒”法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。“白盒”法是窮舉路徑測試。在使用這壹方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出測試數據。貫穿程序的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯誤。第壹，窮舉路徑測試決不能查出程序違反了設計規範，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發現不了壹些與數據相關的錯誤。
3．ALAC(Act-like-a-customer)測試
ALAC測試是壹種基於客戶使用產品的知識開發出來的測試方法。ALAC測試是基於復雜的軟件產品有許多錯誤的原則。最大的受益者是用戶，缺陷查找和改正將針對哪些客戶最容易遇到的錯誤。
單元測試的基本方法
單元測試的對象是軟件設計的最小單位模塊。單元測試的依據是詳細設描述，單元測試應對模塊內所有重要的控制路徑設計測試用例，以便發現模塊內部的錯誤。單元測試多采用白盒測試技術，系統內多個模塊可以並行地進行測試。
單元測試任務
單元測試任務包括：1 模塊接口測試；2 模塊局部數據結構測試；3 模塊邊界條件測試；4 模塊中所有獨立執行通路測試；5 模塊的各條錯誤處理通路測試。
模塊接口測試是單元測試的基礎。只有在數據能正確流入、流出模塊的前提下，其他測試才有意義。測試接口正確與否應該考慮下列因素：
1 輸入的實際參數與形式參數的個數是否相同；
2 輸入的實際參數與形式參數的屬性是否匹配；
3 輸入的實際參數與形式參數的量綱是否壹致；
4 調用其他模塊時所給實際參數的個數是否與被調模塊的形參個數相同；
5 調用其他模塊時所給實際參數的屬性是否與被調模塊的形參屬性匹配；
6調用其他模塊時所給實際參數的量綱是否與被調模塊的形參量綱壹致；
7 調用預定義函數時所用參數的個數、屬性和次序是否正確；
8 是否存在與當前入口點無關的參數引用；
9 是否修改了只讀型參數；
10 對全程變量的定義各模塊是否壹致；
11是否把某些約束作為參數傳遞。
如果模塊內包括外部輸入輸出，還應該考慮下列因素：
1 文件屬性是否正確；
2 OPEN/CLOSE語句是否正確；
3 格式說明與輸入輸出語句是否匹配；
4緩沖區大小與記錄長度是否匹配；
5文件使用前是否已經打開；
6是否處理了文件尾；
7是否處理了輸入/輸出錯誤；
8輸出信息中是否有文字性錯誤；
檢查局部數據結構是為了保證臨時存儲在模塊內的數據在程序執行過程中完整、正確。局部數據結構往往是錯誤的根源，應仔細設計測試用例，力求發現下面幾類錯誤：
1 不合適或不相容的類型說明；
2變量無初值；
3變量初始化或省缺值有錯；
4不正確的變量名（拼錯或不正確地截斷）；
5出現上溢、下溢和地址異常。
除了局部數據結構外，如果可能，單元測試時還應該查清全局數據（例如FORTRAN的公用區）對模塊的影響。
在模塊中應對每壹條獨立執行路徑進行測試，單元測試的基本任務是保證模塊中每條語句至少執行壹次。此時設計測試用例是為了發現因錯誤計算、不正確的比較和不適當的控制流造成的錯誤。此時基本路徑測試和循環測試是最常用且最有效的測試技術。計算中常見的錯誤包括：
1 誤解或用錯了算符優先級；
2混合類型運算；
3變量初值錯；
4精度不夠；
5表達式符號錯。
比較判斷與控制流常常緊密相關，測試用例還應致力於發現下列錯誤：
1不同數據類型的對象之間進行比較；
2錯誤地使用邏輯運算符或優先級；
3因計算機表示的局限性，期望理論上相等而實際上不相等的兩個量相等；
4比較運算或變量出錯；
5循環終止條件或不可能出現；
6叠代發散時不能退出；
7錯誤地修改了循環變量。
壹個好的設計應能預見各種出錯條件，並預設各種出錯處理通路，出錯處理通路同樣需要認真測試，測試應著重檢查下列問題：
1輸出的出錯信息難以理解；
2記錄的錯誤與實際遇到的錯誤不相符；
3在程序自定義的出錯處理段運行之前，系統已介入；
4異常處理不當；
5錯誤陳述中未能提供足夠的定位出錯信息。
邊界條件測試是單元測試中最後，也是最重要的壹項任務。眾的周知，軟件經常在邊界上失效，采用邊界值分析技術，針對邊界值及其左、右設計測試用例，很有可能發現新的錯誤。
單元測試過程
壹般認為單元測試應緊接在編碼之後，當源程序編制完成並通過復審和編譯檢查，便可開始單元測試。測試用例的設計應與復審工作相結合，根據設計信息選取測試數據，將增大發現上述各類錯誤的可能性。在確定測試用例的同時，應給出期望結果。
應為測試模塊開發壹個驅動模塊（driver）和（或）若幹個樁模塊（stub）,下圖顯示了壹般單元測試的環境。驅動模塊在大多數場合稱為“主程序”，它接收測試數據並將這些數據傳遞到被測試模塊，被測試模塊被調用後，“主程序”打印“進入-退出”消息。
驅動模塊和樁模塊是測試使用的軟件，而不是軟件產品的組成部分，但它需要壹定的開發費用。若驅動和樁模塊比較簡單，實際開銷相對低些。遺憾的是，僅用簡單的驅動模塊和樁模塊不能完成某些模塊的測試任務，這些模塊的單元測試只能采用下面討論的綜合測試方法。
提高模塊的內聚度可簡化單元測試，如果每個模塊只能完成壹個，所需測試用例數目將顯著減少，模塊中的錯誤也更容易發現。
綜合測試的基本方法
時常有這樣的情況發生，每個模塊都能單獨工作，但這些模塊集成在壹起之後卻不能正常工作。主要原因是，模塊相互調用時接口會引入許多新問題。例如，數據經過接口可能丟失；壹個模塊對另壹模塊可能造成不應有的影響；幾個子功能組合起來不能實現主功能；誤差不斷積累達到不可接受的程度；全局數據結構出現錯誤，等等。綜合測試是組裝軟件的系統測試技術，按設計要求把通過單元測試的各個模塊組裝在壹起之後，進行綜合測試以便發現與接口有關的各種錯誤。
某設計人員習慣於把所有模塊按設計要求壹次全部組裝起來，然後進行整體測試，這稱為非增量式集成。這種方法容易出現混亂。因為測試時可能發現壹大堆錯誤，為每個錯誤定位和糾正非常困難，並且在改正壹個錯誤的同時又可能引入新的錯誤，新舊錯誤混雜，更難斷定出錯的原因和位置。與之相反的是增量式集成方法，程序壹段壹段地擴展，測試的範圍壹步壹步地增大，錯誤易於定位和糾正，界面的測試亦可做到完全徹底。下面討論兩種增量式集成方法。
1 自頂向下集成
自頂向下集成是構造程序結構的壹種增量式方式，它從主控模塊開始，按照軟件的控制層次結構，以深度優先或廣度優先的策略，逐步把各個模塊集成在壹起。深度優先策略首先是把主控制路徑上的模塊集成在壹起，至於選擇哪壹條路徑作為主控制路徑，這多少帶有隨意性，壹般根據問題的特性確定。以下圖為例，若選擇了最左壹條路徑，首先將模塊M1，M2，M5和M8集成在壹起，再將M6集成起來，然後考慮中間和右邊的路徑。廣度優先策略則不然，它沿控制層次結構水平地向下移動。仍以下圖為例，它首先把M2、M3和M4與主控模塊集成在壹起，再將M5和M6 和其他模塊集資集成起來。
自頂向下綜合測試的具體步驟為：
1 以主控模塊作為測試驅動模塊，把對主控模塊進行單元測試時引入的所有樁模塊用實際模塊替代；
2 依據所選的集成策略（深度優先或廣度優先），每次只替代壹個樁模塊；
3 每集成壹個模塊立即測試壹遍；
4 只有每組測試完成後，才著手替換下壹個樁模塊；
5 為避免引入新錯誤，須不斷地進行回歸測試（即全部或部分地重復已做過的測試）。
從第二步開始，循環執行上述步驟，直至整個程序結構構造完畢。下圖中，實線表示已部分完成的結構，若采用深度優先策略，下壹步將用模塊M7替換樁模塊S7，當然M7本身可能又帶有樁模塊，隨後將被對應的實際模塊壹壹替代。
自頂向下集成的優點在於能盡早地對程序的主要控制和決策機制進行檢驗，因此較早地發現錯誤。缺點是在測試較高層模塊時，低層處理采用樁模塊替代，不能反映真實情況，重要數據不能及時回送到上層模塊，因此測試並不充分。解決這個問題有幾種辦法，第壹種是把某些測試推遲到用真實模塊替代樁模塊之後進行，第二種是開發能模擬真實模塊的樁模塊；第三種是自底向上集成模塊。第壹種方法又回退為非增量式的集成方法，使錯誤難於定位和糾正，並且失去了在組裝模塊時進行壹些特定測試的可能性；第二種方法無疑要大大增加開銷；第三種方法比較切實可行，下面專門討論。
2自底向上集成
自底向上測試是從“原子”模塊（即軟件結構最低層的模塊）開始組裝測試，因測試到較高層模塊時，所需的下層模塊功能均已具備，所以不再需要樁模塊。
自底向上綜合測試的步驟分為：
1 把低層模塊組織成實現某個子功能的模塊群（cluster）;
2 開發壹個測試驅動模塊，控制測試數據的輸入和測試結果的輸出；
3 對每個模塊群進行測試；
4 刪除測試使用的驅動模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群。
從第壹步開始循環執行上述各步驟，直至整個程序構造完畢。
下圖說明了上述過程。首先“原子”模塊被分為三個模塊群，每個模塊群引入壹個驅動模塊進行測試。因模塊群1、模塊群2中的模塊均隸屬於模塊Ma，因此在驅動模塊D1、D2去掉後，模塊群1與模塊群2直接與Ma接口，這時可對MaD3被去掉後，M3與模塊群3直接接口，可對Mb進行集成測試，最後Ma、Mb和 Mc全部集成在壹起進行測試。
自底向上集成方法不用樁模塊，測試用例的設計亦相對簡單，但缺點是程序最後壹個模塊加入時才具有整體形象。它與自頂向綜合測試方法優缺點正好相反。因此，在測試軟件系統時，應根據軟件的特點和工程的進度，選用適當的測試策略，有時混和使用兩種策略更為有效，上層模塊用自頂向下的方法，下層模塊用自底向上的方法。
此外，在綜合測試中尤其要註意關鍵模塊，所謂關鍵模塊壹般都具有下述壹或多個特征：①對應幾條需求；②具有高層控制功能；③復雜、易出錯；④有特殊的性能要求。關鍵模塊應盡早測試，並反復進行回歸測試。
確認測試的基本方法
通過綜合測試之後，軟件已完全組裝起來，接口方面的錯誤也已排除，軟件測試的最後壹步確認測試即可開始。確認測試應檢查軟件能否按合同要求進行工作，即是否滿足軟件需求說明書中的確認標準。
1. 確認測試標準
實現軟件確認要通過壹系列墨盒測試。確認測試同樣需要制訂測試計劃和過程，測試計劃應規定測試的種類和測試進度，測試過程則定義壹些特殊的測試用例，旨在說明軟件與需求是否壹致。無是計劃還是過程，都應該著重考慮軟件是否滿足合同規定的所有功能和性能，文檔資料是否完整、準確人機界面和其他方面（例如，可移植性、兼容性、錯誤恢復能力和可維護性等）是否令用戶滿意。
確認測試的結果有兩種可能，壹種是功能和性能指標滿足軟件需求說明的要求，用戶可以接受；另壹種是軟件不滿足軟件需求說明的要求，用戶無法接受。項目進行到這個階段才發現嚴重錯誤和偏差壹般很難在預定的工期內改正，因此必須與用戶協商，尋求壹個妥善解決問題的方法。
2. 配置復審
確認測試的另壹個重要環節是配置復審。復審的目的在於保證軟件配置齊全、分類有序，並且包括軟件維護所必須的細節。
3. α、β測試
事實上，軟件開發人員不可能完全預見用戶實際使用程序的情況。例如，用戶可能錯誤的理解命令，或提供壹些奇怪的數據組合，亦可能對設計者自認明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應由用戶進行壹系列“驗收測試”。驗收測試既可以是非正式的測試，也可以有計劃、有系統的測試。有時，驗收測試長達數周甚至數月，不斷暴露錯誤，導致開發延期。壹個軟件產品，可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為α、β測試的過程，以期發現那些似乎只有最終用戶才能發現的問題。
α測試是指軟件開發公司組織內部人員模擬各類用戶行對即將面市軟件產品（稱為α版本）進行測試，試圖發現錯誤並修正。α測試的關鍵在於盡可能逼真地模擬實際運行環境和用戶對軟件產品的操作並盡最大努力涵蓋所有可能的 用戶操作方式。經過α測試調整的軟件產品稱為β版本。緊隨其後的β測試是指軟件開發公司組織各方面的典型用戶在日常工作中實際使用β版本，並要求用戶報告異常情況、提出批評意見。然後軟件開發公司再對β版本進行改錯和完善。
系統測試的基本方法
計算機軟件是基於計算機系統的壹個重要組成部分，軟件開發完畢後應與系統中其它成分集成在壹起，此時需要進行壹系列系統集成和確認測試。對這些測試的詳細討論已超出軟件工程的範圍，這些測試也不可能僅由軟件開發人員完成。在系統測試之前，軟件工程師應完成下列工作：
（1） 為測試軟件系統的輸入信息設計出錯處理通路；
（2） 設計測試用例，模擬錯誤數據和軟件界面可能發生的錯誤，記錄測試結果，為系統測試提供經驗和幫助；
（3） 參與系統測試的規劃和設計，保證軟件測試的合理性。
系統測試應該由若幹個不同測試組成，目的是充分運行系統，驗證系統各部件是否都能政黨工作並完成所賦予的任務。下面簡單討論幾類系統測試。
1、恢復測試
恢復測試主要檢查系統的容錯能力。當系統出錯時，能否在指定時間間隔內修正錯誤並重新啟動系統。恢復測試首先要采用各種辦法強迫系統失敗，然後驗證系統是否能盡快恢復。對於自動恢復需驗證重新初始化（reinitialization）、檢查點(checkpointing mechanisms)、數據恢復(data recovery)和重新啟動 (restart)等機制的正確性；對於人工幹預的恢復系統，還需估測平均修復時間，確定其是否在可接受的範圍內。
2、安全測試
安全測試檢查系統對非法侵入的防範能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如，①想方設法截取或破譯口令；②專門定做軟件破壞系統的保護機制；③故意導致系統失敗，企圖趁恢復之機非法進入；④試圖通過瀏覽非保密數據，推導所需信息，等等。理論上講，只要有足夠的時間和資源，沒有不可進入的系統。因此系統安全設計的準則是，使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。
3、強度測試
強度測試檢查程序對異常情況的抵抗能力。強度測試總是迫使系統在異常的資源配置下運行。例如，①當中斷的正常頻率為每秒壹至兩個時，運行每秒產生十個中斷的測試用例；②定量地增長數據輸入率，檢查輸入子功能的反映能力；③運行需要最大存儲空間（或其他資源）的測試用例；④運行可能導致虛存操作系統崩潰或磁盤數據劇烈抖動的測試用例，等等。
4、 性能測試
對於那些實時和嵌入式系統，軟件部分即使滿足功能要求，也未必能夠滿足性能要求，雖然從單元測試起，每壹測試步驟都包含性能測試，但只有當系統真正集成之後，在真實環境中才能全面、可靠地測試運行性能系統性能測試是為了完成這壹任務。性能測試有時與強度測試相結合，經常需要其他軟硬件的配套支持。
五、軟件測試的類型
常見的軟件測試類型有：
BVT (Build Verification Test)
BVT是在所有開發工程師都已經檢入自己的代碼，項目組編譯生成當天的版本之後進行，主要目的是驗證最新生成的軟件版本在功能上是否完整，主要的軟件特性是否正確。如無大的問題，就可以進行相應的功能測試。BVT優點是時間短，驗證了軟件的基本功能。缺點是該種測試的覆蓋率很低。因為運行時間短，不可能把所有的情況都測試到。
Scenario Tests（基於用戶實際應用場景的測試）
在做BVT、功能測試的時候，可能測試主要集中在某個模塊，或比較分離的功能上。當用戶來使用這個應用程序的時候，各個模塊是作為壹個整體來使用的，那麽在做測試的時候，就需要模仿用戶這樣壹個真實的使用環境，即用戶會有哪些用法，會用這個應用程序做哪些事情，操作會是壹個怎樣的流程。加了這些測試用例後，再與BVT、功能測試配合，就能使軟件整體都能符合用戶使用的要求。Scenario Tests優點是關註了用戶的需求，缺點是有時候難以真正模仿用戶真實的使用情況。
Smoke Test
在測試中發現問題，找到了壹個Bug，然後開發人員會來修復這個Bug。這時想知道這次修復是否真的解決了程序的Bug，或者是否會對其它模塊造成影響，就需要針對此問題進行專門測試，這個過程就被稱為Smoke Test。在很多情況下，做Smoke Test是開發人員在試圖解決壹個問題的時候，造成了其它功能模塊壹系列的連鎖反應，原因可能是只集中考慮了壹開始的那個問題，而忽略其它的問題，這就可能引起了新的Bug。Smoke Test優點是節省測試時間，防止build失敗。缺點是覆蓋率還是比較低。
此外，Application Compatibility Test（兼容性測試），主要目的是為了兼容第三方軟件，確保第三方軟件能正常運行，用戶不受影響。Accessibility Test（軟件適用性測試），是確保軟件對於某些有殘疾的人士也能正常的使用，但優先級比較低。其它的測試還有Functional Test（功能測試）、Security Test（安全性測試）、Stress Test（壓力測試）、Performance Test（性能測試）、Regression Test（回歸測試）、Setup/Upgrade Test（安裝升級測試）等。
六、軟件測試支持工具
壹些受軟件開發人員歡迎的軟件測試工具為軟件測試提供了強有力的支持。本文將介紹美國Rational公司的著名套裝軟件SQA和Pure Atria公司極具特色的Purify。
SQA SuiteSQA直接支持對客戶/服務器應用軟件的測試,它的壹個重要特點是可以自動驅動被測程序的運行。SQA可以自動記錄和重放程序執行過程,從而實現了對測試進行"復查"的自動化。
由於測試是壹個需要反復進行的過程,常常要數十次甚至數百次地重復。因此,這壹特性大大地提高了軟件"再測試"(Re-Test)和"回歸測試"(Regression)的自動化程度,把測試人員從繁雜的、重復性的手工測試中解脫出來,從而顯著地提高軟件測試效率。
除了這個最基本的自動錄放功能外,它還提供了壹系列的輔助支持功能,比如,
· 被錄制的程序執行過程可以被自動轉換成具有良好可讀性的高級語言程序,從而使這個測試驅動程序可以由測試人員根據測試需要進行必要的修改,甚至完全用手工方式編制。
·自動記錄和分析比較測試的執行結果。不論是簡單的正文方式的輸出結果,還是任意的圖表、聲音、動畫、圖形用戶界面(GUI)中的任壹構件,都可以根據測試人員的指定被自動記錄在測試結果庫中,並可對兩次測試的結果自動地進行比較,指出其差異部分。此項功能無疑對"自動查找錯誤"很有幫助。