ClearQuest缺陷之当前时间

      Date_Time类型字段记录Entity关于时间方面的信息，是一种必不可少的类型，然而，Date_Time类型字段若不谨慎设计，有时候会带来意想不到的Bug。下面说一下我所遇到的Bug。

 

      Schema中主Entity叫Issue，Issue有一个Date_Time类型的字段叫submitDate，用于记录提交Issue的时间。我们有一条业务规则是Issue必须在某个截止时间之前一周提交，如果小于一周则必须使用下一个截止时间。Schema上线后部门主管找我们说这条规则没有正确实现，因为发现了提交时间距截止时间小于一周的Issue。然而测试表明无法提交这样的Issue，出现这样的Issue令我们百思不得其解。后来，经过与用户的交流，原因才真相大白。最初我们的Schema是这样设计的，在defaultValue hook中确定submitDate的Value，在submit action的validation hook中验证submitDate的value。这样设计看起来似乎没有什么问题，然而有些用户创建好Issue后并不马上提交，甚至会等到第二天再提交，这样问题就出来了，对于这些迟迟没有提交的Issue，validation hook验证submitDate的Value时submitDate的值与当前时间相比已过去了相当长的时间，这就造成了不符合规则的Issue的出现。找到原因后修改了Schema才修正了这个Bug。

 

      像刚才这种Bug只是Schema设计者的问题，有经验后就不会再犯了。然而，由CQ没有提供获取当前时间的API而造成的Bug很难通过Schema修复。下面我再说一个所经历的比较离奇的Bug。

 

      有一个脚本负责将CQ中Issue的改动同步到另外一个系统，后来发现经常遗漏数据，即某些改动没有被同步。我们的设计是这样，脚本每十分钟运行一次，将上次同步之后发生的改动同步到另外一个系统，同步的依据是Issue的ChangeLog中记录的时间。检查脚本的Log发现，遗漏的改动没有出现在查询结果中，而重新运行Log记录的查询却能找到这些遗漏的ChangeLog。这种匪夷所思的现象令我们非常困惑，难道用脚本运行查询与我们手动运行查询会不一样么？直觉与随后的验证都告诉我们这种猜想不正确。重新审查脚本，没有找到任何错误。然而遗漏数据的现象还是接二连三的出现，万般无奈下只好再写一个核对脚本，一旦发现遗漏就手动补齐。后来在一个偶然的机会才找到原因，当时正在测验另外一套系统，无意间发现有一笔Issue的ChangeLog非常奇怪，即ChangeLog中记录的时间与ChangeLog生成的顺序不一致，后生成的ChangeLog记录的时间反而早于先生成的ChangeLog。这个奇怪的现象令我立即想到了同步脚本所遇到的麻烦，经过推理验证后确定原因就在这里。由于CQ没有提供获取当前时间的API，我们只好用perl脚本获取，而这个时间是运行CQ的服务器上的时间，并不能保证就是标准时间。我们的CQ运行在多台服务器上，这些服务器中恰好有一台的时间比其他服务器慢五分钟，这就导致了遗漏数据的发生。确定原因后让IT修正了时间，Bug就解决了，然而我们却不敢撤掉核对脚本，因为不敢保证今后服务器的时间不会再发生异常。

 

      其实产生这个Bug最根本的原因是CQ没有提供获取当前时间的API，这项缺失还为某些员工提供了弄虚作假的可能性，而且很难阻止与检测。QA部门对于同一条Bug最先提出的Issue纳入绩效考核，但其余的不予考虑，所以QA部门内的同事都积极争取Bug的第一提交权。问题是Issue的提交时间记录在submitDate这个字段，无论如何设计Schema无法保证这个字段的时间记录的就是标准时间。如果不幸某个同事了解到这种缺陷，那他就可以通过调整机器上的时间欺上瞒下，即把自己机器的时间往前调，这样他即使不是第一个提交的Issue，然而根据Issue的submitDate计算他仍是最先提交的。这个Bug也不是没有办法解决，但一是没有发现有人这样做，二是解决这个Bug有点得不偿失，所以一直随之任之。

 

      为了减少Schema设计者的麻烦，IBM的Rational团队应该给ClearQuest增加一个获取当前时间的API，否则这种麻烦会继续困扰着CQ的开发维护人员。