自动化测试实践第一章

敏捷团队的自动化测试之旅：第一年

Lisa Crispin 以其特有的迷人方式描述了当一个敏捷团队决定实施自动化测试时所发生的 事情。由于 Lisa 在敏捷技术方面的专业能力，当看到这支团队在实践中确实非常敏捷时，我们 一点儿也没有感到惊讶。这个项目中一件有趣的事情就是 ：团队（小型团队）里面的每个人都 参与了自动化。他们不仅擅长敏捷开发，而且非常敏捷地对其进行了自动化——并且他们成功 了。实施敏捷开发并不是这支团队取得成功的唯一要素，其他要素也同等重要，其中包括通过 良好的沟通建立稳固的管理关系，以及建立自动化平台来支持创造性的手动测试。另一个关键 要素是在团队将过程改进嵌入到整个流程的决策力，包括一年两次的自动化重构的安排。毫无 疑问，Lisa 和她的团队在他们第一年的时间里所取得的成就是非常显著的。这个项目是为一家 美国公司的财务部完成的，特征见表 1-1。

1.1　本案例研究的背景 

我们必须面对这样的事实 ：对于从未进行过自动化测试的人来说，自动化测试是具有一定 难度的。本故事告诉我们，面对无任何自动化的测试和有着糟糕设计的遗留系统，这支团队通 过一年多的努力，将所有的回归测试都实现了自动化。在接下来的几年时间里，我也与数十个 其他面临同样困境并找到类似解决方案的团队进行了交谈。看看我们所遇到的这些困难是否与 你所遇到的相似，并考虑用类似的方法进行尝试。 

1.1.1　问题 

从这里开始着手 ：每两周我们都需要把新的功能添加到产品中，但是代码 bug 成灾并且也 没有自动化测试，更严重的是，产品中有大量随时会导致系统中断的 bug。我们如何摆脱这种 情况呢？

1.1.2　目标 

我们决心尽自己所能编写出最高质量的代码，但是从哪里开始呢？作为一支自组织的敏捷 开发团队，让我们感到欣慰的是整个团队的紧密协作。那是在 2003 年，我们中有些人在别的 团队中曾有过良好的自动化测试经验，他们相信总是会有办法的。我们发现，一个安全的自动 化回归测试网络可以让我们更快速地工作。如果我们知道是由于某段特殊的代码而引入的非预 期的操作，那么我们能够立即稳定我们的代码库。通过充分的测试覆盖来不断进行集成，使我 们每天都有一个稳定的构建过程。而在迭代的后期，现在很难得到稳定的集成，所以这个想法 虽然并非那么容易实现，但听起来很不错！ 

接下来，看看到底是什么帮助我们创建了一个成功的策略来实现自动化回归测试套件。 

1.2　整个团队的承诺 

我们是由多个程序员、一个测试人员、一个数据库管理人员、一个系统管理人员和一个敏捷教练所组成的团队。公司的业务专家可以随时协助我们。我们整个团队致力于在每次发布之 前运行我们的手动回归测试脚本。因为我们每两周发布一次，这意味着两周的迭代周期中我们 要花 1 ~ 2 天的时间进行手动测试。在最终用户使用之前，我们没有足够的时间来进行探索性 测试，虽然这种测试可能会帮助我们找到严重的缺陷。

我们都很关心质量，并且我们都致力于保证所有的测试活动都是有计划的且在每一次迭代 中执行。这是一个好的开始！

1.3　建立自动化策略 

我们需要在不破坏现有功能的前提下发布产品的新功能特性。而且，需要尽快知道一个 新的代码变动是否会引起回归测试的失败。手动回归测试在每两周的迭代后期才能给予我们反 馈，以至于没有时间进行充分的回归测试。

我们中一些人曾经在其他敏捷团队中进行过测试驱动开发（Test-Driven Development,  TDD）。我们发现 TDD 能帮助创建出设计良好的、健壮的代码。

我们现有的回归测试是手动操作的，整个团队通过使用团队 Wiki 上所记录的脚本进行手 动测试。在每两周的迭代周期中，这就花费了整个团队的 20% 的时间。这些测试仅仅为程序最 核心的部分提供了最小程度的覆盖。产品中报告的缺陷表明，回归测试的失败仍有可能发生。 在每次迭代周期中，我们至少要花 20% 的时间修复这些产品缺陷，从而限制了我们能开发的新 功能的数量。

自动化的回归测试会带来更高、更准确的覆盖率，这需要投入大量的时间、金钱和精力， 我们可能需要硬件和软件来建立构建过程、持续运行测试所需要的环境，我们也需要使测试实 现自动化的架构和驱动。然而，我们可以计算出这一自动化将会节省我们 40% 的时间，利用这 些时间可以进行更多有价值的活动，比如进行新的开发，所以，其收益远大于成本。 

继续进行手动回归测试必将会失败，我们需要一个明确的决策来进行自动化。因为我们都 在进行手动回归测试，每个人都感受到了没有自动化测试的痛苦。所以，我们有了解决这一问 题的动力。首先，我们需要一个可测试的架构…… 

1.3.1　一个可测试的架构 

TDD 这条路是要走的，但是当前的代码在业务逻辑、数据库访问和 UI 等处相结合时，情 况比较复杂，自动化单元测试也就变得很难了。往往很难隔离任何一个组件单独进行测试。 

这样看来，似乎找到一种把软件进行分层的新架构是非常明智的。我们开发出了这一新架 构的所有新功能。

如果进行自动化测试的成本比其收益高，那么进行自动化测试就没什么意义。我们研究 图 1-1 所示的自动化测试金字塔（这一金字塔是由我们当时的经理 Mike Cohn 提出的）。单元级 别的测试一般 ROI 最高。程序员可以很快写出它们并运行，而且测试可以根据需要进行更新。 因此可以将单元级别的测试作为自动化回归测试的坚实基础。

我们的业务逻辑相当复杂，而且新架构将这一逻辑从数据库和用户接口层中分离出来，这 样就可以通过设置内存中数据并在其上运行产品代码来进行测试。这是金字塔的中间层——— 比底层运行的测试要少但是依然很重要。

我们还需要测试 UI，但是通过 UI 进行的自动化测试本身就非常脆弱、维护费用高且运行 缓慢。因为最终想使 UI 测试所占的比例尽量最小，所以它就处在金字塔的最顶端。尽管如此， 与其他团队一样，我们从图形用户界面（GUI）冒烟测试（smoke test）开始，来获取一些代码 防护。所以，从这个角度，我们的金字塔是上下颠倒的，但是没关系———最终我们会将它翻 转过来。（我们最终花了 4 年时间才获得为之努力的三角形形状！）

我们现在明白了我们需要做什么，所以我们开始着手实施那个能给我们带来最大实惠的 任务。

如果有对软件测试感兴趣的小伙伴可以加群了解更多：点击进群https://jq.qq.com/?_wv=1027&k=9l9IEkml