低代码应用测试与质量

传统应用：
  类型检查 + 编译 + 单测 + Code Review → 多层拦截

低代码应用：
  元数据在运行期解释 → 无编译期检查
  修改成本极低     → 改得频繁，回归风险高
  修改者未必是工程师 → 缺少「改完跑一下」的习惯

结论：低代码不能省测试，反而要把测试自动化程度做得更高

成本对比（同一需求：给订单列表加一个「是否逾期」列）：
  写代码：改 3 个文件 + 类型定义 + 单测 + 评审   ≈ 2 小时
  低代码：加一个计算字段 + 一个列配置           ≈ 5 分钟

改动频率对比：
  代码：每周几次（受评审与发布流程约束）
  低代码：每天几十次（业务自己就改了）

可测的对象：
  数据模型：字段类型、约束、关系、索引
  表单：Schema 结构、校验规则、联动规则
  页面：组件树、绑定、权限
  流程：节点、分支条件、任务分配
  连接器：请求映射、错误处理
  权限：角色、数据行级规则

测试的两种形态：
  静态检查：不运行应用，直接分析元数据（快、覆盖广）
  动态测试：运行应用，模拟用户操作（慢、贴近真实）

function staticCheck(app: AppSchema): Issue[] {
  const issues: Issue[] = [];
  const entities = new Set(app.entities.map((e) => e.name));
  for (const e of app.entities) {
    for (const f of e.fields) {
      if (f.type === 'ref' && !entities.has(f.target)) {
        issues.push({ level: 'error', msg: `${e.name}.${f.name} 引用了不存在的实体` });
      }
    }
  }
  for (const expr of allExpressions(app)) {
    for (const dep of collectDeps(parse(expr))) {
      if (!fieldExists(app, dep)) {
        issues.push({ level: 'error', msg: `表达式引用了不存在的字段 ${dep}` });
      }
    }
  }
  return issues;
}

import { describe, it, expect } from 'vitest';

describe('leave_form schema', () => {
  it('days 为必填且范围在 0.5~30', () => {
    const f = findField(leaveForm, 'days');
    expect(f.required).toBe(true);
    expect(f.rules).toContainEqual({ type: 'range', min: 0.5, max: 30 });
  });

  it('days > 3 时 reason 变必填', () => {
    const errs = validate(leaveForm, { days: 5, reason: '' });
    expect(errs.reason).toBe('请填写请假原因');
  });

  it('days <= 3 时 reason 不校验', () => {
    const errs = validate(leaveForm, { days: 2, reason: '' });
    expect(errs.reason).toBeUndefined();
  });
});

录制：在真实应用上操作一遍，记录「操作 + 断言」
回放：在 CI 里重放，验证结果一致

关键设计：
  1. 选择器要基于「语义标识」而非 DOM 结构
     ❌ div > div:nth-child(3) > input
     ✅ [data-field="days"]
  2. 数据夹具（fixture）要与录制时一致
  3. 网络请求要能被 mock 或指向测试环境

test('提交请假申请', async ({ page }) => {
  await page.goto('/app/leave/new');
  await page.fill('[data-field="days"]', '5');
  await page.fill('[data-field="reason"]', '年假');
  await page.click('[data-action="submit"]');
  await expect(page.locator('[data-status="success"]')).toBeVisible();
});

三种夹具策略：
  A. 固定数据集：每个用例一套 seed 数据，测试前重建
  B. 快照回滚：测试前打快照，测试后回滚
  C. 用例内自建：用例自己创建所需数据并清理

推荐 A + C 组合：
  基础数据用固定夹具（用户、角色、字典、权限）
  业务数据由用例自建（订单、审批单），避免用例互相干扰

两类回归：
  功能回归：行为变了没有（用 E2E 断言）
  视觉回归：样子变了没有（用截图对比）

视觉对比的实践：
  1. 固定视口尺寸与字体（否则像素级差异永远存在）
  2. 屏蔽动态内容（时间、随机数、头像）
  3. 设置容忍阈值（抗锯齿会导致 1~2% 差异）
  4. 差异需人工确认后才能更新基线

