智能自动化测试方案设计

自动化测试方案

项目概述

• 项目类型分析
  • 客户端：Flutter 主体（iOS/Android 原生壳）、微信小程序；涉及系统级能力（推送、弱网/离线、前后台切换）、多端兼容与数据一致性。
  • 服务端：Node.js（Nest，REST/gRPC）、PostgreSQL；强契约依赖（OpenAPI/Proto）、合规审计与可追溯。
  • 交付节奏：4个月周期，周迭代；团队6人（1TL、2测、2开、1运维），需兼顾效率与长期维护。
• 测试目标说明
  • 接口契约与数据安全：REST/gRPC 契约稳定、向后兼容；敏感字段最小暴露、日志脱敏；错误码一致性。
  • 登录与处方合规流程：实名/资质校验、电子处方流转关键节点的规则校验与审计可追溯。
  • 移动兼容与弱网：主流OS/设备分布覆盖；弱网、断网、切后台/杀进程场景的可靠性。
  • 离线缓存与推送：离线数据一致性、冲突合并策略、消息到达与展示链路可测。
  • 预约流程稳定性与可追溯性：从挂号到取消/改期/退款的端到端稳定性；全链路日志/审计记录可追溯。
• 关键业务场景识别
  • 账户与身份：注册/登录（含短信/一键登录/实名）、登出、设备绑定/解绑。
  • 预约主流程：选择医院/科室/医生/时段→确认就诊人/支付方式→下单→支付结果回传→消息提醒→就诊前提醒→改期/取消/退款。
  • 处方合规：问诊完成→医生开方→药品敏感规则校验→处方签名/留存→用户查看/复核→取药/配送。
  • 通知与消息：就诊提醒、处方状态变更、订单状态变更、系统公告（含深链/点击唤起）。
  • 离线与缓存：首页/就诊人/医院目录/历史订单的离线可用；切网/断网/弱网恢复策略。
  • 小程序：授权/登录、预约核心链路的轻端路径一致性。

测试架构设计

• 测试层级规划（单元测试/集成测试/端到端测试）
  • 单元（Unit）
    • Flutter：业务逻辑/状态管理/数据转换/缓存策略的纯逻辑测试；处方规则校验函数。
    • Node（Nest）：控制器/服务/拦截器/验证管道；错误码与异常映射；DAO 层 SQL 构造与边界。
    • 原生桥接（Kotlin/Swift）：与系统能力相关的适配层（推送、网络状态感知、Deep Link）。
  • 组件/模块集成（Service/Module Integration）
    • Flutter 集成测试（不依赖OS能力）：页面跳转、表单校验、离线读写、缓存合并策略。
    • API 集成：服务与PostgreSQL在容器内联跑，校验路由、认证、鉴权、事务一致性；第三方依赖使用虚拟化/桩。
  • 合同/契约（Contract）
    • REST：OpenAPI 校验（接口字段、类型、必填、错误码）；生产者/消费者契约校验。
    • gRPC：proto 演进的向后兼容、字段演化策略、方法存在性；基础行为烟测。
  • 端到端（E2E）
    • 移动App：Appium 驱动跨平台关键路径（登录、预约下单/支付回执、取消/改期、处方查看、推送到达/点击唤起、弱网/断网、前后台切换、升级后回归）。
    • 小程序：官方 miniprogram-automator 覆盖核心预约链路与登录。
    • 全链路可追溯：下单至DB/审计表/日志链路校验（以接口与数据库查询为证据，不涉及生产数据）。
• 测试用例组织结构
  • 分层目录 + 领域聚合：
    • unit/（flutter|server|native）/领域（account、booking、prescription、notify、cache）
    • integration/(api|flutter)/模块（booking-service、payment-adapter、audit-log）
    • contract/(rest-openapi|grpc-proto)/场景（happy-path、error-codes、backward-compat）
    • e2e/(app|miniprogram)/业务流（login、booking_core、prescription、notify、offline）
  • 标签与追溯：
    • 按业务域、优先级（P0/P1/P2）、风险（合规/高价值/回归）、平台（iOS/Android/MP）打标，Allure 中建立需求-用例-缺陷映射。
