如何制定基于风险的测试策略？

这里我想介绍的是一种全新的测试概念，该文也发表在论坛里

地址为：http://bbs.51testing.com/thread-145131-1-1.html

首先想说，我们为什么要在测试开始前做基于风险的分析？作为每个测试人员，都要明确这一点“YOU CAN NOT TEST EVERTHING!”，测试不是提高质量，而是降低风险的手段之一，如果项目团队给你的资源不充分，进度紧，OK，那我们一起来做个风险分析吧，而事实上，无论是否资源充分，我们也都需要在制定测试计划前，先做风险分析，再基于风险来制定测试策略，这样我们才能保证测试的资源是被合理而有效的利用，在这里也同样适用80/20法则，那就是说我们把测试力量的80%用在了项目风险最大的那20%功能当中。

那么这个基于风险分析的测试策略到底是如何制定呢
~JxP!_!J3Ki0一、风险分析团队组建：
0[#lVG ?V0这时我们需要有两队人马，一队是技术专家，另一队是用户代表（不一定是最终用户、服务人员、市场人员、有经验的资深测试人员都可以担当此角色）
P0@*U5HPZ"x` g0二、风险分析活动流程：51Testing软件测试网SqB+s`;Z6nOrP/Q
1、首先做需求分析，形成功能列表51Testing软件测试网#Zl/rK9L7u(|D e:?.e
2、技术专家为列表中的每一条功能进行评估、打分，至少要考虑如下几条计分项，如：人员经验（新人风险高，有经验的老员工则风险较低），是否采用新技术（全新技术风险高，复用已有技术平台则风险低），该功能的接口和与其他功能的交互性（毫无疑问的，接口和交互越多的，则风险就越高）等等，其他的可以根据需要来自我界定
/b@(df#M!ns03、用户代表为列表中的每一条功能进行评估、打分，至少要考虑如下几条计分项，如：失效影响（一旦失效是否有安全隐患？肯定的答案则得分高），商业价值（是否为产品的卖点），用户的使用频率（频率越高，被探测到问题的风险也就越高），如有需要还可以增加计分项
%q+\b)NT#k%[+D04、将各项分数统计之后，形成风险矩阵，横纵坐标分别为技术风险得分和用户代表评估风险得分，此时，就可以将功能列表中的功能项划分出四种不同的风险区间，两项得分居高的，肯定是测试重点，也是测试力度最应该投入的部分，采取的测试手段也应该是最严谨的，居中的两个区间（分别为高技术风险或者高用户代表评估风险），则可以适当投入力度和资源，风险最低的区间内可以权衡项目的QCD目标来确定要不要投入力度和资源
|5gi$w2^9LZb0以上，一切取决于项目团队的集体意见，并非是测试人员一个人要考虑的问题，对于预留风险的接受情况一定是经过集体权衡出来的结果，并不是测试人员的个人职责，也就是说风险要共同分担，质量是掌握在每个人的手里，并非测试人员说了算
Ht k.}.[Y"L0三、根据风险矩阵得出测试策略后，再合理分配测试资源投入情况
+a+RAMF1IVYS0以上方法适用于所有的项目，并非只有紧急或者资源不足的时候才需要做，因为在任何时候，测试都需要平衡资源投入以提高效率，因为“YOU CAN NOT TEST EVERYTHING”……
\3N\!L-pN^~0