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