AI Agent 驱动接口自动化测试:爱测平台从接口文档解析、路径规划到结果断言

举报
霍格沃兹测试开发学社 发表于 2026/08/01 18:49:01 2026/08/01
【摘要】 接口自动化测试已经发展了很多年,但不少团队依然面临一个现实问题:自动化脚本越来越多,测试人员却没有真正轻松下来。原因并不复杂。很多所谓的接口自动化,只是把人工发送请求改成由脚本发送请求。测试人员仍然需要手工准备请求参数、登录账号、鉴权信息、上下游数据和断言规则。一个看似简单的“创建宠物”测试场景,实际执行时可能需要依次完成:注册测试用户;调用登录接口;获取 access token;创建宠物...
接口自动化测试已经发展了很多年,但不少团队依然面临一个现实问题:

自动化脚本越来越多,测试人员却没有真正轻松下来。

原因并不复杂。

很多所谓的接口自动化,只是把人工发送请求改成由脚本发送请求。测试人员仍然需要手工准备请求参数、登录账号、鉴权信息、上下游数据和断言规则。

一个看似简单的“创建宠物”测试场景,实际执行时可能需要依次完成:

  • 注册测试用户;
  • 调用登录接口;
  • 获取 access token;
  • 创建宠物类别;
  • 创建宠物;
  • 查询宠物列表;
  • 验证返回数据与请求数据是否一致。

接口数量越多、业务链路越长,脚本编排、测试数据准备和后期维护的成本就越高。

爱测智能化测试平台引入接口测试智能体,希望解决的并不是“如何再发送一次接口请求”,而是接口请求前后的复杂工作:

  • 如何理解接口文档;
  • 如何识别接口依赖;
  • 如何规划执行顺序;
  • 如何构造符合约束的测试数据;
  • 如何处理动态鉴权信息;
  • 如何根据执行结果调整后续步骤;
  • 如何完成确定性的结果验证。

需要特别说明的是,接口测试智能体并不是用大模型取代接口执行器和断言引擎。

更合理的技术分工应该是:

AI Agent负责理解测试意图、分析接口文档和规划路径;接口执行引擎负责稳定发送请求;断言引擎负责确定性判断;平台负责日志、审计和结果追踪。

这也是企业级智能化测试与简单“大模型调用接口”之间的重要区别。

文中的接口地址、请求参数及操作界面用于说明爱测平台的能力和执行逻辑,实际接口定义与产品界面以具体接入环境和平台版本为准。


一、接口自动化的难点,早已不只是发送请求

传统接口自动化通常从一条完整的请求开始。

例如,测试人员要调用创建宠物接口,可能需要准备下面的请求:

curl -X POST 'https://api.example.com/pet/createPet' \
  -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "Lucky",
    "age": 2,
    "price": 199,
    "categoryId": 12
  }'

单独执行这一条请求并不复杂。

真正的问题在于:

  • 请求头中的 access token 从哪里获取?
  • categoryId 对应的宠物类别是否已经存在?
  • 登录账号失效后应该如何处理?
  • 上一个接口返回的字段如何传递给下一个接口?
  • 创建接口返回成功,是否代表数据已经真正写入系统?
  • 最终应该验证状态码、响应字段,还是业务数据?

为了获取 access token,测试人员需要先调用登录接口:

curl -X POST 'https://api.example.com/auth/logIn' \
  -H 'Content-Type: application/json' \
  -d '{
    "username": "auto_user_1024",
    "password": "Aice@1234"
  }'

假设登录成功,接口返回:

{
  "code"200,
  "message""success",
  "data": {
    "accessToken""eyJhbGciOiJIUzI1NiJ9...",
    "expiresIn"7200
  }
}

测试脚本还需要从响应中提取:

data.accessToken

然后将其写入后续接口的请求头:

Authorization: Bearer {{accessToken}}

如果登录接口返回账号不存在,还需要先调用注册接口,再重新登录。

因此,接口自动化真正复杂的部分通常不是发送请求本身,而是请求前后的依赖分析、参数传递、测试数据准备和结果验证。

二、从“配置每一个请求”转向“描述测试目标”

爱测平台支持传统接口测试用例和自然语言接口测试用例两种方式。

1. 传统接口测试用例

