怨言家
PDF在 QA 工具沙漠中跋涉
谁应该为代码缺陷真正负责？
Terry Coatta，Silicon Chalk
软件界的耶利米们正在那里哀叹：“软件有缺陷且不安全！” 就像圣经中的先知哀叹他人民的邪恶一样，这些不满者告诉我们，我们必须忏悔并改变我们的方式。 但是，作为一名参与构建商业软件的人，我心里想，“我不需要忏悔。我确实关心软件质量。” 即使如此，我也知道我犯了错误。 我发布了带有缺陷的软件。 我为什么要这样做？ 为什么我不能一直发布完美的软件？
就像生活中的任何事情一样，原因很复杂，但一个重要因素是 QA（质量保证）有多么困难。 你可能要花费数天甚至数周的时间来寻找一个缺陷，最终你会达到这样一种地步，即为了寻找一个似乎永远也找不到的缺陷而阻止产品发布是没有意义的。
在这样的时刻，当我似乎要输掉与缺陷的战斗时，我真的对我们必须花费时间构建本应成为基本开发基础设施一部分的工具感到恼火。 有些人可能会指责我是一个抱怨者。“听着，你已经有了像 Purify 和 BoundsChecker 这样优秀的工具。 别再抱怨了，开始生产更好的软件吧，”他们说。 我喜欢这样的程序，别误会我的意思。 但这些对我来说不是 QA 工具。 如果你的组织和我的一样，你会发现开发人员在使用这些工具，而不是 QA 人员。
让我们退后一步，问问 QA 中发生了什么，因为这真的是我们理解需要什么工具的唯一方法。 QA 位于需求与软件实际功能之间的接口。 这意味着我们关心将需求转化为测试用例，运行软件来执行这些测试，跟踪结果，并将结果反馈给开发人员。
这些中的每一个都是软件可以帮助自动化流程或提高效率的地方。 这并不是说它完全是一片沙漠。 有许多优秀的缺陷跟踪系统，包括开源的和商业的。 帮助表示和执行测试的工具也开始出现 (http://www.eclipse.org/test-and-performance/faq.html 和 http://www.junit.org/index.htm)。 甚至还有一些标准可能有助于为测试工具创建一个更像组件的市场 (http://www.omg.org/cgi-bin/doc?ptc/2004-04-02)。
但是开发工具和操作系统的供应商可以很容易地添加一些非常明显的功能来帮助改善这种情况。 如果你以 QA 为生，你可能会每天都遇到它，而且，如果你和我一样，你会发现自己喃喃自语地咒骂，因为显而易见、易于实现且非常有用的功能就是不存在。 并且没有任何迹象表明它们很快就会到来。
你花费多少时间来尝试确定性地重现问题，以便在向开发人员解释时避免显得很无能：“我发誓昨天缺陷还在那里，但我似乎今天就是无法让它重现。” 考虑一下有多少缺陷是因为无法可靠地重现以供开发人员跟踪和修复而被发布了。
解决这个问题的唯一方法是通过程序化地驱动用户界面 (UI)。 在我工作的地方，我们为 Microsoft 操作系统构建软件。 你可能会期望开发环境会包含一个标准的测试框架，使你能够轻松地构建测试脚本、执行它并验证结果。 毕竟，操作系统清楚地了解 UI 布局，知道如何驱动 UI，并且可以观察结果。 可悲的是，根本没有这样的东西。 起初，我们只是尝试做更多的测试。 我们确保我们所有的测试机器都安装了开发环境，这样如果出现缺陷，我们就可以立即抓一个开发人员来处理它。 即使如此，也很明显我们正在输掉这场战争。 我们研究了允许你记录鼠标移动和操作的商业软件，但由此产生的测试太脆弱了。 如果屏幕布局发生变化，相应的测试就会失效。
即使看起来我们花费在测试工具上的精力比我们生产的实际软件还要多，我们还是决定构建一个像样的测试框架。 我们在产品中添加了代码，以便它将所有 UI 组件注册到一个中央注册表中。 该注册表有助于保留产品用户界面的抽象概念，该概念在某种程度上独立于 UI 组件在屏幕上的实际布局。 我们为一种 UI 脚本语言设计并构建了一个编译器，该语言可以从外部驱动应用程序。 我们添加了一个通用的拦截机制，以便我们可以跟踪应用程序响应 UI 刺激的活动。 这个系统帮助我们确定性地重现了以前无法捉摸的错误。
我们现在真的可以生产更好的软件了。 但是这个系统的每一部分都应该是开发环境的基本组成部分。 操作系统已经拥有每个 UI 组件的注册表，那么我们为什么要构建另一个？ 操作系统已经拥有驱动 UI 的机制，那么我们为什么要构建更多？ 操作系统知道组件何时相互调用，那么我们为什么需要构建拦截机制？ 可悲的是，答案似乎是测试根本不在设计和构建这些系统的人们的考虑范围内。
这不仅仅是供应商提供的其他强大的工具集中的一个小小的遗漏。 相反，这似乎是相反的。 考虑一下在发现缺陷时向开发人员提供有关应用程序状态的有意义的数据的任务：跟踪逻辑控制线程的状态跟踪、死锁的依赖性分析以及链接不同底层交互样式（例如 Windows 消息和函数调用）的集成控制流分析——更不用说涉及测试分布式在多台机器上的应用程序的 QA 了。 这些中的大多数对于供应商来说都不难提供。
那么是什么阻止了他们呢？ 我认为基本问题是 QA 没有编码那么性感（在软件开发领域中的任何事物可以被认为是性感的情况下）。 开发人员倾向于为开发人员开发。 所以，这里有一个行动号召：世界各地的 QA 人员联合起来！ 让我们要求我们应得的工具。
TERRY COATTA 是 编辑咨询委员会的成员。 他是 Silicon Chalk 的开发副总裁，该公司正在为高等教育创建实时协作软件。 在此之前，他曾担任 Open Text Corporation 分布式系统开发总监。 他拥有不列颠哥伦比亚大学计算机科学博士学位。
最初发表于 Queue vol. 3, no. 1—
在 数字图书馆 中评论本文
更多相关文章
Sanjay Sha - 企业应用程序的可靠性
企业可靠性是一门学科，它确保应用程序将在一致、可预测且经济高效的方式下交付所需的业务功能，而不会损害可用性、性能和可维护性等核心方面。 本文介绍了一组企业可以应用的核心原则和工程方法，以帮助他们驾驭复杂的企业可靠性环境并交付高度可靠且经济高效的应用程序。
Robert Guo - MongoDB 的 JavaScript Fuzzer
随着 MongoDB 随着时间的推移变得更加功能丰富和复杂，开发更复杂的方法来查找错误的需求也在增长。 三年前，MongDB 将一个本土的 JavaScript fuzzer 添加到其工具包中，它现在是我们最多产的错误查找工具，在两个发布周期中负责检测到近 200 个错误。 这些错误跨越了从分片到存储引擎的 MongoDB 组件，症状范围从死锁到数据不一致。 fuzzer 作为 CI（持续集成）系统的一部分运行，它经常在新提交的代码中捕获错误。
Robert V. Binder, Bruno Legeard, Anne Kramer - 基于模型的测试：它的现状如何？
您可能听说过 MBT（基于模型的测试），但像许多没有使用过 MBT 的软件工程专业人员一样，您可能对其他人使用这种测试设计方法的经验感到好奇。 从 2014 年 6 月中旬到 2014 年 8 月初，我们进行了一项调查，以了解 MBT 用户如何看待其效率和有效性。 2014 年 MBT 用户调查是 2012 年类似调查的后续调查，向所有评估或使用过任何 MBT 方法的人开放。 它的 32 个问题包括在 2013 年高级自动化测试用户会议上分发的一项调查中的一些问题。 一些问题侧重于 MBT 的效率和有效性，提供了管理者最感兴趣的数据。
Terry Coatta, Michael Donat, Jafar Husain - EA 的自动化 QA 测试：事件驱动
对于数百万游戏爱好者来说，在 Electronic Arts 担任 QA（质量保证）测试员的职位一定像是一个梦想的工作。 但从公司的角度来看，与 QA 相关的开销可能会显得非常可怕，尤其是在大型多人游戏时代。
© 保留所有权利。