为了能够跟上因敏捷软件开发而不断缩短的发布周期，很多开发团队都采用了自动化测试的方法，从而不断保证每个软件版本都符合所需的质量水平。

这是传统软件开发实践的一个重要转变：测试经常被卡在开发过程的最后，被视为了测试过程的负担，而并不是好处。

因此，一个在采用敏捷软件开发，转变为DevOps文化并采用持续集成和持续交付的组织中工作的测试人员，必须对于如何有效地实施测试自动化这一日常活动有一个基本的了解。

不幸的是，敏捷软件开发中的很多测试自动化工具都失败了，或者并没有最大化它们的潜力。

我想探讨一下我认为测试自动化没有办法满足敏捷软件开发过程中测试人员和其他利益相关者期望的两个最重要的原因。

然后，我们来看一下避免陷入这些陷阱的策略和手段，以便于在敏捷环境中成功实现测试自动化。

我看到这么多自动化工作没有成功达到预期的两个主要原因之一是因为实施前的不合理预期。

太多的团队负责人，开发和项目经理，以及C级管理人员（其他人员也并不是完全无关的）都将测试自动化视为所有测试瓶颈的一站式解决方法。

然而，实施已经一再表明：

• 实施自动化测试需要时间、精力和特定技能；

  
  

• 自动化是一个帮助测试人员的活动，而并非代替测试人员；

  
  

• 不是每一项测试活动都可以通过自动化实现。

然而，自动化测试依然被普遍认为能够用某种神奇的方式，按下按钮就能够为你执行所有需要的测试。

经过几个月的努力搭建和运行测试，这样的概念成为一种幻想。辛苦忙于自动化测试的测试人员往往成为了替罪羊，有时候甚至被解雇。

在我看来，测试人员和自动化工程师能够解决这个问题的最佳方式是在测试之前进行思考与沟通。

确保所有利益相关者在自动化方面的预期与你处于同一水平。参考组织内部以及更多软件测试和开发社区的先前的努力，从这些经验中学习。

应该如何做测试，什么可能会导致失败？不要期待自动化是解决所有测试问题的灵丹妙药。

自动化失败的另一主要原因是是因为开发团队（以及更大规模的组织）缺乏时间来创造可用的、稳定的、有效的自动化解决法案。

尽管众所周知，实现自动化需要花费时间和精力，但是当时间变得紧促时，自动化仍然是第一件受影响的事。

这适用于项目中，但它也适用于在敏捷环境中工作的团队。

尽管自动化是很多软件开发团队中最希望能够实现的事，但当接近尾声时，交付功能几乎总是优先于自动化。

需要注意的是，我并不认为这一定是一件坏事。毕竟最终发布的产品是可供用户使用的功能，而非确保功能正确运行的那些自动化测试用例。

然而从长远看来，团队将发布产品的功能置为最高优先级，同时一次又一次地迭代发布日期的制定，已将他们的搞得异常忙碌，精辟尽力。

他们似乎已经忘记了采取敏捷工作方式的目的是以小幅度增长的方式发布可供用户使用的功能，并且得到用户方的即时反馈，而非只是一味追求速度，仓促发布功能。

不允许有足够的时间来创建可靠的自动化解决方案也会产生不必要的副作用：

如果你没有将自动化授予应有的优先级（且可能不是最优先考虑事项），那么你的团队成员将不太可能拥有足够的时间成为熟练的自动化工程师。

我将自动化视作一种手艺，与其他手艺相类似，它需要不断的学习和磨练你的技艺。

既然我们已经讲述了两个导致自动化失败的主要原因。

我想提出一个分布指南来帮助您避免这些陷阱，并成功实现自动化作为软件开发活动中的一部分。

这并不是一个权威指南，也许并非所有的步骤都适用于您的情况。但是按照以下步骤可能能够帮助您在敏捷自动化工作中获得成功。

正如我之前所说，任何自动化的成功都始于合理的预期。我发现提问及对于该问题达成的多方共识是一个设定合理预期的好方法。为什么我们首先要自动化？为什么我们认为我们需要自动化测试？

在我看来，这个问题有好的答案“因为我们希望能够第一时间获得开发人员的反馈”，而“因为我们不想要手动进行测试”是不合理预期来源的一个主要例子。

确保所有的相关方都意识到自动化测试的引入基本等同于在当前项目中又引入了另一个软件开发项目。

自动化测试作为项目进行实施需要同时考虑该项目的计划及其技术实现（您应该为其分配资源并允许在开发和维护自动化上花费时间等等），同上（您写代码，因此确保请务必保证良好的开发模式和实践，并尊重自动化测试是一门需要特定技能的手艺）。

为了在敏捷软件开发工作中成功实现自动化测试，您需要确保所有负责创建和维护自动化的人员都具备合适的技能，并拥有足够的时间来完成。

当前项目中自动化测试人员配备的数量取决于多种因素，其中包括测试人员自身的技术能力，需要哪类自动化测试，以及被测应用程序的复杂性和风险性。

如果您的团队目前没有雇佣足够的人来满足您的自动化需求，或者团队人员缺乏必要的经验，那么临时外聘专家也是一个值得考虑的选择。

从何处着手实施自动化测试，似乎是个非常棘手的难题，正如同面对任何一个重大项目一样难以抉择。

对此，我有两条建议：

• 可以从一些简单易实现的功能着手，或者着眼于当前应用程序中的一些高风险项及重大缺陷（这有助于向利益相关者尽快展示自动化测试的附加价值。

• 尽量避免使用到端对端自动化测试，例如使用Selenium。

虽然当你想要编写自动化回归测试时，这似乎是一个很直接的选择，但这种类型的测试是编写最难，执行速度最慢，最容易失败，失败的原因有可能是待测应用程序界面的变化，也可能是用于部署过程中的同步性，亦或者环境等因素（例如测试数据）。

相反，您更应着眼于是否能够创建可靠的单元测试。

当您在敏捷设置中工作时，将自动化测试作为您所谓“完成”的一部分指定特征是有意义的。

尽管如此，尽可能避免以下两个陷阱：包括诸如“所有测试都应该是自动化的”，或“我们应该为所提供的每个项目实现自动化”之类的声明有时候并没有意义，反而较为繁琐，甚至完全不可能实现。

换而言之，有效的定义诸如“更新现有的自动化脚本以应对当前功能的变更”或”在开发团队认为有必要的前提下，创建额外的自动化测试用例”。

基于百分比—“百分百代码覆盖率”是一个空话，这句话完全没有说明测试的质量以及关联性。同样，“80%的测试已经实现自动化”也没有意义。

首先，这基于自动化测试所执行的一对一转换，而这种方式再三被证明是无效的。但更为重要的是，您如何首先定义了80%，80%的可自动化能被所有测试所执行吗？我想你能明白我的意思。

对此你应不必感到奇怪：自动化测试是一个软件开发活动，当你在用敏捷工作方式时，应用快速反馈，快速评估和学习时有必要的。

自动化的实施并非一蹴而就的。就像您正在测试中的应用程序一样，花时间进行实验，尽早尽快评估，从错误中学习，并坚持使用有效的方法。

假以时日，不断积累，自动化方法与您的软件开发工作密切相关。

请注意，情况各有不同，对一个组织有效的方法未必也适用于其他组织。

话虽如此，我真的相信以上内容能够帮助大多数正在努力进行有效测试的团队有所帮助。也正因此，自动化被视为改进敏捷测试工作中的一种手段。

作者：Bas Dijkstra

-------- THE END --------

🍁