如何从风险的角度制定、管理测试的深度和广度

Background

1.      基于网络的应用

2.      同时升级到新的浏览器、全新的OS、以及至关重要的新版本第三方应用

3.      需要全面回归，但是只有两周的测试时间（额外两周的时间用于组建团队和编写测试脚本及用例）

4.      测试人员对业务很熟悉

5.      每个人只有四分之一或者更少的时间投入到这个项目的测试中

Challenge

制定一个策略，首先保证最重要的功能，然后如果时间允许再做深度的测试。同时要避免只在一点上测的很深入而忽略了测试的广度。专业的有丰富经验的测试人员通常可以有效的权衡风险、深度以及广度，但是对于经验并不丰富的测试人员怎样有效的规划时间和权衡三者的关系呢？

Planning application risk reduction approaches

1.      和项目经理、开发团队以及主要的相关人员讨论将会出现的风险。目的是了解技术架构以及以前项目的风险。我们决定基于讨论的内容对于“全面”回归做一个安全的缩减，并关注于主要的功能范围。

2.      找一个方法如何去衡量我们想要达到什么。一般没有经验的测试人员会形成两个阵营：一个是“测试所有的”（从一开始就关注于所有的错误和边缘的case并总想着再把他们再测一遍），再有一个是“我登陆了而且没问题”。为了避免这两种情况发生，我给出一个缺陷列表并且让测试人员思考：

l 操作非常频繁的东西

l 可能不频繁但是至关重要的东西

l 花公司钱的东西

l 会让公司遭到投诉的东西

l 少了活不了的东西

l 以前经常出错的东西

l 有需要精确计算的东西

这个列表是根据james bash的"Heuristic Risk-Based Testing"和Scott Barber的FIBLOTS heuristic而来的，你也可以根据你的需求来制定自己的风险列表。

Tight deadline app testing approaches

接下来，假设你的boss走过来告诉你一些代码被改变了，但是你只有有限的时间去测试而且你要给出一个合理的解释哪些没有执行，而哪些执行了，你怎么进行测试呢？这里有一个方法，我比较喜欢把测试的范围分到从critical到good：

l Critical/One-thing tests：

如果时间只能测一件事时，需要测的东西，测试时间<15分钟。很重要、频繁操作的。

l Important/One-hour tests

如果有一个小时可以进行测试，可以多进行一些真实环境的用例。

l Good/Four-hour tests

如果有四个小时可以进行测试，可以增加一些有趣的数据组合或者边缘测试用例。

Communicating coverage breadth and depth

有了上面的分类，我们很容易知道哪些需要深度测试的风险点我们已经考虑到了。下一部我们需要一种方法知道如何把深度和广度对应到实现，剩余时间以及我们已经知道的风险。

为了帮助我们实现这个需求，我们把整个应用理解为一个box：