构建模型思维

软件质量保障

所寫即所思｜一个阿里质量人对测试的所感所悟。

很久以前，有一个测试经理并不相信敏捷测试。当团队谈论减少资源浪费、项目冲刺和项目小规模交付时，她会礼貌地点头示意表示赞同。但转身之后，她会按照自己的原有的方式去做事情。对她来说这种方式才是有效的。而她的项目通常都能按时完成，交付质量也比较高，而且发布过程也比较“平稳”。

直到有一天，她遇到了瓶颈。负责的是一个“简单”的迁移项目，目标也很简单——“让它像以前一样运行”。直接迁移，轻而易举。然而，这是一个新组建的团队，应用程序逻辑可能有数百万种可能的组合。之前的测试活动记录得非常糟糕。需求和预期不清晰、缺失甚至自相矛盾。一些棘手的bug隐藏在过于复杂的代码中。这个项目开始看起来像是一个无法克服的挑战。再加上与用户和管理层之间紧张的关系，给团队施加了压力，让他们觉得这是提桶跑路最后的机会。如果这个项目不能顺利完成，他们将永远无法再次进行重构。总结下来就是：“时间紧迫，信息有限”。

我们饱受折磨的测试负责人试图坚持自己的立场，但命运似乎不愿给她所需的6-12个月时间。就在她快要放弃的时候，团队中一位目光炯炯的测试人员建议尝试使用思维导图。仅仅一天时间，思维导图就改变了她的整个看法……他们成功地将测试从缓慢、重复且混乱的状态转变为一个流畅、基于风险且以上下文为导向的测试活动。那位测试负责人就是我，我想分享对可视化模型的热爱，以及它们如何能帮助到你。

可视化模型——它们是如何工作以及为什么有效？

模型是在特定背景下对现实世界或概念的抽象化、简化的表示或模拟，用于理解、预测、解释或指导实践。它捕捉并突出了对象、系统、理论或现象的关键特征和关系，同时忽略或简化了次要细节，以便于分析、交流和决策。

但不是把所有信息都放在一个地方更好吗？其实未必。你有没有看过房屋建筑图纸？当你建造房屋时，你需要很多信息。你需要知道哪里排电线。你需要知道哪里装水管。你需要知道哪些墙是承重墙，等等。如果你在计划如何布置家具，你需要知道房间的尺寸、哪里有窗户和门、哪里有电源插座、哪里可以放置吊灯。但如果把所有这些信息都放在一张图纸上，它将毫无用处。相反，我们可能有同一栋房屋的不同用途的多个模型。你甚至可能想将它们合并，但如果把它们都叠加在一起，它们将毫无用处——会有太多噪音。如果你正在做一些完全不同的事情，比如规划你的花园或决定在哪里建围栏，你可能需要放大地图，关注土地边界、土地的整体轮廓以及房屋的位置和花坛、草坪、树篱的位置。也许你还需要考虑是否要建一个游泳池或客房。你需要一个模型，其中包含你所需要的所有信息，既不多也不少。

模型有各种形状和尺寸，其用途、优点和缺点各不相同。我们有物理模型，如太阳系机械模型（即天体仪）、分子模型、建筑模型、解剖模型，以及飞机的缩尺模型。所有这些模型都非常适合以更直观的方式展示物体的不同方面。想象一下，如果没有这些模型，展示行星如何相互运动、人体内部器官如何排列、分子中原子如何连接等知识会多么困难。想想如果没有这些模型，教这些知识会多么复杂。

然后我们有数学或统计模型，通过对数据进行各种计算来尝试发现模式和关系，并根据模型的结果进行预测。我们还有概念模型，试图描述和代表现实世界系统或概念的某些方面，以便更好地理解它们。在这个组中，我们有诸如流程图、状态图、系统图、数据模型、过程图、用户故事地图、沃德利地图和思维导图等工具。本文的其余部分将重点介绍这些工具，从现在开始，我将使用“可视化模型”这一术语。

出于需要，建模并不能呈现问题的全部情况。这意味着我们从模型中省略掉的内容将不会被考虑，而且我们的偏见也会反映在模型中。然而，这也是一种超级能力——因为它允许我们剔除所有无关信息，并将注意力集中在对我们来说最重要的特定方面。在我的例子中，理论上可能的组合中，几乎有一半在现实生活中永远不会发生。仅通过阅读需求和文档很难看到这些信息，但一旦将所有这些信息以可视化的形式呈现——即我的思维导图，这些信息就变得异常清晰。

任何模型都擅长屏蔽噪音。可视化模型尤其像是你的记忆中的作弊代码。与书面沟通和文档相比，它们在相对较短的时间内能够传达更多的信息。

