前言：軟件迅猛發(fā)展凸現(xiàn)軟件測試問題

　　隨著軟件業(yè)蓬勃發(fā)展，各種軟件需求紛繁而來，在潮起潮落的IT洪流中，軟件項目越來越凸現(xiàn)大型化、復雜化的發(fā)展趨勢。幾十人上百人的開發(fā)團隊、成千上萬的模塊與接口、跨地域、跨系統(tǒng)的使用用戶等情況早已屢見不鮮，所有這些，對項目質量管理提出了更高要求，如何滿足各方需求，做出更好的軟件系統(tǒng)？測試管理逐漸成了大家目光的焦點。

　　軟件的質量靠什么，靠管理、靠各個軟件過程的嚴密配合。但勿庸置疑，質量的守護是靠測試。它就象一只看門狗，認真守護著軟件質量這個“家”。

　　軟件測試的重要性

　　測試是什么？測試就是對項目開發(fā)過程的產品（編碼、文檔等）進行差錯審查，保證其質量的一種過程。

　　軟件業(yè)的迅猛發(fā)展也就是近幾十年的過程，時間雖短，但許多誤解似乎已根深蒂固，對測試的偏見也是如此。“軟件的重點在于需求、在于分析、在于設計、在于開發(fā)，而測試，容易，沒什么技術含量，找一些用戶，對照需求盡力去測就行了；有時間多測點，沒時間就少測點。”這種看法在許多項目經理、軟件負責人的心中固守著，難以改變。

　　這種觀念的結果有目共睹，是什么？很簡單，是大量軟件BUG、缺陷的“流失”，從測試人員手中悄然而過，流失到用戶手中，流失進項目維護階段。隨之而來的，便是用戶無休止的抱怨、維護人員無休止的“救火”、維護成本無休止的增加。這是軟件人員的夢魘！

　　惡夢總有醒來時，經過無數(shù)教訓的重擊，在不堪回首而不得回首的經歷中，軟件業(yè)的管理者發(fā)現(xiàn)：是他們錯了，軟件測試是不可忽視的。

　　“所有這些問題，假如在項目中測試到的話，便不會有造成不可收拾的結果了。”――人們終于意識到測試簡單而純真的真諦。

　　軟件測試

　　軟件測試從直觀上來講是對測試對象進行檢查、驗證，似乎很簡單，但實際不然，它是由許多處理環(huán)節(jié)構成的。根據(jù)測試目標、質量控制的要求，它被劃分為以下各類環(huán)節(jié)（如下圖），并被設置了不同的準入、準出標準。

　　測試的主要過程及活動如上圖所示，內容一目了然，在此就不一一詳述了，只希望通過對測試重點問題、關注熱點的介紹，幫助大家對測試管理有一個總體的把握。

　　測試方式中普遍存在的問題與點評

　　談到測試，我們無法回避的是當前軟件過程普遍存在的測試問題：

　　1、 手工過多，缺少測試工具，自動化測試方式缺失

　　傳統(tǒng)的項目測試還是以手工為主，測試人員根據(jù)需求規(guī)格說明書的要求，與測試對象進行“人機對話”。隨著軟件業(yè)的不斷發(fā)展及軟件規(guī)模的擴大，這種測試的弊端日益明顯：
　　· 大量的手工使項目人力成本、溝通成本居高不下；
　　· 人工操作的低效率使項目耗時增加，帶來進度風險；
　　· 人員素質及其他不確定因素會影響手工測試的結果，導致差錯率的增加。
　　· 在測試過程中，需要對測試案例庫進行統(tǒng)一配置管理，項目規(guī)模的激增使手工管理案例庫的難度日益加大，尤其是在需求變更、回歸測試頻繁發(fā)生的時候。

　　從古到今，當生產率阻礙了生產力的發(fā)展的時候，必然會引入更高級的生產工具及方式。項目測試也是這個道理，引入工具，引入自動化測試及管理，是項目測試的一大趨勢。

　　2、 缺乏文檔測試、檢查

