通过大量测试来构建测试系统

在 Agile Testing Days 2015 上， James Lyndsay 办了一个名为“测试巢”的工作坊。在这次工作坊中，他探究了如何设计微小测试的大型集合并将他们的输出显示在测试系统上。他还展示了如何使用工具来帮助我们做到这种测试。InfoQ 就他的这种测试方法采访了他。

InfoQ：你可以解释一下你用“测试巢”的意思吗？

Lyndsay：鸟巢是用上百块脆弱的碎片组成的——它们独立来看都有欠缺，但是放在一起就可以保护一个正在成长的家庭。作为测试者，我们可以采用单独看来无聊或微不足道的方法，它们可以支持我们探究有关我们正在建立的系统的、更深的真理。他们是押韵的，这是令人愉悦的一件事。

如果想要知道我说的是什么意思，可以看一下 Mike Bostock 的“ Will it Shuffle ”。在这一页面上，Bostock 用建立一个 1800 尺寸的图像展示了随机算法的缺陷，它们用这个算法显示了 10000 个独立的运行结果的总结。在这张图像中，Bostock 用颜色来展示随机选择的倾向，所以图像的色彩越多越规律，算法缺陷越大。因为算法用了一个取决于浏览器端的内建函数，所以一样的代码在不同的浏览器端会显示不同的涌现性，也因此展示了不同的缺陷。一个独立的随机选择不会告诉我们这些，但是 10000 个随机选择就会暴露这些缺陷。选择并建立一张正确的图像会让我们更容易注意到这些不同。

InfoQ：你认为测试中的可视化的重要性有哪些？

Lyndsay：可视化将许多量化的结果放在一个适合我们大脑的、惊奇的视觉过程的模式中，这使得数据中的信息可以影响我们脑中的模型和我们在团队中发展的共同理解。一个图像值得用一千个数据点来构造。

InfoQ：在你的工作坊中，你问了观众他们用什么工具来使数据可视化。那你听下来，他们用的最多的是哪些工具？你建议用哪些工具？

Lyndsay：Excel。这是测试者们通用的“螺丝刀”。它可以画出很不错的图像，还可以将数据处理、过滤、排序。然而，用名字在列与列之间转换很不方便，这使我们在数据中找出原数据变得痛苦。我认为我们可以找一个大数据的工具，例如 Splunk 和 Kibana，来更好地分析测试结果，并且我也很乐意在今年晚些时候玩一玩这两个工具。但是绘图工具也是链子上的一环，所以我们也需要工具来帮助我们生成和应用数据。

InfoQ：你在工作坊中提到你经常用散点图来使数据可视化。你可以解释一下这是如何做到的吗？

Lyndsay：我用了一种工具，是 Visual Data Tools 的 DataGraph 。这让我从很多测试中获取了度量表，使划分表格的列变得简单——这使得我能够在度量之中过滤、上色并调整元素的大小。DataGraph 需要付费并且只能在 OS X 中使用，但还有一个不错的开源工具—— DensityDesign 的 Raw ，它是浏览器端的并且有很不错的散点图。

InfoQ：在什么样的情况下你会推荐用许多自动生成的测试？

Lyndsay：我很快找到了一些有趣的、在探索性测试中驱动组件的问题。例如，代码或单元测试会引导我走向需要一个或多个输入范围的算法。如果这个算法只在一些独立的情况下被检查，我会通过组合变量生成一些细节或大概的范围，并用图来显示其中的重点。

我还在寻找集成测试中的 surprise 时有了很大的进展，特别是当一些组件是用不同技术实现时或当一个简单的解决方案用很强大的部分来建立时。

这方面没有什么特别新奇的东西了，并且性能测试与模糊测试有清晰的比较。

InfoQ：那你什么时候不推荐使用它？

Lyndsay：它对于系统中任务重的部分很容易有限制。你需要善用你的工具，并且任何意义上的完整性都应该带有怀疑——即使它看起来很显然，它通常会更深入。它不是一个有效地验证行为的方法，然而很多时候度量都是符合预期的。

有的时候你会使你写代码的同事感到灰心。但是有的时候我们需要对我们在建立的系统苛刻——远远超过简单的代码层面——来找到真理。

InfoQ：这种测试途径的好处有什么？

Lyndsay：这是一个来显示系统行为范围的快速且省事的方法——并且如果那些行为令我们感到意外，我们还有机会接近理解我们做过的真实的本质和风险。

查看英文原文： Testing Systems with a Nest of Tests

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。