通过测试自动化，可以学到了很多东西，并已在经验丰富的敏捷教练的帮助下开始制定策略。测试策略应针对该项目制定，让我们逐步执定义下一个项目策略的步骤。
确定目标
当我开始我的职业生涯时，测试自动化并没有太多想象力。我们也面临着许多您可能遇到的测试自动化挑战。如果今天问我同样的问题，情况已经发生了巨大变化，这主要归功于可靠工具的可用性。但是，这并不意味着我们会自动执行所有操作。成功的企业测试自动化策略的第一步是定义我们的目标并确定要自动化的测试。
任何测试自动化的决定因素与特定测试可以重复多少次有关。可以自动执行的测试的最佳示例是经常运行的测试，它是一项平凡的任务，非常耗时，并且需要大量数据才能执行规定的任务。这是可以自动化的潜在测试用例的列表：
- 自动执行高度重复的任务，例如登录。
- 具有高风险或失败概率或高风险的任务
- 需要在多个浏览器/设备/操作系统/环境/硬件/配置上进行测试的任务
- 测试具有清晰的通过/失败结果
- 自动化需要通过多个数据集进行操作的测试
- 自动执行允许多个选项的练习，例如，接受不同组合的表单提交
- 如果手动完成，则需要大量时间进行测试；例如，我们进行了一项测试，每次运行新任务时都需要登录。
- 最后，绝对应该自动执行需要检查稳定功能的测试。
ScienceSoft的软件测试总监Andrei Mikhailau和他的团队应用测试自动化来减少验证新功能或修复，提高回归测试覆盖率并消除人为错误的时间。当手动测试效率低下或无法进行手动测试（例如为了测试性能）时，他们还会应用自动测试。
但是，他们在测试自动化中的最大挑战在于如何快速，频繁地进行UI布局和功能更改。即使是最小的修改，也可能需要重写大量测试。减少这种不便的方法之一是确保最大程度地重用测试代码。建议在此处创建标准的高级特定于应用程序的库。
测试自动化的成功要求项目开始时的精心计划。完成定义测试自动化的目标和范围后，下一步就是寻找不同的测试方法。
确定测试方法
我在测试方面的总体经验教会了我一件事：除了他们如何设想测试自动化以及他们如何计划在开发团队之外进行协作之外，任何组织的总体测试文化都受到现行测试方法的极大影响。这意味着需要对当前流程进行回顾，最终确定新的测试方法，并确定团队成员的测试级别，角色和职责。
但是首先，让我们决定在自动化时可以提供最大价值的测试方法。不同的测试级别可以采用不同的测试方法。
参考：43种常见软件测试分类
单元测试
单元测试是任何敏捷测试自动化策略的基础，该策略可以为团队提供最高的ROI。该测试使用了开发人员可以编写，执行和维护的一小段代码（函数或方法）。
同样，每个单元都应单独测试。单元测试将提供细粒度的可观察性，这对开发人员来说很重要，但对产品所有者却很有用。建议在本地和内部版本中运行这些测试。
回归测试
回归测试被定义为一种软件测试类型，以确认最近的程序或代码更改未对现有功能造成不利影响。 从这个定义来看，很明显，这样的测试类型应该集中在通过预定义的计划、触发器或按需执行的全部或部分测试场景中。
如果根据最佳实践正确开发了回归测试并涵盖了足够的功能区域，则它们带来的价值就很高，并且这种测试模型能够发现回归错误，代码更改的副作用或其他意外的问题。
集成测试
集成测试在软件测试类型中排名靠前，这是因为它对任何一支优秀的DevOps团队而言至关重要。
通常，集成测试是在单元测试之后进行的，以确保所有单元相互协调运行。通常，一个单元将被视为具有独立功能，但在与其他单元交互时可能会引起问题。这就是软件测试如此重要的原因，尤其是作为一个整体的测试单元。同样，大多数软件项目都有多个开发人员为不同的模块和单元编写代码。因此，集成测试确定不同开发人员正在编写的软件是否能够按照计划的那样工作。
端到端测试
端到端的目标是验证系统与功能流程的集成。因此在测试任何应用程序时，必须注意用户界面或表示层不是唯一要关注的领域，但应用程序行为背后的基础数据、流程和逻辑也需要进行验证。连接的系统和集成在前端、后端、功能和集成方面均同等重要。
此处省略888字介绍各种测试方法。
选择测试自动化框架
测试自动化框架是在编写和运行测试时需要遵循的一组详细准则。例如，编码标准，过程，测试数据报告等。这是六个测试自动化框架的列表，您可以从中选择：
线性脚本-记录和播放
线性脚本是最方便的框架之一。录制后，可以在其余时间重放它。它允许测试人员按顺序记录步骤。例如，导航，输入等。
优点：
- 不需要编码专业知识
- 更快地生成测试脚本
- 保持顺序，因此任何人都易于理解
缺点：
- 无法使用多个数据集重新运行测试用例
- 无法扩展项目范围
- 返工将需要更改应用程序
图书馆架构测试框架
图书馆架构的工作原理是确定和划分。这意味着该框架可以轻松识别常见任务并将其相应地分组。该框架将这些相似的功能保存到库中，并在测试脚本需要时随时使用。
优点：
- 保持高水平的模块化
- 经济高效且可扩展
- 易于运行多个测试脚本
缺点：
- 由于数据是硬编码的，因此需要更改脚本
- 需要技术门槛较高
模块化的测试框架
顾名思义，该框架将应用程序划分为多个单独的单元，并进行隔离的测试。为每个零件创建一个单独的测试脚本，然后将其合并为合并的测试。
优点：
- 模块化更改不会影响整个应用程序
- 测试脚本是可重用的
- 减少创建测试脚本的工作量和时间
缺点：
- 不能使用多个数据集
- 设置需要技术门槛高
数据驱动的测试框架
它克服了基于线性或模块化框架的故障。它不对数据进行硬编码，但允许从外部文件（如Excel，CSV等）存储和访问它。它允许测试人员使用不同的数据集测试同一功能。
优点：
- 可以使用多个数据集进行测试
- 更少的脚本
- 模块中将来的更改将不会影响整个应用程序
缺点：
- 框架设置很耗时
- 需要专家来设计实施框架
- 数据格式不能太复杂
关键字驱动的测试框架
关键字用于表示在GUI上执行的操作。例如，诸如“单击链接以进行验证”或“单击登录按钮”之类的短语。它在外部存储关键字，并用于测试应用程序的GUI。这些关键字与测试逻辑分开，并且通过遵循一组指令对操作进行无缝测试。
优点：
- 可以使用独立的AUT测试脚本
- 使用一个关键字表示多个测试脚本
- 代码是可重用的
缺点：
- 设置成本高
- 耗时，因为需要设置对象存储库
- 需要具有出色自动化技能的质量检查工程师
确认工具
选择正确的自动化工具的第一步是了解应用程序所基于的技术以及被测应用程序（AUT）的测试要求。选择正确的自动化工具的主要方面之一是与AUT的技术栈的兼容性。很少有工具能够同时满足大多数测试人员的需求和使用习惯。该工具必须支持测试人员最喜欢的编程语言和测试环境。对于移动应用程序，如果同时针对iOS和Android，则选择同时支持Selenium和Appium的平台。
第二步是检查该工具在支持的平台和易用性之间是否具有适当的平衡。越来越多的平台要求测试各种平台上的应用程序部署。必须注意，即使在平台的单个变体中，也需要支持各种版本。例如，如果桌面应用程序声称可以在Windows上运行，则它必须在Windows 7、10（32位和64位）上运行，等等。同样，Android和iOS的不同版本也可以支持移动应用程序。一旦编写了测试脚本，自动化工具就必须在所有平台上对应用程序进行测试，并且对配置文件的更改最少。测试自动化工具必须具备的功能是，通过最大程度地使用测试脚本来支持所有必需平台的跨平台测试。
第三方面是找到一种基于流行度的工具。受欢迎程度证明该工具具有可用的支持，质量文档和技术论坛。这可以帮助找到相关的测试工程师来执行和维护测试工具。例如，如果我们考虑进行Web应用程序自动化测试，则与Sahi相比，Selenium受欢迎并且被广泛使用。
要考虑的第四个方面是该工具的许可成本。但是，这并不像比较入围产品的定价那样简单。需要选择在成本和满足测试要求之间具有适当平衡的工具。首先，可以选择两种工具：开源和商业工具。开源工具是一个有吸引力的选择。但是，商业工具提供了更好的支持和学习资源。但是，在选择开放源代码工具时，购买许可协议之前，需要仔细评估许可协议，因为它们都有各自的警告。以我的经验，到目前为止，在免费的开源工具上构建自定义测试自动化框架效果最好。最大的优势是控制，可以灵活封装以满足团队个性化自动化测试需求。
创建并运行测试
创建完测试自动化策略并选择了正确的工具后，就可以编写和执行脚本了。我们一次又一次地观察到，使自动化测试成为手动测试人员的兼职工作会降低团队士气和生产率。
这是我们的建议：选择专门的自动化测试团队，外包软件测试服务可能是一个不错的选择。
当开始编写测试用例时，建议遵循最佳实践。以下是我们在工作中中严格遵循的一些建议。
- 编写测试用例模板，使它们可以在多个项目中重复使用。在编写任何新的测试用例之前，我们确保检查是否已经编写了类似的测试用例。这有助于我们减少冗余。
- 通常，设计测试用例的人不是执行它的人。这鼓励我们以简洁易懂的方式编写测试用例。
- 随着时间的流逝，我们已经学会了根据所涉及的功能或组件确定每个测试用例的优先级。这样做有助于我们确保首先执行高优先级案件。
维护脚本
维护测试脚本涉及仔细检查测试参数。例如，当产品具有丰富的功能时，实施回归测试可能会花费更多时间，并且未充分利用测试自动化的重要性。对于这种情况，维护测试用例起着至关重要的作用。应该对测试用例进行优化和分类，以评估测试用例的子集并明确定义测试自动化的目的。
根据与敏捷教练和QA专业人士合作的经验，我始终被建议保持专注于保持回归测试的有效性。这可以通过定期清除较旧的测试用例并对其进行分类来实现。您应该清楚自己的要求以及旧的测试用例是否可以有效保留。测试脚本应尽可能少，并且结果更多。如果您可以制作较小的测试用例，则自动化将变得更加容易。
除非触发自动化，否则自动化不会自动完成所有操作。必须通过根据需要设计测试用例来使其适合真实的测试场景，因为它与您的产品交付和ROI直接相关。请您的质量检查分析师处理测试用例的子集，以节省大量时间。
- 测试用例越精简，软件就可以更快地投入生产。
编写测试用例时，不要追求曲折的目标。保持简洁。在自动化方面，请继续缩小测试用例的范围。随着时间的流逝，在实现测试自动化的同时，我们已经意识到，要想成功，自动化就必须成为每个人的工作。我们努力改变业务分析师和测试人员协作的方式以及创建和运行测试的方式。
通过在测试过程中实现自动化，我们可以花更多的时间进行计划，更快地检测更多缺陷并更好地满足项目需求。
