件測試知識帖(21-40)

件測試知識帖(21-40)

第21帖【2004－6－6】：迴歸測試

Roger S. Pressman

每當一個新的模塊被當作集成測試的一部分加進來的時候，軟件就發生了改變。新的數據流路徑建立起來，新的I/O操作可能也會出現，還有可能激活了新的控制邏輯。這些改變可能會使原本工作得很正常的功能產生錯誤。在集成測試策略的環境中，迴歸測試是對某些已經進行過的測試的某些子集再重新進行一遍，以保證上述改變不會傳播無法預料的副作用。

在更廣的環境裏，（任何種類的）成功測試結果都是發現錯誤，而錯誤是要被修改的，每當軟件被修改的時候，軟件配置的某些方面（程序、文檔、或者數據）也被修改了，迴歸測試就是用來保證（由於測試或者其他原因的）改動不會帶來不可預料的行爲或者另外的錯誤。

迴歸測試可以通過重新執行所有的測試用例的一個子集人工地進行，也可以使用自動化的捕獲回放工具來進行。捕獲回放工具使得軟件工程師能夠捕獲到測試用例，然後就可以進行回放和比較。迴歸測試集（要進行的測試的子集）包括三種不同類型的測試用例：

·能夠測試軟件的所有功能的代表性測試用例。

·專門針對可能會被修改影響的軟件功能的附加測試。

·針對修改過的軟件成分的測試。

在集成測試進行的過程中，迴歸測試可能會變得非常龐大。因此，迴歸測試應當設計爲只對出現錯誤的模塊的主要功能進行測試，每當進行一個修改時，就對每一個程序功能都重新執行所有的測試是不實際的而且效率很低的。

第22帖【2004－6－7】：測試與調試

測試的目的是顯示存在錯誤，而調試的目的是發現錯誤或導致程序失效的錯誤原因，並修改程序以修正錯誤。調試是測試之後的活動。[Beizer,1984]認爲，測試和調試在目標、方法和思路上都有所不同，如下：

1、測試從一個已知的條件開始，使用預先定義的過程，有預知的結果。調試從一個未知的條件開始，結束的過程不可預計。

2、測試過程可以實現設計，進度可實現確定。調試不能描述過程或持續時間。

3、測試是顯示錯誤的行爲。調試是推理的過程。

4、測試顯示開發人員的錯誤。調試是開發人員爲自己辯護。

5、測試能預期和可控。調試需要想象，經驗和思考。

6、測試能在沒有詳細設計的情況下完成。沒有詳細設計的信息調試不可能進行。

7、測試能由非開發人員進行。調試必須由開發人員進行。

第23帖【2004－6－8】：系統測試方法之功能測試

功能測試又稱正確性測試，它檢查軟件的功能是否符合規格說明。由於正確性是軟件最重要的質量因素，所以其測試也最重要。

基本的方法是構造一些合理輸入，檢查是否得到期望的輸出。這是一種枚舉方法。測試人員一定要設法減少枚舉的次數，否則測試投入太大。關鍵在於尋找等價區間，因爲在等價區間中，只需用任意值測試一次即可。等價區間的概念可表述如下：

記（A，B）是命題f(x)的一個等價區間，在（A，B）中任意取x1進行測試。如果f(x1) 錯誤，那麼f (x) 在整個（A，B）區間都將出錯。如果f(x1) 正確，那麼f (x) 在整個（A，B）區間都將正確。

上述測試方法稱爲等價測試，來源於人們的直覺與經驗，可令測試事半功倍。

還有一種有效的測試方法是邊界值測試。即採用定義域或者等價區間的邊界值進行測試。因爲程序員容易疏忽邊界情況，程序也“喜歡”在邊界值處出錯。

例如測試平方根函數的一段程序。憑直覺輸入等價區間應是（0，1）和（1，+∞）。可取x=0.5以及x=2.0進行等價測試。再取x=0以及x=1進行邊界值測試。

有一些複雜的程序，我們難以憑直覺與經驗找到等價區間和邊界值，這時枚舉測試就相當有難度。

第24帖【2004－6－9】：黑盒測試的端口測試模型

端口測試模型側重於對被測對象的抽象，它闡明的是我們要測試什麼。它將被測試者間的共性抽象出來，使測試者和被測者可以最大程度地分離開來。