• 测试数据管理策略
  • 环境隔离：dev/staging 独立DB与对象存储；CI 使用docker-compose 启动PostgreSQL并执行迁移与种子数据。
  • 合成数据：严禁生产数据；基于种子脚本构造就诊人、医生、号源、处方样例；提供时间旅行参数（模拟可预约窗口）。
  • 敏感数据防护：日志与Allure附件统一脱敏（手机号/身份证/处方编号），仅保留哈希或掩码。
  • 可重复执行：用例前后置重置号源与库存；订单与处方状态以幂等ID+清理任务保证重跑。
  • 外部依赖虚拟化：REST 使用 WireMock；gRPC 使用生成桩服务或进程内假实现；支付/短信/推送使用沙箱与限流账户。
  • 推送测试数据：维护测试设备池与token清单；iOS 使用测试证书/描述文件，Android 使用FCM测试项目；CI 走模拟注入路径，夜间在真机农场校验真实推送。

框架选型建议

• 推荐框架组合及选型理由
  • 移动E2E：Appium
    • 理由：跨iOS/Android、生态成熟、支持系统级操作（通知、前后台、权限弹框）、适配Flutter壳。
  • Flutter 集成/组件：Flutter integration_test + flutter_test
    • 理由：官方维护，适合无系统依赖的页面/状态流验证，执行快且稳定。
  • 小程序E2E：miniprogram-automator（微信官方）
    • 理由：官方支持、适合核心流程回归，稳定性优于通用UI驱动在小程序场景的兼容。
  • 服务端单元/集成：Jest（Nest 官方推荐实践）+ Supertest（REST集成）
    • 理由：与Node/Nest生态贴合，学习成本低，断言与mock能力充足。
  • 契约/规范
    • REST：OpenAPI（生成与校验）+ Spectral（规范校验）+ Dredd（契约执行）
    • gRPC：Buf（lint/ breaking change 检查）+ grpcurl（烟测）
    • 理由：广泛应用、自动化易集成、对向后兼容与变更检测友好。
  • 服务虚拟化：WireMock（REST）
    • 理由：稳定、可维护性强，易于在CI与本地复用。
  • 报告与可视化：Allure
    • 理由：团队已有，支持分层报告、附件（截图/视频/日志）与趋势跟踪。
  • 设备与网络模拟：Android Emulator 网络限制配置、iOS Network Link Conditioner；Linux CI 上使用 tc/netem 模拟 API 弱网。
• 框架集成方案
  • 代码仓库
    • mono-repo 或多仓均可；建议测试与被测代码同库分层，契约与API测试可独立包以便复用。
  • CI（GitLab CI）流水线阶段
    • lint+unit（并行：flutter/node/native）
    • contract（OpenAPI/Spectral/Dredd、Buf breaking）
    • api-integration（docker-compose: api+db+wiremock）
    • mobile-e2e-smoke（模拟器快速冒烟，关键路径1-2条）
    • nightly-e2e-full（真机/云端设备矩阵、弱网/离线/推送）
    • 报告汇总（Allure上传，趋势看板）
  • 构件与工件
    • 产出 Allure 结果、屏幕录像、App 构建包（Debug/测试证书）、Mock 录制文件、契约校验报告。
• 团队学习成本评估
  • Appium：中等（1周上手+1周稳定性优化）
  • Flutter integration_test：低（1-3天）
  • Jest/Supertest：低（1-3天）
  • OpenAPI/Spectral/Dredd：低-中（3-5天）
  • Buf/grpcurl：低-中（3-5天）
  • WireMock：低（1-3天）
  • 总体：2-3周可形成稳定产线与首批用例。

实施计划

