测试过程方法论-第三章:附件、需求跟踪、缺陷周期计算
2010-08-01 17:53
330 查看
3.1 文档模板
1. 《测试计划模板》
2. 《测试需求模板》
3. 《测试需求变更通知单》
4. 《测试用例模板》
5. 《测试执行记录模板》
6. 《缺陷跟踪汇总表模板》
7. 《缺陷记录单模板》
8. 《软件测试分析报告模板》
3.2 需求变更控制
3.2.1 需求变更控制的条件
1. 在测试计划阶段,如果系统需求有变动,如果该需求已经制定,则只需更改该需求即可,如果该需求尚未制定,则根据变更后的系统需求制定测试需求。
2. 在符合以下条件时可以进行需求变更:
A. 测试计划阶段已经结束,测试需求已经确认并签字;
B. 测试执行阶段尚未正式开始;
3. 如果测试执行阶段出现系统需求变更,而该变更对系统影响不大的话,可以填写备忘记录,在下一次测试项目中进行变更。
4. 如果测试执行阶段出现系统需求变更,而该变更对系统影响较大而必须变更的话,双方PM要就此达成认可,并填写备忘录,然后执行需求变更流程。如果需要暂停或中止当前测试执行过程,则需要更改协议并修正测试计划。
3.2.2 需求变更流程:
![](http://farm5.static.flickr.com/4139/4849088928_5b87284afc.jpg)
1. 发包方的需求发生变更,由发包方项目负责人向承包方项目负责人提出需求变更要求,填写《测试需求变更通知单》,并提供相应变更内容资料或指派人员提供变更内容;
2. 发包方项目负责人收到变更申请表后,制定测试分析人员进行测试需求变更;
3. 被指定的测试分析人员根据发包方提供的需求变更资料进行测试需求变更,如果是发包方指派人员提供变更内容则根据发包方指派人员提供的内容进行测试需求变更;
4. 被指定的测试分析人员在测试需求变更完成后通过承包方项目负责人通知发包方需求变更完成
5. 发包方项目负责人得到通知后指定其需求人员对变更的测试需求进行Review和确认;
6. 变更的测试需求被确认后,承包方项目负责人指派测试设计人员根据变更的需求修改测试用例或重新设计测试用例;
7. 在此之后的测试执行中使用修改后或重新设计的测试用例。
3.3 Rayleigh曲线的计算及其应用
3.3.1 Rayleigh曲线的计算公式
多数软件开发周期中所发现的问题都遵循Rayleigh曲线。Rayleigh曲线表示了某个时间周期内所发现问题随时间的变化趋势。其公式为:
f(t)=(2/t)*(t/c)2*(e-(t/c)**2)
![](http://farm5.static.flickr.com/4081/4848494049_ed50be8542.jpg)
其中,
c=tm* √ 2
e=2.71828 tm-Rayleigh曲线达到最大值时t的值
以上曲线下方所覆盖面积的总和,就是所有问题的总和,即f(t)的积分函数(也称为”累计分布函数“):
F(t)=l-(e -(t/c)**2 )
![](http://farm5.static.flickr.com/4122/4849127464_79651409f9.jpg)
该曲线将无限接近于1
3.3.2 实际应用
由于多数软件开发周期中发现的问题都遵循Rayleigh曲线分布,在软件产品交付给最终用户使用之前,就可以利用该曲线预测出未来发生的问题个数。
例如:
下面是某软件开发周期中发现的问题个数分布图:
![](http://farm5.static.flickr.com/4096/4849139470_c1eef5a85b.jpg)
-I0:t=1,9problems found
-I1:t=2,12problems found
-I2:t=3,17problems found
-UT:t=4,10problems found
-CT:t=5,6problems found
-ST:t=6,3problems found
-----------------------------------------------------------------------------------
小计:截至ST阶段(系统测试)为止,该软件产品已发现57个问题。
问:在该软件提交最终用户之后(FP阶段),可能还会发现多少问题?
解:
1. 因为tm定义为Rayleigh曲线达到最大值时t的值,而在此例中,在I2阶段所发现的问题个数最多,I2阶段对应于t=3,所以此处tm=3。
本例中参数c的计算为:c= tm * √ 2=3*1.41=4.23
2.在t=6(ST阶段结束时),使用公式F(t)=1-(e -(t/c)**2 )
F(6)=1-e*(-(6/4.23)**2)=1-e-99=1-2.71828-99=1-(0.135)=0.865=86.5%
3. t=6时,实际已发现的错误总数为57
57/86.5%=所有错误总数/100%
因此所有错误总数=66
4. 所有错误总数-至今已发现的问题数=66-57=9
即,交付给用户使用的软件中,可能还存在9个问题。
1. 《测试计划模板》
2. 《测试需求模板》
3. 《测试需求变更通知单》
4. 《测试用例模板》
5. 《测试执行记录模板》
6. 《缺陷跟踪汇总表模板》
7. 《缺陷记录单模板》
8. 《软件测试分析报告模板》
3.2 需求变更控制
3.2.1 需求变更控制的条件
1. 在测试计划阶段,如果系统需求有变动,如果该需求已经制定,则只需更改该需求即可,如果该需求尚未制定,则根据变更后的系统需求制定测试需求。
2. 在符合以下条件时可以进行需求变更:
A. 测试计划阶段已经结束,测试需求已经确认并签字;
B. 测试执行阶段尚未正式开始;
3. 如果测试执行阶段出现系统需求变更,而该变更对系统影响不大的话,可以填写备忘记录,在下一次测试项目中进行变更。
4. 如果测试执行阶段出现系统需求变更,而该变更对系统影响较大而必须变更的话,双方PM要就此达成认可,并填写备忘录,然后执行需求变更流程。如果需要暂停或中止当前测试执行过程,则需要更改协议并修正测试计划。
3.2.2 需求变更流程:
![](http://farm5.static.flickr.com/4139/4849088928_5b87284afc.jpg)
1. 发包方的需求发生变更,由发包方项目负责人向承包方项目负责人提出需求变更要求,填写《测试需求变更通知单》,并提供相应变更内容资料或指派人员提供变更内容;
2. 发包方项目负责人收到变更申请表后,制定测试分析人员进行测试需求变更;
3. 被指定的测试分析人员根据发包方提供的需求变更资料进行测试需求变更,如果是发包方指派人员提供变更内容则根据发包方指派人员提供的内容进行测试需求变更;
4. 被指定的测试分析人员在测试需求变更完成后通过承包方项目负责人通知发包方需求变更完成
5. 发包方项目负责人得到通知后指定其需求人员对变更的测试需求进行Review和确认;
6. 变更的测试需求被确认后,承包方项目负责人指派测试设计人员根据变更的需求修改测试用例或重新设计测试用例;
7. 在此之后的测试执行中使用修改后或重新设计的测试用例。
3.3 Rayleigh曲线的计算及其应用
3.3.1 Rayleigh曲线的计算公式
多数软件开发周期中所发现的问题都遵循Rayleigh曲线。Rayleigh曲线表示了某个时间周期内所发现问题随时间的变化趋势。其公式为:
f(t)=(2/t)*(t/c)2*(e-(t/c)**2)
![](http://farm5.static.flickr.com/4081/4848494049_ed50be8542.jpg)
其中,
c=tm* √ 2
e=2.71828 tm-Rayleigh曲线达到最大值时t的值
以上曲线下方所覆盖面积的总和,就是所有问题的总和,即f(t)的积分函数(也称为”累计分布函数“):
F(t)=l-(e -(t/c)**2 )
![](http://farm5.static.flickr.com/4122/4849127464_79651409f9.jpg)
该曲线将无限接近于1
3.3.2 实际应用
由于多数软件开发周期中发现的问题都遵循Rayleigh曲线分布,在软件产品交付给最终用户使用之前,就可以利用该曲线预测出未来发生的问题个数。
例如:
下面是某软件开发周期中发现的问题个数分布图:
![](http://farm5.static.flickr.com/4096/4849139470_c1eef5a85b.jpg)
-I0:t=1,9problems found
-I1:t=2,12problems found
-I2:t=3,17problems found
-UT:t=4,10problems found
-CT:t=5,6problems found
-ST:t=6,3problems found
-----------------------------------------------------------------------------------
小计:截至ST阶段(系统测试)为止,该软件产品已发现57个问题。
问:在该软件提交最终用户之后(FP阶段),可能还会发现多少问题?
解:
1. 因为tm定义为Rayleigh曲线达到最大值时t的值,而在此例中,在I2阶段所发现的问题个数最多,I2阶段对应于t=3,所以此处tm=3。
本例中参数c的计算为:c= tm * √ 2=3*1.41=4.23
2.在t=6(ST阶段结束时),使用公式F(t)=1-(e -(t/c)**2 )
F(6)=1-e*(-(6/4.23)**2)=1-e-99=1-2.71828-99=1-(0.135)=0.865=86.5%
3. t=6时,实际已发现的错误总数为57
57/86.5%=所有错误总数/100%
因此所有错误总数=66
4. 所有错误总数-至今已发现的问题数=66-57=9
即,交付给用户使用的软件中,可能还存在9个问题。
相关文章推荐
- 测试过程方法论-第二章:外包测试过程
- c++重写卷积网络的前向计算过程,完美复现theano的测试结果
- 缺陷漏测分析:测试过程改进
- 测试过程中的一些疑问(缺陷发现率、测试结束标准等)
- 缺陷漏测分析:测试过程改进
- 软件测试缺陷密度的计算方法
- 软件生存周期基本过程和测试过程
- [转载]缺陷漏测分析:测试过程改进- 向东博客 - 博客园
- 测试过程管理工具testlink和缺陷追踪工具mantis的集成
- 缺陷漏测分析:测试过程改进
- 基于缺陷驱动的测试过程有效性评价方法研究
- 测试过程之需求疏漏缺陷汇总
- 软件测试缺陷密度的计算方法
- 缺陷漏测分析:测试过程改进
- 测试过程方法论-第一章:编写目的
- iNOC产品部--完全数计算(测试数据较弱,暴力也通过 时间复杂度O(n*n))
- 用TD的Requirements模块来整理测试需求的一般过程
- 转:性能测试过程中的网络带宽及流量监视讨论
- <转>七种测试驱动模式(方法论)
- 软件测试过程模型的种类之-------------X模型(转)