作業: 實作測試
這項作業說明如何開發獨立式或合作式測試。
規範: 測試
目的

這項作業的目的如下:

  • 實作一或多個測試工作成果,經由實際執行來驗證軟體產品
  • 開發可以在更大的測試基礎架構下搭配其他測試一起執行的測試
關係
步驟
選取適當的實作技術
目的:  判斷適合用來實作測試的技術。 

選取最適合用來實作測試的技術。對於您要執行的每一項測試,考量至少實作一個「測試 Script」。 特定測試的實作有時會跨越多個「測試 Script」。 有時單一「測試 Script」會提供多項測試的實作。

實作測試的一般方式包括以 Script 形式撰寫要遵循的文字說明(用於手動測試), 以及使用 Script 程式設計語言來設計、擷取/錄製或產生(用於自動化測試)。 下列各節探討每一種方法。

如同大多數方法一樣,建議您混合使用下列技術來取得更有用的結果。 雖然不必照單全收,但也不應該自我局限在單一技術上。

子主題:

手動測試 Script 選取實作技術

有許多測試最好手動執行,請避免陷入嘗試不當地自動化測試的陷阱。 使用性測試就是手動測試通常優於自動化測試的一個領域。另外,需要在軟體系統的實際輸出上驗證精確性和品質的測試,通常也需要手動驗證。 根據一般的經驗,最好以手動實作來進行特定「目標測試項目」的初期測試; 這種方式可讓測試人員瞭解目標項目、順應非預期的行為來調整,以及透過人為判斷來決定下一步要採取的適當行動。

有時,手動執行的測試後來會形成自動化,並在迴歸測試策略中重複使用。 然而,請注意,您可手動執行的每一項測試,並非都必須或適合(或甚至可能)自動化。 在測試執行、可見度及對照詳細測試結果的速度和精確度上,以及在建立和維護複雜測試的效率上, 自動化確實帶來優點,但就像所有實用的工具一樣,不可能解決您的所有需求。

自動化有某些缺點:基本上是在測試執行期間缺乏人為判斷和推理。 目前可用的自動化解決方案完全沒有人類具備的認知能力 - 相信永遠也不可能有。 在手動測試的實作期間,人為推理可運用在系統對於刺激因素的觀察反應上。 目前的自動化測試技術及支援工具,通常不太有能力注意到某些系統行為的含意,更沒有什麼能力透過演繹推理來推測可能的問題。

以程式設計的測試 Script 選取實作技術

大多數採用測試自動化的測試人員所認同的最佳方式。純粹以理論來說,此慣例的執行方式和採用的通則同於軟體程式設計。 因此,軟體程式設計上使用的大多數方法和工具,通常也適用且有益於測試自動化程式設計。

在標準的軟體開發環境(例如 Microsoft Visual Studio 或 IBM Visual Age)或特殊的測試自動化開發環境下(例如 Rational Robot 提供的 IDE), 測試人員可以不受約束地將開發環境的特性和功能發揮得淋漓盡緻。

程式設計自動化測試的缺點在於直接以程式設計當做一般技術的缺點。 為了讓程式設計發揮效用,在適當的設計上應該有所考量:否則實作很可能失敗。 如果開發的軟體很可能歷經不同的人來修改(常見的情況),則必須考量在程式開發中採用一般的樣式和格式,並確保用法正確。 有兩項最重要的考量大多肇因於誤用這項技術。

首先,測試人員會全神貫注在程式設計環境的功能上,投入太多時間在問題上精心製作講究又精密的解決方案,然而有更簡單的方法可以解決。 結果,測試人員在原本是程式設計的工作上浪費寶貴的時間,排擠掉可以實際測試和評估「目標測試項目」的時間。 需要規範和經驗才能避免落入這個陷阱。

其次,用來實作測試的程式碼將因為人為錯誤或疏忽而潛藏錯誤。 有些錯誤在正常實作自動化測試期間很容易除錯和更正:但有些則不可能。 就像有些錯誤無法在「目標測試項目」中偵測到一樣,在測試自動化軟體中也同樣難以偵測到錯誤。 再者,當自動化測試實作中採用的演算法是根據軟體實作本身採用的同一種錯誤演算法時,也可能引起錯誤。 這會導致未偵測到錯誤,被表面上執行成功的自動化測試的安全假象所蒙騙。 請儘量在自動化測試中採用不同的演算法來降低這種風險。

