概念: 測試的層次
本準則將測試活動分為「開發人員」、「獨立」、「單元」、「整合」、「系統」及「驗收測試」。
關係
相關元素
主要說明

測試可以在不同的階段下或投入不同的工作量,針對不同的目標類型來進行。這些層次通常以最有能力設計和管理測試的角色來區別,或以每一層次上最適用的測試技術來區別。在這些不同的工作之間,必須隨時掌握工作的重心。

開發人員測試

開發人員測試代表最適合開發團隊採用的測試設計和實作方式。剛好與「獨立測試」相反。 測試執行通常都是由負責設計和實作測試的開發人員測試小組率先執行,但最好的作法是開發人員也可以建立自己的測試,再交由獨立測試小組來執行。

習慣上會認為開發人員測試的主要工作就是執行單元測試。但有些開發人員也會不同程度的整合測試,這多半與組織文化及其他環境因素有關。我們認為開發人員測試不應該只是個別地測試獨立單元而已。

獨立測試

獨立測試代表最適合由開發人員團隊以外的不相關人士來執行的測試設計和實作。您可以將這種差別視為一種超集合,包含獨立查證與驗證。測試執行通常都是由負責設計和實作測試的獨立測試小組率先執行,但獨立的測試人員應該建立自己的測試,再交由開發人員測試小組來執行。獨立測試與開發人員測試的目標不同,Boris Beizer 提出下列解釋:

獨立測試的目的是提供不同觀點,所以有不同的測試;而且能在更複雜的 [...] 環境中執行開發人員 無瑕應付的這些測試。[BEI95]

獨立關係人測試

獨立測試的另一種觀點表示這種測試以不同關係人的需求和關切重點為基礎。因此稱為「關係人測試」。這是一項重大的差別 - 相較於習慣上考量的範圍,這種測試方式能廣納更多方的利害觀點,明確指定技術支援人員、技術訓練人員、銷售人員(除了客戶)及使用者等關係人來延伸籠統的 「客戶」意涵。

總而言之,XP客戶測試概念,與 RUP 的這種獨立測試有關。

單元測試

單元測試強調驗證軟體的最小可測元素。單元測試通常運用在實作模型的元件上,目的是確認已涵蓋控制流程和資料流程,且運作情形符合預期。單元開發出來後,就由「實作人員」執行單元測試。「實作」規範中詳細說明單元測試。

整合測試

整合測試的目的是確定實作模型的元件在合併起來執行一個使用案例時可以正常運作。 測試目標是實作模型中的一個套件或一組套件。結合的套件通常來自於不同的開發組織。整合測試可揭發套件介面規格的不完整性或錯誤。

在某些情況下,開發人員會假設將由其他小組來執行整合測試,例如獨立測試人員。這種情況會引發軟體專案的風險,終將禍延至軟體品質,因為:

  • 整合領域是最常見的軟體失敗。
  • 由獨立測試人員執行的整合測試,通常採用黑箱技術,且通常涉及大量軟體元件。

最好將整合測試視為開發人員與獨立測試人員雙方的責任,但要設法避免各團隊的測試工作過份重疊。 這種重疊現象的真正本質源自於個別專案的需求。我們建議您營造一個讓開發人員與獨立系統測試人員擁有共同品質願景的環境。如需相關資訊,請參閱概念:開發人員測試

系統測試

早期都是要等到軟體整體運作時才要執行測試。反覆的生命週期可以在一部份正確的使用案例行為實作出來時,就儘早地展開系統測試。通常以系統的端對端運作元素為測試目標。

驗收測試

使用者驗收測試是部署軟體之前進行的最後一個測試動作。驗收測試的目標是驗證軟體已就緒,且可供使用者執行軟體當初設計所欲達成的功能和作業。如需相關資訊,請參閱概念:驗收測試

驗收測試還有其他概念,總括來說就是小組或團隊之間的任務交棒。例如,建構版本驗收測試代表新的軟體建構版本從開發進入獨立測試階段之前的驗收測試。

測試層次順序與時機的評論

早期普遍認為單元測試應該在第一個測試階段的反覆初期實作:在能前進到一個階段前必須先通過所有單元測試。可是,在反覆開發流程中,這種方式只是通則,並不適合。更好的方法是找出最可能發現錯誤的單元、整合及系統測試,然後以最高風險和支援環境的組合來實作並執行這些測試。