如何设计测试用例

测试用例是业务测试过程中测试者的生命线。
在大需求面前无从下手测试时,测试用例是测试者对全盘概念的梳理和深度探索;
在测试过程中碰到任何问题阻断测试场景或思路时,测试用例是测试者的执行指令和方向盘。
当需求文档及对应的需求技术方案产出时,测试者需要根据提供的文档对需求进行解构,解构出需求的原子内容后,再进行测试用例的设计,而测试用例即需要考虑测试验证的全面性又需要考虑测试的深度。那么,这就需要测试人员进行全方位考虑来构建测试思路和使用什么样的测试策略和方法来尽可能保证测试覆盖的全面性。

试问,当面对一个大型需求(此处是指需要花费至少 2 个迭代才能完成的需求),测试人员需要有什么样的测试用例设计思路才能达到高时效、高人效、全面的做到测试覆盖呢?

测试用例设计核心

重要程度

测试用例的设计首要考虑的是主流程场景(一定要搞清楚需求的背景及需求是为了解决什么问题而产生的),主流程包括:
1. 测试用例的设计围绕产品需求文档的描述进行设计
2. 测试用例的设计场景是否符合实际用户的使用场景
在主流程中,把握测试用例的优先级,能够尽早在测试过程中发现严重问题,尽早暴露问题

等价性

测试用例的设计需要根据开发的实现逻辑去设计,黑盒测试可能存在设计的多个测试用例间存在无效测试用例的情况,比如有些交互场景中,存在表单中有多个填入项,如果测试者设计时,将每个输入项都作为一个测试场景去设计,而不了解实现的话,那测试用例将呈指数增长,必定会存在很多无效测试用例。当然,此处的比喻比较极端,但测试者需要有这样的意识,去

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

酔清风

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值