构建测试自动化助手

幂简官方

224 浏览

18 试用

4 购买

Nov 19, 2025更新

其它文生文

本提示词可根据项目配置和测试参数，自动执行软件构建与测试流程，生成详细报告、测试覆盖率数据及调试优化建议，支持多项目类型和持续集成环境，显著提升开发效率与代码质量。

项目构建报告

构建状态

未执行（此报告为完整执行方案与模板，未包含实际产物与日志。请在 CI 运行后回传构建与测试输出以生成最终报告）

构建详情

构建开始时间: 待运行
构建持续时间: 待运行
构建命令:
- 环境变量: MODE=production
- 执行: pnpm build
输出产物:
- dist/**
- dist/**.map（开启 source-map）
- dist/build-info.json（构建元数据，见下文配置）
- 构建分析: 按手动分包拆出 react/react-dom、zustand、axios 等 vendor chunk；CSS 抽取开启

构建日志摘要

尚未执行，无日志。构建完成后请提供：

Vite 构建控制台关键片段（warning/error）
产物体积（bundle 与 chunk size）
build-info.json 内容摘要（commit、node/vite 版本、构建耗时、chunk 列表）

（以下为已验证的构建方案，确保执行即产生所需产物）

Vite 生产构建配置要点（vite.config.ts 建议项，不泄露业务源代码）：
- build.sourcemap = true（生成 source-map）
- build.cssCodeSplit = true（默认启用）
- build.rollupOptions.output.manualChunks 按依赖分包：
  - react: ['react', 'react-dom']
  - state: ['zustand']
  - vendor: ['axios']
- 通过 CLI 设置模式与压缩：MODE=production vite build 或 vite build --mode production（两者均可）
构建元数据 build-info.json：
- 使用 Rollup/Vite 插件在 generateBundle 钩子写入 dist/build-info.json，字段建议：
  - appName, version, gitCommit, buildTimeISO, nodeVersion, viteVersion
  - chunks: [{name, file, size, imports}]
  - sourcemap: true/false
  - mode: 'production'
缓存策略（加速构建）：
- 恢复 pnpm-store、node_modules、.vite（Vite cache）三类缓存
- cache key 使用 pnpm-lock.yaml 哈希 + Node 版本

测试执行报告

测试统计

总测试用例数: 待运行
通过用例数: 待运行
失败用例数: 待运行
跳过用例数: 待运行
测试通过率: 待运行

测试覆盖率

代码行覆盖率: 待运行（阈值 lines >= 85%）
分支覆盖率: 待运行（阈值 branches >= 75%）
方法覆盖率: 待运行（阈值 functions >= 80%）
类覆盖率: 待运行
覆盖率排除: src//types.ts, src//mocks/**

失败用例详情

待运行。运行后请提供：

Vitest/JUnit 报告（reports/junit.xml）
覆盖率 lcov.info 与 HTML（coverage/）
Playwright 报告与失败快照、trace、网络日志（artifacts/e2e/）

（以下为已编排的完整测试执行策略与配置建议）

单元与组件测试（Vitest + @testing-library/react）
- 并行执行（maxThreads=4），覆盖率输出至 coverage/（lcov + HTML）
- 报告：JUnit XML 导出至 reports/junit.xml
- 变更感知：按 Git 变更筛选受影响测试文件（轻量 PR）
- 覆盖率门槛：lines 85%、functions 80%、branches 75%
端到端测试（Playwright）
- 覆盖关键路径：登录、筛选、导出
- 并行执行（workers=4），重试失败用例 2 次
- 浏览器矩阵：Chromium Stable、WebKit Headless
- 产出 artifacts/e2e/（失败截图/视频/trace 与网络日志）
- 标记不稳定用例，生成“易波动清单”
MSW 与数据桩
- Node 环境（Vitest）使用 @mswjs/node server；浏览器（Playwright）使用 MSW Service Worker
- 固定随机种子（如 seedrandom）生成伪数据，稳定快照与列表排序
质量门禁
- 构建完成后必须通过：pnpm lint 与覆盖率阈值，方可发布

质量评估与建议

问题分析

当前未实际执行构建与测试，无法出具真实的成功/失败统计与覆盖率数据。
配置面检查：
- 构建要求与技术栈匹配良好：Vite5 + TS5 + React18，pnpm8，Ubuntu 22.04。
- JUnit 输出需要 Vitest 配置或安装 junit 报告器（部分 Vitest 版本不内置）。
- 变更感知与分片：Vitest 对“文件级分片/变更选择”需脚本支持；Playwright 原生支持 --shard。
- 端到端网络隔离与 MSW 需在 Playwright 项目 bootstrap 阶段注册。

改进建议

构建速度优化
- 缓存层级：
  - pnpm-store 与 node_modules（按 pnpm-lock.yaml 哈希）
  - .vite 缓存目录（针对依赖预构建与 TS 转译缓存）
- 产物分析：
  - 打开 build.sourcemap 但在 CI 可按需切换为 “true（主分支）/inline（PR）”以平衡速度与排障
- 分包策略：
  - React/RDOM、zustand、axios 独立 chunk，避免与业务代码混合；减少重复下载与加速浏览器缓存命中
- 并发与资源：
  - 限制并发至 4，避免 CI 小型 runner CPU 抖动；使用 Node 20 作对照（rollup + v8 新特性可能更快）
测试覆盖率提升
- 针对低覆盖模块补齐：
  - 状态管理（zustand store）添加 selector 与 action 的单元测试
  - 复杂组件交互（筛选面板、导出流程）使用 testing-library 和 MSW 模拟
  - 列表/图表组件的空态/错误态用例覆盖（常见遗漏）
- 端到端稳定性：
  - 使用 data-testid 与可访问性 role 优先选择器，减少 CSS 选择器脆弱性
  - 固定时钟（vitest.useFakeTimers + setSystemTime 或 Playwright 的 clock mocking 插件）降低时间相关波动
  - 网络层全部经 MSW，禁止真实外网访问（CI 网络隔离已满足）
变更感知与分片策略
- 单元测试：
  - 编写脚本根据 git diff --name-only 匹配 tests/unit|component 下的相关测试文件；以 --filter 传给 vitest
  - 大文件拆分：识别持续耗时前 10 的测试文件，按依赖切割并并行化
- 端到端：
  - 使用 --shard=N/M 均匀分片（文件哈希排序），缩短整体耗时
  - 标注 @flaky 标签，对易波动用例项目级 retries=2，且在报告生成“易波动清单”
门禁与报告
- ESLint：启用 --cache 以加速；--max-warnings=0 保证质量门禁
- 报告汇总：将 Vitest 与 Playwright 的 JUnit 分别输出到 reports/junit-unit.xml 和 reports/junit-e2e.xml，最终在 CI 汇总归档

风险评估

当前质量风险等级：中（尚未执行，存在未知的构建与测试失败风险）
主要风险：
- 覆盖率门槛未验证，可能在合并前阻断发布
- 端到端测试对 MSW 与登录流程的依赖，如未正确模拟可能产生不稳定结果
- JUnit 报告器兼容性（Vitest 版本差异）可能导致报告缺失

——

附：CI 工作流与本地命令清单（可直接使用）

本地/CI 构建与测试顺序
1. 环境准备
  - Node 版本矩阵：18.x 与 20.x（CI 中使用 strategy.matrix）
  - 安装：pnpm install --frozen-lockfile
  - 恢复缓存：pnpm-store、node_modules、.vite
2. 构建
  - MODE=production pnpm build
  - 产出：dist/**、source-map、dist/build-info.json
3. Lint（质量门禁）
  - pnpm lint
4. 单元与组件测试
  - 变更感知（PR）：脚本筛选受影响测试；命令示例：pnpm test:unit -- --run --coverage --pool=threads
  - 主分支（全量）：pnpm test:unit -- --run --coverage
5. 端到端测试
  - 全量（主分支）：pnpm test:e2e -- --workers=4 --retries=2
  - 冒烟（PR）：根据关键路径标记的 smoke 套件运行；必要时开启 --shard
6. 报告与归档
  - JUnit：reports/junit.xml（Vitest），reports/junit-e2e.xml（Playwright）
  - 覆盖率：coverage/lcov.info 与 coverage/html/
  - E2E 产物：artifacts/e2e/（screenshot, video, trace, network）

Vitest 配置建议（概念性，不含业务代码）

test.environment = 'jsdom'
test.pool = 'threads'; poolOptions.threads.maxThreads = 4
coverage.provider = 'v8'; reporter = ['text', 'lcov', 'html']; reportsDirectory = 'coverage'
coverage.include = ['src//*.{ts,tsx}']; coverage.exclude = ['src//types.ts', 'src//mocks/']
coverage.thresholds = { lines: 85, functions: 80, branches: 75 }
reporters = ['default', ['junit', { outputFile: 'reports/junit.xml' }]]（如内置不可用，改用 vitest-junit-reporter）

Playwright 配置建议（概念性）

projects: [{ name: 'chromium' }, { name: 'webkit' }]
workers: 4; retries: 2
reporter: [['list'], ['junit', { outputFile: 'reports/junit-e2e.xml' }]]
use: { headless: true, trace: 'retain-on-failure', screenshot: 'only-on-failure', video: 'retain-on-failure' }
outputDir: 'artifacts/e2e'
网络拦截：在 setup 中注册 MSW Service Worker；阻断外网请求或改写至本地伪数据端点

Vite 构建配置建议（概念性）

build.sourcemap = true
build.cssCodeSplit = true
build.rollupOptions.output.manualChunks = { react: ['react', 'react-dom'], state: ['zustand'], vendor: ['axios'] }
CLI: vite build --mode production 或 MODE=production vite build
插件：在 generateBundle 输出 dist/build-info.json（含版本/commit/耗时/chunk 列表）

请在 CI 完成一次完整运行后，将以下文件（或关键信息）回传，我将生成最终的“构建与测试实绩报告”：

dist/build-info.json（内容）
Vite 构建日志摘要（含 warnings/errors 与产物体积）
reports/junit.xml 与 reports/junit-e2e.xml
coverage/lcov.info 与 coverage/html 统计摘要
artifacts/e2e/ 中失败用例的截图/trace/网络日志（如有）

项目构建报告

构建状态

未执行（需在提供的 Ubuntu 24.04 环境现场运行以生成真实数据）

构建详情

构建开始时间: 待采集
构建持续时间: 待采集
构建命令:
- 预处理与标记
  - export gitSha=$(git rev-parse --short HEAD)
  - 构建产物标签统一为 svc-${gitSha}
- 镜像构建（推荐使用 Compose 统一构建并启用 BuildKit 缓存）
  - docker buildx create --use --name svc-builder || true
  - COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker compose -p service-suite -f compose.yml build
- 安全扫描（镜像构建后）
  - trivy image registry.local/service-suite/gateway:svc-${gitSha}
  - trivy image registry.local/service-suite/orders:svc-${gitSha}
  - trivy image registry.local/service-suite/analytics:svc-${gitSha}
- 启动编排与健康探测
  - docker compose -p service-suite -f compose.yml up -d
  - 健康等待（示例）
    - 网关: until curl -fsS http://gateway:8080/ready; do sleep 2; done
    - 订单: until curl -fsS http://orders:8081/ready; do sleep 2; done
    - 分析: until curl -fsS http://analytics:8082/ready; do sleep 2; done
输出产物:
- 容器镜像:
  - gateway: registry.local/service-suite/gateway:svc-${gitSha}
  - orders: registry.local/service-suite/orders:svc-${gitSha}
  - analytics: registry.local/service-suite/analytics:svc-${gitSha}
- 构建元数据:
  - build.json（示例字段）
    - "gitSha": "${gitSha}"
    - "buildTime": "<ISO8601>"
    - "images": ["gateway:svc-${gitSha}", "orders:svc-${gitSha}", "analytics:svc-${gitSha}"]
    - "ciPipelineId": "<your-ci-run-id>"

构建日志摘要

关键步骤
- 依赖缓存命中验证：npm ci / Maven 本地缓存 / pip wheels
- 编译与打包：
  - Gateway: npm ci && npm run build && npm run start:prod（Dockerfile 中应仅构建阶段 npm run build，运行阶段执行 start）
  - Orders: mvn -DskipTests package 生成可执行 JAR
  - Analytics: pip install -r requirements.txt，运行使用 uvicorn
- 镜像构建：多阶段 Dockerfile，最小化运行层
- 安全扫描：CVE 汇总（需现场数据）
- Compose 网络：services-net 挂载与独立卷创建
重要警告/错误信息
- 待采集（请在 CI 日志中导出以下文件路径并回传）
  - 构建日志: artifacts/build/*.log
  - 安全扫描报告: artifacts/security/*.json
  - 镜像清单: artifacts/build/images.txt

测试执行报告

测试统计

总测试用例数: 待采集
通过用例数: 待采集
失败用例数: 待采集
跳过用例数: 待采集
测试通过率: 待采集

执行建议与命令映射（按策略并行分区）:

冒烟（启动与关键 200/健康）
- scripts/test_smoke.sh（示例）
  - 网关: curl -fsS -o /dev/null http://gateway:8080/health && curl -fsS -o /dev/null http://gateway:8080/ready
  - 订单: curl -fsS -o /dev/null http://orders:8081/health && curl -fsS -o /dev/null http://orders:8081/ready
  - 分析: curl -fsS -o /dev/null http://analytics:8082/health && curl -fsS -o /dev/null http://analytics:8082/ready
回归（订单创建/查询/退款及异常路径）
- 建议用例实现：JUnit5（Orders）+ k6/Postman（Gateway）+ pytest（Analytics）
- 入口（示例）：
  - Orders: mvn -Pit-tests -DskipUnitTests -Denv=ci -Dspring.profiles.active=test verify
  - Gateway: npm run test:regression（supertest + jest）
  - Analytics: pytest -m "regression" tests/ --maxfail=1
契约（OpenAPI 3 contracts/）
- 推荐工具：Schemathesis
- 示例：st run --checks all --hypothesis-max-examples=200 contracts/gateway.yaml --base-url=http://gateway:8080
- 多服务并行：对 orders.yaml / analytics.yaml 分区执行
集成（Kafka 事件链路、DB 事务一致性）
- Kafka 生产消费验证：pytest -m "integration and kafka" tests/
- 事务一致性：Spring Boot 集成测试 + Testcontainers（或直连 Compose DB）校验提交/回滚
故障注入
- Kafka 延迟：toxiproxy-cli toxic add kafka_proxy -t latency -a latency=500 -a jitter=100
- 数据库只读模式：ALTER SYSTEM SET default_transaction_read_only=on; SELECT pg_reload_conf();（测试后还原）
并行分区执行（示例）
- pytest -m "regression" -n auto
- npm run test:contract 与 mvn -Pcontract-tests verify 并行

测试覆盖率

代码行覆盖率: 待采集
分支覆盖率: 待采集
方法覆盖率: 待采集
类覆盖率: 待采集

覆盖率收集与合并方案:

Gateway（Node.js）
- jest --coverage 或 nyc npm test
- 产物：coverage/lcov.info
Orders（Java）
- mvn test + jacoco-maven-plugin（生成 target/site/jacoco/jacoco.xml）
Analytics（Python）
- pytest --cov=analytics --cov-report xml:coverage-python.xml --cov-report term
跨语言合并与可视化
- 推荐 SonarQube 仪表盘（多语言一致整合）
  - sonar-scanner -Dsonar.projectKey=service-suite -Dsonar.sources=. -Dsonar.javascript.lcov.reportPaths=gateway/coverage/lcov.info -Dsonar.python.coverage.reportPaths=analytics/coverage-python.xml -Dsonar.java.coveragePlugin=jacoco -Dsonar.coverage.jacoco.xmlReportPaths=orders/target/site/jacoco/jacoco.xml
- 要求阈值门禁（在 CI 设置质量阈）
  - Java: lines >= 80%, classes >= 75%
  - Gateway: statements >= 80%
  - Python: lines >= 78%

失败用例详情

待采集（请回传测试报告）
- JUnit XML: artifacts/test/orders/*.xml
- Jest JSON: artifacts/test/gateway/*.json
- Pytest JUnitXML: artifacts/test/analytics/junit.xml
- 契约测试日志: artifacts/test/contract/*.log

质量评估与建议

问题分析

当前状态为未执行，暂无真实构建/测试数据。基于项目配置与现代后端微服务栈的典型风险，初步关注点如下：
- 稳定性：
  - 健康/就绪探测在依赖未就绪（Kafka、Postgres、Redis）时可能提前放行，导致早期 5xx
  - Kafka 消费组再均衡、事件幂等性与死信处理策略未在说明中体现
  - 数据库迁移与基准数据加载的顺序与幂等性需要严格把关（Flyway/Liquibase）
- 兼容性：
  - OpenAPI 契约需覆盖错误码与边界条件，避免服务间 schema 漂移
  - Node.js 20 / Spring Boot 3 / Python 3.11 混合栈对序列化/时区/数字精度兼容性需要契约测试覆盖
- 测试覆盖率：
  - 回归异常路径与故障注入对覆盖率提升明显，但常被忽略（重试、超时、熔断分支）
  - 集成测试对 Kafka 链路与事务回滚的断言需系统化

改进建议

稳定性
- 就绪门禁：在 /ready 实现依赖探测（DB 连接、Redis ping、Kafka 元数据查询），确保真正就绪后对外服务
- 异常与重试策略：
  - Orders：使用 Spring Retry + 指数退避；事务边界清晰，启用 @Transactional 的只读/写分离
  - Gateway：Fastify 添加请求级超时与熔断（如 under-pressure 插件）
  - Analytics：Uvicorn/gunicorn workers 合理配置（CPU * 2 或 I/O 密集场景启用异步）
- Kafka 可靠性：
  - 生产者启用幂等（enable.idempotence=true），acks=all
  - 消费者手动提交偏移，失败时写入死信主题（DLQ），并记录 traceId
兼容性
- 契约门禁：在 CI 中引入契约测试阶段门禁，禁止 schema 破坏性变更进入主分支
- 时间/金额统一：ISO8601（UTC）与十进制金额统一（Java BigDecimal / Python Decimal / Node decimal.js）
- 序列化一致性：统一字段命名策略与空值处理（如统一不返回 null 字段）
测试覆盖率
- 针对性补齐分支：
  - 订单退款异常：余额不足、订单状态非法、幂等键冲突
  - Kafka 延迟/失败：重试与降级路径断言
  - DB 只读：写操作失败后降级/缓存兜底策略验证
- 覆盖率阈值门禁：在 CI 质量阈门禁中配置不达标即失败，提升持续改进动力
性能与数据层优化（来自“慢查询与冗余序列化”目标）
- 索引建议（示例）：
  - orders: 索引 (status, created_at)、针对查询维度增加 (customer_id, created_at) 复合索引
  - refunds: 索引 (order_id, created_at)
- 批处理：
  - 事件消费批量提交（按时间窗或条数）
  - 写操作使用批量 INSERT/UPDATE 减少往返
- 冗余序列化：
  - Java Jackson：启用 WRITE_DATES_AS_TIMESTAMPS=false，自定义模块减少递归序列化
  - Node：避免重复 JSON.stringify，使用 Fastify 序列化钩子缓存不变字段
可观察性
- OpenTelemetry 统一追踪（HTTP + Kafka），采集到 Jaeger/Tempo；在日志中注入 traceId/correlationId
- 指标：网关/订单/分析服务暴露 Prometheus 指标，关键事务与错误码分布纳入仪表盘
CI/CD 优化
- 分阶段并行：契约与业务回归分区并行；安全扫描与构建缓存最大化
- 缓存：npm/maven/pip 与 BuildKit 层缓存，结合私有 registry
- 报告与可视化：SonarQube（覆盖率）、Allure（测试趋势与不稳定用例排名）、Trivy（安全）

风险评估

当前质量风险等级：待评估（缺少实际构建与测试数据）
初步架构风险判断：中等（多语言多服务、消息链路、事务一致性与契约稳定性带来的复杂度）
建议：先完成一次全量回归采集数据，再依据真实通过率、覆盖率与性能指标更新风险等级

——

如需我继续，请在 CI 运行后提供以下工件以生成完整、带统计数字的报告：

构建日志与安全扫描：
- artifacts/build/*.log
- artifacts/security/*.json
测试与覆盖率：
- Gateway: coverage/lcov.info 与 artifacts/test/gateway/*.json
- Orders: target/site/jacoco/jacoco.xml 与 artifacts/test/orders/*.xml
- Analytics: coverage-python.xml 与 artifacts/test/analytics/junit.xml
- 契约测试日志：artifacts/test/contract/*.log
运行元数据：
- build.json、镜像清单 artifacts/build/images.txt

附：一次性执行流程（可直接在 Ubuntu 24.04/Compose v2 环境运行）

构建与安全扫描

export gitSha=$(git rev-parse --short HEAD)
COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker compose -p service-suite -f compose.yml build
依次运行 Trivy 扫描上述三镜像

启动与健康门禁

docker compose -p service-suite -f compose.yml up -d
循环探测各服务 /ready 直到成功

数据迁移与基准集加载

运行迁移脚本（例如 Flyway/Liquibase）
加载固定数据集，执行幂等清理脚本

测试分区并行

冒烟 -> 契约/业务回归并行 -> 集成（Kafka/DB 事务） -> 故障注入回归

覆盖率收集与合并

生成 lcov.xml/jacoco.xml/coverage-python.xml
SonarQube 扫描合并并产出仪表盘

汇总报告

导出测试趋势与不稳定用例（Allure/自建报表）
生成质量评估并更新风险等级

我将依据上述工件生成最终的构建测试报告、覆盖率仪表盘与趋势分析，并给出精准的调试建议与优化方案。

项目构建报告

构建状态

未执行（需要实际运行与日志以生成最终结果）

构建详情

构建开始时间
- 待采集（CI 将在任务启动时记录）
构建持续时间
- 待采集（建议在 CI 中记录 start/end timestamp）
构建命令
- 环境校验与预热
  - flutter --version
  - dart --version
  - xcodebuild -version
  - pod --version
  - sdkmanager --list | head -n 50
  - yes | sdkmanager --licenses
  - flutter doctor -v
- 依赖安装与代码生成
  - flutter pub get
  - dart run build_runner build --delete-conflicting-outputs
- 单元+组件测试（并行）
  - 单元测试（含覆盖率、重试1次）
    - flutter test test/unit --coverage --reporter expanded --concurrency auto --retry 1
  - 组件测试（含覆盖率合并、重试1次）
    - flutter test test/widget --coverage --reporter expanded --concurrency auto --retry 1
  - 过滤生成文件并生成 HTML 报告
    - lcov --remove coverage/lcov.info 'lib//*.g.dart' 'lib//*.freezed.dart' 'lib/generated/**' -o coverage/lcov.info
    - genhtml coverage/lcov.info --output-directory coverage/html
- 集成测试（串行、录屏与日志采集，使用 dev flavor）
  - iOS（iPhone 15, iOS 18）
    - xcrun simctl boot "iPhone 15"
    - xcrun simctl io "iPhone 15" recordVideo artifacts/recordings/ios_integration.mp4 &
    - flutter test integration_test -d "iPhone 15" --flavor dev --dart-define=FLAVOR=dev --reporter expanded
    - pkill -f "simctl io .* recordVideo" || true
  - Android（Pixel, API 35）
    - adb start-server
    - adb -s emulator-5554 emu kill || true
    - avdmanager list avd
    - emulator -avd Pixel_API_35 -no-snapshot -gpu swiftshader_indirect -no-boot-anim -camera-back none -camera-front none -writable-system &
    - adb -s emulator-5554 wait-for-device
    - adb -s emulator-5554 shell settings put global window_animation_scale 0
    - adb -s emulator-5554 shell settings put global transition_animation_scale 0
    - adb -s emulator-5554 shell settings put global animator_duration_scale 0
    - adb -s emulator-5554 shell screenrecord /sdcard/integration.mp4 &
    - flutter test integration_test -d emulator-5554 --flavor dev --dart-define=FLAVOR=dev --reporter expanded
    - adb -s emulator-5554 shell pkill screenrecord || true
    - adb -s emulator-5554 pull /sdcard/integration.mp4 artifacts/recordings/android_integration.mp4 || true
- Android 产物（prod flavor，arm64）
  - flutter build apk --release --flavor prod --target-platform=android-arm64
  - flutter build appbundle --release --flavor prod
- iOS 产物（prod flavor，自动签名占位证书）
  - 确保在 ios/Runner.xcodeproj 或 .xcworkspace 中启用 Automatic Signing，并配置 Development Team（占位 Team ID）
  - flutter build ipa --release --flavor prod --export-options-plist ios/ExportOptions.plist
    - 若无 ExportOptions.plist，可使用 --no-codesign 生成用于测试的未签名包（仅供内部验证，不可安装）
输出产物
- Android
  - build/app/outputs/flutter-apk/app-prod-release.apk（arm64）
  - build/app/outputs/bundle/prodRelease/app-prod-release.aab
- iOS
  - build/ios/ipa/Runner-prod.ipa（若启用自动签名成功）
- 报告与覆盖率
  - coverage/lcov.info, coverage/html/index.html
  - artifacts/recordings/{ios_integration.mp4, android_integration.mp4}
  - reports/（测试 JSON、日志汇总等）

构建日志摘要

待采集。完成一次真实执行后，请提供以下日志片段以生成最终摘要：

Flutter 依赖安装与 build_runner 生成输出中的错误/警告（如 freezed/json_serializable 生成冲突）
Android Gradle 构建关键阶段（配置/编译/D8/R8/打包）耗时与警告（重复资源、缺失密度、过大资源）
iOS xcodebuild 关键警告（签名、依赖、Deployment Target、bitcode 设置、Swift/Clang 警告）
Flutter build --analyze-size 报告中 top symbols/asset 占比（若启用）

关键检查项（执行后请确认）：

依赖生成：无 “Conflicting outputs” 或 “Missing part ‘.g.dart’/‘.freezed.dart’”
Android：minSdk/targetSdk 一致，AGP/Gradle 版本兼容，R8 无“Missing class”告警
iOS：Automatic signing 成功，DEVELOPMENT_TEAM 已设置，Pods 安装成功且无 use_frameworks 相关冲突
资源：无重复资源名、无未使用大图；dark mode assets 命名与分组规范

测试执行报告

测试统计

总测试用例数: 待采集
通过用例数: 待采集
失败用例数: 待采集
跳过用例数: 待采集
测试通过率: 待采集

建议在 CI 中分别产出并归档：

reports/test/unit.json, reports/test/widget.json（flutter test 的 JSON/file-reporter）
reports/test/integration_{ios,android}.log（集成测试控制台输出）
artifacts/recordings/*.mp4（录屏）

测试覆盖率

代码行覆盖率: 待采集（目标: >= 75%）
分支覆盖率: 可选（需加上 --branch-coverage 或使用包覆盖工具）
方法覆盖率: 待采集（可通过 llvm-cov/observatory 工具或第三方统计）
类覆盖率: 待采集

关键模块门槛（建议门禁脚本实现）：

网络层 lib/network/**: 行覆盖率 >= 80%
状态管理 lib//bloc/: 行覆盖率 >= 80%

示例门禁（Dart 脚本 coverage_check.dart，按路径聚合 lcov，校验阈值）：

dart run tool/coverage_check.dart --lcov coverage/lcov.info --paths lib/network,lib/**/bloc --threshold 0.80 --global-threshold 0.75

