基于Gompertz增长模型的BUG预测

基于Gompertz增长模型的BUG预测

背景

基本介绍:
http://www.51testing.com/html/36/489136-831363.html
https://testerhome.com/topics/10381
http://www.doc88.com/p-2445313427576.html

我们在日常的软件测试过程中会发现,在测试的初始阶段,测试人员对测试环境不很熟悉,因此日均发现的软件缺陷数比较少,发现软件缺陷数的增长较为缓慢;随着测试人员逐渐进入状态并熟练掌握测试环境后,日均发现软件缺陷数增多,发现软件缺陷数的增长速度迅速加快;但随着测试的进行,软件缺陷的隐藏加深,测试难度加大,需要执行较多的测试用例才能发现一个缺陷,尽管缺陷数还在增加,但增长速度会减缓,同时软件中隐藏的缺陷是有限的,因而限制了发现缺陷数的无限增长。这种发现软件缺陷的变化趋势及增长速度是一种典型的‘S’曲线,满足Gompertz增长模型的应用条件。模型表达式为:

Y=a*b^(c^T)

其中Y表示随时间T发现的软件缺陷总数,a是当T→∞时的可能发现的软件缺陷总数,即软件中所含的缺陷总数。a*b是当T→0时发现的软件缺陷数,c表示发现缺陷的增长速度。我们需要依据现有测试过程中发现的软件缺陷数量来估算出三个参数a,b,c的值,从而得到拟合曲线函数.

实际使用

  1. 统计项目每天的累积BUG数,获得若干递增的数据
  2. 根据数据获得拟合曲线,计算出a,b,c的值,其中a为可能的软件缺陷总数
  3. 根据a,b,c的值,计算时间T,其中可按95%的a或者90%的a来计算需要发现95%/90%的bug所需要的时间
  4. T-已花费的时间=为了达到质量所仍需的天数

原型代码如下(python)

# coding: UTF-8
import math
import numpy as  np
from scipy.optimize  import leastsq

###采样点
#project 1
yi=np.array([2,4,4,6,12,15,21,27,39,45,50,54])

#project 2
yi=np.array([6,11,15,20,25,31,33,41,42,44,49,52,53])
ti=np.array(xrange(1,yi.size+1))

total=yi[-1]

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

def extra(thread,a,b,c,total,day):
    expect=a*thread/100
    T=(math.log(math.log(expect/a)/math.log(b)))/math.log(c)
    if T>day:
        return T-day
    else:
        return 0

#初始值

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

print '预期bug总数:',a
print '已发现bug总数:' ,total
print '已发现bug占比:',total/a

day=yi.size
print '已花费天数:' ,day
T=extra(95,a,b,c,total,day)
print '为达到发现95的bug还需要%d天'%T
T=extra(90,a,b,c,total,day)
print '为达到发现90的bug还需要%d天'%T

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,yi.size*2,1000)
y=a*b**(c**t)
plt.plot(t,y,color='orange',label='fitting Point',linewidth=2)
plt.legend()
plt.show()

意义

  • 评估当前项目测试的程度
  • 评估可能线上问题的数目
  • 评估达到发布质量所额外需要的工时

不足

  • 这个方法使用前提是产品的整个测试活动中测试能力保持相对稳定,比如分轮次提测或者测试人力投入时间不均匀,数值可能误差较大
  • 对测试过程中发现的缺陷只做数量上的处理,不做等级上的划分

未来可以考虑优化这个预测模型或者采用更好的模型去判断测试退出时间点以及预测漏侧数量

原文地址:https://www.cnblogs.com/opama/p/10549796.html

时间: 2024-08-30 05:09:26

基于Gompertz增长模型的BUG预测的相关文章

GIS规划应用——基于哈夫模型的GIS服务区分析

1.  GIS服务区分析 区位因素是商业分析中一个至关重要的因素,因此在商店选址时,例行的服务区分析十分重要.服务区是指顾客分布的主要区域,在其范围内该店的商品销售量或服务营业额超过其竞争对手.对于现有商店,通过服务区分析可以考察市场潜力,评价经营业绩:对于新店,通过分析服务区可以在竞争对手背后发掘商机,从而有利于确定最佳选址.此外,服务区分析还有助于企业确定广告覆盖的重点地区,揭示顾客较少的薄弱地段,提出企业扩张计划等等. 常见的划分服务区的方法有类比法.邻域法.重力法等几种.类比法是一种非地

第57件事 用户增长模型和运营成本评估

又快到年底了,各种汇报接踵而来,跟着师傅学了这么长时间的产品,觉得也是时候往运营方向努力一把了.这不,师傅已经忙得神龙见首不见尾了,打算帮师傅减轻一下负担.从哪入手呢?好吧,就从用户增长模型开始吧.去网上搜了很多资料,看有没有前辈做好的现成的模型.运气真好,在网上看到有一个叫沙水的前辈写的一篇文章<APP运营与推广的数理分析模型>,研读之后,颇受启发.将文章的知识点制作成了Excel文档,给师傅看后,师傅大喜,连夸是个人才,这下减少不少工作量. 用户增长模型与运营成本预估是紧密相关的,我们分成

