从理论上讲，测试自动化程序或工具可以简化测试人员的工作，节省时间，并为我们的评估覆盖范围提供一个额外的放松毯子。
因此，许多组织无法实施可扩展，强大且良好的测试自动化基础架构，从而无法返回所投资的资源并可以节省这些资源。一些“扔掉”书面的测试自动化工作，而另一些则持续不断地奋斗，以期获得稳定的自动化套件。
多年来，我观察到许多公司试图执行其自动化工作，观察到书面项目被丢弃，框架被更换，管理人员被解雇，因为他们未能提供承诺或设定的目标。
导致失败的原因很多，尽管从长远来看，自动化是完全合理的选择，但我们确实需要理解，看起来它要困难得多。
在继续前进并开始构建测试自动化项目之前，您必须了解以下一些原因：
分析和询问问题：测试自动化工作是与其他任何应用程序项目一样的工作，应像对待一个项目一样对待。您将如何计划软件项目？当您考虑实施您的Test Automation项目时，让这个想法指导您。你会选谁做这份工作？谁将使用生产的产品？哪种语言或框架最适合这份工作？您能从挑战和挑战准则中了解并窥视一下吗？您是自己组成一无所知的架构，还是会打电话给顾问以一些想法为您提供建议？
所有这些问题都只是在编写一行代码甚至测试情况之前应该问自己的冰山一角。
技能不足：让我问一个问题。您会允许更糟糕或没有经验的程序员，一个不了解如何编写出色的可搜索代码的人-设计应用程序的设计风格并从头开始编写它吗？我认为答案是否定的。那么，为什么有这么多公司认为没有经验和技能的人可以通过评估自动化基础架构来实现质量呢？如果敬业的员工没有经验和知识，并且您不打算聘请有经验的人，那么您需要考虑使用无代码自动化工具。
不切实际的期望/方法：我会将其分为两部分。第一个是对测试自动化的ROI（投资回报）的错误理解，第二个是每次时间框架的不切实际的期望。有一项工作与您完成的工作一样好，如果不花费时间，您就无法期望某些东西可以创造价值。我曾与一名QA工程师交谈，他告诉我他每周有6个小时用于组成卧底基础设施。您期望他达到6个小时？
为了使这项工作，您需要查询：
- 您希望与测试自动化一起实现的目标到底是什么？
- 什么是工作/时间的奇妙价值？
- 成就的标准是什么？
- 您准备花费多少时间/金钱以实现目标？
自动化不是“启动后忘记”任务。您想承认这是一个连续的过程，需要维护，团队合作和进步。
我不得不承认，以我所见，可悲的是，有些公司认为为QA工程师提供秘密工作只是保留工人或在他的日常工作中添加一些“香料”的一种方法。不要误会我的意思，我不是说我们不应该保护我们的工人或为他们提供学习和进步的时间，我只是说它应该与对工人本身的现实和透明的期望相一致。 。
规划不足：出色的自动化项目必须从高水平的计划和计划开始，然后再发展为全面的技术风格。即使是“一刀切”的策略也可能对您的成功造成灾难性的影响。对于一家公司而言，出色的工作并不一定表示它将为您完成工作。该声明可能是关于仪器选择的真实信息。每当您实际上不必使用有问题的技术时，它就会成为流行语。这一点非常重要。那里有大量的开放源代码和商业工具，它们可以提供很高的物有所值，甚至无需考虑这些工具可以提供的替代方案和收益/替代方案。选择一种可以满足您需求的工具。这是我的两分钱-支付解决方案比浪费很多时间要好得多（这比程序的成本要高得多）。
现在，随着我们继续讨论规划设计的方式，我们将不得不考虑我们的全方位技术架构和业务需求。以下是您应考虑的一些方面：
- 想象一下人们会检查的工作，模块，业务流程吗？
- 每个执行阶段的计划政策是什么？ （理智，回归，CI / CD专用软件包？）
- 主要的共享/公共/重复流程/功能是什么？
- 我们如何计划一个简短的独立工件的每个测试？ （SetUp和TearDown，依赖于外部数据而不是生成的评估数据，在每个测试套件类之前需要运行什么？）
- 如果并发运行评估，我们如何防止其“破坏”另一评估？
- 我们如何产生良好的可扩展性，清洁和适当的氛围？ （模拟服务器，数据库案例，清理脚本，浏览器首选项，网格/服务器配置，设置和清理，虚拟环境或Docker容器）。
- 如果使用的话，究竟是什么构建工具？
- 究竟如何管理我们的依赖关系？
- 我们的项目存储在哪里？
- 到底有多少工程师在从事该项目以及变型管理的管理方式？
- 哪种CI工具最适合执行我们的构建？
- 您将实施CI / CD工作流程吗？
- 您将在哪里运行测试，并且可以使用资源来设计自己的执行平台？ （是否向您提供了购买云解决方案许可证的资金？您是否具有建立自己的Selenium Server基础架构的工具或支持？）
- 究竟什么样的测试将很快自动进行？ （API，视觉概念，服务器进程，Web / UI自动化，移动-Android / IOS）。
- 是否存在一些大型数据收集，长流程，复杂的流程，集成，需要进行额外的评估？
- 我们应该通过GUI进行哪些测试，而通过API进行检查可以更安全些？
- 我们将需要实施哪些日志，报告机制，处理程序和侦听器，以便更简单地创建根本原因评估和调试程序？ （如果您每天都对结果有所了解，那么什么是一小时的自动化套件？）
- 运行应提供什么指标/报告/输出？
- 我们到底想要什么集成？ （报告程序，ALM工具，错误跟踪器，评估管理程序）。
- 谁可以组成基础架构，谁应该实施测试？ （两者之间甚至可以有分支吗？）
- 谁负责向自动化工程师提供应该是自动的业务流程/测试用例/业务逻辑？
- 是否定义了POC（概念验证）阶段来确定未来目标？
简而言之，这只是一些问题，您应该从中得到的是
适当的工具选项，出色的计划/设计可能会在失败和成功之间产生差异。
使一切自动化：需要注意的重要一点是，不是什么可以或必须是自动的。有时，人们会察觉到或做出错误的管理决策，我们会自动将所有出现在测试人员头上的事情自动化，或将测试用例盲目地转换为脚本。首先，并非所有评估都适合自动化。第二，测试用例本身是不能接受的。这以无法维持的一堆无法维持的自动测试结束，可悲的是，在大多数情况下，它将导致我们大量的书面工作被淘汰。如果您的公司没有足够的资金来维持自动化团队成千上万的测试实例（偶尔检查相同的业务逻辑），那么自动化没有任何附加价值。
我们还需要针对需要维护每个自动化构建的内容制定清晰的计划。回归中包括什么？什么被称为我们的理智？什么足以安全可靠地进入我们的CI / CD管道？
测试自动化需要扎实的计划，理解，承诺和奉献精神，以交付适当的价值。
缺乏技能/正确的指导，错误的工具选择，不足的资源，缺乏适当的准备，不切实际的期望，所有这些都可能使项目失败。
我希望这份报告能够产生积极的影响，并帮助你们中的一些人遵循富有成效的思维方式。