做实际的测试

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

写 Main 方法跑代码逻辑

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

Debug 大法

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

浏览器行为模拟工具

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

Apache Bench

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

用编译脚本偷梁换柱

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

后门参数

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

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

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