测试用例颗粒度实例列举

引言:昨天文章谈及到测试用例设计的颗粒度有人问

# 颗粒度如何划分?

# 颗粒度粗细与什么有关?

网上释义大把个人觉得还不够通俗,我就在通俗描述一下从以下几点去梳理梳理... 

颗粒度分类

- 粗颗粒度

- 细颗粒度

粗细有何标准?

# 以用例数量划分

从我现在了解的测试同学写测试用例条数来看,一般一个功能点大部分都是百条至几百条左右

百条以下可以为粗

千条之上可以为细

万条那肯定是毋庸置疑为细

# 以测试数据去划分

边界值、等价类测试为粗

穷举、钻牛角尖为细

总结:粗颗粒度面向宏观,面向正向的功能点、大的功能模块和整体性,体现测试用例的设计思路;细颗粒度面向微观,面对具体的一个个功能点的正向/负向逻辑,体现测试用例的细节和完备性。

“重要功能”、“特殊功能”颗粒密集度高,“通用功能”可以试用通用测试粒度,密集度应该可以大致界定。个人认为,假如你非要为了一个字体的样式而写了一大长串的测试用例 ,那么...

颗粒度粗细与什么有关?

1.版本此次新增或修改的代码量

2.有效的测试时间以及人力

3.业务逻辑的难易程度

4.以需求去判断

5.以服务用户群体

# 以代码量去判断

如果开发修改几百行代码,测试时间不管是否充足并且逻辑复杂此时肯定是使用细颗粒度测试

如果开发仅仅就是修改几行代码,测试时间充足,可以使用通用颗粒度测试

如果开发仅仅就是修改几行代码,测试时间不充足,可以使用粗颗粒度测试

# 以项目时间判断

时间短、项目紧、编写用例评审时间较短时,适合粗颗粒度用例。

项目周期较长时,适合细颗粒度用例。

# 以测试人员判断

测试人员中熟手多,思路和基础技能扎实,或测试人员构成责任心高时,可以采用粗颗粒度用例。

测试人员新手多,需要再指导下进行基础测试工作,或责任心一般时,需采用细颗粒度用例

# 以需求判断

需求变更较多时,建议采用粗颗粒度的用例,可较灵活的覆盖需求。经过一轮轮的评审,等需求基线化之后,在实际的滚动测试中,在逐步细化用例——根据项目实际情况。

需求变更较少时,或需求变更波及较小,不是系统设计框架的频繁改动——具体的标准需要不同行业产品的评估,可对应较大的细化测试用例变更量。

# 以用户群体判断

如果项目/产品最终面对的客户是特定人员、专业人员、技术人员、培训后的操作员,可以采用粗颗粒度的用例。

如果项目/产品最终面对的客户是广义的使用群体、人民大众消费者,要采用细颗粒度的用例。

# 以实际场景列举

例如此次公司安排个人测试的抽奖系统项目周期5天,测试时间2天 ,个人表示只列举了测试点,测试用例都没来及写 ,每天加班九十点左右,这种何来细可立足之谈

- 仅仅只覆盖主要需求点正向功能为粗

例如:针对一个用户群为自己内部员工或者小范围用户使用,需求方只需要满足功能点能够正常运行就OK我们此时就可以用粗颗粒度进行设计测试用例,达到最少人力时间成本完成最终刚需需求点,提前供他们使用.

- 将功能点正反异常场景功能、页面、UI、兼容、用户体验度、全部涉及到的测试用例为细

例如:一个大型电商APP或者社交软件;用户群是对外投入市场使用,此时用户对其功能界面体验性肯定是要求极高,我们此时就要从各个测试方向细化测试用例,"用户想到的我们要想到,用户想不到的我们也要想到"

专注软件测试行业前景分析、测试思想、管理领域分享;划水之余带领1W+测试开发攻读功能、接口自动化测试、Python好文 关注作者 回复"测试""Python""postman"领取系统学习资料


题图 : 心得分享

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值