自動化測試中，測試數據如何管理？

今晚在某個測試羣，看到有人問了一個問題：把測試數據放配置文件讀取和放文件經過函數調用讀取有什麼區別？

當時我下意識的這麼回答：數據量越大，配置文件越臃腫，放在專門的數據文件（好比excel，csv），方便針對性的維護。

乍看沒毛病，但回頭和人討論這個問題的時候，就認真思考了一下這個問題，下面是個人一些思考和討論的一些結果，僅供參考。。。

 

自動化測試過程當中，如今大多都默認測試腳本與測試數據分離的設計，這樣作的好處是：下降維護成本，遷移成本以及提升效率。

所以測試數據放在哪裏，如何管理，不能一律而論。我的以爲應該從如下幾方面來考慮：

一、業務場景

①、好比在UI自動化測試中，須要測試某個電商網站的各個業務模塊，但前提是要用戶登陸。這個用來執行登陸的測試帳號數據每每是固定的，那麼專門將

　　一組username和password放在一個測試數據文件或者測試數據庫中，這樣就顯得太笨重，耗時費力。將其寫入測試腳本或者寫入配置文件，直接引用效率會更高。

②、一樣，測試電商網站，帳號體系分爲普通帳號，會員帳號，會員還分不少等級，有時候爲了測試會員中心不一樣的帳號展現的信息是否不一樣，就須要使用不一樣的

　　等級的帳號登陸，這種場景下，能夠將測試數據放在測試文件裏（好比excel、csv），經過參數化的方式來循環讀取，執行後續操做。

③、在API自動化測試中，好比針對restful風格的接口，它的域名相對來講都是固定的，只是不一樣接口的path不一樣，那麼也能夠將域名寫入配置文件，

　　測試過程當中只須要將實例化的域名和path進行拼接便可，這樣也省卻了在測試數據文件中維護的成本，必定程度上提高了測試效率。

 

二、數據類型

測試數據也分不一樣類型，大概分爲如下幾種類型：

base-data：即基礎數據，好比電商網站的商品信息、SKU，好比物流公司的倉儲管理等，這類數據每每基數比較大，能夠視爲持久層，儲存在DB中；

test-data：測試數據，根據業務場景不一樣，數據不管量級仍是變動頻次也不一樣，基於測試腳本與數據分離的概念，可放在專門的測試文件中，好比excel、csv；

ephemeral-data：臨時數據，即便用一次的數據，這種類型的數據能夠用臨時文件存儲（好比dat、csv等）格式，而後進行參數化讀取，或者直接寫入腳本中；

 

三、數據量級

①、仍是電商網站的某個場景，須要先執行登陸，登陸的帳號好比是專門配置的一個測試帳號，相對固定，那麼將測試帳號寫入測試腳本也無可厚非。

　　不過我本人不喜歡將測試數據直接寫入腳本，這種狀況我會寫入配置文件，而後實例化調用，這種狀況就須要根據我的習慣來設計，沒有固定的套路；

②、數據量級在幾十——幾百上千之間，這種時候，能夠寫入excel文件進行存儲管理，可是excel的侷限在於其自己目前最大支持65500+行的數據存儲，

　　並且只支持單事務，若是須要多線程讀取，就會變成瓶頸。

③、csv文件，結構簡單、通用，能夠和excel進行轉換，能夠減小存儲文件size，且具有簡單的安全性，能夠在必定程度上替代excel成爲數據存儲文件。

　　我本人目前在大多數場景下也是使用csv類型的文件進行測試數據存儲管理；

④、當測試數據超過必定量級，好比性能測試中，若是要執行併發測試或者穩定性測試，那麼所需測試數據量級就很大，這時使用excel或者csv就會變得很不方便。

　　不管是從維護的成本仍是便捷性考慮，都應該選擇利用DB或其餘高效的管理方式來存儲和管理測試數據；

 

四、使用頻次

測試數據的重用頻次不一樣，也須要選擇不一樣的存儲方式，好比：

①、once：只使用一次的測試數據，那麼只須要寫入臨時文件，用完做廢或者刪除便可；

②、often：即常用的測試數據，應根據數據量級，使用場景，數據類型選擇合適的存儲管理方式；

③、alway：能夠理解爲base-data或者持久數據，這種類型的數據由於其自己更新頻次很低，或者數據量級較大，通常存儲在DB中是比較好的一種管理方案。

 

綜上所述，測試數據的存儲和管理，沒有固定的套路，須要結合業務場景，使用頻次，數據類型和數據量級來綜合考慮，設計合理高效的方案，纔是正確的方式！

內容僅供參考，若有更好的建議，但願評論提出，謝謝。。。