通过OpenAPI 测试脚本生成器批量生成脚本

1. 概述

主要优势：

快速生成测试脚本： 根据您的 API 定义自动生成一套测试脚本（包括正向和各种反向场景），极大地加快了测试创建过程。
改进测试覆盖率： 生成涵盖您 API 端点不同方面的测试（例如，有效请求、无效数据类型、缺少必需字段、边界条件），这些都依据 OpenAPI 规范中的定义。
一致性和标准化： 确保测试脚本遵循标准化的结构和方法，促进测试团队内的维护和协作。
减少手动工作： 最大限度地减少初始 API 验证所需的手动编写测试脚本的需求，使测试人员能够专注于更复杂的场景和探索性测试。
与 Git 集成： 将生成的测试脚本直接存储在指定的 Git 仓库中，便于版本控制、代码审查以及集成到 CI/CD 流水中线。

2. 先决条件

在使用 Testany 从 OpenAPI 规范成功生成测试脚本之前，请确保满足以下前置条件：

2.1 创建 Git 仓库凭证

为了让 Testany 能够与您的 Git 仓库交互，以读取 OpenAPI 规范（如果托管在那里）并写入生成的测试脚本，您需要配置两种类型的 Git 访问权限：

只读访问： 如果您的 OpenAPI 规范文件托管在私有 Git 仓库中，并且您在生成过程中选择“URL 导入”方法，则需要此权限。此访问权限允许 Testany 安全地获取和读取规范文件。
写入访问： Testany 将自动生成的测试脚本和相关环境变量文件提交并推送到目标 Git 仓库的指定分支时需要此权限。

为了向 Testany 提供必要的 Git 访问权限，您必须在您的 Git 提供商（Bitbucket、GitHub ）中生成一个个人访问令牌。强烈建议将这些令牌安全地存储在专用的秘密管理系统中，例如：

Azure Key Vault
AWS Secrets Manager

👉 参考文档：

创建令牌后，请联系您所在的工作区的管理员在Testany中注册该凭证。

👉 参考文档：管理测试过程中的凭证

2.2 确保 OpenAPI 规范质量

强烈建议 在将您的 OpenAPI 规范上传或导入到 Testany 之前，使用 API 安全和质量工具（例如 42Crunch）对其进行审计，以确保其质量并遵循最佳实践。具体来说，以42Crunch为例，力争达到高“安全评分”（理想情况下满分）和高于 40 分的“数据校验评分”。事先审计规范有助于确保生成的测试基于一个明确定义且安全的 API 契约，从而生成更健壮、更成功的测试脚本。

2.3 确定 Git 分支和生成记录所有者

在启动测试脚本生成过程之前，您需要决定：

目标 Git 分支： 您必须指定将提交生成的测试脚本的 Git 分支的名称。强烈建议专门为此生成过程设置一个 新的且专用的分支。这种做法可以确保可靠的测试执行，并防止意外覆盖稳定分支上的现有代码。请勿使用任何现有分支，除非您有意图覆盖其内容。 如果分支不存在，Testany 会创建它。
生成记录所有者： 决定您打算为 OpenAPI 规范中定义的哪些特定 API 生成测试，以及您的团队中谁将负责维护生成的测试脚本和 Testany 中相应的生成记录。为每条生成记录指定所有者有助于确保适当的问责制并方便未来的更新或故障排除。

3. 分步指南

按照以下步骤使用 Testany 从您的 OpenAPI 规范生成 API 测试脚本。

3.1 前期步骤：访问向导

首先，通过以下步骤访问 Testany 界面中的“从 OpenAPI 生成”向导：

导航到“测试用例库”部分。
点击“注册测试用例”按钮旁边的“↓”箭头图标。
从下拉菜单中选择“从 OpenAPI 生成”。

Test Case Tree View - Testany - 12 May 2025.gif

3.2 创建新的生成记录

在生成向导的“步骤 1/2”中，您通常会选择是创建新生成还是更新现有生成。要全新开始，请点击“创建新生成记录”。

3.2.1 配置生成设置

进入“步骤 2/2”，在这里您将配置生成的详细设置。然后点击“提交”按钮.

