从优到胜做测试

上次我们同时就投资方和工程师角度谈了如何把测试做得更好。这次则是怎样在商业竞争中发挥测试的作用。

测试的回报跟商业竞争有什么联系呢？如果只是从产品角度而言，谈不上太多联系，毕竟产品只是商业竞争中的其中一个因素。但是试想如果测试不限于发现产品的bug，而是再进一步，去发现项目的bug和团队的bug呢？

何谓项目的bug？一个项目的目标是要在给定的人力物力时间内生产预期质量的产品，如果一个项目最终没有达到预期目标，大多数情况下是由整个项目周期内产生的各种各样的问题所导致的。这些问题或许在项目最后阶段才暴露，但是通常是较早的时候就埋伏下来的。听上去很像对bug的描述吧？所以，你可以把它称作项目的bug。

l 举个例子，测试用例如果覆盖的范围不够，——这一点通常不容易直观的发现，产品的一些部分或许从头到尾就没有运行或者验证过。这样有些产品上的bug就找不到了，运气不好的话就可以出现很严重的bug。所以，测试用例覆盖不够，这就是一种项目的bug，它呈现了项目运行中没有保证产品具备足够测试覆盖的缺陷。

l 另一个例子，一些测试用例这段时间能通过，那段时间就通不过，也就是不够稳定。这种情况要么是因为产品不够稳定，要么是因为测试用例设计得不合理，如果是自动化的测试用例，则尤其容易是因为测试代码不够稳定。不管怎样，到底产品有没有bug呢？这可不知道了，于是开发人员和测试人员容易在上面扯皮、吵架、不了了之，然后发布之后再暴露出来。所以，测试用例不能稳定的通过，也是一种项目的bug，它呈现了项目运行中没有充分了解测试用例失败根源的缺陷。

那何谓团队的bug呢？一个人的精力和工作效率是有限的，如果团队成员花在无效工作上的时间比较多，相应的花在有效工作上的时间就较少。同时如果团队成员感觉到自己花了较多时间在无效工作上，因为心理的因素，他/她的精力和工作效率就会降低。这些问题会导致团队生产效率下降，长时间的积累会导致士气下降以及人员流失。对一个追求长期及稳定业绩的公司来说，这可不是个好事。这些问题也是较早的时候埋伏，后来才暴露，所以，你可以把他们称作团队的bug。

l 举个例子，等待编译或者“路障测试”（参见上一篇“从有到优做测试”）的时间很长。为了把代码提交到代码库，这样的工作是无可厚非的质量保障。但是如果需要的时间很长，例如一个程序员花了一个小时写代码，等待一次提交所需的编译检查或者“路障测试”花了三个小时，如果他/她的进度压力很大，他/她就倾向于花六个小时写六倍的代码，然后提交，下班，第二天早上再看看有没有出问题。这样做的结果是，要么因为短时间写了过多的代码，质量非常差，一次又一次的通不过编译检查或者“路障测试”；要么因为六倍的代码需要十倍的小心，为保证质量工作强度过大或者工作时间过长，程序员心力交瘁或者失去热情。可见在这个例子里，团队成员无意识地把时间花在不必要的过多代码的质量保证上。问题是，很少人想到根本原因是等待时间，员工认为老板逼着加班，老板认为员工技术水平不够。试想如果只需十分钟的等待，还会有人一天只提交一次总共数千行的代码，只因为受不了等十分钟吗？

l 另一个例子，修复bug的阶段，有可能代码的改动速度非常快，产品内部版本的变动也很快，例如一天一次，回归测试一次的时间却非常长，例如一个星期。那么这个星期一开始的回归测试，得到报告已经是下个星期一了。如果这里面发现了一个bug，开发人员该在哪个版本上debug呢？上个星期一的吗？就算知道根源在哪又该如何修复呢？代码都改得天翻地覆了，而且好像该修复的地方也改过了，所以只好说，再做一次回归测试看看能不能重现吧。但是改得这么快，bug是很容易一会儿能重现一会儿又不能重现的。于是，几乎每个找到的bug都不了了之，每次debug都不了了之，自然开发和测试团队会扯皮吵架。这样能不泄气吗？开发和测试团队的关系能好吗？他们还可能合作改善产品质量吗？

这两种bug对软件企业项目团队的杀伤力在于，要么问题不容易发现，要么是项目情况逐渐变化，导致“每一步变化都好像没问题，量变却引起质变”，等到后果出现时，就好比产品已经发布，缺陷已经造成恶果了。而且造成的恶果往往被解释为领导和员工关系、部门之间关系的缘故，这样团队成员走马灯的换，结果却没多大变化。

这样就跟商业竞争有关系啦？关系大着呢！软件企业最重要的资产是什么？大楼？电脑？数据中心？都不是，是团队，是人力资源。如果软件企业的团队生产力被损害了，还能指望在商业竞争中胜出吗？现在明摆着一系列杀伤团队的bug，测试团队上去预防、发现和修复这些bug，这是不是商业竞争的重要组成部分？

那么一个测试团队该如何发现这两种bug呢？测试不外乎产生输入、检验输出。现在团队作为一个有机整体，无时无刻不在接受外界的各种输入：需求、任务、计划、进度……所以，收集输出并作出分析，就是最重要的手段，学术上称为“衡量”（Metrics）。注意，大量书籍文章谈论的是软件度量（Software Measurement或者Software Metrics），这里说的是对项目和团队本身作为一个系统的衡量。在上述的例子中，测试团队可以衡量测试覆盖率、测试结果稳定性、代码提交验证过程耗时、平均代码提交频率、提交验证失败率、回归测试耗时、修复阶段代码提交速度（例如千代码行/天）、修复bug的平均时间等等，目的在于发现项目和团队在工程活动中各个影响因素是否产生了不利于项目和团队长期和稳定业绩的后果。

一个测试团队要高质量的做到这一点，需要相应的理论知识。这正是当前测试业界所忽视的一个领域：系统工程（System Engineering）。系统工程关注作为整体的系统各部分及其相互影响的关系。显然，计算机专业教授这门课的不太多，自然难以期望测试团队普遍具备这方面的理论知识。正因为如此，谁占领了这个制高点，谁就更能成为软件企业中的关键因素。