软件工程
测试应抓住回归问题，而非为提升覆盖率数字而测试
一个测试套件值得拥有，前提是它能让你在周五放心部署。大多数测试套件做不到，原因有二：要么测试的是代码而非行为，导致每次重构都会崩溃，而结账功能损坏时却仍能通过——要么就是不稳定到所有人都会反复重跑直到绿灯。
此方案解决的问题
覆盖率百分比是导致这种情况的根源。追求 80% 覆盖率会产生数百个针对琐碎函数的测试，却对创造收入的四个核心流程一无所用。同时，不稳定的测试套件还会产生危害：它会训练团队忽视红色警示，这比完全没有测试更糟糕。
您将获得的服务
测试创收流程
注册、登录、搜索、加购物车、结账、支付、管理履约。优先覆盖这些流程，其余功能再考虑测试。
在正确层级使用正确测试
逻辑使用单元测试，数据层使用集成测试，仅对真实流程使用端到端测试。端到端测试速度慢且脆弱；若滥用，便是测试套件被废弃的原因。
零容忍不稳定测试
不稳定的测试即缺陷，必须修复或删除，绝不允许通过重试强行通过。使用确定性等待与种子数据，避免任意睡眠。
集成 CI 作为门控
在每次拉取请求时运行，并在失败时阻止合并。运行时间需足够短，避免有人因此跳过测试。
无障碍与跨浏览器检查
关键页面自动化 axe 检查，并实际在 Chrome、Safari 与 Firefox 中运行。仅在 Safari 中出现的布局问题很常见，若只在 Chrome 中测试则无法发现。
可诊断的失败
失败时自动捕获截图、录像与追踪，使红色构建能在两分钟内诊断，而非耗费半天本地复现。
我们的工作方式
找出关键路径
如果某个流程中断一小时，会让您损失金钱或客户，那么这就是测试计划的重点。
评估现有测试
审查现有测试，确认其真实断言。部分测试会保留，部分会删除———个无法有意义失败的测试比没有测试更糟糕。
搭建测试框架
数据预置、固件及可重复运行测试的环境。
自动化关键路径
优先覆盖核心流程的端到端测试。
集成CI门禁
接入CI系统并设置必需检查项，同时保持测试套件运行速度。
移交维护
开发人员按照相同模式编写测试，因为一个仅由外包承包商维护的测试套件，在其离职后将无法继续维护。
您应当期待什么
- 在发布前捕获收入关键流程的回归问题
- 团队信任的测试套件，红色即代表停止发布
- 部署前无需再手动逐步验证
- CI中的失败可直接诊断，无需本地复现
构建于
- Playwright
- Cypress
- Vitest
- Jest
- PHPUnit
- Pest
- Testing Library
- axe-core
- GitHub Actions
- Lighthouse CI
- k6
Mainstream, well-supported technology — chosen so you can hire for it and so another team could take the project over.
QA与软件测试 — your questions
包括那些大多数机构在页面上忽略的成本问题。
为典型Web应用自动化关键流程的费用为£4,500至£12,000，具体取决于流程数量及当前应用的可测试性。若应用缺乏测试接缝，则需先进行部分重构，此部分工作将单独报价而非隐藏成本。
我们不以百分比为目标，因为这是错误的衡量方式——90%的覆盖率但无结账测试，不如40%覆盖率且包含结账测试。目标是确保每条收入关键路径实现端到端覆盖，且每个修复的Bug均附带能捕获该Bug的测试。
新项目使用Playwright：真正的跨浏览器支持（包括Safari）、更好的并行处理能力，且其跟踪视图可显著加快故障诊断。Cypress是优秀的工具，我们会维护现有Cypress测试套件而非强制重写。
可以。有时应用需进行小幅改动以提升可测试性——稳定的选择器、数据注入方式、时间控制钩子等。这些改动值得一做，因为难以测试的代码通常也难以修改。
在重大版本发布前的探索性测试阶段，是的——人工能发现断言无法捕获的可用性问题。但在回归测试阶段，不做——每次发布重复相同的手动检查既昂贵又不可靠，这正是自动化的用武之地。