第一步：源头标记 —— Angular 下的声明式测试契约

在 Angular 生态中，标记不能只做“注释”，必须利用 TypeScript Decorators（装饰器） + Angular Metadata 在编译期把测试需求挂载到 NgModule 或组件类的元数据上，便于 Jenkins 扫描。

1. 自定义装饰器（@E2E）实现

我们创建一个工厂装饰器，利用 reflect-metadata 将配置挂载到类的原型上：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// e2e.decorator.ts
import 'reflect-metadata';

export interface E2EConfig {
  priority: 'high' | 'medium' | 'low';
  scenario: string;          // 业务场景，如 'checkout'
  apiPattern?: string;       // 关联API正则，如 '/api/order/*'
  dependsOn?: string[];      // 依赖的其他组件标记
}

export function E2E(config: E2EConfig) {
  return function (target: any) {
    // 关键：将配置写入类的元数据，同时保留到 Angular 的 Injectable 上下文中
    Reflect.defineMetadata('e2e:config', config, target);
    // 挂载一个静态属性，方便运行时直接读取（用于E2E环境下的自我描述）
    target.__E2E_CONFIG__ = config;
  };
}

2. 在业务组件/服务中使用

以订单结算页为例，直接装饰 Component 或核心 Service：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// checkout.component.ts
import { Component } from '@angular/core';
import { E2E } from './e2e.decorator';

@E2E({
  priority: 'high',
  scenario: 'checkout_submit',
  apiPattern: '/api/order/(create|update)',
  dependsOn: ['login', 'cart']
})
@Component({
  selector: 'app-checkout',
  templateUrl: './checkout.component.html'
})
export class CheckoutComponent {
  // 原有业务逻辑...
}

3. 构建时扫描器（Manifest 生成）

Jenkins 触发时，不是直接扫描全部 TS，而是运行一个 Node Script，利用 ts-morph 或 typescript AST 解析器，专门提取带有 __E2E_CONFIG__ 属性的类，并聚合输出 e2e-manifest.json：

1
2
3
4
5
6
7
8
9
10

[
  {
    "file": "src/app/checkout/checkout.component.ts",
    "className": "CheckoutComponent",
    "selector": "app-checkout",
    "priority": "high",
    "apiPattern": "/api/order/(create|update)",
    "route": "/checkout"  // 通过解析 Angular Router 额外获取
  }
]

实现细节：结合 Angular 的 Builder API（@angular-devkit），我们可以把这个扫描器写成一个标准的 ng builder，直接集成进 angular.json 的 architect 中，确保每次生产构建（ng build --prod）都会自动吐出最新的 Manifest。

第二步：规则解析 —— Jenkins 联合 Sonar/AI 网关

Jenkins Pipeline 拿到 Manifest 后，不再硬编码规则，而是动态拉取：

• 告警规则库：存储在 Git 仓库的 /.quality/alerts.yml 中，包含如 response_time_threshold: 300ms。
• PS规则（生产就绪）：通过 AI 网关读取 Swagger/OpenAPI 文档，AI 自动分析哪些字段是 required、哪些枚举有 invalid 状态，自动生成边界规则集（无需人工写断言）。

Jenkins 具体动作：

1
2
3
4
5
6
7
8
9
10
11

stage('Parse & Enrich') {
  steps {
    script {
      // 调用 Node 脚本读取 manifest
      def manifest = readJSON file: 'e2e-manifest.json'
      // 调用 Python AI 服务，补全每个用例的预期断言策略
      def enriched = sh(script: "python3 ai_gateway/enrich.py --manifest ${manifest}", returnStdout: true)
      writeJSON file: 'enriched-tasks.json', json: enriched
    }
  }
}

第三步：AI 生成用例 —— Playwright + LangChain 的具体实现

此处不再是“一句话生成代码”，而是采用 Chain-of-Thought（思维链） 分步生成：

1. 上下文注入：将 enriched-tasks.json、Angular 路由表（Route）、以及组件的 DOM 快照（通过 Puppeteer 无头抓取） 一同传入 GPT-4o。
2. 生成规约：AI 先输出自然语言步骤（如：1. 访问 /checkout 2. 等待 API /api/cart 返回 3. 点击 submit）。
3. 翻译为代码：锁定 @playwright/test，AI 自动生成包含 page.goto 和 page.route 拦截的 .spec.ts 文件。

关键防幻觉机制（自愈循环）：

1
2
3
4
5
6
7
8

for attempt in range(3):
    test_result = run_playwright(headless=True)
    if test_result.passed:
        break
    else:
        # 将 Playwright 的错误日志、截图、Trace 回灌给 AI
        error_feedback = extract_error(test_result)
        ai.rewrite_code(prompt=original_prompt, error=error_feedback)

第四步：验证迭代（波动性检测）

生成的用例要在 沙箱环境 运行，沙箱采用 Docker-Compose + 独立 Test DB。

波动性检测（Flaky Test Detection） 具体做法：

• 将同一批用例乱序执行 5 次（Playwright 的 --shuffle 参数）。
• 如果某用例失败超过 2 次，AI 自动分析是“时序问题”还是“数据脏读”。
• 针对时序问题，AI 不在代码里写死 waitForTimeout，而是自动注入 expect(response).toBeOK() 和 waitForSelector 的智能轮询。

第五步：自动提交 PR 与前端 Review 减负

PR 自动生成：Jenkins 使用 github-api 创建分支，将生成的 .spec.ts 放入 e2e/generated/ 目录。

Review 增效（结合 Angular 特性）：

• AI 生成的 PR 描述中，自动附上 Angular 依赖注入关系图，标明该测试覆盖了哪些 @Injectable() 服务。
• 前端 Review 时，只需检查 AI 置信度标记。若置信度低于 90%，PR 会自动打上 need-human-review 标签；高于 90% 且所有断言为“只读 GET”，则允许自动合并（需配置仓库规则）。

第六步：产线 K8s 运行时回归（零侵入实现）

产线部署在 K8s 集群，我们利用 Istio 流量镜像（Traffic Mirroring） 功能，不修改业务 Pod：

1. 配置 VirtualService：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

   apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: checkout-mirror spec: hosts: - order-service http: - match: - uri: prefix: /api/order/ route: - destination: host: order-service subset: v1 weight: 100 mirror: host: order-service-shadow # 影子容器 subset: v1 mirrorPercent: 100

2. 影子容器（Shadow Pod）：只运行 playwright test 的只读断言集（仅验证 GET 请求的响应体 Schema）。不写 DB、不发 MQ。

3. 告警与 PD 联动：影子容器中 Prometheus SDK 埋点 e2e_assertion_failed_total。当指标异常，AlertManager 调用 Jira API 自动建单，并将 Trace ID（通过 x-request-id 链路追踪）写入缺陷描述。

附：数据飞轮（模型微调反馈）

每一次产线误报或漏报，系统都会自动截取 请求Payload + AI断言代码 + 研发修复后的代码，存入 向量数据库（Milvus）。每周定时任务用这些高质量语料对开源模型（如 Qwen-Coder）进行 LoRA 微调，让下次生成的用例更贴合你们的 Angular 业务风格。

这套方案将 Angular 的“元数据编程”优势发挥到极致，把 Jenkins 从“调度器”升级为“质量大脑”。如果你需要，我可以把第一步的 Angular Schematics 扫描器完整源码和 Jenkins Shared Library 的 Groovy 封装单独抽出来作为开源脚手架提供。需要的话随时告诉我。😊