一、自動測試技術簡介
1. 自動測試的前提條件
自動測試是把以人爲驅動的測試行爲轉化爲機器執行的一種過程。實施自動測試之前需要對軟件開發過程進行分析，以觀察其是否適合使用自動測試。自動測試通常需要滿足以下條件：
1) 軟件需求變動不頻繁
測試腳本的穩定性決定了自動測試的維護成本。如果軟件需求變動過於頻繁，測試人員需要根據變動的需求更新測試用例以及相關的測試腳本，較大的變動勢必會增加維護腳本的成本，導致自動測試失敗。一般情況下，對於需求分析中相對穩定的模塊進行自動測試，而變動較大的模塊仍採用手工測試。
2) 項目週期足夠長
自動測試需求的確定、自動測試框架的設計、測試腳本的編寫與調試均需要相當長的時間來完成。這樣的過程本身就是一個測試軟件的開發過程，需要較長的時間來完成。
3) 自動測試腳本可重複使用
在手工測試無法完成，需要投入大量時間成本與人力成本時，可考慮引入自動測試。
2. 自動測試過程
自動測試與軟件開發過程從本質上來講是一樣的。自動測試過程可概括爲利用自動化測試工具，經過對測試需求的分析，設計出自動測試用例，搭建自動測試的框架，設計與編寫自動測試腳本，測試腳本的正確性，完成該套測試腳本。具體來講可分爲如下步驟：
1) 自動測試需求分析
當測試項目滿足了自動化的前提條件，並確定在該項目中需要使用自動測試時，就可進行自動測試需求分析。此過程需要確定自動測試的範圍以及相應的測試用例、測試數據，並形成詳細的文檔，以便於自動測試框架的建立。
2) 自動測試框架的搭建
自動測試框架與軟件架構一樣，定義了在使用該套腳本時需要調用哪些文件、結構，調用的過程，以及文件結構如何劃分。搭建自動測試框架時需要將如下典型要素考慮進去。
(1) 公用的對象。不同的測試用例會有一些相同的對象被重複使用，比如窗口、按鈕、頁面等。這些公用的對象可被抽取出來，在編寫腳本時調用。當這些對象的屬性因爲需求的變更而改變時，只需要修改該對象屬性即可，無需修改所有相關的測試腳本。
(2) 公用的環境。測試用例使用相同的測試環境，將該測試環境獨立封裝，在各個測試用例中靈活調用，增強腳本的可維護性。
(3) 公用的方法。編寫測試工具經常使用的方法，方便腳本的調用。
(4) 測試數據。一個測試用例往往需要執行多個測試數據，可將測試數據放在獨立的文件中，由測試腳本執行到該用例時自動讀取測試數據文件，以達到數據覆蓋的目的。
3) 自動測試腳本的編寫
自動測試腳本的編寫過程是具體的測試用例的腳本轉換。建議以錄製爲參考，以編寫腳本爲主要行爲，避免錄製腳本帶來的冗餘、公用元素的不可調用、腳本的調試複雜等問題。
4) 腳本的測試與試運行
事實上，測試用例形成的腳本通過測試後，並不意味着執行多個甚至所有的測試用例就不會出錯。輸入數據以及測試環境的改變，都會導致測試結果受到影響甚至失敗。因此，腳本的測試與試運行極爲重要，需要檢查多個腳本不能按計劃執行的原因，並保證其得到修復。
二、自動測試發展歷程
如圖6.1所示，自動測試發展大致經歷瞭如下四個階段。
第一階段：機械方式實現人工重複操作。
最初，自動測試主要研究如何採用自動方法來實現和替代人工測試中的繁瑣和機械重複的工作。通過工人設計測試數據，對程序進行動態執行檢測，腳本驅動自動執行。此時的自動測試活動只是軟件測試過程的偶然行爲，可在一定程度上提高效率，簡化測試人員工作，但對整體的測試過程並無太大改進。
第二階段：統計分析的自動測試。
只有自動測試結果具有可靠性，其使用才具有實際的意義。針對不同的測試準則和測試策略，指導測試的自動化過程以及對測試的結果進行評估。
第三階段：面向目標的自動測試技術。
軟件測試並不是機械和隨機地發現錯誤，而是帶有很強的目的性。進化計算和人工智能等技術，以及各種高性能的算法被引入自動測試技術。
第四階段：智能應用的自動測試技術。
能力成熟度模型被引入軟件工程，測試業界產生對應的測試成熟度模型。不同的自動測試等級成爲測試好壞的一個衡量依據。
三、測試成熟度模型
1. 初始級
TMM初始級軟件測試過程的特點是測試過程無序，有時甚至是混亂的，幾乎沒有妥善定義的。初始級中軟件的測試與調試常常被混爲一談，軟件開發過程中缺乏測試資源、工具以及訓練有素的測試人員。初始級的軟件測試過程沒有定義成熟度目標。
2. 定義級
TMM的定義級中，測試已具備基本的測試技術和方法，軟件的測試與調試已經明確地被區分開。這時，測試被定義爲軟件生命週期中的一個階段，它緊隨編碼階段之後，由於測試計劃往往在編碼之後才得以制訂，這顯然有背於軟件工程的要求。
TMM的定義級中需實現3個成熟度目標：制訂測試與調試目標，啓動測試計劃過程，制度化基本的測試技術和方法。
1) 制訂測試與調試目標
軟件組織必須區分軟件開發的測試過程與調試過程，識別各自的目標、任務和活動。正確區分這兩個過程是提高軟件組織測試能力的基礎。與調試工作不同，測試工作是一種有計劃的活動，可以進行管理和控制。這種管理和控制活動需要制訂相應的策略和政策，以確定和協調這兩個過程。
制訂測試與調試目標包含5個子成熟度目標：
(1) 分別形成測試組織和調試組織，並有經費支持。
(2) 規劃並記錄測試目標。
(3) 規劃並記錄調試目標。
(4) 將測試和調試目標形成文檔，並分發至項目涉及的所有管理人員和開發人員。
(5) 將測試目標反映在測試計劃中。
2) 啓動測試計劃過程
測試計劃作爲過程可重複、可定義和可管理的基礎，包括測試目的、風險分析、測試策略以及測試設計規格說明和測試用例。此外，測試計劃還應說明如何分配測試資源，如何劃分單元測試、集成測試、系統測試和驗收測試。
啓動測試計劃過程包含5個子目標：
(1) 建立組織內的測試計劃組織並予以經費支持。
(2) 建立組織內的測試計劃政策框架並予以管理上的支持。
(3) 開發測試計劃模板並分發至項目的管理者和開發者。
(4) 建立一種機制，使用戶需求成爲測試計劃的依據之一。
(5) 評價、推薦和獲得基本的計劃工具並從管理上支持工具的使用。
3) 制度化基本的測試技術和方法
改進測試過程能力，組織中應用基本的測試技術和方法，並說明何時和怎樣使用這些技術、方法和支持工具。
基本測試技術和方法制度化有如下2個子目標：
(1) 在組織範圍內成立測試技術組，研究、評價和推薦基本的測試技術和測試方法，推薦支持這些技術與方法的基本工具。
(2) 制訂管理方針以保證在全組織範圍內一致使用所推薦的技術和方法。
3. 集成級
TMM的集成級中，測試不再是編碼階段之後的階段，已被擴展成與軟件生命週期融爲一體的一組活動。測試活動遵循V字模型。測試人員在需求分析階段便開始着手製訂測試計劃，根據用戶需求建立測試目標和設計測試用例。軟件測試組織提供測試技術培訓，測試工具支持關鍵測試活動。但是，集成級沒有正式的評審程序，沒有建立質量過程和產品屬性的測試度量。
集成級要實現如下4個成熟度目標：建立軟件測試組織，制訂技術培訓計劃，測試軟件生命週期，控制和監視測試過程。
1) 建立軟件測試組織
軟件測試過程對軟件產品質量有直接影響。測試往往是在時間緊、壓力大的情況下完成一系列複雜活動，測試組完成與測試有關的活動，包括制訂測試計劃，實施測試執行，記錄測試結果，制訂與測試有關的標準和測試度量，建立測試數據庫，測試重用，測試跟蹤以及測試評價等。
建立軟件測試組織要實現4個子目標：
(1) 建立全組織範圍內的測試組，並得到上級管理層的領導和各方面的支持，包括經費支持。
(2) 定義測試組的作用和職責。
(3) 由訓練有素的人員組成測試組。
(4) 建立與用戶或客戶的聯繫，收集他們對測試的需求和建議。
2) 制訂技術培訓計劃
爲高效率地完成好測試工作，測試人員必須經過適當的培訓。 制訂技術培訓規劃有3個子目標：
(1) 制訂組織的培訓計劃，並在管理上提供包括經費在內的支持。
(2) 制訂培訓目標和具體的培訓計劃。
(3) 成立培訓組，配備相應的工具、設備和教材。
3) 測試軟件生命週期
提高測試成熟度和改善軟件產品質量都要求將測試工作與軟件生命週期中的各個階段聯繫起來。
該階段有4個子目標：
(1) 將測試階段劃分爲子階段，並與軟件生命週期的各階段相聯繫。
(2) 基於已定義的測試子階段，採用軟件生命週期V字模型。
(3) 制訂與測試相關的工作產品的標準。
(4) 建立測試人員與開發人員共同工作的機制。這種機制有利於將測試活動集成於軟件生命週期中。
4) 控制和監視測試過程
軟件組織採取如下措施：制訂測試產品的標準，制訂與測試相關的偶發事件的處理預案，確定測試里程碑，確定評估測試效率的度量，建立測試日誌等。
控制和監視測試過程有3個子目標：
(1) 制訂控制和監視測試過程的機制和政策。
(2) 定義、記錄並分配一組與測試過程相關的基本測量。
(3) 開發、記錄並文檔化一組糾偏措施和偶發事件處理預案，以備實際測試嚴重偏離計劃時使用。
4.管理和測量級
TMM的管理和測量級中，測試活動包括軟件生命週期中各個階段的評審、審查和追查，使得測試活動涵蓋軟件驗證和確認活動。因爲測試是可以量化並度量的過程，根據管理和測量級要求，與軟件測試相關的活動，如測試計劃、測試設計和測試步驟都要經過評審。爲了測量測試過程，建立測試數據庫，用於收集和記錄測試用例，應記錄缺陷並按缺陷的嚴重程度劃分等級。
管理和測量級有3個要實現的成熟度目標：建立組織範圍內的評審程序，建立測試過程的測量程序和軟件質量評價。
1) 建立組織範圍內的評審程序
軟件組織應在軟件生命週期的各階段實施評審，以便儘早有效地識別、分類和消除軟件中的缺陷。建立評審程序有3個子目標：
(1) 管理層要制訂評審政策支持評審過程。
(2) 測試組和軟件質量保證組要確定並文檔化整個軟件生命週期中的評審目標、評審計劃、評審步驟以及評審記錄機制。
(3) 評審項由上層組織指定。通過培訓參加評審的人員，使他們理解和遵循相關的評審政策和評審步驟。
2) 建立測試過程的測量程序
測試過程的測量程序是評價測試過程質量、改進測試過程的基礎，對監視和控制測試過程至關重要。測量包括測試進展、測試費用、軟件錯誤和缺陷數據以及產品測量等。
建立測試測量程序有3個子目標：
(1) 定義組織範圍內的測試過程測量政策和目標。
(2) 制訂測試過程測量計劃。測量計劃中應給出收集、分析和應用測量數據的方法。
(3) 應用測量結果制訂測試過程改進計劃。
3) 軟件質量評價
軟件質量評價內容包括定義可測量的軟件質量屬性，定義評價軟件工作產品的質量目標等項工作。軟件質量評價有2個子目標：
(1) 管理層、測試組和軟件質量保證組要制訂與質量有關的政策、質量目標和軟件產品質量屬性。
(2) 測試過程應是結構化、已測量和已評價的，以保證達到質量目標。
5.優化、預防缺陷和質量控制級
本級的測試過程是可重複、可定義、可管理的，因此軟件組織優化調整和持續改進測試過程。測試過程的管理爲持續改進產品質量和過程質量提供指導，並提供必要的基礎設施。
優化、預防缺陷和質量控制級有3個要實現的成熟度目標。
1) 應用過程數據預防缺陷
此時的軟件組織能夠記錄軟件缺陷，分析缺陷模式，識別錯誤根源，制訂防止缺陷再次發生的計劃，提供跟蹤這種活動的辦法，並將這些活動貫穿於全組織的各個項目中。
應用過程數據預防缺陷的成熟度有如下4個子目標：
(1) 成立缺陷預防組。
(2) 識別和記錄在軟件生命週期各階段引入的軟件缺陷和消除的缺陷。
(3) 建立缺陷原因分析機制，確定缺陷原因。
(4) 管理、開發和測試人員互相配合制訂缺陷預防計劃, 防止已識別的缺陷再次發生。缺陷預防計劃要具有可跟蹤性。
2) 支持軟件質量控制
軟件組織通過採用統計採樣技術，測量組織的自信度，測量用戶對組織的信賴度以及設定軟件可靠性目標來推進測試過程。爲了加強軟件質量控制，測試組和質量保證組要有負責質量的人員參加，他們應掌握能減少軟件缺陷和改進軟件質量的技術和工具。
支持統計質量控制的子目標有：
(1) 軟件測試組和軟件質量保證組建立軟件產品的質量目標，如產品的缺陷密度、組織的自信度以及可信賴度等。
(2) 測試管理者要將這些質量目標納入測試計劃中。
(3) 培訓測試組學習和使用統計學方法。
(4) 收集用戶需求以建立使用模型。
3) 優化測試過程
優化測試過程在測試成熟度的最高級，已能夠量化測試過程。這樣就可以依據量化結果來調整測試過程，不斷提高測試過程能力，並且軟件組織具有支持這種能力持續增長的基礎設施。基礎設施包括政策、標準、培訓、設備、工具以及組織結構等。
優化測試過程包含：
(1) 識別需要改進的測試活動。
(2) 實施改進。
(3) 跟蹤改進進程。
(4) 不斷評估所採用的與測試相關的新工具和新方法。
(5) 支持技術更新。
優化測試過程所需子成熟度目標包括：
(1) 建立測試過程改進組，監視測試過程並識別其需要改進的部分。
(2) 建立適當的機制以評估改進測試過程能力和測試成熟度的新工具和新技術。
(3) 持續評估測試過程的有效性，確定測試終止準則。終止測試的準則要與質量目標相聯繫。
總之，TMM的5個階段可總結如下：
第一階段：測試和調試沒有區別，除了支持調試外，測試沒有其它目的。
第二階段：測試的目的是表明軟件能夠工作。
第三階段：測試的目的是表明軟件能夠正常工作。
第四階段：測試的目的不是要證明什麼，而是要把軟件不能正常工作的預知風險降低到能夠接受的程度。
第五階段：測試成爲了自覺的約束，不用太多的測試投入即可產生低風險的軟件。
綜上所述，以下給出了測試成熟度模型的基本描述。
測試成熟度模型的基本描述
|
級別
|
簡單描述
|
特徵
|
目標
|
| 初始級 |
測試處於一個混亂的狀態，缺乏成熟的測試目標，測試處於可有可無的地位
|
還不能把測試同調試分開;
編碼完成後才進行測試工作;
測試的目的是表明程序沒有錯;
缺乏相應的測試資源
|
|
|
定義級
|
測試目標是驗證軟件是否符合需求，會採用基本的測試技術和方法
|
測試被看做是有計劃的活動;
測試同調試分開;
在編碼完成後才進行測試工作
|
啓動測試計劃過程;將基本的測試技術和方法
制度化
|
|
集成級
|
測試不再是編碼後的個階段，而是貫穿在整個軟件生命週期中，測試建立在滿足用戶或客戶的需求上
|
具有獨立的測試部門;
根據用戶需求設計測試用例;
有測試工具輔助進行測試工作;
沒有建立起有效的評審制度;
沒有建立起質量控制和質量度量標準
|
建立軟件測試組織;制.訂技術培訓計劃;測試在
整個生命週期內進行;控制和監視測試過程
|
| 管理和度量級 |
測試是一個度量和質量的控制過程。在軟件生命週期中，評審被作爲測試和軟件質量控制的一部分
|
進行可靠性、可用性和可維護性等方面的測試;
採用數據庫來管理測試用例;
具有缺陷管理系統並劃分缺陷的級別;
還沒有建立起缺陷預防機制，缺乏自動對測試中產生的數據進行收集和分析的手段
|
實施軟件生命週期中各階段評審:建立測試數據庫並記錄、收集有關測試數據;建立組織範圍內的評審程序;建立測試過程的度量方法和程序;進行軟件質量評價
|
|
優化級
|
具有缺陷預防和質量控制的能力，已經建立起測試規範和流程，並不斷地進行測試改進.
|
運用缺陷預防和質量控制措施;
選擇和評估測試工具存在一個既定的流程;
測試自動化程度高;自動收集缺陷信息;
有常規的缺陷分析機制
|
應用過程數據預防缺陷，統計質量控制，建立
軟件產品的質量目標，持續改進、優化測試過程
|
四、三代測試框架
測試框架是爲自動化軟件測試提供支持的集合。測試框架經歷瞭如下發展過程：
第一代，無測試框架。
無測試框架幾乎沒有起到自動化測試管理作用，測試需求與測試用例關聯非常弱，對自動化測試人員的編程水平以及對測試方面的整體知識把握要求都非常高。
第二代，部分的測試框架。
部分的測試框架完成部分自動化測試管理，實現對測試用例的管理和缺陷跟蹤，面向業務流，實現自動化測試需編寫程序。
第三代，完整的測試框架。
完整的測試框架具有如下功能：
(1) 基於完整的BPT的測試框架；
(2) 擁有數據場景管理；
(3) 企業級的面向工作流的缺陷管理；
(4) 業務流複用框架，輕鬆完成；
(5) 高伸縮的自動執行框架。
五、自動測試原理
自動測試模擬人工對計算機的操作過程和操作行爲，採用類似於編譯的方法對程序代碼進行檢查。自動測試原理可概括如下：直接對代碼進行靜態和動態分析、測試過程的捕獲和回放、測試腳本技術和虛擬用戶技術。
1. 代碼分析
代碼分析是白盒測試的自動化方法，類似於高級編譯系統，一般針對高級語言構造分析工具，定義類、對象、函數、變量等定義規則和語法規則，對代碼進行語法掃描，找出不符合編碼規範的地方，根據某種質量模型評價代碼質量，生成系統的調用關係圖等。
2. 錄製回放
錄製回放是黑盒測試的自動化方法，通過捕獲用戶的每一步操作，如用戶界面的像素座標或程序顯示對象(窗口、按鈕、滾動條等)的位置以及相應操作、狀態變化或屬性變化，用一種腳本語言記錄描述，模擬用戶操作。回放時，將腳本語言轉換爲屏幕操作，比較被測系統的輸出記錄與預先給定的標準結果。
目前的自動化負載測試解決方案几乎都是採用“錄製—回放”的技術。所謂“錄製—回放”技術，就是先由手工完成一遍測試流程，由計算機記錄下這個流程期間客戶端和服務器端之間的通信信息(這些信息通常是一些協議和數據)，並形成特定的腳本程序。然後在系統的統一管理下同時生成多個虛擬用戶，並運行該腳本，監控硬件和軟件平臺的性能，提供分析報告或相關資料。通過模擬出成百上千的用戶對應用系統進行負載能力的測試。
3. 腳本技術
1) 腳本概述
腳本是一組測試工具執行的指令集合，也是計算機程序的另一種表現形式。腳本至少具有如下的功能：
(1) 支持多種常用的變量和數據類型；
(2) 支持各種條件邏輯和循環結構；
(3) 支持函數的創建和調用。
腳本有兩種：一種是手動編寫或嵌入源代碼；一種是通過測試工具提供的錄製功能，運行程序自動錄製生成腳本。錄製生成腳本簡單且智能化，容易操作，但僅靠自動錄製腳本無法滿足用戶複雜的要求，因此需要手工添加函數進行參數設置，增強腳本的實用性。
2) 腳本分類
腳本分爲以下幾種類型：
(1) 線性腳本。錄製手工執行的測試用例得到的線性腳本，包含用戶鍵盤和鼠標輸入，用於檢查某個窗口是否彈出等操作。
(2) 結構化腳本。結構化腳本類似於結構化程序設計，包含控制腳本執行指令，具有順序、循環和分支等結構。結構化腳本的優點是健壯性好，通過循環和調用減少工作量，缺點是較複雜，而且測試數據仍然與腳本“捆綁”在一起。
(3) 共享腳本。共享腳本側重描述腳本中共享的特性，腳本可以被多個測試用例使用，一個腳本可以被另一個腳本調用。當重複任務發生變化時，只需修改一個腳本，便可達到腳本共享的目的。
4. 虛擬用戶技術
虛擬用戶技術通過模擬真實用戶行爲對被測程序(Application Under Test，AUT)施加負載，測量AUT的性能指標值，如事務的響應時間、服務器吞吐量等。虛擬用戶技術以真實用戶的“商務處理”(用戶爲完成一個商業業務而執行的一系列操作)作爲負載的基本組成單位，用“虛擬用戶”(模擬用戶行爲的測試腳本)模擬真實用戶。
負載需求(例如併發虛擬用戶數、處理的執行頻率等)通過人工收集和分析系統使用信息來獲得，負載測試工具模擬成千上萬個來自不同IP地址、不同瀏覽器類型以及不同網絡連接方式的虛擬用戶同時訪問AUT，並實時監視系統性能，幫助測試人員分析測試結果。虛擬用戶技術具有成熟測試工具支持，但確定負載的信息要依靠人工收集，因此準確性不高。
六、自動測試的19條經驗教訓
Elfriede Dustin在總結了多年的自動測試項目經驗後，提出了19條經驗教訓：
(1) 在軟件開發週期中使用的各種工具不能夠很輕易地整合在一起(The various tools used throughout the development lifecycle did not easily integrate)。
(2) 很多冗餘的信息被存儲在多個庫中(Duplicate information was kept in multiple repositories)。
(3) 被測試工具牽着鼻子走(The automated testing tool drove the testing effort)。
(4) 整個測試組的每個人都在忙着編寫自動測試腳本(Everyone on the testing staff was busy trying to automate scripts)。
(5) 重複開發的勞動，嘗試編寫一些非常複雜的測試腳本(Elaborate test scripts were developed，duplicating the development effort)。
(6) 自動測試腳本的創建往往會很麻煩，而不像工具廠商所吹噓的那樣簡單易用(Automated test script creation was cumbersome)。
(7) 工具的培訓開展得太遲，測試工程師缺乏工具方面的知識(Training was too late in the process，so test engineers lacked tool knowledge)。
(8) 測試工具在系統測試前兩週才引入(The test tool was introduced to the testing program with two weeks left for system testing)。
(9) 測試人員對工具有牴觸情緒(Testers resisted the tool)。
(10) 對自動化測試的期待值過高，期待及早得到回報(There were expectations of early payback)。
(11) 工具在識別第三方控件方面存在問題(The tool had problems recognizing third-party controls (widgets))。
(12) 缺乏測試腳本開發的規範性指南(A lack of test development guidelines was noted)。
(13) 某些測試工具需要插入代碼到被測試程序中，但是開發人員直到測試後期才被告知這個問題(The tool was intrusive，but the development staff wasn’t informed of this problem until late in the testing lifecycle)。
(14) 工具創建的報告沒什麼用處(Reports produced by the tool were useless)。
(15) 在尚未確定系統工程環境之前就選擇和購買工具(Tools were selected and purchased before a system engineering environment was defined)。 (16) 工具的不同版本都在使用(Various tool versions were in use)。
(17) 工具的升級與現有的系統工程環境不兼容(The new tool upgrade wasn’t compatible with the existing system engineering environment)。
(18) 工具的數據庫不允許擴展(The tool’s database didn’t allow for scalability)。
(19) 未能正確地使用測試工具的管理功能，導致時間的浪費(Incorrect use of a test tool’s management functionality results in wasted time)。
七、自動測試研究熱點
目前，軟件自動測試研究的主要熱點如下。
1. 測試自動化框架
實際測試情況中，項目開發中同時包含了可實現自動化的測試活動以及難以完全實現自動化的測試活動。在自動測試與軟件開發過程相融合的過程中，自動測試技術或測試方法難以完全匹配到整個項目中。而且，由於項目開發的動態特性，也難以使用通用的、普適的自動測試模型來完成測試，這就要求設計出具有較大可塑性的自動測試模型，在較少改動或者配置的情況下，最大化適應自動化測試的需求。
2. 測試自動化腳本技術
在測試過程中，大量的測試行爲被自動化，測試人員指定一些簡單的腳本，指導測試的自動化進行。例如，對應用程序的測試，人工的測試方式用腳本方式自動模擬執行，節省人力資源。但是，衆多的自動測試工具包含了不同的腳本語言，測試人員必須學習不同的測試自動化腳本語言，如果測試腳本語言標準化且易於掌握，則可以簡化自動測試的複雜性和減少測試人員的工作量。因此，對測試自動化腳本技術的研究也是自動測試技術中的一個主要內容。
3. 自動測試用例生成
最初的自動測試用例生成採用隨機方式，這種方法簡單且易於實現，但測試效率不高，受測試空間的分佈影響，會有大量的測試冗餘數據產生。採用啓發式學習方法設計的測試用例在生成效率上有了較大的提高，包括使用進化計算或智能計算等技術，指導測試用例的自動生成，這些方法採用反饋方式對測試用例的產生進行自學習，可加速有效測試用例的生成，抑制和減少冗餘數據的生成。 自動化測試用例的生成是一種典型的數據驅動測試技術，通過自動化測試數據的生成，測試程序中存在的缺陷或錯誤。由於測試用例對測試的重要性，以及測試數據自動構造實現上的可行性，使得這個領域成爲自動測試技術中研究得最爲廣泛的技術之一。
4. 測試自動化中的預測
自動測試技術的發展不僅僅是自動化程度的提高，同時在測試的性能和效率上都提出了更高的要求。雖然測試的活動或行爲已能夠很大程度上實現自動化，但對測試結果的判定仍然依賴於人工干預。如果在測試過程中能通過特定的評測標準判斷什麼是程序錯誤，那麼測試就能夠實現真正意義的自動化。因此，測試預測是自動測試技術中非常關鍵的研究內容，直接關係到測試結果的準確性。
目前，對測試自動化中的預測問題的研究仍相對較少，研究大多集中在使用外部規則說明產生測試預測，該信息被作爲自動測試過程發現錯誤的參照。
5. 自動測試與可靠性分析
自動測試是一個反覆的過程，測試與可靠性之間的關係一直都是技術人員所關注的內容。究竟在多大程度上可以信任測試的結果，什麼條件下所完成的測試纔是充分的，只有解決了這些問題自動測試才能體現出其價值和意義。自動測試技術是爲了提高測試的效率，各種自動化測試方法和技術的引入是否會影響測試的結果以及測試評測的可信度，這些都使得對自動測試的可靠性分析的研究非常有必要。
6. 自動化安全測試
該領域的研究主要集中在網絡通信協議的安全性測試方面。隨着網絡應用的日益廣泛，信息安全問題也日益嚴重，網絡應用程序的安全性是測試的重要內容。針對網絡安全的有限狀態，自動測試機模型是該領域的主要研究內容。
簡答題
1．自動測試相對於手工測試有什麼好處？
2. 自動測試發展經過了幾個階段？
3. 測試成熟度模型是什麼？其包括哪些內容？
4. 錄製和回放是指什麼？
5. 腳本技術可以分爲幾類？分別是什麼？