当然，这在很大程度上要归功于抽象消除了噪音。还有一个有趣的现象叫做“可视化优势效应”(PSE)，可以描述为：“输入越可视化化，就越有可能被识别和回忆起来”。

要说明这种效应有多强大，可以想象一下下面的情况：

让一组人记住一个单词或句子，仅使用文本。72小时后，大约只有10%的人能记住这些信息。如果你添加一张图片，这个数字会增加到65%。如果图片有颜色，那么这个数字会高达85%！这可能是因为彩色图像在记忆中具有“更丰富”的表达方式。最好的方法是将文字和图片结合起来。

可视化是我们最强大的感觉，它占用了我们大脑资源的近一半。其中大部分是针对图像的，而不是文字。

首先，图像是并行处理的，这意味着我们可以同时处理多张图片，而语言信息则是顺序处理的——也就是说，我们一次处理一个片段。此外，它们在大脑的不同部位进行处理。

因此，通过使用图片和模型，我们可以减轻阅读和记忆的脑力负担。同时，我们还可以大大提高读者记住信息的可能性。此外，将信息浓缩在像思维导图这样的模型中比将其写成文本要容易得多。即使是像列表这样的东西——为了传达同样的信息，你需要详细说明更多内容。

最后，由于它如此优越——它也更有可能引发讨论并发现错误的假设，而不是发送一份非常冗长的文档。它不仅可以作为测试场景的通用语言使用，还可以用于系统文档、需求规格说明。当然，你可能需要调整模型以反映不同的方面，但这要比重新编写文档容易得多。

有模型可以解决这个问题

让我们来看看几种常见的模型及其适用的场景和时机。

流程图

流程图将一个过程分解为一系列的步骤。它是一种非常通用的工具，可以适用于各种不同的目的，并可用于任何类型的过程。对于更好地理解过程、沟通、文档化或识别过程中的缺陷（改进的空间）非常有用。

另一方面，它很容易变得非常复杂，因为过程很少像我们希望的那样非黑即白。在上面的例子中，您看到的是一个非常抽象的保险索赔流程视图。在现实生活中，这通常是多个不同的泳道和可能的流程，因此，为了使流程图有用，必须能够找到一个足够小且简单的流程部分进行文档化。但是，如果太小，它又会变得没有那么有用。

状态图

状态图旨在以状态的形式可视化系统，其中每个状态都有一套不同于其他状态的特定特征。它以状态、转换和转换过程中发生的事件来描述系统。只要潜在的状态和转换较少，状态图就是展示系统行为的极佳方式。就像流程图一样，状态图很容易变得过于复杂或需要太多抽象才能真正有用。

在软件开发中，就像在测试中一样，确定测试用例是一个很好的方法，因为这些转换是找到可能出现问题的地方（即风险）的重要输入。

数据库模型

数据库模型是表、字段及其之间的关系的视图。

在下面的例子中，您可以看到一个非常简单的表格，其中包含客户、订单、订单行和物品。在这个例子中，一个客户可以有多个订单，但每个订单只有一个客户，一个订单可以有多个订单行，但每个订单行只属于一个订单，每个订单行引用一个物品，而每个物品可以存在于多个订单行中。实际上，数据库要复杂得多，数据库图表可以包含更多信息，例如索引、字段格式、适用的规则以及更多内容。

时间管理——紧急与重要

可视化模型有很多不同的类型。“紧急 vs 重要”矩阵就是一个与软件无关的很好的可视化模型示例。它是一个优秀的工具，可以帮助您管理时间和优先处理任务，确保您按照正确的顺序完成最重要的事情。我们经常把太多的时间花在紧急但不重要的事情上，其实最好提前规划时间，以免它们变得紧急，或者花在不紧急也不重要的事情上，这些事情我们最好完全不做。它还可以帮助我们找到可以委派的任务，即重要但可能由他人完成的任务（如果有需要，我们可以提供支持）。

卡诺模型

卡诺模型将功能分为如果提供或不提供，它们会让客户感到多么满意。该理论认为，如果我们没有提供客户期望但可能没有明确表示他们期望的功能，他们会非常失望。我们需要识别这些功能。提供他们未曾期待的功能可能会让他们感到惊喜，而不提供则不会影响客户满意度。该模型是优先处理待办事项清单和优先安排测试的有效方法。

思维导图——心灵的指南针

我倾向于采用的可视化模型是思维导图，我发现它非常适合表达我的特定大脑对测试场景、需求和系统描述的思考方式。它们可以用来可视化计划和场景之间的关系，可以替代状态报告，而且最重要的是：它们非常擅长定义需求、业务规则和详细说明系统行为。

