每次做测试架构师,就会面临测试工具的问题。尤其是在System Verification部门,他们的case是在仿真用户对产品的使用,产品的功能不断添加,但是用户的行为却是可遵循的,而且是复杂的,是各种行为的组合。不断地重复测试,似乎是在浪费测试人员的时间。在这种情况下,自动化测试工具就成为提高测试效率,解放测试人员的法宝。
 
  如何开发测试工具,有很多需要注意的地方。
 
  记得我刚去WiMax部门做测试架构师的时候,WiMax功能测试组需要软件组帮他们做一个截获正常报文,产生错误报文的工具。我和测试人员交流的时候,测试人员说这个工具很不好用。我再去询问软件人员,他们很惊讶。说已经完全按照需求实现了功能,该做的都做了,怎么就不肯用呢?我具体看了看他们的实现,发现基本功能确实都实现了,可是确实没办法用。测试人员不仅仅需要这个软件实现截获和修改报文的功能,更需要在实际的测试过程中灵活地使用它来实现整体的测试。软件人员没有做过测试,无法正确地理解测试人员的需要,再加上两个部门一个在15楼,一个在16楼,交流很不通畅,才造成彼此无法理解,做不出真正需要的东西。我和软件人员坐在一起,仔细地告诉他们我需要怎样来用这个工具,需要他们提供什么样的接口,测试人员该如何接入和管理这个软件,哪些配置要图形化,哪些配置要被自动化工具调用,需要什么样的输出,哪些状态实时显示,哪些数据需要统计,哪些log需要输出到统一的log文档中,等等。他们才恍然大悟,原来截获和修改报文只是很基本的需求,还有那么多事情要做。
 
  所以,开发测试工具,最理想的情况是找一个既精通开发,又精通测试的人来做。但这样的人比较难找。更普遍的办法是让软件人员和测试人员紧密合作,互相理解,才能够真正完成可用好用的产品。
 
  在我看来,一个好的自动化测试工具,需要注意以下特点:
  第一,必须将数据、配置和功能分开
  第二,尽量使用已有的稳定的公开库
  第三,使用cjava还是tclpython,各有利弊
  第四,封装基本功能,提供调用接口,用于测试人员的二次开发
  第五,尽量采用统一的可直接编辑的格式用于记录数据、配置和log
  第六,不要求大求全,也不要采用过于复杂和灵活的测试框架,要有针对性,简单为上
  第七,图形界面友好,符合测试人员的使用习惯
  第八,注重系统效率,要采用多进程以利用多核CPU
  第九,提供测试结果采集、统计和log分析页面
  第十,要考虑如何容纳已有的测试case
 
  我们曾经使用过Mobile Metrics的测试套件,据说这个公司只有9个人在开发和维护这个产品,但这个测试套件功能强大,比一般大公司100个人做出来的东西还要好,绝对是我们学习的楷模。这个套件是用cjava写的,底层调用和报文处理都是c,以提高系统性能。用户界面都是java,非常友好。提供了众多的接口调用,封装粒度合理,测试人员可以用非常简单的java语言实现非常复杂的测试行为,如入网、退网、handover等等。提供标准的java调用,让测试人员方便地使用其他标准功能,如产生随机数,条件语句,循环语句,网络连接,文件读写,报文分析等等。
 
  还有Spirent的自动化测试套件,这个套件在使用界面上非常友好,配置和执行测试都很方便。我们曾经仿照它的模式来管理自己的测试case。但它不够开放,要想在上面做2次开发不是很容易,需要请Spirent专门派人来协助和培训。Spirent的测试套都是用Tcl写的,我们觉得Tcl在开发大型测试软件的时候有点难度,出了错很难查错,开发环境不够友好,不如cjava方便。Python近几年发展比Tcl快,可以调用的库很多,开发环境也友好一些了。但TclPython的效率都要差一些。我们自己写的测试管理工具还兼容了原先大量使用的内部测试工具,可直接运行原来的case,只是将测试结果和log记录下来。这样就不需要重写了。
 
  我们曾经研究过泰克的测试工具。泰克的图形化做得是最面面俱到的,连设计一个测试流程,也只需要用鼠标拉来拉去,这样其实很限制灵活性,只能按照它所设定的模式来设计测试,二次开发很难。它的配置和数据也都是用自有的格式存储的,必须用它的工具来打开和修改。我个人不大喜欢这样的测试工具。
 
  我们公司内部也有一些自动化测试的工具,有些是自己开发的,有些是外包的。我也不大喜欢这些工具,因为功能很弱,图形化差,不灵活,也不能与时俱进。这些代码都是从头开始写的,比起外面那些开源代码和公开库,无论是质量还是数量,都差远了。
 
  顺便说说开发测试工具的流程。
 
  要开发一个测试工具,首先就是要了解测试人员的需求。需求包括测试功能本身的需求,和如何使用工具的需求。
 
  然后是定义模块和接口。模块包括功能模块和输入输出模块。功能模块由上及下逐步细分,分到多细取决于功能的复杂程度和接口的数量。每个模块要尽量独立,减少彼此的依赖。画几个数据流程图,看看需要哪些接口,接口参数如何定义。定义接口的时候要考虑到扩展性。当然,扩展性和简单化,有的时候要进行取舍。我们没必要面面俱到,但至少要考虑近期的扩展需求。查找已有的库函数,尽量减少自己开发的工作量,尽量采用一些标准做法。输入输出模块要和测试人员一起沟通,给测试人员尽量多的调用接口以实现复杂的测试行为。输入输出模块往往是一个测试工具成败的关键,这常常是软件人员容易忽视的。如果是性能测试工具,必须要考虑硬件的承受能力。如果能够做到分布运行,那当然是最好的了。
 
  测试工具的开发过程最好是和测试人员pair-work的,让测试人员不断地使用工具以获得反馈。测试人员是测试工具的用户,来自用户的声音永远是最重要的。自动化的程度是可以协商的,测试结果分析自动化往往是吃力不讨好的,自动化应该偏重于配置、执行和管理。出错处理是需要很小心的,尽量不要测试一出错就停止测试,这个要让测试人员来权衡。
 
  其实测试工具的开发和普通的软件开发没有太多的区别,这么蜻蜓点水一下,似乎没有多大的帮助。只是很多公司都在面临如何开发和使用自有测试工具的问题,我也顺嘴谈一谈。