你好，我是董建琴。今天想和你聊聊精准、快速测试的一些方法。

作为测试人员，我们在日常测试中会碰到这些“灵魂拷问”：
这个改动点影响的范围有多大，我需要回归所有功能吗？
接口有变动为什么我不知道，引起了线上Bug？
改动的需求会影响这个功能，为什么之前没有想到？
我选择的测试重点正确吗，我的测试有效且覆盖完全了吗？

这些问题，最终都会影响项目的交付质量。其实，总结归纳一下你就会发现，刚才的那些问题不外乎就3个测试痛点：
如何精准确认开发改动的影响面？
如何降低需求不完整，或者需求变更对测试环节的影响？
如何通过数据统计、测试工具，来确定测试重点？

那么这三个痛点，该怎么解决呢？我们可以从下面3个方面来将这些痛点逐个击破：
首先，通过一些工具和方法提取开发改动点和影响面，确定“我要测什么”。
其次，通过规范化需求流程和需求变更流程，降低需求变化对测试环节的影响，减少重新梳理“我要测什么”的各种资源投入。
最后结合工具进行数据统计，用数据化、可视化的手段帮助测试人员进一步明确测试范围和测试重点，了解自己“测得怎么样”。

接下来我会详细讲解这三个方面，带你了解具体解决上述痛点的一些方法。

如何确定“我要测什么”

刚才也说了，我们要先利用工具和方法提取开发改动点和影响面，确定我们要测什么。那在项目实践中，我们的项目由于对业务或数据的准确性和实时性要求很高，同时对市场环境的变化很敏感，需要项目随时作出变化或调整，所以项目会经常产生一些临时或小的需求，针对这些临时或小的需求改动，测试人员往往都是依据开发人员提供的测试点进行测试的，所以经常会出现漏测或者少测的问题，引起线上Bug。针对这种情况，我们结合精准测试思路做了一些改进。那什么是精准测试？从代码分析的角度，精准测试就是针对应用代码的变更，更有针对性的测试变更部分，使得测试目的更加明确，减少漏测或少测的发生。它的核心部分就是精准圈定代码变更的影响面。

从这张图中，你可以看三个关键点：

一是规范提测清单：提测的时候，开发需要提交提测清单，提测内容 = 改动的功能 + 影响的功能。
二是代码分析：测试人员比对提交的代码找出变更的方法，定位出变更的接口，然后通过接口详情，提取出影响的业务和接口。
三是监控分析：通过Skywalking分析调用链路，进一步找出影响范围，补充核心用例。

通过规范提测 + 代码分析 + 监控分析结合的方法，我们就可以精准判断出这次改动需要测试的范围和重点了，减少漏测或少测的发生。那你可能要问了，怎么评估这种改进方法的效果呢？你可以在每周发布后，观察跟踪线上质量，同时结合测试工具（如Jira Software）的数据分析，定期对线上问题进行分析和总结。我们也是在实践过程中，通过这种反复校验，不断改进的办法，确认了这种方法是有效可行的。

减少需求变更对测试带来的影响

那么在精准确认开发的改动点和影响面之后，测试人员就开始执行测试了，为了能够顺利交付，测试人员要面对和解决各种各样的“拦路虎”，其中之一就是需求变更。一旦出现需求变更，那就要重新梳理和分析“我要测什么”，重新制定计划和评估风险，这是我们最不希望发生的。

那么为什么会出现需求变更？我结合工作中遇到的部分案例，总结了一些原因：

一是前期需求设计不完整，只实现了一部分功能或逻辑，导致需求断层。
二是需求产出时没有进行合理的调研，导致测试阶段才发现部分功能实现不了或实现有问题。
三是市场环境的变化，比如产品需求需要临时调整或变更。

所以你看，在一个项目中，需求有变动是很正常的。我们作为测试人员，面对需求变更时最重要的是搞清楚需求的变化带来的影响，比如哪些需求发生了变化，这些需求变化后，对测试工作会产生哪些影响，包括对哪些用例产生了影响？当发生较大改动时，还要明确是不是影响到了测试方案，甚至是测试计划。明确这些变化后，我们还要清楚这对项目、对测试进度会产生多大的影响和风险。

明确了需求带来的影响后，我们就要思考如何降低需求不完整，或者需求变更对测试环节的影响。这里我分享3点我们团队的实践，你可以根据自己团队的情况进行参考。

第一，预防需求变更。主要是提升需求确定性，把需求分析做好，减少需求变更。这里要提到一个测试工具——Jira Software。对于我们团队来说，它可以支持基于需求的测试，可以管理和跟踪所有的问题、任务、需求的进展和过程；也可以链接代码库，实现对代码变更的跟踪和管理；还可以链接到其他系统，可以将需求任务与Confluence中的需求文档进行关联；并且支持高级搜索和报告，可以生成特定报表、构建面板等等。因此我们结合Jira Software提供了一个实践方案，让需求流转可以流程化、可控化。在Jira Software中一个项目需求会经历两个阶段：新生需求（需求池）和确定需求（评审后需求）。新生需求统一在需求面板中进行管理，确定需求经过评审后会进入开发面板等待排期，两个面板相互独立又相互关联。我们通过这种确定需求的方式提升需求确定性，以达到减少需求变更的目的。

