软件测试风险识别

什么是风险识别

风险的识别是基于风险的测试的起始点，后续所有的分析和决策都依赖于此项工作的成果，如果在此期间遗漏了某项重大的风险，那么在后续的测试中就得不到足够覆盖的情况，从而产品上市后也会带来巨大的隐患和不确定性。
风险识别依赖于测试人员对产品、业务和相关产业等方面的理解和认识。并没有一个确定的算法来保证找出所有的风险。

识别风险的方法

通常通过专家访谈、头脑风暴和采用风险框架或者检查表来尽量保证识别完整的风险和客观的评估优先级。通过专家访谈可以得到基本的风险列表或者对已有的风险列表进行补充，头脑风暴可以邀请相关项目组参与人，开会讨论列举出需求方关心的风险；风险框架或者检查表能提供风险识别的历史经验和尽量完整、全局的视角。

我们一般可以采用上图通用风险识别框架，再结合项目/产品本身，对第三层风险做进一步解析，比如从系统的复杂性出发，从功能的完备性、正确性等角度去思考，寻找风险点，然后再从性能效率的特性上去思考寻找风险，直到将所有的质量特性都思考一遍，就得到了下图的内容。

通用的风险识别检查表在项目中可应用，而且可以自由扩展的检查表，基于实践经验教训，不断地扩展和维护，从而形成能涵盖组织产品的完整的风险识别检查表。

质量风险类别	相关问题的描述
竞争劣势	质量上相比竞品低
数据处理质量	处理或存储或获取数据失败
日期和时间处理	在日期或时间相关的输入/输出、计算或时间处理上出现失败
灾难处置和恢复	当面临灾难时，不能进行服务/功能降级，或不能从这样的事件中恢复
文档相关	用户操作或系统管理员如何操作系统的说明写得不清楚
错误处理和恢复	由于出现异常情况而导致系统崩溃无法恢复
功能相关	某个功能不能工作
安装、配置、升级和合并	部署系统失败，数据合并失败，能否升级/降级，升级/降级后的副作用，意外安装不合适的软件或模块等
互操作	在主要模块、子系统外部系统之间的交互发生失败
本地化	在某种特定的地区、语言、消息、税率、操作习惯和时区中出现失效
网络和分布式	不能处理网络或分布式请求，比如严重的延迟、丢包、资源被占用等导致的失败
操作和维护	备份/恢复操作影响到了运行中的系统
打包/发布	打包失败或发布渠道出现问题
性能	无法承担期望要求的负载量
移植、配置和兼容	在声称支持的某些版本的系统上失败不能工作
某些声称支持的系统配置下不能正常工作
可靠性	不能达到持续长时间稳定运行
信息安全和隐私	不能保护系统，不能避免非法的数据访问
标准一致性	与强制标准冲突
状态和迁移	不能对一系列的操作进行及时的、正确的响应
用户界面和可用性	忽视人的因素尤其是用户界面的操作

我们还可以从一下方面获取识别风险：

• 各种规格说明书
• 实现的细节
• 销售、市场资料
• 竞争对手的研究
• 独立评估机构
• 过去历史项目
• 个人的历史经验

在这个阶段多花些精力能大大减少后续返工，甚至是风险出现时造成的经济损失。但也需要注意的是，识别风险和软件测试工作一样，是不可穷尽的，要避免将测试活动阻塞在无穷尽的风险识别上。可以通过固定工时的做法，固定安排风险识别的工作时间。在项目结束后，要注意复盘积累在测试计划阶段未能识别的一般性风险，并将其加入到检查表中。

学习技术交流群：704807680