掌控感|快速分析测试对象

作为质量工程师，最难堪的应该是自己负责的产品模块，在上线后第二天就出现了线上的问题，产生的负面影响当然会有很多，比如测试环境为什么没有测试等等，更加负面的是有时候还会被贴上缺少责任心的标签。

掌控感是一种能力，对产品质量也是如此。产品质量需要考虑的因素是非常多的，它除了本身技术因素外，还涉及非技术的因素。本文章主要先谈谈针对测试对象的分析与测试范围的边界问题。

作为质量交付工程师，首先需要具备的是针对被测试的对象要熟悉，能够清晰地知道哪里是重点，哪里是非重点，以及哪里需要投入更多的资源来进行保障。古人言“知彼知己，百战不殆”，对质量交付而言也是如此。

把测试的对象当作一个整体，那么这个整体就是一个独立的世界，测试工程师最核心的目标与价值就是无论外面发生了什么，都不能影响这个世界的正常运转，都让它能够按照某一种规则能够有序地运转和完成输入流与输出流的闭环。再通俗的解读就是不管系统无论发生任何的意外，这个系统的核心业务流程都不能受到任何的影响，核心业务逻辑也不能受到任何的影响。

“资源总是会自我调整，目的是使工作量减少。而20%~30%的资源与70%~80%的资源活动有关。”这是管理学上最初二八原则的研究成果，后来这一伟大的发明被朱伦应用到产品品质理论上，也就是经典的“二八原则”。

对质量交付团队而言即使有太多的资源与人力，也无法对一个测试对象进行穷举的测试，即使有资源也不建议进行穷举测试，因为这涉及资源浪费，也不建议进行过度测试。根据“二八原则”，结合到研发中产品上线的环节，需要考虑的测试范围具体如下：

• 系统核心业务流程
• 系统中容易出问题的模块
• 迭代新增的功能

清楚了测试的边界后，下面分别详细的阐述下针对如上三个部分如何进行梳理。

针对系统核心业务流程，可以结合EXCEL文档等其他文档，首先把自己认为是系统核心业务流程的进行梳理出来。梳理的具体模式就是第一层级是一级模块，第二层级是二级模块，第三层级是具体测试点的描述，形象点就如下所示。

当然描述的方式有很多的，总之您的描述需要别人能够看懂，因为仅仅个人理解的系统核心业务流程是不够的，还需要和其他不同角色之间进行一次沟通（产品&开发以及其他人），最终在您的主导下确定下系统的核心业务流程。那么同时也需要阐述到后续每次上线这些点都需要覆盖到。针对产品测试的方式可以有多样性的选择，比如可以使用手工测试的方式也可以使用自动化测试的方式，不过建议使用自动化测试的方式。但是需要明确的一点就是后续迭代交付这些功能都必须是需要进行测试验证并且它的结果是通过的情况下才可以发布上线，如果失败，取消上线的计划。

第二是系统容易出问题的模块，这部分可能部分包含在系统核心业务流程中，也有部分未包含在里面。那么怎么可以快速的获取到系统经常哪些模块出问题了，获取的途径可以有多种的方式，比如可以咨询开发与产品，也可以在之前测试过程中进行总结，或者还可以查询线上工单系统库进行分析。经常出问题的模块背后代表着它是一个用户高频使用的场景，而且又容易受到多个不同模块之间的代码影响。在清楚这点的基础上，把这些对应的模块和模块对应的测试用例使用EXCEL等文档的模式梳理出来，也加入到系统核心业务流程中，也就是每次上线必须验证的点。系统核心业务流程的测试点它不代表是不变的，它是一个变化的过程，也是一个增量的过程，增量的测试用例就是在产品迭代交付过程中又出现了新的工单而且该功能被用户高频使用，那么可以把这样的测试用例再纳入到核心测试用例中。事物是变化的，不可能一蹴而就，所以对这点要清楚地认识。

第三是增量的迭代功能的测试，这点很好理解的，不需要太多的讨论。当然，除了如上讨论的几点，还是不够的，建议再引入探索性的测试，结合探索性的测试思想看哪些还没有考虑到而进行验证。

对被测对象一定要清楚地认识到，它如果出问题了，问题带来的结果是什么？即使再完美也是存在不可确定性的因素存在，不可能尽善尽美的。当然这涉及功能层面的考虑范畴，也涉及非功能层面的考虑范畴。抛开测试层面的考虑，需要知道的是当系统真的出问题，那么它带来最负面的结果和影响是什么？针对这点可以和研发多沟通，然后进行制定对应的策略与方案来确保该事件发生。

产品质量之所以越来越重要，是因为一家公司的核心竞争力并不是技术有多强，或者人才有多么优秀，因为在市场，最终都是过硬的产品质量与良好的用户体验才可以赢得客户，客户才会买单。所以从某种角度上说，质量也是一家企业的核心战略之一。