軟件測試人員對 RUP 四個階段的貢獻：另一種觀點(3)

　　評估進展

　　RUP 提到的迭代節奏到構建階段還是活躍著的，并且該頻率與測試人員有特別的關系。測試人員的主要目標是能夠客觀地描述系統的當前狀態，并且能夠將該狀態與以前的狀態進行比較。這兩個狀態之間的區別，簡單地說，就是進展。

　　測試人員的“節奏”源于以下活動。

　　測試設計和實現

　　測試人員的一項主要任務是測試腳本的設計和實現。在迭代開發中，這是由為當前迭代安排的場景所驅動的。測試腳本必須開發成能夠將應用程序推到正確的“屏幕”或其他應用程序模式。測試數據必須開發成可以在此處執行應用程序，并且驗證必須設計成可以核對應用程序的行為。

　　如果使用了自動化的測試工具，那么此時會提出某種考慮，關于該測試用例是否是好的自動化候選或者是否應該手動執行。

　　測試執行

　　執行測試來確定每個驗證點的通過或失敗狀態。執行手動測試意味著有方法地遵守測試實現提示并適當地觀察和注意結果。

　　執行自動化的測試意味著安排正確的系統初始條件，然后調用腳本回放工具。在控制初始條件時，我們希望管理測試過程中什么數據處于什么狀態。該需求也適用于手動測試，區別在于測試人員可以“照顧”交互并且經常讓測試不工作來工作于未初始化的開始條件周圍。

　　回歸和測試腳本維護

　　迭代開發的一個明確的任務是需要為每個新的迭代再次運行舊的測試。這種對現有測試集的重復執行稱為回歸測試，是一個顯露出自動化測試的好處和負擔的活動。好處：因為另一種是手動測試，很明顯的耗費時間的活動。負擔：因為自動化的腳本經常需要仔細的修改來服務于下一個構建。測試腳本維護，和腳本回放調試器，對測試人員來說將會是非常熟悉的。測試人員將會及早并且使用減少腳本退化的測試工具，了解如何減少維護工作。

　　缺陷跟蹤和分辨

　　缺陷跟蹤和分辨活動是測試人員都知道的。測試行為總是揭示缺陷或問題，并且必須勤奮地跟蹤每個事故來進行分辨。首先，分辨通常需要在實驗室中復制的錯誤，但至少是處于這個原因，即 SEI Capability Maturity Model Integration (CMMI) 要求項目團隊實現配置管理以達到有威信的“可重復級別, 級別 2”。只有通過將所有開發文件置于該控制下，并且用材料清單描述每個構建，開發人員才可能有許多機會重復所有已知的事件并因此能夠滿足該標準。

　　為了提高項目角色之間缺陷信息的共享，用開發人員使用的同樣的配置管理和缺陷跟蹤環境來裝備測試人員是合理的。

　　針對進展的量度

　　我們已經回顧了測試人員在構建階段所做的事情。我們如何將其轉化為進展的量度呢?有多種描述恰當的技術， 3 以下的處理是可以借鑒的。

　　完成百分比

　　度量進展的一個過分簡單但特別實際的方法是利用“完成百分比”作為量度。如果有人考慮通過測試的場景的流程，我們可以考慮構造一組檢查點，表 1 中所顯示的一個實例。

　　我們確定表 1 中每個場景和測試中所描述的每個檢查點。不論完成或是沒完成，它們的值都嚴格地報告為是或不是的值。我們合計每一層并將其表示為前一個層的某個百分比。目標是達到每一層的 100% 覆蓋?？偟慕Y果相當粗略，但針對達到最高百分比的工作帶來了提前測試工作的非常有意義的副加作用。

　　缺陷趨勢

　　每個迭代將擁有一個開發包，一些新的特性或場景加入其中并且根據現有場景的缺陷也得到修復。當然有一個趨勢，即實現新的而不修復老的，但是明智的項目經理將注意缺陷趨勢并強調，至多一兩個以缺陷形式的未解決的迭代工作的價值將保留。

　　無論如何，分辨缺陷無疑可以看作進展。與缺陷相關的量度也能夠以有趣的方式得來，包括：

　　每個缺陷的工作、每行源代碼的缺陷、每個模塊或組件的缺陷、按照注入點的缺陷、按照時間的缺陷、按照狀態的缺陷。

　　使用時間圖表 —— 根據時間所有這些量度都可以畫為圖表趨勢，例如，應該積極地調查表示修復缺陷工作穩定增長的趨勢。

　　我們還能夠通過余下的迭代的數量和平均的缺陷分辨工作來增加每個迭代的預期缺陷。這指示了顯著的缺陷負擔，包括在還沒撰寫的代碼中沒有發現的缺陷!這些是粗略的數字，但是是要求全部的完成百分比的重要基礎。

　　對于測試人員的缺陷趨勢

　　雖然上面的缺陷趨勢不是具體到測試規程的，但是存在重要的缺陷量度來指導測試人員，包括每個找到的缺陷的測試工作、每個測試用例的缺陷、每個場景的缺陷，及每個迭代的缺陷。

　　這樣的量度是有效的，不僅從歷史的觀察，還從預言能力上講。例如，如果我們的測試揭示了一個突然的且出乎意料的缺陷密度，我們可能宣稱該構建是不健全的，放棄測試，并讓架構團隊檢查此構建。測試一個糟糕的構建以致精疲力盡，從中得不到一點好處。

　　MTBF

　　平均故障時間(mean time between failure，MTBF)是重要的“人造”量度 —— 也就是，我們不得不捏造定義，為了能夠生成受控條件下的客觀度量。MTBF 通常作為非功能需求出現。為了驗證我們的系統，我們必須在實驗室設置在測的應用程序，利用事件進行干擾，并且當不能適當處理事件時進行監測。我們將其記錄為一個失敗，并且繼續測試或者(如果不幸的話)重新啟動應用程序。我們能夠以快于真實情況的節奏來生成事件流。這些手段的凈效應是能夠在幾個星期內生成幾年中才能度量出的 MTBF 數字。 因為明顯的理由，可以將其認為是人造的量度。

　　這些量度證明測試人員應該看作是項目經理重要的數據來源。

　　構建迭代測試優先級

　　用例驅動的迭代方法生成了新的機會和新的負擔。因為我們將已經限制阻礙完全測試的資源，所以我們應該根據以下優先級順序執行測試：

　　運行“冒煙測試”。如果冒煙測試通過了，那么：

原文轉自：http://www.kjueaiud.com