跳至內容

表徵測試

維基百科,自由的百科全書

計算機編程中,表徵測試(也稱為黃金大師測試[1])是一種描述(表徵)現有軟件的實際行為,從而通過自動測試來保護遺留代碼的現有行為不被意外更改的手段。這個名詞由邁克爾·費瑟斯(Michael Feathers)首創。 [2]

概覽

[編輯]

表徵測試的目的是幫助開發人員驗證對軟件系統的參考版本所做的修改沒有以不想要或不希望的方式修改其行為。它們為沒有足夠的單元測試的代碼擴展和重構提供了安全網。

在吉米·巴赫和邁克爾·博爾頓(Michael Boltons)對測試先知的分類中, [3]這種測試對應於歷史先知。與通常的基於斷言的軟件測試方法相反,測試的結果不是由單個值或屬性(由斷言檢查)決定的,而是由被測試的軟件過程的複雜結果作為一個整體與該軟件的早期版本中相同過程的結果進行比較來確定的。從某種意義上講,表徵測試會顛覆傳統測試:傳統測試會檢查單個屬性(將它們列入白名單),而表徵測試會檢查所有未刪除的屬性(列入黑名單)。

創建表徵測試時,必須觀察給定一組輸入會發生什麼輸出。假定觀察到遺存代碼基於給定輸入給出了特定的輸出,則可以編寫一個測試,斷言遺存代碼的輸出與給定輸入的觀察結果相匹配。例如,如果觀察到 f(3.14) == 42,則可以將其創建為一個表徵測試。然後,在對系統進行修改之後,如果給出相同的輸入,測試可以確定修改是否會導致結果變化。

不幸的是,與任何測試一樣,通常不可能為每個可能的輸入和輸出創建特徵測試。因此,許多人選擇聲明或分支覆蓋。但是,即使這樣也可能很困難。測試編寫者必須使用他們的判斷來決定多少測試是合適的。通常情況下,編寫只涵蓋已知發生的特定輸入和輸出的表徵測試就足夠了,要特別注意邊界情況。

與非常相似的回歸測試不同,表徵測試不會驗證代碼的正確行為,這是無法確定的。相反,他們驗證在編寫時觀察到的行為。通常沒有規範或測試套件可用,僅保留表徵測試作為選項,因為保守的做法是假定舊的行為是必需的行為。表徵測試本質上是變化檢測器。它依賴於分析結果的人來確定所檢測到的變化是預期的和/或理想的,還是意外的和/或不理想的。

表徵測試有趣的一個地方是,由於它們基於現有代碼,因此可以自動生成一些表徵測試。自動化的表徵測試工具將使用具有大量的相關的和/或隨機輸入值來執行現有代碼,記錄輸出值(或狀態變化)並生成一組表徵測試。當生成的測試針對新版本的代碼執行時,如果該版本代碼的修改以某種方式改變了先前建立的行為,則它們將產生一個或多個失敗或警告。

GUI級別上進行測試時,可以將表徵測試與智能猴子測試結合使用,以創建複雜的測試,捕獲用例及其中的特殊情況。

優點

[編輯]

與基於斷言的傳統軟件測試相比,表徵測試具有以下優點:

  • 對於複雜的遺存系統來說,實現起來相對容易。
  • 就可以進行重構了。
  • 通常,對於諸如PDFXML、圖像等複雜結果,這通常是一種明智的做法,在這些結果中,用斷言檢查所有相關的屬性,會由於屬性的數量而無法實現,並導致測試代碼不可讀/不可維護。

缺點

[編輯]

與基於斷言的傳統軟件測試相比,表徵測試具有以下缺點:

  • 它基於可重複性。無論是表徵還是過程結果,都需要掩蓋/刪除易變和不確定的值。如果需要刪除太多元素或刪除元素太複雜,則可能會使表徵測試無法實施。
  • 它不僅取決於軟件的可重複性,還取決於環境和輸入值的穩定性。
  • 表徵測試不能推斷結果的正確性。它僅有助於檢測軟件更改的有害影響。

參考文獻

[編輯]
  1. ^ J. B. Rainsberger - Surviving Legacy Code with Golden Master and Sampling. [2017-05-30]. (原始內容存檔於2022-04-26). 
  2. ^ Feathers, Michael C. Working Effectively with Legacy Code (ISBN 0-13-117705-2).
  3. ^ Bolton, Michael. Testing Without a Map (PDF). Better Software (Sticky Minds / TechWell). January 2005 [2017-05-30]. (原始內容 (PDF)存檔於2022-04-12). 

外部連結

[編輯]