基于风险来测试是一项技能。要了解一个产品可能出现问题的方面好，决定这些失败如果发生会产生多重要的影响，然后开发和执行测试来发现他们不管这个产品是不是在这些方面上出现了问题并不简单。当实施与典型的开发环境中，加上最后期限即将到来的压力，缺乏完整的信息和对于产品上哪些地方出错的不同观点的存在让这个过程甚至更难。但是这是一项值得学的技能。对风险关注将会把测试的关注点放在通常是测试任务的核心：快速找出重要的问题。
在我的咨询案例中，我注意到一些特定的常见的问题，这些问题是测试人员和测试经理在追求基于风险的方法时经历过的。我们来看一下这四个问题，看看怎么克服他们。
问题1："每个人都认为基于风险的测试只是一个管理问题。"
我经常听到有人谈到基于风险的测试时，他们看起来像是只讨论了基于风险的测试管理---根据特定产品的风险分配资源到测试活动。基于风险的测试管理的首要问题是测试活动是最有用的，和我们应当做其中的多少部分。举例来说，你可能使用风险作为决定的基础让四个测试人员来测试一个网站的性能和可扩展性，而只让一个人做功能测试。很酷。但是测试人员被指派给其各自的任务后会发生什么呢？难道基于风险的测试设计没有价值吗？
解决方案1：也使用风险来驱动测试设计
当我使用基于风险的测试这个词时，我的意思是包括基于风险的测试管理和基于风险的测试设计两部分。测试设计紧随测试管理其后。基于风险的测试设计是一个披露特定产品风险信息的设计测试的过程。基于风险的测试设计的首要问题是该产品是否会在我们担心他可能会出问题的样子/方向上出问题。结果是一组特定的测试来决定。
解决这种任务的一个方法是创建一个风险类（也称作缺陷分类）。在其最简单的表格上，这是一类可能会在产品中出现的缺陷列表。我指向清楚地说"缺陷"，意指任何会威胁到产品价值的东西。它可以包括错误，失败，或威胁条件。当我写风险类时，它是一个"有东西可能出错"的表单上的声明的大纲。如果我有更多的信息，如什么导致了该问题的发生或者该问题如果发生的话会有什么影响，我也许也会把它包括进来。我已经做好了风险类别，用了一整页来描述每个缺陷。
但是一般来说，我更喜欢用一个单独的句子或句子片段来表述那些风险分类说明。
凯姆.卡訥发表了一篇相当全面的风险目录分类在其书《测试计算机软件》中作为附录。但是那个目录在web时代到来之前就存在了。现在凯姆的一个在佛罗里达科技的学生，吉瑞.维佳阿拉格哈文，已将所有测试电子商务购物车有用的风险目录类放到了一起。
... ...
查看更多精彩内容，请点击下载：http://www.51testing.com/html/98/n-1298298.html
问题2："我的风险列表乱作一团"
有很多识别和分析风险的方法。我要讲一下风险分析的推理过程和他们怎样让好点子明朗起来的。但是当你与其他人这么做的时候会发生什么？然后这不不再仅仅是一个推理的过程，却也是一个社会化的过程。不同的人对该情景的表达不一样。想法常常重叠互相冲突。
我的同事布来特.皮提考德在最近的一个项目中经历过这样的事情。"我们与测试团队在会议上开始讨论风险列表"，他回想到，"我们有6个人，很快地产生了一个长长的风险列表。难的是找出怎样管理这个列表。我们要担心这个长长的列表上的东西，但是对很多项来说，我们并不十分确定要做什么。"
就像他所说的，"我们的很多项都是模糊的。一个项是"临近干扰"，意思是添加到该列表上的某些东西，但是当我们晚点再看它的时候，我们记不得了。这是什么意思？我们也有很多不同类型的事情在任务列表上出现。我们列表上的风险包括风险，也包括测试类型（如负载测试），产品性能和质量标准（如可扩展性或安全性）。我们需要一个对一个风险是什么样以及其与将要出现的其他一些问题是怎样关联的有个更精确的理解。"布莱特在这里是广义地使用"风险"这个词。
既然测试是有关发现产品中的问题，基于风险的测试是有关产品的风险。布莱特的团队列出了很多除了产品风险外的东西。现在，这是一个开头吧。头脑风暴中头脑中观点乱七八糟混作一团很正常。实际上这是一件好事。头脑风暴的核心目的在于最小化重要想法没有记录下来的几率，即使有一百个奇怪的点子也同时出现。问题是，你不能拿头脑风波的原始输出期待将他正好放入到测试计划中。"我们习惯于使用能给你一个要做事情列表的测试或缺陷列表"，布莱特说，"这样当你完成任务时，所有东西都将被一一核清。我们现难以排出怎样核清我们清单上的东西。"他的挑战是将该列表转换成某些可行的东西。
... ...
查看更多精彩内容，请点击下载：http://www.51testing.com/html/98/n-1298298.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
