1
测试用例是什么?
测试用例的设计就是如何覆盖所有软件表现出来的状态,即在满足输入/输出的一组条件下,软件运行时一系列有次序的、受控制的状态变化过程
2
设计用例是否有必要?
将测试内容记录下来,避免了在执行的时候部分测试点被遗漏,另外也便于用例评审,用例总结,对后期测试工作起到改进作用,因此,测试用例必须要写,颗粒度可以视情况而定,针对测试人员少,上线时间紧的项目,可做思维导图载出测试点。
3
如何写测试点?
根据需求及设计交互稿,先列功能点,后扩展功能点为测试点(作为测试的标题),有必要的时候借助产品、开发、后端的力量,保证用例的覆盖度、学会借力。
测试点(注:这里不是测试用例,用例一般都比较详细,开发不一定会花费很多时间去做自测)写完后,可发给开发做自测,部分遗漏点可以在测试时进行记录与补充
4
设计用例的益处?
设计用例的过程可以更深刻的理解需求,熟悉各功能点,保证尽可能全的覆盖到各测试点,也便于用例评审
5
测试用例有哪些测试方法?
等价类划分法,边界值法,功能图法、错误推测法、因果图法、场景法。
6
如何保证用例的覆盖度?
首先一定要熟悉需求,需求分析,拆解非常重要,需要熟悉过程中,不理解或者有疑问的地方,一定要找产品进行及时沟通,确定结果,其次项目开发过程中,每期的测试用例都要不短总结,学会总结,尽可能的保证少漏,其实这个与测试
思维密切相关,工作经验的积累,以及测试思维的形成,都有助于你设计一份较完整的测试用例
7
用例写完,我们先要做什么?
先自检,自检完毕,列出仍有疑问的点,评审之前,把用例提前发给相关的开发,产品,预留时间告诉他们先看,在统一时间进行评审
8
哪些人应该参加用例评审?
产品。开发(客户端、后端、前端等,每个公司情况不一,可按实际来),测试需一起进行用例评审,评审力度需要加大,不能只是走个过场,需要有产出,否则有可能体会不出用例评审的作用。如果开发不重视,可拉上研发总监一起评审,我之前评审过的用例,每次在评审时,产品不同岗位的人员,都能提出相关的一些用例中没有包含的问题,都需重新调整用例,最后在进行二次评审,在用例的评审过程中,针对大家提出的问题,可以简单的进行记录,评审后再进行详细补充,第一次评审过的用例重新整理完成之后,再次通知相关的评审参与人,这样做的目的是告诉大家,我们做了什么事,做的结果如何,后续还有什么改进的地方,及时总结,目标明确,可带动大家积极参与。
9
用例评审有必要逐条念吗?
用例评审没有必要逐条念标题和预期结果,这样很浪费时间,比如,一个项目的用例整理之后都是上百条,如果逐条念很耗费时间,建议可以根据条件总结性的过,大部分用例结果是已知的,步骤和预期结果是不用讲的,除非个别有疑惑的测试点,可以花费时间一起讨论沟通下(建议:使用思维导图进行用例的讲解,对某些特殊说明点可以参照用例进行)
10
对于开发不自测的,我们该如何做?
建议加入提测环节,测试给出提测标准,没达标就打回,或者先给产品进行功能主流程验收(设计对UI进行验收),产品说通过验收了再给测试提测,要开发自测可自上而下进行推动,加入某个环节也需要技术总监的支持。开发自测可以使测试人员轻松点,一些比较容易发现的问题可在进入测试人员测试阶段可避免,这样下来整体节约了时间,而测试也有更多的时间去测试复杂的逻辑问题,而不是只测需求功能问题,同时,给研发一点压力,开发的功能模块质量也会有提高,多次提测不通过也可作为研发考核的一个标准。