夏令时(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测试作好。