测试用例评审考虑什么因素

小编 302

测试用例评审考虑以下六个因素:1.测试环境的定义;2.测试用例的设计;3.测试用例的需求覆盖率;4.测试用例的可执行性;5.是否有负面测试用例;6.复用性和可维护性;7.自动化测试的转化能力。测试环境的定义将直接影响到测试结果,因此测试环境描述的准确性十分重要。

1.测试环境的定义

测试环境会直接影响测试结果。所以在评审测试用例的时候,要注意测试环境的描述是否准确,是否满足对应的测试用例的运行要求。

2.测试用例的设计

首先,要关注测试用例设计的结构安排是否清晰、合理,是否利于高效对需求进行覆盖;其次,优先级是否合理;最后,是否从用户层面来设计用户使用场景和使用流程的测试用例。

3.测试用例的需求覆盖率

评审测试用例对需求的覆盖率,不仅仅是看每个需求是否都有对应的测试用例,更要考虑到这些测试用例有没有覆盖到产品使用中一些特别场景,有没有考虑到一些特殊的边界和接口的地方。

4.测试用例的可执行性

测试用例评审要考虑用例是否具有很好可执行性,例如用例的前提条件、执行步骤、输入数据和预期结果是否清晰、正确;预期结果是否有明显的验证方法。

5.是否有负面测试用例

是否包含充分的负面测试用例。充分的定义,如果在这里使用“二八”法则,那就是4倍于正面用例的量,毕竟一个健壮的软件,其中80%的代码都是在“保护”20%的功能实现;

6.复用性和可维护性

基于软件复用的考虑,评审测试用例的时候还要注意测试用例是否具有重复使用的功能。可复用的测试用例,将会极大地提高测试的效率。

7.自动化测试的转化能力

自动化测试是提高测试效率的一种有效手段。如果组织想要推进自动化测试的能力,在评审测试用例的时候要考虑该测试用例是否易于向自动化测试的测试用例转化。

延伸阅读

什么是测试用例评审?

测试用例评审是通过测试人员组织用例评审会议,邀约项目相关人员,主要包括产品、开发及测试三方,对测试人员设计的测试用例的可执行性和全面性进行评估,同时消除各方对需求文档理解的偏差达到对需求理解的一致。

测试用例评审主要包含以下步骤和内容:

名列前茅步,测试人员提前准备好用例评审的资料,提前定好会议室发出会议邀约并附上用例评审资料。

评审时,测试用例建议使用xmind脑图进行评审,脑图可以清晰的展示用例的设计思路和关键信息,让参与评审的人员可以一目了然,能更快的捕获到用例设计者要表达的思想,降低阅读成本,提高会议效率。脑图需要包含全部用例的设计思路及测试功能点,并重点标注出有疑问的测试点。在评审前一天提前发出给相关与会人。

第二步,开始用例评审,会议组织者即测试人员做好会议记录,并标注清楚需要修改的用例内容。

评审开始时,先做简单的业务流程介绍。之后开始评审测试用例,评审时,不建议一条一条读下去,这样耗时长,收效差。可以将测试用例分主次进行划分,先评审主要功能,然后讨论有争议的功能点,最后一些简单的用例可以一笔带过。

除了功能点的评审,在会议中,可以与开发确认技术疑问点,例如:搜索功能是开发自写sql还是请求es搜索服务?哪些接口是调用第三方接口?哪些页面需要实时刷新?对于设计不合理的地方,可以提出一些可行性的建议。对于开发可能考虑遗漏的功能点或细节及时在会议上提醒,可从根源上遏制bug的出现。

在评审过程中,测试人员要做好会议纪要,如果用例有需要补充或修改的地方快速在Xmind上标注清楚,便于会后进行整理补充测试用例。

第三步,测试用例评审完成后,测试人员根据会中修改和补充的地方重新整理测试用例。

优化完成后,将冒烟测试用例发送给产品,开发人员,供开发人员提测之前进行自测。同时,将测试用例通过项目管理工具,平台等分享给项目的相关人员,方便项目其他成员查阅。在后续测试中,如若有需求修改的地方,需及时更新测试用例,做好测试用例的后续维护工作。

回复

我来回复
  • 暂无回复内容

站长微信
站长微信
电话联系

400-800-1024

工作日9:30-21:00在线

分享本页
返回顶部