测试管理 缺陷增长模型

lion · 发布于 2017年10月10日 · 最后由 zailushang 回复于 2017年10月19日 · 最后更新自管理员 Lihuazhang · 1188 次阅读
本帖已被设为精华帖!

Gompertz 增长模型,有没有数学上,证明下该模型有效性或者思路的?
y=a*bcT

项目中哪些因素对结果有影响,如 加班因素、人员变更

# coding: UTF-8

import numpy as  np
from scipy.optimize  import leastsq

###采样点
ti=np.array(xrange(1,23))
#yi=np.array([7,10,21,23,24,50,91,120.140,154,171,201,220,224,239.247,256,274,295,325,346,353,369,386,424,484,534,
 #            582,621,636,708,736,800,863,932,965,1001,1042,1082])
#3,4,12,13,14,23,42,62,72,76,87,107,117,118,127
yi=np.array([152,168,194,206,213,225,242,280,336,382,429,466,479,548,
             572,626,683,748,778,813,847,885])
def func(p,t):
    a,b,c=p
    return a*b**(c**t)

def error(p,t,y,s):
    print s
    return func(p,t)-y

p0=[1500,0.078,0.874]
s="Test the number of iteration"
para=leastsq(error,p0,args=(ti,yi,s))
a,b,c=para[0]
print 'a=',a,'b=',b,'c=',c

import matplotlib.pyplot as plt
plt.figure(figsize=(8,6))
plt.scatter(ti,yi,color='red',label='Sample Point',linewidth=3)
t=np.linspace(0,80,1000)
y=a*b**(c**t)
plt.plot(t,y,color='orange',label='fitting Point',linewidth=2)
plt.legend()
plt.show()






如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 33 条回复
2651
110Lihuazhang 回复

您好,看到这篇文章真是幸运,请问一下,这个模型对测试活动确实适用吗?有公司或者团队实践过证明可行吗?例子中测试周期长达28周,如果把周改为天,还适用吗?感谢!

110
2651kaitlyn 回复

不知道,我只是网上搬过来的,没有实践过。

297
lion · #4 · 2017年10月11日 作者

#3楼 @Lihuazhang 我拟合效果非常好。不过中间有加班,对结果有些影响。当前缺陷量900,拟合最大2700。
直观感觉不太对。

—— 来自TesterHome官方 安卓客户端

297

#2楼 @kaitlyn 我拟合后,拟合效果非常好,曲线很美。偏差很小。但团队中间有加班。 这部分因素对结果应该有影响。
所以咨询下,这个模型的广义(不仅仅测试缺陷预估)适用性,有哪些因素制约结果。

—— 来自TesterHome官方 安卓客户端

110
297lion 回复

放下你的数据?

16280
  • 肯定可用,而且具备参考价值
  • 这个公式的每个参数,是需要拿既往数据来调整之后才能去拟合的,并非每个团队都能通用

我之前在平安科技做这个工作比较久,不过计算用存储过程搞的,推算出预期之后再来观察每天工作是否到位,我们的版本周期只有15~30天,所以周期上不会有太大差别
除了这个Gompertz之外,还有个Rayleigh模型,更精细,用于分阶段预测甚至推算线上bug数,至于效果么,我说两条:

  • 不见得每次都那么好,因为维护性、补丁性的变更版本和大项目不一样,大项目从头来过,没有历史数据好参考
  • 最好把这个计算用规则引擎实现一下,各个参数可以动态调整才是王道,这伴随团队成熟度和管理水平而动态改变,并非一成不变

图例:

再看下,到年底了,发生了什么😂

16280

一个比较初级的版本供参考,说明:

  • 基础配置数据需要自己灌(劝你别费劲了)
  • 存储过程居然都在mysql里面(这个锅我不抗)
  • 前后端分离没做干净,所以有些页面无法访问
  • 地址:https://github.com/fudax/sqcs
16280

丑便丑了,我再晒一图,我一直引以为傲的:


110

忍不住加精了!

110 Lihuazhang 将本帖设为了精华贴 10月12日 10:50
110

@fudax 这个预测需要多少历史数据?

16280
110Lihuazhang 回复

按照我的经验三五个release是要的,然后开始预测,然后分析、优化参数,拍拍脑袋瞎估算一下,稳定下来至少要:

  • 团队人数、任务量稳定
  • 扣腚的团队人数8人以上为佳,SRS至少每个release要达到5个以上吧
  • 但是新项目、产品研发,我一般第一个迭代上线之后就会立刻开始下一个迭代的计算,拿整个测试团队的平均参数水平来拟合,所以偏差难免会大点,但是越早开始,后面越早贴近真实情况

每个团队的业务类型、复杂度不一样,即便是同样的开发量,缺陷密度也不一样,所以,参数要具体到每个产品或者业务系统,分析的维度也可以多元化:按产品、按产品的release、按开发团队、按测试团队……最后在一维分析的基础上再做二维、三维的分析,比如加上时间周期来看整体的趋势,这样在全年工作衡量乃至考核打分的时候都有点参考价值(这是大M的事)。

16280
110Lihuazhang 回复

我再说一次我去蚂蚁面试的事情,第二次去蚂蚁面试的时候面试题就有一张累积缺陷趋势图,让我来说一下这个项目有什么问题,当时我惊叹于这帮互联网屌丝居然也懂我传统业务的管理办法……那时候开始我以为阿里在这块有一整套的评估和监控体系在实行,现在看你的描述,应该也只是某些团队才会有吧。

110
16280fudax 回复

应该都有,可能不用了。不过我是野路子出生的测试,所以不懂这些。

50

这个东西不错!

16280
110Lihuazhang 回复

嗯,连测试工程师这个岗位都撤消了还说啥呢

115

没玩过,我们只有每周发布的缺陷统计以及每周功能性缺陷总和以及非功能性缺陷总和的统计

9fa33f

太六了。。。

10083

那可不可以换个思路,根据目前的经验,开发出bug的概率都是有一定规律可行的,那么可以通过每个开发过往的bug数量,然后来预测项目的bug数量?

6667
16280fudax 回复

楼主有时间一起交流下哈,方便留下微信不 , @Lihuazhang 以后准备弄个私信啥的不

110
6667taki 回复

随时可以加,不过还是鼓励贴内交流

6667
6667taki 回复

针对预测这块比较干兴趣,这块的准确度怎么样?对于团队的收益点都有哪些?

16280
6667taki 回复

只是管理效率、便利性和准确性的提升,对于一线帮助不大,你可以那这个数据透视的结果要求他们(包括开发、产品、测试)在哪里加强测试、在什么阶段要抓紧投入等等,而想要他们自己理解这些,估计就比较难了,除非是精英团队……而精英团队才不会用这个咧~

16280

最后还是要鸣谢一下,当年marvell测试经理张昊翔,现在去哪里也不知道了
做这些还是来自他chinatest2012的演讲,可惜现在TID大会演讲的水平已经不复当年了,说明测试真的就那么点事可说,技术发展都是被动的,而非领跑IT行业~

6667
16280fudax 回复

所有的数据指标是都有的,就是对预测感兴趣😀 精英团队也是需要地

110
16280fudax 回复

张昊翔去爱奇艺了吧

16280
110Lihuazhang 回复

这我知道,好像后面又跳了

2203
16280fudax 回复

精英团队一般用什么啊?

16280
2203zailushang 回复

精英不用管,自组织、自管理啊,领导都是端茶送水的角色😂

2203
16280fudax 回复

嗯嗯,感觉自己太无知了,平台和环境很重要,能看到很多好东西啊

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册