4、资源配置:
资源配置较少,无法实现测试用例的细化时,可以采用粗颗粒度的测试用例。
资源配置较多,可满足用例编写、评审、修订的交叉进行时,可采用细颗粒度。
举例:如果测试人员配置较少,一共就三五个人,每人负责一个项目,彼此没有时间去做评审,甚至项目都存在临时增多的现象,就无从谈起测试用例的细化,甚至粗颗粒度都较难实现,只能拉一个测试大纲出来。
或者测试团队有十多个人,但是项目是流水式过来的。需求、开发、测试是流水线模式处理大批量的项目,无法做到一个项目的全流程参与时,也很难展开测试用例评审、修订以致细化事宜。
5、需求变更:
需求变更较多时,建议采用粗颗粒度的用例,可较灵活的覆盖需求。经过一轮轮的评审,等需求基线化之后,在实际的滚动测试中,在逐步细化用例——根据项目实际情况。
需求变更较少时,或需求变更波及较小,不是系统设计框架的频繁改动——具体的标准需要不同行业产品的评估,可对应较大的细化测试用例变更量。
举例:一个需求,粗颗粒度的用例为100条,细颗粒度的用例为10000条。此需求变更,如果要修改粗颗粒度的用例,只需要修改10条;修改细颗粒度的用例,牵扯到细化的交叉逻辑,需要审阅2000条用例并可能修改1200条。
如果测试用例修改人非测试用例编写人,则修改时间还可能延长1.3倍。
6、项目对象:
如果项目/产品最终面对的客户是特定人员、专业人员、技术人员、培训后的操作员,可以采用粗颗粒度的用例。
如果项目/产品最终面对的客户是广义的使用群体、人民大众消费者,要采用细颗粒度的用例。
面向专业人员的项目/产品,测试倾向于正向测试,一些问题或使用方式在规定、需求之外,可以在培训或规范中指定操作模式,或凭借技术人员的功底来避免问题。
面向非专业人员的项目/产品,无法做到培训和操作约定,各种稀奇古怪的使用方法,操作习惯,所以更倾向于细颗粒度,覆盖负向和随机操作的测试用例。
7、测试团队素质:
团队个体素质较高,可适应粗犷、敏捷的风格时,可以采用粗颗粒度的用例。
团队处于成立初期或磨合期,需要细化的规则约定来指导时,采用细颗粒度的用例。