3.2.1.1 基本信息

提供生成记录的基本信息：

名称： 为此生成记录输入一个唯一且有描述性的名称。此名称有助于日后识别该记录。请注意，名称在提交生成后无法更改。
运行时： 展开下拉列表并选择将执行这些脚本的目标测试运行时环境。可用的运行时取决于您的 Testany 配置。
点击“下一步”继续。

注意：如果某个运行时当前不可用或非工作状态，它将在选择列表中显示为灰色。

3.2.1.2 OpenAPI 规范

通过以下两种方式之一向 Testany 提供 OpenAPI 规范文件（支持 OpenAPI，版本 3.x 及以上）：

3.2.1.2.1 本地上传

如果您将 OpenAPI 规范文件本地存储在计算机上：

切换到“本地上传”标签页。
点击指定区域，将您的 OpenAPI 文件直接上传到 Testany。

3.2.1.2.2 URL 导入

如果您的 OpenAPI 规范可通过 URL 访问：

切换到“URL 导入”标签页。
输入 OpenAPI 文件的完整 URL。
点击“获取”以检索规范的内容。

注意：如果 OpenAPI 文件存储在私有 Git 仓库中或需要认证才能访问该 URL，您需要提供具有该资源的只读访问的相应凭证。从显示的“令牌”下拉列表中选择预配置的凭证（由您的管理员根据 2.1章节 注册）。

文件被 Testany 成功解析后，将显示一条确认消息，表明规范已正确处理。

3.2.1.3 仓库信息

填写将存储生成的测试脚本的 Git 仓库详细信息：

仓库类型：Bitbucket 或 GitHub
仓库 URL：https://bitbucket.org/workspace/repo.git 或 https://github.com/username/repo.git
分支：<分支名称> 此分支名称在提交生成后无法更改（详见 2.3章节）
仓库令牌： 选择具有对指定仓库的写入访问权限的预配置 Git 凭证（由您的管理员根据 2.1章节注册）。

3.2.1.4 选择端点并启动生成

在生成向导的最后一步，您将看到从您的 OpenAPI 规范中发现的 API 端点列表。

选择您要为其生成测试脚本的特定 API 端点。您可以选择单个端点或整个路径/组。
点击“生成测试脚本”。

然后，Testany 将根据您的选择和提供的 OpenAPI 规范开始生成测试脚本。测试脚本成功生成并注册到 Testany 后，将出现一个确认弹出窗口。此弹出窗口通常显示：

用于提交生成脚本的仓库 URL 和分支名称。
每选定端点生成的测试文件（*.py 文件）数量。

3.2.2 查看 Testany 中已注册的测试用例

测试脚本成功生成并自动导入到Testany后，新创建的测试用例将出现在 Testany 的测试用例库中。

为了轻松找到此特定生成过程注册的用例，您可以在测试用例库中使用标签和条件的组合进行筛选搜索：

labels = {您的分支名称} (Testany 会自动添加一个与目标分支名称对应的标签)
created_from = {生成日期} (按生成记录创建的日期筛选)
owner = {用户 ID} (按启动生成的用户筛选)

有关管理这些已注册测试用例（包括它们与 Git 仓库的关系）的更多详细信息，请参阅有关批量导入的指南部分：从Git批量导入测试用例 #3.1.9.

3.2.3 查看 Git 中生成的测试脚本

OpenAPI 测试生成器的核心输出是提交到您的 Git 仓库指定分支的一组测试脚本。Testany 会以标准化的结构组织这些脚本。

3.2.3.1 分支概览和目录结构

导航到您在 3.2.1.3章节中配置的 Git 仓库的特定分支。您将找到 Testany 创建的一个新的目录结构（通常位于仓库根目录或配置的指定子目录中）。该结构按 API 端点组织：

CODE