其主要思想是：被測試者可以用測試端口集來表達。

測試功能體現在測試端口對外協議（稱爲端口協議）的實現，對不同系統的測試或對同一系統中不同子系統的測試都表現爲對不同端口的測試。端口協議一般是非確定的有限自動機（NFA)，它可以分解成確定的有限自動機（DFA)的集合（對應於功能遷移路徑集），並可以用結構化語言描述在測試用例中。這樣，端口協議的差異就不會影響測試者的內部實現（與被測者的接口除外）。

第25帖【2004－6－10】：黑盒測試的對象測試模型

對象測試模型注重於測試內容的表達，它闡明的是如何表達我們的測試內容。它把分散的功能測試單元有機地組合起來，使實際測試更逼近真正的系統測試。

其主要思想是：測試內容及測試的實現方法（指對測試數據的處理）可以被封裝在一個個的測試對象中。

測試對象有三個層次：數據對象、業務對象和事務對象，它們的關係是逐級被包含。簡單來說，數據對象是指業務（或功能）數據的載體，它通常有物理對應，其主要測試內容是一個狀態遷移圖；業務對象指共同實現一種業務（或功能）的數據對象集合，它一般都只有邏輯對應，其主要測試內容是一個時間追蹤圖；事務對象是指一組業務相關的業務對象的有序組合，其主要測試內容是業務間的關係圖，準確地說是業務結果間的布爾關係圖。

第26帖【2004－6－11】：黑盒測試的分層設計模型

分層設計模型側重於黑盒自動測試工具的實現，它闡明的是我們如何設計測試工具。它將測試工具的功能進行抽象和分層，使測試工具的積木化開發現實可行。

其主要思想是：測試工具可劃分爲五個不同的層次，從低到高依次是：端口驅動層、測試執行層、測試表達層、測試管理層、測試設計層。通過規範這五個層次間的接口，可以使按照這個設計模型設計的測試工具或提供相同的接口的其它測試工具無縫地集成在一起，從而實現理想的積木式開發。

第27帖【2004－6－12】：QA的職責

QA到底應該在企業裏起什麼作用呢？下面是QA職責的總結：

1、保障軟件組織流程體系得到遵守；

2、促使軟件組織過程改進；

3、指導項目實施流程，；

4、增加開發活動透明度；

5、評審項目活動；

6、審覈工作產品；

7、協助工作產品問題解決；

8、度量數據採集、分析，提供決策參考；

9、進行缺陷預防；

10、實現質量目標。

第28帖【2004－6－13】：軟件走讀

軟件走讀的目的是爲了對軟件產品進行評價，軟件走讀也可以是爲給參與走讀的人員培訓有關軟件產品知識而舉行，軟件走讀的主要目的是：

1）發現軟件產品中的軟件異常，缺陷、遺漏和自相矛盾的地方，以改進產品並提出可供選擇的實現方案；

2）改進軟件產品；

3）考慮可選項方案的實現方法；

4）評價與標準和規格的符合性；

5）進行技術交流，人員培訓。

在軟件走讀中可以指出各種缺陷，例如軟件產品中的效率和可讀性問題，設計或編碼中模塊化問題，或者規格書中的可測試問題等等。

要求進行軟件走讀的軟件產品，包括但不限於：

1）軟件需求規格，

2）軟件設計文檔，

3）源代碼，

4）軟件測試文檔，

5）軟件用戶文檔，

6）維護手冊，

7）安裝過程

第29帖【2004－6－14】：TCL簡介

TCL是一腳本解釋器，具有基本的語言特性，支持整型和字符串變量，支持循環等控制結構；同時它具有靈活的擴展性和跨平臺的特性，後者是它最主要的特性。通過TCL腳本可以編寫測試用例，通過擴展功能，可以擴展你想要的測試動作。最終目的是將測試的自動化和靈活性（可擴展性）結合在一起。

TCL提供以下接口：

1、用戶接口

對用戶提供語言特性，如循環、條件判斷等控制結構，通過它用戶可以靈活的書寫測試用例；當然只提供語言特性遠遠不夠，因爲業務千差萬別，所以用戶需要業務接口，從而完成特定的測試任務。 而業務接口，是通過下面的程序員接口實現。

2、程序員接口

