「測試」規範在許多方面可以做為其他規範的服務提供者。測試的重點在於鑑定或評估透過這些核心慣例實現的產品品質:
-
尋找和記錄軟體品質的缺失。
-
對認知性軟體品質提出建議。
-
透過具體示範,驗證和證明在設計與需求規格中提出的假設。
-
驗證軟體產品的運作符合預期。
-
驗證已適當地實作需求。
「測試」和 RUP 的其他規範之間存在一項很有趣的差異 - 基本上,「測試」就是設法找出和揭發軟體產品的弱點。 有趣的是為了得到最好的效果,您必須採取一種不同於「需求」、「分析與設計」及「實作」規範的基本觀念。
有一項微妙的差別是這三個規範強調完整性,而「測試」強調不完整性。
良好的測試工作由類似下列的問題來主導:
-
什麼原因會造成此軟體崩潰?
-
在什麼可能的情況下,此軟體無法以預期的方式運作?
測試會質疑其他規範的工作中固有的假設、風險及不確定性,並透過具體的示範和公平的評估來解決這些爭議。 您一定希望避免兩種可能的極端情形:
-
方法無法適當地或有效地質疑軟體並揭發內在的問題或弱點
-
方法過於負面或具有破壞性 - 如果採取這種負面方法,您會發現無法以驗收品質來考量軟體產品,以致於「測試」工作疏離其他規範
各種調查和評論指出,軟體測試約佔軟體開發總成本的 30% 到 50%。 因此,令人驚訝,大多數的人認為電腦軟體在交付之前並未經過妥善測試。 這種矛盾起因於幾項重要的問題:
-
軟體測試非常困難。您如何量化特定程式的各種不同的表現?
-
測試通常沒有明確的方法,導致在不同專案和不同組織中會得到不同的結果。 人的素質和技術是成功的主要因素。
-
生產力工具使用不足,導致投入測試的人力失控。除了缺乏自動化測試以外,許多測試工作未善用工具來有效管理大量的「測試資料」和「測試結果」。 軟體的使用彈性和複雜性,導致不可能達成完整測試。
利用精密和先進的工具可以提高軟體測試的生產力和效率。
安全第一的系統必須有高品質的軟體 - 例如飛航管制、飛彈導引或醫療轉診系統 - 一旦故障,可能危害生命。 一般 MIS 系統可能無法立即看出重要性,但一項缺失很可能導致採用此軟體的商業損失大量利潤,甚至付出大筆的訴訟用費。
在此資訊爆炸的年代,隨著愈來愈需要在網際網路上提供電子交付服務, 許多 MIS 系統現在都視為關鍵任務; 亦即,在發生問題時,如果公司無法正常運作,就要遭受巨大損失。
在軟體生命週期早期開始持續地追蹤品質,可以大量節省完成和維護軟體的成本。 如此可以明顯降低部署不良軟體的風險。
「測試」規範與下列其他規範有關:
-
需求規範捕捉軟體產品的需求,是找出執行什麼測試的重要決策因素之一。
-
分析與設計規範決定軟體產品的適當設計,是找出執行什麼測試的另一項重要因素。
-
實作規範產生軟體產品的建構版本,再由「測試」規範來驗證。 一個反覆內會測試多個建構版本 — 通常每一個測試週期只測試一個建構版本。
-
部署規範將完成的軟體產品交付給一般使用者。 在此之前,由「測試」規範來驗證軟體,但外部測試和驗收測試通常在「部署」時才進行。
-
環境規範開發和維護「測試」期間使用的支援成果,例如「測試準則」和「測試環境」。
-
專案管理規範會規劃專案和每一次反覆時的必要工作。 此成果是您定義測試工作的正確評估任務時的重要輸入,記錄在「反覆計劃」中。
-
配置與變更管理規範控制專案小組內的變更。 測試工作會驗證每一項變更已適當地完成。
建議閱讀 Kaner、Bach 及 Pettichord 合著的 Lessons Learned in Software Testing [KAN01],本書精闢列舉測試團隊的重要考量。
|