88 lines
6.5 KiB
Markdown
88 lines
6.5 KiB
Markdown
需要改进的地方是我想实现一个机制，能够灵活地增加各种测试方法，现在的规则库我觉得不够好，我想完全重新设计，你帮我想想怎么能够实现一种强大的自定义规则库的方法（是不是完全用代码定义规则好一点？我需要你帮我设计）比如说至少要支持下面这些规则，怎么把这些验证添加到header、响应、url中，或者定义并行测试等等，我不是很清楚，你一定给我一个强大通用的设计，具体的测试功能可以先不考虑，先想想这个架构。比如域名要求是动宾结构，我就可以在这里添加大模型测试。是不是让用户自定义validate函数比较好，比如可以定义生成query的函数，定义验证url的函数，定义验证响应的函数，不同的函数自动加到不同的部分来验证，还可以定义额外的并行参数、对于响应时间等参数的测试函数等，就是提供一个testcase模板，这样也容易灵活添加，你觉得怎么样：一、 核心功能测试
|
||
|
||
1. 数据存取服务接口测试：
|
||
|
||
- 标准化查询接口验证： 测试数据查询接口，覆盖不同查询条件，验证返回结果的准确性和完整性。
|
||
- 标准化读取接口验证： 测试数据读取接口，验证特定标识数据的准确获取。
|
||
- 标准化写入接口验证： 测试数据写入接口，验证数据正确持久化，并考虑边界值、异常值写入。
|
||
- 输出格式验证： 确保所有数据存取服务的输出符合定义的数据交换格式 (JSON Schema)。
|
||
|
||
2. 状态监控接口测试：
|
||
|
||
- 实时状态反馈验证： 调用状态监控接口，验证返回的系统运行状态、接口健康度信息的准确性和实时性。
|
||
|
||
3. 专业领域扩展接口测试：
|
||
|
||
- 遵循总则要求验证： 对各专业领域扩展的数据服务接口，均需重新应用本总则中的所有相关测试点。
|
||
- 专业领域数据交换模型验证： 验证其是否按照该专业领域的特定应用要求进行设置和交互。
|
||
二、 数据服务接口规范性测试 (对应规范第7部分)
|
||
|
||
1. 通用技术实现测试：
|
||
|
||
- OpenAPI规范符合性验证：
|
||
- 验证实际API行为与描述是否一致（路径、参数、方法、响应码、数据结构等）。
|
||
- JSON序列化验证： 确保所有请求和响应的数据都使用有效的JSON格式进行序列化。
|
||
|
||
2. 数据服务接口功能与设计原则测试：
|
||
|
||
- 可靠性存取验证： 进行长时间、多并发的数据操作，验证其可靠性。
|
||
- 分页查询功能验证： 测试不同的页码、每页数量，验证返回数据子集的正确性、边界条件（首页、末页、空页）。
|
||
- 条件过滤功能验证： 测试多种有效和无效的过滤条件组合，验证结果集的准确性。
|
||
- RESTful API设计原则符合性验证：
|
||
- HTTP方法使用： 验证GET（检索）、POST（创建）、PUT（更新）、DELETE（删除）的正确使用。测试对不支持的方法返回405。
|
||
- 接口命名语义化： 评审接口名称是否为动词+名词，比如GetWellLog
|
||
- 路径结构： 验证路径是否遵循 /{专业}/{版本号}/资源类型 格式。
|
||
- 资源命名： 验证资源集合是否用复数，术语是否为行业标准。
|
||
- 请求头验证：
|
||
- 必含字段：
|
||
- X-Tenant-ID 测试： 验证包含、缺失、无效租户标识的场景下的行为，特别是数据隔离性。
|
||
- Authorization (Bearer令牌) 测试： 验证包含有效令牌、缺失令牌、无效/过期令牌的场景。
|
||
- X-Data-Domain：数据域声明，比如logging
|
||
- 路径参数测试： 全小写+下划线命名
|
||
- 查询参数测试： 测试过滤、分页、排序参数的有效组合及无效输入的处理。
|
||
- 错误响应结构验证： 触发错误，验证响应是否为包含code、message的结构化错误码（参照附录B）。
|
||
|
||
3. 模型管理接口功能与安全测试：
|
||
|
||
- 元信息管理功能验证： 测试数据字典、权限策略、接口版本等元信息的增删改查功能（若API提供）。
|
||
- 动态配置与审计追踪验证： 测试动态配置的生效情况，验证相关操作是否产生审计记录（若可查）。
|
||
- 敏感元数据访问限制： 验证不同权限用户对敏感元数据的访问是否受控。
|
||
|
||
4. 兼容性测试：
|
||
|
||
- URL版本号嵌入与多版本共存验证： 验证URL中是否包含版本号 (如 /v1/datasets)。
|
||
|
||
5. 服务质量测试)：
|
||
|
||
- 分页控制有效性： 验证分页参数能有效控制响应数据量。
|
||
四、 安全要求测试
|
||
|
||
1. 传输安全测试：
|
||
|
||
- HTTPS协议强制性验证： 验证所有接口是否仅能通过HTTPS访问，HTTP访问是否被拒绝或重定向。
|
||
- 认证鉴权方法验证：
|
||
- 无凭证访问： 尝试在未提供认证信息的情况下访问受保护接口，验证是否返回401或类似错误。
|
||
- 无效/过期凭证访问： 使用无效或过期的令牌/凭证访问，验证是否被拒绝。
|
||
|
||
2. 敏感数据防护测试：
|
||
|
||
- 敏感字段加密传输验证： 抓包分析（在HTTPS解密后，若测试环境允许）或通过响应内容，验证规范中定义的敏感字段是否按要求（如SM4算法）进行了字段级加密（此项可能需要特定配合或白盒信息）。通常HTTPS已保障传输层加密。
|
||
- 强制加密传输验证： 验证在认证鉴权后，传输内容是否仍然强制通过加密信道（HTTPS）。
|
||
|
||
3. 访问控制测试：
|
||
|
||
- 权限分离验证：
|
||
- 使用不同角色的账户/令牌，分别测试其对数据进行增加、删除、修改、查询等操作的权限。
|
||
- 验证用户A无法访问/操作用户B或其他租户的数据（除非明确授权）。
|
||
- 验证低权限用户无法执行高权限操作。
|
||
- 对未授权的操作，验证是否返回403或类似错误。
|
||
五、 附录B (JSON关键字与错误代码) 符合性测试
|
||
- 特定错误场景触发与代码验证：
|
||
- 类型校验失败 (4001)： 发送与Schema定义类型不符的数据 (如string代替number)。
|
||
- 必填字段缺失 (4003)： 请求中缺少Schema定义的必填字段。
|
||
- 数值越界 (4002)： 发送超出Schema定义minimum/maximum范围的数值。
|
||
- 自定义格式校验失败 (4004)： 发送不符合Schema中format定义的数据 (如无效的email、date-time)。
|
||
- 数组元素重复 (4005)： 若Schema定义了uniqueItems: true，发送包含重复元素的数组。
|
||
- 非法枚举值 (4006)： 发送不在Schema中enum定义列表内的值。
|
||
- 对以上每种情况，验证API是否返回对应的、正确的错误码和描述。
|