Testany-scripts/                (示例根目录)
 ├─ env/                        (包含环境变量/测试数据文件)
 │   ├─ {method}_{endpoint_1_url}_environment.txt
 │   ├─ {method}_{endpoint_2_url}_environment.txt
 │   └─ ...
 ├─ {method}_{endpoint_1_url}/  (特定端点的目录，例如 post_pet_petId)
 │   ├─ positive/               (包含正向测试脚本)
 │   │   └─ test_{method}_{endpoint_1_url}_positive.py
 │   └─ negative/               (包含反向测试脚本)
 │       ├─ test_{method}_{endpoint_1_url}_negative_header_{field}.py
 │       ├─ test_{method}_{endpoint_1_url}_negative_path_{field}.py
 │       ├─ test_{method}_{endpoint_1_url}_negative_query_{field}.py
 │       ├─ test_{method}_{endpoint_1_url}_negative_body_{field}.py
 │       └─ ...                 (根据 schema 定义的其他反向场景)
 ├─ {method}_{endpoint_2_url}/
 │   └─ ...
 └─ ...

POST /pet/{petId}的示例结构：

根据 OpenAPI 路径 POST /pet/{petId}，Testany 会生成一个遵循 {method}_{endpoint_url_path_segments} 命名约定的专用目录和文件。这种结构按端点和测试类型（正向/反向）对测试脚本进行逻辑分组，使得导航和管理生成的代码变得容易。

CODE

Testany-scripts/
 ├─ env/
 │   └─ post_pet_petId_environment.txt                  (此端点的环境变量/数据)
 └─ post_pet_petId/
     ├─ positive/
     │   └─ test_post_pet_petId_positive.py             (正向测试脚本)
     └─ negative/                                       (反向测试)
         ├─ test_post_pet_petId_negative_body_name.py   (针对 body 中 'name' 字段的反向测试)
         ├─ test_post_pet_petId_negative_body_status.py (针对 body 中 'status' 字段的反向测试)
         └─ test_post_pet_petId_negative_path_petId.py  (针对 path 中 'petId' 的反向测试)

3.2.3.2 反向测试场景

CODE

Testany-scripts 
 ├─ {method}_{endpoint_1_url}
 │   └─ negative
 │       ├─ test_{method}_{endpoint_1_url}_negative_header_{field}.py
 │       ├─ test_{method}_{endpoint_1_url}_negative_path_{field}.py
 │       ├─ test_{method}_{endpoint_1_url}_negative_query_{field}.py
 │       ├─ test_{method}_{endpoint_1_url}_negative_body_{field}.py

每个端点的 negative/ 子目录包含旨在测试 API 如何根据 OpenAPI 规范的 schema 定义处理无效或非预期输入的脚本（*.py 文件）。这些测试专门用于覆盖输入数据或请求结构违反 OpenAPI schema 中定义约束的场景。此类违规通常会触发带有 400 级别 HTTP 状态码的客户端错误响应，而不是服务器错误或认证/授权问题（如 401 Unauthorized 或 403 Forbidden）。文件名表明了正在测试的特定字段及其位置（例如，_negative_body_status 测试请求体中的 status 字段）。

Testany 的生成过程会考虑 OpenAPI 规范约束（如 minLength, maxLength, format, pattern, enum, nullable, type, required 等）定义的各种反向场景。

下表提供了 Testany 可以生成的反向测试场景类型的清晰概览，按数据类型和场景 ID 进行组织。每个条目列出了场景 ID、适用的数据字段类型、场景描述、必须定义的 OpenAPI 约束条件（以便生成此场景）以及可能跳过的条件。它能帮助开发和 QA 团队理解生成的脚本所执行的反向测试范围，并快速参考哪些约束条件触发了特定的测试场景。

