更正以前风险调整中的一个缺陷

简介: 以前在我写的书《软件测试技术实战——设计、工具及管理》中提及一个关于风险调整的策略是完全错误的,现在更正如下

以前在我写的书《软件测试技术实战——设计、工具及管理》中提及一个关于风险调整的策略是完全错误的,现在更正如下:

调整前

4.2.2 调整风险级别

案例4-3:风险级别的调整。

假设原先的风险级别见表4-8。

表4-8 原先的风险级别

模块

可能性

严重度

风险级别

用户登录

3

6

18

用户注册

2

7

14

填写购物地址及支付信息

2

5

10

选择商品

3

4

12

放入购物车

3

5

15

结算

4

5

20

在线付款

4

6

24

目前级别发现的风险见表4-9。

表4-9 目前级别发现的缺陷

模块

高级

中级

低级

用户登录

2

5

16

用户注册

3

6

31

填写购物地址及支付信息

2

7

22

选择商品

1

5

13

放入购物车

1

0

3

结算

2

4

12

在线付款

3

5

15

下面来看如何调整风险级别。

Mi=高级错误数×5+中级错误数×3+低级错误数×1。

a=(Mi/∑Mi)×100%,根据a获得现在的发生可能性b。

  • a=1%~20%:b=1。
  • a=21%~40%:b=2。
  • a=41%~60%:b=3。
  • a=61%~80%:b=4。
  • a=81%~100%:b=5。

于是得到表4-10。

表4-10 风险级别调整(一)

模块

高级

中级

低级

合计

%

级别

用户登录

2×5=10

5×3=15

16×1=16

10+15+16=41

14.7%

1

用户注册

3×5=15

6×3=18

31×1=31

15+18+31=64

23%

2

填写购物地址及支付信息

2×5=10

7×3=21

22×1=22

10+21+22=53

19%

1

选择商品

1×5=5

5×3=15

13×1=13

5+15+13=33

11.9%

1

放入购物车

1×5=5

0×3=0

3×1=3

5+0+3=8

2.88%

1

结算

2×5=10

4×3=12

12×1=12

10+12+12=34

12.23%

1

在线付款

3×5=15

5×3=15

15×1=15

15+15+15=45

16.29%

1

合计

278

所以,e=(c + b)/2×d(c为原可能性,b为现在可能性,(c + b)/2为调整后的可能性。d为原严重性,e为现优先级)。

由于缺陷只体现出可能性,而对严重度的影响不存在,所以不考虑对影响度的调整。根据前面的公式,得到表4-11。

表4-11 风险级别调整(二)

模块

可能性

严重度

风险级别

用户登录

(3+1)/2=2

5

10

用户注册

(2+2)/2=2

5

20

填写购物地址及支付信息

(2+1)/2=1.5

4

6

选择商品

(3+1)/2=2

3

6

放入购物车

(3+1)/2=2

3

6

结算

(4+1)/2=2.5

4

10

在线付款

(4+1)/2=2.5

4

10

比较前后结果,得到表4-12。

表4-12 前后结果比较

模块

风险级别(调整前)

风险级别(调整后)

用户登录

18

10

用户注册

14

20

填写购物地址及支付信息

10

6

选择商品

12

6

放入购物车

15

6

结算

20

10

在线付款

24

10

调整后

Mi=高级错误数×5+中级错误数×3+低级错误数×1。

a=(Mi/ (MAXMi+MINMi))×100%,根据a获得现在的发生可能性b。

  • a=1%~20%:b=1。
  • a=21%~40%:b=2。
  • a=41%~60%:b=3。
  • a=61%~80%:b=4。
  • a=81%~100%:b=5。

于是得到表4-10。

表4-10 风险级别调整(一)

模块

高级

中级

低级

合计

%

级别

用户登录

2×5=10

5×3=15

16×1=16

10+15+16=41

60

4

用户注册

3×5=15

6×3=18

31×1=31

15+18+31=64

89

5

填写购物地址及支付信息

2×5=10

7×3=21

22×1=22

10+21+22=53

74

4

选择商品

1×5=5

5×3=15

13×1=13

5+15+13=33

46

3

放入购物车

1×5=5

0×3=0

3×1=3

5+0+3=8

11

1

结算

2×5=10

4×3=12

12×1=12

10+12+12=34

47

3

在线付款

3×5=15

5×3=15

15×1=15

15+15+15=45

63

4

MAXMi = 64

MINMi = 8

MAXMi + MINMi = 72

所以,e=(c + b)/2×d(c为原可能性,b为现在可能性,(c + b)/2为调整后的可能性。d为原严重性,e为现优先级)。

由于缺陷只体现出可能性,而对严重度的影响不存在,所以不考虑对影响度的调整。根据前面的公式,得到表4-11。

表4-11 风险级别调整(二)

模块

可能性

严重度

风险级别

用户登录

(3+4)/2=3.5

5

18

用户注册

(2+5)/2=3.5

5

18

填写购物地址及支付信息

(2+4)/2=3

4

12

选择商品

(3+3)/2=3

3

9

放入购物车

(3+1)/2=2

3

6

结算

(4+3)/2=3.5

4

15

在线付款

(4+4)/2=4

4

16

比较前后结果,得到表4-12。

表4-12 前后结果比较

模块

风险级别(调整前)

风险级别(调整后)

用户登录

18

18

用户注册

14

18

填写购物地址及支付信息

10

12

选择商品

12

9

放入购物车

15

6

结算

20

15

在线付款

24

16

目录
相关文章
|
10月前
|
测试技术 开发工具 数据安全/隐私保护
缺陷报告
缺陷报告
缺陷报告
|
10月前
|
设计模式 测试技术
什么是缺陷预防和缺陷改进?
什么是缺陷预防和缺陷改进?
284 0
|
10月前
|
测试技术
有了测试标准流程后缺陷就不会遗漏到线上吗?
有了测试标准流程后缺陷就不会遗漏到线上吗?
|
程序员
缺陷(bug)管理
理论上软件的缺陷是可修复的,不过有的修复成本比较高,不能追求软件的完美,根据风险来确定是否修复缺陷
|
测试技术
测试中的误报和漏报同样的值得反复修正
测试中的误报和漏报同样的值得反复修正
258 0
|
搜索推荐 IDE 测试技术
如何验证程序是否完成,测试以及修正Bug?
在日常中,我们码代码都是按照需求来的,为了验证我们的工作成果是否符合项目的需求,那么验证程序是否完成、测试以及修复bug就成了我们工作中非常重要的流程。
|
移动开发 JavaScript 前端开发
|
存储 容器 程序员