测试工具如何创新

本年度的测试工具 Jolt 大奖最近公布，社区专家 Andrew Binstock 认为测试工具多年来没有任何创新，他在文章中说，对这些产品的实现质量感到非常高兴，唯一的遗憾是它们大部分只支持 Windows 平台。质量对于测试工具来说非常重要，特别是对于编译器和调试器来说，因为通过测试工具引入的 Bug 会让测试人员和开发人员搞不清楚到底是测试的产品出了问题还是测试工具本身出了问题，让他感到失望的是，年复一年，测试工具没有什么创新。它们总是把已有的概念实现并应用到新的平台上。今年也是一样，主题与移动领域和与计算领域有关。是的，这些平台需要测试工具，但是也许开发者需要的测试功能不仅限于以下几条：

• 代码检查
• 单元测试
• 界面测试
• 浏览器测试
• 负载和性能测试

Andrew 列举了一些他认为比较创新性的测试功能：

• 自动化黑盒测试
• Fuzz 测试
• 配置测试
• 安全测试
• 灾难恢复测试
• 隐私测试（当你关闭应用时，应用把内存中的敏感数据删除了吗？目前很难测试这一点，也没有相应的测试工具，只能编写特定的脚本来运行）

他认为目前各种测试功能的支持方面最大的问题是缺乏自动化，“自动化”意味着录制、回放。这意味着编写脚本来测试不是自动化，测试工具应该从界面上来支持自动化，而不是要求测试人员在后台编写脚本。

Andrew 举了一个实际工作中的例子，在测试 Web 应用的时候，他希望能够运行测试工具自动生成检查安全问题的测试脚本，包括 SQL 注入、空字符串攻击、CRLF 攻击、非常 REST 命令、cookie 攻击、多次登陆、缓存溢出等等。Andrew 还希望在测试一个整型参数的函数时，测试工具能够准备好何种边界值，比如最大整型值、最小整型值、-1、0、1 等等。如果参数是字符串类型，那么测试值应该包括 null、空字符串、30000 个字符长度的字符串、随机字符串等等。如果应用读取一个输入文件，那么测试工具应该考虑到文件不存在、空文件、大小超过 2G 的文件、特殊名字的文件等等。如果是文本文件，那么测试工具是否考虑了外国字符的情况？

虽然测试情况可能有成百上千种，，但是目前的测试工具可能只考虑了几种条件。Andrew 希望测试工具能够做到：

• 抓取异常情况
• 模拟异常输入
• 通过良好的界面报告测试结果

这种理想情况可以大大减轻测试人员的脚本准备精力投入。

提到测试工具的录制和回放功能，测试专家 Lisa 和 Janet 在“敏捷测试指南”一书中对该领域有过深入的探讨：

我们已经提到过记录 / 回放工具的一些缺点，但只要用对地方，他们还是有用的。你可以在下面这种情况下使用记录 / 回放工具：或许遗留代码拥有了一个使用该工具创建的自动化测试套件，团队也拥有该工具的使用经验，或是管理层出于某种原因想让你使用该工具。你可以将记录脚本作为起点，接下来将该脚本划分为几个模块，使用恰当的参数替换掉硬编码的数据，将模块作为构建块来组装测试。即便你没有太多编程经验也不会影响到如何将脚本块放到模块中。比如说，登录就是一个显而易见的选择。

Lisa 举了一个例子。Gerard Meszaros 是一位敏捷教练，同时也是“xUnit Test Patterns”一书的作者，他描述了一种情况，其中最简单的办法就是使用记录 / 回放。我们曾提到过记录 / 回放工具的缺点，但如果设计代码时就支持他们，那么他们也能成为最好的方法。有团队曾求助 Gerard 将一个“高度重视安全”的应用由 OS2 迁移到 Windows 上。其业务主要关注于测量迁移系统所花费的时间以及团队忽略掉重要 bug 的可能性。设计该系统的目的在于向用户提供有效选择而不会危及系统的安全性。他们考虑使用一个测试记录工具来记录旧系统上的测试并在新系统上回放，但并没有适合于 OS2 和 Windows 的测试记录工具能够使用 ASCII 字符处理类 Windows 绘图。在审查了系统架构后，Gerard 认为编写 xUnit 测试并不是一个有效的系统测试方式，因为很多业务逻辑都嵌入到了用户界面逻辑当中了，重构代码将其分隔开来风险又太高，也比较花时间。因此，我们提议在移植前为系统开发一个记录 / 回放测试功能。

即便项目的其他部分是里程碑驱动的，Gerard 也使用敏捷方式开发了内建的测试机制。每个界面至少需要一个新的回调，有时也需要几个。Gerard 从使用最为频繁的界面开始，增加必要的回调来记录用户的行为和系统对其的响应（保存到 XML 文件中）。他还增加了回调以回放该 XML 并观察测试结果。一开始，Gerard 主要将回调放在需要记录的界面上并使用简单但实际的测试进行回放。在所有人都相信这种方式可行后，他们根据界面所能提供的好处对其进行优先级的划分。一个一个地实现了回调直到可以自动化重要的测试为止。还创建了一个 XSLT 样式表，它可以适合于 Fit 的方式格式化 XML，绿色单元格表示接受的测试而红色单元格表示失败的测试。与此同时，客户确定需要测试用例的测试场景。由于已经完成了足够的界面来记录特殊的测试，客户通过记录与回放（仍旧在 OS2 上）测试进行“验收”测试。当所有的回调就绪后，可以更进一步并开始从 OS2 到 Windows 移植代码了，包括测试回调。在 OS2 上成功验证完回放后，客户会将 XML 测试文件迁移到 Windows 上并再一次针对移植版本的代码运行。客户发现这么做很简单并且可以在相对少的时间内记录大量的测试。由于测试记录了行为以及业务上的响应，因此他们很容易理解。客户喜欢这种方式，它节省了大量的时间，同时对产品也更具信心了。“这不仅节省了大量的测试工作量，甚至还发现了遗留系统中隐藏很深的 bug，这就是 Gerard 所说的黄金标准”。在 Gerard 的故事中，团队一起将可测试性追加到并不适合测试的系统中。他们给予客户一种手段，在一个平台上捕获测试场景并在两个平台上进行回放来验证该移植是成功的。这是团队方法的鲜明示例。在团队协作进行测试自动化方法的探索中，有更多成功的机会。