知识卡片
风险要描述为可测试的失败场景
内容
笼统地说”这个系统可靠性不足”这类质量属性标签，无法判断某个行动到底有没有真正降低风险；正确的做法是把风险描述成一个具体的、可日后测试验证的失败场景，例如”当负载达到峰值时，客户体验到的用户界面延迟超过5秒”，而不是抽象的”可靠性”。这样描述之后，任何缓解措施都能被事后检验：延迟真的降到5秒以内了吗？发散：这与写单元测试断言的道理相通——”这段代码是对的”无法验证，”输入X应返回Y”才可以。
参考来源
- 位置：《恰如其分的软件架构》第3章《风险驱动模型》3.3节《风险》（源文件：_epub-src/OEBPS/text00029.html）
- 结论依据：原文指出笼统列出质量属性（如可修改性、可靠性）过于含糊无法验证是否真的缓解了风险，建议把风险描述为可测试的失败场景，并举例"当负载达到峰值时，客户体验到的用户界面延迟超过5秒"。
- 原始内容：描述风险最好达到这样的程度，即可以稍后进行测试，从而检查风险是否得以缓解。不要单纯列出如可靠性这样的质量属性，而要将可能导致失败的风险逐个描述为可测试的失败场景。