準則: 測試資料
這個準則簡介測試資料集的設計。
關係
相關元素
主要說明

說明

在測試設計作業中,識別和說明了兩個重要的構件:測試 Script 和測試案例。如果測試資料不存在,這兩個構件也無法實作和執行。它們只是條件、情境和路徑的說明,並沒有可供簡單識別的具體的值。測試資料本身並不是構件,但會嚴重影響測試的成敗。當沒有測試資料時,無法實作和執行測試,因為下列各項都需要測試資料:

  • 建立條件的輸入
  • 評估需求的輸出
  • 支援(測試的前置條件)

因此,在指定「測試實例」時找出值很重要 (請參閱工作成果:測試案例準則:測試案例)。

測試資料有四個在識別實際測試資料時所應處理的屬性:

  • 深度 - 測試資料的資料量
  • 寬度 - 測試資料中的變異程度
  • 範圍 - 測試資料與測試目標的關聯
  • 架構 - 測試資料的實體結構

下列各節詳細說明這些特性:

深度

深度是測試所用的資料量。深度是一項重要考量,因為資料太少無法反映真實生活的狀況,太多又難以處理和維護。理想上,測試應該開始於一小組支援關鍵測試案例 (通常都是正面的測試案例)的資料。在測試期間增加信心之後,也應該增加測試資料,直到資料深度足以代表部署環境為止(或直到適當而可行為止)。

寬度

寬度是指測試資料值的變異程度。您可能會建立更多記錄來增加測試資料的深度。這通常是一個好的解決方案,但它並不處理實際資料中將會出現的真正資料變異。當測試資料中沒有這些變異時,我們可能會無法將問題識別出來(畢竟從 ATM 中提款,並非每一筆都是 $50.00 元)。因此,測試資料值應該反映部署環境中所找到的資料值,如提款 $10.00 或 $120.00 元。另外,測試資料也應該反映真實世界的資訊,例如:

  • 名稱,其中包括職稱、數值、標點和字尾:
    • Dr. James Bandlin、Ms. Susan Smith 和 Rev. Joseph P. Mayers
    • James Johnson III、Steven Wilshire 3rd 和 Charles James Ellsworth, Esq.
    • Ellen Jones-Smythe、Brian P. Tellstor
  • 地址,地址會有許多行,例如:
    • 6500 Broadway Street
      Suite 175
    • 1550 Broadway
      Floor 17
      Mailstop 75A
  • 城市(和國家)代碼及電話號碼真實且一致
    • Lexington, MA, USA + 01 781 676 2400
    • Kista, Sweden +46 8 56 62 82 00
    • Paris, France +33 1 30 12 09 50

測試資料值可能是用來取得足夠寬度的真實資料之實體表示法或統計表示法。這兩個方法都很有價值,建議您採用它們。

如果要根據部署資料的實體表示法來建立測試資料,請將部署資料庫中每個資料元素的容許值(或範圍)識別出來,並確定對於每個資料元素,測試資料至少有一項記錄包含它的每個容許值。

例如:

  帳號(範圍) PIN 號碼
(整數)
帳戶餘額
(十進位)
帳戶類型
(字串)
(S) 0812 0000 0000 至
0812 9999 9999

© 0829 0000 0000 至
0829 9999 9999

(X) 0799 0000 0000 至
0799 9999 9999

0000 - 9999 -999,999.99 至 999,999.99 S, C, X
記錄 1 0812 0837 0293 8493 -3,123.84 S
記錄 2 0812 6493 8355 3558 8,438.53 S
記錄 3 0829 7483 0462 0352 673.00 C
記錄 4 0799 4896 1893 4896 493,498.49 X

上方矩陣包含實際代表可接受的資料值的最低記錄數目。帳號的三個範圍都有一項記錄,所有 PIN 號碼都在指定範圍內,總共有幾個不同的帳戶餘額,其中包括一個負值,每個不同的帳戶類型也都各有幾項記錄。 上方矩陣是最低限度,最好在每一個範圍的限界上及範圍內都有資料值(請參閱準則:測試案例)。

實體表示法的好處是測試資料的大小有限而可管理,焦點集中而鎖定在可接受的值上。不過,缺點是真實世界實際的資料並不完全隨機。真實資料往往會有可能影響效能,但在使用實體表示法時無法觀察到的統計概況。

