自动化测试

自动化测试（也称为测试自动化）是指测试活动的自动化，包括软件测试和硬件测试。

在软件开发中，了解软件的固定、定义状态尤为重要，例如

• 当前的新软件版本是否比旧版本好？

在实施更改后测试对其他功能的不良影响的自动测试称为回归测试。 它们使软件在质量方面可衡量，并显示直接和可识别的更改可能产生的副作用。 它们可以作为对开发人员和可能无法立即看到整个软件系统的测试人员的直接反馈，以及识别副作用和随之而来的错误。

因此，自动测试提供了一个指标，即每次测试运行的成功测试用例数。 这允许回答以下问题：

• 软件何时能完全满足新要求？
• 错误何时修复？
• 开发人员的工作什么时候完成？
• 谁在什么时候负责什么？
• 新软件版本的质量如何（参见开发阶段（软件））？
• 新软件版本的质量是否比以前的版本更好？
• 已修复的错误或新要求是否对现有软件有影响（软件行为的变化）？
• 是否确保新软件的实时操作成功且安全？
• 该软件在新功能和任何错误修复方面实际包含哪些内容； 这可以理解吗？
• 如果无法评估软件的当前质量，是否仍能按期交付软件？

对于示例问题：“何时修复程序错误？”在这种情况下的答案是：

“正是在所有现有测试用例以及针对程序错误编写的测试用例都已成功完成时。”

只有不断的测试才能提供反馈，而这只有通过自动化才有可能实现。

自动化测试的另一个优势是开发过程的加速。 在没有自动化的软件项目中，生产、安装和测试是依次手动进行的，在完全自动化的项目中（即如果除了测试之外，生产和安装也可以自动化），这三个步骤可以同时自动启动一个接一个，例如 B. 在夜跑中。 根据项目的范围，您可以在晚上开始这个过程，并在第二天早上获得测试结果。

原则上，以下活动可以自动化：

• 创建测试用例
  • 测试数据创建
  • 测试脚本
• 测试执行
• 测试评估
• 测试文档
• 考试管理

根据用于描述测试用例的格式，可以通过将高级语言描述（测试规范）转换为这种格式来自动创建测试用例。 不同抽象级别的语言用于测试规范：用于测试数据和函数调用的简单的类似表格的符号、脚本语言、命令式语言、面向对象的方法和声明式和逻辑形式主义以及基于模型的方法（例如 TPT）。 目标是实现深远的，如果可能的话，全自动地将非机器、专业语言级别的工件翻译成接近机器的技术语言级别的工件。 另一种方法是根据要声明的业务对象动态生成测试用例创建。 如果测试规范还没有以可执行的形式提供，而是以不可执行的语言（例如 UML、Excel 表或类似语言）提供，则可以使用合适的工具将其自动转换为可执行的测试用例。

由于程序中可能的输入值和过程的数量往往非常大，因此在根据测试规范生成测试用例时，必须根据要达到的测试覆盖率来选择输入数据和过程。 软件的数据模型通常可用于创建测试数据，软件的行为模型用于在基于模型的测试中创建测试脚本。 商业市场上也有非脚本解决方案无障碍。

今天，测试主要使用全自动测试工具进行。 根据目标系统，此处使用单元测试工具、图形用户界面测试系统、负载测试系统、硬件在环测试台或其他工具。

为了评估测试，必须将获得的测试结果与预期值进行比较。 最简单的情况，这里只做一个表比较； 但是，如果目标行为由逻辑约束定义或包含极其复杂的计算，就会出现所谓的预言机问题。 如果将两个软件版本或两个测试周期以及两个测试结果与目标结果进行比较，则可以计算出趋势陈述和质量统计数据。

在测试文档中，根据收到的测试结果生成一份通俗易懂的测试报告。 为此可以使用文档生成器和模板工具。

测试管理的任务是测试套件的管理和版本控制以及提供适当的用户环境。 除了标准工具（例如 CVS、Eclipse）之外，还有一些专门为软件测试的需要量身定制的专用工具。

存在用于使上述活动自动化的各种工具。 这些总是专注于特殊任务的解决方案，并且在操作理念、语法和语义上有所不同。 因此，通常很难为一组特定的活动选择正确的工具或正确使用这些工具。 通用测试系统架构提供了活动的结构化和分类，可以针对抽象的、与解决方案无关的工具功能自动执行这些活动。 为此，它定义了五个功能级别：测试管理、测试执行和评估、测试台控制、测试对象刺激和观察以及测试对象环境。 测试系统架构支持将现有测试工具和组件集成到测试系统中，因此代表了自动化测试的通用基础。