• 测试覆盖范围规划
  • Unit（目标覆盖率：核心模块>80%）
    • Flutter：预约规则、处方规则、缓存合并、日期/时段计算、错误码映射。
    • Node：鉴权/权限、业务规则服务、审计记录写入、数据库仓储边界。
    • Native：推送处理、网络状态感知、深链路由。
  • Integration（目标：关键API>60%用例覆盖）
    • 用户/登录、预约（查余量/下单/取消/改期/退款）、处方（创建/签名/查询）、通知（生成/落库）。
  • Contract
    • REST：每次变更触发 Dredd 对主流程端点全量校验；Spectral 保障规范一致性。
    • gRPC：每次proto变更跑 Buf breaking；grpcurl 对核心方法冒烟。
  • E2E（目标：覆盖所有P0/P1关键路径；用例数控制在20-30条）
    • P0：登录、预约下单（含支付回执模拟）、取消、处方查看与合规校验点、推送到达与点击唤起、断网下查看历史订单、弱网下提交预约重试、前后台切换保持状态。
    • P1：改期、就诊提醒、App升级后回归、设备更换与登录态迁移。
    • 小程序：登录、预约下单/取消、处方查看（P0）。
• 实施优先级排序
  1. 契约与API冒烟基线（OpenAPI/Spectral/Dredd、Buf、Jest+Supertest）
  2. Flutter unit/integration 覆盖预约与处方规则
  3. Appium 核心P0链路（登录、预约下单、取消、处方查看、前后台）
  4. 弱网/离线 场景与数据一致性
  5. 推送链路：模拟注入→夜间真机校验
  6. 小程序E2E核心链路
  7. 长尾P1/P2与兼容矩阵扩展
• 风险评估与应对措施
  • E2E易脆弱：采用稳定定位（测试ID）、显式等待、重试封装与失败录屏；引入“隔离重跑+Flaky隔离清单”制度。
  • 设备碎片化：建立最小兼容矩阵（iOS 16/17，Android 11/13/14；2-3款主流机型），其余走夜间或周回归。
  • 推送在模拟器不可验证：CI 使用模拟注入，真机农场夜间执行；非确定性失败自动重试一次。
  • 测试数据漂移：用例前置校验与种子重置；订单幂等ID；每日清理任务。
  • 契约双向变更风险：将契约校验作为合并门禁；REST 用 Dredd、gRPC 用 Buf breaking 必须绿灯。
  • 弱网不稳定：网络配置走预设档案（延迟、丢包、带宽），固定档案+基准脚本，减少偶发性。

可维护性指导

• 测试代码组织规范
  • 分层与抽象：页面对象/屏幕对象（Appium）、领域DSL（预约/处方步骤封装）、服务适配器（API/Mock层）。
  • 可复用能力：统一登录/清缓存/切网络/前后台操作的工具层；测试数据构造器（就诊人/号源/处方模板）。
  • 稳定性策略：统一等待策略、测试ID标注准则（元素必须有稳定resource-id/testTag）；禁止通过文本模糊匹配关键动作。
  • 命名与标注：用例以“业务-场景-预期”命名；标签包含平台/优先级/风险；Allure 增加附件（网络配置、截图、日志切片）。
• 持续集成集成建议
  • 门禁策略：PR 必须通过 unit+contract+api-integration+smoke-e2e；全量E2E 夜间/每日定时。
  • 并行化：按平台/场景切分E2E；API集成按模块并行；缓存依赖容器镜像加速。
  • 失败治理：构建失败自动采集装置信息、网络档案与重试一次；Flaky 标记后进入隔离队列并安排修复。
  • 报告与可视化：Allure 历史趋势、失败聚类、稳定性看板（通过率、平均时长、波动）。
• 长期维护策略
  • 契约先行：REST/OpenAPI 与 Proto 改动走设计评审与自动化校验；禁止“先改后补”。
  • 覆盖度与规模控制：单元/集成为主，E2E 只保留高价值路径；定期梳理冗余/重叠用例。
  • 测试数据基线：每次架构变更更新种子与数据字典；新增业务建立可构造模板。
  • 设备矩阵滚动：季度评估市场份额调整主覆盖设备；淘汰低占比版本。
  • 知识与规范：沉淀测试指南（定位、等待、数据、网络、推送），新成员1周内可独立编写稳定用例。
  • 审计与追溯：关键业务E2E用例必须校验审计记录落库与关键字段完整性，保证合规可证据化。

附：阶段性里程碑（建议）

