测试管理测试灵魂三问及解决方案

CKL的思考 · 2024年10月23日 · 最后由王中回复于 2024年11月11日 · 7027 次阅读

上周在公司内部做了一次关于质量相关主题的分享，本文同步记录其中的部分核心观点。思考为主，具体案例没有放出来，如需进一步探讨，可以留言。

01

测试人员，总会在不同的场景下被这三个问题拷问。现根据自己的经验，尝试对这三个问题给出自己的看法。

为什么这个 BUG 测试不出来？这个问题的本质是对测试充分性的质疑；

测试到底会不会测？这个问题的本质是对测试有效性的质疑；

测试为什么那么慢？这个问题的本质是对测试效率的质疑；

针对这类问题，当然也可以直接找各类理由怼回去（测试无法穷尽、BUG 又不是测试产生的，需求那么乱，时间那么紧。。。。。。），但意义不大，除了加深矛盾，没有实质的意义。还是要尝试去解决问题。

02

针对为什么这个 BUG 测试不出来的问题，我们需要考虑的是如何让测试更充分。

测试充分性包含三个层次的：代码层次的测试充分性、系统（功能/非功能）层次的测试充分性、业务层次的测试充分性，而 “业务层次的测试充分性” 最具决定性的。

代码层次：这一层次在很长一段时间内，是被测试人员忽略的（能力不够）。万丈高楼平地起，测试人员需要花一部分精力去关注代码层的交付质量：代码静态分析、覆盖率验证、全链路测试、契约测试等，可以快速提升测试效率。同时，这个层次也是最适合做自动化的层次。

系统（功能/非功能）层次：大部分测试人员的主要精力都会花在这里（自称点工）。根据现有的需求文档或者 Story 描述，结合业务特点和自己的经验，通过测试用例的设计，验证功能点的正确性。并适当地开展一些非功能性测试。只关注这层，往往会忽略很多上下游业务依赖的错误，或者是底层代码在特定场景下的问题。

业务层：这里指的是需要有端到端的业务视野，从全流程的角度去验证复杂场景。这需要测试人员对业务非常熟悉，同时也熟悉业务关联的上下游系统。这类测试人员其实非常难得（在制造业的某个领域，曾经半年招不到一个，但这类人其实就业面也比较窄，因为对口的业务公司也不会太多，所以专注业务的同学需要慎重选择深入哪个业务）。

在做测试策略和测试设计时，需要针对以上三个层次都有所覆盖，才能提升测试的充分性。

03

针对测试会不会测试的问题，其实是对测试预期（Test Oracle）的管理。在面对比较简单的业务时，预期结果是明确的。但随着业务复杂度的提升、细分专业领域的业务场景、大数据、海量用户的非常规操作，都使得 Test Oracle 问题更加突出。因为如果没有可靠的 Test Oracle，测试人员就无法判断测试结果是否正确、无法发现软件中的缺陷，自然，测试就无法进行。

在笔者遇到过的场景中，曾经遇到过一个场景。测试人员在 SIT 环境测试时，发现了部分浅层的问题。修复完成后，投入 UAT 测试。但是在 UAT 测试时，用户反馈了大量的问题，通过针对这些问题的分析，其实是因为研发和测试都对这个系统的实际应用场景不够了解，导致对系统的使用与业务不一致，导致无法发现问题（一个非常专业的制造业细分系统）。

如何解决这类问题呢？

01 必要的业务培训：熟悉业务属性，结合业务流程图、系统架构图，对业务系统有个整体的感知。了解业务的流转规则、约束条件及数据流向。

02 制定明确地测试策略：根据业务特性制定对应的测试策略，做针对性的测试设计，保障更好地覆盖。而不是根据执行人的个人经验进行测试。

03 严格执行测试流程：很多人都讨厌自己走流程，但更讨厌别人不按流程来（是不是很熟悉？）。不要让测试设计停留在表面上。

04 建立质量意识和责任感：作为测试人，经过自己测试过的内容，应该承担一份责任，能够保证产品的基本质量。测试遗漏是难免的，但是我们不能把线上问题简单地归结为对质量意识不强或者开发人员能力太差，测试应该有责任和能力去探查问题的根源并加以改进。

05 定期回顾和总结：著名的 PDCA 法则告诉我们，想要把事做得更好，复盘和总结是必不可少的，通过复盘，能够更好地认识自己，发现问题，改进方法，提高工作效率

——以上内容可参考：迭代测试发现不了问题，怎么办

测试的充分性和有效性通常会耦合在一起。测试负责人需要能够有针对性地去识别其中的问题。因为解决这两类问题的侧重点是不一样的，虽然看起来很像。测试的充分性是测试设计的问题，测试有效性更多的是业务和流程的问题。