自动化测试套件生成器

幂简官方

227 浏览

21 试用

5 购买

Nov 19, 2025更新

本提示词专为开发人员和测试工程师设计，能够根据代码结构、功能需求或用户故事等输入规格，自动生成全面且可执行的测试套件。通过智能分析输入信息，系统会创建包含单元测试、集成测试和功能测试的完整测试方案，显著提升测试覆盖率并减少人工编写测试用例的时间。该工具支持多种测试类型和优先级设置，确保生成的测试套件既符合业务需求又具备良好的可维护性。

测试套件概述

目标：基于给定业务规则与用户故事，构建覆盖“单元/集成/功能/端到端”的高优先级自动化测试套件，验证价格计算、优惠选择、运费计价、库存锁定与释放、支付回调幂等、订单状态机、并发一致性、可观察性指标。
范围：
- 服务：order-svc、inventory-svc、payment-adapter（沙箱）、coupon-svc
- 流程：类目页筛选→详情页→购物车→结算→支付→回调→完成（含邮件/站内信）
- 业务规则：购物车限制（50行/单SKU≤5件）、优惠“满减优先，券次之”、地区+重量运费/免运门槛、库存提交订单时锁定30分钟、支付回调幂等、Pending→Paid→Fulfilled/Cancelled 状态机
非目标：渲染层像素级视觉回归、第三方真实支付网关联调（使用沙箱/模拟）
通过标准（验收）：
- 有券/无券、不同地区运费、并发下单均能生成正确订单金额与状态
- 幂等回调不重复扣减库存/发券
- 可观察性完备（关键埋点/日志/trace，测试中可断言）

测试环境要求

操作系统：Ubuntu 22.04 LTS
运行时与语言：Node.js 18、TypeScript 5
依赖：PostgreSQL 14、Redis 6、Nginx（静态与反向代理）
容器：Docker 24 + Docker Compose
服务：
- order-svc（HTTP API，端口示例：8080）
- inventory-svc（端口示例：8081）
- coupon-svc（端口示例：8082）
- payment-adapter（沙箱，端口示例：8083）
环境变量（示例占位值）：
- DB_URL=postgres://postgres:postgres@postgres:5432/shop
- REDIS_URL=redis://redis:6379/0
- PAYMENT_SANDBOX_KEY=change-me
- JWT_SECRET=local-dev-secret
- FEATURE_COUPON_STACKING=false
浏览器：Playwright Chromium（E2E）
CI：GitHub Actions（Node 18 矩阵 + Postgres/Redis 服务容器），报告：JUnit + Allure
建议依赖与脚本：
- 测试框架：Jest + ts-jest（单元/集成/功能）、Supertest（API）、testcontainers（可选，内启容器）、Playwright（E2E）
- 报告：jest-junit、allure-jest、allure-playwright
- 时间控制：@sinonjs/fake-timers（单元）、可配置 LOCK_TTL_SEC（集成/功能环境中加速）

测试用例列表

说明：

编号前缀：UT- 单元、IT- 集成、FT- 功能、E2E- 端到端
接口路径供参考，可在测试配置中以 BASE_URL 绑定到 Nginx 反向代理
优先级：均为高

单元测试

用例编号	测试类型	前置条件/数据	测试步骤	预期结果	优先级
UT-001	价格计算-税费	税率10%（exclusive），单价100，qty=2	调用 priceCalculator({items:[{100,2}], tax=10%})	总商品=200；税=20；合计=220	高
UT-002	运费-按地区+重量	模板A：CN-NORTH 基础10，>5kg每kg+2；包邮门槛99	计算 4kg 商品金额80，地区CN-NORTH	运费=10（未达免运）；合计=90	高
UT-003	运费-免运门槛	模板A，金额120，4kg	计算	运费=0（达99免运）	高
UT-004	大件运费	模板B：CN-SOUTH 大件附加20，基础8	20kg 大件金额300	运费=8+20=28	高
UT-005	满减优先	满100-20，券10元不可叠加	金额120，尝试同时应用	选满减（实际-20）不叠加券	高
UT-006	券优先于无满减	无满减可用，券10元	金额80	应用券-10	高
UT-007	地址校验	地址对象缺省邮编	validateAddress()	返回错误码 INVALID_ZIP	高
UT-008	库存扣减函数	SKU-STD-001 库存10	reserve(5) 后 available=5；release(5) 恢复到10	高
UT-009	锁定超时释放	锁TTL 30min（测试用5秒）	lock(2) 后 advanceTimersByTime(5s)	锁释放，可再锁	高
UT-010	状态机-正常流	Pending→Paid→Fulfilled	触发支付成功→发货	合法转移，无异常	高
UT-011	状态机-取消流	Pending→Cancelled	取消时触发库存回补与退款事件emit	事件发出，状态=Cancelled	高
UT-012	回调幂等键	同一 paymentId+nonce	processCallback(x2)	第二次返回“idempotent/no-op”，无重复副作用	高

集成测试

