1.1 自動化測試的定義及概述
1.1.1 軟體測試的定義與分類

        軟體測試[2]，就是在軟體投入執行前，對軟體需求分析、設計規格說明和編碼的最終複查，是軟體質量保證的關鍵步驟。

        定義1：軟體測試是為了發現錯誤而在規定的條件下執行程式的過程。

        定義2：軟體測試是根據軟體開發各階段的規格說明和程式的內部結構而精心設計一批測試用例（即輸入資料及其預期的輸出結果），並利用這些測試用例去執行程式，以發現程式錯誤的過程。

        由軟體測試的定義，不難看出測試的目的[13]，是尋找錯誤，並且是盡最大可能找出最多的錯誤。著名的Grenford J. Myers在《The Art of Software Testing

        測試是程式的執行過程，目的在於發現錯誤； 
        一個好的測試用例在於發現至今未發現的錯誤； 
        一個成功的測試是發現了至今未發現的錯誤的測試。 
        軟體測試，按照不同的分類原則有不同的分類結果：

（1） 按測試用例設計方法分，軟體測試分為：黑盒測試，白盒測試和灰盒測試。

        黑盒測試（Black-box testing），又稱為功能測試或資料驅動測試，把系統看成一個黑盒子，不考慮程式的內在邏輯，只根據需求規格說明書的要求來檢查程式的功能是否符合它的功能說明。

        白盒測試（White-box testing），又稱為結構測試或邏輯驅動測試，允許測試人員對程式內部邏輯結構及有關資訊來設計和選擇測試用例，對程式的邏輯路徑進行測試。

        灰盒測試（Gray-box testing），是融合了白盒和黑盒測試的一種測試策略，又稱混合測試法

        本文主要涉及的是根據需求規格說明書進行的黒盒測試。

（2） 按測試策略和過程分，軟體測試分為：單元測試、整合測試（組裝測試）、確認測試、系統測試以及迴歸測試[2]。

        單元測試（Unit Testing），又稱模組測試，是最小單位測試，是在系統開發過程中要進行的最低級別的測試活動。單元測試活動中對原始碼實現的每個程式單元進行測試，檢查各個程式模組是否正確地實現了規定的功能。其目的在於發現各模組內部可能存在的各種錯誤，單元測試需要從程式的內部結構出發設計測試用例，必要的時候要製作驅動模組和樁模組。測試工程師要依據詳細設計說明書和源程式清單，瞭解模組的I/O條件和邏輯結構。主要採用白盒測試的測試用例，輔之以黒盒測試的測試用例。

        整合測試（Integration Testing），也稱為組裝測試，是在單元測試的基礎上，將所有模組按照結構設計要求組裝成為一個可執行的系統。整合測試對應於軟體概要設計階段的測試，它要求儘可能地暴露程式單元或模組間介面和軟體設計上的錯誤和缺陷，確保程式單元或模組間介面正確和軟體結構合理。整合測試按系統整合方式，可分為非增量式和增量式兩種。其中增量式整合方式可分為自定向下整合、自底向上整合和混合增量式整合。整合測試主要依據概要設計說明書，主要採用黒盒測試，輔之以白盒測試方法。

        系統測試（System Testing），是基於一定的計算機硬體環境，對整個軟體進行的一系列測試；是將已經通過整合測試的軟體與具有一定代表性的計算機實用環境相結合，根據軟體專案系統級的有關文件，檢查軟體與系統定義、與需求的符合性，檢驗並確認軟體在整個系統中的功能、效能和正確性。完成整合測試後的軟體系統，必須與系統的其他元素相結合，進行系統級的確認和驗證測試。

        所謂確認（validation），是一系列的活動和過程，其目的是想證實在給定的外部環境下軟體的邏輯正確性。分為靜態確認和動態確認。

        所謂驗證（verification），是試圖證明在軟體生成周期各個階段以及階段間的邏輯協調性、完備性和正確性。

        系統測試主要採用黒盒測試方法，對於具體的專案，這個階段的測試中非常重要的一點是建立滿足具體軟體專案的模擬環境。

        驗收測試（Acceptance Testing），是以使用者為主的測試。一般，在軟體系統測試結束以及軟體配置審查之後開始，驗收測試應由使用者、測試人員、軟體開發人員和質量保證人員一起參與，驗證軟體系統的功能和效能及其它特性是否與使用者的要求一致。

        迴歸測試（Regression Testing）不是一個特定的測試級別，只要對軟體程式碼有修改，不論是修改錯誤還是增加新的功能或是提高效能，原則上都要進行迴歸測試，以保證對程式碼修改的正確性，且不會對其餘部分帶來負面影響。本文中主要論述的是在整合測試和系統測試階段遇到程式碼變動所進行的重複測試。迴歸測試可以通過重新執行所有的測試用例的一個子集進行，迴歸測試集包括三種類型的測試用例：

        能夠測試軟體的所有功能的代表性測試用例。 
        專門針對可能會被修改影響的軟體功能的附加測試。 
        針對修改過的軟體成分的測試。 
        迴歸測試可以有選擇地重複執行整合和系統測試的測試用例，迴歸測試變動比較小，同時測試所基於的實際硬體環境相對比較穩定。但迴歸測試要頻繁地重複執行，需要的工作量很大，所以，迴歸測試最值得自動化。自動測試便於迴歸測試以非常高效的方式進行。

