今天 “不幸” 被老板拉去 REVIEW 刚结项的项目，结果自然是一顿被批评；不过从总体 “收益” 来讲还是比较 “划算” 的！毕竟还是学习到了很多东西，其实我还是比较喜欢这样的 REVIEW，因为它可以给自己带来较快的成长！

既然说到了被 REVIEW、被批评，那么今天要说的内容自然就是与这个相关的。在此之前我们可以问自己几个问题：

1. 作为测试人员，我们该如何保证质量？
2. 作为项目 OWNER，该如何保证质量？
3. 作为一个大型项目的 OWNER，该如何保证质量？
4. 作为一个大型紧急项目的 OWNER，该如何保证质量？
5. 作为一个大型紧急新接手项目的 OWNER，该如何保证质量？

我相信，很多时候这些问题就可能出现在面试当中，尤其是非技术流，偏项目管理的岗位面试中。虽然说我是偏技术流的，但也避免不了被问到这样的问题，甚至我在面试别人的时候也会问到这样的 “奇怪” 问题。

无形的 “被动”

作为测试人员，我们经常会发现自己的工作非常的 “被动”。比如：被动的等着开发提测的延期；被动的背起线上的 bug；被动的要保证 100% 的项目质量 (即使开发一点自测都不做)。

如果你 “摸” 胸而论，你还会觉得这些都是作为测试应该有的结果么？来自你内心深处的答案肯定是否定的，当这些事情被摆在明面上的时候，很多人都会 “情不自禁” 的接受了！

为什么会这么被动？是因为我们从根本上没有明确测试的职责！我们不是应该是被延期的对象，不应该是背锅侠，更不应该是保障质量的唯一能力者。

开发自测 VS 测试人员测试

前几天看到一篇文章写的很好，讲的就是开发自测与测试人员测试的本质区别，并且我还转发到朋友圈了。文章中打了个比方来形容两者的区别。

如果说质量是一张平面，平面中有一个圆圈，开发自测就是等于在圆内做检查，而测试人员的测试则是在圆外做检查。即一个是在既定/有限的区域内保障质量，一个是在未知/无限的区域中探索质量问题。

所以你就能理解，为什么需要开发做单元测试、需要 TDD、需要自测，因为这本来就是他的本质工作。如果一个开发人员写完一个功能后，自己都没有完全跑通就提交测试，那么肯定是一个不合格的开发人员，是需要慎重对待的。

同样你也能理解，为什么开发自测了，测试人员还有需要存在的价值。测试不仅是开发的 DOUBLE CHECK，更是对未知区域隐藏 bug 的探索，也是对非功能性需求的覆盖测试。

不存在的 “完美” 质量

测试人员的思想往往会被带入常识性的误区。比如：作为专业的测试人员不应该有 bug；只要是质量问题就是测试的锅。其实这些都是不对的，只有没被发现的 bug，没有 0bug；所以我们不需要追求 100% 的质量，这个是不存在的。天塌下来还有 “高个子” 顶着，项目出了质量问题，第一责任人首先应该是最高负责人。

所以有 bug 或者有缺陷的项目是可以接受或者上线的，但前提一定是这些已知/未知缺陷是在当前可接受范围内。比如：线上大促，肯定不能是性能有问题；参加大赛，肯定不能是流程中断问题。

如果说测试也遵循着 2/8 原则，花 20% 的精力就能发现 80% 的 bug，那么我肯定不会把剩下的 80% 的精力再去发现剩下的 20% 的问题。首先产出比不高，更重要的是它存在很大的风险。所以剩下的 80% 的精力一定是思考如何更好的保证正常功能的稳定性，思考各种极端环境可能出现的问题及其对应的预备方案。而剩下的 20% 的问题则属于长尾问题，需要长期不断的优化和打磨，可能即使你 “毕其一生” 也发现不完！

技术保障 “质量”

