软件质量保障
所寫即所思|一个阿里质量人对测试的所感所悟。
很久以前,有一个测试经理并不相信敏捷测试。当团队谈论减少资源浪费、项目冲刺和项目小规模交付时,她会礼貌地点头示意表示赞同。但转身之后,她会按照自己的原有的方式去做事情。对她来说这种方式才是有效的。而她的项目通常都能按时完成,交付质量也比较高,而且发布过程也比较“平稳”。
直到有一天,她遇到了瓶颈。负责的是一个“简单”的迁移项目,目标也很简单——“让它像以前一样运行”。直接迁移,轻而易举。然而,这是一个新组建的团队,应用程序逻辑可能有数百万种可能的组合。之前的测试活动记录得非常糟糕。需求和预期不清晰、缺失甚至自相矛盾。一些棘手的bug隐藏在过于复杂的代码中。这个项目开始看起来像是一个无法克服的挑战。再加上与用户和管理层之间紧张的关系,给团队施加了压力,让他们觉得这是提桶跑路最后的机会。如果这个项目不能顺利完成,他们将永远无法再次进行重构。总结下来就是:“时间紧迫,信息有限”。
我们饱受折磨的测试负责人试图坚持自己的立场,但命运似乎不愿给她所需的6-12个月时间。就在她快要放弃的时候,团队中一位目光炯炯的测试人员建议尝试使用思维导图。仅仅一天时间,思维导图就改变了她的整个看法……他们成功地将测试从缓慢、重复且混乱的状态转变为一个流畅、基于风险且以上下文为导向的测试活动。那位测试负责人就是我,我想分享对可视化模型的热爱,以及它们如何能帮助到你。
可视化模型——它们是如何工作以及为什么有效?
模型是在特定背景下对现实世界或概念的抽象化、简化的表示或模拟,用于理解、预测、解释或指导实践。它捕捉并突出了对象、系统、理论或现象的关键特征和关系,同时忽略或简化了次要细节,以便于分析、交流和决策。
但不是把所有信息都放在一个地方更好吗?其实未必。你有没有看过房屋建筑图纸?当你建造房屋时,你需要很多信息。你需要知道哪里排电线。你需要知道哪里装水管。你需要知道哪些墙是承重墙,等等。如果你在计划如何布置家具,你需要知道房间的尺寸、哪里有窗户和门、哪里有电源插座、哪里可以放置吊灯。但如果把所有这些信息都放在一张图纸上,它将毫无用处。相反,我们可能有同一栋房屋的不同用途的多个模型。你甚至可能想将它们合并,但如果把它们都叠加在一起,它们将毫无用处——会有太多噪音。如果你正在做一些完全不同的事情,比如规划你的花园或决定在哪里建围栏,你可能需要放大地图,关注土地边界、土地的整体轮廓以及房屋的位置和花坛、草坪、树篱的位置。也许你还需要考虑是否要建一个游泳池或客房。你需要一个模型,其中包含你所需要的所有信息,既不多也不少。
模型有各种形状和尺寸,其用途、优点和缺点各不相同。我们有物理模型,如太阳系机械模型(即天体仪)、分子模型、建筑模型、解剖模型,以及飞机的缩尺模型。所有这些模型都非常适合以更直观的方式展示物体的不同方面。想象一下,如果没有这些模型,展示行星如何相互运动、人体内部器官如何排列、分子中原子如何连接等知识会多么困难。想想如果没有这些模型,教这些知识会多么复杂。
然后我们有数学或统计模型,通过对数据进行各种计算来尝试发现模式和关系,并根据模型的结果进行预测。我们还有概念模型,试图描述和代表现实世界系统或概念的某些方面,以便更好地理解它们。在这个组中,我们有诸如流程图、状态图、系统图、数据模型、过程图、用户故事地图、沃德利地图和思维导图等工具。本文的其余部分将重点介绍这些工具,从现在开始,我将使用“可视化模型”这一术语。
出于需要,建模并不能呈现问题的全部情况。这意味着我们从模型中省略掉的内容将不会被考虑,而且我们的偏见也会反映在模型中。然而,这也是一种超级能力——因为它允许我们剔除所有无关信息,并将注意力集中在对我们来说最重要的特定方面。在我的例子中,理论上可能的组合中,几乎有一半在现实生活中永远不会发生。仅通过阅读需求和文档很难看到这些信息,但一旦将所有这些信息以可视化的形式呈现——即我的思维导图,这些信息就变得异常清晰。
任何模型都擅长屏蔽噪音。可视化模型尤其像是你的记忆中的作弊代码。与书面沟通和文档相比,它们在相对较短的时间内能够传达更多的信息。
当然,这在很大程度上要归功于抽象消除了噪音。还有一个有趣的现象叫做“可视化优势效应”(PSE),可以描述为:“输入越可视化化,就越有可能被识别和回忆起来”。
要说明这种效应有多强大,可以想象一下下面的情况:
让一组人记住一个单词或句子,仅使用文本。72小时后,大约只有10%的人能记住这些信息。如果你添加一张图片,这个数字会增加到65%。如果图片有颜色,那么这个数字会高达85%!这可能是因为彩色图像在记忆中具有“更丰富”的表达方式。最好的方法是将文字和图片结合起来。
![](https://img-blog.csdnimg.cn/img_convert/00c74c70bca4540ebbe133752534f47f.png)
可视化是我们最强大的感觉,它占用了我们大脑资源的近一半。其中大部分是针对图像的,而不是文字。
首先,图像是并行处理的,这意味着我们可以同时处理多张图片,而语言信息则是顺序处理的——也就是说,我们一次处理一个片段。此外,它们在大脑的不同部位进行处理。
因此,通过使用图片和模型,我们可以减轻阅读和记忆的脑力负担。同时,我们还可以大大提高读者记住信息的可能性。此外,将信息浓缩在像思维导图这样的模型中比将其写成文本要容易得多。即使是像列表这样的东西——为了传达同样的信息,你需要详细说明更多内容。
最后,由于它如此优越——它也更有可能引发讨论并发现错误的假设,而不是发送一份非常冗长的文档。它不仅可以作为测试场景的通用语言使用,还可以用于系统文档、需求规格说明。当然,你可能需要调整模型以反映不同的方面,但这要比重新编写文档容易得多。
有模型可以解决这个问题
让我们来看看几种常见的模型及其适用的场景和时机。
流程图
流程图将一个过程分解为一系列的步骤。它是一种非常通用的工具,可以适用于各种不同的目的,并可用于任何类型的过程。对于更好地理解过程、沟通、文档化或识别过程中的缺陷(改进的空间)非常有用。
![](https://img-blog.csdnimg.cn/img_convert/4f93f0c3b9a122a3d837764e481454eb.png)
另一方面,它很容易变得非常复杂,因为过程很少像我们希望的那样非黑即白。在上面的例子中,您看到的是一个非常抽象的保险索赔流程视图。在现实生活中,这通常是多个不同的泳道和可能的流程,因此,为了使流程图有用,必须能够找到一个足够小且简单的流程部分进行文档化。但是,如果太小,它又会变得没有那么有用。
状态图
状态图旨在以状态的形式可视化系统,其中每个状态都有一套不同于其他状态的特定特征。它以状态、转换和转换过程中发生的事件来描述系统。只要潜在的状态和转换较少,状态图就是展示系统行为的极佳方式。就像流程图一样,状态图很容易变得过于复杂或需要太多抽象才能真正有用。
![](https://img-blog.csdnimg.cn/img_convert/0d10a78ef20383058780cdf12901660c.png)
在软件开发中,就像在测试中一样,确定测试用例是一个很好的方法,因为这些转换是找到可能出现问题的地方(即风险)的重要输入。
数据库模型
数据库模型是表、字段及其之间的关系的视图。
在下面的例子中,您可以看到一个非常简单的表格,其中包含客户、订单、订单行和物品。在这个例子中,一个客户可以有多个订单,但每个订单只有一个客户,一个订单可以有多个订单行,但每个订单行只属于一个订单,每个订单行引用一个物品,而每个物品可以存在于多个订单行中。实际上,数据库要复杂得多,数据库图表可以包含更多信息,例如索引、字段格式、适用的规则以及更多内容。
![](https://img-blog.csdnimg.cn/img_convert/0b323bbcc95905830a968a8842bb7944.png)
时间管理——紧急与重要
可视化模型有很多不同的类型。“紧急 vs 重要”矩阵就是一个与软件无关的很好的可视化模型示例。它是一个优秀的工具,可以帮助您管理时间和优先处理任务,确保您按照正确的顺序完成最重要的事情。我们经常把太多的时间花在紧急但不重要的事情上,其实最好提前规划时间,以免它们变得紧急,或者花在不紧急也不重要的事情上,这些事情我们最好完全不做。它还可以帮助我们找到可以委派的任务,即重要但可能由他人完成的任务(如果有需要,我们可以提供支持)。
![](https://img-blog.csdnimg.cn/img_convert/9e12fca718fc6963af251d3c6fdf0ebf.png)
卡诺模型
卡诺模型将功能分为如果提供或不提供,它们会让客户感到多么满意。该理论认为,如果我们没有提供客户期望但可能没有明确表示他们期望的功能,他们会非常失望。我们需要识别这些功能。提供他们未曾期待的功能可能会让他们感到惊喜,而不提供则不会影响客户满意度。该模型是优先处理待办事项清单和优先安排测试的有效方法。
![](https://img-blog.csdnimg.cn/img_convert/06a8e45c4df4c70eb6fa078068aab9bc.png)
思维导图——心灵的指南针
我倾向于采用的可视化模型是思维导图,我发现它非常适合表达我的特定大脑对测试场景、需求和系统描述的思考方式。它们可以用来可视化计划和场景之间的关系,可以替代状态报告,而且最重要的是:它们非常擅长定义需求、业务规则和详细说明系统行为。
它们和其他模型一样,都有局限性,尤其是在事情变得复杂之后。在某些时候,它们会变得过于复杂,以至于难以跟踪。但公平地说,文档也存在同样的问题,它们往往会很快变得太大而无法使用。
我发现思维导图有一种给信息提供结构的方法,可以在几乎不增加额外负担的情况下添加边界和上下文。我知道这取决于个人喜好,但对我来说,它们可以让我的大脑以恰到好处的抽象程度理解非常复杂的领域,而不受限于单一的格式,并允许我根据发现的新信息调整和改变模型。
![](https://img-blog.csdnimg.cn/img_convert/35edf4ac0fc3d6d01a7303122eac6040.jpeg)
用数字化方式来做这些事情最符合我的工作方式,因为我可以在工作的过程中拖动和移动各种元素,从而更好地理解它们。这也是一种很好的开始对话的方式,而且改变它的所需努力非常低,因此非常适合团队协作。
让我们回到项目和测试负责人那里看看情况
我给自己定了三条基本原则,以便让这个目标变得可行:
从你所知道的开始——弄清楚你所知道的,不要因为未知的事物而感到恐慌。
可行 - 我们将首先专注于简单的情况(80%),如果时间允许再逐步增加复杂度。
简化 - 将相似的行为归类并尽可能多地使用可视化元素代替文本。
“……有一些我们知道的已知事物;这是我们知道我们知道的事物。我们也知道有一些已知的未知事物;也就是说,我们知道有些事情我们并不知道。但也有一些未知的未知事物。”
——唐纳德·拉姆斯菲尔德
首先,我们试图弄清楚我们已经掌握了哪些知识,并列出了需要进一步了解的所有事项。
为了做到这一点,我阅读了大量的文件、数据库模型和代码。我把所有信息都整理成一个庞大的思维导图,其中包括各个领域的信息、配置信息、业务规则和其他可能相关的信息。
![](https://img-blog.csdnimg.cn/img_convert/29d7b075d5b5d24b56d0050540affa9d.png)
我利用各种不同的“预言家”(文档、旧的测试用例、代码和我的业务专家)——形成了一系列可以被证实或证伪的假设。不断重复这一过程,直到我们所有人都同意一个“正确”的模型为止。
我们聚集在一起,达成了共同的语言,增进了理解。我们从一个悲伤、压力重重的团队和一群愤怒的用户,转变为一个团结一致、有着共同目标的团队。我们从审查转变为讨论。
我们以一种我们认为可以实现的标准作为起点,以帕累托原则(又称80/20法则、关键少数定律、要素稀缺原则)为基础。这个原则指出,对于许多结果来说,80%的后果来自20%的原因。这个原则由约瑟夫·M·朱兰提出,而且奇怪的是,它似乎可以适用于几乎所有的场合。
80%的bug存在于20%的代码中。80%的系统使用发生在20%的功能中。80%的工作可以在20%的总时间里完成。80%的销售额将来自20%的客户。我们团队以及主要利益相关者一致同意,先专注于“简单情况”,如有必要,再手动解决复杂情况。
帕累托原则
在工作的过程中,我们发现了许多有趣的发现!我们发现许多领域和业务规则不再使用。有些可能从未被使用过。这些可以从模型、代码和数据库中删除。我们发现文档、业务专家预期的系统工作方式和代码之间存在不一致之处。这最终变得非常重要,我们决定放弃最初的“迁移和复制”方法。最初的计划是尽可能少地更改代码,只更改足够的代码,使新的SQL数据库和旧的Oracle数据库完全相同。在查看这些不一致之处时,我们意识到可以通过修复代码中的问题来节省时间——使期望的行为与代码相匹配——这反过来允许我们删除大量代码。例如,一个用于手动调整的完整功能,不再需要了。整个功能都是因为开发人员和主题专家无法相互理解而构建的。
我们通过在纸上打印思维导图、运行测试并核对结果来进行测试。有了这些模型,我可以轻松地组合和重复使用测试。通过传统的等价类划分和双边测试,我减少了最初的组合。只需几分钟,我就可以轻松覆盖最初的10-20个测试用例,并在几天的测试中覆盖所有相关用例,整个过程中我始终对自己的覆盖率充满信心。在我们将工作/验收测试人员接手后,他们几乎未发现任何bug,交接工作从痛苦变成了乐趣。
最终,我花了三天时间才完成了对7188480种组合(确切地说:所有实际可行且相关的组合)的估算。
通过使用这些可视化模型,我们能够在减少测试时间的情况下扩大覆盖范围。我们找到了一种更易于维护的文档编写方式,可以减少误解。这提高了我们的业务理解能力,使得新员工更容易上手。由于思维导图的格式不允许包含太多文字,因此你必须去除所有多余的内容,直击问题的核心。没有商业术语,也没有技术术语。只有例子、图片和少量文字。
![](https://img-blog.csdnimg.cn/img_convert/d95e9e4a085311f554522a2c30c89e90.jpeg)
往期系列文章
- END -
下方扫码关注 软件质量保障,与质量君一起学习成长、共同进步,做一个职场最贵Tester!
往期推荐