來自：ibm
在本文中，我們要討論為什麼進行測試，尤其是自動化測試，是必需的。然後，我們將介紹制定計畫的概念：為什麼制定計畫是如此的重要？在隨後的文章中，我們將分解測試計畫中的不同因素，並且研究如何進行制定計畫的過程才能最大程度地增加成功的機會。
現代客戶端/伺服器應用程式是非常複雜的，因此測試也就成為開發過程中關鍵的並且至關重要的一部分。現在，沒有人會考慮（或者承認）不對自己開發的軟體進行測試工作。但是，研究和調查表明，在軟體開發過程中，制定測試計畫卻常常是優先順序較低的工作專案。而且，更加糟糕的是，計畫往往沒有被執行，或者即使執行了，也進行的不很完整、不很準確，或者沒有持續進行。
假設我們都贊成測試是必要的，那麼我們接下來必須回答這些問題：我們如何進行測試？實際上都包括哪些內容？我們如何保證已經進行了有效的工作，並且真正地改善了應用程式的質量？
答案很簡單：制定計畫。
本文將評審在軟體生命週期中制定測試計畫的作用，以及有效制定測試計畫的有關概念。在本文中，我們要討論為什麼進行測試，尤其是自動化測試，是必需的。然後，我們將介紹制定計畫的概念：為什麼制定計畫是如此的重要？在隨後的文章中，我們將分解測試計畫中的不同因素，並且研究如何進行制定計畫的過程才能最大程度地增加成功的機會。
現在看來，沒有怎麼制定測試計畫而造成的後果比以前更加明顯了。失敗的案例有很多--看看報紙或者雜誌就知道了。還有一些明顯的低質量軟體的案例，它們包括：
at&t－乙個軟體交換系統，系統崩潰造成了美國幾乎24小時的長距離通訊中斷。僅僅修改了一行源**就解決了問題。
denvor機場--軟體的缺陷延誤了機場的開放幾乎長達9個月之久，據估算，每天花費納稅人大概$500,000。
ashton-tate--在80年代，ashton-tate的dbase軟體是基於pc的資料庫應用程式的實際標準。版本中的缺陷導致了利潤的減少，最終造成了ashton-tate（和dbase）的轉讓。ashton-tate最後被borland（擁有極具競爭力的資料庫管理應用程式，paradox）收購。
當然，這些都是知名度很高的公司和專案。這些問題不會出現在您的公司中，對嗎？
錯誤！我們都要面對軟體的缺陷，在我們的組織中與外界都是一樣，這些問題都是關鍵的，也是很明顯的。這裡有一些低質量軟體的更加共同的症狀：
l 生產力損失
系統效能；
缺少功能/特性；
沒有滿足使用者需求--無法銷售；
l 使用者挫折感
強迫使用者以不直觀的方式執行任務；
迴圈工作；
延遲；沒有滿足預期目標；
存在使用者操作錯誤與理解錯誤；
l 系統崩潰，資料丟失/破壞
客戶端/伺服器應用程式為質量保證專家帶來了不同的挑戰，下面是一些比較重要的內容：
大多數的客戶端/伺服器應用程式都使用快速程式開發（rad）方法學進行開發。測試人員必須"努力跟上"這些較短的開發周期。早些時候，非客戶端/伺服器應用程式常常使用18-24個月就完成了整個的開發過程和初始部署。現在，使用rad，應用程式的發布需要經過多次部署或者"塊"。每個塊都基於以前的版本，並且包括改善、修改和修理。每個塊都需要多次建立或者迭代的原型。每個塊都需要進行測試，並且在3-6個月的更短時間內完成。
當前的客戶端/伺服器應用程式都需要很多的軟體元件結合起來以實現功能，包括客戶端應用程式、工作站作業系統、網路和資料庫管理系統。常常也包括其他的元件，例如為實現正確執行而包含的附加源**的dll（動態連線庫）、事務處理器或者應用程式與資料庫管理服務。軟體的每個附加"層"都在客戶端/伺服器架構中增加了額外的複雜度（並且需要進行測試）。
另外，測試客戶端/伺服器應用程式也需要使用許多不同型別的測試方法，例如，功能測試、使用者介面、效能測試以及配置測試。這些測試都針對乙個或幾個測試目標。為了防止測試迂迴不前或者嘗試同時測試所有內容，每種測試必須制定仔細的計畫。當您進行自動化測試時，這一點尤其正確。
對於我們執行的每種型別的測試，都必須使用資料。資料對於測試的執行和成功完成來說是至關重要的，因為要使用資料識別最初的應用程式資料狀態（條件），並且呼叫或者引出特定的事件或者操作。而且也要使用資料來驗證測試事件或者操作是否執行正常！
如前所述，現代的應用程式與以前開發的應用程式相比具有很大的不同。客戶端/伺服器技術加強了我們開發與部署以任務關鍵型的企業系統的能力，而且花費的週期更短，提供的功能更加強大。客戶端/伺服器應用程式也為開發人員與終端使用者提供了大量的選擇和控制。但是使用這些好處的同時，也需要加強測試。
逐漸地，測試軟體必須使用測試自動化工具和技術，以滿足具有挑戰性的日程安排。但是，單單使用工具還不足夠，成功的測試自動化需要制定測試計畫。在沒有進行計畫的條件下，實施測試自動化只會帶來自動化的混亂。使用測試自動化工具，我們可以管理混亂並且識別過程中造成混亂的因素，同時管理專案費用（例如"未被文件化的特性/變更"）。
測試自動化是使軟體測試人員跟上開發人員腳步的惟一方式，軟體測試人員可以像測試早先構建版本那樣，充滿信心地、可靠地測試新構建的版本。
但是測試常常為測試人員帶來挑戰，他們必須最有效地、生產力極高地使用時間，進行工作。測試自動化引入了一種新型的資源需求--測試開發。手工測試需要進行測試設計，以識別測試的內容和方式，但是由於沒有使用工具，所以也沒有必要開發任何的測試指令碼或過程，僅僅來除錯一下系統，然後使用鍵盤就可以了！如果對於每個要進行的測試，需要使用的資源僅僅是鍵盤，那麼就可以看出，您並沒有有效地利用時間。
測試開發是一種新技術，在設計完成之後，需要使用工具並且建立測試過程。作為一種有效的方式，可以使用三名不同的技術員，並確保將最高端的資源用於設計與制定計畫任務上，而將中級資源（或外界資源）用於開發與執行。這樣可以增強職員所需的能力，並且共享資源，同時也不會對專案計畫產生什麼影響。
缺陷是肯定會被發現的。這是進行測試的結果，或者說是目的，所以我們必須對缺陷的生命週期進行識別和溝通，同時分析結果以確保缺陷已被有效地並且高效地處理。制定測試計畫能夠確保缺陷管理與分析是一筆面向整個專案的寶貴資產，而不會帶來阻礙。如果您還沒有配備缺陷管理系統和過程，或者已具有但是工作得不是很理想，那麼制定測試計畫就會給您帶來建立（或者修正）它的機會。
制定測試計畫也可以識別應該使用什麼樣的度量方法。制定測試計畫可以處理您所度量軟體質量程度的問題。它也可以處理如何度量與溝通缺陷密度或缺陷趨勢的問題。
另外，制定測試計畫可以識別與溝通資料收集與分布的方式，也應該指明使用報告的格式，以及作出報告的時間。
制定測試計畫提供了進行風險評估的機會。風險與不利因素對於組織來說是就一場噩夢，但是它們也是可以被控制的。不過首先必須對其進行分析。風險分析有助於制定測試工作的優先順序，並且關注所進行的工作，確保測試內容的正確性，以正確的順序解決正確的問題。（所謂正確，是以組織的風險與可接收度為基礎的。）
對於每個專案來說，都要進行風險評估並將其用於識別潛在的風險或者未發現缺陷帶來的影響。風險應該用來評估缺陷對於直接終端使用者、資料或者其他終端使用者和應用程式帶來的影響。這些資料可以用來建立測試優先順序，並且評估所有約束，例如面市時間、預算或者費用，或者質量問題。
風險評估還應該包括對於現有標準、指南和需求的評審。其目的就是為了分析這三種文件，判斷它們對於專案是否恰當，並且由此進行實施或者修正。
評審任何可能影響或者對專案帶來衝擊的外界因素也是很重要的。這些影響可以包括特定使用者請求、規範的需求、或者市場條件，這其中的任何一項都可以變更風險或者優先順序的評估結果。
制定測試計畫就是為測試過程制定文件。為測試制定計畫不僅僅為文件化並且溝通測試工作提供機會，也可以評審測試工作的有效性。
l您曾聽到過以下對話嗎：
"使用者報告發現缺陷在…，難道你沒有測試它嗎?"；
"這是如此的明顯，你怎麼能發布帶有這種缺陷的產品呢？"；
"我知道你已經說了需要三個月的時間進行測試，但是你只有兩個…"；
改善產品質量（具有較少的軟體缺陷）需要對產品開發過程進行持續的完善工作。開發測試計畫可以使測試人員能夠識別、執行、度量並且改善他們的測試工作。
總而言之，可以從幾個理由來說明制定良好計畫的自動化測試的必要性。首先，不進行測試的組織會大大增加出現重大系統故障的可能，帶來延遲，花費巨資進行修復，而且還可能潛在地帶來對於客戶信心無法修補的破壞。其次，現代客戶端/伺服器應用程式的本質允許快速地開發出複雜度很高的系統，該系統完全無法使用傳統的手工方法進行正確的測試。最後，制定計畫的目的就是為了管理不斷增加的測試過程，分析並且跟蹤已被發現的缺陷，執行關鍵性風險分析，並且持續改善測試與開發過程。
《軟體自動化測試成功之道》學習資源
軟體自動化測試成功之道 由於本書面向的是有一定基礎的自動化測試工程師，因此對於初學者，特地在本書附帶的光碟中提供了testcomplete qtp自動化測試工具的基礎培訓材料。初學者可在閱讀本書之前按照提供的資源先進行學習。軟體自動化測試成功之道 隨書光碟 testcomplete基礎培訓.ppt ...
自動化測試成熟度模型
自動化測試成熟度模型 這裡討論一下不同的指令碼技術及用途。接下來要討論的這些技術並不是相互排斥的，事實恰好相反，它們是相輔相成的，每種種指令碼技術在支援指令碼完成測試用例的時間和開銷上都有各自的長處和短處。應該注意到，對於軟體測試來說，使用哪種指令碼技術並不是最主要的，指令碼所支援的實現測試用例體現...
成功的自動化測試專案實施
成熟的軟體測試是確保軟體質量的一種重要手段，自動化測試技術的出現，對於提高測試單位績效比起了重要作用，被廣泛應用於回歸測試中，但是由於被測試系統的不確定性和複雜性，使得軟體自動化測試變得異常困難。本文基於商業工具結合實際專案，分析自動化測試實施期間出現的各種問題，以提高大家對自動化測試專案的真正認識...