包含内容

测试的价值不在于找到多少缺陷,而在于积累下来、每次都要跑一遍的场景集。

沟通服务内容

需求评审

在开发之前先读需求、找出矛盾之处。最省钱的缺陷是在需求阶段发现的。

测试用例

写明场景与预期结果,可反复复用,而不是每次临时想。

功能验证

主流程、边界值,以及输入非法数据时的表现。

回归测试

验证新改动没有破坏旧功能。这是缺陷反复出现的主要原因。

缺陷记录

附复现步骤、运行环境与预期行为,让开发不必靠猜。

测试报告

说明测了什么、没测什么,以及发布时仍存在哪些风险。

工作如何开展

第一轮耗时较长,因为用例要从零编写;此后回归会快得多。

01

熟悉产品

了解产品,并弄清哪些对业务关键、哪些属于次要。

02

测试计划

确定测什么、测到什么深度、边界在哪里。无限测下去是不可能的。

03

执行测试

跑通场景、记录问题,并对修复结果做复测。

04

出具报告

给出是否可发布的结论,并列出遗留风险。

测试报告不会说「没有缺陷」。它说明测了什么、没测什么、还剩哪些风险。「没有缺陷」是无法证明的;而在知晓风险的前提下决定发布,则是正常的做法。

常见问题

会测,但看自己的东西容易视而不见,而且只会验证他设想的路径。专职测试关注的是开发没想到的情况:非法输入、连接中断、按钮连点两次。

大致是开发工时的四分之一到三分之一。低于这个比例,就只能覆盖主流程,部分缺陷会流到用户手里。如果这是有意识的取舍,也可以接受。

可以,这是常见需求:系统已经有了,但质量存疑。我们会先做梳理,并依据产品本身而不是文档来编写用例,因为这类项目通常没有文档。

我们来检验贵司产品

请说明是什么系统、哪些地方让您不放心。我们会制定测试计划并评估工作量。