3.2 功能与性能测试

3.2 功能与性能测试

本节摘要：CD 阶段在类生产环境运行端到端（E2E）、性能与安全测试——比 CI 单元测试慢但覆盖更广。本节配置 Cypress 浏览器测试、k6 负载脚本与 OWASP ZAP 基线扫描，作为 staging 晋级 prod 的门禁。

本节导航

阅读完本节，你应当能够：

1. 在 staging 环境运行 Cypress E2E 测试套件
2. 编写 k6 脚本并设定 P95 延迟阈值
3. 将 OWASP ZAP baseline 扫描接入 pipeline
4. 区分功能测试、性能测试、安全测试的触发时机

一、Cypress E2E 在 staging 跑

E2E 模拟用户完整操作路径——登录、下单、支付——在 staging 而非 CI runner 上跑，因需真实后端与数据库。

// cypress/e2e/checkout.cy.js
describe('Checkout', () => {
  it('completes purchase', () => {
    cy.visit('https://staging.shop.example.com')
    cy.get('[data-testid=add-cart]').click()
    cy.get('[data-testid=checkout]').click()
    cy.contains('Order confirmed').should('be.visible')
  })
})
​

GitHub Actions job（staging 部署后触发）：

e2e-staging:
  needs: deploy-staging
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: cypress-io/github-action@v6
      with:
        config: baseUrl=https://staging.shop.example.com
        spec: cypress/e2e/**/*.cy.js
​

二、k6 性能测试门禁

// load-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 50,
  duration: '2m',
  thresholds: {
    http_req_duration: ['p(95)<500'],  // P95 < 500ms
    http_req_failed: ['rate<0.01'],    // 错误率 < 1%
  },
};

export default function () {
  const res = http.get('https://staging.api.example.com/health');
  check(res, { 'status 200': (r) => r.status === 200 });
  sleep(1);
}
​

CI 中运行：

k6 run load-test.js
​

阈值不达标 k6 exit code 非 0，阻断 prod promote。

测试类型对照

三、OWASP ZAP 基线扫描

- name: ZAP Baseline
  uses: zaproxy/action-baseline@v0.12.0
  with:
    target: 'https://staging.shop.example.com'
    rules_file_name: '.zap/rules.tsv'
    fail_action: true
​

fail_action: true 发现 High 漏洞即 fail job。SAST（静态）在 CI；DAST（动态）在 staging 部署后——互补。

Playwright 并行加速

- run: npx playwright test --shard=1/4
- run: npx playwright test --shard=2/4
# matrix 四并行，wall time 降为 1/4
​

⚠️ 常见坑：E2E 依赖生产第三方支付网关——staging 应 mock 或使用 sandbox key，否则 flaky 且污染真实账务。

💡 关键直觉：测试金字塔在 CD 层「变胖」——E2E 数量仍应少，但关键用户路径必须覆盖；用 smoke（5 条）+ regression（50 条）分层。

JMeter 非 GUI 模式

jmeter -n -t checkout.jmx -l results.jtl -e -o report/
​

-n 非 GUI 适合 CI；-e -o 生成 HTML 报告供归档。Gatling 用 Scala DSL，报告更现代，适合 JVM 团队。

性能基线对比

与上次 release tag 对比，而非绝对值——硬件升级后绝对值会变。

四、安全测试与性能基线（SOURCE 3.2 扩展）

SAST 与 DAST 分工

SAST（SonarQube、Semgrep）看源码，不需运行应用——CI 阶段跑。DAST（OWASP ZAP、Burp CI）打运行中的 staging URL——找 XSS、SQLi 等运行时漏洞。二者互补：SAST 拦硬编码密钥，DAST 拦 auth bypass。

性能测试场景设计

k6 scenario 模拟真实负载：

export const options = {
  scenarios: {
    checkout_spike: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 0 },
      ],
    },
  },
};
​

促销峰值模拟——P95 在 100 VU 下仍 < 800ms 才放行 prod。

Selenium 网格与 Playwright

Selenium Grid 分布式跑 E2E——hub + 多 node browser。Playwright 内置 parallel、auto-wait、trace 录像——失败时下载 trace 比看 log 快十倍定位 flaky。

测试数据管理

staging E2E 需隔离测试账号与数据——每 run 用 factory 创建 user，teardown 删除。共用 test@example.com 导致并行 job 互相删数据 flaky。

一节小结

• E2E 在 staging 跑，不在 CI unit stage
• Cypress/Playwright 覆盖关键用户路径
• k6 thresholds 量化性能门禁
• ZAP baseline DAST 补 SAST 盲区
• shard 并行 缩短 E2E wall time
• mock 外部依赖 避免 flaky 与污染
• 基线对比 比绝对阈值更稳

下一节 3.3 多环境配置分离与发布审批。

CD 阶段测试的取舍

CD 阶段的测试与 CI 阶段互补：CI 跑得快但覆盖浅，CD 跑得全但代价高。设计测试集时，先列业务关键路径，把「用户会踩的坑」排进 E2E，其余交给 API 层与单元测试。测试数量要有上限——E2E 超过五十条后维护成本会急剧上升，此时应该优先补 API 层与契约测试，而不是继续堆 E2E。

性能测试则要区分「基准」与「门禁」：基准用于趋势观察，门禁用于阻断发布。门禁阈值必须来自业务 SLA（如支付接口 P95 < 500ms），而不是拍脑袋数字。测试数据管理是 CD 测试最容易翻车的地方——共用账号导致并行 job 互相干扰，应该用工厂模式为每次运行创建独立测试数据并在 teardown 清理。