1.4 不同軟件開發模式下的軟件測試

軟件測試作為軟件工程中的重要一環，是項目成敗的一個不可忽略的內容。

但是不同的軟件企業采用不一樣的開發模式，不同的項目采用不同的開發過程，不同的產品適合采用不同的軟件工程方法。那么對于不同的軟件開發模式或開發過程，測試人員如何找準自己的位置，如何更好地配合這個過程進行工作呢？

按照軟件工程的兩大流派，可以分成“流程派”和“個體派”。“流程派”以CMMI和ISO為代表，強調按既定的流程工作。“個體派”以新興的敏捷開發為代表，強調人在過程中發揮的價值。

1.4.1 CMMI和ISO中的軟件測試

“流程派”強調形成文檔的制度、規范和模板，嚴格按照制度辦事，按照要求形成必要的記錄，檢查、監督和持續改善。因此，測試人員在實施這樣的流程改進方式的組織中工作，需要注意按照測試流程定義的模板進行工作，填寫必要的測試記錄和報告，度量測試的各個方面是否符合要求。

1.4.2 CMMI與軟件測試

CMMI全稱是Capability Maturity Model Integration，即能力成熟度模型集成（也有稱為：軟件能力成熟度集成模型），是美國國防部的一個設想，1994年由美國國防部與卡內基-梅隆大學下的軟件工程研究中心以及美國國防工業協會共同開發和研制的。其目的是幫助軟件企業對軟件工程過程進行管理和改進，增強開發與改進能力，從而能按時地、不超預算地開發出高質量的軟件。其所依據的想法是：只要集中精力持續努力去建立有效的軟件工程過程的基礎結構，不斷進行管理的實踐和過程的改進，就可以克服軟件開發中的困難。

CMMI為改進一個組織的各種過程提供了一個單一的集成化框架，新的集成模型框架消除了各個模型的不一致性，減少了模型間的重復，增加透明度和可理解性，建立了一個自動的、可擴展的框架。因而能夠從總體上改進組織的質量和效率。CMMI主要關注點就是成本效益、明確重點、過程集中和靈活性四個方面。

CMMI把軟件企業的過程管理能力劃分成5個等級，如圖1.17所示。

每一個級別的過程特征可概括如下。

（1）初始級：個別的、混亂無序的過程，軟件過程缺乏定義，項目的成功嚴重依賴于某幾個關鍵人員的努力。軟件質量由個人的開發經驗來保證。

（2）可重復級：建立了基本的項目管理過程來跟蹤費用、進度和功能特性。制定了必要的過程紀律，能重復早先類似應用項目取得的成功經驗。

（3）已定義級：已將軟件管理和工程兩方面的過程文檔化、標準化，并綜合成該組織的標準軟件過程。所有項目均使用經批準、剪裁的標準軟件過程來開發和維護軟件，軟件產品的生產在整個軟件過程是可見的。

（4）量化管理級：分析對軟件過程和產品質量的詳細度量數據，對軟件過程和產品都有定量的理解與控制。管理有一個作出結論的客觀依據，管理能夠在定量的范圍內預測性能。

（5）優化管理級：過程的量化反饋和先進的新思想、新技術促使過程持續不斷改進。關注改進的持續性，融入了技術改革、缺陷預防等理念。軟件組織可從自己的過程控制和管理中得到反饋信息，用于進一步指導過程的改進。

CMMI的二級關鍵域包括軟件質量保證，主要需要解決的問題是培訓、測試、技術評審等。這是任何一個想從混亂的初始級別上升到可重復級別的軟件組織需要關注和解決的問題。

對于軟件測試，在這個階段需要考慮的是測試是否有規范的流程，與開發人員如何協作， Bug 如何記錄和跟蹤。還需要關注測試人員的技能水平是否達到一定的要求，是否建立起培訓機制。

注意

測試的管理是否完善直接關系到測試執行的效果。因此，測試組織必須確保形成了完善的測試策略和測試計劃，測試完成的標準，以及測試報告的形式和內容。

1.4.3 ISO與軟件測試

ISO 9000質量標準體系是在20世紀70年代由歐洲首先采用的，其后來在美國和世界各地迅速發展起來。很多企業都熱衷于 ISO 認證，ISO 9000的質量環如圖1.18所示。

ISO基于PDCA的循環提出了測量、分析和改進的重要性，使用測試作為軟件測量的重要手段。它要求測試人員需要得到有關授權才能進行測試活動，應該得到充分的培訓和指導，確保測試人員有足夠的能力對軟件產品進行測試。

ISO 非常強調缺陷的控制，包括對缺陷的修改進行回歸測試和驗證，對缺陷進行分析和評審，確保缺陷在交付使用前得到控制，并確保對缺陷制定了糾正預防措施，形成預防機制，防止缺陷的再次出現。

軟件企業使用ISO進行過程管理和改進應該參考ISO 9000-3標準。ISO 9000-3標準是ISO在軟件開發、供應和維護中的使用指南，是針對軟件行業的特點而制定的。ISO 9000-3的主要內容如下。

●合同評審。

●需求規格說明。

●開發計劃。

●質量計劃。

●設計和實現。

●測試和確認。

●驗收。

●復制、交付和安裝。

●維護。

上述內容基本上覆蓋了軟件生命周期的全部階段，并且比ISO 9001更貼近軟件企業的實際需求。但是需要注意的是ISO 9000-3是指南，而不是認證的準則。

1.4.4 敏捷開發中的軟件測試

在敏捷開發中，測試是整個項目組的“車頭燈”，它告訴大家現在到哪了，正在往哪個方向走。測試員為項目組提供豐富的信息，使得項目組基于這些可靠的信息做出正確的決定，如圖1.19所示。

在敏捷項目中，測試人員不再做出發布的決定。不只是由測試員來保證質量，而是由整個項目組中的每一個人都要對質量負責。測試員不再跟開發人員糾纏錯誤，而是幫助開發人員找到目標。

對于測試員來說，如果是在一個敏捷的團隊，采用完全的 XP 方法，則應該按照敏捷測試的原則，調整自己的角色，讓自己成為一名真正的敏捷測試員。

在敏捷的團隊中，測試工作的核心內容是沒有變的，就是不斷地找Bug，只是要調整好自己的心態，一切以敏捷的原則為主。敏捷測試需要更多地考慮以下方面的內容。

●更多地采用探索性測試方法。

●更多地采用上下文驅動的測試方法論。

●更多地采用敏捷自動化測試原則。

在敏捷項目中，測試人員不能依賴文檔，而是看是否能自動地尋找和挖掘更多關于軟件的信息來指導測試。探索性測試，這種強調同時設計、測試和學習被測試系統的測試方式是可以被充分借鑒和應用的。

敏捷講求合作，在敏捷項目組中，測試人員應該更主動點，多向開發人員了解需求、討論設計、一起研究Bug出現的原因。

技巧

敏捷測試認為要持續地測試，不斷地回歸測試，快速地測試。測試人員需要多點借鑒上下文驅動測試的方法，適當采用自動化的方式加快測試的速度。