用例评审】为什么要进行测试用例评审?

2022-04-02 17:11发布

9条回答
小光光321
2楼 · 2022-04-06 11:25

功能测试的用例评审首先需要弄清楚功能测试的用例评审的目的:第一是为了减少测试人员执行阶段做无效工作,如执行无效case,提交无效问题;第二是为了避免三方需求理解不一致;第三为了每个测试人员的质量标准与项目要求标准达成一致。

回答: 2022-04-07 11:41

第一是为了减少测试人员执行阶段做无效工作,如执行无效case,提交无效问题;第二是为了避免三方需求理解不一致;第三为了每个测试人员的质量标准与项目要求标准达成一致。

不吃鱼的猫
3楼 · 2022-04-07 11:10

这样才能测试出关键地方是否符合需求

IT学习助手 - qq:2676427015
4楼 · 2022-04-08 08:51

第一、测试用例的好处:

1、 在开始实施测试之前设计好测试用例,可以避免盲目测试并提高测试效率;

2、 测试用例的使用令软件测试的实施重点突出、目的明确;

3、 在软件版本更新后只需修正少部分的测试用例便可展开测试工作,降低工作强度,缩短项目周期;

4、 功能模块的通用化和复用化使软件易于开发,而测试用例的通用化和复用化则会使软件测试易于开展,并随着测试用例的不断精化其效率也不断攀升;

5、测试用例构成了设计和制定测试过程的基础。测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流,因而,随着测试用例数量的增加,对产品质量和测试流程的信心也会增强;

6、 测试工作量与测试用例的数量成比例。根据全面且细化的测试用例,可以更准确地估计测试周期各连续阶段的时间安排;

7、测试设计和开发的类型以及所需的资源主要都受控于测试用例;

8、 测试用例通常根据它们所关联关系的测试类型或测试需求来分类,而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两种测试用例:一种测试用例用于证明该需求已经满足,称作正向测试用例;另一种测试用例反映某个无法接受、反常或意外的条件或数据,用于论证只有在所需条件下才能够满足该需求,这种测试用例称作反向测试用例;

第二、测试用例给谁看:

1、在计划阶段,项目管理人员就要根据测试用例(需要多少工作量,需要什么测试环境,需要什么测试人员等等)来制定测试计划,合理安排工作任务;

2、在测试执行阶段,测试人员要依据测试用例来指导测试工作,否则整个测试过程就是盲目的;

3、当测试人员发现问题时,开发有时也需要查看测试用例来判断问题发生的背景;

4、 项目结束后,需要作为验收成果交于客户。

所以,测试用例在测试的整个过程当中起到了一个串联的作用,是必不可少的。



征戰撩四汸
5楼 · 2022-04-11 15:31

  1、测试思维不系统(没有经过系统性培训或专项训练)--针对新人


  2、个体思维局限(某些思维定势导致测试点遗漏)--所有人


  因此测试评审非常重要,目前我们的测试用例评审大部分是以项目维度在项目组内进行review,责任主体是开发,一般以邮件和会议的形式组织评审。这样也能补充一些测试点,但是没有一个完整的测试评审在线的流程约束,不是每个人都能进行前期的认真检视并能提出有效的意见。另外仅依赖开发的review,很容易只从软件设计实现的角度出发补充测试点,而不是从全局用户角度出发来补充,可能还是会造成测试遗漏。

猫的想法不敢猜
6楼 · 2022-04-12 15:16

原因一:设计完成的测试用例要分配给每个人来设计具体数据,并实现自动测试。设计用例和实现用例、执行用例并非一人完成。设计用例的人并不知道用例在具体执行的时候是否有问题,或者哪些步骤不能实现自动测试。再者“测试是无穷尽的”,谁又能保证自己设计的用例能覆盖完全?

  原因二:测试人员总是抱怨测试出来Bug后与开发扯皮太多,主要的原因之一是测试人员和开发人员对于被测试功能的理解未达成一致。因此用例需要提交给开发人员check,并在测试开始之前对于测试目标的功能需求理解达成一致。用例一般比需求文档更加具体,能更好的体现具体测试思路。如果在测试开始之前就提前和开发达成一致,那么在你发现争议的bug的时候,就不用费劲解释了,可以直接告诉他“用例评审的时候已经确认是这样了。”

  原因三:让需求人员参与评审,她们能帮助你找出更多的问题。经常在测试的时候,有些细节是无法送需求文档上得知的,需要频繁来和需求人员沟通,问东问西,如果他们在忙,也许会产生这样的心理“怎么连这个也不知道?”我们测试人员多委屈,吃苦不讨好。所以在评审的时候让需求人员明亮的眼睛多帮我们找出问题,解决疑问。

  原因四:设计完成用例至少要让Leader评审下,让她理解你的思路,如果有问题也及早提出。不然当你测试的模块出现问题的时候,Leader绝不会说都怪她当时没review你的用例,责任还是在你身上。

  原因五:现在有很多人是项目外包或人员外包,那么完成每一项工作的第一件事就是提交客户评审,当然在提交给客户前自己team先评审下最好,确保提交给客户高质量的成功。

  原因六:如果严格按照用例数量来计算工作量,真正测试A模块需要200个用例,一周的时间,可是你却由于某些误差设计出100个case,那么评估出来3天的工作量,那么你就等着加班吐血吧。


