需求评审
在开发之前先读需求、找出矛盾之处。最省钱的缺陷是在需求阶段发现的。
测试的价值不在于找到多少缺陷,而在于积累下来、每次都要跑一遍的场景集。
在开发之前先读需求、找出矛盾之处。最省钱的缺陷是在需求阶段发现的。
写明场景与预期结果,可反复复用,而不是每次临时想。
主流程、边界值,以及输入非法数据时的表现。
验证新改动没有破坏旧功能。这是缺陷反复出现的主要原因。
附复现步骤、运行环境与预期行为,让开发不必靠猜。
说明测了什么、没测什么,以及发布时仍存在哪些风险。
第一轮耗时较长,因为用例要从零编写;此后回归会快得多。
了解产品,并弄清哪些对业务关键、哪些属于次要。
确定测什么、测到什么深度、边界在哪里。无限测下去是不可能的。
跑通场景、记录问题,并对修复结果做复测。
给出是否可发布的结论,并列出遗留风险。
测试报告不会说「没有缺陷」。它说明测了什么、没测什么、还剩哪些风险。「没有缺陷」是无法证明的;而在知晓风险的前提下决定发布,则是正常的做法。
会测,但看自己的东西容易视而不见,而且只会验证他设想的路径。专职测试关注的是开发没想到的情况:非法输入、连接中断、按钮连点两次。
大致是开发工时的四分之一到三分之一。低于这个比例,就只能覆盖主流程,部分缺陷会流到用户手里。如果这是有意识的取舍,也可以接受。
可以,这是常见需求:系统已经有了,但质量存疑。我们会先做梳理,并依据产品本身而不是文档来编写用例,因为这类项目通常没有文档。
请说明是什么系统、哪些地方让您不放心。我们会制定测试计划并评估工作量。
申请已受理
我们已经收到。我们会在一个工作日内回复,紧急问题将立即安排值班工程师处理。
未找到该城市,请检查拼写。