經驗分享—測試資料產生器

你是否也曾經遇過網站或 App 卡卡的、很慢，效能不佳的狀況，而影響用戶的使用？
透過模擬實際使用情境來測試效能，如果測試的回應時間在可接受範圍內，就可以判定效能符合要求。 如果回應時間過長，可以做為開發、測試、正式環境資源的提升參考。

此外，在軟體開發過程中，測試案例的準備也是驗收的關鍵因素。測試案例是最耗神準備的項目，而測試資料又是最耗時間準備的項目。筆者有一段期間協助某產品的測試，在測試資料製造上，光是一個早上只能做出 10 份有效資料(每份資料約有6~8個流程關卡)，感覺一天做完測試資料大個只能測一個測試案例，看起來挺沒有效率的。不僅感覺沒做啥事情，如果要在期限內完成測試工作，那就勢必要加班了，於是就開始來想方法自救一下。

  這一切的測試仰賴不同測試案例中的測試資料準備。

以下是某個需要大量測試資料的情境：在某產品的「歸檔文件管理」上，編號結構是這樣：

年度號 + 分類號 + 卷次號 + 文件流水號，編號樣子如：2024-A001-001-01，而該客戶的規則是 30 份文件要新編下一個卷次號，產出的文件編號樣子如下：

30份文件要換一個卷次號，表示至少要有 31 份文件， 如前所述每份文件約有6~8個流程關卡，完成這樣一份文件的時間大約是 10 分鐘左右，10 分鐘 x 31 份文 = 310 分鐘/60分鐘，約當花了 5 個多小時，才能完成 31 份文件的製作，而且只能測試一次案例就花掉了。想來就是很沒有效率的一天，嗚呼哀哉，苦啊~~~，於是便動動腦想一想可以怎麼做呢?

取巧測試 幸好，這個滿幾份文要換卷次號是可以透過參數設定的，於是可以把 30 份文件要換一個卷次號的設定改為 2 份文件就新編下一個卷次號，這樣只要 3 份文件就可以完成測試了！但這個取巧測試會衍生一些問題，就是自家這樣測試過關了，去到客戶哪裡是沒辦法這樣測試的，如果客戶提供的資源環境不佳，或是自己開發的程式效能不佳，停在運轉中沒法結束，這個時候資料的清理更是麻煩。

而身為 開發人員，是否也曾遇過如上 測試人員 會遇到的情況？

• 需要製作大量的測試資料，以確認自己撰寫的功能是否正確？
• 測試資料製作耗時費力，讓人感到十分煩惱？
• 開發分工細致，不知道如何製作可測試用的有效文件？

如果你曾經遇過上述情況，那麼以下「測試資料產生器」的運作框架也許對您有幫助。引用此概念，你可以：

• 節省大量製作測試資料的時間和精力
• 確保測試資料的準確性和完整性
• 輕鬆製作類似「多流程關卡的測試資料」

在本次分享的「測試資料產生器」，在使用上非常簡單。你只需輸入以下資訊：

• 要生成的測試資料的數量(ex：100 份)
• 資料的格式(範本文件)

開發人員不到 1 分鐘的時間，便完成了 100 份測試資料的製作。減少了開發人員的取巧測試：「第一種取巧」的是改設定規則，2 份文件換一次卷次號；「第二種取巧」的是，進資料庫改最大文件目次號，再做測試。因此，有了「測試資料產生器」，開發人員可以自信地說：「我已經完成測試了，而且我使用了 100 份資料進行測試。放心，效能沒有問題。這個部分在我完成開發撰寫後，也一併完成了測試。」

接下來，我們來說明「測試資料產生器」的運作概念。起初，我們手動使用 SQL script 複製多份文件資料。後來，我們打包了一個 UI(WinForm)程式，將這些 Script 打包。（提醒：由於讀者的環境各有不同，因此這邊介紹以「概念性 Re-use」 為主。)

首先，複製一個與正式使用的資料庫結構相同的資料庫，但將表格名稱更名為可明確辨識為測試資料製造使用的名稱(如 template_原tableName)。這個資料庫簡稱為「範本資料」。複製的資料可以包括主要基本資料、流程資料和文件檔案資料（檔案也是另外放到「範本資料」區）。

假設一份文件資料有十個流程，現在需要一份測試資料到第六關流程的程式，那麼就是手動透過原始系統在UI上跑完第五關流程，把第五關的資料複製放到「範本資料」中，給它一個範本名稱，例如：「範本資料-第五關完成」。這裡要做的就是解析流程到第五關時，資料總共寫了哪些地方[開 SQL Profile 錄製]，要去使用的環境中（table、檔案）複製到「範本資料」區（table、檔案）。

測試資料產生的流程如下：

1. 到「範本資料」區（table、檔案），取「範本資料-第五關完成」的資料。
2. 複製時類似主 Key 取號的動作，一樣要呼叫取號 API 重新取號，將被複製出來的資料更新為新的 Key 值。
3. 再將這些資料寫入要使用的資料庫中。檔案複製也是一樣的處理，關鍵 Key 要如同使用環境中取新值。
4. 並依照所需要建置的筆數 Loop 以上的處理。
5. 介面上記錄執行的時間。

因此，測試資料同一個類型的範本只要手動儲存一次即可，其他的可以透過工具來產生多筆。實際運用 100 份資料的產生大約需要 30 秒左右的時間。

使用的技術包括 db script（或處理 data 的 API）、處理檔案的 js 程式或是引用原始開發的程式、UI介面程式 winForm，以及相關所需的環境設定。這些設定可以寫在 .ini 檔案中或是做一個介面來處理設定檔案。即便沒有 winForm UI 手動執行 SQL script 的半自動處理，在測試資料的製造上面也是很有幫助的。

概念上的虛擬碼如下

依據上述概念，提供部分虛擬碼(MS-SQL)：
EXEC('CREATE SCHEMA [template] AUTHORIZATION [dbo]') (設置專屬的 Schema 以示區別)

select distinct a.name from sys.objects a join sys.columns c 
on a.object_id = c.object_id AND c.name = '關鍵欄位名稱' 
AND a.type = 'U' (取得關鍵 TABLE NAME 有哪些)

INSERT template.範本DB.範本Table(A) 
SELECT * FROM 正式DB.正式TABLE(A) 
WHERE 關鍵欄位=設定為範本的關鍵值(留存範本資料用)

關鍵值重新取新號
WHILE BEGIN   FETCH NEXT FROM XXX      END(Loop 筆數)
 INSERT INTO 正式DB.正式TABLE 
 SELECT FROM template.範本DB.範本TABLE(A) 
 WHERE 關鍵欄位=範本格式名稱
 (從範本取資料+新取的號碼，回寫一筆新的資料到正式 TABLE 中)

以上提供概念上簡單的框架與虛擬碼，大家可以找個簡單的 table 來試試看，再慢慢擴增到比較複雜的流程。這樣可以節省時間(即使半自動的手動執行 SQL SCRIPT)，也可以增加測試的確實度。或是直接叫用資料處理的 API 來運作也很有用的。希望對您有幫助。

適用時機點

什麼時候適合引用上述「測試資料產生器」的概念呢? 測試資料關卡越多，越複雜，越能彰顯這個方法的功效。單純的 CRUD 的單元測試由開發人員寫測試程式就可以完成了。不需要用到工具來幫忙。