用戶可以編寫自己命令，它包括用戶層（即名字）和實現層（通過C語言實現），然後用TCL提供的註冊函數登記，以後命令就可靈活的嵌入到腳本中了。

TCL測試模型分三部分：

被測試程序（由開發人員編寫）----測試人員應搞清楚程序結構和業務功能，指導擴展命令的設計。

測試代碼（由測試設計人員編寫） ---通過程序員接口，提供給腳本擴展命令。

測試用例（TCL腳本形式，由測試執行人員編寫）---通過腳本對擴展命令進一步組合。

第30帖【2004－6－15】：CMM的五級簡介

CMM爲企業的軟件過程能力提供了一個階梯式的進化框架，階梯共有五級。第一級只是一個起點，任何準備按CMM體系進化的企業都自然處於這個起點上，並通過它向第二級邁進。除第一級外，每一級都設定了一組目標，如果達到了這組目標，則表明達到了這個成熟級別，可以向下一級別邁進。

第一級、初始級：

初始級的軟件過程是未加定義的隨意過程，項目的執行是隨意甚至是混亂的。也許有些企業制定了一些軟件工程規範，但若這些規範未能覆蓋基本的關鍵過程要求，且執行沒有政策、資源等方面的保證時，那麼它仍然被視爲初始級。

第二級、重複級：

根據多年的經驗和教訓，人們總結出軟件開發的首要問題不是技術問題而是管理問題。因此，第二級的焦點集中在軟件管理過程上。一個可管理的過程則是一個可重複的過程，可重複的過程才能逐漸改進和成熟。可重複級的管理過程包括了需求管理、項目管理、質量管理、配置管理和子合同管理五個方面；其中項目管理過程又分爲計劃過程和跟蹤與監控過程。通過實施這些過程，從管理角度可以看到一個按計劃執行的且階段可控的軟件開發過程。

第三級、定義級：

在可重複級定義了管理的基本過程，而沒有定義執行的步驟標準。在第三級則要求制定企業範圍的工程化標準，並將這些標準集成到企業軟件開發標準過程中去。所有開發的項目需根據這個標準過程，裁剪出與項目適宜的過程，並且按照過程執行。過程的裁剪不是隨意的，在使用前必須經過企業有關人員的批准。

第四級、管理級：

第四級的管理是量化的管理。所有過程需建立相應的度量方式，所有產品的質量（包括工作產品和提交給用戶的最終產品）需要有明確的度量指標。這些度量應是詳盡的，且可用於理解和控制軟件過程和產品。量化控制將使軟件開發真正成爲一種工業生產活動。

第五級、優化級：

優化級的目標是達到一個持續改善的境界。所謂持續改善是指可以根據過程執行的反饋信息來改善下一步的執行過程，即優化執行步驟。如果企業達到了第五級，就表明該企業能夠根據實際的項目性質、技術等因素，不斷調整軟件生產過程以求達到最佳。

第31帖【2004－6－16】：CMM 2級KPA的目標

CMM 2級：可重複級

Requirement Management

需求管理

Goal 1 System requiremnets allocated to software are controlled to establish a baseline for software engineering and management use.

目標1：分配到軟件部分的系統需求通過建立基線受控。

Goal 2 Software plans, products, and activities are kept consistent with the system requirements allocated to software.

目標2：軟件計劃、產品和活動與分配到軟件部分的系統需求一致。

Software Project Planning

軟件項目計劃

Goal 1 Software estimates are documented for use in planning and tracking the software project.

目標1：用來計劃和跟蹤軟件項目的軟件估計文檔化。

Goal 2 Software project activities and commitments are planned and documented.

目標2：制定了軟件項目活動和任務書的計劃，並且有文檔記錄。

Goal 3 Affected groups and individuals agree to their commitments related to the software project.

目標3：受影響的小組和個人接受和軟件項目相關的任務書。

Software Project Tracking and Oversight

軟件項目跟蹤及監控

Goal 1 Actual results and performances are tracked against the software plans.

目標1：按照軟件計劃跟蹤實際結果和性能。

Goal 2 Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans.

目標2：當實際的結果和性能嚴重偏離軟件計劃時，採取了正確的行動終止這種狀況。

Goal 3 Changes to sofware commitments are agreed to by the affected groups and individuals.

目標3：受影響的小組和個人接受軟件任務書的變化。

