做实际的测试

  • Post author:
  • Post category:IT
  • Post comments:0评论

做实际的测试我经历过两种公司的风格,一种开发测试界限明显,多数时候测试给开发打下手,转测试之前开发围着测试转;第二种没有什么开发测试的分工,程序员从头干到尾,从需求分析干到处理线上问题。我不想在这里分析优劣,我想说的是,不论什么样的形式,项目阶段中测试的环节是很实际、很重要的。这也是被许多程序员低估的步骤。都在说设计,都在谈用户体验,但是测试呢?设计再精良的东西,如果满是bug,还是白搭。很多人都愿意写程序,不愿意做测试,多数人觉得单纯的测试比单纯的开发发展空间小多了。但是不可否认的是,测试这一项活动,从来都有着举足轻重的作用,不论是什么样的角色去完成。抛开那些冠冕堂皇的话,我总结了几个实际、好用,或者说土鳖,但是成本不高的测试方法。

写Main方法跑代码逻辑

我记得以前在一个项目组里面,我写的一些类,顺手写了main方法来完成开发阶段的初步验证,但是很快被一些有经验的工程师要求删掉。事实上直到今天,我也没有觉得那样有多么不妥。作为领导当然很愿意看到一个独立的测试代码包,大大小小的mock,批量执行起来齐刷刷的绿条。可是从实际的角度出发,这样的方式也有不少局限性。其中一条,就是不能和源代码放在足够近的位置。写起来远没有一个main方法来的便捷简明。有人在说可维护性,没错,可是大部分情况下测试代码能够同步更新的产品真是不多,再者写得好的main方法一样可以做到同步更新。很多情况下我们做出一些东西以后,代码就趋于稳定,在开发阶段写main方法快速阅读和获得结果反馈,是很有价值的。

Debug大法

以前我在讲Java多线程程序的测试的时候提到过它,看起来很土,但是在开发阶段跑通逻辑是非常有效的。本身测试用例的构造往往很耗费精力,但是在debug模式下可以任意执行、修改代码逻辑,改变变量取值。很容易遍历到希望的逻辑分支。Debug不是正儿八经的测试方法,同时被很多专业测试人员所不齿,他们还是更喜欢花大量的精力去构造各种奇葩的测试用例,条件组合。其实debug的好处远不止测试和问题定位,还可以帮助熟悉代码逻辑等等。

浏览器行为模拟工具

界面测试本来就不像后台代码那么容易完成。但是一些脚本工具,比如iMacros就很好用,可以很方便地录制和修改脚本,然后批量执行。很多情况下我们其实不需要天天喊多少自动化多少持续集成,对于完备稳定的脚本集合,就是手动跑一遍也很方便。这些80%的重复劳动其实很容易做,很容易就可以砍掉堆人的成本。以前用过一些公司级别的庞大的浏览器模拟测试工具,看起来很强大,但是却笨重而且容易出问题。

Apache Bench

我把AB这个工具单列一行是因为它用起来实在太方便了,特别是对于请求速率准确性要求不高的情形。我还把它用来当做性能测试的时候提供请求压力的工具。和Load Runner比起来,就像是游击队和正规军一样的区别。

用编译脚本偷梁换柱

对于一些独立的、清晰的远程调用的类,可以在编译打包的时候,用一个触发本地调用的mock类替换掉,相同的类、方法定义和路径,但是做的事情却大不相同。免去了那些复杂的mock技术,还把远程的调用放到本地来跟踪。

后门参数

这个东西用起来要小心,但是对于一些不容易重现、构建的环境中,如果预留一些后门参数,帮助清除缓存、收集信息、打印日志,或者是在发布以后短时间内在生产环境上主要功能的冒烟测试,是很有价值的。顺便提一提强大的BTrace工具,对于无法在本地或者beta环境中重现的线上问题,它是一把能够窥探代码执行的利器。

最后,我想说的是,对于不喜欢测试的工程师,这样的想法是可以理解的,但是必须通过约束自己的行为,保证各个阶段软件的质量。这是不可变的东西,我们可以做得更好、玩得更转的,也就是那些五花八门的测试技术,但是测试更需要责任心和周全的考虑,技术能帮忙简化测试上的问题,而没有态度则什么也做不成。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接《四火的唠叨》

分享到:
你可能也喜欢:

发表回复