用例编号	测试类型	前置条件/数据	测试步骤	预期结果	优先级
IT-001	订单↔库存-扣减	SKU-STD-001 库存10	POST /api/orders 创建订单 qty=3	库存保留=3，订单=Pending	高
IT-002	提交时锁定30min	LOCK_TTL_SEC=5（测试加速）	下单qty=2→Redis查看TTL	TTL≈5s，锁存在	高
IT-003	锁过期自动释放	延时>TTL	再次下单qty=9	成功锁定（释放生效）	高
IT-004	支付回调-签名验签	sandbox key	POST /payment/callback 签名正确	订单转Paid，库存实际扣减	高
IT-005	回调幂等	重复发送同一回调	第二次返回200但no-op；库存/券/状态不变	高
IT-006	优惠选择（不叠加）	满100-20；券10元；金额120	POST /api/checkout/pricing	选择满减方案，总价-20，券未用	高
IT-007	不同地区运费	CN-NORTH vs CN-SOUTH 相同商品重量	两次计算	运费不同，符合模板A/B	高
IT-008	发券服务联动	支付成功后触发发券（若活动配置）	完成支付→监听发券回调/队列	仅一次发券（幂等）	高
IT-009	取消订单退款回补	Paid 订单取消	POST /api/orders/{id}/cancel	状态=Cancelled；退款事件；库存回补	高
IT-010	发票信息存储	提交发票抬头/税号	下单→查询订单详情	发票字段正确持久化	高

功能测试（API/业务流程）

用例编号	测试类型	前置条件/数据	测试步骤	预期结果	优先级
FT-001	购物车-新增	登录 testuser	POST /api/cart add SKU-STD-001 x2	行数+1，数量=2	高
FT-002	购物车-编辑数量	现有 x2	PATCH /api/cart line qty=5	数量=5	高
FT-003	购物车-单SKU上限	已有 x5	再加 x1	被拒，错误 CODE=SKU_QTY_LIMIT	高
FT-004	购物车-行数上限	已有50行	新增第51行	被拒，CODE=CART_LINE_LIMIT	高
FT-005	购物车-删除	有1行	DELETE /api/cart/{lineId}	行删除成功	高
FT-006	结算-地址校验	地址缺邮编	POST /api/checkout	400 INVALID_ZIP	高
FT-007	价格明细	有券/满减场景	POST /api/checkout/pricing	返回明细：商品小计/税/运费/优惠/应付	高
FT-008	提交订单	购物车有效、地址/配送方式就绪	POST /api/orders	返回订单号，状态=Pending，锁定库存	高
FT-009	支付失败重试	Pending 订单	POST pay intent→模拟失败→重试成功	成功转Paid	高
FT-010	站内信/邮件	Paid→Fulfilled	监听消息日志/事件	邮件/站内信发送一次	高

端到端测试（Playwright）

用例编号	测试类型	前置条件/数据	测试步骤	预期结果	优先级
E2E-001	无券-CN-NORTH	SKU-STD-001 2件，金额≥免运	浏览类目→详情→加购→购物车→结算→选地址NORTH→下单→跳转沙箱→模拟成功→回跳	订单Paid；运费0；金额正确；订单详情可见	高
E2E-002	有券-无满减更优	券10元，满减不可用	与001相同但金额<满减门槛	应用券-10；对账正确	高
E2E-003	满减优先	满100-20与券10并存	路径同上	选择满减；不叠加券	高
E2E-004	CN-SOUTH 运费模板B	相同SKU重量	选择南区地址	运费按B模板；总额正确	高
E2E-005	大件商品	SKU-BULK-001 20kg	全流程	含大件附加；支付后Paid	高
E2E-006	预售商品	SKU-PRE-001	全流程	Paid 后可下单但发货标记为预售，状态机正常	高
E2E-007	移动端视口	iPhone 12 视口	相同流程	UI/流程可用，金额一致	高
E2E-008	回调幂等	已支付成功	重放回调2次（devtools/脚本）	第二次无副作用；日志记录idempotent	高

并发与一致性（归类为集成/端到端的专项场景）

用例编号	测试类型	前置条件/数据	测试步骤	预期结果	优先级
IT-CC-001	并发扣减同一SKU	SKU-STD-001 可售10	并发20个下单请求各qty=1	成功≈10，失败≈10；无超卖；库存一致	高
IT-CC-002	超时释放后再下单	同上	成功10→等待锁TTL过期→再下单10	第二批可成功（锁释放生效）	高
IT-CC-003	可观察性校验	开启trace/log指标	并发下单	指标包含：锁等待时间、callbacks幂等命中、库存冲突数	高

测试数据说明

构造方式：混合（数据库种子 + API 造数 + Factory/Builder）
推荐目录
- tests/fixtures/seed.sql（或 seed.ts）
- tests/factories/{user,sku,order}.ts
- tests/helpers/{auth,pricing,payment}.ts
基础种子（示例）
- 用户：testuser@example.test / P@ssw0rd!
- SKU：
  - SKU-STD-001（现货，price=100，weight=1kg，stock=100）
  - SKU-PRE-001（预售，price=80，weight=0.5kg，stock=100，fulfill_policy=presale）
  - SKU-BULK-001（大件，price=300，weight=20kg，stock=20，tag=bulk）