（3） 按測試內容分，介面測試、路徑測試、功能測試、健壯性測試、效能測試、使用者介面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試。

        本文的測試系統主要針對整合測試和系統測試階段，在這些階段測試的內容主要是功能測試、健壯性測試、效能測試、使用者介面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試。

1.1.2 自動測試的概述

        自動化測試是藉助於測試工具、測試規範，從而區域性或全部代替人工進行測試及提高測試效率的過程。

        自動測試相對於手工測試而言，其主要進步在於自動測試工具的引入。自動測試的一般定義[1]為：各種測試活動的管理與實施，包括測試指令碼的開發與執行，以便使用某種自動測試工具來驗證測試需求。測試活動的自動化在許多情況下可以獲得最大的實用價值，尤其在自動測試的測試用例開發和組裝階段，測試指令碼被重複呼叫，可重用指令碼可能執行很多次。因此，採用自動測試可以獲得很高的回報。

        系統測試級上的迴歸測試是有效應用自動測試的情況。迴歸測試設法驗證改進後的系統提供的功能是否按照規定執行，系統在執行中沒有出現非預期變化。自動測試幾乎可以不加改動地重用先前的測試用例和測試指令碼，以非常有效的方式執行迴歸測試。

自動測試具有以下優點[4]：

        （1） 能執行更多更頻繁的測試，使某些測試任務的執行比手動方式更高效，可以更快地將軟體推向市場；

        （2） 能執行一些手動測試困難或不可能做的測試；

        （3） 更好地利用資源，利用整夜或週末空閒的裝置執行自動化測試；

        （4） 將煩瑣的任務自動化，讓測試人員投入更多的精力設計出更多更好的測試用例，提高測試準確性和測試人員的積極性；

        （5） 自動測試具有一致性和可重複性的特點，而且測試更客觀，提高了軟體的信任度。

但自動化測試仍然存在著一定的侷限性[15]：

        （1） 不能取代手工測試，不可能自動化所有的測試。如測試只是偶爾執行，或待測系統經常變動、不穩定，測試需要大量的人工參與時，就不適宜採用自動測試。

        （2） 自動測試工具本身不具有想象力，只是按命令執行。而手工測試時測試執行者可以在測試中判斷測試輸出是否正確，以及改進測試，還可以處理意外事件。

        （3） 自動測試對測試質量的依賴性較大，在確保測試質量的前提下，實施自動化測試才有意義。

        （4） 自動測試在剛開始執行時，工作效率並不一定高於手動測試，只有當整個自動測試系統成熟，且測試工程師熟練掌握測試工具後，工作效率才會隨著測試執行次數的增加而提高。

        （5） 自動測試的成本可能高於手工測試。自動測試的成本大致有以下幾個部分組成：自動測試開發成本、自動測試執行成本、自動測試維護成本和其他相關任務帶來的成本。軟體的修改帶來測試指令碼部分或全部修改，就會增加測試維護的開銷。

1.1.3 測試與自動化測試概念的區別

        測試[5]是通過執行測試用例實現，描述測試用例質量有四個特徵：有效性、修改性、可仿效性和經濟性。有效性指是否能發現缺陷、或至少可能發現缺陷；可仿效性指測試用例是否能測試多項內容，以減少測試用例的數量；經濟性指測試用例的執行、分析和除錯是否經濟；修改性指每次軟體修改後對測試用例的維護成本。通常要平衡這四個方面。

        自動測試技術，與測試技術存在著很大區別。自動化的程度與測試的質量是獨立的。無論自動執行還是手動執行測試都不影響測試的有效性和仿效性。測試本身的有效性直接導致測試的成敗，而自動測試只對測試的經濟性和修改性有影響，自動測試通常要比手動測試經濟得多，自動測試的方法越好，長期使用獲得的收益就越大。測試質量取決於測試執行者實現測試質量的技術；而自動化質量取決於測試自動化者的自動化技術。

        圖2-1說明了測試與自動化測試在測試用例的四個質量特徵上的區別。