錄製或擷取的測試 Script 選取實作技術

有許多測試自動化工具可以錄製或擷取軟體應用程式的人機交談過程,然後產生基本的「測試 Script」。 這有許多不同的工具解決方案。大多數工具會產生以某種高階(通常可編輯的)程式設計語言來實作的「測試 Script」。 最常見的設計有下列運作方式:

  • 將用戶端硬體過邊輸入裝置(滑鼠、鍵盤等)的輸入攔截到用戶端作業系統,以擷取與應用程式用戶端 UI 的互動。 有些解決方案會攔截作業系統和裝置驅動程式之間交換的高階訊息,這些訊息以稍具意義的方式描述互動; 另外一些解決方案會擷取低階訊息,通常根據滑鼠座標上的時間性移動,或 key-up 和 key-down 事件。
  • 攔截用戶端應用程式和一或多個伺服器應用程式之間透過網路收送的訊息。 成功攔截這些訊息通常仰賴於使用標準、公認的傳訊通訊協定, 例如 HTTPSQL 等。 有些工具也可以擷取「基本」通訊協定,例如 TCP/IP,但用於這種性質的「測試 Script」會很複雜。

雖然這些技術通常適合納入自動化測試方法中,但部分業者認為這些技術有所限制。 其中一項主要的考量是有些工具只是擷取應用程式互動,此外毫無功用。 如果不加入觀察點來捕捉和比較後續 Script 執行期間的系統狀態,基本「測試 Script」不能視為完整的測試。 在此情況下,最初的錄製功能必須再加強,加入其他自訂的程式碼在「測試 Script」內實作觀察點。

關於此點及其他以測試程序錄製或擷取做為測試自動化技術的議題上,有許多作者已出版書籍和評論。 若要深入瞭解這些議題,建議您閱覽下列作者公佈在網際網路上的著作:James BachCem KanerBrian MarickBret Pettichord, 以及 Lessons Learned in Software Testing 這本書的相關內容 [KAN01]

產生的測試 選取實作技術

有些較精密的測試自動化軟體可以根據產生演算法,實際產生測試的各種層面 -「測試 Scriipt」的程序化層面或「測試資料」層面。 這種自動化有利於您的測試工作,但本身不足以成為完整的方法。 Rational TestFactory 工具和 Rational TestManager 資料儲存池產生特性是這種技術的實作例子。

設定測試環境前置條件
目的:  讓環境在正確的啟動狀態下準備就緒。 

設定測試環境,包括所有硬體、軟體、工具及資料。 確保所有元件正常運作。除了將紙張放入印表機以外, 這通常還需要某種形式的基本環境重設(例如,重設 Windows 登錄及其他配置檔)、基礎資料庫還原到已知狀態等。 有些作業可以自動執行,但有些作業卻需要人工介入。

子主題:

(選用)手動演練測試 設定

特別適用於自動化「測試 Script」,有利於在最初手動演練測試,以確認預期的先決要件存在。 在演練時,您應該驗證環境、軟體及測試設計的完整性。 演練在您採用互動式錄製技術時最重要,在您以程式設計「測試 Script」時最不重要。 目的是確認成功實作測試所需的全部元素都存在。

由於已知軟體已相當穩定或成熟,如果您認為手動演練所表達的領域中發生問題的風險非常低,則可以選擇略過此步驟。

指定和確認測試法則的適當性 設定

確認您打算採用的測試法則很適當。之前尚未確認,現在是該這樣做的時候。

您應該利用替代方法來試著確定選擇的「測試法則」可提供準確又可靠的結果。 比方說,如果打算以表示資料更新已發生的應用程式 UI 所顯示的欄位來驗證測試結果, 請考慮獨立查詢後端資料庫,以驗證相對應的記錄在資料庫中的狀態。 或者,忽略更新確認對話框中顯示的結果,改以透過替代的前端功能或操作來查詢記錄,以確認更新。