要建立的基线：
  1. 首屏渲染时间（页面 Schema 越大越明显）
  2. 表格滚动帧率（虚拟化是否生效）
  3. 表单联动响应（大表单下的输入延迟）
  4. 保存接口 P95 延迟
  5. 并发用户数下的内存增长

容量评估的输入：
  字段数、组件数、数据行数、联动规则数

test('1000 行表格滚动保持 50fps 以上', async () => {
  const metrics = await measureScrollFps('/app/orders', { rows: 1000 });
  expect(metrics.avgFps).toBeGreaterThan(50);
});

权限测试矩阵：
  角色 × 资源 × 操作 × 数据范围

必测项：
  1. 无权限角色看不到入口（UI 层）
  2. 直接调接口被拒（服务端层，UI 隐藏不算数）
  3. 数据行级过滤生效（A 租户看不到 B 租户数据）
  4. 字段级权限生效（敏感字段脱敏）
  5. 越权提权被拒（篡改请求参数提权）

test('租户隔离：A 租户无法读取 B 租户订单', async () => {
  const res = await api.get('/orders/ORDER_OF_TENANT_B', { token: tokenOfTenantA });
  expect(res.status).toBe(404);      // 用 404 而非 403，避免泄露存在性
});

反向用例清单（比正向用例更值得投入）：
  - 未登录访问受保护页面     → 跳登录，不泄露数据
  - 低权限角色调高权限接口   → 403
  - 跨租户 ID 越权读取       → 404
  - 篡改请求体中的 ownerId   → 服务端以会话身份为准，忽略入参
  - 已离职用户的历史 token   → 立即失效

发布前必查：
  □ 数据模型变更是否向后兼容（先加后删，不改类型）
  □ 新增字段是否可空或有默认值
  □ 流程定义是否版本隔离（旧实例不受影响）
  □ 连接器凭据是否已配置到目标环境
  □ 权限规则是否已配置到目标环境
  □ 定时任务 / Webhook 地址是否指向正确环境
  □ 是否有回滚预案（记录可回退的配置版本号）
  □ 关键路径是否有 E2E 用例覆盖

preflight:
  - check: schema_compat
    on_fail: block
  - check: credentials_present
    on_fail: block
  - check: e2e_critical_paths
    on_fail: block
  - check: rollback_version_recorded
    on_fail: warn

灰度验证：
  1. 按用户分桶放量（1% → 10% → 50% → 100%）
  2. 每一档停留观察关键指标
  3. 指标劣化立即回退（配置版本回退，不是重新发布）

线上可观测：
  - 前端错误率与错误堆栈（带应用版本号）
  - 接口成功率与延迟
  - 关键业务动作完成率（提交成功数 / 打开表单数）
  - 元数据加载失败率

关键指标与放量档位（示意）：
  指标                  1% 档     10% 档    50% 档
  前端错误率            < 0.5%    < 0.5%    < 0.5%
  接口 P95 延迟         不劣化    不劣化    不劣化
  业务动作完成率        不下降    不下降    不下降
  元数据加载失败率      0         0         0

CI 流水线（元数据变更触发）：
  1. Schema 静态校验（命名、引用、兼容性）
  2. Schema 层单元测试
  3. 表达式与流程定义的求值测试
  4. 关键路径 E2E（跑在预览环境）
  5. 视觉回归（与基线对比）
  6. 性能基线对比
  7. 生成发布候选版本（打版本号）

门禁策略：
  静态校验失败   → 阻断
  单测失败       → 阻断
  E2E 失败       → 阻断
  视觉差异       → 需人工确认
  性能退化 > 15% → 阻断

stages:
  - static_check
  - unit_test
  - e2e_preview
  - visual_regression
  - perf_baseline
  - publish_candidate

rules:
  - if: schema_changed
    run: static_check
  - if: static_check.passed
    run: [unit_test, e2e_preview]
  - if: e2e_preview.passed
    run: [visual_regression, perf_baseline]