我们思考,什么需要测试覆盖是“完整的”的方式,影响了我们如何测试和创建的测试用例。毕竟,一般情况下你只会为发生在你身上的情况设计测试——正常来讲,你也只能测试那些看得到的东西,是时候该脱下眼罩了。

下面介绍如何能在你的产品中找到发生bug的地方,接着调整你的策略来精确地定位到它们。


当我在一家保险公司工作时,我处理了大量的数据提取程序。在那段时间里,我从来没有见过一个需求文档来指明数据库关闭时应该做什么,即便大多数测试都是基于这些需求的。

任何专家都可以使用需求文档并创建一个地图、要点或电子表格来构建一个“覆概率模型”。整个软件公司都存在可视化这些模型,当测试“覆盖”到这些功能时,把它们设计成全部从空白闪烁到绿色。

然而,不可避免的是,当接口在运行而数据库关闭的时候,将会发生什么事情……不可预知。

到处都是盲点。我们就是看不到它们。

自动化测试

在类似于客户测试的世界中,今天对测试的主要思考方式是基于用户界面和工具。按住一个按钮,看着屏幕飞过(或基于云的客户端),然后一个小时后回来并得到结果。这是惊人的——几乎是神奇的。

我使用这些工具的经验是它们不能打印,或者说如果它们能,这些工具缺少检查生成的PDF文档是否呈现正确文本能力。它们当然不能检查结果是否正确。大多数工具甚至不能通过模拟的对比发现错误的地方。当一个人可以在一个复杂的表单上连续按十次tab键来检查tab顺序时,这项工作是如此难以编程,以至于大多数人都跳过了对tab顺序的任何自动检查。

工具变得越来越好。几年前,人们常常混淆屏幕,使按钮或链接不可见,因为它隐藏在其他东西下面,但是Selenium之类的工具可以单击它。今天,一些工具解决了这个问题。其他人添加了对屏幕的一部分进行用户界面比较的功能,以及用于快速审批的工作流。

不过,你还是明白我的意思。该工具使测试打印成为不可能。当我们不为打印创建自动化测试时,最终我们将停止测试打印。

我们认为测试的覆盖率是“完整的”,或者“测试是完整的”可能意味着什么,这将影响我们所做的事情。

功能测试

当我教授测试时,我早期的经验之一是关于失败模式的——也就是说,软件可能崩溃的方式。这包括两种常见的缺陷,比如程序员反复犯一些相同的错误. (“不管他们接触到什么,开发者似乎总是在破坏ALF组件”),以及平台常见的故障模式。如果我在用一个低成熟度的团队测试一个移动应用程序,我可能会尝试从拥有无线数据到没有覆盖,然后再回来。

对于具有复杂图形的web应用程序,我将大量调整窗口的大小。我将打开多个选项卡并在它们之间切换。我将在平板电脑上试用这个应用程序,然后把平板电脑翻转过来。我将发送一个链接到另一个需要登录的设备,并尝试在不登录的情况下访问链接。所有这些都是响应式设计的常见故障模式,但我从未在任何仪表板或正式的测试步骤中看到过它们,除非我的公司创建了这个列表。

也许资深人士“只知道”要根据经验来测试这种方法。资历较浅的人当然不会。测试方向变得越规定性,我们越专注于把事情写下来以便我们可以雇佣低技能的人,我们就越有可能得到这样的结果:人们完全按照测试说的去做,他们错过了所有的错误。

使用测试工具,这不是一个风险;它是保证。自动化工具只会按照您的要求去做。与此同时,评估调整窗口大小的结果是一项非常复杂的任务,非常难以编写。

因此,人们不需要记录自动化或构建逻辑来模拟这些行为。

也许,在某种程度上,这是可以的。另一位测试培训师詹姆斯·巴赫(James Bach)曾告诉我,有些人不想花钱买手工制作的木制家具。对他们来说,便宜的、自己组装的配件就足够了。制定计划,让电脑来做裁剪——够好,毕竟,足够好。

但是在软件中,廉价的、千篇一律的测试(和测试工具)意味着缺失bug,这可能是因为覆盖模型没有考虑它们。

新策略

这里有一种方法,可以让你在午餐时间和一天之间找出你错过了什么。

看看在过去的6个月里,程序员漏掉的所有bug。(如果你的敏捷团队没有跟踪这些,你可能想要开始,至少在短时间内。) 对于每一个人,不要把它与根本原因联系在一起,而是与他们将如何被看见——他们如何显现——联系在一起。

然后查看每种减少缺陷的机制,从代码评审到人工探索再到工具。如果可以的话,问一问你现有的正式流程是否已经发现问题,而且如果确实是已经发现了也需要问一下。

接下来做两件事。分别从人员和流程两方面着手,以防止整个类别的缺陷,并消除盲目性。找到bug所在,并调整测试策略来找到它们。考虑一个覆盖模型,它是关于缺陷类型的,以及您使用测试、检查、观察和走读来“覆盖”它们的所有方法。

我们有理由为盲人辩护;他们帮助马直走。它们也阻止了探险。

谁想要?

加我微信:atstudyIT  回复关键词“测试”领取限量软件测试学习资料哦~~