本文主要是介绍测试用例颗粒度实例列举,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
引言:昨天文章谈及到测试用例设计的颗粒度有人问
# 颗粒度如何划分?
# 颗粒度粗细与什么有关?
网上释义大把个人觉得还不够通俗,我就在通俗描述一下从以下几点去梳理梳理...
颗粒度分类
- 粗颗粒度
- 细颗粒度
粗细有何标准?
# 以用例数量划分
从我现在了解的测试同学写测试用例条数来看,一般一个功能点大部分都是百条至几百条左右
百条以下可以为粗
千条之上可以为细
万条那肯定是毋庸置疑为细
# 以测试数据去划分
边界值、等价类测试为粗
穷举、钻牛角尖为细
总结:粗颗粒度面向宏观,面向正向的功能点、大的功能模块和整体性,体现测试用例的设计思路;细颗粒度面向微观,面对具体的一个个功能点的正向/负向逻辑,体现测试用例的细节和完备性。
“重要功能”、“特殊功能”颗粒密集度高,“通用功能”可以试用通用测试粒度,密集度应该可以大致界定。个人认为,假如你非要为了一个字体的样式而写了一大长串的测试用例 ,那么...
颗粒度粗细与什么有关?
1.版本此次新增或修改的代码量
2.有效的测试时间以及人力
3.业务逻辑的难易程度
4.以需求去判断
5.以服务用户群体
# 以代码量去判断
如果开发修改几百行代码,测试时间不管是否充足并且逻辑复杂此时肯定是使用细颗粒度测试
如果开发仅仅就是修改几行代码,测试时间充足,可以使用通用颗粒度测试
如果开发仅仅就是修改几行代码,测试时间不充足,可以使用粗颗粒度测试
# 以项目时间判断
时间短、项目紧、编写用例评审时间较短时,适合粗颗粒度用例。
项目周期较长时,适合细颗粒度用例。
# 以测试人员判断
测试人员中熟手多,思路和基础技能扎实,或测试人员构成责任心高时,可以采用粗颗粒度用例。
测试人员新手多,需要再指导下进行基础测试工作,或责任心一般时,需采用细颗粒度用例
# 以需求判断
需求变更较多时,建议采用粗颗粒度的用例,可较灵活的覆盖需求。经过一轮轮的评审,等需求基线化之后,在实际的滚动测试中,在逐步细化用例——根据项目实际情况。
需求变更较少时,或需求变更波及较小,不是系统设计框架的频繁改动——具体的标准需要不同行业产品的评估,可对应较大的细化测试用例变更量。
# 以用户群体判断
如果项目/产品最终面对的客户是特定人员、专业人员、技术人员、培训后的操作员,可以采用粗颗粒度的用例。
如果项目/产品最终面对的客户是广义的使用群体、人民大众消费者,要采用细颗粒度的用例。
# 以实际场景列举
例如此次公司安排个人测试的抽奖系统项目周期5天,测试时间2天 ,个人表示只列举了测试点,测试用例都没来及写 ,每天加班九十点左右,这种何来细可立足之谈
- 仅仅只覆盖主要需求点正向功能为粗
例如:针对一个用户群为自己内部员工或者小范围用户使用,需求方只需要满足功能点能够正常运行就OK我们此时就可以用粗颗粒度进行设计测试用例,达到最少人力时间成本完成最终刚需需求点,提前供他们使用.
- 将功能点正反异常场景功能、页面、UI、兼容、用户体验度、全部涉及到的测试用例为细
例如:一个大型电商APP或者社交软件;用户群是对外投入市场使用,此时用户对其功能界面体验性肯定是要求极高,我们此时就要从各个测试方向细化测试用例,"用户想到的我们要想到,用户想不到的我们也要想到"
专注软件测试行业前景分析、测试思想、管理领域分享;划水之余带领1W+测试开发攻读功能、接口自动化测试、Python好文 关注作者 回复"测试""Python""postman"领取系统学习资料
题图 : 心得分享
这篇关于测试用例颗粒度实例列举的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!