夏令時(DST)測試

夏令時測試是比較小衆的測試，主要針對在有夏令時的國家使用的軟件，若是你接觸到了這方面的測試，說明你在掙國外的錢:).

 

話很少說，先來介紹下什麼是夏令時：

 

夏時制，夏時令（Daylight Saving Time：DST），又稱「日光節約時制」和「夏令時間」，是一種爲節約能源而人爲規定地方時間的制度，在這一制度實行期間所採用的統一時間稱爲「夏令時間」。

 

咱們所說的夏令時實際上包括兩類：夏令時和冬令時

• 夏令時(1:00 -> 3:00 AM)
  • 日後撥一個小時，直接從1點變到3點，也就是說咱們要比原來提早一個小時和美國佬開會。
• 冬令時(1:00 -> 1:00 -> 2:00 AM)
  • 往前撥一個小時，要過兩個1點，這時比日常晚一個小時。

 

從這兩種類型上看，咱們的測試重點是放在有時間相關的操做上（時間顯示、比較），以檢測系統是否可以正確地運行。

下面咱們來介紹夏令時測試須要關注的各個點：

 

• 白盒測試
  • 代碼走查以找出和時間操做相關的模塊，進行合理的時間轉換(本地時間轉換爲UTC時間）。這裏須要關注的是和時間有關的部分，若是模塊只和日期有關，能夠忽略。
  • 並非全部和時間有關的模塊都要轉換爲UTC時間，這由業務決定（好比說打印log和界面時間顯示，這時就須要用本地時間，而非UTC）

 

• UI 測試
  • 時間輸入：對於須要輸入起始時間的控件，在夏令時當天須要注意對輸入的檢查，好比夏令時當天沒有2：00AM。（對於冬令時，若是選擇1：00 AM表明的是第一個一點）
  • 時間顯示（輸出）: 產品時間的顯示規則是與本地時間一致。對於須要顯示時間段的部分，須要注意夏令時沒有2：00AM，冬令時包含第二個1：00AM
  • 報表展現：首先大部分報表的數據都來源於數據庫，而數據庫通常保存的是UTC時間，因此須要轉化成本地時間展現，這時在報表上可能出現的情況是：有些有起始時間的項的結束時間<開始時間，若是沒有特別的要求，這種報表結果是能夠接受的，可是要注意檢查時間轉換的準確性。

 

• 數據存儲
  • 文件的存儲：這裏分爲日誌和數據文件
    • 日誌文件須要用本地時間存儲，主要是問了方便查看。
    • 數據文件須要用UTC或者時間戳進行存儲，防止形成數據不許確。
  • 數據庫
    • 須要用UTC時間或者時間戳存儲。
    • 進行查詢操做，觀察是否返回正確結果
    • 在夏令時轉換點附近進行數據表的操做，檢查數據時間顯示(UTC或者時間戳）
    • 對於數據庫中須要按期定時執行的任務，須要格外注意在夏令時當天的執行時間。

 

• 功能性測試
  • 跨時間段任務
    • 經常會有一些任務會跨時間段，例如：一個Job計劃執行的時間是2：00AM，在夏令時當天由於沒有2：00AM，job會不會執行？或者是在冬令時的1：59AM執行，第二個1：00AM執行完畢，job會不會報錯？如下時間段是須要咱們在測試功能中須要特別關注的，以這些時間段做指導，執行用例，能夠覆蓋大部分場景。

                              

 

• • • 須要注意的點：
• 1. 1. 夏令時沒有2：00AM
     2. 任務消耗時間區間須要特別注意，若是一個任務1：50執行到3：10，其實只用了20分鐘，而不是1小時20分鐘
     3. 冬令時有兩個一點，預先計劃好的任務中說的1：00AM，指的都是第一個1：00AM
     4. 冬令時有圖中5中比較典型的時間段，須要特別注意。                                            

 

• 和其餘模塊的交互

 

• • 模塊之間的交互須要遵循一致的規則，最好都能用UTC或者時間戳進行傳輸
  • 若是其餘模塊未遵循規則，須要對時間的傳入和傳出進行轉換檢查                   

 

總結：

DST測試的關注點更多的是夏令時、冬令時當天時間轉換的處理邏輯，這就須要咱們定義出來哪些時間段是容易出問題的，而後結合咱們平時的用例，也會比較容易的把DST測試作好。