[原] 测试的核心技术

最近一直在想测试的事情。几年的摸爬滚打下来，混迹于游击队野战军和正规军的经历，越来越觉得测试的重要。不谈测试的理论，从具体的一个tester来看，什么是核心的技术？

 

我目前的结论是测试用例和自动化测试工具。

 

测试用例的设计从根本上决定了测试的质量。好的用例不但能反应需要，还能定义设计。从另外一个角度，也是检查系统模块化程度的标准。设计和编写优秀的测试用例，是团队的基石，是质量的验金石，是保证团队目标和信心的依据。而自动化测试工具，如果使用得当，可以成倍数甚至成指数的提高测试效率。Brooks在70年代就指出，优秀和熟练的程序员与普通程序员之间的生产效率能够达到10倍以上。而掌握自动化测试方法的tester，甚至可以自己写出自动化测试工具的tester，他比普通tester间的差距相信会更加大。

 

以上这两个，只是核心技术。要说核心因素，我想来想去，还是米卢老早就说过的态度问题。

 

我一直觉得，心态很重要。不同的心态做件事，结果可能大相径庭。测试如果抱着：我们的软件很稳定的乐观态度，一般都发现不了太多问题；一旦有问题爆出来，心理上又受到怎么我们的软件这么烂的打击。而如果tester每天很积极的想，我们的软件肯定很多bug，今天一定要找它几个出来。bug的产生率就想飞涨的房价一样...

 

这是我直观上的感受，而仔细想想，可以有下面的结论：

 

测试是质量的检测者，不是质量的控制者。测试往往因为检测出产品的过多缺陷而沮丧，实际上这应该是tester的骄傲，让对质量负责的人去沮丧吧。

开发人员不是测试者的敌人。有时候开发人员不像想的那样对质量那么关心，这时往往背后别有隐情。质量的提供需要团队的共同努力，这时应和开发更好的合作而不是积极的或消极的对立。当然这对开发的要求也是一样。

 

测试和开发分开，是社会分工细化的必然。但总有这样的负面效应：开发人员过度依赖测试人员。极端的情况就是代码写出来后直接扔给测试组。表面上看来开发人员省下了进行无聊的测试的时间，但我相信修改时隔几天后从测试组那扔回来的bug，要耗费这位逍遥了几天的开发人员更多的时间。更何况在bug踢来踢去过程中，这位开发人员能收获到什么样的名声呢？相比于将希望寄托在每个人的自我修养和职业素质上，我更喜欢用适当和恰当的制度来保证组织的健康性。就开发和测试的关系这一点，TDD（测试驱动开发）似乎是个好办法。