- 运费模板：
  - 模板A（CN-NORTH）：base=10，>5kg 每kg+2，free_threshold=99
  - 模板B（CN-SOUTH）：base=8，bulk_surcharge=20，free_threshold=199
- 税：rate=10%（exclusive）
- 优惠：
  - 满减：FULL100_20（订单满100减20）
  - 优惠券：C10（满50-10）、P10（全场9折），受 FEATURE_COUPON_STACKING=false 限制
数据依赖初始化
- npm run db:migrate && npm run db:seed:test
- 或 tests/bootstrap.ts 中使用 testcontainers 拉起 Postgres/Redis 并执行 seed
账户与鉴权
- 通过 /api/auth/login 获取 JWT，tests/helpers/auth.ts 提供 getAuthToken()
并发测试数据
- 事先设置库存精确值（如10），并在测试结束 teardown 回滚

执行建议

执行顺序
1. 单元测试（无外部依赖，最快，先行发现逻辑缺陷）
2. 集成测试（docker compose 启动依赖服务，验证服务间交互）
3. 功能测试（API 级端到端业务流）
4. 端到端测试（Playwright，含移动端视口）
5. 并发专项（可能占用时间，放在最后并可单独作业）
稳定性与加速
- 为锁定与回收相关测试设置可配置 LOCK_TTL_SEC=5（测试环境），避免真实30分钟等待
- 网络重试与幂等令牌：提交订单/支付创建时附带 Idempotency-Key 头，重试不重复下单
- 对 payment-adapter 使用沙箱固定响应与固定签名密钥
可观察性
- 在订单创建/库存锁定/支付回调/状态转移点记录结构化日志（含 orderId、paymentId、idempotencyKey）
- OpenTelemetry trace：下单→库存→券→支付→通知的跨服务 traceId 可在测试中断言存在
- Metrics：并发冲突计数、锁等待直方图、回调幂等命中计数
CI 集成（简述）
- GitHub Actions：使用 services: postgres, redis；步骤含 docker compose up -d；npm ci；npm run test:unit/integration/e2e
- 报告：jest-junit 输出到 reports/junit.xml；Allure 结果到 reports/allure-results，playwright generate report
目录与命名规范
- tests/unit/...：Calculator.spec.ts、StateMachine.spec.ts
- tests/integration/...：OrderInventory.spec.ts、PaymentCallback.spec.ts
- tests/functional/...：Cart.spec.ts、Checkout.spec.ts
- tests/e2e/...：PurchaseFlow.spec.ts
- 用例命名：should_<行为>when<条件>，标签化注释 @critical @idempotency @concurrency
运行脚本（示例）
- npm run test:unit
- npm run test:int
- npm run test:func
- npm run test:e2e
- npm run report:allure

附：关键用例实现要点（简要）

支付回调验签：对 payload 使用 PAYMENT_SANDBOX_KEY HMAC-SHA256，测试含签名正确/错误、重复回调
并发下单：Jest + p-map 并发发起 20 个 POST /api/orders，请求体带相同 SKU 与不同 idempotency-key；统计成功/失败分布并校验库存不为负
锁释放测试：在测试环境临时将 LOCK_TTL_SEC=5；下单→等待>5s→再次下单应成功
价格计算断言：断言 amount_breakdown = {subtotal, tax, shipping, discount, total} 与预期匹配
预售 SKU：下单成功、状态 Paid，且 fulfillment 标记为 presale，不立即计入已发货

以上套件设计遵循等价类与边界值分析，覆盖正常流程与异常/并发场景，具备可执行性、可维护性，并满足验收标准。

测试套件概述

