上周在公司内部做了一次关于质量相关主题的分享，本文同步记录其中的部分核心观点。思考为主，具体案例没有放出来，如需进一步探讨，可以留言。
01
测试人员，总会在不同的场景下被这三个问题拷问。现根据自己的经验，尝试对这三个问题给出自己的看法。
为什么这个BUG测试不出来？这个问题的本质是对测试充分性的质疑；
测试到底会不会测？这个问题的本质是对测试有效性的质疑；
测试为什么那么慢？ 这个问题的本质是对测试效率的质疑；
针对这类问题，当然也可以直接找各类理由怼回去（测试无法穷尽、BUG又不是测试产生的，需求那么乱，时间那么紧。。。。。。），但意义不大，除了加深矛盾，没有实质的意义。还是要尝试去解决问题。
02
针对为什么这个BUG测试不出来的问题，我们需要考虑的是如何让测试更充分。
测试充分性包含三个层次的：代码层次的测试充分性、系统（功能/非功能）层次的测试充分性、业务层次的测试充分性，而“业务层次的测试充分性”最具决定性的。
代码层次：这一层次在很长一段时间内，是被测试人员忽略的（能力不够）。万丈高楼平地起，测试人员需要花一部分精力去关注代码层的交付质量：代码静态分析、覆盖率验证、全链路测试、契约测试等，可以快速提升测试效率。同时，这个层次也是最适合做自动化的层次。
系统（功能/非功能）层次：大部分测试人员的主要精力都会花在这里（自称点工）。根据现有的需求文档或者Story描述，结合业务特点和自己的经验，通过测试用例的设计，验证功能点的正确性。并适当地开展一些非功能性测试。只关注这层，往往会忽略很多上下游业务依赖的错误，或者是底层代码在特定场景下的问题。
业务层：这里指的是需要有端到端的业务视野，从全流程的角度去验证复杂场景。这需要测试人员对业务非常熟悉，同时也熟悉业务关联的上下游系统。这类测试人员其实非常难得（在制造业的某个领域，曾经半年招不到一个，但这类人其实就业面也比较窄，因为对口的业务公司也不会太多，所以专注业务的同学需要慎重选择深入哪个业务）。
在做测试策略和测试设计时，需要针对以上三个层次都有所覆盖，才能提升测试的充分性。
03
针对测试会不会测试的问题，其实是对测试预期（Test Oracle）的管理。在面对比较简单的业务时，预期结果是明确的。但随着业务复杂度的提升、细分专业领域的业务场景、大数据、海量用户的非常规操作，都使得Test Oracle 问题更加突出。因为如果没有可靠的Test Oracle，测试人员就无法判断测试结果是否正确、无法发现软件中的缺陷，自然，测试就无法进行。
在笔者遇到过的场景中，曾经遇到过一个场景。测试人员在SIT环境测试时，发现了部分浅层的问题。修复完成后，投入UAT测试。但是在UAT测试时，用户反馈了大量的问题，通过针对这些问题的分析，其实是因为研发和测试都对这个系统的实际应用场景不够了解，导致对系统的使用与业务不一致，导致无法发现问题（一个非常专业的制造业细分系统）。
如何解决这类问题呢？
01 必要的业务培训：熟悉业务属性，结合业务流程图、系统架构图，对业务系统有个整体的感知。了解业务的流转规则、约束条件及数据流向。
02 制定明确地测试策略：根据业务特性制定对应的测试策略，做针对性的测试设计，保障更好地覆盖。而不是根据执行人的个人经验进行测试。
03 严格执行测试流程：很多人都讨厌自己走流程，但更讨厌别人不按流程来（是不是很熟悉？）。不要让测试设计停留在表面上。
04 建立质量意识和责任感：作为测试人，经过自己测试过的内容，应该承担一份责任，能够保证产品的基本质量。测试遗漏是难免的，但是我们不能把线上问题简单地归结为对质量意识不强或者开发人员能力太差，测试应该有责任和能力去探查问题的根源并加以改进。
05 定期回顾和总结：著名的PDCA法则告诉我们，想要把事做得更好，复盘和总结是必不可少的，通过复盘，能够更好地认识自己，发现问题，改进方法，提高工作效率
——以上内容可参考：迭代测试发现不了问题，怎么办
测试的充分性和有效性通常会耦合在一起。测试负责人需要能够有针对性地去识别其中的问题。因为解决这两类问题的侧重点是不一样的，虽然看起来很像。测试的充分性是测试设计的问题，测试有效性更多的是业务和流程的问题。
04
关于测试效率的提升，本质上是需要在适当的场景下做减法，去减少那些不必要的活动。但是做减法是需要勇气的（容易背锅）。
消除重复测试：重复的测试用例、重叠的测试流程、非必要的回归测试范围
消除测试中的等待：从流程规范上，让测试活动更顺畅，让研发过程流动更快。设置必要的DOD，对齐每个环节的完成标准，更合理地分配Story研发顺序（关联优先，而不是难度优先）
消除没有必要的测试：过度的非功能测试（是不是都要做兼容性测试、性能测试）、过度的测试范围（制定基于风险的测试策略，而不是大而全的全量覆盖）
05
为了解决以上三个灵魂拷问，也为了对交付质量有更高的要求，提升测试人员自身的素质。测试人员需要学会去构建适合自己的质量保障体系（可参考：构建软件质量保障体系），建立质量意识和责任感。但是，这些都需要时间和成本的投入（不论是公司流程制度的投入，还是个人技能提升的投入）。
质量不是“希望”的结果，它是付出的收获。关键在于你愿意用什么去交换。
质量是昂贵的，在当下很多的团队中，快比好更重要，只不过当有一天质量变成我们无法再忽视的问题时，别不知所措地想不起来质量是在哪里搞丢的。
共勉。
往期推荐：
学习，从接受自己的笨拙开始
如何开展大规模集成测试
越迷信技巧越容易失败
自动化测试落地为什么那么难
接口测试这么玩才明白
如何高质量的做BUG分析
接口自动化不是救命稻草
END
标星、点赞、关注三连走起，感谢支持。
如果想阅读更多文章，请关注我的公众号。
声明：文中观点不代表本站立场。本文传送门：https://eyangzhen.com/423225.html
