以前有个朋友跟我说：做测试这行就是在隐忍中负重前行。因为测试是软件发布前的最后一个环节，被称作质量出口儿，测试环节之前所有未做好的工作所带来的不良后果，似乎都能被轻松甩锅给测试人员。软件一旦出现问题，我们经常听到有人红口白牙地直接定性说是测试人员把关没把好；测试能力不行...。我想说的是技术能力固然是第一要位，但不是唯一要位。如果一个公司上层领导认为软件质量就是通过测试工作来保障的，那基本可以断言，这个公司的软件质量很差，即使其测试团队的“把关”本领有多强，技术能力多高超也一样，因为软件的高质量并不是“测”出来的。
橘 VS 枳
《晏子春秋》有曰“橘生淮南则为橘，生于淮北则为枳”。意思是说同一个物种因环境条件不同而会发生变异。其实不只是橘子，我们平时所测试的代码也是如此啊。工作中我们难免遇到这种情形：在经历测试-修改-复测-再改...数个回合之后，测试人员呕心沥血，通宵达旦终于配合发布完一版软件，结果第二天用户反馈业务数据计算出错，业务流程报错等。于是熟悉的声音响起：“测试连这么简单的bug都没测出来？...” 显然，测试人员的能力又遭到了严重质疑。此时的测试同学往往一脸震惊，不禁自言自语：“明明已经测过无数次的场景了，怎么突然出错了呢？”这种时候公司紧急修复，快速补丁发布，然后迫于时间紧、任务重，大家继续马不停蹄地投入到下一个迭代中。测试同学虽深感不解和疑惑，但也无力自证清白，只能更加细致认真开启下一版测试。结果不久之后，后续版本还是出现这种“诡异”现象，于是质疑声再起，紧接着又是紧急补丁灭之，如此循环往复。到底是怎么回事呢？
有一次我们遇到了同样奇幻的问题，后来调查发现测试环境和正式环境的数据库配置、数据库版本竟然都不一致，而且业务数据差异非常大！两套运行环境差异如此之大，虽然是同一套代码，但很容易出现各种问题。这就是奇幻之处。测试人员品尝通过的“橘”，到实际用户那里已经变成了“枳”。既然已经不是同一样东西了，怎么能质疑“口味”不同呢？除了环境、数据的差异，正式发布前代码是否做了封版，代码基线是否规范，业务所依赖的服务是否一致，业务流程是否都是真实全流程验证（例如支付业务）等等，这些都是直接影响上线后软件质量的重要因素。而这些，并不“测”能保障的了的。
支点 VS 体系
作为一个测试经理，每次听到上司语重心长地说对我说“质量这块儿就交给你们测试部门了，一定要好好测”这类话语，我就有点哭笑不得。质量的重担让测试一肩挑，是不是有点偷换概念了？测试工作做的再出色，也只是软件整体质量把控的其中一个支点而已。测试的职责是检验质量，并不是保证质量呀。对这两个概念的混淆，可能也是大多数测试同学在工作中各种有苦说不出的原因所在吧。毕竟流转到测试手里的如果是一堆垃圾代码，大bug套小bug，改一个bug带出十个新bug，低能bug环环相扣，生生不息，那测试的专业技能也毫无用武之地啊。况且，即便开发和测试技术水平非常优秀，质量也绝对不是靠一个支点来支撑的。软件每一道工序的完成水平都决定着软件最后的输出质量，每一个环节都存在一定的质量风险，因此质量保证应该是多支点并存，各支点相互作用的。确切地说，它应该是一套多维立体的支撑体系。
本文节选自第七十二期《51测试天地》
《又当“背锅侠”？支棱起来：软件质量不是“测”出来的！》一文
想继续阅读全文或查看更多精彩内容，请点击下载：