第二，制定规范的需求变更流程。当产品确认需要发生需求变更的时候，应该发起需求变更评审会议，协同项目所有的开发人员和测试人员，对需求变更内容进行评审，评审通过后等待排期进入研发阶段。从这张图你可以看到具体的需求变更流程：

第三，通过Jira Software提供的数据统计和分析，把需求不清晰带来的影响透明化，反推产品提高需求质量。Jira Software提供了筛选器和仪表板，可以通过各种维度如经办人，模块，日期，Bug类型等生成各种图表，实现基于数据进行统计，基于统计进行数据绘图，使数据透明化、可视化。我们用Jira Software可以精确统计出项目或模块因为需求不清晰产出的Bug数据，比如这张图（图4）就是一个项目需求不清晰产出的Bug统计图，从这张图里，产品经理可以清晰地看到"需求不清晰"Bug的占比，现象，原因等信息。这些数据就可以帮助产品经理进行分析，提高下一次的需求产出和质量。

在这里，我们需要清楚的是，需求变更流程并不能消除需求变更，但规范的需求变更流程能够控制和管理需求变更，把需求变更带来的波动或影响控制在一定范围内，从而使测试工作可以顺利进行。

通过数据统计识别测试重点

现在我们明确了“我要测什么”，也了解了怎么减少需求变化带来的影响，那么，有没有一些工具或方式可以从不同的维度帮助我们分析，进一步确定测试重点呢？目前主流的测试工具有禅道、Jira Software、TestLink、Bugzilla、Bugfree、QC等等。刚才也说了，我们是选用了Jira Software进行数据统计和分析。Jira Software可以从多个维度收集项目的质量数据进行分析和整合，从数据分析的角度判断测试的侧重点。比如测试人员在提交Bug的时候，会将Bug按模块识别分类，最后通过筛选和统计呈现在仪表板上。

这张图就是把所有模块的线上问题统计出来了，我们的项目的功能模块很多，并且具有明显的特点：一是除了用户相关，模块和模块之间相互独立；二是股权激励等核心模块，业务逻辑相对比较复杂；三是公告，行情，法规等基础模块，用户使用频率较高。在模块多，模块要求各不相同，测试时间和人力资源不足等的情况下，基于Jira Software提供的数据分析，我们的实践方案如下：

第一，根据模块对应的线上Bug数量初步筛选测试重点，先考虑把排名靠前的模块作为测试重点进行测试。
第二，根据业务逻辑的复杂程度确认测试重点，业务逻辑越复杂，改动影响的面越大，所以要作为重点测试模块进行测试。
第三，再具体分析用户使用频率和模块缺陷严重程度的分布情况，分梯队对重点模块进行测试验证。

接下来我们再从研发阶段产出的Bug进行分析，这张图我们可以清晰的看到所有模块在开发阶段的缺陷产出，可以从缺陷质量的角度分析评估对应模块的业务的复杂程度和测试质量情况。

结合可视化和透明化的数据，针对我们的项目，Bug产出和业务逻辑的复杂程度是直接相关的，业务逻辑越复杂，需要考虑的细节点越多，开发在对应模块的Bug产出越多。在对应模块如股权激励、三会、用户相关等模块有新需求的改动时，对应模块会作为测试重点进行关注和测试。

总的来说，我们使用Jira Software工具进行数据统计和图表分析，可以实现项目质量的实时跟踪与监控分析。通过模块、Bug类型、Bug产生端等不同维度对测试质量进行评估和分析，当有新需求时，可以通过各个维度的数据分析判断对应模块或功能的重要程度和影响范围，识别出测试重点。

总结+延伸思考

今天的分享到这里就结束了，最后我来给你总结一下。今天我们分享了在日常测试工作中会遇到的3个测试痛点，那么怎么有效的解决这3个测试痛点呢？第一步，确定“我要测什么”，通过开发提交的改动点和代码分析并结合Skywalking分析调用链路，精准判断影响范围；第二步，通过提升需求确定性和规范需求变更等方法减少需求变化对测试的影响。第三步，通过数据统计，反推需求提升质量，并识别测试重点。当然，不同公司针对测试痛点都有自己不同的解决方案，我们之所以结合代码分析的测试方法，原因是由于开发测试人员能力和对业务熟悉程度不一致，测试人员无法仅依赖于开发提供的测试点和业务熟悉程度精确把控。

当然，除了今天我们讲到的方法以外，提升测试的精准度还有很多方法，比如采用抽象语法树分析的方法识别变更代码、通过JavaAgent对代码进行织入来分析影响的接口以及采用公司内部的调用链系统分析调用链路等等，后续有机会我再详细跟你分享。

好，我是董建琴，希望我的分享可以帮助到你，也希望你在视频下方的留言区和我讨论。