对于企业已经积累的接口测试资产,测试人员仍然可以明确配置:

  • 请求地址;
  • 请求方法;
  • 请求头;
  • 查询参数;
  • 请求体;
  • 前置接口;
  • 参数提取规则;
  • 状态码断言;
  • 响应字段断言。

例如:

name: 创建宠物

request:
  method: POST
  url: /pet/createPet
  headers:
    Authorization: Bearer ${accessToken}
    Content-Type: application/json
  body:
    name: Lucky
    age: 2
    price: 199
    categoryId: ${categoryId}

assertions:
  - statusCode: 201
  - response.name: Lucky
  - response.age: 2

这种方式适合已经拥有成熟接口脚本、固定请求模板和明确调用流程的团队。

2. 自然语言接口测试用例

对于新的业务场景,测试人员可以直接描述测试目标:

用例名称: 创建宠物正常场景

测试目标:
  注册一个新用户并完成登录,
  创建宠物类别,
  创建一只宠物,
  最后查询宠物列表并验证创建结果。

测试数据:
  宠物名称: Lucky
  年龄: 2
  价格: 199
  类别: Dog

预期结果:
  - 用户能够成功注册并登录
  - 创建宠物接口返回201
  - 查询结果中包含新创建的宠物
  - 返回的名称、年龄和价格与请求数据一致

在这种模式下,测试人员不必在用例中提前写出所有底层细节,例如:

  • 注册和登录接口地址;
  • Token 提取表达式;
  • 多个接口的执行顺序;
  • 每个请求的完整请求体;
  • 上下文变量传递关系;
  • 每一步的底层断言代码。

接口测试智能体会结合已经接入平台的接口文档,将自然语言测试目标转换成可执行的接口测试任务。

在执行页面中,测试人员可以选择对应模型、API 智能体和执行节点,然后保存并运行任务。

平台会展示测试用例、执行参数、智能规划路径,以及根据接口定义生成的请求示例。

这里需要注意:

自然语言用例并不是不要接口参数,而是由智能体协助把测试意图转换成结构化请求。

测试人员仍然需要关注业务目标、风险场景和预期结果,接口执行器仍然需要按照确定的参数发送请求。

三、智能体如何分析接口文档

接口测试智能体在执行测试之前,需要先理解接入平台的接口文档。

接口文档中通常需要包含:

  • 接口路径;
  • 请求方法;
  • operationId;
  • 请求参数;
  • 请求体结构;
  • 必填字段;
  • 字段类型;
  • 长度和取值范围;
  • 响应状态码;
  • 响应体结构;
  • 鉴权方式。

假设接口文档中包含下面这些接口:

POST /auth/signUp
POST /auth/logIn
POST /category
POST /pet/createPet
GET  /pet/readPetList
GET  /pet/{id}

当测试人员提交“创建一只宠物并验证结果”的测试目标后,智能体需要完成三层分析。

第一层:识别核心业务接口

“创建宠物”对应的核心接口可能是:

POST /pet/createPet

但只找到目标接口还不够,智能体还需要继续分析其输入条件和鉴权要求。

第二层:识别鉴权和业务依赖

假设接口文档声明,创建宠物接口需要 Bearer Token:

security:
  - bearerAuth: []

同时,请求体中必须包含:

{
  "name""string",
  "age"1,
  "price"1,
  "categoryId"1
}

智能体可以据此识别两个前置依赖:

鉴权依赖:access token
业务依赖:categoryId

因此,在调用创建宠物接口之前,需要先完成登录和宠物类别准备。

第三层:生成执行计划

完整的接口调用链路可能是:

signUp
   ↓
logIn
   ↓
createCategory
   ↓
createPet
   ↓
readPetList

智能体可以将调用链路转换成结构化执行计划:

{
  "goal""创建宠物并验证创建结果",
  "dependencies": [
    "accessToken",
    "categoryId"
  ],
  "steps": [
    {
      "order"1,
      "operationId""signUp",
      "purpose""创建测试用户"
    },
    {
      "order"2,
      "operationId""logIn",
      "purpose""获取access token"
    },
    {
      "order"3,
      "operationId""createCategory",
      "purpose""创建宠物类别并获取categoryId"
    },
    {
      "order"4,
      "operationId""createPet",
      "purpose""创建宠物"
    },
    {
      "order"5,
      "operationId""readPetList",
      "purpose""查询并验证创建结果"
    }
  ]
}

