作業: 執行測試套組
這項作業說明如何執行 評估產品品質所需的適當測試集合,以及如何取得測試結果,來促進產品的持續評量。
關係
步驟
將測試環境設定為已知的狀態
目的:  正確地建立測試環境,以準備開始執行測試套組。

設定測試環境時,確定建置好所有必要的元件(硬體、軟體、工具、資料等),並且所有元件都可以開始在測試環境中使用,並且處於正確的狀態可以開始執行測試。通常這個動作會進行某種形式的基本環境重設(例如登錄和其他配置檔)、將基礎資料庫還原到必要的狀態,以及安裝任何週邊裝置(例如在印表機中放入紙張)等。有些作業可以自動執行,但有些作業卻需要人工介入。

使用如可以擷取和還原硬碟映像檔的環境支援工具,可以很有效率地管理這項工作。

設定執行工具選項
目的:  正確地配置執行「測試套組」時使用的工具。

設定支援工具的執行選項。視工具的準確程度,這裡可能有許多選項可以考慮。如果未適當設定這些選項,可能會減少所產生的「測試日誌」以及其他輸出的用途和價值。可能的話,您應該嘗試儲存這些工具選項和設定,以便能輕易地依據一或多個預先決定的設定檔來重新載入。如果是使用自動化測試執行工具,則可能會有許多不同的設定可以考慮,例如執行作業的速度。

如果是手動測試,這通常只是記載至問題或變更需求追蹤系統,或是將新的唯一項目分割到支援系統的記載結果中。您應該想想要寫入「測試日誌」的檔案名稱、位置和狀態。

排定測試套組執行時間
目的:  決定開始執行測試的適當時間。

在可以專人執行測試的許多情況中,「測試套組」通常可以隨需應變執行。在這種情況下,進行排程時,就需要考慮到諸如其他測試者、小組的其他成員以及共用測試環境的不同測試小組的工作。在這種情況下,測試執行作業通常需要考慮不經常重設環境。

不過,如果希望進行無人式自動化測試,或必須協調在不同機器上平行執行測試時,就需要某種形式的自動化排程機制。這可以使用您的自動化測試執行工具的功能,或是開發您自己的公用程式功能,來啟用必要的排程。

執行測試套組
目的:  進行「測試套組」中包含的測試,並監視其完成情況。

「測試套組」的執行方式會視測試是以自動方式或手動方式執行而定。在這兩種情況中,都會使用於測試實作作業期間開發的測試套組來自動執行測試,或引導執行手動測試。

評估測試套組的執行
目的:  決定「測試套組」是否執行到完成或異常地停止,並評量是否需要採取更正動作。

測試的執行作業會在兩種情況下結束或終止:

  • 正常:所有測試都執行到預期的完成狀態。 
  • 異常或過早結束:測試未執行到預期的完成狀態。當測試異常終止時,從「測試日誌」衍生的後續「測試結果」可能就不可靠。需要找出異常終止的原因,並且必要的話,更正錯誤然後重新執行測試。
從中止的測試回復
目的:  決定從中止的「測試套組」執行作業回復的適當更正動作,並且在必要時,更正問題、回復以及重新執行「測試套組」。

若要回復中止的測試,請執行下列動作:

視察「測試日誌」及其他輸出 回復中止的測試

視察「測試日誌」及其他輸出,看看完成度和精確度。指出發生錯誤的地方,並加以檢查。

若採用自動化測試時,有兩種重要的中止測試需要注意:

  • 嚴重錯誤-系統失敗(網路故障、硬體毀損等)
  • 測試失敗-這是指「測試套組」中的某個部分測試無法如預期般執行。

如果在測試執行期間發生任何一種異常的行為,它們可能是下列症狀的象徵:

  • 執行「測試套組」時,發生大量(持續發生)非預期的動作或非預期的視窗
  • 測試環境好像沒有反映、很慢或是處於非預期的狀態(如當掉或毀損)。

