无论是公司领导还是测试人员本身，现在普遍存在一个错误的直觉，是认为测试比开发简单，上手快，技术和经验要求低。很多公司将测试人员的工资开的比开发人员低，职业路线也没有开发人员宽广。测试人员自己也常常认为，做测试是敲命令，取log，把所有的难题都交给开发人员，不认为自己对软件的质量提高也有责任，对自己的要求也很低。我也有一些同事认为，开发人员和架构师可以插手和质疑测试过程，可是测试人员不应该插手和质疑软件的设计和需求分析，测试人员应该只管好测试OK了。

　　其实，这样的想法，对企业自身的发展是很不利的。要知道，一个产品的质量取决于这个产品链上薄弱的环节。设计开发和测试是对等的，设计强而测试弱，产品的质量一样上不去。

　　软件是不可能不出错的。记得以前看过一本书，有个原来做硬件开发的人后来转去做软件。他写的代码一个错误也没有，大家都很奇怪，去问他是怎么做到的。他更奇怪地反问大家，啊？难道可以出错吗？他原先是做硬件的，硬件对bug是很难容忍的，所以要求处处小心，严格把关。可是软件不同了，软件的bug似乎是与生俱来的，原因有很多。软件的应用发展很快，升级换代也快；软件结构复杂，层次丰富，接口众多；软件开发人员门槛较低，素质参差不齐；人们对软件bug的容忍度较高，等等。我们已经无法期望软件零缺陷。尽管敏捷的鼓吹者曾经宣称过敏捷环境可以避免传统软件开发带来的问题，但事实证明他们只是在吹牛而已。

　　软件的质量在多大程度上依赖测试人员，取决于测试人员的素质和管理者对测试的理解。

　　我比较欣赏米国的企业，把测试人员叫做QA，是质量保证人员。这是在告诉测试人员，他们不仅仅要执行测试，而且要参与一切和产品质量有关的活动，是对产品质量负责的人。这样，测试人员的责任和重要程度会大大提升。

　　为什么呢？我们首先来看，软件的错误有哪些？

　　软件从需求分析开始，会引入错误。而且越是前期的错误，造成的损失越大。需求分析，是将用户的需求转化成产品的需求。这是系统架构师需要做的事情。系统架构师需要明确这个产品该如何来满足用户的需求，有哪些use case，这些use case直接关系到V-mode中对应着的系统测试的test case。系统架构师需要来自系统测试人员的反馈，来判断这个case的可测性和可用性。用户是否真的需要这些case，系统测试人员往往会给出他们的意见。Use case的偏差，直接会导致用户的不满，而且有可能导致整个feature的失败。我们有过不少这样的经历，是系统架构师在需求阶段容易求大求全，在系统的复杂性和新功能对系统的影响上，在客户如何使用新feature上没有经验，在开发和测试阶段，麻烦不断，导致整个feature无法按期完成，后不了了之，所有的努力都付之东流。系统测试人员在需求阶段加入，可以从用户的角度给架构师以反馈，告诉他什么功能是用户需要的，什么功能是可有可无的，用户关注的点在哪里。这样，架构师可以有所取舍，将能满足用户，且易实现和测试的部分规划出来，进行优化，舍弃那些对用户来说可有可无，却占到大量开发和测试时间的部分。一个公司的架构师往往是从软件开发人员培养而来，他们过多地重视开发成本，而忽视测试成本，也忽视用户的使用感受。记得有一个产品经理曾经告诉我，他们很难获得用户的真实感受，因为和用户开会的时间非常有限，一两个小时的会议，要讨论几十个新feature，每个feature只能占用5分钟，很难在这5分钟里问清所有的问题，只能靠猜。其实，比猜更有效的方法，是培养的系统测试人员。他们不但熟悉测试，也能通过验证用户报的bug了解用户对feature的使用，也能够体会用户的感受。让系统测试人员参与需求分析过程，避免系统架构师出现大的偏差，帮助系统架构师预测用户对新feature的使用方式，是对产品质量提升的一个很重要的手段。

　　然后是软件实现引入的错误。软件实现包括软件设计思想，软件架构和代码开发。对应的是功能测试。有些人认为，功能测试应该是黑盒测试，只关注需求，不应该了解软件的实现。我觉得这句话的意思是，不应该受软件实现的困扰。但是，知己知彼，百战不殆，这句话总是对的。有的时候，了解软件的设计思想，可以预见软件实现是否满足了需求，可以避免毫无意义的测试，浪费宝贵的时间。比如说，我们曾经有一个接口双备份的feature，设计思想非常糟糕，逻辑混乱，只要看了设计文档，已经很清楚测试的结果了。根本没有必要再去执行测试。正确的行为应该是“发回重审”，让软件架构师重新考虑设计方法。可我们还是执行了测试，发现了很多问题，然后是开发人员修改bug，结果越改越乱，后连开发人员自己都不知道什么才是正确的行为。这个feature浪费了大家很多时间。还有一个IP QoS的例子，在了解软件人员的解决方案之后，我们已经知道测试的结果了。我们认为这不能满足用户的需求，可是还是经过了测试，报错，改错的过程，也并没有达到一个好的结果。软件设计是否满足需求，这是软件架构师，有些公司是软件开发人员的工作。如果软件设计无法满足需求，后面的工作都是白费力气。测试人员参与软件设计，不仅仅是审查需求的可测性，也是在以测试和使用者的眼光来看待这个设计是否符合产品的需求，预见测试的结果。这对开发人员来说是很重要的。