Software Subcontract Management

軟件子合同管理

Goal 1 The prime contractor selects qualified software subcontractors.

目標1：主簽約人挑選有資格的子簽約人。

Goal 2 The prime contractor and the software subcontractor agree to their commitments to each other.

目標2：主簽約人和子簽約人互相接受他們的任務書。

Goal 3 The prime contractor and the software subcontractor maintain ongoing communications.

目標3：主簽約人和子簽約人保持持續的溝通。

Goal 4 The prime contractor tracks the software subcontractor's actual results and performance against its commitments.

目標4：主簽約人按照任務書跟蹤子簽約人的實際結果和效能。

Software Quality Assurance

軟件質量保證

Goal 1 Software quality assurance activities are planned.

目標1：制定了軟件質量保證計劃。

Goal 2 Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively.

目標2：客觀地檢驗軟件產品和活動是否符合適用的標準、過程和需求。

Goal 3 Affected groups and individuals are informed of software quality assurance activities and results.

目標3：軟件質量保證的活動和結果通知了受影響的小組和個人。

Goal 4 Noncompliance issues that cannot be resolved within the software project are addressed by senior management.

目標4：高層管理着手解決在軟件項目內部不能解決的不符合項。

Software Configuration Management

軟件配置管理

Goal 1 Software configuration management activities are planned.

目標1：制定了軟件配置管理活動的計劃。

Goal 2 Selected software work products are identified, controlled, and available.

目標2：選定的軟件工作產品是被標識的、受控的和可利用的。

Goal 3 Changes to identified software work products are controlled.

目標3：被標識的軟件工作產品的變化是受控的。

Goal 4 Affected groups and individuals are informed of the status and content of software baselines.

目標4：軟件基線的狀態和內容通知受影響的小組和個人。

第32帖【2004－6－17】：Logiscope的功能

LOGISCOPE是爲軟件的全面質量控制而開發的強大工具，可以用在編程、測試和維護階段。LOGISCOPE五個模塊的功能：

(1) 閱讀器(Viewer)：以文件調用圖(各部件文件之間的關係)及組件調用圖(函數和程序間的調用關係)的形式進行可視化應用軟件設計。可以在各種各樣的抽象級別上分析應用程序，在不同級別上的引導有助於整個應用程序的理解。

(2) 效果檢查器(ImpactChecker)：允許用戶檢查使用的資源(文件、函數、用戶定義類型、全局變量、結構成員常量)。它有助於我們理解函數間的信息流(參數傳遞)，以及數據和其它應用程序資源間的關係。

(3)規則檢查器(RuleChecker)：軟件公司應該定義自己的編程規則和質量目標。這樣做的好處是公司編程行爲保持一致性、易於維護、提高可靠性、易於移植到其它機器上。我們可以用規則檢查器(RuleChecker)確立編程標準，保證質量控制。

(4) 測試檢查器(TestChecker)：實時度量測試覆蓋率、顯示未覆蓋路徑原始數據、生成測試報告、幫助管理測試實例。測試檢查器(TestChecker)和動態分析器 (Dynamic Analyzer)通過閱讀器產生用於應用程序分析的數據。

(5) 代碼檢查器(CodeChecker)：驗證應用程序與質量模型的一致性。代碼檢查器和靜態分析器(Static Analyzer)通過閱讀器(Viewer)產生用於應用程序分析的數據。代碼檢查器(CodeChecker)可以使我們儘早發現和修改質量缺陷。這對質量控制尤爲重要。

第33帖【2004－6－18】：α測試

α測試是由一個用戶在開發環境下進行的測試，也可以是開發機構內部的用戶在模擬實際操作環境下進行的測試。軟件在一個自然設置狀態下使用。開發者坐在用戶旁邊，隨時記下錯誤情況和使用中的問題。這是在受控制的環境下進行的測試，α測試的目的是評價軟件產品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。尤其注重產品的界面和特色。α測試人員是除開產品開發人員之外首先見到產品的人，他們提出的功能和修改意見是特別有價值的。 α測試可以從軟件產品編碼結束之時開始，或在模塊（子系統）測試完成之後開始，也可以在確認測試過程中產品達到一定的穩定和可靠程序之後再開始。有關的手冊（草稿）等應事先準備好。