• 第1月：CI流水线与契约校验上线；API集成覆盖预约/处方/通知主链路；Flutter单元/集成基线；Appium 冒烟2条。
• 第2月：Appium P0 全覆盖；弱网/离线基础；小程序E2E核心链路；Allure 报告完善与趋势看板。
• 第3月：推送真机夜间稳定；gRPC/REST 契约门禁全面生效；兼容矩阵最小集合跑通；Flaky治理与重试机制完善。
• 第4月：回归集固化（P0/P1）；用例精简与冗余清理；文档/规范与交接材料完善。

预期效果

• 合同变更零意外：契约门禁阻断不兼容发布。
• 关键业务“红线”稳定：预约/处方/通知 P0 用例在每日/每周回归稳定通过。
• 端到端可追溯：每次构建可提供从动作到审计记录的闭环证据。
• 总体成本可控：单元/集成为主，E2E 精准覆盖，4个月内形成可持续的测试体系。

自动化测试方案

项目概述

• 项目类型分析
  • 多租户SaaS后台管理，微服务架构，Go + gRPC 内部通信，Kafka 异步消息，PostgreSQL 存储，K8s + Istio 部署，ArgoCD 持续交付。
  • 核心质量风险：接口契约变更导致级联故障、租户隔离/权限错误、消息一致性与幂等、服务降级/重试正确性、发布回滚与金丝雀验证的可靠性、容器化环境及测试环境可复现性。
• 测试目标说明
  • 优先保障契约稳定性与向后兼容；确保租户隔离与权限策略行为符合设计；验证服务在失败场景下的降级、重试和超时策略；验证消息处理的至少一次投递与幂等处理；将金丝雀发布与自动回滚纳入测试与交付流水线的门禁；保证本地、CI、测试环境的可重复部署与结果一致性。
• 关键业务场景识别
  • 多租户：租户创建/生命周期、跨租户隔离、租户管理员与普通用户权限、审计轨迹。
  • 权限/RBAC：角色分配、特权操作（如用户禁用、配置变更）受控。
  • 配置与异步流程：配置变更事件通过Kafka广播并由不同服务消费，确保消息一致性与幂等。
  • 管理后台关键流程：登录/会话、列表/检索/导出、跨服务聚合查询。
  • 运维流程：灰度（金丝雀）发布、快速回滚、配置下发（Istio流量规则）、服务降级策略。

测试架构设计

• 测试层级规划（单元测试/集成测试/端到端测试）
  • 单元测试（目标覆盖率：核心包≥80%）
    • 业务逻辑、校验器、RBAC判定、租户上下文传播（中间件）、幂等键计算、重试/退避策略函数级验证。
  • 契约测试（优先级最高）
    • gRPC 同步契约：基于 Pact（pact-go + Protobuf 插件）进行消费者驱动契约；配合 buf 的 breaking change 检查保障IDL向后兼容。
    • Kafka 消息契约：使用 Pact 消息契约定义事件负载与元数据（header、schema版本）。
  • 服务级集成测试（Testcontainers）
    • 以容器化依赖（PostgreSQL、Kafka）为基座，启动被测服务的二进制，验证数据层/RLS、事务外加 Outbox/Relay、消息发布与消费链路、gRPC 客户端重试与超时行为。
  • 端到端测试（E2E）
    • Cypress 覆盖关键管理员流程与多租户切换路径（轻量化冒烟+关键路径，不追求广覆盖）；在K8s测试环境上执行，校验真实入口（网关/Ingress/Istio）。
  • 发布后验证（金丝雀/回滚）
    • 在Rollout阶段执行冒烟与合约验证门禁；若不通过自动回滚。
  • 分层比例建议（MVP阶段）：单元50% / 契约25% / 集成20% / E2E 5%（契约优先策略，缩短回归时间，降低端到端脆弱性）。
• 测试用例组织结构
  • 每服务仓库（单体或mono-repo内独立模块）建议目录
    • /api：protobuf 定义 + buf 配置 + breaking check
    • /internal/...：业务代码与单元测试
    • /contracts/grpc：Pact 消费者契约；/contracts/messages：Kafka 消息契约
    • /integration：Testcontainers 场景（DB、Kafka、服务进程）
    • /e2e-smoke：跨服务冒烟（仅必要）
    • /testdata：租户/用户/权限/消息样例工厂与固定夹具
  • 用例命名与标签
    • 按领域与租户/权限维度打标签（tenant, rbac, degrade, msg, rollback）
    • CI中按标签选择性执行（快、慢、变更影响范围）。
