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

夏令时(DST)测试

标签：

原文地址：http://www.cnblogs.com/AlwinXu/p/5467759.html