第34帖【2004－6－19】：β測試

β測試是由軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。這些用戶是與公司簽定了支持產品預發行合同的外部客戶，他們要求使用該產品，並願意返回有關錯位錯誤信息給開發者。與α測試不同的是，開發者通常不在測試現場。因而，β測試是在開發者無法控制的環境下進行的軟件現場應用。在β測試中，由用戶記下遇到的所有問題，包括真實的以及主觀認定的，定期向開發者報告，開發者在綜合用戶的報告之後，做出修改，最終將軟件產品交付給全體用戶使用。 β測試主要衡量產品的FLURPS。着重於產品的支持性，包括文檔、客戶培訓和支持產品生產能力。只有當α測試達到一定的可靠程度時，才能開始β測試。由於它處在整個測試的最後階段，不能指望這時發現主要問題。同時，產品的所有手冊文本也應該在此階段完全定稿。

由於β測試的主要目標是測試可支持性，所以β測試應儘可能由主持產品發行的人員來管理。

第35帖【2004－6－20】：面向對象的集成測試

傳統的集成測試，是通過各種集成策略集成各功能模塊進行測試，一般可以在部分程序編譯完成的情況下進行。而對於面向對象程序，相互調用的功能是散佈在程序的不同類中，類通過消息相互作用申請和提供服務。類的行爲與它的狀態密切相關，狀態不僅僅是體現在類數據成員的值，也許還包括其他類中的狀態信息。由此可見，類相互依賴極其緊密，根本無法在編譯不完全的程序上對類進行測試。所以，面向對象的集成測試通常需要在整個程序編譯完成後進行。此外，面向對象程序具有動態特性，程序的控制流往往無法確定，因此也只能對整個編譯後的程序做基於黑盒子的集成測試。

面向對象的集成測試能夠檢測出相對獨立的單元測試無法檢測出的那些類相互作用時纔會產生的錯誤。基於單元測試對成員函數行爲正確性的保證，集成測試只關注於系統的結構和內部的相互作用。面向對象的集成測試可以分成兩步進行：先進行靜態測試，再進行動態測試。

靜態測試主要針對程序的結構進行，檢測程序結構是否符合設計要求。現在流行的一些測試軟件都能提供一種稱爲"可逆性工程"的功能，即通過原程序得到類關係圖和函數功能調用關係圖，例如International Software Automation 公司的Panorama-2 、Rational公司的Rose C++ Analyzer等，將"可逆性工程"得到的結果與OOD的結果相比較，檢測程序結構和實現上是否有缺陷。換句話說，通過這種方法檢測OOP是否達到了設計要求。

動態測試設計測試用例時，通常需要上述的功能調用結構圖、類關係圖或者實體關係圖爲參考，確定不需要被重複測試的部分，從而優化測試用例，減少測試工作量，使得進行的測試能夠達到一定覆蓋標準。測試所要達到的覆蓋標準可以是：達到類所有的服務要求或服務提供的一定覆蓋率；依據類間傳遞的消息，達到對所有執行線程的一定覆蓋率；達到類的所有狀態的一定覆蓋率等。同時也可以考慮使用現有的一些測試工具來得到程序代碼執行的覆蓋率。

具體設計測試用例，可參考下列步驟：

1. 先選定檢測的類，參考OOD分析結果，仔細出類的狀態和相應的行爲，類或成員函數間傳遞的消息，輸入或輸出的界定等。

2. 確定覆蓋標準。

3. 利用結構關係圖確定待測類的所有關聯。

4. 根據程序中類的對象構造測試用例，確認使用什麼輸入激發類的狀態、使用類的服務和期望產生什麼行爲等。

值得注意，設計測試用例時，不但要設計確認類功能滿足的輸入，還應該有意識的設計一些被禁止的例子，確認類是否有不合法的行爲產生，如發送與類狀態不相適應的消息，要求不相適應的服務等。根據具體情況，動態的集成測試，有時也可以通過系統測試完成。

第36帖【2004－6－21】：面向對象的系統測試

通過單元測試和集成測試，僅能保證軟件開發的功能得以實現。但不能確認在實際運行時，它是否滿足用戶的需要，是否大量存在實際使用條件下會被誘發產生錯誤的隱患。爲此，對完成開發的軟件必須經過規範的系統測試。換個角度說，開發完成的軟件僅僅是實際投入使用系統的一個組成部分，需要測試它與系統其他部分配套運行的表現，以保證在系統各部分協調工作的環境下也能正常工作。　　