重設測試環境和工具 設定

接下來,您應該將環境(包括支援工具)還原到的原始狀態。如先前的步驟所述,除了將紙張放入印表機之類的工作外, 這通常還需要某種形式的基本作業環境重設、基礎資料庫還原到已知狀態等。 有些重設作業可以自動完成,有些方面通常需要人工介入。

設定測試支援工具的實作選項,視工具的複雜性而定。 可能的話,您應該考慮儲存每一項工具的選項設定,以便根據一或多個預先決定的設定檔來輕鬆地重新載入。 在手動測試的情況下,將包括在支援系統中分割新的項目來記載測試結果,或登入爭議和變更要求記載系統。

以自動化測試實作工具而言,可能有許多不同的設定需要考量。未適當設定這些選項可能降低產生的測試資產的效用和價值。

實作測試
目的:  實作一或多個可重複使用的測試實作資產。 

利用「測試構想清單」,或一或多個選定的「測試案例」成果,開始實作測試。 一開始先將以唯一可識別的名稱來命名測試(如果尚無名稱),並準備 IDE、擷取工具、試算表或文件,以開始錄製測試的特定步驟。 視情況重複執行下列子區段來實作測試。

請注意,對於某些特定的測試或測試類型,將執行測試所需的明確步驟記錄下來,可能沒有什麼用處。 在某些形式的探索測試中,重複的測試不是預期的交付項目。 在非常簡單的測試中,測試用途的簡要說明通常就足以重現測試。

子主題:

實作導覽動作 頁面頂端

以程式設計、錄製或產生必要的導覽動作。一開始選取適當的最佳導覽方式。 對於目前大多數的系統種類,「滑鼠」或其他指標裝置是較佳和主要的導覽媒介。 例如,「個人數位助理 (PDA)」使用的指標和劃線裝置,概念上等同於「滑鼠」。

次要的導覽方法通常是透過鍵盤互動。在大多數情況下,導覽由滑鼠驅動和鍵盤驅動的動作組合所構成。

在某些情況下,您需要考量聲控、燈光、視覺及其他形式的辨識。 這些在做自動化測試時可能比較麻煩,且可能需要在應用程式中加入特殊的測試介面延伸模組, 才能從檔案載入及處理語音和視覺元素,而不用動態捕捉。

在某些情況下,您可能想要(或需要)以多種導覽方式來執行相同的測試。 達到這的目的有不同的方法,例如:利用一種方法來自動化所有測試,利用其他方法來手動執行所有或部分測試; 隔離測試的導覽層面和特定測試專用的「測試資料」,提供並建置邏輯導覽介面以容許選擇方法來推動測試; 直接混合和結合導覽方法。

實作觀察點 頁面頂端

在「測試 Script」中應該觀察的每一點上,採用適當的「測試法則」來捕捉所需的資訊。 在許多情況下,從觀察點取得的資訊必須記錄並保留下來,供後續的控制點參考。

由於是自動化測試,請決定如何從「測試 Script」報告觀察到的資訊。 大多數情況下,通常很適合直接在中央「測試日誌」中,以相對於「測試 Script」開頭的時間差量來記錄觀察結果; 在其他情況下,特定的觀察結果可能另外輸出到試算表或資料檔,做為更複雜的用途。

實作控制點 頁面頂端

在「測試 Script」中應該採取控制決策的每一點上,請取得並評估適當的資訊,以決定控制流程的正確分支。 從先前的觀察點擷取的資料通常會輸入到控制點。

只要在控制點及關於控制流程下一個動作的決策出現的地方, 就建議您記錄控制點的輸入值及「測試日誌」中選取的結果流程。

解決測試實作的錯誤 頁面頂端

在測試實作期間,您很可能直接在測試實作中犯下錯誤。這些錯誤甚至可能肇因於您在測試實作中忽略的事物,或與您在測試環境中疏於考慮的事物有關。 必須解決這些錯誤,測試才算實作完成。 請確認您遭遇的每一個錯誤,並努力解決。