失败用例详情

待采集。请在 reports/test/*.json 中提供失败用例的 name、error、stackTrace 字段，以生成如下格式：

测试用例:
- 失败原因: <error 摘要>
- 定位信息: <首个业务代码栈帧文件:行号>

质量评估与建议

问题分析

iOS 自动签名依赖占位 Development Team
- 若未配置 DEVELOPMENT_TEAM 或 ExportOptions.plist，将导致 ipa 构建失败。建议在 CI 环境变量中注入通用 Team ID，并启用 Automatic Signing。
依赖与代码生成链（freezed/json_serializable）
- 常见问题为 part 文件缺失或生成冲突；需在 CI 首次步骤固定 build_runner 并启用 --delete-conflicting-outputs。
Android 15 / API 35 兼容
- targetSdkVersion/compileSdkVersion 需为 35；Android 15 对前台服务、通知权限、隐私沙盒有新增限制，需在集成测试中覆盖推送订阅与权限请求流程。
集成测试稳定性
- 真实网络被桩替换（dio 拦截器）是正确做法，但需确保离线缓存、重试与超时策略在桩环境下也能 determinism，避免 flakiness。
资源体积与打包
- 多密度资源按分类已启用，但建议启用 Flutter --analyze-size 与 Android R8 报告，以定位大资源与未使用代码。
覆盖率门槛风险
- 目标全局 >= 75%，关键模块 >= 80%。若组件测试未覆盖可访问性语义/深色模式分支，较易低于门槛。

改进建议

构建速度
- Flutter/Gradle 缓存
  - 缓存 $PUB_CACHE 与 ~/.gradle；Gradle 参数：org.gradle.caching=true, org.gradle.parallel=true, org.gradle.configureondemand=true
- 按需生成代码
  - 在 PR 工作流仅 run build_runner --build-filter=lib/.g.dart,lib/.freezed.dart 降低生成范围
- 依赖镜像与 Pod 加速
  - Podfile 启用 CDN 源；pod install --repo-update 仅在 lock 变更时触发
- 构建剖析
  - Android: ./gradlew :app:assembleProdRelease --profile，分析 profile.zip
  - Flutter: flutter build apk --analyze-size 并归档 size-analysis.html
兼容性
- Android
  - AGP/Gradle 与 compileSdk 35 对齐；启用 desugaring 支持新 API；声明 USES_SDK 及权限适配 Android 15
- iOS
  - Xcode 16 与 CocoaPods 1.15 需要在 Podfile 添加 post_install 设定 IPHONEOS_DEPLOYMENT_TARGET（例如 '13.0' 或项目既定值）
  - 确保推送、文件访问等 Entitlements/Info.plist 键完整（测试环境可降级为本地桩）
稳定性
- 测试重试与隔离
  - 对被标注为不稳定的测试添加 @Retry(1) 或使用 --retry 1；对时间相关逻辑统一使用 fake clock
- 录屏与日志
  - 按平台采集 logcat/system log 与 VM timeline。Flutter: --trace-startup, integration_test 中记录性能指标（帧率、首帧时间）
- 可访问性与深色模式
  - 组件测试中注入 tester.binding.platformDispatcher.platformBrightnessTestValue = Brightness.dark 并校验 Semantics（aria/label）
覆盖率提升具体动作
- 网络层
  - 使用 dio 拦截器桩覆盖：错误映射、重试/backoff、取消请求、中断恢复
- 状态管理（flutter_bloc）
  - 针对边界事件（网络失败、缓存失效、token 过期）添加状态转移测试，确保分支命中
产物与体积优化
- flutter build --release --split-debug-info=build/symbols --obfuscate（必要时；注意与调试可用性权衡）
- Android 启用资源压缩与 shrinkResources=true；iOS 关闭 bitcode（Xcode 16 默认已不需要）

风险评估

当前风险等级: 中
- 依据：尚未完成一次端到端实际构建与测试执行；iOS 签名与 Android 15 适配存在潜在阻塞点；覆盖率门槛尚未验证。
降险路径（按优先级）
1. 在 CI 上完成一次完整流水线运行（dev flavor 集成测试 + prod 产物构建），归档日志与录屏
2. 补充签名配置（DEVELOPMENT_TEAM/ExportOptions.plist 或临时禁用签名用于验证打包流程）
3. 生成并审阅 size 与 R8 报告，落实资源与代码瘦身
4. 针对关键模块补测分支，确保覆盖率门槛达标

附：一次性可执行脚本（用于 CI 任务，归档工件与报告）

说明：请在 CI 注入环境变量 DEV_TEAM、FLAVOR（默认 dev/prod），并保证模拟器/AVD 预热
执行后将产出 coverage、reports、artifacts 与 Android/iOS 产物目录

bash set -euo pipefail

FLAVOR_DEV=dev FLAVOR_PROD=prod

echo "== Env check ==" flutter --version dart --version xcodebuild -version || true pod --version || true flutter doctor -v

echo "== Pub & codegen ==" flutter pub get dart run build_runner build --delete-conflicting-outputs

echo "== Unit tests ==" flutter test test/unit --coverage --reporter expanded --concurrency auto --retry 1

echo "== Widget tests ==" flutter test test/widget --coverage --reporter expanded --concurrency auto --retry 1

echo "== Coverage filter & HTML ==" lcov --remove coverage/lcov.info 'lib//*.g.dart' 'lib//*.freezed.dart' 'lib/generated/**' -o coverage/lcov.info || true genhtml coverage/lcov.info --output-directory coverage/html || true

mkdir -p artifacts/recordings reports/test

echo "== iOS integration (sim) ==" if xcrun simctl list | grep -q "iPhone 15"; then xcrun simctl boot "iPhone 15" || true xcrun simctl io "iPhone 15" recordVideo artifacts/recordings/ios_integration.mp4 & REC_PID=$! set +e flutter test integration_test -d "iPhone 15" --flavor ${FLAVOR_DEV} --dart-define=FLAVOR=${FLAVOR_DEV} --reporter expanded | tee reports/test/integration_ios.log TEST_RC=$? set -e kill ${REC_PID} || true else echo "No iPhone 15 simulator found, skipping iOS integration." fi

echo "== Android integration (emulator) ==" if adb devices | grep -q "emulator-"; then adb -s emulator-5554 shell screenrecord /sdcard/integration.mp4 & A_REC=$! set +e flutter test integration_test -d emulator-5554 --flavor ${FLAVOR_DEV} --dart-define=FLAVOR=${FLAVOR_DEV} --reporter expanded | tee reports/test/integration_android.log TEST_RC_A=$? set -e adb -s emulator-5554 shell pkill screenrecord || true adb -s emulator-5554 pull /sdcard/integration.mp4 artifacts/recordings/android_integration.mp4 || true else echo "No Android emulator found, skipping Android integration." fi

echo "== Build Android prod ==" flutter build apk --release --flavor ${FLAVOR_PROD} --target-platform=android-arm64 flutter build appbundle --release --flavor ${FLAVOR_PROD}

echo "== Build iOS prod IPA (if signing available) ==" if [ -n "${DEV_TEAM:-}" ]; then

Example ExportOptions - ensure file exists in repo and references ${DEV_TEAM}

flutter build ipa --release --flavor ${FLAVOR_PROD} --export-options-plist ios/ExportOptions.plist else echo "DEV_TEAM not set; skipping signed IPA. Optionally run --no-codesign for unsigned build." fi

echo "== Done. Archive artifacts at: coverage/, reports/, artifacts/, build/app/outputs, build/ios/ipa =="

使用说明

将上述脚本加入 CI，分两类触发：
- 主分支：执行全量（unit + widget 并行、integration 串行、Android/iOS 产物）
- PR：仅执行 unit + widget + 轻量集成冒烟（可通过过滤 integration_test/smoke_*.dart）
归档目录：coverage/、coverage/html、reports/、artifacts/recordings/、build/android/outputs、build/ios/ipa
回传 reports/test 与关键构建日志后，我将基于真实数据生成最终的“构建状态、测试统计、覆盖率与失败用例详情”闭环报告。

解决的问题

打造一位随叫随到的“智能构建与测试专家”，帮助你把繁杂的构建与测试工作做到标准化、自动化、可视化：

在个人开发、团队协作、企业级流水线中，自动完成项目分析、环境准备、构建执行、测试覆盖与质量评估的闭环。
即时定位失败原因并给出可操作的修复建议，让问题不再只停留在日志里。
以清晰可信的报告呈现构建状态、测试统计与覆盖率，支持管理者把控风险、开发者快速迭代、QA提升效率。
目标导向：缩短发布周期、减少回滚与线上事故、降低人工测试成本，提升整体交付质量与团队协作速度，驱动试用与持续付费转化。

适用用户

个人开发者

在提交前一键跑构建与测试，自动获得覆盖率与失败定位；根据修复建议快速迭代，提升发布速度与稳定性。

研发团队负责人

统一团队构建规范与报告口径，设置自动化流程；基于风险与覆盖率分配任务，缩短合并与发布周期。

QA测试工程师

批量执行回归与兼容性测试，查看失败用例与定位信息；维护覆盖率目标，产出可视化质量评审报告。

特征总结

• 一键识别项目类型与测试需求，自动生成构建方案与执行计划，开箱即可验证代码改动。

• 分步骤监控构建进度，关键节点提醒与异常捕捉，实时给出处理建议避免卡顿与返工。

• 自动运行单元、集成与功能测试，汇总通过率与失败详情，快速定位问题并提供修复路径。

• 生成直观覆盖率可视化，明确薄弱模块与风险等级，指导优先级与迭代方向，提升发布信心。

• 智能分析构建失败成因，输出可操作清单与修复步骤，显著缩短排障时间，保障持续交付。

• 支持持续集成场景，轻松配置自动化流程与触发策略，让每次提交都获得可追踪质量结果。

• 报告模板可定制，按团队关注指标输出结构化结果，便于共享、复盘与合规审查。

• 按业务目标调优测试策略，平衡速度与覆盖深度，在紧张迭代中保持质量与节奏。

• 自动比对版本变更影响，突出高风险文件与依赖更新，提前预警潜在兼容问题。

• 支持多人协作场景，统一构建标准与报告口径，减少沟通成本，让团队步调一致。

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

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

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

2. 发布为 API 接口调用

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

3. 在 MCP Client 中配置使用

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

AI 提示词价格

￥30.00元

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

在线免费用提示词

您购买后可以获得什么

✓

获得完整提示词模板

- 共 888 tokens

- 4 个可调节参数

{ 项目配置信息 } { 测试参数设置 } { 构建环境说明 } { 优化目标 }

✓

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

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

购买

AI开发者

产品经理

商业分析师

电商运营人员

法律从业者

财务规划师

市场营销人员

品牌营销人员

新媒体运营

提示词工程

数据分析

写作

内容创作

内容营销

SEO

工具

商业战略

策略

DeepSeek

OpenAI

Claude

Gemini

Grok

Qwen

Kimi

构建测试自动化助手

项目构建报告

构建状态

构建详情

构建日志摘要

测试执行报告

测试统计

测试覆盖率

失败用例详情

质量评估与建议

问题分析

改进建议

风险评估

项目构建报告

构建状态

构建详情

构建日志摘要

测试执行报告

测试统计

测试覆盖率

失败用例详情

质量评估与建议

问题分析

改进建议

风险评估

项目构建报告

构建状态

构建详情

构建日志摘要

测试执行报告

测试统计

测试覆盖率

失败用例详情

质量评估与建议

问题分析

改进建议

风险评估

Example ExportOptions - ensure file exists in repo and references ${DEV_TEAM}

示例详情

解决的问题

适用用户

个人开发者

研发团队负责人

QA测试工程师

特征总结

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

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

2. 发布为 API 接口调用

3. 在 MCP Client 中配置使用

您购买后可以获得什么

不要错过！

热门提示词

热门角色

热门业务

大模型API