系統測試應該儘量搭建與用戶實際使用環境相同的測試平臺，應該保證被測系統的完整性，對臨時沒有的系統設備部件，也應有相應的模擬手段。系統測試時，應該參考OOA分析的結果，對應描述的對象、屬性和各種服務，檢測軟件是否能夠完全"再現"問題空間。系統測試不僅是檢測軟件的整體行爲表現，從另一個側面看，也是對軟件開發設計的再確認。

這裏說的系統測試是對測試步驟的抽象描述。它體現的具體測試內容包括：

· 功能測試：測試是否滿足開發要求，是否能夠提供設計所描述的功能，是否用戶的需求都得到滿足。功能測試是系統測試最常用和必須的測試，通常還會以正式的軟件說明書爲測試標準。

· 強度測試：測試系統的能力最高實際限度，即軟件在一些超負荷的情況，功能實現情況。如要求軟件某一行爲的大量重複、輸入大量的數據或大數值數據、對數據庫大量複雜的查詢等。

· 性能測試：測試軟件的運行性能。這種測試常常與強度測試結合進行，需要事先對被測軟件提出性能指標，如傳輸連接的最長時限、傳輸的錯誤率、計算的精度、記錄的精度、響應的時限和恢復時限等。

· 安全測試：驗證安裝在系統內的保護機構確實能夠對系統進行保護，使之不受各種非常的干擾。安全測試時需要設計一些測試用例試圖突破系統的安全保密措施，檢驗系統是否有安全保密的漏洞。

· 恢復測試：採用人工的干擾使軟件出錯，中斷使用，檢測系統的恢復能力，特別是通訊系統。恢復測試時，應該參考性能測試的相關測試指標。

· 可用性測試：測試用戶是否能夠滿意使用。具體體現爲操作是否方便，用戶界面是否友好等。

· 安裝/卸載測試（install/uninstall test）等等。

系統測試需要對被測的軟件結合需求分析做仔細的測試分析，建立測試用例。

第37帖【2004－6－22】：TMM介紹

測試是軟件開發的重要過程之一，但是CMM沒有充分的定義測試，沒有提及測試成熟度的概念，沒有對測試過程改進進行充分說明，在KPA中沒有定義測試問題，與質量相關的測試問題如可測性，充分測試標準，測試計劃等方面也沒有滿意的闡述。　

TMM是受CMM模型啓發產生的，關注於測試的成熟度模型。它描述了測試過程，是項目測試部分得到良好計劃和控制的基礎。TMM測試成熟度分解爲5級別，關注於5個成熟度級別遞增：　

Phase 0 ：測試和調試沒有區別，除了支持調試外，測試沒有其他目的

Phase 1 ： 測試的目的是爲了表明軟件能夠工作

Phase 2 ：測試的目的是爲了表明軟件不能夠能夠正常工作

Phase 3 ： 測試的目的不是要證明什麼，而是爲了把軟件不能正常工作的預知風險降低到能夠接受的程度

Phase 4 ： 測試不是行爲，而是一種自覺的約束(mental discipline)，不用太多的測試投入產生低風險的軟件上的

第38帖【2004－6－23】：軟件測試自動化的概念

軟件測試自動化，是一項讓計算機代替測試人員進行軟件測試的技術。他可以讓測試人員從繁瑣和重複的測試活動中解脫出來，專心從事有意義的測試設計等活動。如果採用自動比較技術，還可以自動完成測試用例執行結果的判斷，從而避免人工比對存在的疏漏問題。設計良好的自動化測試，在某些情況下可以實現“夜間測試”和“無人測試”。在大多數情況下，軟件測試自動化可以減少開支，增加有限時間內可執行的測試，在執行相同數量測試時節約測試時間。　

軟件測試自動化通常藉助測試工具進行。測試工具可以進行部分的測試設計、實現、執行和比較的工作。通過運用測試工具，可以達到提高測試效率的目的。所以測試工具的選擇和推廣使用應該給予重視。部分的測試工具可以實現測試用例的自動生成，但通常的工作方式爲人工設計測試用例，使用工具進行用例的執行和比較。　