　　文檔是項目的重要產品之一，產品需求、功能分析、架構設計、詳細設計、用戶手冊、維護手冊等等，對于項目的測試、上線、維護等過程起到至關重要的參考、指導作用，所以它們的質量應該是項目重點關注點之一。令人遺憾的是，許多軟件項目對于文檔的重視只停留在口頭上，“編碼第一”的觀念似乎根深蒂固。

　　隨著需求不斷變更、補充，業(yè)務、技術人員忙于應付，無法騰出精力來進行文檔內容的修改及完善，往往是將包含需求變更內容的工作聯(lián)系單往需求文檔后一附了事，而不去更新需求與其他相關文檔；另一方面，項目變更管理還不夠完善，管理重點往往集中于開發(fā)，而輕視文檔質量管理，未留出充分的文檔更新時間，導致文檔更新嚴重滯后于編碼進度。為保證文檔質量，必須定期進行文檔測試，但測試要花成本，項目高層不愿意付此代價。

　　文檔若可讀性低，便會影響用戶的理解；若與編碼不一致，便起不到參考作用，編碼測試就沒有可靠的測試依據(jù)。路都看不清楚，怎么往前走呀？所以，強烈建議進行文檔測試，并將其置于測試管理的首位。

　　當前文檔測試的方法沒有什么特別的形式，還缺乏測試工具支持，通常是通過靜態(tài)審查方式――“走查”來進行的，主要查看文檔的可讀性，內容真實性、可靠性、全面性。另外，在項目里程碑時期召集相關領域專家對重要文檔進行集中審核，也是一種檢查方式。

　　3、 單元測試應引入交叉測試方法

　　單元測試是對軟件基本組成單元進行的測試，測試對象是軟件模塊。通常，單元測試是由開發(fā)人員來完成，而且往往是各人測各人的。這存在問題隱患。

　　為什么呢，技術人員是軟件模塊的制造者，自己來測自己的軟件的話，角色便從制造者變成了審查者，而前一個角色的目的是為了保證軟件正確，后一個角色的目的是為了發(fā)現(xiàn)更多的缺陷，讓一個人同時來扮演兩種目的不同的角色，好比讓他既當裁判員又當運動員，怎么能做好呢？
    解決方法通常有兩種，一種是：由測試人員來進行單元測試，這種方式要求測試人員要有較高的軟件技術知識；另一種是：將軟件人員分組，在模塊開發(fā)告一段落時進行交叉測試，這種方法只需要測試者了解被測方的軟件需求，不需要另外的知識培訓，而且測試出發(fā)點較為客觀，所以被較普遍的推廣使用。

　　4、 測試在開發(fā)基本完成才啟動

　　在傳統(tǒng)的瀑布型開發(fā)模式中，軟件測試位于編碼階段之后，是作為一個獨立階段存在的，許多人便一刀切地認為應該將所有的測試工作在編碼完成后再開始。這個觀點要不得，原因有二：

　　首先，若將測試工作細分，有許多工作是可以提前先期執(zhí)行的，如：需求書與設計書的學習、測試計劃的制定、測試人員的培訓、測試腳本的建立、測試資源的搭建、測試模板的創(chuàng)建、測試工具的選擇等等，都是可以與其他階段并行處理的，這將大大縮短項目開發(fā)時間，為測試提供充分的時間保障，提高測試質量。

　　其次，軟件缺陷發(fā)現(xiàn)的越晚，修改、補救所耗費的成本越高。引用Boehm在《Software Engineering Economics》一書中的話――“平均而言，如果在需求階段修證一個錯誤的代價是1，那么，在設計階段就是它的3－6倍，在編程階段是它的10倍，在內部測試階段是它的20—40倍，在外部測試階段是它的30－70倍，而到了產品發(fā)布出去時，這個數(shù)字就是40－1000倍。”由此可見，測試目標的最佳定位應該是：在錯誤第一次出現(xiàn)的時候就捕捉到它。所以，在盡可能的情況下，測試越早展開越好。

　　在項目的各個進行階段，都有不同的項目產品產生，他們質量的好壞，對后續(xù)開發(fā)影響重大，所以，現(xiàn)在國際上比較流行的做法是：將測試融合到各個開發(fā)環(huán)節(jié)中去，盡早測試。

　　5、 測試案例、測試方案的重用率低下