在路径规划页面中,可以同时查看接口列表、依赖关系、推荐执行路径和自动构造的测试数据。

接口文档越规范,智能体识别接口能力和依赖关系的准确性就越高。

如果接口文档缺少鉴权声明、字段约束、operationId 或响应结构,智能体的规划结果也可能受到影响。因此,AI Agent 并不能替代企业对接口文档的规范治理。

四、没有提供完整数据,智能体如何构造请求

自然语言测试用例通常只描述业务目标,不一定包含完整测试数据。

例如:

注册一个用户,登录后创建宠物类别,
再创建一只宠物,最后查询宠物列表验证结果。

这段描述中没有提供用户名、密码、宠物名称、年龄和价格。

智能体需要结合接口字段定义,生成候选测试数据。

假设注册接口要求:

{
  "username""string",
  "password""string",
  "email""string"
}

并且存在下面的参数约束:

username:
  type: string
  minLength: 6
  maxLength: 32

password:
  type: string
  minLength: 8

email:
  type: string
  format: email

智能体可以生成符合格式的测试数据:

{
  "username""auto_user_1024",
  "password""Aice@1234",
  "email""auto_user_1024@example.com"
}

对于创建宠物接口,假设文档声明:

name:
  type: string
  minLength: 1

age:
  type: integer
  minimum: 1

price:
  type: integer
  minimum: 1

categoryId:
  type: integer

智能体可以生成:

{
  "name""Lucky",
  "age"2,
  "price"199,
  "categoryId"12
}

这里的关键不是简单生成随机值,而是根据字段类型、格式、长度和取值范围,生成符合接口约束的候选数据。

对于 age > 0 这样的规则,还可以辅助生成正常、边界和异常场景:

[
  {
    "scene""正常值",
    "age"2,
    "expectedStatus"201
  },
  {
    "scene""最小边界值",
    "age"1,
    "expectedStatus"201
  },
  {
    "scene""非法零值",
    "age"0,
    "expectedStatus"422
  },
  {
    "scene""非法负数",
    "age"-1,
    "expectedStatus"422
  },
  {
    "scene""错误字段类型",
    "age""two",
    "expectedStatus"422
  }
]

但在企业环境中,测试数据生成不能只依赖模型自由发挥,还需要结合:

  • 业务字典;
  • 数据模板;
  • 测试环境规则;
  • 唯一性约束;
  • 脱敏要求;
  • 数据清理策略。

否则,即使字段格式合法,也可能生成不符合真实业务规则的数据。

五、智能体如何处理执行过程中的前置依赖

传统自动化脚本一般按照预先写好的固定顺序执行。

接口测试智能体则可以结合实际响应结果,对后续步骤进行重新分析。

以创建宠物场景为例。

第一步:尝试登录

智能体生成测试账号并调用登录接口:

POST /auth/logIn
Content-Type: application/json

请求体:

{
  "username""auto_user_1024",
  "password""Aice@1234"
}

接口返回:

HTTP/1.1 401 Unauthorized

响应体:

{
  "code"401,
  "message""user not found"
}

第二步:分析失败原因

智能体识别到当前结果可能表示测试账号不存在,于是继续在接口文档中查找用户注册接口:

POST /auth/signUp

这里不应该仅根据 HTTP 401 就直接判断“账号不存在”。

在真实系统中,401 可能代表:

  • 账号不存在;
  • 密码错误;
  • Token 失效;
  • 鉴权格式错误;
  • 登录服务异常。

因此,平台需要结合响应体中的错误码、错误信息和企业定义的错误码规则进行判断,而不能只依赖大模型猜测。

第三步:注册测试用户

智能体构造注册数据并调用接口:

curl -X POST 'https://api.example.com/auth/signUp' \
  -H 'Content-Type: application/json' \
  -d '{
    "username": "auto_user_1024",
    "password": "Aice@1234",
    "email": "auto_user_1024@example.com"
  }'

注册成功后返回:

HTTP/1.1 201 Created

第四步:重新登录并提取 Token

