上个礼拜,遇到一个问题:
给美国的客户做的软件,测试是在去年冬天,一切顺利。前段时间,测试人员突然报了一个BUG,说他们配置了一个时间参数,输入的值是2013-03-27 22:30:00,但是在运行过程中,软件显示确却是2013-03-27 23:30:00,整整快了一个小时。但是别的时间,比如2013-01-27 22:30:00,却没有问题。
当时想了想,立即觉得可能与夏令时有关系,于是赶把相关的函数调用单独拿出来测试了一下,果然如此。至于DST的概念,请大家自己去google吧。
这里的经验教训有如下两点:
1. 如果你的代码使用了mktime(struct tm * timeptr),并且你的代码可能会运行在DST可能实行的环境中,那么最好在你调用mktime之前将timeptr->tm_isdat设置为-1。
0: 不考虑DST时间;
1: 考虑DST时间;
-1: 操作系统根据当前系统设置决定是否使用DST时间;
给美国的客户做的软件,测试是在去年冬天,一切顺利。前段时间,测试人员突然报了一个BUG,说他们配置了一个时间参数,输入的值是2013-03-27 22:30:00,但是在运行过程中,软件显示确却是2013-03-27 23:30:00,整整快了一个小时。但是别的时间,比如2013-01-27 22:30:00,却没有问题。
当时想了想,立即觉得可能与夏令时有关系,于是赶把相关的函数调用单独拿出来测试了一下,果然如此。至于DST的概念,请大家自己去google吧。
这里的经验教训有如下两点:
1. 如果你的代码使用了mktime(struct tm * timeptr),并且你的代码可能会运行在DST可能实行的环境中,那么最好在你调用mktime之前将timeptr->tm_isdat设置为-1。
0: 不考虑DST时间;
1: 考虑DST时间;
-1: 操作系统根据当前系统设置决定是否使用DST时间;
2. 如果代码使用了当地时间进行逻辑调度,并且软件可能会运行在DST可能实行的环境中,那么一定要有相应的DST测试用例覆盖。因为这样的场景极有可能出现:软件测试在是在冬天,而客户是在夏天才开始使用软件的,一运行就发现如此刺眼的BUG,该多么扫兴啊。
====================