統計測試資料表示法是反映正式作業資料之統計取樣(相同百分比)的測試資料。例如,當使用上述相同資料元素時,如果我們分析了正式作業資料庫,且發現了下列情況:

  • 記錄總數:294,031
  • 帳戶類型 S 的總數:141,135 (48 % of total)
  • 帳戶類型 C 的總數:144,075 (49 %)
  • 帳戶類型 X 的總數:8,821 (3 %)
  • 帳號和 PIN 號碼平均分佈

這時我們以統計取樣為基礎的測試資料會包括 294 項記錄(相較於上面所記的 4 項):

  測試資料(正式作業的 .1 百分比)
記錄數 百分比
記錄總數 294 100
帳號
(S) 0812 0000 0000 至
0812 9999 9999
141 48
帳號
© 0829 0000 0000 至
0829 9999 9999
144 49
帳號
(X) 0799 0000 0000 至
0799 9999 9999
9 3

上方矩陣只處理帳戶類型。在開發基於統計表示法的最佳測試資料時,您會併入重要的資料元素。在上述範例中,它將包括反映實際的帳戶餘額。

統計表示法的缺點是可能無法反映可接受值的完整範圍。

一般而言,這兩種識別測試資料的方法都可以確保測試資料會處理所有值及效能/移入問題。

測試資料寬度與用來作為輸入的測試資料及用來支援測試(在預先存在的資料中)的測試資料相關。

範圍

範圍是測試資料與測試目標的關聯,它與深度和寬度相關。資料很多並不代表資料正確。如同測試資料的寬度一樣,我們也必須確保測試資料與測試目標相關,也就是說,我們有測試資料可用來支援特定測試目標。

例如,在下列矩陣中,最前面四項測試資料記錄處理每個資料元素的可接受的值。不過,並沒有任何記錄可用來評估帳戶類型 C 和 X 的負餘額。因此,雖然這個測試資料正確包含了負餘額(有效寬度),但下面的資料範圍卻不足以支援利用每個帳戶類型的負帳戶餘額來進行任何測試。處理這項疏失,需要擴充這項資料來併入其他記錄,其中包括各不同帳戶類型的負餘額。

帳號(範圍) PIN 號碼
(整數)
帳戶餘額
(十進位)
帳戶類型
(字串)
(S) 0812 0000 0000 至
0812 9999 9999

© 0829 0000 0000 至
0829 9999 9999

(X) 0799 0000 0000 至
0799 9999 9999

0000 - 9999 -999,999.99 至 999,999.99 S, C, X
記錄 1 0812 0837 0293 8493 -3,123.84 S
記錄 2 0812 6493 8355 3558 8,438.53 S
記錄 3 0829 7483 0462 0352 673.00 C
記錄 4 0799 4896 1893 4896 493,498.49 X
新記錄 1 0829 3491 4927 0352 -995,498.34 C
新記錄 2 0799 6578 9436 4896 -64,913.87 X

測試資料範圍與用來作為輸入的測試資料及用來支援測試(在預先存在的資料中)的測試資料相關。

架構

測試資料的實體結構只與測試目標用來支援測試的任何預先存在的資料相關,如應用程式的資料庫或規則表。

測試並非執行一次便完成。測試要在各次反覆之間重複進行。為了一致、可信而有效地執行測試,在執行測試之前,測試資料應該先返回它的起始狀態。當測試要自動進行時,尤其如此。

因此,為了確保測試的一致、可信和有效,測試資料務必免除所有外部影響,且在測試開始、進行中和結束時,都必須知道它的狀態。您必須處理兩個問題,才能達到這個測試目標:

所有這些問題都會影響測試資料庫的管理方式、測試模型的設計方式,以及與其他角色的互動方式。

不穩定性/隔離

測試資料可能會為了下列原因而變成不穩定:

  • 與測試無關的外部影響修改了資料
  • 測試人員彼此不知道對方所用的資料

