测试用例评审
测 试 组 内 评 审
1、用例描述是否清晰:比如看到用例标题就能明白这条用例测试的是什么(而不是直到看到期望结果才明白这条用例的目的), 执行步骤和期望输出是否有歧义。
SRE实战 互联网时代守护先锋,助力企业售后服务体系运筹帷幄!一键直达领取阿里云限量特价优惠。2、操作步骤是否有可执行性:
-
其他人读完你的操作步骤,是否明白如何去操作;
-
一条用例多个测试点,这可能导致其他人执行你的用例时产生遗漏;
-
测试点是否有连贯性,是否贴近测试执行时的步骤。
3、是否考虑到测试用例的编写效率:即复用性要强。例如,可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。否则写用例和执行时阅读用例都会花费很多时间。
4、是否考虑到了执行效率:用例怎么跟版本迭代结合?(我的期望是可以快速筛选出每次冒烟、系统测试、回归测试的用例,回归用例包括bug回归、功能新增回归、功能修改回归、 验收前整体回归)。
5、是否覆盖了所有的软件需求?测试人员对需求的理解是否透彻?期望结果是否与需求一致?
6、异常测试点:可以从测试思维框架和以前的bug中找找看。
7、其他,比如优先级安排是否合理;二次评审时是否修改/删除了之前说过的问题。
项 目 组 内 评 审
外部评审涉及协调外部资源,需要注意:
1、确定参会人:一般情况下我们会跟产品、开发一起评审,但并非所有情况下都是如此;
2、提前约时间:在外部的人看来,用例评审并不是本职工作,是给测试人员帮忙的,也有的会认为评审需求跟产品评审就好了。加上开发人员一般开发任务都紧张,所以测试人员要提前跟别人约时间。
3、确定评审内容:我一般在外部评审时只讨论测试范围和测试执行时可能有的风险。比如有的测试数据测试人员不能自己做,需要研发配合做程序改动。尽量避免在会议上讨论别人一句话或几句话就能说清楚的需求问题(显得不专业,浪费大家时间。这些内容应该在会前确认)。
4、评审形式:思维导图形式进行。