测试目标
- 验证鉴权与授权闭环：/auth/login、/auth/refresh、/users/me、/orders、/admin/* 的正确性与安全性
- 覆盖 RBAC（user、manager、admin）与资源级权限（订单仅资源所有者可访问）
- 验证限流策略：每IP、每用户、登录接口独立限流；超限返回友好提示并有审计日志
- 验证安全与可观测：密码加盐哈希、JWT RS256、公私钥轮换兼容、刷新令牌可撤销（Redis白名单）、审计日志字段完整（userId/ip/ua/traceId）、Prometheus 指标导出
- 回归：刷新后旧令牌处理、密钥轮换期间兼容
测试范围
- 测试类型：接口测试、单元测试、回归测试（优先级：中）
- 端点范围：/auth/login、/auth/refresh、/users/me、/orders（资源级检查）、/admin/*（仅admin）
- 限流策略验证：RATE_LIMIT_IP=60/m、RATE_LIMIT_USER=120/m、LOGIN_LIMIT=5/m（部分用例在测试环境下调值以缩短执行时间）

测试环境要求

操作系统：Ubuntu 22.04
后端：Java 17 + Spring Boot 3（Gradle 构建）
依赖：
- MySQL 8（用户、角色、订单数据）— 使用 Testcontainers 自动启动
- Redis 6（限流与刷新令牌白名单）— 使用 Testcontainers 自动启动
- NGINX（反向代理/注入 X-Request-Id）— 非必需；接口测试可直接打到应用（在测试中手动设置 X-Request-Id 头模拟网关）
密钥管理（测试态）：
- 动态生成自签名RS256密钥对（避免硬编码）：通过测试启动钩子生成，并注入 env：JWT_PRIVATE_KEY、JWT_PUBLIC_KEY
- 轮换测试额外生成第二套密钥对，测试中以容器重启或 Spring TestContext 重载属性模拟切换
配置：
- RATE_LIMIT_IP=60/m、RATE_LIMIT_USER=120/m、LOGIN_LIMIT=5/m（接口限流场景可通过测试 profile 下调到小值，如 5/m、10/m）
- X-Request-Id 由测试请求头注入（traceId）
框架与工具：
- 单元测试：JUnit 5 + Mockito + AssertJ
- 接口测试：SpringBootTest(WebEnvironment.RANDOM_PORT) + RestAssured + JSONAssert
- Testcontainers：MySQL、Redis 容器（网络联通），支持重复构建
- 日志验证：Logback Test ListAppender（捕获审计日志）
- 指标验证：访问 /actuator/prometheus
- 报告：Surefire + Allure
CI：
- Gradle 任务：test（单元）→ integrationTest（接口/回归）
- 并行/隔离：测试类级隔离，数据自动生成并清理，保证可重复运行

测试用例列表

说明：

编号规则：UT-xx（单元）、API-xx（接口）、REG-xx（回归）
优先级：均为“中”
步骤中默认基于 RestAssured 发 HTTP；必要时说明日志捕获与容器重启动作
若涉及订单接口细化，默认采用 REST 风格 /orders/{id}；若实现不同，请在测试适配层映射

用例编号	测试步骤	预期结果	优先级
UT-01 JWT签发-包含必要Claims	模拟用户登录成功后调用TokenService.issue(); 断言payload含exp、iat、aud、roles，exp>iat，roles包含用户角色	JWT有效载荷完整且类型正确	中
UT-02 JWT校验-正常	使用RS256密钥对签发token，调用TokenService.validate();	返回有效，包含主体与claims	中
UT-03 JWT校验-过期	构造已过期token（exp<now），validate()	抛出过期异常/返回无效	中
UT-04 JWT校验-签名不匹配	用不同私钥签发token，服务端用本公钥验签	校验失败	中
UT-05 JWT校验-受众aud不匹配	签发aud=tenantA，资源检查要求tenantB	校验或授权失败（403/无效）	中
UT-06 权限判定-RBAC	使用角色矩阵(user/manager/admin)调用AuthorizationService.canAccess("/admin/x")	仅admin返回true；其余false	中
UT-07 权限判定-订单所有者	模拟订单ownerId=U1：用户U1访问返回true，U2访问false	资源级权限正确	中
UT-08 限流键生成-IP	传入ip、路由、窗口参数生成key	key格式稳定（含ip与路由标识），相同输入相同输出	中
UT-09 限流键生成-用户	传入userId、路由生成key	key包含userId且避免冲突	中
UT-10 密码加盐哈希	调用PasswordService.hash("p")两次结果不同；verify匹配	加盐有效且验证通过	中
API-01 登录成功	POST /auth/login {username: user1, password: valid}；请求头User-Agent与X-Request-Id设置	200；返回accessToken、refreshToken；access可解码含roles、aud；审计日志包含userId/ip/ua/traceId	中
API-02 登录失败-密码错误	POST /auth/login {username: user1, password: wrong}	401或400；提示友好且不泄露具体原因；审计日志记录失败事件（含ip/ua/traceId；userId可为空或未知）	中
API-03 登录限流	连续6次/分钟相同账号或同IP调用 /auth/login	第6次返回429与友好提示；审计日志有“login_rate_limited”事件	中
API-04 刷新成功	登录获取refreshToken；POST /auth/refresh {refreshToken}	200；返回新access/refresh；新access签发iat更新、exp延后	中
API-05 刷新失败-无效/撤销	使用伪造或已撤销refreshToken调用 /auth/refresh	401；错误码/消息明确，审计日志记录	中
API-06 退出-刷新令牌失效	登录→刷新获得R2→调用注销API（若无显式接口，则调用服务端提供的 revoke 或在测试中调用服务层）→再用R2刷新	刷新失败（401）；Redis白名单已移除/标记失效	中
API-07 访问受保护资源-无Token	GET /users/me	401	中
API-08 访问受保护资源-有效Token	登录获取access；GET /users/me	200；返回自己的用户信息（userId匹配token）	中
API-09 访问受保护资源-过期Token	构造短exp token或操控时钟让token过期；GET /users/me	401（token过期）	中
API-10 RBAC-访问admin-普通用户	user角色Access；GET /admin/any	403（拒绝）且审计日志记录授权失败	中
API-11 RBAC-访问admin-admin用户	admin角色Access；GET /admin/any	200	中
API-12 订单-仅所有者可读	用户A创建订单O1；用户B使用其access访问GET /orders/{O1}	403（拒绝）	中
API-13 订单-所有者可读	用户A访问GET /orders/{O1}	200；返回订单ownerId=用户A	中
API-14 每用户限流	登录用户X；1分钟内对某受保护资源发起121次请求	≥第121次返回429；其它非用户限流优先级不抢占；Prometheus限流命中计数增加	中
API-15 每IP限流	未登录/或多用户从同一IP发起61次公共可访问动作（或同一受保护资源不同用户以避免用户限流触发）	≥第61次返回429；Prometheus命中率指标可观测	中
API-16 审计日志-字段完整	成功登录、访问受保护资源、触发一次限流；捕获日志	三类日志均包含userId（登录失败场景允许空）、ip、ua、traceId；traceId=请求头X-Request-Id	中
API-17 Prometheus指标-限流	触发登录限流≥1次后访问/actuator/prometheus	存在限流命中指标（如 rate_limit_hits_total 之类，包含维度key或route）；值≥1	中
REG-01 刷新后旧令牌处理	登录得A,R；用R刷新得A2,R2；用旧A继续访问受保护资源	按约定行为验证：旧A在exp内仍可用（200）；无黑名单误拦截	中
REG-02 密钥轮换兼容	用私钥K1签发token T1；服务切换到K2（公钥K1仍信任）；用T1访问/users/me；再登录获取新token应由K2签发	T1仍可用（200）；新token验签keyId/签名变化，兼容期无中断	中
REG-03 登录限流-审计回归	连续触发>阈值登录限流	429返回体包含友好提示（不含敏感信息）；审计日志事件枚举值/格式稳定	中
REG-04 历史问题-跨租户访问被拒	使用aud=tenantA的token访问tenantB数据资源（如预置订单隶属tenantB）	403；审计日志记录跨租户拒绝，包含traceId	中

补充说明：

REG-02 环境切换：通过 Testcontainers 或 Spring TestContext 动态属性重载模拟密钥轮换（先加载K1，执行请求；后重启应用容器或刷新上下文为K2，同时保留旧公钥用于验签，验证兼容）
API-12/13 订单接口：若系统未提供创建接口，测试可通过仓储层插入测试订单数据，并在测试结束清理

测试数据说明

用户与角色（测试库预置或自动生成）
- admin 用户1个（角色：admin；tenant=tenantA，示例）
- 普通用户 userA、userB 各1个（角色：user；tenant=tenantA/tenantB）
- 可选 manager 用户1个（角色：manager）
- 密码使用自动生成并通过 PasswordService.hash 入库，避免明文存储
订单数据
- 自动生成订单记录，字段至少包含：id、ownerId、tenant、status、amount、createdAt
- 用例API-12/13：为userA创建订单O1（tenantA）；为跨租户回归（REG-04）创建tenantB下订单O2
JWT/密钥
- 测试启动生成密钥对K1（默认）与K2（轮换），以PEM字符串形式注入环境变量（仅在测试容器生命周期内有效）
- accessToken 过期性测试：可通过测试配置缩短TTL（如 5s），或使用可注入的Clock/TimeProvider
限流配置
- 默认按题设；为缩短测试：
  - 用户限流在 integrationTest profile 下设 RATE_LIMIT_USER=10/m
  - IP 限流 RATE_LIMIT_IP=15/m
  - 登录限流 LOGIN_LIMIT=3/m
Redis
- 刷新令牌白名单：测试生成 refreshToken 时写入白名单；注销/撤销测试移除并断言
审计日志
- 使用 Logback ListAppender 捕获日志事件；日志为结构化JSON或键值对（根据实现），断言包含 userId、ip（从请求或代理头）、ua（User-Agent）、traceId（X-Request-Id）
Prometheus 指标
- 通过 /actuator/prometheus 抓取；断言存在包含 “rate_limit” 与 “login”/“user”/“ip” 维度的计数器或直方图（若具体名为 rate_limit_hits_total、rate_limit_exceeded_total 等，测试正则匹配名称与labels）

执行建议

执行顺序（由快到慢，减少依赖耦合）
1. 单元测试（UT-01…UT-10）：纯内存执行，快速反馈
2. 接口测试基础流（API-01、02、07、08、09）：验证鉴权/基础保护
3. 接口测试权限/资源（API-10、11、12、13）
4. 限流相关（API-03、14、15、17）：在独立测试类中，使用下调阈值的测试profile；各测试间通过时间窗口隔离或重置计数键
5. 审计日志完整性（API-16）：集中验证
6. 回归测试（REG-01…REG-04）：容器/上下文重载较慢，放最后
注意事项
- 测试隔离：每个测试类使用独立测试数据命名空间（如 tenant/test-run-id），或在BeforeEach/AfterEach清理DB、Redis键（限流计数、refresh白名单）
- 时钟控制：对于过期/刷新类用例使用可注入Clock或Awaitility等待最小窗口，防止时间抖动导致 flakiness
- 并发与速率：限流测试需串行执行；通过 JUnit @ResourceLock 或 Gradle test max-parallel-forks 配置避免相互干扰
- 友好提示与错误码：断言不包含敏感信息（例如“不提示用户是否存在”）
- 密钥轮换：保障旧公钥在轮换窗口内仍可用于验签；测试需要显式加载“受信公钥集合”
- CI 重复运行：所有数据自动生成，测试结束清理；避免依赖系统时间外部状态；容器镜像使用固定标签
产出与报告
- 通过 Allure 注解为每个用例打标签（type=unit/api/regression、component=auth/rbac/rate-limit）
- 输出覆盖率报告（branches for auth/rbac/rate-limit modules）并在CI阈值中设置最小覆盖标准（如 80% lines / 70% branches）

备注

若 /orders 仅提供集合接口（非 /orders/{id}），可替换为查询自身订单列表并尝试查询包含他人订单的ID，预期返回过滤后集合不含他人订单或返回403。
若系统提供显式 /auth/logout 接口，API-06 使用该端点；如无，则通过服务层撤销 refreshToken 并验证。

测试套件概述

目标：验证订单服务在订单确认后发布的 OrderConfirmed 事件被账单服务正确消费，生成账单与发票，PDF正确存储与可下载；保证幂等与一致性（重复事件不重复记账，失败进入DLQ并可补偿），跨服务链路可追踪（traceId贯穿），对账任务与支付网关一致。

范围：

单元测试：金额汇总/税率应用/币种转换、幂等仓储、PDF模板渲染、抬头与税号校验、风控前置校验
集成测试：Kafka消费与重试、DLQ路由、对象存储（MinIO）上传与预签名、对账任务对接支付网关沙箱、OpenTelemetry传播
功能测试：发票下载、账单列表过滤、异常标记与备注
端到端测试：下单→事件→账单生成→PDF可下载→对账通过的整链路
回归测试：历史“重复消费导致双记账”问题与DLQ回放防重、事件模式演进兼容

默认优先级：低（可在执行建议中按阶段提升关键用例优先级）

测试环境要求

运行平台
- Kubernetes 开发命名空间（例如 dev-billing），镜像：billing-svc:latest、order-svc:latest
- CI：Argo Workflows 触发集成/端到端测试
消息与存储
- Kafka 3.5 + Schema Registry（建议Confluent兼容端点），Topic: order.events（key=orderId），DLQ: order.events.dlq
- PostgreSQL 14（账单库，具账单表/发票表/幂等表唯一索引）
- MinIO（发票PDF存储），专用bucket（如 invoices），私有ACL
配置与凭据（以K8s Secret/ConfigMap注入）
- KAFKA_BROKERS
- SCHEMA_REGISTRY_URL
- MINIO_ENDPOINT
- ACCESS_KEY / SECRET_KEY
- EXCHANGE_RATE_PROVIDER=mock（稳定汇率）
- 可观测：OpenTelemetry Collector，Grafana Tempo/Prometheus
测试框架与工具
- 单元/集成：JUnit5/TestNG、AssertJ、Mockito、Testcontainers（Kafka、MinIO、Postgres、Schema Registry）
- 接口/功能：REST-assured 或 Playwright API、Awaitility（异步断言）
- 支付网关沙箱：WireMock/MockServer
- 事件序列化：Avro/JSON Schema 校验（依据实际实现）
前置数据
- 两种税类（例：Digital 6%，Physical 13%）、三种币种（USD、EUR、CNY）、风控开关可配置（on/off）
- 账单库初始化DDL、唯一约束（order_id 唯一、idempotency_key 唯一）
- MinIO 预建 bucket invoices

测试用例列表

编号	类型	前置条件	测试步骤	预期结果	优先级
UT-001	单元	EXCHANGE_RATE_PROVIDER=mock	计算含两项明细、折扣10%、税类不同（Digital/Physical），币种USD	总金额=明细小计-折扣+税额；四舍五入符合规则（中间保留4位，最终2位）	低
UT-002	单元	mock汇率：EUR→USD=1.10	转换三项明细EUR→USD，校验中间与最终精度	最终金额符合精度策略，不丢失分（cent）	低
UT-003	单元	税率表启用	税额按地区CN/US、品类不同	税额按规则正确，免税类为0	低
UT-004	单元	幂等仓储有唯一索引(idempotency_key)	并发两次以同一orderId保存处理标记	仅一条记录插入，第二次返回已存在	低
UT-005	单元	PDF模板与样例数据	渲染包含多语言字符、发票抬头/税号	PDF可生成，文本完整，无乱码，文件大小>0	低
UT-006	单元	税号规则表	校验发票抬头与税号（有效/无效/空）	有效通过；无效给出错误；空必填报错	低
UT-007	单元	风控开关=on	风控失败时阻止开票	返回阻断状态，不写账单/发票	低
IT-001	集成	Testcontainers: Kafka+Schema Registry	发送 OrderConfirmed 到 order.events（key=orderId），消费成功Ack	消费者提交offset；事件模式通过Schema校验；账单入库	低
IT-002	集成	Kafka主/重试策略配置	模拟Postgres短暂失败抛可重试异常	消费重试N次后成功；未进入DLQ	低
IT-003	集成	Kafka DLQ已配置	模拟非重试异常（税号校验失败）	消息路由到DLQ，header含Idempotency-Key与error原因	低
IT-004	集成	Testcontainers MinIO	生成PDF并上传至MinIO，生成预签名URL	对象存在于invoices/{invoiceId}.pdf；Content-Type=application/pdf；预签名URL可用且过期时间正确	低
IT-005	集成	WireMock支付网关沙箱	触发对账任务（手动触发接口或模拟定时）	对账匹配成功：账单标记reconciled；不匹配：生成差异报告并标记异常	低
IT-006	集成	OTel Collector/Tempo已运行	生产事件带traceparent，消费端启用Context Propagation	Tempo中可看到跨服务链路（order-svc→billing-svc）同一traceId	低
IT-007	集成	MinIO不可用	处理事件时上传PDF失败	写入DLQ并记录失败原因；幂等记录保持“未完成”状态	低
FT-001	功能	登录为有权限用户	GET /invoices/{id}/pdf	返回200，PDF可下载，审计日志记录下载人/时间	低
FT-002	功能	已有多笔账单	GET /billing?status=paid&currency=USD&dateRange=...	过滤结果准确，分页/排序正确，空结果返回空集合	低
FT-003	功能	存在异常账单	POST /billing/{id}/abnormal with note; GET查看	账单被标记异常，备注可见，可审计，重复标记受限	低
FT-004	功能	多币种账单	GET /billing/{id}	展示原币金额及主币（如USD）换算金额，汇率标注撮合时点	低
E2E-001	端到端	K8s部署order-svc/billing-svc	调用下单接口→order.events发出→账单服务消费→生成账单与发票PDF→发送通知	DB生成账单+发票；MinIO存在PDF；通知发送成功；Tempo中完整trace	低
E2E-002	端到端	幂等开启	发送相同orderId事件两次	仅一笔账单/发票；第二次被认定重复且不重复记账	低
E2E-003	端到端	风控=on	下单命中高风险→补偿前不出发票；解除风险后触发补偿/重放	初次入DLQ或待处理；解除后生成发票，状态更新正常	低
E2E-004	端到端	支付成功交易存在于沙箱	完成支付→运行对账任务	对账通过，账单状态=reconciled，报告无差异	低
E2E-005	端到端	制造一笔网关侧有而账单侧无	运行对账任务	生成差异报告，账单标记异常，告警指标上报	低
REG-001	回归	并发消费者>=2	注入短暂DB错误导致重试；重复消费相同orderId	不发生双记账；唯一索引和幂等记录生效	低
REG-002	回归	Schema新增可选字段discountReason	发布包含新字段的事件	兼容消费成功；老字段仍正常解析	低
REG-003	回归	存在历史DLQ消息	触发DLQ回放工具/补偿流程	回放后不产生重复账单；成功后从DLQ移除	低

测试数据说明

事件样例（OrderConfirmed）
- key: orderId = "ORD-202311-0001"
- payload（示例结构，按实际Schema对齐）：
  - orderId: "ORD-202311-0001"
  - userId: "U1001"
  - currency: "EUR"
  - matchedAt: "2025-01-02T10:30:00Z"（用于汇率撮合时点）
  - items: [{sku:"SKU-1", category:"Digital", region:"US", qty:2, unitPrice:20.00},{sku:"SKU-2", category:"Physical", region:"CN", qty:1, unitPrice:100.00}]
  - discount: {type:"percentage", value:10}
  - taxInfo: {invoiceTitle:"ACME Corp", taxNumber:"US-12-3456789"}
  - traceId: 填入或通过traceparent头传递
税率与币种
- 税类：Digital=6%，Physical=13%（示例）
- 币种：USD、EUR、CNY；mock汇率示例：EUR→USD=1.10，CNY→USD=0.14（测试中固定）
风控
- 风控开关可通过配置或测试API设置（on/off）；指定userId或订单标签命中高风险
数据准备（手动）
- 在账单库初始化税率、币种、发票抬头校验配置
- MinIO创建invoices bucket
- Kafka与Schema Registry创建主题与注册Schema（order.events、order.events.dlq）
- WireMock启动并录入支付网关模拟响应：/payments/transactions?date=... 返回匹配/差异集
- OpenTelemetry Collector/Tempo地址在ConfigMap中配置
清理数据
- 测试完成删除MinIO中的测试对象、回滚Postgres测试表数据、清理DLQ消息、删除临时WireMock stub

执行建议

执行顺序（由快到慢、由内到外）
1. 单元测试（UT-001~UT-007）→快速反馈计算/校验/幂等与模板正确性
2. 集成测试（IT-001~IT-007）→验证与Kafka/MinIO/支付沙箱/OTel的集成
3. 功能测试（FT-001~FT-004）→API与可用性校验
4. 端到端（E2E-001~E2E-005）→覆盖核心业务闭环与验收点
5. 回归（REG-001~REG-003）→问题防回归与可恢复性
CI建议（Argo Workflows）
- 步骤1：构建与镜像推送（order-svc、billing-svc）
- 步骤2：部署到K8s开发命名空间，注入配置与Secret，等待Pod健康
- 步骤3：运行单元与集成测试（可在CI容器中使用Testcontainers启动Kafka/MinIO/Postgres/Schema Registry/WireMock）
- 步骤4：运行功能与端到端测试（指向K8s Service；必要时port-forward）
- 步骤5：收集覆盖率（单元/集成）与可观测性校验（查询Tempo中trace，Prometheus指标校验消费延迟、DLQ计数）
- 步骤6：环境与数据清理
注意事项
- 幂等：确保账单表与幂等表具备唯一约束（order_id、idempotency_key）；回放/重试前先查询状态
- 事件顺序：以key=orderId保证分区有序；并发测试需确保多分区或多消费者组行为受控
- 定时任务：测试中通过手动触发接口或job运行对账（避免等待00:30）
- 时间与汇率：使用mock时钟/固定汇率，避免波动导致断言不稳定
- PDF：对比文件hash或关键字段渲染文本，避免仅比大小
- 可观测：在E2E测试中校验traceId贯穿（生成traceparent→Tempo查询相关span）
覆盖与质量门槛
- 单元覆盖率≥80%（计算/校验/幂等模块≥90%）
- DLQ与补偿路径至少1正1反案例通过
- 关键验收项（重复事件不重复记账、traceId贯穿、对账一致）在E2E必须通过

以上测试套件可直接落地为自动化测试代码结构（modules: unit, integration, functional, e2e, regression），结合Testcontainers与WireMock确保可重复、可维护，并在CI中按阶段递进执行。

解决的问题

将“自动化测试套件生成器”打造为团队的测试加速引擎：用一次清晰的输入（需求、代码结构、用户故事），在几分钟内生成可直接落地的完整测试套件（单元/集成/功能），显著提升测试覆盖率与稳定性，减少人工编写与重复沟通成本，推动敏捷迭代与持续集成高效运行，最终以更低风险、更快交付赢得业务与用户。

适用用户

开发工程师

为新增功能和修复提交快速生成单元与异常场景用例，随手运行，及时发现回归与边界问题，提升改动信心。

测试工程师

根据需求或用户故事一键产出完整用例与数据说明，按优先级执行关键路径与异常流程，显著提升覆盖与交付速度。

QA负责人

获得清晰的测试策略与执行顺序建议，把控版本风险，在紧张迭代中平衡质量与进度，减少漏测与返工。

特征总结

• 一键生成多层级测试套件，覆盖正常与异常流程，快速提升质量保障效率。

• 自动理解代码与需求描述，定位关键风险点，生成针对性测试用例与建议。

• 按优先级与执行顺序组织用例，即拿即跑，迭代发布更可控更从容，减少协调成本。

• 为新功能、重构与回归场景提供模板化方案，轻松补齐测试空白与遗漏风险点。

• 智能设计边界与极端数据，减少人手编写时间，提高覆盖率与问题暴露速度。

• 支持单元、集成、验收等测试组合，一套方案适配不同团队与开发节奏，快速落地。

• 自动生成测试数据与预期结果说明，缩短上手时间，降低沟通与协作成本。

• 提供清晰的环境与执行建议，保障跨环境稳定运行，显著减少试错与返工。

• 输出结构规范、易读易改，可持续迭代更新，长期降低维护与培训成本投入。

• 协同持续集成流程，轻松扩展回归套件，确保每次改动均可快速验证与追踪。

如何使用购买的提示词模板

1. 直接在外部 Chat 应用中使用

将模板生成的提示词复制粘贴到您常用的 Chat 应用（如 ChatGPT、Claude 等），即可直接对话使用，无需额外开发。适合个人快速体验和轻量使用场景。

2. 发布为 API 接口调用

把提示词模板转化为 API，您的程序可任意修改模板参数，通过接口直接调用，轻松实现自动化与批量处理。适合开发者集成与业务系统嵌入。

3. 在 MCP Client 中配置使用

在 MCP client 中配置对应的 server 地址，让您的 AI 应用自动调用提示词模板。适合高级用户和团队协作，让提示词在不同 AI 工具间无缝衔接。

AI 提示词价格

￥30.00元

先用后买，用好了再付款，超安全！

在线免费用提示词

您购买后可以获得什么

✓

获得完整提示词模板

- 共 627 tokens

- 5 个可调节参数

{ 测试需求规格 } { 测试类型 } { 优先级设置 } { 测试环境 } { 数据准备方式 }

✓

获得社区贡献内容的使用权

- 精选社区优质案例，助您快速上手提示词

购买

自动化测试套件生成器

测试套件概述

测试环境要求

测试用例列表

单元测试

集成测试

功能测试（API/业务流程）

端到端测试（Playwright）

并发与一致性（归类为集成/端到端的专项场景）

测试数据说明

执行建议

附：关键用例实现要点（简要）

测试套件概述

测试环境要求

测试用例列表

测试数据说明

执行建议

测试套件概述

测试环境要求

测试用例列表

测试数据说明

执行建议

解决的问题