将测试自动化维护的噩梦转化为成功实践

“自动化”在业界并不是一个新的流行语。 随着电子商务的发展和对移动技术的快速访问，一段时间以来，尽快交付软件应用程序已成为一种趋势。 但是，如果不真正理解问题，就很难理解解决方案。 一种尺寸无法满足所有需求，并且没有一种适用于所有自动化问题的完美“最佳实践”解决方案。 我们必须权衡成本，工作量和风险与潜在收益。

关于测试自动化最佳实践的在线资源很多，其中都强调可靠性，可移植性，可重用性，可读性，可维护性等。 刚开始创建自动化测试时，我发现此信息既有用又有压力。 从一开始就将所有这些实践用于您的测试如何可行？ 如果您是测试自动化工程师，那么我相信您在职业生涯中的某些时候也面临过其中一些挑战。

让我从编写浏览器自动化测试的旅程开始，然后进入从错误中学到的知识以及如何克服挑战。

编写测试最初很耗时，在维护过程中，我不断尝试改进测试。 就像任何其他开发任务一样，创建测试也具有截止日期和管理期望，而平衡这些因素对于测试自动化项目的成功至关重要。

为了使我的第一个项目符合计划，我急于创建测试，并且没有考虑前面提到的一些最佳实践。 我的测试是稳定的，并且100％地通过了测试-直到几个月后被测试的应用程序（AUT）开始更改。 现在，我的测试的真正质量浮出水面，并且成为维护的噩梦。

每当测试失败时，我们都会花费大量时间来尝试了解失败的原因，以便我们确定是由于回归，AUT的预期变化还是诸如新浏览器或系统更新之类的环境问题所致。 经过数周的故障排除和沮丧后，我们花了一些时间来确定测试中出现的问题。

ps: 个人理解，自动化失败，极大概率不意味着业务实现的非正常，这是最可怕的噩梦。

这是我们发现的：

• 我们的大多数测试都太大，包含太多步骤，并且试图验证太多不同功能。 这些步骤中的许多步骤还取决于先前步骤的成功执行，并且添加了许多效率低下的等待条件，例如静态延迟，这使执行过程不必要地漫长。

ps : 自动化的一个原则/理念，就是要小而美

• 从测试报告的角度来看，很多时候很难理解测试失败。 如果不花费大量时间在报告上，我们就无法快速确定失败的原因。 许多测试步骤都有基于元
• 素定位器的通用名称或描述（例如，clickButton-// div [2] / button），并且当这样的测试失败时，并不清楚要引用页面上的哪个按钮。
• 这些测试不是很容易移植。 如果有人要从工作站执行测试，则他们必须在本地设置许多其他环境数据，因为在测试之外的构建过程中需要设置一些前提条件。 另一个问题是测试具有许多硬编码的引用，例如资源名称，这使得任何人都无法在其特定测试环境之外运行这些测试。
• 测试缺乏执行的可重复性。 在相同的环境中运行测试具有挑战性，并且很多时候都无法正常工作，因为人们在初始执行后没有重置环境。 这样可以防止在更新测试之后或在构建新的AUT之后快速重新运行测试，而无需手动设置测试之外的所有前提条件。

一旦确定了问题，接下来我们必须决定如何解决它们。 我们的选择是要么通过我们现有的测试解决这些问题，要么创建一组全新的测试。

由于我们有大量复杂的测试，因此我们必须考虑重新创建它们所花费的时间，并向管理层保证新测试不会出现维护方面的问题。 在与团队一起评估工作量与风险因素之后，我们一致认为重新创建所有测试将不是一个可行的选择。 我们不想意外错过这些测试涵盖的任何现有功能。

这使我们可以选择使用最佳实践来修复现有测试，以解决我们的大多数维护难题。 这是我们缓解已发现问题的方法。

首先，我们必须将现有的制作不当的测试分解为较小的模块，这些模块可以独立运行和测试特定功能。 请注意，这可能不适用于每个组织，这取决于测试的数量和重构它们所花费的时间。 在这种情况下，最好的做法是保留旧的，稳定的测试，而仅重构那些需要立即关注的测试。 考虑到修复所有现有测试所需的时间，有时重新创建测试可能不是一个坏选择。

然后，我们将所有常用的测试代码和过程分离到各自的模块中。 与其完全复制并粘贴这些代码，我们只是开始引用它。

然后，我们创建设置（前提条件）和拆卸（重置在AUT中引入的测试的任何更改）条件作为测试的一部分。 总体而言，这会使测试的执行时间更长一些，但是值得拥有独立的测试，这些测试无需任何手动步骤或冗长的构建过程即可快速执行。

ps: 个人感悟，自动化实现可能往往忽略最重要的测试资产，自动化实现的方案/伪代码，有了它，任何人实现、修改、维护自动化”宪法“，而不是只有自动化测试代码。

我们删除了硬编码的引用（主机名，端口，http，https等），对其进行了参数化并使其可配置。

最后，我们通过应用适当的智能等待条件（例如，必须等到元素可见，可点击等），优化了测试执行时间并修复了固定的延迟。这有助于我们消除测试执行过程中不必要的长时间延迟。

为了使测试保持一致，我们为将要维护这些测试或在我们的基础架构中创建新测试的每个人定义了一个准则和审查过程。 该准则包括测试和元素命名，元素定位器技术（使用XPath与CSS）以及文档和注释。 这种一致性练习使团队中的任何人都易于阅读和维护我们的测试。

此外，我们设定了一个团队目标，以保持100％通过测试，并尽快解决所有失败的测试。 由于环境问题，不良的测试或等待条件，不断变化的AUT等原因，测试可能会失败或不稳定，因此始终最好及时识别此类故障并尝试立即解决。 这将保留团队对您的自动化测试的真诚信任。

这些是我们的自动化测试套件的问题和解决方案，但是同样，没有一个正确的公式适用于所有人。 您如何知道您是否对一套自动化测试采用了最佳实践方法？

提出这些问题将帮助您确定测试自动化维护程序是否正在按预期方式运行：

• 您的团队容易维护测试吗？
• 它们稳定且可重复吗？
• 在不更改AUT的情况下是否存在间歇性故障？
• 其他人是否可以在不执行大量设置工作的情况下在其环境中运行这些测试？ （通过浏览器测试，只要设置了AUT，任何人都应该能够在任何受支持的浏览器的计算机上运行这些测试）
• 执行测试需要很长时间吗？
• 有人可以根据测试报告了解可能的故障吗？
• 您是否必须在多个地方应用相同的修复程序？ 您可以在一个模块中重构通用代码段并进行引用吗？

不要害怕向开发人员和其他团队成员征求有关您测试的反馈。 总是有改进的空间，作为测试自动化工程师，您应该始终为之努力。