軟件測試自動化的設計並不能由工具來完成，必須由測試人員進行手工設計，但是在設計時卻必須考慮自動化的特殊要求，否則無法實現利用工具進行用例的自動執行。爲此，就必須在測試的設計和內容的組織方面採取一些特殊的方法。　

對於軟件測試自動化的工作，大多數人都認爲是一件非常容易的事。其實，軟件測試自動化的工作量非常大，而且也並不是在任何情況下都適用，同時軟件測試自動化的設計並不比程序設計簡單。

第39帖【2004－6－24】：自動化測試的優點

通過自動化測試，可以使某些任務提高執行效率。除此之外，還有其它優點：　

① 對程序的迴歸測試更方便。這可能是自動化測試最主要的任務，特別是在程序修改比較頻繁時，效果是非常明顯的。由於迴歸測試的動作和用例是完全設計好的，測試期望的結果也是完全可以預料的，將回歸測試自動運行，可以極大提高測試效率，縮短迴歸測試時間。　

② 可以運行更多更繁瑣的測試。自動化的一個明顯的好處是可以在較少的時間內運行更多的測試。　

③ 可以執行一些手工測試困難或不可能進行的測試。比如，對於大量用戶的測試，不可能同時讓足夠多的測試人員同時進行測試，但是卻可以通過自動化測試模擬同時有許多用戶，從而達到測試的目的。　

④ 更好地利用資源。將繁瑣的任務自動化，可以提高準確性和測試人員的積極性，將測試技術人員解脫出來投入更多精力設計更好的測試用例。有些測試不適合於自動測試，僅適合於手工測試，將可自動測試的測試自動化後，可以讓測試人員專注於手工測試部分，提高手工測試的效率。　

⑤ 測試具有一致性和可重複性。由於測試是自動執行的，每次測試的結果和執行的內容的一致性是可以得到保障的，從而達到測試的可重複的效果。　

⑥ 測試的複用性。由於自動測試通常採用腳本技術，這樣就有可能只需要做少量的甚至不做修改，實現在不同的測試過程中使用相同的用例。

⑦ 可以讓產品更快面向市場。自動化測試可以縮短測試時間，加快產品開發週期。　

⑧ 增加軟件信任度。由於測試是自動執行的，所以不存在執行過程中的疏忽和錯誤，完全取決於測試的設計質量。一旦軟件通過了強有力的自動測試後，軟件的信任度自然會增加。　

總之，通過較少的開銷獲得更徹底的測試，提高軟件質量，這是測試自動化的最終目的。

第40帖［2004-6-25］：自動化測試中常見的問題

在軟件測試自動化的實施過程中會遇到許多問題，以下是一些比較普遍的問題：　

① 不現實的期望。一般來說，業界對於任何新技術的解決方案都深信不疑，認爲可以解決面臨的所有問題，對於測試工具也不例外。但事實上，如果期望不現實，無論測試工具如何，都滿足不了期望。　

② 缺乏測試實踐經驗。如果缺乏測試的實踐經驗，測試組織差，文檔較少或不一致，測試發現缺陷的能力較差，那麼首先要做的是改進測試的有效性，而不是改進測試效率。只有手工測試積累到一定程度，才能做好自動化測試。　

③ 期望自動測試發現大量的新缺陷。測試第一次運行時最有可能發現缺陷。如果測試已經運行，再次運行相同的測試發現新缺陷的概率就小得多。對迴歸測試而言，再次運行相同的測試只是確保修改是正確的，並不能發現新的問題。　

④ 安全性錯覺。如果自動測試過程沒有發現任何缺陷，並不意味着軟件沒有缺陷。可能由於測試設計的原因導致測試本身就有缺陷。　

⑤ 自動測試的維護性。當軟件修改後，通常也需要修改部分測試，這樣必然導致對自動化測試的修改。在進行自動化測試的設計和實現時，需要注意這個問題，防止自動化測試帶來的好處被高維護成本所淹沒。　

⑥ 技術問題。商業的測試工具也是軟件產品，並不能解決所有問題，通常在某些地方還會有欠缺。測試工具都有適用範圍，要很好的利用它，對使用者進行培訓是必不可少的。　

⑦ 組織問題。自動測試實施並不簡單，必須有管理支持及組織藝術。