是软件都会有漏洞，这道理也是再平常不过了。然而最近在APP线上问题处理过程中发现“漏洞”数量越来越多的时候，这就不再是一个平常的事情。反推过程，这些“漏洞”是什么时候出现的，如何出现的，为什么没有在测试环节暴露出来，我们能够做些什么来规避这些问题。也许是测试工作方法需要改进，也许是测试人员的主观能动性有待提高，除此之外，有一些个人想法和建议，记录在这里。
管理层面，建议在测试日报中增加测试用例执行数目，今天执行了多少测试用例，其中pass/fail的比例，有多少条用例不能执行/未完成。在最终的测试报告中，也要有明确的体现。目前不难看出，产品设计的工作情况能够通过PRD和设计稿质量来评价，研发的工作情况可以参考bug数量、代码质量来评价，而测试工作往往不那么透明，不容易衡量。通过改善测试报告内容，一方面，能够让项目组全员看到测试用例的覆盖率如何，及早的发现问题和解决问题；另一方面，能够评价测试人员发现bug的能力，为垂直线条的管理提供依据。
流程层面，我们需要灰度发布相关的功能流程支持。虽然这个事情喊了一年多两年仍没有落地，但它的重要程度没有削减一分一毫。目前APP版本迭代周期短，但涉及业务越来越多，提供测试环境、正式环境的验证时间有限，人工测试毕竟也存在人力、精力等方面的局限，短时间内，很多问题是不容易被发现的。而通过灰度发布，我们能够在正式环境中，提供1-2周左右的时间来跟踪小部分用户使用产品的情况，获取用户反馈，尽早的暴露问题并解决问题，完善功能与体验，提升产品质量；同时，让用户参与到产品的测试环节中来，既与用户增强了互动，也能够缩小版本升级对用户的影响范围。
运营层面，首先，版本上线的第1-2周，需要格外密切关注数据，对于新功能相关的各项数据指标，每天进行跟踪和分析。新功能上线，用户必定会好奇尝鲜去体验，这对于产品的稳定性、功能等各个方面都是最好的验证时期，同时也能够便于我们及早的发现问题，安排快速修复，或者确定后续迭代计划。其次，对于处于异常状态的用户，应该第一时间安排客服跟进，获取详细的用户反馈，便于团队分析问题所在原因，提供解决方案思路。接收用户反馈后，再给予一定的安抚措施。例如，为了感谢您的耐心接听，我们特别为您赠送XXX积分/代金券，诸如此类的话术和运营手段，让用户感知到我们的用心，觉得我们的服务质量很高，很周到。即使出现问题，用户的感受也会不一样。比如结合砍价功能，用户下单后24小时未支付，订单将自动取消。那么在这有限的时间里，是不是应该关注这些提交订单未支付的用户，问问他们当时的场景是如何，就差临门一脚，为什么没有支付，是哪里出了问题，遇到了阻塞。最后，可以通过不定期的小组分享，来共同分析用户反馈详情，不管是产品、设计还是研发、运营，都有必要知晓我们的用户体验过程中发生了什么，归结原因，商讨对策。
