目录
一、风险分析
在软件测试中，我们按照一个常识性的过程来理解风险。
哪些事件需要担心?
这些事件发生的可能性有多大?
一旦发生，对公司产生多大影响?
一旦发生，对客户产生多大影响?
产品具备什么缓解措施?
这些缓解措施有多大可能会失败?
处理这些失败的成本有哪些?
恢复过程有多困难?
事件是一次性问题，还是会再次发生?
影响风险的因素很多，试图精确地、定量地计算风险比缓解风险还要麻烦。在大厂，我们确定了两个要素：失败频率和影响。测试人员用这两个要素给每项能力打分。我们发现，风险实际上是一个定性的相对值，而非一个定量的绝对值。风险分析的目标不是要给出一个精确的值，而是要识别一个能力与另一个相比风险是大是小，这对于决定以何种顺序测试哪些能力足够了。
二、按照风险发现的频率划分
罕见：发生故障的可能性很小，发生问题后的恢复也很容易。
少见：在少数情况下会发生故障，但是在使用场景复杂度不高的情况下或使用率较低的情况下，发生的可能性非常小。
偶尔：故障的情形容易想象、场景有点复杂，而该能力是比较常用的。
常见：此能力所属的特性使用量大、复杂度高、问题频发。
三、项目相关干系人对风险的评估
开发人员：
大多数开发人员在被征求意见的时候，都会给自己负责的特性选择最大的风险，因为他们希望自己写的代码得到充分的测试。经验表明，开发人员对自己负责的特性的风险估计过高。
项目经理：
PM也是常人，也会有自己的偏见。在对能力点重要性的评判上，他们当然有自己的偏好。通常来说，他们喜欢那些使得软件能从竞争产品中脱颖而出引人注目的特性。
销售人员：
销售岗位本来就是要吸引用户的，因此他们会对那些有卖点、演示起来很拉风的特性更感兴趣。
总监和 VP：
管理层经常会更加注意那些使软件有别于主要竞争对手产品的特性。
显然，所有利益相关人员都有明显的偏好，因此我们的办法就是征求所有人的意见，请大家各自给前面所述的失败频率和影响指标打分。并不总是轻而易举地就能吸引大家的参与，不过我们发现了一个成功的策略。我们并不需要跟他们解释这个流程然后说服他们来帮忙，只要自己完成然后把热图展示给他们就行了。一旦他们发现其中的偏差，自然就会提出自己的意见。开发人员知道这个热图会被用来决定测试的优先级，因此参与度很高，项目经理和销售人员也是一样，质量对大家都很重要。
这个方法很给力，我们自己确定风险所得到的结论，毫无疑问会被质疑。在将风险分析结果作为随后测试的依据展示给大家的时候，我们实际上是树了一个靶子供大家争论。这就是重点:与其询问他们关于某个模糊概念的看法，不如拿一个明确的结论来引起辩论。通常来说，都是排除容易下定义难。除此之外，我们还会避免让每一个人都去查看他们其实不感兴趣或不理解的数据。这个小策略使得我们通常能得到大量有效的输入纳入风险计算。
四、风险的化解
风险不大可能彻底消除。驾驶有风险，但我们仍然会开车出行；旅游有风险，但我们并没有停止旅游。通常情况下，风险并没有真的变成伤害。为什么呢？因为我们会以实际行动缓解风险。例如，我们会避免在一天的某个时间驾车出行，避免到一些地方旅行，这就是缓解。
就软件而言，一种极端的缓解办法是去掉风险最大的组件:交付的软件越少，风险越小。但是，除了彻底的风险消除，还有很多措施可以缓解风险：
我们可以围绕风险大的能力点编写用户故事，并从中确定低风险的使用场景，然后反馈到开发团队，请他们有针对性地增加约束。
我们可以编写回归测试用例，以确保问题在重现时可以被捕捉到。
我们可以编写和运行引发故障的测试用例，来推动开发实现恢复和回滚的特性。
我们可以插入监听代码，以便更早地检测到故障。
我们可以插入代码监听软件，发现新旧版本间的行为变化以发现回归问题。
具体的缓解措施很大程度上取决于应用本身以及用户对于安全性的期望。测试人员可能会参与到实际的缓解过程，但更主要的工作是暴露风险。那些标记为红色的能力点比黄色和绿色要优先处理，按照风险顺序进行测试。原则是：如果不能全测，就先测最重要的，也就是风险最大的。
对于风险较低的能力点，可以降低些要求。我们可能会做出判断：为较低风险的领域编写特定的测试用例是得不偿失的。我们可能会选择进行探索式测试，或者使用众包去测试这些领域。
标签：风险,开发人员,特性,聊一聊,测试,缓解,我们 From： https://blog.csdn.net/qd_lifeng/article/details/142207810