至於採用程式設計語言的測試自動化,這可能包括由於未宣告變數或函數或不當使用函數而造成的編譯錯誤。 逐一解決編譯器顯示的錯誤訊息或其他任何來源的錯誤訊息,直到「測試 Script」沒有語法上及其他基本實作的錯誤為止。

請注意,在後續執行測試期間,可能會發現測試實作的其他錯誤。 最初,這些可能顯示為目標測試項目中的失敗 - 在分析測試失敗,您必須非常小心確認失敗確實在目標測試項目中,而不是在測試實作的某些方面。

建立外部資料集
目的:  建立和維護供測試在執行期間使用的資料(儲存在測試 Script 之外)。 

在許多情況下,最好將「測試資料」存放在「測試 Script」之外。 如此在「測試 Script」和「測試資料」維護上會更靈活、簡單及安全。 外部資料集依下列方式提供要測試的值:

  • 「測試資料」在「測試 Script」之外,不必在「測試 Script」中寫入固定的參照
  • 輕易修改「外部測試資料」,對「測試 Script」的影響通常最小
  • 「測試資料」很容易支援更多「測試案例」,不太需要甚至不必修改「測試 Script」
  • 許多「測試 Script」可以共用「外部測試資料」
  • 「測試 Script」可以設計為使用「測試資料」來控制「測試 Script」內的條件性分支邏輯。
驗證測試實作
目的:  執行「測試 Script」來驗證「測試 Script」運作正確。 

特別是在測試自動化的情況下,在測試執行時,您可能需要花些時間來穩定測試的運作。 「測試 Script」的基本實作完成之後,應該經過測試以確定適當地實作個別的測試且運作正常。

將測試環境回復到已知狀態 驗證測試實作

同樣地,您應該將環境還原到原始狀態,在測試實作工作之後做好清除動作。 如先前的步驟所述,除了將紙張放入印表機之類的工作外, 這通常還需要某種形式的基本作業環境重設、基礎資料庫還原到已知狀態等。 有些作業可以自動執行,但有些作業卻需要人工介入。

設定工具和起始測試執行 驗證測試實作

尤其在測試自動化的情況下,應該變更支援工具內的設定。目的是執行「測試 Script」來驗證「測試 Script」運作正確。

最好以實作「測試 Script」時所用的同一個「建置」版本的軟體來執行此步驟。 如此可避免由於後續建構版本中潛藏的錯誤而造成問題。

解決執行錯誤 驗證測試實作

在實作期間完成的一些事物和使用的方法,經常需要一定程度的調整,才能自動執行測試, 尤其是在多個「測試環境配置」下執行測試的情況。

在測試自動化的情況下,請預留時間來檢查和測試「在誤差範圍內」,並調整到表現可靠為止,然後才宣佈測試已完成實作。 您可能將此步驟延到生命週期稍後才執行(例如,在「測試套組」開發期間), 但建議不要拖延:否則最後會積壓一大堆需要解決的失敗。

將測試環境還原到已知狀態
目的:  讓環境維持在最初建立時的狀態,或設為實作下一個測試所需的狀態。 

此步驟乍看之下可能不太重要,但最好養成習慣與團隊的其他測試人員確實合作 - 尤其在共用實作環境的情況下。 也最好建立常規,養成思考系統狀態的習慣。

在主要為手動測試的工作中,雖然通常很容易指出和修正環境還原問題,但切記,測試自動化較不允許環境狀態出現意外問題。

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

使用「測試計劃」中概述的「可追蹤需求」,視需要更新追蹤關係。

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

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

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

請記得 RUP 是一項反覆式的交付程序,在許多情況下,工作成果都會隨著時間而演進。因此,通常並不需要(通常是缺乏生產力)對只會在緊跟在後的後續工作中用到一部分,或甚至於完全用不到的工作,做出完整的工作成果。這是因為和工作成果相關的狀況極可能會變動,因此在建立工作成果所做的假設狀況就變成不正確,導致要重做,因而浪費了許多人力物力。

同時也要避免浪費太多時間在呈現方式上,而導致損害內容本身的價值。在外觀和專案交付項目有同等重要性和經濟價值的專案環境中, 您可能會考慮運用行政或資淺的資源來處理工作成果,以改善外觀。



詳細資訊