CoBOT在部署一年之后的经验分享

作者:胡婉莉

      在一年多的部署之中,我们也不可避免的遭遇一些问题。我们遇到的第一个问题是实验室和商业化的巨大不同。主要体现在一下几个方面:
    (1)首先,实验室中测试人员和测试的代码都较少,是几个人测几个工程。而在实际使用中,是很多测试人员测试更多的代码,很多在实验室中没有发现的问题在用户那里暴露出来。
    (2)在实验室中,测试者都是站在设计者的角度,而实际上的使用者往往完全不懂这个工具,也没有兴趣提出意见帮助改善,而且他们倾向于认为所有他们不懂的地方都是错的。所以在工具的开发过程中需要大量完全站在用户角度的测试人员,才能找出更多的问题。
    (3)实际上用户的操作系统和编译环境千奇百怪,是实验室无法完全涵盖的,需要不断改进自己的工具去适应他们。
    (4)用户对于速度有较高要求,在保证质量的情况下,要尽可能的快。        

      在不断解决问题的过程中,我们获得了许多经验之谈。

      一、你不能检测你看不到的代码
      这句话的意思是为了检测的更准确,工具需要能找到尽可能多的可执行代码。我们认为最可靠的得到更多代码的方式是获得构建过程的代码。看起来简单,但是很难知道一个临时的特定的构建系统干了什么,而且很多公司的电脑拒绝外部修改。
      我们最初的做法是对构建命令行的只读replay。run make, 在文件里记录输出,然后重写调用用户的编译器为调用自己的测试工具,然后rerunall。这种方法在lab里证实好用,但是遇到了一些问题。首先,许多公司不用make,而是用clearmake或者用UI界面。其次,这种方法可能会使系统出一些问题。
      为了解决这个问题,我们做出了改进。现在,它开始构建过程,然后截断所有系统调用。这样可以得到所有需要的信息,如调用的可执行文件、命令行、运行目录、编译器版本等。
      二、你不能检测你不能解析的代码
      找到代码之后的解析也不是一件容易的事。首先,编程语言相当抽象且标准难统一,编译器被认为是语言的标准。一段编译器能解析,而测试工具不能解析的代码会给顾客留下相当不好的印象。其次,编译器何其多,有各种版本,还有嵌入式的编译器,有些保密部门喜欢用特别老的版本的编译器,而且有些编译器还有错,比如会无故跳过很多文件,还有奇葩的汇编语言插入,这都增加了解析的难度。
      为此,我们使用了CDT来解析代码。把这个难题抛给了别人。这样我们只需要对每一个支持的编译器写一些转换器把个人的代码变成CDT可以解析的代码。但是也存在问题,首先CDT的版本需要常常更新,而且CDT的解析本身不够完美,有时我们遇到了解析上的问题,需要对CDT进行修改维护。

      三、一些和bug相关的经验
      1)不是所有人都关注bugs,开发者一般不会在意bug,如果没有经历后果。
      2)如果遇到checker的不清楚,一定不要和顾客争论,可以试着组织大的会议讨论结果,参加的人越多,总会有聪明的、关心bugs的人,而且还可以起宣传作用。
      3)解决bugs有时意味着更多的bugs,有时版本更新也会发现更多的bugs。
      4)漏报一般发现不了,但是一旦被发现了,就不太妙了。例如:有时用户会写一些小例子来测试工具,这些小例子往往是他们之前遇到过的,带来严重后果的。这时如果不能报出,用户就会质疑工具的质量,是不是什么都不报。
      5)有时解释清楚一个bug比发现bug更难,我们因此放弃了不少checker。
      6)误报不能简单以误报率来衡量,因为误报各不相同。一个低级的误报会使人认为整个工具都是低级的。
      商业化的道路最初总是崎岖难行的,但是我们一直在成长,不断汲取经验,我们的产品也一直在进步和完善。