场景 ID	字段类型	场景描述	必要约束条件	跳过条件
1.00	string	符合所有约束条件的有效字符串值
1.01	string	不符合指定格式的字符串值	定义了 `format`
1.02	string	不符合指定模式的字符串值		定义了 `enum`
1.03	string	字符串长度小于 `minLength`	定义了 `minLength`	定义了 `enum`
1.04	string	`minLength` > 0 时，字符串为空	`minLength > 0`	定义了 `enum`
1.05	string	字符串长度大于 `maxLength`		定义了 `enum`
1.06	string	字符串值不在 `enum` 列表中	定义了 enum
1.07	string	`nullable` 为 false 时，字符串值为 null	`nullable=false`
1.08	string	值类型是数字而不是字符串	`type=string`
1.09	string	值类型是布尔值而不是字符串	`type=string`
1.10	string	值类型是数组而不是字符串	`type=string`
1.11	string	值类型是对象而不是字符串	`type=string`
1.21	string	payload 中不存在此字段	字段是必需的
2.00	integer	符合所有约束条件的有效整数值
2.01	integer	不符合指定格式的整数值	定义了 `format`	定义了 `enum`
2.03	integer	整数值小于 `minimum`	定义了 `minimum`	定义了 `enum`
2.05	integer	整数值大于 `maximum`	定义了 `maximum`	定义了 `enum`
2.06	integer	整数值不在 `enum` 列表中	定义了 `enum`	定义了 `minimum`、`maximum`、`multipleOf`中的任意一个
2.07	integer	`nullable` 为 false 时，整数值为 null	`nullable=false`
2.09	integer	值类型是布尔值而不是整数	定义了 `format`
2.10	integer	值类型是数组而不是整数	定义了 `format`
2.11	integer	值类型是对象而不是整数	定义了 `format`
2.12	integer	值类型是浮点数而不是整数	定义了 `format`
2.13	integer	`exclusiveMinimum` 为 true 时，整数值等于 minimum	`exclusiveMinimum=true`	定义了 `enum`
2.15	integer	`exclusiveMaximum` 为 true 时，整数值等于 maximum	`exclusiveMaximum=true`	定义了 `enum`
2.16	integer	整数值不是指定数字的倍数	定义了 `multipleOf`	定义了 `enum`、`minimum`、`maximum`中的任意一个
2.17	integer	值类型是字符串而不是整数	`type=integer`
2.21	integer	payload 中不存在此字段	字段是必需的
3.00	boolean	符合所有约束条件的有效布尔值
3.08	boolean	值类型是数字而不是布尔值	`type=boolean`
3.10	boolean	值类型是数组而不是布尔值	`type=boolean`
3.11	boolean	值类型是对象而不是布尔值	`type=boolean`
3.17	boolean	值类型是字符串而不是布尔值	`type=boolean`
3.21	boolean	payload 中不存在此字段	字段是必需的
4.00	number	符合所有约束条件的有效数值
4.01	number	不符合指定格式的数值	定义了 `format`	定义了 `enum`
4.03	number	数值小于 `minimum`	定义了 `minimum`	定义了 `enum`
4.05	number	数值大于 `maximum`	定义了 `maximum`	定义了 `enum`
4.06	number	数值不在 `enum` 列表中	定义了 `enum`	定义了 `minimum`、`maximum`、`multipleOf`中的任意一个
4.07	number	`nullable` 为 false 时，数值为 null	`nullable=false`
4.09	number	值类型是布尔值而不是数值	`type=number`
4.10	number	值类型是数组而不是数值	`type=number`
4.11	number	值类型是对象而不是数值	`type=number`
4.13	number	`exclusiveMinimum` 为 true 时，数值等于 minimum	`exclusiveMinimum=true`	定义了 `enum`
4.15	number	`exclusiveMaximum` 为 true 时，数值等于 maximum	`exclusiveMaximum=true`	定义了 `enum`
4.16	number	数值不是指定数字的倍数	定义了 `multipleOf`	`定义了 enum、minimum、maximum中的任意一个`
4.17	number	值类型是字符串而不是数值	`type=number`
4.21	number	payload 中不存在此字段	字段是必需的
5.00	array	符合所有约束条件的有效数组值
5.03	array	数组长度小于 `minItems`	定义了 `minItems`
5.04	array	`minItems` > 0 时，数组为空	`minItems > 0`
5.05	array	数组长度大于 `maxItems`
5.07	array	`nullable` 为 false 时，数组值为 null	`nullable=false`
5.08	array	值类型是数字而不是数组	`type=array`
5.09	array	值类型是布尔值而不是数组	`type=array`
5.11	array	值类型是对象而不是数组	`type=array`
5.17	array	值类型是字符串而不是数组	`type=array`
5.18	array	`uniqueItems` 为 true 时，数组包含重复项	`uniqueItems=true`
5.21	array	payload 中不存在此字段	字段是必需的
6.00	object	符合所有约束条件的有效对象值
6.03	object	对象属性数量小于 `minProperties`	定义了 `minProperties`
6.04	object	`minProperties` > 0 时，对象为空	`minProperties > 0`
6.05	object	对象属性数量大于 `maxProperties`	定义了 `maxProperties`
6.07	object	`nullable` 为 false 时，对象值为 null	`nullable=false`
6.08	object	值类型是数字而不是对象	`type=object`
6.09	object	值类型是布尔值而不是对象	`type=object`
6.10	object	值类型是数组而不是对象	`type=object`
6.17	object	值类型是字符串而不是对象	`type=object`
6.19	object	对象缺少必需属性	属性是必需的
6.20	object	`additionalProperties` 为 false 时，对象包含额外属性	`additionalProperties=false`
6.21	object	payload 中不存在此字段	字段是必需的

