1. 程式人生 > >自動化測試如何準備測試資料

自動化測試如何準備測試資料

其實大部分型別的測試都需要去準備測試資料。

  • 手工測試:一些基礎資料,比如配置資料等等是需要去準備的;
  • 自動化測試:基礎需要準備,現有資料,動態執行時產生的資料是需要準備的;
  • 效能測試:跟自動化測試差不多;

這裡就牽扯到了一些關於資料的概念了。

測試資料的分類

我們可以給測試資料分一些種類

  • 基礎資料,比如一些內容管理系統會配置站點的標題,友情連結之類的基礎配置資料
  • 存量資料,也就是現有資料。比如在測試一些電商站點的時候會提前插入一些商品資訊,類目資訊物流資訊等
  • 動態資料,也可以叫做session資料。比如在測試電商站點的釋出商品功能的時候,往往會去建立一些新的商品

我們可以想象到,基礎資料其實可以比較容易的跟生產環境保持一致。測試環境的存量資料會比線上環境要少,測試環境的動態資料可能不會像線上環境那樣真實。

這裡就需要討論測試資料的量級和真實性的問題了。

測試資料的量級

大部分情況下,測試資料的量級是沒有產生環境多的。所以測試資料可以是真實資料的子集。

如果有類生產環境或預釋出環境的話,可以儘量保持跟線上資料相當的量級。這樣一些測試環境不好測出來的由於資料量導致的問題可以在預釋出環境測出來。

測試資料的真實性

我們測試環境的資料往往跟真實使用者產生的資料是有差異的。比如測試論壇系統時,我們在帖子裡的貼圖可能往往就那麼幾張,尺寸也是恰到好處,而線上使用者的貼圖可能是五花八門,從而導致意想不到的問題。

如何準備基礎和存量資料

基礎和存量資料與線上環境越一致,測試中發現問題的概率可能就越高。一般來說,可以有下面的策略

  • 全量+脫敏策略。直接定期把線上的資料做脫敏,匯入到測試環境。這裡脫敏是必選,資料洩漏導致的問題嚴重程度往往比普通的線上bug要嚴重得多。
  • 定量+脫敏策略。只上一些線上資料,比如只在線上拉1000個商品,1000個使用者資訊,然後做脫敏。這裡技術實現難度會比較高,畢竟要把關聯表理順。
  • 爬蟲策略。如果是新專案/產品的話,線上沒有存量資料可以導,那麼可能要去友商那裡爬一些資料,導到測環境做測試。比如做一個旅遊站點,開始的時候是沒有使用者的遊記的,這時候就要去類似站點爬一點來測試了。
  • 生成動態資料。如果線上沒有資料,友商也沒有的爬,那麼就要人肉或者自動化的方式去產生一些資料了。系統簡單的話可以用sql去跑,複雜點的話可能要呼叫介面或者用自動化的方式去生成。實在沒轍的時候也可以手動去造一些資料。

關於動態資料

大家在做自動化或者介面測試後往往會大量的去產生動態資料。那麼問題就來了。

這些資料存在哪裡?什麼意思呢?如果我們需要用自動化的方式去建立一個商品,那麼商品的資訊,圖片地址該放在哪裡呢?其實這是個持久化的問題了。

  • 放檔案裡。檔案格式有很多可以選的,比如xml/csv/json/yaml等。不過不推薦excel,畢竟是私有格式,沒有太強的擴充套件性。而且excel一升級,你的解析程式碼和庫也可能要跟著改一次,嗯,強烈不推薦了。
  • 放資料庫裡。爬一些商品的資訊存到資料庫裡,然後讀資料庫也是很好的辦法,還能熟悉一下sql的用法,面試經常問到,另外可以用資料庫的事務機制來清理測試資料
  • 在程式碼裡動態生成。比如動態隨機生成使用者的姓名啊性別和年齡之類的

資料生成之後就面臨著一個清理的問題。清理問題實際上資料生命週期的問題,測試資料應該有下面一些生命週期吧

  • 短期資料。用例完了就刪掉的資料,一般線上做效能測試的資料都是這樣的短期資料
  • 長期資料。用例跑出來的資料放在那裡也沒事,可以一直存在。這種資料太多有時候會影響測試環境的效能

自動化測試跑出的資料建議做短期資料,跑出來想辦法清掉,因為自動化跑的頻率其實可以很高,每次都產生一堆資料的話資料的量級可能會在短期變得很大,對測試環境的效能造成影響。

以上的一些看法是個人的淺顯的粗鄙的看法,肯定有很多不成熟的地方,歡迎大家斧正。