测试自动化
在软件测试中，测试自动化是使用与正在测试的软件分开的软件，以控制测试的执行以及与预测结果的实际结果的比较。测试自动化可以在已经到位的形式化测试过程中自动化一些重复但必要的任务，或者执行难以手动执行的其他测试。测试自动化对于连续交付和连续测试至关重要。
一般方法
测试自动化有许多方法，但是以下是广泛使用的一般方法：
- 图形用户界面测试。一个生成用户界面事件（例如击键和鼠标单击）的测试框架，并观察导致用户界面的更改，以验证程序的可观察行为是否正确。
- API驱动的测试。一个使用编程接口到应用程序的测试框架来验证正在测试的行为。通常，API驱动的测试绕过应用程序用户界面。它还可以通过多种输入参数测试与类，模块或库进行公开测试（通常）接口，以验证返回的结果是否正确。
其他方法
基于模型的测试
自动生成测试用例的一种方法是通过使用系统的模型进行测试案例生成，但研究继续进行多种替代方法。在某些情况下，基于模型的方法使非技术用户能够以普通英语创建自动化的业务测试用例，因此为了将它们配置为多个操作系统，浏览器和智能设备，因此不需要任何类型的编程。
回归测试
某些软件测试任务（例如广泛的低级接口回归测试）可能会艰辛，并且可以手动执行时间耗时。此外，手动方法可能并不总是有效地找到某些类别的缺陷。测试自动化提供了有效执行这些类型测试的可能性。
一旦开发了自动测试，它们就可以快速，反复多次运行。这可能是对具有较长维护寿命的软件产品回归测试的经济高效方法。即使在应用程序的一生中，即使是较小的补丁也可能导致现有功能破裂，而现有功能在较早的时间点工作。
API测试
软件测试人员还广泛使用了API测试，因为它使他们能够验证与GUI实施无关的要求，通常是在开发中早些时候测试它们，并确保测试本身遵守清洁代码原则，尤其是单一责任原则。它涉及直接测试API作为集成测试的一部分，以确定它们是否满足对功能，可靠性，性能和安全性的期望。由于API缺少GUI ，因此在消息层执行API测试。当API充当应用程序逻辑的主要接口时，API测试被认为是至关重要的。
图形用户界面（GUI）测试
许多测试自动化工具提供了记录和播放功能，使用户可以交互记录用户操作并重新播放任何次数，将实际结果与预期结果进行比较。这种方法的优点是它几乎不需要软件开发。该方法可以应用于具有图形用户界面的任何应用程序。但是，依赖这些功能会带来主要的可靠性和可维护性问题。重新标记按钮或将其移至窗口的另一部分可能需要重新录制测试。记录和播放通常还会增加无关的活动或错误记录某些活动。
这种类型的工具的一种变体是用于测试网站。在这里，“接口”是网页。但是，这样的框架使用了完全不同的技术，因为它正在渲染HTML并聆听DOM事件而不是操作系统事件。通常将基于Selenium Web驱动程序的无头浏览器或解决方案用于此目的。
这种类型的测试自动化工具的另一个变体是用于测试移动应用程序。鉴于手机上使用的不同尺寸，分辨率和操作系统的数量，这非常有用。为了进行这种变化，使用框架来实例化移动设备上的操作并收集操作结果。
另一个变化是无脚本测试自动化，不使用记录和播放，而是构建应用程序的模型，然后使测试仪能够通过简单地插入测试参数和条件来创建测试用例，这不需要脚本技能。
方法论
测试驱动的开发
测试自动化（主要是使用单元测试）是极端编程和敏捷软件开发的关键功能，它被称为测试驱动的开发（TDD）或测试优先开发。可以编写单元测试以在编写代码之前定义功能。但是，这些单元测试会随着编码的进行而扩展并扩展，发现了问题，并且代码被重构进行了重构。只有当所有要求的功能通过的所有测试都是被认为完整的代码时。支持者认为，它生产的软件比手动探索测试的代码更可靠，更昂贵。它被认为更可靠，因为代码覆盖范围更好，并且由于它在开发过程中不断运行，而不是在瀑布开发周期结束时一次运行。开发人员在进行更改后立即发现缺陷，而修复最不昂贵。最后，使用单位测试时，代码重构更安全。将代码转换为更简单的形式，而代码重复较少，但是等效行为，当重构代码被单位测试涵盖时，引入新的缺陷的可能性要小得多。
连续测试
连续测试是作为软件交付管道的一部分执行自动测试的过程，以获得与软件发布候选者相关的业务风险的立即反馈。对于持续测试，测试范围从验证自下而上的要求或用户故事到评估与总体业务目标相关的系统要求。
考虑因素
考虑决定实施测试自动化的因素
自动化，何时自动化，甚至一个人是否真正需要自动化是测试（或开发）团队必须做出的关键决策。对52名从业者和26个学术来源的多声学文献综述发现，在测试自动化决策中要考虑的五个主要因素是：1）正在测试的系统（SUT），2）测试的类型和数量，3 ）测试工具， 4）人类和组织主题，以及5）横切因素。研究中发现的最常见的个体因素是：需要回归测试，经济因素和SUT的成熟度。
高原效应
尽管软件开发公司对自动测试的可重复性进行了评价，但该属性也可以看作是一个劣势。它导致了所谓的“农药悖论” ，在那里反复执行的脚本停止检测到超出其框架的错误。在这种情况下，手动测试可能是一项更好的投资。这种歧义再次得出这样的结论，即应单独做出测试自动化的决定，遵循项目要求和特殊性。
测试什么
测试工具可以帮助自动化任务，例如产品安装，测试数据创建，GUI相互作用，问题检测（考虑解析或投票剂，配备了测试Oracles ），缺陷记录等，而无需以端到端方式自动化测试。
在考虑测试自动化时，必须保持满足流行的要求：
- 平台和操作系统独立性
- 数据驱动能力（输入数据，输出数据，元数据）
- 自定义报告（数据库数据库访问，水晶报告）
- 轻松调试和记录
- 版本控制友好 - 最小二进制文件
- 可扩展和自定义（打开API ，能够与其他工具集成）
- 常见的驱动程序（例如，在Java开发生态系统中，这意味着蚂蚁或Maven和流行的IDE ）。这使得测试能够与开发人员的工作流程集成。
- 支持无人看管的测试运行，以与构建过程和批处理运行集成。连续集成服务器需要此。
- 弹跳消息等电子邮件通知
- 支持分布式执行环境（分布式测试床）
- 分布式应用程序支持（分布式SUT ）
角色
测试自动化工具
测试自动化工具可能很昂贵，通常与手动测试结合使用。从长远来看，可以使测试自动化具有成本效益，尤其是在回归测试中反复使用时。测试自动化的良好候选者是应用程序通用流的测试用例，因为每次在应用程序中进行增强时都需要执行（回归测试）。测试自动化减少了与手动测试相关的工作。需要手动努力来开发和维护自动检查以及审查测试结果。
测试工程师
在自动测试中，测试工程师或软件质量保证人员必须具有软件编码能力，因为测试案例是以源代码的形式编写的，当运行时，该编码是根据其一部分的主张产生输出的。一些测试自动化工具允许通过关键字而不是编码来完成测试作者，而不是需要编程。
AI在测试自动化中的作用
近年来，由于人工智能（AI）技术的整合，测试自动化领域已经看到了深刻的转变。 AI对测试自动化实践产生了重大影响，彻底改变了组织进行软件测试的方式。随着AI的快速开发，软件测试变得更加有效，有助于提供高质量的软件产品。 AI驱动的解决方案在测试自动化方面引入了一些显著的优势，例如智能测试和自我修复测试。这些创新允许自动生成测试用例，测试过程的优化以及迅速检测潜在问题的能力。此外，测试自动化的AI扩大了测试范围，促进了增强的测试覆盖范围，尤其是在Web用户界面，API，移动应用程序和性能测试中。
但是，AI在测试自动化中的这种集成并非没有挑战。对培训数据的依赖是一个关键的考虑因素，因为AI模型广泛依赖于高质量的培训数据来进行准确的预测和测试案例生成。不足或有偏见的培训数据可能导致误报或假否定性，从而降低了UI测试自动化的有效性。此外，AI在测试自动化中的应用可能会在处理复杂协议（例如SOAP或GraphQL）时会遇到局限性，需要在特定情况下进行手动干预。
在不同级别的测试
决定自动化测试量的策略是测试自动化金字塔。该策略建议用不同的粒度编写三种类型的测试。级别越高，要写的测试量越小。
单元，服务和用户界面级别
- 作为坚实的基础，单元测试为软件产品提供了鲁棒性。测试代码的各个部分使编写和运行测试变得容易。开发人员将单元测试作为每个故事的一部分，并将其与CI集成在一起。
- 服务层是指分别与其用户界面分开测试应用程序的服务，这些服务是该应用程序对某些输入或一组输入的响应。
- 在最高级别，我们进行了UI测试，由于不同的属性使运行更加复杂，例如测试的脆弱性，用户界面的较小更改可以打破大量测试并添加维护，因此其测试的测试更少。努力。
单位，集成和端到端级别
测试金字塔的一个概念包含单元，集成和端到端单元测试。根据Google的测试博客，单位测试应构成您的大部分测试策略，并具有更少的集成测试，并且只有少量的端到端测试。
- 单位测试：这些是隔离测试单个组件或代码单元的测试。它们是较小的代码单位的快速，可靠和孤立的失败。
- 集成测试：这些测试检查不同的代码单位如何共同工作。尽管单个单元可以自行正常运行，但集成测试确保它们连贯地一起运行。
- 端到端测试：这些测试整个系统，模拟现实世界的使用方案。它们是最慢，最复杂的测试。
自动化的框架方法
测试自动化框架是一个集成系统，可以设置特定产品的自动化规则。该系统集成了功能库，测试数据源，对象详细信息和各种可重复使用的模块。这些组件充当小构建块，需要组装以代表业务流程。该框架提供了测试自动化的基础，并简化了自动化工作。
为自动软件测试提供支持的假设，概念和工具框架的主要优点是维护的低成本。如果对任何测试用例都有更改，则仅需要更新测试案例文件，并且驱动程序脚本和启动脚本将保持不变。理想情况下，如果应用程序更改，则无需更新脚本。
选择正确的框架/脚本技术有助于保持较低的成本。与测试脚本相关的成本是由于开发和维护工作所致。测试自动化过程中使用的脚本方法会影响成本。
通常使用各种框架/脚本技术：
- 线性（程序代码，可能由使用记录和播放的工俱生成）
- 结构化（使用控制结构 - 通常为“ if -else”，“ switch”，“ for”，while'''条件/语句）
- 数据驱动（数据持续在数据库，电子表格或其他机制的测试之外）
- 关键字驱动
- 混合动力（上面使用了两个或多个模式）
- 敏捷自动化框架
测试框架负责：
- 定义表达期望的格式
- 创建一种机制，以勾入或驱动正在测试的应用程序
- 执行测试
- 报告结果
单元测试框架
软件开发的增长趋势是使用单元测试框架，例如Xunit框架（例如Junit和Nunit ），这些框架允许执行单位测试的执行来确定代码的各个部分在各种情况下是否按预期行事。测试用例描述了需要在程序上运行的测试，以验证程序是否按预期运行。
测试自动化接口
测试自动化接口是提供一个单个工作区的平台，用于合并多个测试工具和框架，用于系统/集成测试。测试自动化接口的目的是简化将测试映射到业务标准的过程，而无需以过程的方式进行编码。测试自动化接口有望提高维护测试脚本的效率和灵活性。
测试自动化接口由以下核心模块组成：
- 接口引擎
- 接口环境
- 对象存储库
接口引擎
接口引擎建立在接口环境之上。接口引擎由解析器和测试跑者组成。解析器存在于将来自对象存储库传来的对象文件解析到特定的脚本语言中。测试跑者使用测试安全带执行测试脚本。
对象存储库
对象存储库是测试工具在探索测试应用程序时记录的UI/应用程序对像数据的集合。
定义自动化框架和测试工具之间的界限
工具专门设计用于针对某些特定的测试环境，例如Windows和Web自动化工具等。工具是自动化过程的驱动代理。但是，自动化框架不是执行特定任务的工具，而是提供解决方案的基础架构，其中不同的工具可以以统一的方式完成其工作。这为自动化工程师提供了一个通用的平台。
有各种类型的框架。它们是根据他们杠杆的自动化组件进行分类的。这些都是：
