昨天和老黄（研发 TL）讨论关于漏测的问题。老黄的观点还算中立：一方面认同在一些边缘场景下总归会有遗漏；另一方面认为如果是非边缘场景还有遗漏，那是测试同学的能力不够。
比起常听到的一切问题归测试的论断，这个评价已经算是比较客气的了。首先我不否认测试能力的确在较大程度上会影响测试结果，其次我也不认为非边缘场景漏测就一定是测试能力问题。讲几个典型的案例吧。
第一个案例：范围扩散
某需求到临上线时，为了修改一个重复请求的缺陷动了底层代码。这个需求可能影响到 40 多家商户的对接，即便是只改了十来行代码，但保不准会波及到哪个未知功能点。研发担心造成资损，于是同步测试需要全部回归。
该变更涉及到 600 多条用例，只有半天时间，迫于进度压力，测试同学只好挑选部分核心商户执行回归，然而最终还是有一家商户由于调用参数不同出现异常。这算不算测试能力问题？
第二个案例：特异代码
某电商项目，发布后收到用户反馈，蜡烛（我到现在还清楚记得它的品名）的会员折扣计算不正确。后来经过复盘发现，两周之前因为活动上线赶工，将蜡烛的价格单独写了一个 if 条件特殊处理，导致新的计算逻辑在这个分支下未能生效。
当然，测试无从知晓这个事情，一百多个品类也没有（通常也不会）逐个验证。而对应处理这段代码的研发，在活动发布之后也将此事忘得一干二净。这算不算测试能力问题？
第三个案例：历史影响
一个调整套餐月度可用消费额的需求发布之后，30 多家老客户电话投诉新的额度未生效。调查之后得知，多年前在产品发布初期为了吸引客户，曾经售卖过一批价格比较优惠的套餐，并对客户承诺永远有效。
优惠套餐早已在管理后台中下线，因此本次调整也就忘记了这批初始客户（况且相关人员也轮换过多次了）。更有意思的是，该套餐下线的时候，还没有测试团队。这算不算测试能力问题？
总结：这是个工程问题
上面的几个案例，如果非要让测试来解决，其实也不是不行。比如可能会有人说：我可以提高自动化覆盖率；我可以要求测试也得 Code Review；我可以如何如何等等。都很有道理。
我的看法是，如果只把眼光放在测试身上，得到的并不一定是最优解。比如明明研发用 3 个小时做个架构设计就能避免的问题，为什么非要测试花 30 个小时写自动化脚本来保证？
质量是需要以工程的视角来看待的，在设计问题解决方案的时候，建议还是从整条链路的效率上考虑，争取以最少的成本获得最大的收益，这样就不容易陷在“为什么我招了这么多高级测试工程师，还是会有缺陷遗漏”的困惑里。