以 test_post_pet_petId_negative_body_status.py为例：

如果 POST /pet/{petId} 请求体中 status 字段的 OpenAPI 定义是带有特定约束（例如，一个 enum）的字符串，则生成的脚本 test_post_pet_petId_negative_body_status.py 将包含根据这些约束而适用的上述表格中的场景测试。例如，如果 status 被定义为一个字符串枚举，那么场景 1.02（不符合模式，如果定义了模式）、1.05（长度大于 maxLength，如果定义了 maxLength）、1.06（不在 enum 列表中），以及类型不匹配（1.08、1.09、1.10、1.11）等都可能被生成，前提是存在相关的约束。

3.2.3.3 环境变量和测试数据

env/ 目录包含文本文件（每个端点一个），文件名为 {method}_{endpoint_url}_environment.txt。这些文件保存了执行相应端点生成的正向和反向测试场景所需的测试数据和环境变量。

CODE

Testany-scripts/
 ├─ env/
 │   ├─ {method}_{endpoint_1_url}_environment.txt  (端点 1 的数据)
 │   ├─ {method}_{endpoint_2_url}_environment.txt  (端点 2 的数据)
 │   └─ ...

每个 {method}_{endpoint_url}_environment.txt 文件列出了生成的 Python 脚本在执行期间将使用的变量（如基础 URL、正向用例的特定参数值、反向用例的无效值，以及可能的其他环境配置）。

如果您需要根据特定的业务需求、测试环境或数据可用性修改生成的测试数据，您应该直接在您的 Git 仓库中更新这些 .txt 文件。进行更改后，请按照您的标准 Git 工作流程提交并推送更新。执行这些脚本的 Testany 运行时将从指定的分支获取这些环境变量文件的最新版本。

以 post_pet_petId_environment.txt 为例：

此文件将包含 test_post_pet_petId_positive.py 和 post_pet_petId/ 目录下所有 test_post_pet_petId_negative_*.py 脚本所需的测试数据。这包括有效的 petId 值、用于 name 和 status 等字段的有效和无效请求体数据，以及可能的其他环境配置。

3.3 更新生成记录

您可以更新现有生成记录，以便根据修改后的 OpenAPI 规范或从同一规范文件源中选择不同的端点集来重新生成测试脚本。

3.3.1 选择要更新的生成记录

在生成向导的“步骤 1/2”中：

展开“生成记录”下拉列表。
选择您希望更新和重新生成的特定生成记录。

3.3.2 重新上传或重新导入 OpenAPI 文件

选择记录后，您将进入配置步骤（类似于 3.2.1章节）。提供更新后的 OpenAPI 规范文件。这可以通过重新上传本地文件或从 URL 重新导入来完成。

提供更新后的规范后，点击“提交”。

3.3.3 选择端点并提交

类似于 3.2.1.4章节，在“选择 API 端点”页面选择您要生成或重新生成测试脚本的 API 端点。向导将解析更新后的 OpenAPI 规范。

更新的关键注意事项：

