隨著軟件業蓬勃發展，各種軟件需求紛繁而來，在潮起潮落的IT洪流中，軟件項目越來越凸現大型化、復雜化的發展趨勢。幾十人上百人的開發團隊、成千上萬的模塊與接口、跨地域、跨系統的使用用戶等情況早已屢見不鮮，所有這些，對項目質量管理提出了更高要求，如何滿足各方需求，做出更好的軟件系統？測試管理逐漸成了大家目光的焦點。
軟件的質量靠什么，靠管理、靠各個軟件過程的嚴密配合。但勿庸置疑，質量的守護是靠測試。它就象一只看門狗，認真守護著軟件質量這個“家”。
軟件測試的重要性
測試是什么？測試就是對項目開發過程的產品（編碼、文檔等）進行差錯審查，保證其質量的一種過程。
軟件業的迅猛發展也就是近幾十年的過程，時間雖短，但許多誤解似乎已根深蒂固，對測試的偏見也是如此�！败浖闹攸c在于需求、在于分析、在于設計、在于開發，而測試，容易，沒什么技術含量，找一些用戶，對照需求盡力去測就行了；有時間多測點，沒時間就少測點�！边@種看法在許多項目經理、軟件負責人的心中固守著，難以改變。
這種觀念的結果有目共睹，是什么？很簡單，是大量軟件BUG、缺陷的“流失”，從測試人員手中悄然而過，流失到用戶手中，流失進項目維護階段。隨之而來的，便是用戶無休止的抱怨、維護人員無休止的“救火”、維護成本無休止的增加。這是軟件人員的夢魘！
惡夢總有醒來時，經過無數教訓的重擊，在不堪回首而不得回首的經歷中，軟件業的管理者發現：是他們錯了，軟件測試是不可忽視的。
“所有這些問題，假如在項目中測試到的話，便不會有造成不可收拾的結果了�！报D―人們終于意識到測試簡單而純真的真諦。
軟件測試
軟件測試從直觀上來講是對測試對象進行檢查、驗證，似乎很簡單，但實際不然，它是由許多處理環節構成的。根據測試目標、質量控制的要求，它被劃分為以下各類環節（如下圖），并被設置了不同的準入、準出標準。
測試的主要過程及活動如上圖所示，內容一目了然，在此就不一一詳述了，只希望通過對測試重點問題、關注熱點的介紹，幫助大家對測試管理有一個總體的把握。
測試方式中普遍存在的問題與點評
談到測試，我們無法回避的是當前軟件過程普遍存在的測試問題：
1、 手工過多，缺少測試工具，自動化測試方式缺失。
傳統的項目測試還是以手工為主，測試人員根據需求規格說明書的要求，與測試對象進行“人機對話”。隨著軟件業的不斷發展及軟件規模的擴大，這種測試的弊端日益明顯：
· 大量的手工使項目人力成本、溝通成本居高不下；
· 人工操作的低效率使項目耗時增加，帶來進度風險；
· 人員素質及其他不確定因素會影響手工測試的結果，導致差錯率的增加。
· 在測試過程中，需要對測試案例庫進行統一配置管理，項目規模的激增使手工管理案例庫的難度日益加大，尤其是在需求變更、回歸測試頻繁發生的時候。
從古到今，當生產率阻礙了生產力的發展的時候，必然會引入更高級的生產工具及方式。項目測試也是這個道理，引入工具，引入自動化測試及管理，是項目測試的一大趨勢。
2、 缺乏文檔測試、檢查。
文檔是項目的重要產品之一，產品需求、功能分析、架構設計、詳細設計、用戶手冊、維護手冊等等，對于項目的測試、上線、維護等過程起到至關重要的參考、指導作用，所以它們的質量應該是項目重點關注點之一。令人遺憾的是，許多軟件項目對于文檔的重視只停留在口頭上，“編碼第一”的觀念似乎根深蒂固。
隨著需求不斷變更、補充，業務、技術人員忙于應付，無法騰出精力來進行文檔內容的修改及完善，往往是將包含需求變更內容的工作聯系單往需求文檔后一附了事，而不去更新需求與其他相關文檔；另一方面，項目變更管理還不夠完善，管理重點往往集中于開發，而輕視文檔質量管理，未留出充分的文檔更新時間，導致文檔更新嚴重滯后于編碼進度。為保證文檔質量，必須定期進行文檔測試，但測試要花成本，項目高層不愿意付此代價。
文檔若可讀性低，便會影響用戶的理解；若與編碼不一致，便起不到參考作用，編碼測試就沒有可靠的測試依據。路都看不清楚，怎么往前走呀？所以，強烈建議進行文檔測試，并將其置于測試管理的首位。
當前文檔測試的方法沒有什么特別的形式，還缺乏測試工具支持，通常是通過靜態審查方式――“走查”來進行的，主要查看文檔的可讀性，內容真實性、可靠性、全面性。另外，在項目里程碑時期召集相關領域專家對重要文檔進行集中審核，也是一種檢查方式。
3、 單元測試應引入交叉測試方法；
單元測試是對軟件基本組成單元進行的測試，測試對象是軟件模塊。通常，單元測試是由開發人員來完成，而且往往是各人測各人的。這存在問題隱患。
為什么呢，技術人員是軟件模塊的制造者，自己來測自己的軟件的話，角色便從制造者變成了審查者，而前一個角色的目的是為了保證軟件正確，后一個角色的目的是為了發現更多的缺陷，讓一個人同時來扮演兩種目的不同的角色，好比讓他既當裁判員又當運動員，怎么能做好呢？
解決方法通常有兩種，一種是：由測試人員來進行單元測試，這種方式要求測試人員要有較高的軟件技術知識；另一種是：將軟件人員分組，在模塊開發告一段落時進行交叉測試，這種方法只需要測試者了解被測方的軟件需求，不需要另外的知識培訓，而且測試出發點較為客觀，所以被較普遍的推廣使用。
4、 測試在開發基本完成才啟動；
在傳統的瀑布型開發模式中，軟件測試位于編碼階段之后，是作為一個獨立階段存在的，許多人便一刀切地認為應該將所有的測試工作在編碼完成后再開始。這個觀點要不得，原因有二：
首先，若將測試工作細分，有許多工作是可以提前先期執行的，如：需求書與設計書的學習、測試計劃的制定、測試人員的培訓、測試腳本的建立、測試資源的搭建、測試模板的創建、測試工具的選擇等等，都是可以與其他階段并行處理的，這將大大縮短項目開發時間，為測試提供充分的時間保障，提高測試質量。
其次，軟件缺陷發現的越晚，修改、補救所耗費的成本越高。引用Boehm在《Software Engineering Economics》一書中的話――“平均而言，如果在需求階段修證一個錯誤的代價是1，那么，在設計階段就是它的3－6倍，在編程階段是它的10倍，在內部測試階段是它的20—40倍，在外部測試階段是它的30－70倍，而到了產品發布出去時，這個數字就是40－1000倍�！庇纱丝梢�，測試目標的最佳定位應該是：在錯誤第一次出現的時候就捕捉到它。所以，在盡可能的情況下，測試越早展開越好。
在項目的各個進行階段，都有不同的項目產品產生，他們質量的好壞，對后續開發影響重大，所以，現在國際上比較流行的做法是：將測試融合到各個開發環節中去，盡早測試。
5、 測試案例、測試方案的重用率低下。
傳統的測試過程，測試管理不嚴密，測試人員未建立完整的測試庫，未將測試案例、測試程序、測試方案進行有效保存，等到回歸測試時，相關測試程序等往往已不知所終，無處可尋了；即使能找到這些程序、案例，可往往因為回歸測試過于頻繁、項目期限日益迫近，已經沒有時間余量來修改、完善這些程序及案例，只能憑借經驗、記憶及技術人員的口述對程序修改過的地方草草重測一遍而已，缺乏正規化的測試過程，造成測試的虎頭蛇尾。
正常的測試案例使用方式如上圖，測試設計階段，相關測試設計人員會對測試對象進行了解、分析，為保證測試順利進行，保證測試覆蓋盡量多的測試對象，會設計測試案例、測試方案，在測試期間進行使用；測試發現錯誤時，軟件技術人員會根據測試的缺陷反饋結果及技術人員的軟件修改信息對測試程序進行修改，完畢后再進行回歸測試。
6、 測試人員素質低，缺乏相關知識培訓。
項目管理人員對測試存有偏見，對于測試的重要性認識不足，導致其嚴重忽略測試
人員的選拔和知識培訓。許多軟件項目讓軟件用戶或新招收的技術人員來完成測試工作，他們認為測試人員的工作很簡單，就是技術人員讓測什么就測什么，它基本是一個動手不動腦的工作。
這樣做的后果進一步導致了測試工作的無序和混亂，測試過程缺乏計劃性，測試人員缺乏技術能力，缺乏對架構的了解，相關素質的缺失使他們成為技術人員的附庸。測試對于他們來說，是一種枯燥的“手＋眼”式的工作，他們唯一渴望的，是將無聊的測試盡快完成，從而遠遠的逃離。這樣的測試結果可想而知。
其實，軟件工程對測試人員的素質要求是很嚴格的，比如：要有相關計算機知識背景、具備軟件工程基本知識、熟悉項目編程語言、熟悉項目技術架構及需求內容、工作有責任感、獨立分析能力及團隊精神等等。真正規范的軟件項目對于測試人員的要求是不會低于技術人員的，而且會為測試人員提供進一步的知識培訓機會，以應對各種項目的復雜情況。
7、 測試進度的錯誤估算。
在項目開發中，領導為督促測試的進程，往往會讓項目組匯報工作進度，了解已經
完成的工作占比，從而對工作進度做出判斷。我對這種工作方式完全擁護，只是覺得這種方式還有不足。
測試進程不是簡單的1＋1過程，不能武斷地認為“我用8天干完了80％的工作，那么，剩余工作便能在2天內干完”。著名的Pareto80/20規律告訴我們：測試發現的所有錯誤中的80％很可能集中在20％的程序模塊中，另外20％很可能集中在80％的程序模塊中。
所以，沒有對測試對象認真分析的基礎，單憑工作完成數量而對工作進度做出的的判斷往往是錯誤的。
我認為，“工作實際進度＝工作完成量占比＋測試對象的錯誤占比分析”才是一個較合理的測試進度估算方式。
測試新思路：
項目的開發風險來自于對需求的誤解，來自于設計與開發過程及產品的缺陷，只有盡早發現這些缺陷，才能降低并控制項目風險�；谶@種思想，軟件業出現了一些新的測試思路，主要有二：
1、測試驅動開發（Test-Driven Development，簡稱TDD）。這種測試思想被最近流行的XP（Extreme Programming）極限編程方式所大力提倡。它的基本思想是，通過測試來為編程做指導，在某個要開發的需求對象明確之后，在編碼之前，先進行相關測試代碼（測試代碼的內容和需求規格說明書描述是相同的，有人把它稱為“可執行的需求規格說明書”）的編寫工作，完成之后針對測試代碼進行編程，然后再用測試程序對開發代碼進行測試，驗證其正確性，若程序通過了測試，就說明它是符合需求規格說明書要求的。周而復始，通過這樣的過程，開發進程得以層層深入，直到開發完成。而這時單元測試也基本完成了。
這種測試方式的最大的好處是，盡早地發現設計、開發中存在的問題，避免傳統開發模式中的“測試過程中發現代碼不能滿足需求而導致的大量返工”。降低項目風險；同時可以盡早地將“半成品”展示給客戶，使客戶對需求進行驗證、補充及完善，另外測試代碼的表達方式相對準確、無二義性，可以降低因需求理解錯誤而導致的項目風險。
2、迭代測試。這種測試是IBM所推崇測試方式之一，它從迭代式開發模式演變而來。在迭代開發模式中，每個迭代都包含需求、設計、編碼、集成、測試等過程。在每一次迭代完成之后，便會開始新的迭代過程。通過一次次迭代的累進，系統會增量式集成一些新的功能，直至整個系統功能的完成。其中，每個迭代周期的測試工作由兩方面內容構成：
· 對當前迭代周期產品的增量測試。
· 對前迭代周期已完成功能的回歸測試。
隨著迭代周期的累進，測試工作內容隨之不斷變化。早期迭代測試重點在于新功能的測試，后期迭代測試重點在于累積功能的回歸測試。
有的人不喜歡XP編程的開發方式，認為其沒有明確的階段性劃分，不利于計劃管理，模式過于靈活，不好掌握。迭代式開發模式為這些人提供了新的選擇。這種開發方式繼承了瀑布式開發模式的優點――全面、嚴謹、有計劃性、易管理，更重要的是，這種模式將測試工作分布到每個迭代周期中，使測試工作提前進行，從而使將發現軟件缺陷的周期提前，大大降低軟件風險及開發成本。
測試過程的衡量
測試過程在不斷地改進，但效果如何，如何來衡量測試的效果呢？我們需要引入一把尺子，一個度量標準，這樣才能把握測試過程的改進方向。那么，怎樣來收集數據，如何來度量？這是我們長久以來一直困惑的地方。
我們不妨借助“他山之石”來想想辦法，CMMI是當今國際流行的軟件過程衡量模型，它在這方面是有自己的獨到之處的：
1、 面向全局。CMMI的測試度量面向的不僅僅是測試過程的改進，測試效果的加
強，它面向的是整個開發過程，并始終將質量監督放在工作首位。比如，它度量工作產品規模（例如代碼行數），度量工作量和成本（例如人工小時數）。我們從中搜集的數據對整個開發過程的改進都有指導作用。更高的起點可使我們避免項目管理改進過程中常見的“頭痛醫頭、腳痛醫腳”毛病。
2、 建立度量數據庫，從而對搜集的數據、分析的方式及結果進行完整、規范的
保存。這個數據庫面向的是軟件開發過程的持續改進，它的數據是可復用的，可供多個項目參考使用，不隨當前項目的結束而消失，而是會作為歷史信息持續保存，從而為測試及其他軟件過程的改進提供更客觀、更全面的度量數據。
3、 關注度量、分析過程的改進。度量過程是為了對測試及其他軟件
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
