以独占方式锁定此配置文件失败.另一个正在运行_加速用例执行最有效的方法，手把手教你如何并行地运行自动化测试...

在自动化测试过程中的某些时刻，你将遇到一个共同的问题，那就是：需要花费很长时间去执行大量的UI自动化测试用例。最为有效地加速用例执行的方式就是并行地运行自动化测试。不幸地是，使各个自动化测试用例并行地执行并非一件容易的事情。典型地，线程安全就没有融入到自动化测试中去。线程安全可以确保代码编写完成后，程序可以运行并操作各种数据结构而不产生意想不到的结果。

为了测试可以并行地运行，需要满足一些强制性的要求。这些要求同我们的一些客户每天用来帮助运行五万条自动化测试用例所需的条件相同。四个强制要求如下：

1．测试必须是原子的

你的自动化测试用例应该形成一个单一的不能简化的单元。这就意味着你的测试必须极其集中并且每个测试用例只做一件事。一个单独的自动化测试用例应该不能测试端到端的功能。

在我的团队中使用的一个比较好的经验办法就是：自动化验收测试在你本地资源上运行的时间不能超过一分钟，实际上当然是运行越快越好，但是也不要太着急、慢慢来，可以逐步改进运行时间。如果你的测试用例运行时间超过一分钟，那将是很危险的事。

有一个例子，在这个存储库中可用的非原子测试(NAT)。本篇文章将自始至终地引用此测试库中的内容。

原子测试可以快速失败

为什么要使用原子测试？首先，它让你尽早地快速地失败。这就意味着你将得到及其快速的有针对性的反馈。如果你想检查一个特征功能的状态，原子测试只会花费你不到一分钟的时间就能让你拿到结果。

原子测试可以降低薄片行为

第二，写原子测试用例减少了薄片，因为它降低了测试过程中可能出现的断点数量。薄片是自动化测试领域的一个概念，它是指测试展示出一种无效的测试结果，例如原本失败的用例结果显示通过了或者原本通过的用例结果显示失败了。一个没有薄片的自动化测试是一个可以正确传达系统状态的测试---无论被测系统是否正常运行。

原子测试考虑到了更好的测试

原子测试第三点好处就是一旦一个原子用例失败了，它不会阻止你进行其他功能的测试。比如，一个普通测试在第25行失败了，假如你不手动执行测试用例去验证剩余的功能话，那么在25行之后的功能点都不会被测试到。所造成的结果就是，如果你正进行大范围的测试，由于有一些特性没有被测试到，实际上就降低了测试覆盖率。

下图是一个从上面的测试集中摘取的原子测试用例，如果这个用例失败了，你仍然可以接着测试其他功能点，这样整个测试过程不会中断，自然也不会影响到测试覆盖率。

2．测试必须是自主的

一个自主的自动化测试是指测试本身并不依赖其他测试的结果。一种常见的反面模式就是将所有的用例连接到一起执行以避免重复执行一些测试步骤，这种反面模式是从加速执行测试集演变而来的。

例如，你要先执行登陆测试、再执行搜索测试、最后执行结算测试。为了进行结算场景的测试，所有的测试项目都应该按照正确的顺序进行。

这对于平行化来说就是一个很大的挑战了，因为它意味着你的测试永远不可能失序的进行。如果不按顺序执行第一步到第三步，那测试结果将失---但是这种失败并不是因为应用系统里有BUG，而是设计逻辑本该如此，是因为结算的场景里需要一个已登录的用户，而具体测试时由于打乱了三步的顺序致使登陆操作是失败的。

3．正确管理你的测试数据

测试数据的管理对完成并行测试来说是非常关键的。管理测试数据最为有效的方式就是使用实时数据。这就意味着你在测试过程中有很多种方式来创造和销毁数据。一个RESTFUL风格的API接口可以实现这一功能，并且这是最优的方法。

遗憾的是：在我的WEB应用里没有现成的RESTFUL风格的API可供使用。因此，我和开发人员一起合作，容许JavaScript注入来控制应用程序的状态和数据。这样我们测试团队就可以解决如何在不需要事先登陆、搜索商品、添加商品到购物车的情况下进行购物车结算了。

通过适当的测试数据管理，我可以直接打开购物车页面。结果就是我可以旁路掉/忽略掉登陆页面和搜索商品页面。如下图所示我注入了一个用户和一个商品到购物车里：

现在我就可以使用应有程序的UI界面来完成结算过程并且测试这一功能是否OK，如下图：

最后，这种方式能够让你有能力旁路掉/忽略掉应用系统中任何与测试无关的UI界面。在你使用API或者JavaScript操作应用程序的状态后，你就可以使用任意的UI自动化工具执行相关的测试步骤。

4．不能使用静态关键字

这里有一个一般性的经验法则：在你的自动化代码里不要使用静态关键字。这既是最简单的需要遵循的规则，同时也是最危险的。

在面向对象的程序设计语言中一个静态关键字会要求程序在代码运行期间内给一个变量分配一个单独的内存空间，这就意味代码运行期间这个空间的内容不能改变。任何使用静态变量的程序都将信息存储在单独的内存空间里。

一个单一的错位的静态关键字实例会毁掉你所有并行测试的希望。也许这个经验法则(指"不要使用静态关键字")会有很多例外情况，但是确保安全总比意外发生后懊悔不已好得多。

例如，在你的浏览器中创建一个静态的浏览器驱动关键字，当你尝试并行地运行所有测试用例时，这些用例都将尝试使用唯一的浏览器驱动。就会造成一种局面：一个用例正在准备键入账号密码时，另一个用例尝试打开一个不同的页面等等，结果这些用例会将浏览器驱动实例带到不同的方向上去，最终造成各种稀奇古怪的错误。

使测试又快又准确

自动化需要快速地进行才能发挥它的作用，同时并行测试是快速执行完测试用例的一种最好的方式。但是并行运行自动化测试的时候，你需要原子的、非依赖性的用例，并且这些用例里不能包含任何静态关键字，并且你需要正确地管理测试数据集。

请关注+私信回复：“学习”就可以免费拿到软件测试学习资料，全栈测试工程师相关资料可以私信我。