覆盖生成的代码： 指定 Git 分支中选定 API 的测试脚本和环境变量文件将根据新的 OpenAPI 规范和您选择的端点重新生成并完全替换。这意味着之前在该分支中为此些 API 生成的内容将被覆盖。
分支覆盖： 作为第 1 点的直接结果，此生成记录关联的特定分支上 Testany-scripts/（或等效目录）内的全部内容将根据新的生成输出进行更新或替换。您在先前生成的文件中进行的任何手动更改，如果这些文件被重新生成，可能会丢失。
对未选择 API 的影响： 如果某个 API 端点在上次此记录生成时被选中，但在本次更新步骤中被手动取消选择，则其在 Testany 中对应的已注册测试用例将在导入过程完成后被删除或与 Git 仓库解除关联。具体行为（删除还是解除关联）取决于该测试用例当前是否包含在任何测试流水线中（参见下方参考）。
重命名/移动 API 的影响： 如果某个 API 端点在上次生成时被选中，但在重新上传的 OpenAPI 规范中被重命名或移动了位置，Testany 将其视为新的或丢失的端点。它将不再作为同一可选择的端点出现在此记录的生成向导中。因此，其之前在 Testany 中注册的（链接到旧名称/路径的）测试用例将在流程完成后被删除或解除关联（参见下方参考）。

👉 参考：从Git批量导入测试用例 #3.3.2.

3.4 删除生成记录

删除生成记录会移除 Testany 中记录与它创建的已注册测试用例之间的关联。这也会影响已注册的测试用例本身。

3.4.1 选择并删除生成记录

在删除生成记录之前，请仔细评估其对通过此生成过程注册的测试用例的影响。

删除对已注册测试用例的影响：

未组装到任何测试流水线中的测试用例： 如果此生成记录创建的测试用例当前未包含在任何测试流水线中，它们将从 Testany 中永久删除。
已组装到测试流水线中的测试用例： 如果测试用例当前包含在一个或多个测试流水线中，它们将保留在 Testany 中以保持测试流水线的完整性，但它们将与此生成记录以及特定的 Git 仓库/分支解除关联。您可以在删除生成记录之前从相关的测试流水线中移除这些测试用例，以确保它们从 Testany 中永久删除；或者您可以在移除生成记录且它们解除关联后，手动在测试用例库中找到并删除它们。

请注意：此操作未影响已经生成的源代码。它们仍然保留在您的Git仓库中。

在生成向导的“步骤 1/2”中：

展开“生成记录”下拉列表。
选择您希望删除的特定生成记录项。
点击该项目旁边的删除按钮（由垃圾桶图标表示）。

5. 常见问题 (FAQ)

问题： 为什么我在生成过程中看到以下错误？

💡 回答： 这些错误通常表明访问源 OpenAPI 规范或目标 Git 仓库时存在问题。请确保：

如果使用 URL 导入，请验证 OpenAPI URL 是否正确且可以从 Testany 环境访问。
如果 URL 或仓库是私有的，请确认在配置过程中选择了正确的 Git 凭证（访问令牌）。
验证选定的凭证是否具有所需的访问级别：从私有 URL 获取需要只读访问（3.2.1.2.2 章节），提交到仓库需要写入访问（3.2.1.3章节）。
检查 Git 仓库 URL 和分支名称是否有任何拼写错误或格式不正确。

问题： 为什么我无法删除测试用例库中的某些测试用例？

💡 回答： 在 Testany 中删除测试用例的能力取决于其来源和所有权。通常：

您可以删除您直接上传的、您自己拥有的测试用例。
您可以删除从 Git 仓库导入的测试用例（例如由 OpenAPI 功能生成的），前提是您是启动导入/生成的用户并且该用例目前未关联到阻止其删除的测试流水线。
从 Git 导入但已关联到测试流水线的用例可能需要先从测试流水线中移除，或者在删除生成记录时可能解除关联但不被删除（参见 3.4章节）。

问题： 如何追踪测试用例来自哪个仓库和提交？

💡 回答： 对于从 Git 仓库导入或生成的测试用例，请导航到 Testany 中该特定测试用例的详情页，鼠标选停在 source 上或者直接点击其图标链接打开源文件。