圖2-1 測試用例質量Keviat圖

1.2 自動化測試生命週期的概述
1.2.1 自動化測試過程

        提到測試，一般都認為是使用測試用例進行測試，而事實上，這只是完整測試過程中的一個步驟，測試活動其實是一個過程，如圖2-2所示，是一系列的步驟，通過這些步驟實現測試活動，導致測試的執行和測試產物的產生。測試過程有開發者、測試設計工程師和測試工程師的共同參與。包括了測試計劃、設計、開發、執行和評估這幾個步驟[1]。各個步驟分別又有不同的自動化工具提供支援。

圖2-2 自動化測試過程

（1）自動測試的計劃

        理想情況下，測試始於測試目標和測試策略的建立，測試策略應滿足測試目標的要求。管理層的測試計劃包括評估完成所有測試活動的時間，測試活動安排及資源分配，控制測試過程以及跟蹤整個測試過程所需採取的活動，這些高層次活動應該在專案開始前就實施，並貫穿專案的整個開發過程。

        測試計劃是測試過程中最重要的活動，包括風險評估、鑑別和確定測試需求的優先順序，估計測試資源的需求量，開發測試專案計劃以及給測試小組成員分配測試職責等。

        測試計劃的目的是收集從需求/設計文件中得到的資訊，並將這些資訊表現在測試需求中，而測試需求將在測試場景中得到實現。測試場景是測試計劃的一部分，它直接提供給測試條件、測試用例、測試資料的開發。我們可以視測試計劃為從軟體需求中抽出來工作文件，並和測試需求和測試結果相聯絡。測試計劃還會隨著軟體需求的更新而更新，是動態的文件。

        這個階段主要是測試設計工程師根據開發者提供的功能需求，高階設計文件及詳細設計文件，使用如Rational RequisitePro這樣的工具得到測試需求，測試計劃，以及測試用例的Excel形式的列表。

（2）自動測試的設計

        測試設計包括經過測試需求分析後，定義測試活動模型（確定測試所使用的測試技術），定義測試體系結構，完成測試程式的定義與對映（建立測試程式與測試需求之間的聯絡），自動/手動測試對映（確定哪些測試使用自動測試），以及測試資料對映。

        需要指出的是確定自動/手動測試對映，對於自動測試相當重要，因為並不是所有的測試都適合自動化。作者認為，一般以下幾類情況適合進行自動測試：

        當前的測試專案比較大，且在今後專案中重複測試的概率比較高； 
        測試本身的執行簡單、機械，而測試所需硬體環境則相對來說比較穩定； 
        測試難以通過手動方式實現，例如部分負載/壓力測試； 
        測試基本不需要人工參與，且重複性較高，如系統的配置測試。 
        這個階段主要參與者有測試設計工程師，其任務是根據測試需求，測試計劃文件，測試用例列表等，使用工具如Excel來構建電子資料表，包括測試條件電子資料表，測試資料電子資料表，有關各種對映關係定義的表格以及詳細測試電子資料表。

（3）自動測試的開發

        測試開發包括建立具有可維護性、可重用性、簡單性、健壯性的測試程式。同時要注意確保自動測試開發的結構化和一致性。

        這個階段由測試設計工程師在上一階段的基礎上，根據詳細測試表、對映關係定義表等電子資料表格，可以使用Robot、WinRunner等工具，生成手工測試指令碼，自動化測試指令碼。尤其是自動測試指令碼的開發，有線性指令碼、結構化指令碼、共享指令碼、資料驅動指令碼和關鍵字驅動指令碼這幾種指令碼技術。各種指令碼技術將在後面章節詳細論述。

（4）自動測試的執行與評估

        隨著測試計劃的建立和測試環境的搭建完畢，按照測試程式進度安排執行測試，可以通過手動或自動或半手動半自動方式執行，它們各自可以發現不同型別的錯誤。測試執行結束後，需要對測試結果進行比較、分析以及結果驗證，得出測試報告（包括總結性報告和詳細報告）。其中總結性報告是提供給被測方中高層管理者及客戶的，而詳細報告，寄過編輯整理，作為反饋文件提供給開發小組成員。執行及評價過程如圖2-3所示。

                                                                           圖2-3 測試執行及評估流程

        這個階段由測試設計工程師與測試工程師共同參與。構建好的待測系統上使用測試用例指令碼執行測試資料，其中測試資料是被設計用於測試該應用程式各種特徵的。可以使用Excel、Word、ClearQuest等工具，得到測試後的測試結果日誌、測試度量、缺陷報告及測試評估總結等。

