背景

构建场景图的目的是为了在持续增大的项目中，有个比较可靠和标准的业务边界衡量工具。在业务的持续迭代和拓展中，人员变动多，文档沉淀冗余，在黑盒领域我们希望通过工具和方法论的形式去衡量和评估业务的功能边界，避免测试出现功能漏测，需求出现功能缺失。

构建思路

最初在基于上述背景的前提下，我们设想使用常见的流程图去解决这件事，但是流程图的局限性在于目前我们的业务流程过长，并且分析的方式依然是上下游的业务链路进行串联，导致无法分析并行业务甚至是跨端业务。多方调研之后，我们选择了使用场景图的思想并进行发散，构建了目前使用的业务场景图。

以上是百度常见的场景图的图形描述。场景图的主要思想是找到 “主干流程”，再在 “主干流程” 的基础上发散 “备选流程”。但是在这个基础上我们做了一些变动。请看一下以电商业务流程为 demo 的示例 1。

在构建主干流程的时候并没特别的区别，只是会给每个流程节点标记数据当前业务的特殊标签，用于后续更好的进行影响面评估。在主干流程之外，我们加了 2 个示例功能 “退款”&“变更产品”。分支功能在绘图时需要遵循 2 个原则。

1. 找到功能最初的起点。
2. 找到该功能影响链路传播最远的流程节点，这个节点可以是单向的也可以是双向的。

在上图中分支的功能，最远的影响链路是单向的。但是还是有部分业务功能会像 demo 功能一样，会存在双向的链路影响。掌握以上的两个原则你就懂得该如何绘制场景图了。

使用方法

不要忘记流程图式的链路分析

在这里使用场景图的伙伴，初次使用不要忘记 “新功能” 引入后的主干流程测试分析。

场景图式的横向功能边界

“新功能” 的引入同样要遵循场景图绘图的 2 个原则，当你绘制完图像后，根据流程起点和影响最远的功能交集点你将得到 2 条线，功能上游边界，和功能下游边界。而在这 2 个边界内功能将是所有你需要重点注意的功能。他们将会有以下特性。

1. 新功能影响旧功能
2. 旧功能影响新功能
3. 原功能组合可能会影响新功能 (⭐️)
4. 新功能可能会影响原功能组合 (⭐️) > 使用场景图确定影响的功能，根据数据链路分析方法，我们基本能 90% 的确定在这 2 条线之内的功能会存在以上描述的特性。其中重点关注，3 和 4。当功能组合之后产生新的数据，而这个数据产生的影响是最隐蔽的。就像使用等价类方法一样，我们基本会使用最复杂的组合数据进行测试组合。 以上就是使用场景图，可以得出功能边界的方法。使用这种方法不断扩大场景图的功能选项，就能进行更加细致的黑盒层面的业务分析，这也是区别于白盒测试以及白盒测试不可能分析到的盲点。因为他本质是对功能影响的考量而非代码设计的考量。

丰富分析模型

上图已经在业务上有了功能上的评估，但是很多时候我们功能内部就是一个比较复杂的流程。针对这点可以使用功能场景图去进行制作和评估。小型功能可以引入功能的数据模型图去丰富他的评估效率和评估其相关性。

有更好的评估功能影响面，以及评估现有功能与历史功能干扰的方式。大家可以一期讨论讨论。
后面有时间会再写一版，基于场景图，我们使用的较为适配的分析方法，已经分析相关性的底层逻辑方式。