• 测试数据管理策略
  • 多租户数据
    • 测试运行生成唯一tenant_id（基于时间戳/UUID），全链路透传（gRPC metadata、DB 列 tenant_id、Kafka header）。
    • Postgres 启用RLS（Row Level Security）策略，集成测试中验证不同角色/tenant_id下查询/变更限制。
  • 种子与工厂
    • 基于迁移工具预置基础结构；使用工厂方法生成租户、用户、角色、策略与初始业务数据，避免共享状态。
  • 消息与主题
    • 每次测试创建临时主题或使用带测试前缀和保留期极短的主题；消息携带幂等键与租户标识；测试结束清理。
  • 幂等与一致性
    • 验证Outbox表写入->Relay发布->消费者处理的端到端效果；断电/重启场景下重复投递不产生副作用（以幂等键/去重表验证）。
  • 环境可复现
    • 本地/CI统一通过 Testcontainers 拉起依赖；K8s层面使用Kind生成临时集群用于E2E/金丝雀演练；固定镜像版本与Kustomize/Helm values。

框架选型建议

• 推荐框架组合及选型理由
  • 单元测试：Go testing + Testify
    • 轻量、学习成本低、生态成熟，满足断言与模拟需求。
  • 契约测试：Pact（pact-go + Protobuf 插件）+ Pact Broker
    • 满足消费者驱动合约与跨仓库验证；gRPC与消息契约统一管理；Broker用于版本比对与回归验证。
  • IDL与兼容性：buf
    • 自动进行 protobuf 模式的 lint 与 breaking change 检查，降低契约破坏风险。
  • 集成测试：Testcontainers for Go
    • 稳定、可复现地拉起 PostgreSQL、Kafka 等依赖，适合CI。
  • E2E：Cypress
    • Web 管理后台主流选择，支持网络拦截、数据前置与可视化报告。
  • 发布与金丝雀：ArgoCD + Istio（配合 Argo Rollouts）
    • 标准的GitOps与渐进式交付方案；可注入故障、流量分割与回滚自动化。
• 框架集成方案
  • CI 阶段
    • 代码扫描与buf breaking check -> 单元测试 -> 消费者契约生成并发布到Broker -> 生成镜像并推送 -> Provider 在PR或合并分支触发对最新契约的验证（使用 Testcontainers 拉起依赖服务或在Kind中起服务进行验证）。
  • CD 阶段
    • ArgoCD 同步到测试环境 -> Argo Rollouts 创建金丝雀（如 10%/30%/100%）-> 在每个步骤触发分析任务（合约回放、Cypress 冒烟、健康探针）-> 失败自动回滚。
  • 故障注入
    • 使用Istio VirtualService 注入延迟/错误率来验证重试/超时/降级；测试结束移除规则。
• 团队学习成本评估
  • Testify、Go testing：极低（<0.5周）
  • Pact（含Broker与Protobuf插件）：中等（1-1.5周含样例落地与流水线集成）
  • buf：低（0.5周）
  • Testcontainers：低-中（0.5-1周，涵盖Kafka/PG模块与CI权限）
  • Cypress：低（0.5周，冒烟级用例）
  • ArgoCD + Rollouts + Istio门禁：中（1周，含分析模板与回滚策略）

实施计划

• 测试覆盖范围规划
  • 契约测试
    • gRPC：所有对外与跨服务接口均需消费者契约；覆盖成功/校验失败/鉴权失败/边界分页等。
    • Kafka：所有领域事件与命令消息均建立消息契约（payload schema、必填字段与版本）。
  • 租户隔离与权限
    • DB层RLS规则：正/反向场景（跨租户访问被拒、同租户不同角色受限）。
    • API层鉴权与上下文：gRPC metadata中tenant_id与角色校验；Cypress验证UI层受控展示与禁止操作。
  • 服务降级与重试
    • 在目标下游注入超时/5xx/限流，验证重试次数、退避、超时与降级回退值。
  • 消息一致性
    • Outbox->Kafka->消费者端到端：模拟消费者异常/重复消费/重启，验证幂等与补偿。
  • 发布回滚与金丝雀
    • 金丝雀阶段的冒烟用例（登录、核心列表、关键按钮操作）与契约回放通过方可晋级，否则自动回滚。
  • 容器化可重复
    • 本地/CI/测试环境脚本一键启动（Testcontainers/Kind），结果一致性比对。
