坊间关于测试的一些认知，尤其是局外人对我们的看法，有一些颇具杀伤力。，我们重点聊一下关于软件测试的那些神话，给我们的玻璃心罩上一层保护膜。


　　看到这句话，测试团队是否充满了自豪感？确实，作为测试的一员，我们应该以此为目标：有我们在，质量可以得到保证。但是，绝大部分测试团队是没有这个魄力去做此承诺的；然而，客户对我们的期望往往比我们自己有信心的多啊。当一个原先没有测试的IT团队负责人向老板申请测试资源时，老板往往是这么认为的。
　　去年，我们所负责的一个测试项目上线后出了问题，客户方的老板不出意外地发出了怒吼：不是已经请了测试团队了么，花了那么多钱，为什么还是有问题？的确，由测试终把关却出现了问题，测试团队难辞其咎，这个锅是必须背的。只是老板们不会关心：业务关于需求的确认是有问题的；开发对代码管理的版本是不受控的，以致提交生产的部分代码不是测试后测过的版本；还有上线的时间点总是紧急而不可变更的但测试的资源和时间却是有限的。
　　指望有了测试，所有的质量问题会迎刃而解；这个多少有些一厢情愿。不过，从无到有引入测试，无疑是有帮助的；至少会多一层验证的“关卡”，让提交更有把握。哪怕是前面提到的场景，我们的团队还是在长达两年的时间里保障了系统在线上的稳定运行，并提前找出了数以千计的缺陷。
　　如同我们昨天文中所介绍的，引起软件质量的因素并非测试，有效的测试可以帮助发现缺陷进而寻找出问题所在，但是它不能从根本上解决问题。比较让人欣慰的是，上述案例中“事故”的后解决方式，还是各方一起协商，把流程和职责进行了梳理；算是一个很圆满的结局了。


自动化测试


　　这个说法再次把测试工作给神话了，我真心表示诚惶诚恐。它的意思和上一条类似，但是更加具象化了。
　　当然作为软件研发团队整体，零缺陷提交应该一直是我们的追求。只是当客户把这一条作为验收条款之一写进合作协议书的时候，我很难淡定了。
　　其实，关于如何证明测试有效、如何设定测试后的验收标准一直是个难题。而且我不止一次在客户的合同条款上，看到了“没有缺陷”这样的要求。面对这样的要求，我肯定是拒绝的。于是免不了会来来回回地沟通，终双方进行妥协。所幸的是，在这一点上大部分对于软件开发有概念的客户也都是有认知的，所以达成一个双方都能接受的一致条件并不算太难。比如我们一个客户对于系统的关键点的把握非常，也知道以项目的情况和时间表而言不可能达到零缺陷的程度，于是划了一个底线条件：所有记账的功能不能有缺陷。对此，我们除了说理解万岁外，真的不能赞同更多了。
　　事实上，我们很多时候都要对“测试通过”做一个定义，一般测试通过意味着符合了项目某些客观和主观的质量标准。但是考虑我们的测试理念之一：“缺陷一直在潜伏，因此测试工作永远都可以继续”，我们真的很难把“零缺陷”作为测试通过的条件。现实中，“测试通过”往往是基于风险的判断，是一个权衡的结果。而且，更加现实的情况是，在可控情况下，商业目标往往是高于测试的结论的。



　　看到这句话的时候，自动化工程师们（测试开发们）有没有热血沸腾？不过，我猜真正玩过自动化的团队们看到这一条，多半会觉得压力山大。自动化测试后取得的效果往往低于哪怕是保守的预期。
　　至少从我所经历的情形来看，自动化测试做成功的案例远远少于失败的案例；尽管大部分项目都号称成功了，但是以我的标准来看，大都没能达到预期的效果。这个结论多少有些让人沮丧。
　　去年，我们支持一个客户完成了自动化测试脚本的开发，而由于自身系统的频繁变更以及测试环境的混乱，客户后续投入了大量的精力在自动化脚本的维护和更新、测试环境的准备和恢复、处理各种运行时的异常上。于是，对于自动化测试从一开始的憧憬，变成了现在的怀疑，可以说是一个典型的例子。
　　今年初，我们和一个客户交流自动化测试。在听到我描述过几个成功案例取得的效果后，客户方分管测试的副总信心满满、跃跃欲试，开始规划他们的目标以及盘算会带来的成果。其中，提到了是否可以很快减少目前支持的测试人员。因为关系还算不错，我比较直白地泼了一下冷水：自动化测试在短期并不能减少多少人力（哪怕是手工测试的工作量），而且还得增加可靠的投入；只有把战线拉长到足够可观的时间，才有可能实现人力成本的缩减。这个时候，旁边负责自动化测试实施的经理则马上接过我的话，对我的观点表达了认同。好吧，她不敢直接对老板说的话，我替她说了。毕竟外来的和尚好念经啊~
　　自动化测试的决策本身远不是一个技术可行性分析，而更多是一个“投资回报”分析：在“合适的场景”下确实可以大幅提高测试效率，但是这样的效率也是以“高额”成本为前提的。做成一个自动化测试，需要有明智的场景和范围选择、需要有高额的投入、需要技术的正确选择、需要项目的高水平实施、还需要足够时间去等待“盈利”，可谓天时、地利、人和缺一不可。