測試很多時候需要準備測試資料,例如基礎資料,配置資料,現有資料,動態資料等;那麼如何準備資料,如何做到真實可靠有效?
一、測試資料的分類
現有資料:比如在測試一些電商站點的時候會提前插入一些商品資訊,種類資訊物流資訊等;
動態資料:比如在測試電商站點的發布商品功能的時候,往往會去建立一些新的商品。
我們可以想象到,基礎資料其實可以比較容易的跟生產環境保持一致。測試環境的存量資料會比線上環境要少,測試環境的動態資料可能不會像線上環境那樣真實。
這裡就需要討論測試資料的量級和真實性的問題了。
二、測試資料的量級
大部分情況下,測試資料的量級是沒有產生環境多的。所以測試資料可以是真實資料的子集。
如果有類生產環境或預發布環境的話,可以盡量保持跟線上資料相當的量級。這樣一些測試環境不好測出來的由於資料量導致的問題可以在預發布環境測出來。
三、測試資料的真實性
我們測試環境的資料往往跟真實使用者產生的資料是有差異的。比如測試論壇系統時,我們在帖子裡的貼圖可能往往就那麼幾張,尺寸也是恰到好處,而線上使用者的貼圖可能是五花八門,從而導致意想不到的問題。
四、如何準備基礎和存量資料
基礎和存量資料與線上環境越一致,測試中發現問題的概率可能就越高。一般來說,可以有下面的策略
1、全量+脫敏策略:直接定期把線上的資料做脫敏,匯入到測試環境。這裡脫敏是必選,資料洩漏導致的問題嚴重程度往往比普通的線上bug要嚴重得多。
3、爬蟲策略:如果是新專案/產品的話,線上沒有存量資料可以導,那麼可能要去友商那裡爬一些資料,導到測環境做測試。比如做乙個旅遊站點,開始的時候是沒有使用者的遊記的,這時候就要去類似站點爬一點來測試了。
4、生成動態資料:如果線上沒有資料,友商也沒有的爬,那麼就要人肉或者自動化的方式去產生一些資料了。系統簡單的話可以用sql去跑,複雜點的話可能要呼叫介面或者用自動化的方式去生成。實在沒轍的時候也可以手動去造一些資料。
五、關於動態資料
大家在做自動化或者介面測試後往往會大量的去產生動態資料。那麼問題就來了。
這些資料存在**?什麼意思呢?如果我們需要用自動化的方式去建立乙個商品,那麼商品的資訊,位址該放在**呢?其實這是個持久化的問題了。
2、放資料庫裡:爬一些商品的資訊存到資料庫裡,然後讀資料庫也是很好的辦法,還能熟悉一下sql的用法,面試經常問到,另外可以用資料庫的事務機制來清理測試資料
3、在**裡動態生成:比如動態隨機生成使用者的姓名啊性別和年齡之類的。
資料生成之後就面臨著乙個清理的問題。清理問題實際上資料生命週期的問題,測試資料應該有下面一些生命週期吧
1、短期資料:用例完了就刪掉的資料,一般線上做效能測試的資料都是這樣的短期資料。
2、長期資料:用例跑出來的資料放在那裡也沒事,可以一直存在。這種資料太多有時候會影響測試環境的效能。
自動化測試跑出的資料建議做短期資料,跑出來想辦法清掉,因為自動化跑的頻率其實可以很高,每次都產生一堆資料的話資料的量級可能會在短期變得很大,對測試環境的效能造成影響。
準備測試資料
在我過去參與的專案中,準備測試資料的方法各種各樣。在給一些大型企業做諮詢時,建議他們的開發團隊使用單元測試或者 api 測試來守護 他們在編寫測試的過程中遇到的第乙個困難就是測試資料的準備。測試資料的準備往往會遇到幾個問題 這幾個問題都沒有唯一答案,下面就聊一下我在專案中採用過的方案,以及推薦比較好...
效能測試資料準備
方法一 編寫儲存過程,用 sql指令碼方式,插入測試資料 這個方式有幾個前提條件 1 需要對該業務下所有關聯的表結構非常熟悉 2 需要對 整個業務也非常熟悉 這時需要開發協助編寫測試指令碼或者向他們學習業務和關聯的表結構,自己編寫指令碼 但是資訊 不全的情況,需要不斷嘗試,不斷除錯才能夠準備出符合要...
MySQL 準備測試資料 日期時間
函式描述 now 返回當前的日期和時間,格式 2020 11 11 11 11 11 curdate 返回當前的日期,格式 2020 11 11 curtime 返回當前的時間,格式 11 11 11 date 提取日期或日期 時間表示式的日期部分,date now 2020 11 11 extra...