它们和其他模型一样，都有局限性，尤其是在事情变得复杂之后。在某些时候，它们会变得过于复杂，以至于难以跟踪。但公平地说，文档也存在同样的问题，它们往往会很快变得太大而无法使用。

我发现思维导图有一种给信息提供结构的方法，可以在几乎不增加额外负担的情况下添加边界和上下文。我知道这取决于个人喜好，但对我来说，它们可以让我的大脑以恰到好处的抽象程度理解非常复杂的领域，而不受限于单一的格式，并允许我根据发现的新信息调整和改变模型。

用数字化方式来做这些事情最符合我的工作方式，因为我可以在工作的过程中拖动和移动各种元素，从而更好地理解它们。这也是一种很好的开始对话的方式，而且改变它的所需努力非常低，因此非常适合团队协作。

让我们回到项目和测试负责人那里看看情况

我给自己定了三条基本原则，以便让这个目标变得可行：

从你所知道的开始——弄清楚你所知道的，不要因为未知的事物而感到恐慌。
可行 - 我们将首先专注于简单的情况（80%），如果时间允许再逐步增加复杂度。
简化 - 将相似的行为归类并尽可能多地使用可视化元素代替文本。

“……有一些我们知道的已知事物；这是我们知道我们知道的事物。我们也知道有一些已知的未知事物；也就是说，我们知道有些事情我们并不知道。但也有一些未知的未知事物。”

——唐纳德·拉姆斯菲尔德

首先，我们试图弄清楚我们已经掌握了哪些知识，并列出了需要进一步了解的所有事项。

为了做到这一点，我阅读了大量的文件、数据库模型和代码。我把所有信息都整理成一个庞大的思维导图，其中包括各个领域的信息、配置信息、业务规则和其他可能相关的信息。

我利用各种不同的“预言家”（文档、旧的测试用例、代码和我的业务专家）——形成了一系列可以被证实或证伪的假设。不断重复这一过程，直到我们所有人都同意一个“正确”的模型为止。

我们聚集在一起，达成了共同的语言，增进了理解。我们从一个悲伤、压力重重的团队和一群愤怒的用户，转变为一个团结一致、有着共同目标的团队。我们从审查转变为讨论。

我们以一种我们认为可以实现的标准作为起点，以帕累托原则（又称80/20法则、关键少数定律、要素稀缺原则）为基础。这个原则指出，对于许多结果来说，80%的后果来自20%的原因。这个原则由约瑟夫·M·朱兰提出，而且奇怪的是，它似乎可以适用于几乎所有的场合。

80%的bug存在于20%的代码中。80%的系统使用发生在20%的功能中。80%的工作可以在20%的总时间里完成。80%的销售额将来自20%的客户。我们团队以及主要利益相关者一致同意，先专注于“简单情况”，如有必要，再手动解决复杂情况。

帕累托原则

在工作的过程中，我们发现了许多有趣的发现！我们发现许多领域和业务规则不再使用。有些可能从未被使用过。这些可以从模型、代码和数据库中删除。我们发现文档、业务专家预期的系统工作方式和代码之间存在不一致之处。这最终变得非常重要，我们决定放弃最初的“迁移和复制”方法。最初的计划是尽可能少地更改代码，只更改足够的代码，使新的SQL数据库和旧的Oracle数据库完全相同。在查看这些不一致之处时，我们意识到可以通过修复代码中的问题来节省时间——使期望的行为与代码相匹配——这反过来允许我们删除大量代码。例如，一个用于手动调整的完整功能，不再需要了。整个功能都是因为开发人员和主题专家无法相互理解而构建的。

我们通过在纸上打印思维导图、运行测试并核对结果来进行测试。有了这些模型，我可以轻松地组合和重复使用测试。通过传统的等价类划分和双边测试，我减少了最初的组合。只需几分钟，我就可以轻松覆盖最初的10-20个测试用例，并在几天的测试中覆盖所有相关用例，整个过程中我始终对自己的覆盖率充满信心。在我们将工作/验收测试人员接手后，他们几乎未发现任何bug，交接工作从痛苦变成了乐趣。

最终，我花了三天时间才完成了对7188480种组合（确切地说：所有实际可行且相关的组合）的估算。

通过使用这些可视化模型，我们能够在减少测试时间的情况下扩大覆盖范围。我们找到了一种更易于维护的文档编写方式，可以减少误解。这提高了我们的业务理解能力，使得新员工更容易上手。由于思维导图的格式不允许包含太多文字，因此你必须去除所有多余的内容，直击问题的核心。没有商业术语，也没有技术术语。只有例子、图片和少量文字。