测试案例颗粒度,目前测量颗粒度最常用的方法有

  测试案例颗粒度,目前测量颗粒度最常用的方法有

  导读:昨天文章谈到了测试用例设计的粒度,有人问。

  #粒度是怎么划分的?

  #粒度粗细和什么有关?

  网上解读对很多个人来说还不够普及,我就用普及度来描述,从以下几点来梳理。

  颗粒度分类

  -粗粒度

  -精细粒度

  粗细有何标准?

  #以用例数量划分

  从我现在所知道的测试同学写的测试用例数量来看,一个功能点大部分都在一百到几百左右。

  100以下可以厚。

  一千巴以上也可以。

  一万条,肯定是毋庸置疑的。

  # 以测试数据去划分

  边界值和等价类测试很粗糙。

  筋疲力尽,往一个细洞里钻死胡同。

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

  “重要功能”和“特殊功能”的粒子密度较高,“一般功能”的粒子密度可以用一般的测试粒度来大致定义。就个人而言,如果你必须为一种字体样式写一长串测试用例,那么.

  颗粒度粗细与什么有关?

  1.这次添加或修改的代码量。

  2.有效的测试时间和人力

  3.业务逻辑的难度

  4.根据需求判断

  5.为了服务于用户群

  # 以代码量去判断

  如果你开发修改了几百行代码,不管测试时间是否充足,逻辑是否复杂,那么你都必须使用细粒度测试。

  如果开发只是修改几行代码,测试时间足够,可以使用通用粒度测试。

  如果开发只是修改几行代码,测试时间不够,可以用粗粒度测试。

  # 以项目时间判断

  当时间短,项目紧,编写用例的评审时间短时,适合粗粒度的用例。

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

  # 以测试人员判断

  当测试人员精通,有坚实的想法和基本技能,或者有高度的责任感时,可以采用粗粒度的用例。

  当有很多新手测试人员,需要在别人的指导下进行基本的测试,或者有普遍的责任感时,应该采用细粒度的用例。

  # 以需求判断

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

  当需求变化较小,或者需求变化影响较小时,并不是系统设计框架的频繁变更。——具体标准需要对不同行业的产品进行评估,可以对应详细测试用例的较大变化。

  # 以用户群体判断

  如果项目/产品的最终客户是特定的人员、专业人员、技术人员和训练有素的操作人员,可以采用粗粒度的用例。

  如果项目/产品的最终客户是广泛的用户和消费者,那么应该采用细粒度的用例。

  # 以实际场景列举

  比如这次公司安排个人测试的抽奖系统项目周期为5天,测试时间为2天。个人说只列了测试点,测试用例没来没写,每天加班到90点左右。这怎么能有根据呢?

  -仅覆盖主要需求点。正向函数粗糙。

  比如一个用户群是自己内部员工或者小范围用户使用,需求方只要满足功能点,正常工作,就OK了。我们此时可以设计粗粒度的测试用例,实现最小的人力和时间成本完成最终的刚需需求点,供他们提前使用。

  -将功能点的功能、页面、UI、兼容性、用户体验以及所有相关的正反异常场景的测试用例进行细分。

  比如:某大型电商APP或社交软件;用户群投放市场供外部使用。这时候用户对其功能界面的体验肯定有极高的要求。此时我们将从所有测试方向细化测试用例,"用户想到的我们要想到,用户想不到的我们也要想到"

  专注于软件测试行业的前景分析,测试思想和管理领域的分享;划水之后带领1W测试开发学习函数,接口自动化测试,Python好文章。作者回复测试, Python ,邮差来

郑重声明:本文由网友发布,不代表盛行IT的观点,版权归原作者所有,仅为传播更多信息之目的,如有侵权请联系,我们将第一时间修改或删除,多谢。

留言与评论(共有 条评论)
   
验证码: