夏令時(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測試做好。