智能体重新调用登录接口,并从响应中提取:

{
  "data": {
    "accessToken""eyJhbGciOiJIUzI1NiJ9..."
  }
}

平台将 Token 写入执行上下文:

{{accessToken}}

后续请求可以引用:

Authorization: Bearer {{accessToken}}

第五步:创建宠物类别

如果创建宠物接口依赖 categoryId,平台需要先调用类别创建接口:

curl -X POST 'https://api.example.com/category' \
  -H 'Authorization: Bearer {{accessToken}}' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "Dog"
  }'

响应结果:

{
  "id"12,
  "name""Dog"
}

将返回的 id 保存为上下文变量:

{{categoryId}}

第六步:创建宠物

curl -X POST 'https://api.example.com/pet/createPet' \
  -H 'Authorization: Bearer {{accessToken}}' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "Lucky",
    "age": 2,
    "price": 199,
    "categoryId": {{categoryId}}
  }'

第七步:回查验证

创建接口返回成功,并不代表数据一定正确写入。

平台还需要调用查询接口:

curl -X GET 'https://api.example.com/pet/readPetList' \
  -H 'Authorization: Bearer {{accessToken}}'

然后在查询结果中定位新创建的数据,完成业务结果校验。

从执行过程可以看到,智能体的价值不仅是调用接口,还包括识别前置依赖和辅助调整执行计划。

不过,为了保证执行的可重复性和稳定性,真正发送请求的步骤仍然应该由确定性的执行引擎完成,而不是让大模型直接、不受约束地操作生产系统。

六、接口验证不能只看状态码

很多接口自动化用例只验证 HTTP 状态码:

assert response.status_code == 201

但状态码返回 201,并不能证明业务结果完全正确。

一个完整的创建接口测试,至少需要验证四个层面。

1. HTTP 状态码验证

assert response.status_code == 201

2. 响应结构验证

除了判断字段值,还应该先验证关键字段是否存在、字段类型是否正确。

response_data = response.json()

assert "id" in response_data
assert isinstance(response_data["id"], int)
assert "name" in response_data
assert isinstance(response_data["name"], str)

如果企业使用 OpenAPI Schema,也可以执行响应结构校验。

3. 请求与响应数据一致性验证

request_data = {
    "name""Lucky",
    "age"2,
    "price"199,
    "categoryId"12
}

response_data = response.json()

for field in ["name""age""price""categoryId"]:
    assert response_data[field] == request_data[field], (
        f"{field}字段不一致:"
        f"请求值={request_data[field]},"
        f"响应值={response_data[field]}"
    )

4. 业务结果回查验证

import requests

pet_list_response = requests.get(
    "https://api.example.com/pet/readPetList",
    headers={
        "Authorization"f"Bearer {access_token}"
    },
    timeout=10
)

assert pet_list_response.status_code == 200

response_body = pet_list_response.json()
pet_list = response_body["data"]

created_pet = next(
    (
        pet
        for pet in pet_list
        if pet["name"] == request_data["name"]
        and pet["categoryId"] == request_data["categoryId"]
    ),
    None
)

assert created_pet is not None"查询结果中未找到新创建的宠物"
assert created_pet["age"] == request_data["age"]
assert created_pet["price"] == request_data["price"]

这里还需要注意一个问题:只通过名称和类别定位数据,可能遇到重复数据。

在真实测试中,更可靠的方式是优先使用创建接口返回的唯一 ID:

created_pet_id = response_data["id"]

detail_response = requests.get(
    f"https://api.example.com/pet/{created_pet_id}",
    headers={
        "Authorization"f"Bearer {access_token}"
    },
    timeout=10
)

assert detail_response.status_code == 200

detail = detail_response.json()

assert detail["id"] == created_pet_id
assert detail["name"] == request_data["name"]
assert detail["age"] == request_data["age"]
assert detail["price"] == request_data["price"]

因此,接口测试智能体生成断言时,不能只关注状态码,还应该根据接口语义选择更稳定的业务验证方式。

七、AI 可以生成断言,但不应该独立决定测试是否通过

这是智能化接口测试中非常重要的一条原则。

大模型适合辅助完成:

  • 识别哪些字段值得验证;
  • 根据自然语言预期生成断言草案;
  • 分析失败日志;
  • 解释请求和响应差异;
  • 推荐补充验证点。

