一条好的测试用例,到底应该是什么样的?

玩技站长
玩技站长
管理员, Keymaster
11056
文章
0
粉丝
测试分享评论139字数 1405阅读4分41秒阅读模式
摘要在整个测试的过程中,提测之前,准确说,应该在需求评审、技术方案确认之后,那我们就需要去编写测试用例,通过测试用例来执行测试。

在整个测试的过程中,提测之前,准确说,应该在需求评审、技术方案确认之后,那我们就需要去编写测试用例,通过测试用例来执行测试。

本篇只是单纯的描述如何编写一条用例,针对用例本身,比如:包含哪些必要字段、可以有哪些扩展字段,每个字段应该编写到什么样的程度;不包括如何分析、设计用例,如何设计一套完整的用例,会有另外一篇文章来专门介绍。文章源自玩技e族-https://www.playezu.com/185589.html

好的测试用例有诸多的好处:文章源自玩技e族-https://www.playezu.com/185589.html

任何人测试人员都可以执行:可以给不是很熟悉该业务或者该模块的同学直接去执行,而不需要去反复再同开发、产品对齐,或者是猜测该条用例的意思或者意图;文章源自玩技e族-https://www.playezu.com/185589.html

减少不必要的沟通成本、节省实际执行时间:一条步骤清晰的用例,完全可以照着一步步执行;预期结果清晰,则可以很容易的断定该条用例是否通过;前置条件清楚明白,则可以顺利执行;文章源自玩技e族-https://www.playezu.com/185589.html

尽可能的减少重复劳动:在实际的工作中,我们会发现A同学写的用例交接给B同学之后,由于用例步骤不详细、前置不清晰等,导致无法理解、执行,导致会去重写该模块的用例,这就导致工作成本的增加;文章源自玩技e族-https://www.playezu.com/185589.html

归档:为后续的迭代、回归,回溯或者交接等提供清晰的依据以及指导。文章源自玩技e族-https://www.playezu.com/185589.html

一条基本的用例应当包含哪些字段:文章源自玩技e族-https://www.playezu.com/185589.html

用例名称、前置条件、输入步骤、预期结果,这几个字段是必不可少的,在保证基本字段清晰的情况下,根据需要,我们可以适当添加一些字段,比如:用例编号、优先级、使用平台、是否自动化、关联需求、是否通过、网络、备注等等;文章源自玩技e族-https://www.playezu.com/185589.html

基本字段必不可少,而且还要清晰描述:文章源自玩技e族-https://www.playezu.com/185589.html

用例名称文章源自玩技e族-https://www.playezu.com/185589.html

能完整且简洁的描述该条用例要做什么;

前置条件

用例执行需要做哪些前置步骤,或者需要哪些条件才能使该条用例顺利的执行下去;一般来说,在功能模块之前存在关联时或者依赖时,此时需要将前置条件写清楚,因为这些依赖和关联的点,可能只有当时相关的测试和开发比较清楚。

比如:限免时段内,重复领取福利;

例:

那么在前置条件或者备注里,最好解释一下限免规则;

发布限时免费的活动到测试环境;

同一时段内,领取过一次;

用例步骤或者输入步骤

这里也是指导用例执行的关键,需要将每一步写的比较清楚,否则其他人来执行的话,很容易出错或者理解错,比如:下载QQ表情的过程中,退出手机QQ这么个用例:

例:

手机登录QQ

打开一个聊天窗口

点击表情

点击“+”,进入表情商城首页

点击表情包,进入详情页

点击下载

当下载到50%之后,手机操作退出详情页面返回到aio界面

退出之后,检查是否可以正常下载完

预期结果

预期结果非常重要,不仅要将相关的检查点写的清晰、完整,而且还要严谨、不易产生误解,能够让其他人执行用例之后,明确判断该条用例是否通过;

比如点击下载某个表情包或者文件,这里的检查,包括前端、后端、数据、本地文件等检查;

下载过程中进度条的检查;

下载完成之后文件是否完整、正常打开,内容是否正确;

如果存在状态,状态是否变化;

如果存在数据存储,数据库检查等;

用例编号

代表着用例ID,可以通过多种方式来定,只要清晰明了即可;一般可以是:需求编号+功能模块代号+测试类别+编号;

优先级

用例优先级一般分为3个级别,P0P1P2,P0为最高级别,P2为最低级别;在测试活动中,P0级别用例通常会作为开发提测前的自测用例,因此,P0级别的用例比较重要,但量不能太多,在后续的迭代功能、回归测试中,会起着比较重要的作用。一般为正常功能、主流程用例。

使用平台

一般是指测试平台,比如:android、IOS、或者PC、mac等;

是否自动化

一般是指UI自动化或者接口自动化,如果已经自动化的用例,后续在回归测试以及迭代版本的冒烟测试上可以使用自动化来替代,方便区分、统计;

关联需求

这个一般是指需求的链接,或者需求名称(如果没有链接的话);方便后续回溯,以及其他人来使用或者熟悉该模块的测试以及开发。

是否通过

标注当前测试用例是否通过;

网络

测试需要使用网络,比如:3G、4G、wifi、弱网或者弱网详细参数,比如:丢包、延迟、具体网速等;

备注

一般说明该用例需要注意的事项或者特殊的事项。

 
匿名

发表评论

匿名网友
确定

拖动滑块以完成验证