軟件測試也要做過程改進

儘管，軟件測試過程改進現在還沒有得到足夠的重視，但並不意味着我們不需要做這項工作。相反，它對於提高軟件質量尤爲重要。

　　過程改進並不是IT行業專有的詞彙。自從有質量活動以來，人們就開始廣泛地關注過程改進。在著名的Deming循環中，過程改進甚至被賦予了舉足輕重的地位。我們知道在這個循環中（即計劃、實施、檢查、改進循環），過程改進既是一次質量活動的終點，又是下次質量活動的原點，它起着承上啓下的作用。Deming循環中過程改進的理念是如此鮮明而且深入人心，以致CMM的起草者，卡內基梅隆大學軟件工程研究所直接將它作爲成爲CMM進行持續過程改進的基本模型。

　　儘管過程改進已經不再是新的名詞，然而，提出軟件測試過程改進卻是近些年的事情。讀者不妨查閱一下IEEE、ISO、CMM或者CMMI。在這些文獻中，有關軟件測試過程改進的描述少之又少。那麼這是不是意味着軟件測試就不需要做過程改進了呢？顯然不是這樣。首先，測試作爲質量控制的重要活動，天然屬於Deming循環的應用範疇。這是因爲Deming循環最初就是針對質量控制而提出的。其次，軟件測試真正進入大衆的視野也僅僅是近20年間的事，相關的研究工作做得都還不夠。

　　鑑於資料的嚴重缺乏，本文僅從工程實踐的角度，對軟件測試過程改進做一個淺顯的介紹與探討，並歡迎讀者朋友來信交流。

　　軟件測試過程的提出

　　從軟件測試外包發展起來的印度軟件業，測試過程改進方面值得中國企業學習。

　　在軟件作爲手工藝品產出的年代，軟件過程的概念還沒有萌芽，就談不上軟件測試過程了。直到人們意識到必須用工程化的手段來規範軟件生產，軟件過程纔開始廣受關注。一些激進的理論家甚至提出“軟件工廠”的概念。顧名思義，這個詞很形象地表達了人們對軟件開發行業的一種“流程化”的願望：即開發過程遵循一定的開發步驟，各司其職，井然有序，如同流水線作業一般完成軟件產品的開發。不錯，在工程思想上，它們的生產過程的確有可以類比的地方，不同的是，流水線生產的冰箱、彩電都是有形的，而軟件是無形的。

　　我們假想一下冰箱的生產過程，在冰箱開始組裝之前，所需的所有組件都必須採購或生產出來，並且這些組件必須是嚴格按照要求的大小、規格、質量完成的，這樣才能夠組裝在一起，達到相應的功能和性能指標。如果冰箱的門比櫃體高了2釐米或者說某個螺絲的直徑小了1毫米，那麼這批冰箱是不能正常使用甚至是不能銷售的。

　　假設冰箱質量檢查的流程是這樣的：明確標準（也就是知道冰箱的櫃體的尺寸，冰箱門的尺寸）→驗證標準（驗證冰箱櫃體的尺寸，冰箱門的尺寸是否匹配）→發現不符合的產品（冰箱門比櫃體高了2釐米）→採取措施（更換冰箱櫃體或者更換冰箱門）→重新驗證（確定冰箱門與櫃體的尺寸相匹配了）。

　　軟件測試流程與上述冰箱質量檢查流程是類似的，一個較爲典型的軟件測試流程可以這樣描述：制定測試計劃→撰寫測試用例→執行測試用例→記錄並提交缺陷→修改缺陷→迴歸測試。

　　把兩個過程一一對應起來，得到如下映射關係：制定測試計劃、撰寫測試用例，也就是明確標準，類似於在生產冰箱的時候，需要根據設計圖紙、生產程序，零部件樣品逐一確定冰箱的零部件檢驗標準。執行測試用例，也就是驗證標準，類似於逐一分解冰箱的零部件，逐一檢查生產質量。記錄並提交缺陷，也就是發現不符合的產品。這裏略有不同，冰箱的零部件一旦被發現不符合標準，就可能被扔進廢品堆，軟件部件卻不會因此全部都被廢棄掉。所以詳細的記錄缺陷的操作步驟、便於開發人員進行缺陷修復是很有必要的。修改缺陷，類似於冰箱生產過程中發現問題後採取措施，可能是圖紙設計的時候尺寸標註錯誤，也可能試生產系統參數設置的錯誤，還可能是工人操作不當，總之真正的原因是一定要被找到的。迴歸測試，類似於冰箱返工後的重新驗證，一般找到不符合標準的零件原因後，冰箱除更換相關零部件還需經過二次檢測。軟件產品也是這樣，修正缺陷後仍需進行迴歸測試。

　　軟件測試過程改進

　　咋一看，軟件測試過程非常簡單，讀者或許會問，對這樣一個簡單的過程，有必要進行過程改進嗎？回答是肯定的。請看下面這樣一個工程經驗公式: 質量控制=技術+管理+過程。