為了維護測試的機密和完整性,測試資料受到高度的控制,隔離這些影響。確保隔離測試資料的策略如下:

  • 分隔測試環境 - 測試人員有自己的測試環境,實際上彼此分開。測試人員不共用任何東西,也就是說,他們有自己的測試目標和資料。比方說,每個測試人員都使用自己的 PC,就可以做到這一點。
  • 分隔測試資料基礎實例 - 測試人員有自己的資料實例,不受到任何其他影響。實體環境(甚至包括測試目標)都可以共用,但每位測試人員都有自己的資料實例,測試資料便比較不會有受污染的風險。
  • 測試資料/資料庫分割 - 所有測試人員都共用資料庫,且都瞭解其他測試人員所用的資料(並避免使用其他測試人員的資料)。例如,一位測試人員使用 0 - 99 的記錄,另一位測試人員使用 100-199 的記錄,或一位測試人員使用姓氏為 Aa - Kz 的客戶,另一位測試人員使用名稱為 La - Zz 的病人。

起始狀態

其他需要處理的測試資料架構問題,還有在開始執行測試時的測試資料起始狀態。當使用測試自動化時,尤其如此。正如同測試目標必須在已知恰當的狀態中開始執行測試,測試資料也是如此。這有助於可重複性和信任度,每一次執行測試都與前一次相同。

處理這個問題,通常會用四種策略:

  • 重新整理資料
  • 重新起始設定資料
  • 重設資料
  • 向前捲動資料

以下會詳細說明其中的每一項。

使用的方法會隨著多種因素而不同,其中包括資料庫的實體特性、測試人員的技術能力、外部(非測試)角色是否可得,以及測試目標。

重新整理資料

使測試資料返回起始狀態,最恰當的方法是重新整理資料。這個方法包括建立一份起始狀態的資料庫副本,將它儲存起來。在測試執行完成之時(或執行測試之前),將測試資料庫的保存副本複製到測試環境中,以便使用。這可以確保在每次開始執行測試時,測試資料的起始狀態都相同。

這個方法的好處是可以保存資料的多個不同起始狀態。例如,測試資料的保存狀態可能是當天結束、當週結束、當月結束等。如此一來,測試人員便可以快速重新整理到給定的狀態,以便支援測試,例如,測試當月結束使用案例。

重新起始設定資料

如果無法重新整理資料,下一個最佳方法是利用某些程式方法,將資料還原為起始狀態。重新起始設定資料必須依賴特殊使用案例和工具,使測試資料返回起始值。

這時必須小心確定所有資料、關係和鍵值都返回適當的起始值,以確保沒有將錯誤帶入資料中。

這個方法的一項好處是它可以支援測試資料庫中無效的值。在正常情況下, 將攔截無效的資料值,不允許輸入資料中(例如,透過用戶端的驗證規則)。 不過,另一個參與者仍可能影響資料(如來自另一個系統的電子更新)。測試需要驗證已適當識別和處理無效的資料,不論它出現的方式為何。

重設資料

使資料返回起始狀態最簡單的方法就是針對在測試期間對資料所做的變更進行「反轉變更」。這個方法有賴於利用測試目標來輸入反轉的項目,也就是說,新增已刪除的記錄/值、將已修改的記錄/值取消修改,以及刪除已新增的資料。

不過,這個方法是有風險的,其中包括:

  • 不是一部分,而是所有動作都需要反轉
  • 依賴測試目標中的使用案例(它們必須先測試以驗證適當功能,之後,才能用來重設資料)。
  • 資料庫索引鍵、索引和指標有可能無法重設

如果這是測試環境唯一可用的方法,請避免使用資料庫索引鍵、索引和指標作為驗證的主要目標。也就是說,例如,利用「病患名稱」欄位來判斷病人是否已加入資料庫中,而不用系統產生的病人 ID 號碼。

向前捲動資料

向前捲動資料是處理測試資料起始狀態的最不好的方法。事實上,它並不會真正處理問題。相反地,測試執行完成時的資料狀態會成為測試資料的新起始狀態。一般而言,這需要修改 用來輸入的測試資料和/或用來評估結果的測試案例和測試資料。

在必要時,如月底,會有一些實例。如果將到月底之時,沒有保存資料,就必須執行每天和每週的測試資料和測試 Script,以將資料「向前捲動」到月底處理測試所需要的狀態。

這個方法的相關風險包括:

  • 資料庫索引鍵、索引和指標無法重設(無法用來驗證
  • 資料不斷變更
  • 需要其他工作來認證結果的驗證