Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
本文介绍管道 测试报表 和 测试分析中使用的常用术语,并提供有关在 Azure Pipelines 中更好地测试的提示。
| 术语 | Definition |
|---|---|
| Duration | 在生成或发布管道中执行 测试、 测试运行或 整个测试执行 的时间。 |
| Owner | 测试或测试运行的所有者。 测试所有者通常指定为测试代码中的属性。 请参阅 “发布测试结果 ”任务,查看支持的测试结果格式的 “所有者” 属性的映射。 |
| 生成失败 | 对生成具有测试用例连续失败的第一次生成的引用。 |
| 失败的发布 | 对出现测试用例连续失败的第一次版本的引用。 |
| 结果 | 测试结果有 15 个可能的结果:中止、阻止、错误、失败、无结果、正在进行、无、不适用、未执行、未影响、传递、暂停、超时、未指定和警告。 一些常用的结果包括: - 已中止:测试执行因内部或外部因素(例如代码错误、环境问题)而突然终止。 - 失败:测试不满足所需的结果。 - 无结论:在没有最终结果的情况下进行测试。 - 未执行:标记为已跳过执行的测试。 - 不受影响:测试不受触发管道的代码更改的影响。 - 通过:测试已成功执行。 - 超时:测试执行持续时间超过指定的阈值。 |
| Flaky 测试 | 具有不确定行为的测试。 例如,测试可能会导致相同的配置、代码或输入产生不同的结果。 |
| 滤波器 | 使用可用属性搜索结果集中的测试结果的机制。 了解详细信息。 |
| 分组 | 基于可用属性(如 要求、 测试文件、 优先级等)组织测试结果视图的帮助。 测试报告和测试分析都支持对测试结果进行分组。 |
| 传递百分比 | 衡量单个执行实例或一段时间内的测试结果是否成功。 |
| 优先级 | 指定测试的重要性或重要性程度。 优先级通常指定为测试代码中的属性。 请参阅 “发布测试结果 ”任务,查看支持的测试结果格式的 Priority 属性的映射。 |
| 测试分析 | 用于提供有意义的见解 的历史测试数据的视图 。 |
| 测试用例 | 唯一标识指定分支中的单个测试。 |
| 测试文件 | 根据打包方式对测试进行分组;例如文件、DLL 或其他格式。 |
| 测试报告 | 管道中 测试执行的单个实例的视图 ,其中包含状态详细信息以及故障排除、可跟踪性等帮助。 |
| 测试结果 | 具有特定结果和详细信息的测试用例执行的单个实例。 |
| 试运转 | 基于以下结果的逻辑分组: - 使用内置任务执行的测试:使用单个任务(如 Visual Studio 测试、 Ant、 Maven、 Gulp、 Grunt 或 Xcode )执行的所有测试都将在单个测试运行下报告 - 使用 发布测试结果 任务发布的结果:提供一个选项,用于将一个或多个测试结果文件中的所有测试结果分组到单个运行中,或按文件单独运行 - 使用 API(s)发布的测试结果: API(s) 可以灵活地创建测试运行,并根据需要为每个运行组织测试结果。 |
| 溯源 | 能够从测试结果中向前或向后 跟踪 到要求、bug 或源代码。 |
最佳做法
确保应用程序可靠性需要在 Azure Pipelines 中 进行全面的测试 ,单元测试和集成测试至关重要。 在云环境中(尤其是 无服务器应用程序)中测试集成会带来挑战,因为分布式体系结构、配置不当的 IAM 权限和服务到服务集成问题。
若要解决此问题,请考虑在本地运行代码,同时与真正的 Azure 服务交互,促进实际测试并启用适合自动测试的调试器工具。 实现此方法需要预配临时 Azure 资源。 理想情况下, 为每个环境创建单独的帐户;或者,Azure 管道中的动态预配是可能的,尽管这会增加执行时间,并且需要仔细的资源停用计划。 若要最大程度地减少命名冲突,请避免显式资源命名,除非必要,并在资源名称中包含环境名称。
帮助和支持
- 请参阅 我们的故障排除 页面
- 获取有关 Stack Overflow 的建议,并通过开发人员社区获取支持