这里我想介绍的是一种全新的测试概念,该文也发表在论坛里
首先想说,我们为什么要在测试开始前做基于风险的分析?作为每个测试人员,都要明确这一点“YOU CAN NOT TEST EVERTHING!”,测试不是提高质量,而是降低风险的手段之一,如果项目团队给你的资源不充分,进度紧,OK,那我们一起来做个风险分析吧,而事实上,无论是否资源充分,我们也都需要在制定测试计划前,先做风险分析,再基于风险来制定测试策略,这样我们才能保证测试的资源是被合理而有效的利用,在这里也同样适用80/20法则,那就是说我们把测试力量的80%用在了项目风险最大的那20%功能当中。
那么这个基于风险分析的测试策略到底是如何制定呢
一、风险分析团队组建:
这时我们需要有两队人马,一队是技术专家,另一队是用户代表(不一定是最终用户、服务人员、市场人员、有经验的资深测试人员都可以担当此角色)
二、风险分析活动流程:
1、首先做需求分析,形成功能列表
2、技术专家为列表中的每一条功能进行评估、打分,至少要考虑如下几条计分项,如:人员经验(新人风险高,有经验的老员工则风险较低),是否采用新技术(全新技术风险高,复用已有技术平台则风险低),该功能的接口和与其他功能的交互性(毫无疑问的,接口和交互越多的,则风险就越高)等等,其他的可以根据需要来自我界定
3、用户代表为列表中的每一条功能进行评估、打分,至少要考虑如下几条计分项,如:失效影响(一旦失效是否有安全隐患?肯定的答案则得分高),商业价值(是否为产品的卖点),用户的使用频率(频率越高,被探测到问题的风险也就越高),如有需要还可以增加计分项
4、将各项分数统计之后,形成风险矩阵,横纵坐标分别为技术风险得分和用户代表评估风险得分,此时,就可以将功能列表中的功能项划分出四种不同的风险区间,两项得分居高的,肯定是测试重点,也是测试力度最应该投入的部分,采取的测试手段也应该是最严谨的,居中的两个区间(分别为高技术风险或者高用户代表评估风险),则可以适当投入力度和资源,风险最低的区间内可以权衡项目的QCD目标来确定要不要投入力度和资源
以上,一切取决于项目团队的集体意见,并非是测试人员一个人要考虑的问题,对于预留风险的接受情况一定是经过集体权衡出来的结果,并不是测试人员的个人职责,也就是说风险要共同分担,质量是掌握在每个人的手里,并非测试人员说了算
三、根据风险矩阵得出测试策略后,再合理分配测试资源投入情况
以上方法适用于所有的项目,并非只有紧急或者资源不足的时候才需要做,因为在任何时候,测试都需要平衡资源投入以提高效率,因为“YOU CAN NOT TEST EVERYTHING”……