回答: 2022-06-01 13:44

1、开始实施测试之前设计好测试用例,可以避免盲目测试并提高测试效率。
2、测试用例的使用令软件测试的**实施重点突出、目的明确。
3、在软件版本更新后只需修正少部分的测试用例便可展开测试工作,降低工作强度、缩短项目周期。
4、检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路.
测试用例参与人员仅测试人员,测试用例评审的参与人员是:开发、产品、测试人员。进行测试用例评审有以下好处:
1、产品人员参与,可以方便核对测试用例是否覆盖产品需求,在评审的过程中完善产品说明文档,完善产品的逻辑。
2、开发人员参与用例评审,可以从代码实现角度给出建议,防止漏测或过度测试,保证测试的全面性,减少无效测试,增加重点模块的测试。
3、测试人员参与用例评审,可以审查用例是否规范,对于交互模块的用例覆盖的是否齐全。

lucky璐呀
7楼 · 2022-04-15 09:21

第一是为了减少测试人员执行阶段做无效工作,如执行无效case,提交无效问题;第二是为了避免三方需求理解不一致;第三为了每个测试人员的质量标准与项目要求标准达成一致。

三岁奶猫
8楼 · 2022-04-21 10:35

每个测试工程师写测试用例的时候或多或少都会遗漏一些测试点, 不是说他们能力不行,而是每个人的思维有局限性,通过测试、产品、开发一起评审,把没有想到的测试点找出来  

俗话说:三个臭皮匠赛过诸葛亮,一个人的智慧有限,通过测试用例评审,就能够汇聚集体的力量,别人可能发现自己考虑不到的测试 点。 当局者迷,旁观者清,

相关问题推荐

  • 回答 1

    模板:也看自己需求呢,可以变动

  • 回答 1

    一、 部门评审,测试部门全体成员参与的评审。二、公司评审,这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员三、 客户评审,包括了客户方的开发人员和测试人员。...

  • 回答 1

    1、评审之前,需要将即将评审的测试用例以及测试需求、测试分析的结果(测试点分析)等文档提前发送给相关的人员;最好能够让他们有时间提前阅读; 2、随时的问题沟通与反馈机制。评审之前做一些问题的沟通与反馈,以便于在测试用例评审会议上能够节省出来宝...

  • 回答 3

    1、用例设计的结构安排是否清晰、合理,是否利于高效对需求进行覆盖;2、优先级安排是否合理;3、是否覆盖测试需求上的所有功能点 ;4、用例是否具有很好可执行性;5、例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确;6、期待结果是否有明...

  • 回答 2

    1.为了减少测试人员执行阶段做无效工作;(执行无效case,提交无效问题)2.为了避免三方需求理解不一致;3.为了每个测试人员的质量标准与项目要求标准达成一致;

  • 回答 9

    两个时间点:

  • 回答 9

    ①评审过程中收集相关人员的反馈信息,并在此基础上进行测试用例更新,直到评审通过;②评审结束后,测试负责人出测试用例评审报告给到相关人员;③评审结果经项目经理同意确认。...

  • 回答 5

    测试用例本身的描述是否清晰,语言准确;是否存在二义性;测试用例内容是否完整,是否清晰的包含输入和预期输出的结果;测试步骤是否清晰;测试用例中使用的测试数据是否恰当,准确;测试用例是否具有指导性,是否能灵活的指导软件测试工程师通过测试用例发现...

没有解决我的问题,去提问