风险测试可谓是一项困难的技术，既须要预估可能导致一件产品发生故障的原因及后果的严重程度，还要开发执行测试用例来证实该产品是否真的会由于这个原因而发生故障。这个过程在特定的开发环境中执行起来会更加困难，因为还要顾虑到时间、资源的压力，以及可能存在的各种各样不同的观点。尽管如此，这还是一项值得深究的技术。因为它关注风险，将精力集中于测试任务的重心，即快速发掘重要问题。
通过我个人经验总结，发现测试人员和测试经理在运用风险测试方法的时候常会碰到类似的问题。就像下面四个典型问题，让我们一起来解决它们。
问题1：“每个人都认为风险测试属于管理范畴。”
我经常听到有人讨论风险测试的时候将重点仅仅局限于风险测试管理--如何根据产品风险来决定测试策略--怎样的测试活动是最有效的，以及我们应该执行到什么程度才算合适。例如您可能根据风险决定了人员的分工--四个测试人员执行网站的性能和扩展测试，仅一人执行功能测试。尽管这可能是个好策略，但是仅根据这点，测试人员知道怎么做吗？是否有必要进行风险测试设计呢？
解决方法 1：同样基于风险进行测试设计
我认为风险测试不仅包括风险测试管理，还包括风险测试设计。
进行测试设计的时间点位于管理之后。它是一个测试用例设计的过程，用于挖掘特定产品风险的相关信息。重点关心的是产品是否会像我们所担心的那样，由于某种原因而真的碰到故障。输出结果是一系列的测试用例。
完成这一任务的其中一种方法就是建立一份风险目录（也可称之为 Bug 分类）。这是一张很简单的表格，列有产品可能碰到的各种种类的 Bug。我所说的 Bug，即指任何可能威胁到产品价值的东西，包括故障、失败，或线程环境。我编写风险目录常用的格式是“[什么]可能导致[什么]”。如果我有更多的信息，如导致问题的原因，或问题可能受到何种因素影响等，我都可能将其做到目录里面去。当我针对每个风险都进行了一番详细描述后，这个目录就算完工了。但是通常情况下我更偏向于使用简单的短语，或词组碎片来进行风险描述。
Cem Kaner 发行过一本名为 Testing Computer Software（测试电脑软件）的书，其附录内有一份非常详尽的风险目录。但该目录所列内容未能涵盖后期的网络时代。之后， Cem 的一位学生， Giri Vijayaraghavan，对原有的目录进行了补充，加入了一部份非常实用的风险目录，该部分目录是专门针对电子商务网站购物车进行测试的，其中包括有以下几项：
……………………
查看全文请点击下载：http：//www.51testing.com/html/29/n-120029.html
问题3：“我项目组内没有人愿意讨论风险。”
风险是可怕的。如果您是一个设计者，且刚刚成功说服大家在产品中使用一项未经试验的新技术，您可能就不愿意当众承认其可能带来的风险。如果您是一个客户，可能不愿意听到您即将使用的产品存在很多风险。如果您是公司法务，您可能会因为风险目录而惶惶不安，唯恐其会引来一张法院传票。我曾经见到有些高层管理人员希望，且假设所有的风险都处于“已管控”状态，其实“已管控”就意味着这些风险已经被排除了。
让人们去直面风险可能是件困难的事情。即便他们能够面对，让他们在某个理性团队内讨论风险也是很难的。您很有可能被看成“消极派”，形成误解。
解决方法 3：将注意点从风险转移到选择
不可能对所有东西进行同样程度的测试。即使您能做到，也会花费大量人力、物力。风险测试人员的标语是：让我们做出明智的选择。
如果人们都不喜欢讨论风险，好吧，那就讨论选择。没有人可以逃避选择。我们应该测试什么？需要进行怎样的测试？为什么针对这个需要进行更多的测试？除了勉强人家来讨论风险外，还可以来讨论一下这些问题。
另一种策略是独自进行风险分析，然后宣布您选择测试些什么。仔细聆听管理人员和开发人员的反应。这就是“石头汤”的方法--先假装煮石头来诱使人家提供煮汤的原料，最终成就一锅鲜汤。如果人们可以对我的风险目录发表想法，或是来反对我的选择，我就能得到更多关于风险的信息。
……………………
查看全文请点击下载：http://www.51testing.com/html/29/n-120029.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
