测试自动化

为了充分利用您的测试工作，请根据应用程序或 RPA 测试考虑以下测试自动化最佳实践。

应用程序测试

• 使用测试自动化框架模板实施稳定且可扩展的自动化项目。
• 测试用例应相互独立。一个测试用例不应依赖于另一个测试用例的运行。
• 测试用例应仅具有一个特定目的。每个测试工作流应仅包含一个验证。
• 每个功能都应该有一个单元测试。如果允许存在异常，则为每个测试用例创建一个单独的测试和异常。
• 在 Given-When-Then 测试用例结构中，如果 Given 部分变得过于广泛且难以管理，请尝试重新定义测试用例。它可能需要更多的粒度或重构。
• 维护测试用例，并在收到任何变更请求后进行更新。
• 考虑建立测试管理逻辑，以使用单一方法定义测试用例。
• 要提高单个测试项目之间以及测试和 RPA 项目之间的可重用性，请尽可能使用库和对象存储库。
• 将测试包含在 CI/CD 管道中。
• 应尽快运行作为 CI 管道一部分的功能测试，以免延迟构建。因此，请尝试在尽可能多的机器人上并行执行这些测试。
• 活动名称应反映所采取的操作。对于不明显的行为，请考虑在活动中使用注释。
• 考虑使用详细的日志记录和异常处理来调试流程并避免漏报结果。
• 在不同阶段计划恢复或重试错误，以避免失败的结果。
• 考虑使用专用于测试的文件夹结构，并在项目中使用相同的测试用例命名约定。
• 对于可能会更改并多次使用的变量，请使用资产。
• 对于在继续流程中的某些步骤之前必须验证应用程序状态的场景，请考虑应用验证措施。这些措施可能包括使用额外的活动，在其他交互之前等待所需的应用程序状态（硬编码延迟不被视为良好做法）。
• 只要有可能，请考虑使用模拟单击/键入或发送 Windows 消息。
• 不要在 Studio 之外删除、移动或重命名测试用例。仅在 Studio 中执行这些操作。如果应引用另一个项目中的测试用例，请使用“导入测试用例”。

RPA 测试

• 测试用例应相互独立。一个测试用例不应依赖于另一个测试用例的运行。
• 考虑创建小型工作流，以处理尽可能少的操作。通过这种方式，可以更轻松地理解并执行单元测试。
• 测试用例应仅具有一个特定目的。每个测试工作流应仅包含一个验证。
• 每个功能都应该有一个单元测试。如果允许存在异常，则为每个测试用例创建一个单独的测试。
• 要提高单个测试项目之间以及测试和 RPA 项目之间的可重用性，请尽可能使用库和对象存储库。
• 在 Given-When-Then 测试用例结构中，如果 Given 部分变得过于广泛且难以管理，请尝试重新定义测试用例。它可能需要更多的粒度或重构。模块化是良好的单元测试的关键。编写测试可以充当开发的反馈/代码审核。
• 每当有与测试用例目的无关的复杂步骤可以替换时，请使用模拟。
• 考虑建立测试管理逻辑，以使用单一方法定义测试用例。
• 维护测试用例，并在收到任何变更请求后进行更新。
• 将测试包含在 CI/CD 管道中。
• 每当提交对 RPA 的更改时，都要运行测试用例，以确保没有引入错误。
• 准备一个可由 IT 部门在预生产环境中运行的 RPA 测试集，每当他们计划推出环境更改（如 Windows 更新）时，您就可以在潜在问题出现之前将其捕获。
• 活动名称应反映所采取的操作。对于不明显的行为，请考虑在活动中使用注释。
• 在不同阶段计划恢复或重试错误，以避免失败的结果。
• 考虑使用专用于测试的文件夹结构，并在项目中使用相同的测试用例命名约定。
• 对于可能会更改并多次使用的变量，请使用资产。
• 对于在继续流程中的某些步骤之前必须验证应用程序状态的场景，请考虑应用验证措施。这些措施可能包括使用额外的活动，在其他交互之前等待所需的应用程序状态（硬编码延迟不被视为良好做法）。
• 只要有可能，请考虑使用模拟单击/键入或发送 Windows 消息。
• 不要在 Studio 之外删除、移动或重命名测试用例。仅在 Studio 中执行这些操作。如果应引用另一个项目中的测试用例，请使用“导入测试用例”。