　　其中，測試技術解決了測試採用的方法和技術問題，測試管理保證各項測試活動的順利開展。然而，對於一個工程而言，過程也就是生命週期，也會至關重要地影響着生產效率和軟件質量。軟件測試的過程改進，主要着眼於合理調整各項測試活動的時序關係，優化各項測試活動的資源配置以及實現各項測試活動效果的最優化。

　　以下筆者根據工程實踐經驗粗略談談如何實施軟件過程改進。需要引起注意的是，這裏列出的僅僅是過程改進中很小的一部分，也是最常見的一些內容。切勿將它們當作過程改進工作的全部。

　　1．調整測試活動的時序關係

　　不恰當的測試時序會引起誤工和測試進度失控。具體到某個工程實踐中，哪些測試活動可以並行，哪些測試活動可以歸併完成，哪些測試活動存在時間上的線序關係，一定要區分清楚並做最優化調整。

　　2．優化測試活動資源配置

　　測試活動會涉及到人力、設備、場地、軟件環境與經費等資源。如何合理地調配各項資源給相關測試活動也是非常值得斟酌的。最常見的就是人力資源的調配，測試部門如果能深入瞭解員工的專長與興趣所在，能對測試活動的開展起到事半功倍的效果。

　　3．提高測試計劃的指導性

　　提高軟件測試計劃指導性通俗地講就是提高測試計劃的執行力度。這部分內容具體涵蓋軟件測試策劃、軟件測試技術剪裁、測試進度管理、成本管理等幾個部分。其中測試策劃工作主要是指具體測試活動實施之前做好策劃工作; 軟件測試技術剪裁工作主要是指測試團隊應根據軟件項目的具體實際剪裁出所要實施的測試技術; 測試進度管理工作主要是指排出各項測試的時間進度及人員安排，如有變動時應做相應調整; 測試成本管理工作的內容是開列出測試活動中會涉及到的資源需求。完成這項工作不僅僅是起草測試大綱以及測試計劃，而是要確保這些大綱，計劃的內容能真正被執行、真正能用於指導測試工作。

　　4．確立合理的度量模型和標準

　　測試過程改進小組應根據企業與項目的實際情況制訂適合自己公司的質量度量模型和標準，做符合自己公司發展策略的投入。必須說明：這個標準和模型的確立不是一蹴而就的，而是需要過程改進小組不斷實踐、不斷總結、不斷改進的。在公司與項目不斷髮展變化的氛圍中保持動態平衡。一旦確立了質量度量模型和標準，很多測試活動就不至於陷入過度測試或測試不夠的尷尬狀態中。

　　5．提高覆蓋率

　　在兼顧成本的前提下，儘量提高覆蓋率，對於過程改進而言，是很有意義的。這裏主要談以下三個方面：

　　一是提高內容的覆蓋。不論是起草測試計劃、設計測試用例、執行測試用例還是跟蹤軟件缺陷，內容覆蓋率越高，就越能避免故障被遺漏的情況。

　　二是提高技術的覆蓋。對於一項技術指標要儘可能地做到測試技術的覆蓋，我們不必要迷信於某位專家或者專業人士，但必須相信他們提出的科學的驗證方法，採用越科學的方法來驗證某項指標，我們對產品的質量就越有信心。

　　三是提高測試過程的覆蓋。我們知道，沒有需求就不能做分析，就不能設計，就不能做開發。測試也是一樣，在測試過程中如果疏漏了一個重要環節，就不能很好地達到預先的目標。比如有些企業根本不寫測試用例就讓測試人員去做測試; 有些企業根本不做測試用例評審，就匆匆發佈出去讓測試人員執行測試用例; 有些企業測試人員不知道測試的標準，就去報Bug。這些看似不很重要的工作流程一旦被省略往往就造成工作無所適從，難於開展，成爲測試活動失敗的關鍵原因所在。

　　軟件測試過程改進的注意事項

　　1．必須注意過程改進是跟公司的發展戰略相關的

　　過程改進是跟公司的發展戰略相關的。有句話叫“過猶不及”，做事情要把握好度。不是所有的公司都像微軟公司那樣對質量控制和管理能大手筆投入，也不是所有的項目都需要像delphi第一版發佈時那樣投入3萬開發工程師去測試。公司的規模、經濟實力、產品投放市場的契機等都將影響軟件測試過程訂製的策略。不要忘了利潤是很多公司的命脈所在。

　　2．測試過程改進並不意味着必須投入大筆資金

　　測試過程改進不意味着需要大筆資金投入。有些人說我們公司不給錢買測試工具，不給任何資金請諮詢公司，所以我們的過程改進沒有任何進展。其實，很多情況下，工具只不過是一個輔助手段，並不足以影響到工作部署與過程改進的效果。請諮詢公司固然能很快獲得一些知識，但沒有它們，也並不意味着過程改進就寸步難行。當然，如果公司已經承諾能提供相關投入，那就另當別論了，在這種情況下，就更有理由做好測試過程改進了。


摘自　計算機世界報 2005年07月25日 第28期 C10