夏令时测试是比较小众的测试，主要针对在有夏令时的国家使用的软件，如果你接触到了这方面的测试，说明你在挣国外的钱:).
话不多说，先来介绍下什么是夏令时：
夏时制，夏时令（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会不会报错？以下时间段是需要我们在测试功能中需要特别关注的，以这些时间段作指导，执行用例，可以覆盖大部分场景。
- 跨时间段任务
- 需要注意的点：
- 夏令时没有2：00AM
- 任务消耗时间区间需要特别注意，如果一个任务1：50执行到3：10，其实只用了20分钟，而不是1小时20分钟
- 冬令时有两个一点，预先计划好的任务中说的1：00AM，指的都是第一个1：00AM
- 冬令时有图中5中比较典型的时间段，需要特别注意。
- 和其他模块的交互
- 模块之间的交互需要遵循一致的规则，最好都能用UTC或者时间戳进行传输
- 如果其他模块未遵循规则，需要对时间的传入和传出进行转换检查
总结：
DST测试的关注点更多的是夏令时、冬令时当天时间转换的处理逻辑，这就需要我们定义出来哪些时间段是容易出问题的，然后结合我们平时的用例，也会比较容易的把DST测试做好。