基于大数据的用户行为预测

随着智能手机的普及和APP形态的愈发丰富,移动设备的应用安装量急剧上升.用户在每天使用这些APP的过程中,也会产生大量的线上和线下行为数据.这些数据反映了用户的兴趣与需求,如果能够被深入挖掘并且合理利用,可以指导用户的运营.若能提前预测用户下一步的行为,甚至提前得知用户卸载.流失的可能性,则能更好地指导产品的优化以及用户的精细化运营. 大数据服务商个推旗下的应用统计产品"个数",可以从用户属性.使用行为.行业对比等多指标多维度对APP进行全面统计分析.除了基础统计.渠道统计.埋点统计等

Python中利用LSTM模型进行时间序列预测分析 - 预测爱尔兰的电力消耗

此示例中,神经网络用于使用2011年4月至2013年2月期间的数据预测都柏林市议会公民办公室的能源消耗. 每日数据是通过总计每天提供的15分钟间隔的消耗量来创建的. LSTM简介 LSTM(或长期短期存储器网络)允许分析具有长期依赖性的顺序或有序数据.当涉及到这项任务时,传统的神经网络不足,在这方面,LSTM将用于预测这种情况下的电力消耗模式. 与ARIMA等模型相比,LSTM的一个特殊优势是数据不一定需要是固定的(常数均值,方差和自相关),以便LSTM对其进行分析 - 即使这样做可能会导致性能

肺炎确诊人数增长趋势拟合和预测(截止1月28日)

截止目前(1月28日),数据都符合简单的指数曲线增长趋势. 所有数据都来自官方公布的确诊人数,取每天中午12点的人数为准.前4天没有拟合,因为数据点太少. 第4天(1月24日) 第6天(1月26日) 第8天(1月28日) 需要声明的是,没有任何证据显示预测人数是准确无误的,本文也不构成任何建议.这里只是简单的做一个数据分析,用的是指数曲线进行拟合,公式已经在图里了. 这几张图只能说明在疫情扩散前期,是符合简单的指数曲线增长规律的.我没有使用复杂的时间序列模型和RNN类模型,因为预测出来的反而会过

肺炎确诊人数增长趋势拟合和预测(截止1月30日)

预测明天(1月31日)确诊感染人数为9000,预计31日12时至24时增长区间为9000-9500. 1月29日预测1月30日确诊感染人数为8000,实际感染人数7736.预计30日12时至24时增长区间为8000-8500. ?1月28日预测1月30日感染确诊人数为6000,实际感染人数5999.预计29日12时至24时增长区间为6000-7000. 截止目前(1月28日),数据都符合简单的指数曲线增长趋势. 所有数据都来自官方公布的确诊人数,取每天中午12点的人数为准.前4天没有拟合,因为数

肺炎确诊人数增长趋势拟合和预测(截止2月1日)

预测2月2日确诊感染人数为14000,增长区间为14000-14500 昨日(1月31日)预测2月1日确诊感染人数为11500,增长区间为11500-12000.目前实际感染人数11800,误差较小. 前日(1月30日)预测1月31日确诊感染人数为9500,目前实际感染人数9723例,增速环比上升,但和模型相比再次放缓.增长区间为9500-10000 更新:昨天预测1月30日确诊感染人数为8500,目前实际感染人数8147例,增速再次放缓 更新:1月29日,预测感染确诊人数6000(中午12时)

基于价值链分析模型的业务流程梳理

基于价值链分析模型的 石油勘探开发业务流程梳理 ----业务流程梳理对于大型软件工程的重要意义 林道远 2013年04月22日 目录 一.业务流程梳理的重要性... 2 二.业务流程梳理的方法论... 2 三.石油勘探开发核心价值链分析... 3 四.石油勘探开发核心业务流程梳理(一级流程梳理)... 5 1.勘探开发(E&P)核心价值链(一级流程)及业务对象分析... 5 2.勘探开发业务流程与业务对象二维关系模型... 5 3.业务流程.业务对象与业务内容三维关系模型... 6 五.油田开发

tornado项目之基于领域驱动模型架构设计的京东用户管理后台

本博文将一步步揭秘京东等大型网站的领域驱动模型,致力于让读者完全掌握这种网络架构中的“高富帅”. 一.预备知识: 1.接口: python中并没有类似java等其它语言中的接口类型,但是python中有抽象类和抽象方法.如果一个抽象类有抽象方法,那么继承它的子类必须实现抽象类的所有方法,因此,我们基于python的抽象类和抽象方法实现接口功能. 示例代码: from abc import ABCMeta from abc import abstractmethod #导入抽象方法 class F