各阶段的缺陷代价

同一个缺陷,发现时机不同,代价天差地别。这正是把测试当作持续过程、而非交付前一次性服务的理由。

设计阶段

成本×1。 只需在开工前修改需求中的一条即可。

开发阶段

成本×3。 开发人员在代码进入构建之前就完成修复。

测试阶段

成本×10。 任务退回开发人员,流程重新走一遍。

发布之后

成本×30。 需要在常规发布计划之外紧急发布补丁。

被客户发现

成本×100。 除修复成本外,还要加上业务损失与声誉代价。

自动化测试的价值不在第一次运行,而在第二十次。 因此值得自动化的是每次发布都要验证的稳定流程。把每周都在变的功能自动化,等于把预算花在维护测试脚本本身。

我们如何测试

交付的不是一句「问题很多」,而是可复现、带优先级的缺陷清单,开发可以直接照着改。

01

产品梳理

我们研究业务场景、用户群体以及对业务最关键的部分。对所有功能同等力度测试并无意义。

02

测试计划与检查清单

明确测试范围以及涉及的设备与浏览器。测试计划经双方确认,同时也界定了工作量与费用。

03

执行测试与出具报告

每个缺陷都附复现步骤、截图与优先级。缺少这些,报告对开发毫无用处。

04

回归验证

修复之后,我们不仅验证该缺陷,还会检查相邻功能是否受影响。

常见问题

会测,但他们验证的是「按设计走通」。专职测试验证的是另一件事:如果不按设计走会怎样。这是两种角色,由同一个人兼任效果很差,因为看久了就会视而不见。

可以,这是验收承包商成果前的常见需求。我们没有隐瞒缺陷的动机,报告因此更加客观。这类检测最好在签署验收单之前进行。

按贵司的访问数据确定,而不是照搬通用清单。通常是两三种手机分辨率与三种浏览器,即可覆盖九成以上访客。全面覆盖成本高且不划算。

三个数字:系统能从容承载多少并发用户、从哪里开始变慢,以及瓶颈到底在CPU、磁盘、数据库还是代码。有了它们,才能理性判断是扩容还是优化。

在用户之前先检验产品

请说明需要测试什么、期限如何。我们会制定测试计划,并按场景数量报价。