严格来讲，技术保障质量是个伪命题。因为研发/测试人员本身都保障不了质量，技术又怎么能保障质量呢？当然这并不妨碍我们在质量保障过程中使用技术手段，毕竟技术可以提高测试效率、增加测试覆盖率、增强测试手段。所以技术在质量保障过程中还是有它独特的价值的，并且不同项目中体现的价值也会有差异。

技术保障适用于那些测试场景重复且固定流程的改进，适合那些机械且重复组合的场景；技术保障适用于我们平常没有时间或者覆盖不到的场景，比如：单元测试、API 测试；技术保障适用于那些手工无法测试的场景，比如：建造大量的测试数据，控制程序的微观操作，测试场景的改造和测试内容的欺骗。

技术保障的方式有很多种，在不同的团队和项目组中达到的效果也不尽相同；在应用好的项目中它是利器，在应用不好的项目中它就成为了鸡肋。因此还考虑使用技术来保障质量的之前，需要深刻思考它真正能解决的问题和期望能达到的效果，甚至可以先使用 DEMO 来进行一段时间的适用，在拿到实际数据之后再评估是否真的需要技术改造。

什么是质量

质量从来都不是测试说了算，也不是老板说了算，而是用户说了算。你认为不是问题的问题，对于用户可能是不可接受的 bug；而你认为是问题的问题，对于用户可能根本就是不是问题；你认为不会出现的问题，在用户那可能就会真实的出现。

质量可以是项目/产品的验收标准，包括功能性、非功能性的；同时质量也是用户的一种综合体验，越多的人觉得系统/产品好用，就说明质量越高。而那些小部分人认为不习惯用，和用户不关注的 bug 都应当不在质量的范畴之内！

质量不是说线上一定不能出 bug，质量是长期稳定的保障服务正常运行，保障用户体验流畅，保障用户留存率，保障业务收入的一种能力。不影响这种能力的线上 bug，可以视为低价值的 bug；这类 bug 不是不改，而是应该在合适的时间里去修复它。比如：项目组有额外精力的时候。

质量是一种自顶向下的态度，为什么微软、谷歌的项目质量做的比较好？那是因为它们是技术性公司，从顶层设计时就会考虑质量，不仅仅只是考虑功能的开发；所以一个完整的项目/系统设计，一定是从一开始就确定了如何去度量质量，如何去执行测试，如何去覆盖场景，如何协调团队的整体资源分工合作。

如果把测试当做足球守门员，那么开发就是后卫，项目管理者就是中场，高层领导就是前锋。虽然位置不同但是目标是一致的，质量保障就像防守一样需要整个团队的通力合作才能做到更好。如果所有问题都直接漏到测试这一层，那么 “守门员” 就会被打成筛子，即便他使出了 “洪荒之力”。

质量体现在可控的流程之下，有些人可能会觉得有些系统就是没有质量问题；比如：银行系统为什么不出错，航天系统为什么不出错。实际情况真的是这样么？当然不是。新闻偶尔也会爆出 ATM 机可以取出超额的现金，电影里也会演绎利息余数的 bug，NASA 也有发射失败卫星失败的时候，导弹也会有击中错误目标的情况，甚至某飞机近期接二连三的爆出飞行事故问题。

但是当我们反过来思考的时候，你会发现虽然这些系统也会有一些意外的情况，但是它们发生的概率还是非常小的，一旦发生就会是新闻级的现象。而之所以这些系统的质量在普通人眼里觉得非常高，根本原因是在于这些系统都是固定的流程系统，每一个操作、指令、设备都是有严格要求的，不是你想怎么操作就怎么操作的。而我们日常所测试的系统则是用户产品，所以你懂的！

当我们在谈 “质量” 时

• 是保障 80%，还是追求 100%
• 是追求 0BUG，还是追求不出错
• 是测试来背锅，还是领导来负责
• 质量属于测试，还是质量属于团队
• 质量是常规功能，还是用户综合感受
• 质量是穷举未知范围，还是确定固定流程

欢迎大家讨论交流，另外获取更多关于 Python 和自动化测试的文章，请扫描如下二维码！