软件测试——用例设计篇

测试用例的概念:

1.测试用例是一份测试文档,它描述输入、动作、和一个期望的结果,其目的是确定应用程序的某个特性是否正常的工作。

2.测试用例是软件测试团队的主要工作成果之一

3.测试用例的质量与写该用例的测试人员的水平关系极大

4.执行测试用例: 当一个软件版本被测试时,测试人员会使用一整套的测试用例(或者筛选其中的一部分),将这些用例逐个在被测的软件上执行,并判断其结果是否和预期相符,并以此评价软件版本的质量。

测试用例的定义:

测试用例是为某个特殊目标(Test Case)而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求

用例的构成元素:

用例编号
用例标题
优先级
预置条件
操作步骤
预期结果
实际结果
备注

例如:
在这里插入图片描述
用例的构成元素
测试编号(用例ID),顾名思义,就是为用例导入系统或者与bug进行关联时方便应用用例编号通常为 项目简称+模块简称+ 顺序编号

用例标题(用例名称),就像人的名字一样,给你书写的用例起一个名称,以方便执行用例,书写bug,其他人参考等时容易理解
通常名称包括在哪里+操作+验证内容

优先级,根据功能的大小,以及对系统的影响,划分等级以便于应对风险。
优先级通常划分为三部分: 高、中、低高:系统基本功能,重要特性、实际使用频率高的用例中:基本逻辑,非主要功能,使用频率也较高。低:提示,ui等影响不大的功能,使用频率不高

预置条件,就是执行当前测试用例的前提描述,如果不满足这些条件,则无法进行测试。预置条件要是充分条件

测试步骤,为了验证某个功能,我们需要怎样的操作才能看到这个功能

预期结果,按照用例测试步骤执行后希望达到的结果用来与实际结果比较,如果相同则该测试用例通过,不同则该测试用例失败

测试用例的注意事项

用语简洁清晰,但不能过于简单用语无歧义,尽量少用过长的句子1用例的各个基本要素要齐备,不能缺失用例的步骤应该足够详细,操作应该明确容易被其它测试工程师读懂,并能顺利执行

测试用例的粒度

粒度,指的是粗细程度。粒度大,就是说一个用例所涵盖的关注内容比较多,反之同理

用例的粒度大,则总的用例数就少,用例看起来也简洁

用例的粒度小,则单条用例关注的测试点很集不容易遗漏,并且执行需要的时间比较好估计

测试用例的执行状态

Block
Fail
Pass
N/A
Investigate
No Test

N/A——(not applicable) 不适用,客观原因导致无法适用于当前测试

Pass——通过,当执行结果与预期结果相符时,为passPass状态。

Fail——失败,当执行结果与预期结果不符时,为Fail失Fail败状态。

Block——阻塞,功能或者测试环境等的欠缺,导致测Block试不能进行到底,为Block状态。

No Test——未执行,当用例还尚未被执行时,是No Test未No Test执行状态。

Investigate——观察,当用例正在执行中,但是需要耗较多时间去观察其结果,是Investigate观察中状态。

整合测试用例
用例写作的技术含量体现并不是单条用例本身,而是针对整个特性,写出的整套的测试用例,是否有效地覆盖了应该验证的各个测试点。

回归测试用例
回归到测试的根本目的:保障软件质量,意味着我们要发现所有导致软件不能满足需求的缺陷。

优秀的测试用例写作者,具有的是灵活发散的思维,和全面的视野,写出的用例套能保证涉及软件运行时的各个关键要点,在执行完这样的用例并且没有发现问题,我们就可以对软件的质量下一个良好的结论。

测试用例并不可能一开始就写得很完美,可能也有写错的可能也有遗漏的测试点
随着软件的版本不断更新,软件本身的需求和规格以及设计都可能在不断地变更
随着测试的不断开展,测试人员对产品的理解逐渐加深

基于上述,就使得我们完全有理由在测试用例执行的过程中同时不断地优化我们的测试用例,使得用例的质量越来越高

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值