当我们在谈质量时，我们在谈什么？

作者: VTester | 来源:发表于2019-10-28 13:34 被阅读0次

作为一名测试人员，我们该如何保证质量？
作为项目的owner，该如何保证质量？
作为一个大型项目的owner，该如何保证质量？
作为一个大型紧急项目的owner，该如何保证质量？
作为一个大型紧急新接手项目的owner，该如何保证质量？

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

测试人员无形的“被动”

作为测试人员，我们经常会发现自己的工作非常的“被动”。
典型的例子：
1. 被动的等着开发提测的延期；
2. 被动的背起线上的bug；
3. 被动的要保证100%的项目质量(即使开发一点自测都不做)
4. 这么简单的功能，为什么没测到；
......
平心而论，你还会觉得这些都是作为测试应该有的结果么？来自你内心深处的答案肯定是否定的，当这些事情被摆在明面上的时候，很多人都会“情不自禁”的接受了！
为什么会这么被动？是因为我们从根本上没有明确测试的职责！我们不是应该是被延期的对象，不应该是背锅侠，更不应该是保障质量的唯一能力者。

开发自测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也有发射失败卫星失败的时候，导弹也会有击中错误目标的情况，甚至某飞机近期接二连三的爆出飞行事故问题。

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