但最终的测试通过与失败,应该由确定性的规则执行。

例如:

{
  "assertions": [
    {
      "type""statusCode",
      "operator""equals",
      "expected"201
    },
    {
      "type""jsonPath",
      "path""$.name",
      "operator""equals",
      "expectedFrom""${request.name}"
    },
    {
      "type""jsonPath",
      "path""$.id",
      "operator""notNull"
    }
  ]
}

平台将智能体生成的断言转换成结构化规则,再由断言引擎执行。

这样做有三个好处:

  1. 相同输入可以获得稳定结果;
  2. 测试结果可以回放和审计;
  3. 模型升级不会直接改变历史用例的通过标准。

八、全链路测试报告,让执行过程可追踪

AI Agent 参与接口测试后,一个非常重要的问题是:

智能体为什么选择了这条执行路径?

如果测试报告只展示“通过”或者“失败”,测试人员很难判断问题究竟出在:

  • 接口本身;
  • 测试数据;
  • 鉴权信息;
  • 参数构造;
  • 接口依赖;
  • 路径规划;
  • 还是断言规则。

因此,爱测平台会记录接口调用链路、请求参数、响应结果和断言信息。

测试报告中可以查看:

调用链路

signUp
  ↓
logIn
  ↓
createCategory
  ↓
createPet
  ↓
readPetList

执行结果概览

执行时长:00:13
接口调用:5
断言通过:8
失败数量:0

单接口请求信息

POST /pet/createPet
Authorization: Bearer ***
Content-Type: application/json

请求数据

{
  "name""Lucky",
  "age"2,
  "price"199,
  "categoryId"12
}

响应数据

{
  "id"10086,
  "name""Lucky",
  "age"2,
  "price"199,
  "categoryId"12
}

断言结果

状态码等于201                         通过
响应体包含id字段                      通过
response.name等于request.name        通过
response.age等于request.age          通过
response.price等于request.price      通过
查询接口能够读取新创建的数据           通过

一份完整的智能体测试报告,至少应该回答以下问题:

  1. 智能体执行了哪些接口;
  2. 为什么按照这个顺序执行;
  3. 测试数据是如何生成的;
  4. 参数如何在接口之间传递;
  5. 每一条断言由谁生成、由谁执行;
  6. 失败具体发生在哪一个步骤;
  7. 执行过程是否可以回放。

九、企业落地时,还需要解决四个关键问题

接口测试智能体能够降低脚本编排成本,但企业落地时不能只关注模型能力。

1. 测试数据隔离与清理

智能体自动创建的账号、类别、订单和业务对象,需要有明确的数据标识和清理机制。

例如,可以为自动生成数据增加统一前缀:

aice_auto_user_20260730_1024
aice_auto_category_20260730_001

测试完成后,再执行清理接口或者数据库清理任务,避免测试环境长期积累脏数据。

2. 敏感信息保护

测试报告和执行日志中不应该明文展示:

  • access token;
  • 登录密码;
  • Cookie;
  • API Key;
  • 身份证号;
  • 手机号;
  • 银行卡号。

例如:

Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

在报告中应脱敏为:

Authorization: Bearer eyJ***d9

3. 执行可重复性

如果智能体每次都随机选择完全不同的数据和路径,失败问题可能难以复现。

平台应记录:

  • 用例版本;
  • 接口文档版本;
  • 模型版本;
  • Prompt 或 Skill 版本;
  • 测试数据;
  • 执行计划;
  • 环境信息;
  • 断言规则。

这样才能在问题发生后重新执行相同任务。

4. 权限和环境控制

智能体不应该在没有权限控制的情况下任意调用接口。

企业需要限制:

  • 可以访问哪些环境;
  • 可以调用哪些接口;
  • 是否允许执行新增、删除、退款等高风险操作;
  • 单次任务最多调用多少接口;
  • 是否需要人工审批;
  • 是否允许连接生产环境。

对于删除数据、资金操作、权限变更等高风险接口,应该增加人工确认或禁止智能体自动执行。

十、接口测试智能体带来的核心变化

爱测平台并不是简单地在接口测试工具中增加一个大模型对话框。

