测试用例中遇到的常见问题!这10到题应该能帮到你很多【附答案】

本文详细阐述了测试用例的重要性和设计方法,包括等价类划分、边界值分析等测试策略。强调了用例评审的重要性,指出评审过程能加深需求理解,提高测试覆盖率,并列举了评审参与者和注意事项。同时,提出了应对开发不自测的策略,提倡引入提测标准和产品验收环节,以提升产品质量。
摘要由CSDN通过智能技术生成

1

测试用例是什么?

  测试用例的设计就是如何覆盖所有软件表现出来的状态,即在满足输入/输出的一组条件下,软件运行时一系列有次序的、受控制的状态变化过程

 

2

设计用例是否有必要?

 

  将测试内容记录下来,避免了在执行的时候部分测试点被遗漏,另外也便于用例评审,用例总结,对后期测试工作起到改进作用,因此,测试用例必须要写,颗粒度可以视情况而定,针对测试人员少,上线时间紧的项目,可做思维导图载出测试点。

 

3

如何写测试点?

 

  根据需求及设计交互稿,先列功能点,后扩展功能点为测试点(作为测试的标题),有必要的时候借助产品、开发、后端的力量,保证用例的覆盖度、学会借力。

  测试点(注:这里不是测试用例,用例一般都比较详细,开发不一定会花费很多时间去做自测)写完后,可发给开发做自测,部分遗漏点可以在测试时进行记录与补充

 

4

设计用例的益处?

 

  设计用例的过程可以更深刻的理解需求,熟悉各功能点,保证尽可能全的覆盖到各测试点,也便于用例评审

 

5

测试用例有哪些测试方法?

 

  等价类划分法,边界值法,功能图法、错误推测法、因果图法、场景法。

 

6

如何保证用例的覆盖度?

 

  首先一定要熟悉需求,需求分析,拆解非常重要,需要熟悉过程中,不理解或者有疑问的地方,一定要找产品进行及时沟通,确定结果,其次项目开发过程中,每期的测试用例都要不短总结,学会总结,尽可能的保证少漏,其实这个与测试

  思维密切相关,工作经验的积累,以及测试思维的形成,都有助于你设计一份较完整的测试用例

 

7

用例写完,我们先要做什么?

 

  先自检,自检完毕,列出仍有疑问的点,评审之前,把用例提前发给相关的开发,产品,预留时间告诉他们先看,在统一时间进行评审

 

8

哪些人应该参加用例评审?

 

  产品。开发(客户端、后端、前端等,每个公司情况不一,可按实际来),测试需一起进行用例评审,评审力度需要加大,不能只是走个过场,需要有产出,否则有可能体会不出用例评审的作用。如果开发不重视,可拉上研发总监一起评审,我之前评审过的用例,每次在评审时,产品不同岗位的人员,都能提出相关的一些用例中没有包含的问题,都需重新调整用例,最后在进行二次评审,在用例的评审过程中,针对大家提出的问题,可以简单的进行记录,评审后再进行详细补充,第一次评审过的用例重新整理完成之后,再次通知相关的评审参与人,这样做的目的是告诉大家,我们做了什么事,做的结果如何,后续还有什么改进的地方,及时总结,目标明确,可带动大家积极参与。

 

9

用例评审有必要逐条念吗?

 

  用例评审没有必要逐条念标题和预期结果,这样很浪费时间,比如,一个项目的用例整理之后都是上百条,如果逐条念很耗费时间,建议可以根据条件总结性的过,大部分用例结果是已知的,步骤和预期结果是不用讲的,除非个别有疑惑的测试点,可以花费时间一起讨论沟通下(建议:使用思维导图进行用例的讲解,对某些特殊说明点可以参照用例进行)

 

10

对于开发不自测的,我们该如何做?

 

  建议加入提测环节,测试给出提测标准,没达标就打回,或者先给产品进行功能主流程验收(设计对UI进行验收),产品说通过验收了再给测试提测,要开发自测可自上而下进行推动,加入某个环节也需要技术总监的支持。开发自测可以使测试人员轻松点,一些比较容易发现的问题可在进入测试人员测试阶段可避免,这样下来整体节约了时间,而测试也有更多的时间去测试复杂的逻辑问题,而不是只测需求功能问题,同时,给研发一点压力,开发的功能模块质量也会有提高,多次提测不通过也可作为研发考核的一个标准。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值