作業: 分析測試失敗
這項作業的重點是有效率地尋找、隔離及診斷測試失敗並做成文件。
目的

這項作業的目的如下:

  • 調查「測試日誌」詳細資料,分析在測試實作和執行期間發生的失敗
  • 修正測試過程中的錯誤所導致的失敗
  • 適當地記錄重要的調查結果
關係
步驟
檢查測試日誌
目的:  對照並瞭解測試的輸出結果。 

一開始先收集在測試實作和執行期間所輸出的「測試日誌」。 相關的日誌可能有許多來源 - 由您使用的工具所記錄(測試執行和診斷工具)、 由團隊開發的自訂常式所產生、「目標測試項目」本身的輸出,以及由測試人員手動記錄。 收集所有可得的「測試日誌」來源,並檢查內容。 檢查所有排定的測試已執行完成,且所有測試也依預期般地排定。

捕捉重大事件資料
目的:  記錄任何異常、重大的事件,供後續進一步調查。 

必須捕捉任何異常事件 - 如果無法立即重現當時情況或解釋,則後續類似症狀的事件仍然會產生足夠的資訊,有助於隔離背後的錯誤原因。

立即儘可能地詳細記載,但要指出尚無法解決發生的事件。

找出測試中的程序錯誤
目的:  從事件日誌中排除測試過程的人為錯誤及其他程序化和流程錯誤。 

在實作測試期間或管理測試環境時出現的錯誤,經常是導致許多失敗的禍因。 請找出並解決這些錯誤。

如果測試完成時出現異常,以至於無法執行其他測試,您可能必須先將測試回復到失敗點附近,然後繼續執行剩餘測試。

尋找和隔離失敗
目的:  若要找出失敗點,請從失敗分析中剔除不是失敗來源的「目標測試項目」。 

對失敗進行愈多診斷手續,最後愈有可能找出並瞭解失敗。

試者隔離失敗,剔除不太可能與失敗有關的「目標測試項目」,並尋找剩餘項目的趨勢和性質,例如系統狀態。

對失敗進行分析,如果不重現失敗情形就無法有效地調查失敗,請在一定的控制條件下重現失敗的情形。 利用任何有用處的診斷和除錯工具。

診斷失敗症狀和特性
目的:  捕捉有用的失敗分析結果,以利於判斷和解決錯誤。 

以您在類似狀況上的處置經驗來試著診斷背後的錯誤原因。

如果必要且可行,請求助開發人員,利用開發人員對於軟體的深入瞭解來改善失敗分析。

找出候選的解決方案
目的:  讓負責解決失敗的人員更瞭解失敗的本質和衝擊,並提出可能的思考方向來協助開發人員。 

如需撰寫有效的事件報告和「變更要求」的相關資訊,請參閱作業:決定測試結果 - 建立和維護變更要求

適當地將調查結果做成文件
目的:  以適當的方式向負責解決失敗的人員描述您的失敗分析。 

如需撰寫有效的事件報告和「變更要求」的相關資訊,請參閱作業:決定測試結果 - 建立和維護變更要求

評估及驗證結果
目的:  驗證作業已適當完成,並且產生可接受的工作成果。 

現在您已經完成工作了,這時最好驗證該項工作確實具有足夠的價值,而不只是花費在大量紙上作業。您應該評估您的工作是否具有適當的品質,並且該工作的完成狀態可以讓團隊的其他成員用作他們的後續工作之輸入。請盡可能使用 RUP 提供的檢查清單,來驗證品質和完成狀態都「夠好」。

請邀請執行下游作業而必須以您的工作成果作為輸入的人參與審查您的暫時性工作。請在您仍有時間採取動作來處理他們關心的問題時執行這個動作。您同時也應該將您的工作和關鍵的輸入工作成果做評估,以確定您已經正確且適當地重新呈現那些工作成果。如果由輸入工作成果的作者以此根據來審查您的工作,可能會更好。

請記得 RUP 是一項反覆式的交付程序,在許多情況下,工作成果都會隨著時間而演進。因此,通常並不需要(通常是缺乏生產力)對只會在緊跟在後的後續工作中用到一部分,或甚至於完全用不到的工作,做出完整的工作成果。這是因為和工作成果相關的狀況極可能會變動,因此在建立工作成果所做的假設狀況就變成不正確,導致浪費許多人力物力以及成本高昂的重做。同時也要避免浪費太多時間在呈現方式上,而導致損害內容本身的價值。在呈現方式佔極大的重要性,並且可以提交專案就具有商業價值的專案環境中,您可以考慮將呈現工作交給管理資源來做。



內容
多次出現的項目
事件驅動
持續進行中
選用
規劃
可重複的
詳細資訊