• 实施优先级排序（按8周MVP）
  • 第1-2周：基础设施与守门
    • buf + protobuf 规范与breaking check；Pact Broker 部署与契约模板；Testcontainers 基座（PG/Kafka）；基础单元测试框架；CI骨架（并发缓存、依赖缓存）。
  • 第3-4周：契约优先与集成
    • 主要gRPC接口与消息流建立消费者契约并接入Provider验证；核心服务的集成测试（RLS、Outbox）；初步Cypress冒烟。
  • 第5-6周：弹性与一致性
    • Istio 故障注入场景测试（重试/超时/降级）；消息幂等/重复消费/重启恢复用例。
  • 第7周：金丝雀与回滚门禁
    • Argo Rollouts 分析模板（契约回放+冒烟）；自动回滚策略验证；灰度演练。
  • 第8周：收尾与覆盖补强
    • 缺口用例补齐、稳定性修复、文档与准入门槛（merge gate）固化。
• 风险评估与应对措施
  • gRPC 契约测试复杂度（Pact+Protobuf插件）
    • 应对：同时启用 buf breaking check；从最关键接口先行；提供参考契约样例与Provider状态机模板。
  • Testcontainers 在CI的权限与性能
    • 应对：使用基于Docker的CI运行器；缓存镜像层与Testcontainers复用；必要时为Kafka使用精简镜像。
  • Cypress 端到端的脆弱性
    • 应对：仅保留冒烟与关键路径；使用稳定的测试ID；网络拦截减少跨服务不确定性。
  • Istio 故障注入影响共享环境
    • 应对：为测试创建独立命名空间与选择器标签，测试结束自动清理。

可维护性指导

• 测试代码组织规范
  • 单元测试紧邻被测包；契约与集成测试独立目录；命名以行为与约束为中心（When_Then模式）；严格区分快速/慢速用例并打标签以便选择性运行。
  • 测试固件与工厂集中在/testdata，避免跨用例共享可变状态；幂等键与时间相关逻辑以可注入时钟实现。
• 持续集成集成建议
  • PR流水线顺序：lint+buf breaking -> 单元测试 -> 消费者契约生成/发布 -> Provider契约验证（若为服务仓库）-> 构建镜像 -> 集成测试（Testcontainers）-> 报告与门禁。
  • 主干合并后：打包镜像 -> 推送 -> ArgoCD 同步到测试环境 -> Argo Rollouts 金丝雀 + 分析模板（Pact回放、Cypress冒烟、健康检查）-> 自动晋级或回滚。
  • 可观测性辅助：在测试阶段采集关键指标（错误率、重试计数、超时次数、重复消费计数）用于断言和分析（不展开性能专项）。
• 长期维护策略
  • 合约基线管理：Pact Broker中保留最新N个版本；服务端需兼容至少两个相邻小版本；合约破坏必须伴随协商与版本标记。
  • DB迁移遵循expand/contract：先扩展后迁移流量，再清理旧字段；在金丝雀阶段验证新旧并存。
  • 用例健康度治理：每周统计失败用例与重跑率，超过阈值需修复或下沉至更低层（避免将系统性问题放在E2E）。
  • 测试资产复用：统一的租户/用户/角色工厂与消息样例库；跨服务共享IDL与契约校验工具链（buf与Pact脚手架）。
  • 文档与培训：沉淀“契约签订流程”“RLS规则测试清单”“故障注入操作手册”，新成员1-2天可上手。

本方案以契约为主线、以容器化可复现为支撑，围绕多租户隔离、权限控制、消息一致性与弹性策略，建立从开发到发布的自动化质量闭环，适配5人团队在8周MVP内逐步落地并可持续演进。