听他这么一说，我当场就愣住了，不过因为初到公司，见上司都没反应，我自然也就忍了。我列举了一些证据，说明这
应该是模块里面的问题，他根本就不听，只是不断重复地表示这不可能是他程序的问题，而是我们QA的人太蠢了，总是
在浪费他的时间。过了一会儿，他终于闭上了嘴巴，又过了一会儿，他才对我说：“等会儿重新发个版本给你吧。”后
来又请他过来四五次，结果每次都是他的问题。
之后我再没有听到他说过“你们QA的人太蠢了”这样的话。为了避免让他抓到把柄来嘲笑测试组，我决定在请他来查问题之前做更详细的测试。当时我写的测试程序和现在初学者写的测试程序没有两样，都是从教科书上学来的，先通
过scanf从终端输入数据，调用被测函数，再把结果printf出来，这花了我太多时间。一想到后面还有50多个模块的测试
程序要写，我知道这样下去肯定不行，一定得想个更好的办法。
后来我把输入的数据和期望的结果都写到一个INI文件中，测试程序从这个文件中读入数据，运行测试，再将输入与
预期结果相比较，整个过程都自动化了。写INI文件的解析器花了我一周时间，后来又重写了那个测试程序，结果是完成RDFParser的测试程序花了我整整一个月的时间。进度上自然是大大落后了，还好上司知道事情的来龙去脉后并没有责备
我，只是让我慢慢做就好了。
写第二个测试程序时把INI解析器的代码复制过去，再加一些调用模块的代码就算写好了，第三个也是如此。写了几
个之后，我发现了INI解析器有个bug，结果就是我不得不去修改每个测试程序，我意识到之前那样做会让维护工作很麻烦，于是把INI解析器的接口规范化了，并编译成一个独立共享库。之后，我又写了几个测试程序，写着写着就觉得不耐
烦了，因为这些测试程序无非都是读入数据，调用被测函数，再检查结果，这个过程就是个很机械化的过程，实在是太
无聊了。想到后面还要把这个机械的过程再重复个几十遍，我很是郁闷。不过在郁闷了几天之后，我突然灵机一动，决
定写一个代码生成器来自动生成这些代码。开始的代码生成器是用C写的，用一个简单的规则来描述被测函数，通过这些
规则来产生测试程序。我把这些东西和INI解析器放在一个独立的库中，就成了一个TesterFrameWork，经过几个测试程
序的验证和完善，后来利用这个TesterFrameWork，只要一两个小时就能完成一个测试程序了。有次请开发人员中的一个
阅读(279) | 评论(0) | 转发(0) |