它真正改变的是接口自动化测试的建设方式。

从接口配置驱动转向测试意图驱动

测试人员优先描述业务目标和预期结果,智能体再生成结构化执行计划。

从人工编排转向辅助规划

智能体结合接口文档识别鉴权依赖、数据依赖和业务前置条件,减少人工编排工作。

从静态数据转向动态数据构造

平台可以结合字段约束和业务模板生成测试数据,减少账号、Token 和关联业务数据的准备成本。

从固定脚本转向可调整的执行计划

当接口返回结果与预期不一致时,智能体可以辅助分析原因,并在受控范围内调整后续步骤。

从状态码断言转向业务链路验证

除了验证状态码,还可以验证响应结构、数据一致性和最终业务结果。

从黑盒执行转向全链路可追踪

平台记录接口调用、参数构造、响应结果、执行路径和断言信息,方便问题定位和复盘。

十一、哪些团队更适合引入接口测试智能体

接口测试智能体更适合以下场景:

接口数量较多

系统中存在大量微服务和业务接口,人工维护接口链路的成本较高。

接口依赖复杂

测试场景涉及注册、登录、鉴权、数据创建、状态流转和结果查询等多个接口。

测试数据准备困难

测试账号、Token、订单、商品和类别数据需要动态创建,难以长期使用固定数据。

接口变化频繁

接口字段、路径和鉴权方式经常调整,传统脚本维护成本较高。

已经使用 AI 生成测试用例

团队已经能够根据需求文档或接口文档生成测试用例,希望继续打通自动执行、结果验证和报告分析环节。

希望降低自动化维护成本

团队积累了大量接口测试脚本,但脚本修改、测试数据维护和失败排查占用了较多时间。

十二、企业可以如何逐步落地

引入接口测试智能体并不意味着推翻现有接口自动化体系。

企业可以分三个阶段推进。

第一阶段:规范并接入接口文档

重点检查:

  • 接口路径是否完整;
  • operationId 是否唯一;
  • 请求字段定义是否准确;
  • 响应结构是否明确;
  • 状态码和错误码是否齐全;
  • 鉴权方式是否声明;
  • 参数约束是否完整。

第二阶段:选择典型业务链路

优先选择:

  • 用户注册与登录;
  • 商品创建与查询;
  • 订单创建与状态流转;
  • 数据新增与回查;
  • 权限申请与审批;
  • 不涉及真实资金的测试场景。

这些场景依赖关系清晰,适合验证智能体的路径规划和数据构造能力。

第三阶段:接入持续集成流程

当接口测试任务已经稳定后,可以逐步用于:

  • 提交后的接口冒烟测试;
  • 测试环境每日回归;
  • 发布前核心链路验证;
  • 接口文档变更影响分析;
  • 失败用例智能归因。

需要注意,接入 CI/CD 后,执行入口应调用爱测平台实际提供的 API、插件或任务触发能力,而不是自行假设某个不存在的命令行工具。

写在最后

接口自动化测试的发展,不应该只停留在“自动发送请求”。

真正影响接口测试效率的,是请求前后的大量工作:

  • 如何理解接口文档;
  • 如何识别上下游依赖;
  • 如何准备测试数据;
  • 如何处理鉴权信息;
  • 如何根据响应结果调整执行计划;
  • 如何验证最终业务结果;
  • 如何快速定位失败原因。

爱测智能化测试平台通过接口文档、自然语言测试用例和接口测试智能体,将这些环节连接起来。

测试人员负责描述业务目标和风险场景,智能体负责辅助分析和规划,接口执行器负责稳定执行,断言引擎负责确定性判断。

这种架构既能利用大模型对自然语言和复杂上下文的理解能力,又能保留传统自动化测试所要求的稳定性、可重复性和可审计性。

目前,爱测智能化测试平台已经能够根据接口文档生成接口测试用例,并借助接口测试智能体完成路径分析、测试数据构造、接口执行、结果验证和测试报告生成。

对于正在建设接口自动化测试体系、探索 AI Agent 测试能力,或者希望降低接口脚本维护成本的团队,可以预约爱测平台试用,体验从接口文档、测试用例到智能执行和测试报告的完整流程。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料,主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容,侧重测试实践、工具应用与工程经验整理。

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。