請檢查症狀,直到找出問題的主要原因為止。

更正錯誤 回復中止的測試

錯誤可以從測試使用的輸入資料、測試本身或測試的其他層面,例如測試環境或執行時期工具設定中尋找。經常若要更正某個測試層面的一個錯誤時,測試的所有層面都必須處於正確狀態才行。

完成問題調查之後,您可能會發現有一或多個錯誤需要更正。若要對環境、測試資料或測試本身進行永久的更正,最好能在套用任何永久更正之前,先將每一個測試層面重新還原回已知的狀態。如此可以確保在已知狀態的環境中不會有任何其他不需要或無效的變更。

做好必要的變更之後,請視需要,儲存測試並備份或儲存相伴隨的輸入資料和測試環境。

重新排定及執行「測試套組」 回復中止的測試

重新排定及重新執行「測試套組」。視有什麼回復程序可用,您可能可以從某個過渡點重新開始測試套組,而不需要從頭開始。請注意,若要從執行測試的半途回復測試執行作業,通常需要實作及持續維護某些局部回復程序。

重新評估「測試套組」的執行 回復中止的測試

確認現在「測試套組」已執行到完成。如果仍有問題存在,請重新檢查「回復中止的測試」的這些子區段,直到解決所有問題為止。

視察「測試日誌」中的完成度和精確度
目的:  決定「測試套組」的執行確實有產生有用的測試資訊,如果不然,則找出適當的更正動作。

當測試執行作業剛完成時,應該要審查「測試日誌」,以確保日誌是可靠的,並且報告的失敗、警告或非預期的結果並不是由外部的影響造成(對測試目標),如不正確的環境設定或測試的輸入資料無效等。

對於使用 GUI 的自動化測試,常見的測試失敗包括:

  • 測試驗證失敗 - 當實際的結果和預期的結果不相符時,即會發生此情況。驗證所使用的驗證方法只專注於必要的項目及/或內容,並視需要加以修改。
  • 非預期的 GUI 視窗 - 這個情況的發生原因有數個。最常見的原因是 當有非預期的 GUI 視窗為主動式,或是所顯示的 GUI 視窗數目超過預期時。請確定將測試環境設定及起始設定為可正確的進行測試執行。
  • 遺漏 GUI 視窗 - 當預期 GUI 視窗應該可以使用(不一定是在主動式),但卻無法使用時,就會出現此失敗狀況。請確定將測試環境設定及起始設定為可正確的進行測試執行。驗證實際的遺漏視窗是否從測試目標移除。

如果所報告的失敗是由測試工作成果中指出的錯誤,或是由測試環境問題造成,就應該採取適當的更正動作,然後重新執行測試。

如果您可以從「測試日誌」中判斷失敗是由「目標測試項目」中的實際失敗造成的,則該作業的執行部分就算完成了。

將測試環境還原為已知的狀態
目的:  確保在執行「測試套組」之後,正確地重設環境。

(請看第一個步驟)接下來您應該將環境還原回其原始狀態。通常這個動作會進行某種形式的基本環境重設 (例如登錄和其他配置檔)、將基礎資料庫還原回已知的狀態等,以及除了如在印表機中放入紙張以外的其他作業。有些作業可以自動執行,但有些作業卻需要人工介入。

維護追蹤關係
目的:  對受追蹤項目啟用影響分析以及執行評量報告。 

使用「測試計劃」中概述的「可追蹤需求」,視需要更新追蹤關係。有一個理想的開始點,是以測試範圍或測試涵蓋面,來考慮可追蹤性。我們通常會建議將測試範圍的測量和您在測試規劃活動期間發現的驅動力相比。

「測試套組」也可以追蹤回其實現的已定義測試案例。它們也可以追蹤回需求元素、軟體規格、設計或實作方式。

不論您決定哪些關係是需要追蹤的重要關係,您都需要更新在實作「測試套組」時,所建立的關係狀態。

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

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

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

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



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