測試總結-時間推移
測試背景
由於項目機制,用戶的操作數據以及後續數據都與時間相關,時間推移的決策就顯得非常重要.時間前移還是後移影響着整個測試流程.由於用戶的操作也隨時間影響,顯然時間往後推移是比較服務預期邏輯的.
測試目標
通過模擬時間推移,觀察用戶數據並校驗其正確性
測試方案
前置條件:測試代碼和db(docker)都是在測試宿主機上
在本次時間推移測試中,有兩種測試方案(前置條件:)
測試方案1: 修改系統時間
修改系統時間的方法可以參考[附錄1-修改系統時間]
優點:
- 這種方法是最直接的, 代碼中獲取的時間就是修改後的系統時間,db亦是如此.
缺點:
-
前置條件是需要關閉系統時間自動同步.
- 在沒有腳本的幫助下,每次需要在命令終端通過命令修改時間.
3. 在有隨着時間變化的業務情況下(比如,每日用戶數據情況),需要而外的腳本調用支持
- 在沒有腳本的幫助下,每次需要在命令終端通過命令修改時間.
適用場景推薦:
1. 比較適合觀察隨時間變化的業務數據,比如電站的單價,年化
2. 在會寫腳本的情況下,[缺點3]不再是問題,很大程度上可以提高測試效率
測試方案2: 修改業務代碼中獲取當前時間的方法
方案2需要將業務代碼中獲取當前時間相關代碼都通過一個工具類公有方法獲取(比如new Date(), System.currentTimeMillis()). 這裏以new Date() 獲取當前時間爲例.DateUtil中提供獲取當前Date數據接口
public static int dateAdd = 4; // 增加天數
public static Date getCurrentDate() {
Date date = new Date(); // 獲取系統時間
return addTimes(date, dateAdd, CalendarTimeType.DAY); // 系統時間往後加dateAdd天
}
優點:
- 方便大範圍時間推移
- 對於[有隨着時間變化的業務],能夠通過編寫代碼友好的支持
缺點:
- 該方法只能修改業務代碼運行時通過指定接口獲取到的時間(比如DateUtil.getCurrentDate())
- 對於db中自動時間不能友好的支持,除非業務代碼在執行響應sql語句時作爲參數傳過來.
適用場景:
在大規模時間推移的情況下,以及有隨着時間變化的業務情況下能夠友好的支持.
本次測試對於今後開發的幫助
在今後的開發過程中,在可預知有時間推移的情況下,我們可以將業務代碼中的關於時間的代碼建議參考方案2,以方便日後的時間推移測試.
附錄1: 修改系統時間(Ubuntu)
開啓/關閉系統時間同步
# 開啓時間同步
timedatectl set-ntp true
# 關閉時間同步
timedatectl set-ntp false
設置時間
# date 方式
date -s "2019-06-19 17:50:05"