当测试覆盖率达到100%了，软件测试员还会遇到什么问题？

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

正文：
下面介绍如何能在你的产品中找到发生bug的地方，接着调整你的策略来精确地定位到它们。
当我在一家保险公司工作时，我处理了大量的数据提取程序。在那段时间里，我从来没有见过一个需求文档来指明数据库关闭时应该做什么，即便大多数测试都是基于这些需求的。

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

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

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

自动化测试

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

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

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

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

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

功能测试

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

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

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

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

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

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

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

新策略

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

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

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

在这里推荐一个我自己创建的软件测试交流群，QQ：642830685，群中会不定期的分享软件测试资源，测试面试题以及测试行业资讯。大家可以在群中积极交流技术。还有大佬为你解答技术问题。

• 还没有人评论，欢迎说说您的想法！