性能測試之數據準備  《轉載》

不知道大家在做性能測試的時候，測試數據是如何準備的，筆者在實際工作中發現測試數據的準備會遇到以下幾個問題：

　　其一，由于性能測試需要具備一定的并發量，尤其在實際系統所能承受最大并發量未知的情況下，測試數據的量也必須滿足預期業務并發量的一個量的需求，如何準備這些量的數據是第一個問題；

　　其二，除了量的需求，數據也必須是符合業務邏輯的，是可用或者可測試用的數據，不是臟數據或無效數據。比如表與表之間是具備一定的關聯關系，記錄之間也有關聯關系，所有的測試數據要符合這些規則，如何完全了解掌握這些規則，并且根據規則來生成測試數據是第二個問題；

　　其三，性能測試往往是安排在功能測試完成之后，在項目進度非常緊張的情況下，時間資源甚至是人力資源非常有限的情況下，如何快速掌握業務，準備有效的并且符合量的需求的測試數據是一個比較大的挑戰。

　　針對以上問題，筆者工作中用到以下幾種數據準備的方法：

　　一是用SQL腳本方式，插入測試數據，但是有幾個前提條件，首先需要對該業務下所有關聯的表結構非常熟悉，其次對整個業務也需要非常熟悉，而這些條件只有開發或者功能測試人員會具備。在以這種方式準備數據的時候，需要密切與開發或者功能測試人員進行溝通了解學習，并且在信息來源不全的情況，需要不斷嘗試，不斷調試才能夠準備出符合要求的測試數據。但是仍然會存在風險，即便數據準備完畢，也不能完全確保這些數據是真正合法的，可能這些數據符合被測業務的需求，但是卻不符合其他業務或者實際生產環境的需求，也就是說不能完全代表真實數據；并且也存在遺漏其他數據但是業務卻跑通的情況。通常情況下，SQL腳本批量導入數據的方式仍然是非常直接有效的方法，比較靈活，量和業務需求都是可控的；缺點就是需要搞清表間關系，精通業務流程，腳本也需要經常維護。

　　二是通過業務的方式去產生測試數據，當然不是手工去一個一個添加，如果量很大，勢必需要依靠自動化工具來實現。這種情況下，測試人員只需要了解業務的操作流程，然后采用自動化工具比如LoadRunner，QTP之類就能通過業務大量生成數據，這樣的數據一般都是合法可用的，能夠確保之后的性能測試的質量。然而缺點也很明顯，需要開發額外的測試腳本，要花費額外的時間和人力。

　　三是直接采用生產數據，在有現成數據并且數據保密性要求不高的情況下，可以采用這種方法，畢竟生產數據是原原本本的用戶行為所產生的數據。但是有這樣幾個缺點，量不可能控，可能某些業務的數據量少了，不符合性能測試的需求；生產數據也會有臟數據的產生，會因為系統架構的調整，表結構的變化等等諸多因素產生臟數據，而這些數據是不具備業務意義的；多數情況下，生產數據一般不會被用于測試。

　　在沒有開發的支持下，第一種方法會略顯困難，但第一種方法也是非常直接有效的。

　　最后講一下，我所設想的最后一種方法，可以節省很多時間和精力，從而把重點放在性能的調優上。在性能測試的初期分析階段，可以先確立被測的模塊，盡量縮小模塊的范圍，針對這個小模塊的業務來準備數據，讓開發配合去掉不必要的業務限制，比如說驗證碼、資格碼之類就用相同的碼就能驗證通過，盡量減少數據之間的關聯和限制。這樣在準備數據的時候就非常輕松，可能只是簡單的插入操作而已。從而把主要的精力放在了性能調優或者用戶模型以及場景的設計上。

　　如果各位看客有自己的想法或者經驗，非常歡迎暢所欲言，感激不盡！