【译】自动化测试是什么（开始自动化测试的终极指南）

原文链接:https://www.softwaretestinghelp.com/automation-testing-tutorial-1/

在项目中开展自动化测试的完整指南：

什么是自动化测试？

自动化测试是一种用于测试和比较实际结果与预期结果的软件测试技术。这个过程可以通过编写测试脚本或使用自动化测试工具实现。测试自动化用于执行难以手动执行的重复任务和其他测试任务。

开展自动化测试脚本的问题

• 如何在项目中运用自动化测试
• 如何选择合适的自动化工具
• 如何有效地开发脚本
• 如何执行并维护测试脚本
• 成功进行自动化测试需要遵循的最佳实践是什么?

 

什么是自动化测试？——如果软件可以做任何事，为什么不能用于测试软件呢？

      想象一下你作为SQA工作的第一天，你将看到被测试的应用，它是一个ERP应用程序，包含100多个表单和数千个报表。你开始打开一个包含大约50个不同字段的表单进行探索测试。你花费将近20分钟在这个表单中输入随机数据，然后提交。显示了一个看似未处理异常的错误信息。然后你在你的错误管理系统中提交bug报告并记录复现步骤。然后继续测试，测出了更多的bug。第二天，开发者修复了问题并发布了构建后的新版本。你使用相同的步骤测试相同的表单并且发现bug已被修复，然后将bug标记为已修复。第三天，开发人员再次发布了新版本，现在，你必须再次测试表单以企鹅包不存在回归问题。假设新版本在不断的发布，每个版本中，你都需要做回归测试。。。

      这种现象是90%的手工测试人员都遇到过的情况。

      回归问题是一件最痛苦的事情，我们不可能每天用相同的精力、速度和准确度做同一件事情，这是机器应该做的事情。这就是我们对自动化的需求，为了用相同的速度、精力和准确度重复同样的步骤。自动化测试将帮助你在处理回归的同时专注于新功能。

      脚本将填写所有字段并截图记录测试结果，如果测试用例未通过，它可以精确定位测试用例失败的位置，从而帮助你轻松地重现它。

自动化——回归测试的成本效益方法

       最初的自动化成本确实很高，它包括工具的成本、自动化测试资源成本和员工培训。但是当脚本准备就绪时，它们可以以相同的准确度重复执行数百次，而且速度很快。这将节省许多小时的手动测试。因此成本逐渐降低，最终成为回归测试的一种经济有效的方法。

推荐工具：Ranorex Studio

Ranorex Studio 是一个完整的端到端的自动化测试工具，适用于桌面，web和移动应用程序。快速创建可靠的测试，无需任何编码或使用完整的IDE。使用外部CSV、Excel文件或SQL数据库作为测试的输入，并行运行测试或在内置Selenium WebDriver的selenium Grid上运行测试。Ranorex Studio可与CI/CD/DevOps流程集成，在不牺牲质量的情况下缩短发布周期。

需要做自动化的场景

除了重复工作外，有些无法手工完成的测试也可以使用自动化。

如：

1. 逐个像素地比较两个图像；
2. 比较包含数千行和列的两个电子表格；
3. 在100000个用户的负载下测试应用程序；
4. 绩效基准
5. 在不同浏览器和不同操作系统上并行测试应用程序。

何时开始自动化？

在进入自动化之前，需要考虑一下情况：

• 该产品可能处于原始阶段，当产品还没有UI时，在这些阶段，我们必须清楚地思考我们想要实现的自动化。
  • 测试不应该超超时；
  • 随着产品的发展，应该很容易选择脚本并添加它；
  • 确保脚本易于调试。
• 不要在初始化阶段尝试UI自动化，因为UI经常发生变化，从而导致脚本失败。在产品稳定之前，尽可能选择API级别/非UI级别自动化。API自动化易于修复和调试。

正确的自动化测试

解决这个问题的最佳方法是快速提出适合我们产品的“自动化策略”。我们的想法是对测试用例进行分组，以便每个组都能给出不同类型的结果。

分组示例：

1. Positive tests：所有基本功能套件的测试，此套件应该自动化，当针对任何构建运行此套件时，会立即显示结果。此套件中发生故障的任何脚本都会导致S1（紧急）或S2（严重）缺陷，并且该特定构建可能会被取消。这里可以为测试人员节省大量时间；
2. End to End tests：在大的方案下，测试端到端功能是关键，特别是在项目的关键阶段。我们应该有一些自动化脚本可以触及端到端的解决方案测试。运行此套件时，结果显示整个产品是否按预期工作。如果任何集成部分损坏，则应指示自动化测试套件。该套件无需覆盖解决方案的每个小功能/特性，但它应该涵盖整个产品的工作。每当我们有alpha或beta或任何其他中间版本时，这样的脚本就会派上用场，给客户一定程度的信心。
3. Feature/Functionality based tests：我们可能具有浏览和选择文件的功能，因此当我们自动执行此操作时，我们可以编写自动化案例以包括选择不同类型的文件，文件大小等，以便完成功能测试。当该功能有任何更改/添加时，此套件可用作回归套件。
4. UI based tests：我们可以拥有另一个套件，它将测试纯粹基于UI的功能，如分页，文本框字符限制，日历按钮，下啦菜单，图形，图像和许多此类仅限UI的中心功能。除非UI完全关闭或某些页面未按预期显示，否则这些脚本的失败通常不是非常关键。

不做自动化的场景

1. 负面测试/故障转移测试：负面测试需要大量手动干预来模拟实际的灾难恢复类场景；
2. 临时测试：这些测试可能与产品无关，进行临时性验证的测试；
3. 通过大量预设置进行测试

那么让我们开启自动化测试之旅吧。。。。