1.2.2 自動化測試與自動化測試過程的區別

        如果需要的是一個完全的自動化的測試過程，而不僅僅是一些自動化測試，那麼圍繞測試執行過程的前處理和後處理任務就必須自動化，如圖2-4。前處理，包括所有與建立和恢復那些與測試先決條件相關的工作。後處理，包括對測試結果進行評估，儲存工具日誌檔案，清除測試環境等工作。對測試過程進行自動化，更有利於減輕工作量。

圖2-4 自動化測試與自動化測試過程的區別

1.2.3 自動化測試生命週期方法學

        自動化測試生命週期方法學（Automated Test Lifecycle Methodology，ATLM）[1]是一個旨在確保自動化測試成功實施的結構化的方法學，反映了現代的快速應用開發（Rapid Application Development, RAD）工作的益處。它是一個多階段的過程，該方法學由六個部分組成：自動測試決定，自動測試工具獲取，自動測試引入測試過程，自動測試計劃、設計與開發，測試的執行與管理，測試的評審與評估。如圖2-5所示。

        在2.2.1節中論述的自動化測試過程是自動化測試生命週期的一個重要組成部分。而ATLM則從方法論的角度，更全面更系統地論述了整個自動化測試專案。

圖2-5 自動測試生命週期方法學

（1）自動測試決定

        正如在2.1.2節中論述的，自動化測試確實存在許多優點，但並不是任何測試都能自動化，它也存在著侷限性。克服不正確的自動測試期望，必須針對測試專案的具體情況，確定什麼時候，對什麼進行自動化[14]。如果對不適合自動化的測試，實施自動化，不但耗費了大量資源，而且得不到相應的回報。要記住：自動測試不可能完全替代手動測試。

        作者認為，在針對測試專案的整個週期時間、資源分配情況及資金安排情況的綜合分析後，確定什麼時候，對什麼進行自動化。

（2）測試工具獲取

        實現自動化測試，測試工具的選擇很重要，而目前還沒有一個單一的測試工具能用來完成所有的測試需求。測試工具品種不一，功能效能各異。對自動測試工具的適當選擇，很大程度上決定了該工具能否獲得相應的投資回報。

        作者認為，要對市場上各種測試工具進行廣泛地調查比較。在選擇時，建議考慮以下幾個方面：該工具引入後改進測試的效果，能實現何種測試需求；測試工具與待測軟體/系統的互操作性；工具的成本估算；引入工具所需的額外時間；工具所需的專業知識及培訓費用等等。有時，可以選擇開放性開發的測試工具。

（3）自動測試引入階段

        首先需要測試過程分析，從而確定適用的技術環境以及自動工具可支援的各種測試。其次，將潛在的測試工具和實用程式對映到測試需求中，驗證測試工具是否與應用及環境相容。

        作者認為，使測試工具得到最大回報的方法，就是在測試中最大限度地發揮它的功能。對於獲得的測試工具，要真正引入到測試專案中，與待測系統實現互操作，可以以某些測試工具為基礎進行二次開發，使得測試工具更專業化，更適合測試工程師操作。

（4）自動化測試過程

        自動化測試過程包括：測試計劃、設計及開發，測試執行與管理，測試評審與評價，已經在2.2.1節中具體論述過了。

1.3 自動測試生命週期方法學的應用
        自動測試生命週期方法學作為一種結構化的方法學，本課題以之為指導，進行自動化測試系統的設計與實現。

        本文第三章將論述根據iSAM系統的測試需求作出自動測試的決定，以及自動測試系統建模的方法。

        第四、五章將詳細介紹自動化測試系統的框架和實現，以及為此係統設計和實現的自動工具。這正對應於自動測試生命週期第二階段自動測試工具的獲取和第三階段自動測試引入到過程。

        第六章將詳細介紹自動測試過程中的核心——自動測試用例的設計與實現，這部分是以自動測試生命週期的第四階段為指導的。

        第七章主要包括了測試的執行、測試結果的分析及評價，這章與自動測試生命週期中的第五、六階段相對應。

        最後一章是對本自動測試系統的總結。