在软件测试活动中，作为一名测试人员有没有遇到过这样的场景，在测试一个特性或者制定一份测试方案时，往往会想着进行简单测试、做简单设计，认为

　　1、这个场景出现的概率太低，几乎不可能会存在，不测了

　　2、实际应用时不可能会有这么大的用户量，不用考虑

　　3、在这个时间段应该不可能会有这么大的业务量

　　4、同一时刻不可能会存在多种业务并发上来

　　但版本发布上线后，实际应用时之前认为的那些小概率事项，结果确往往就是会出现，这是为什么呢？管理学中有一个定律——墨菲定律；这个定律指出，当事情有变坏的可能，不管可能性有多小，他总是会发生；

　　在具体的研发测试中，当测试过程、测试交付存在潜在风险导致出现不好的结果时，我们需要如何做好全方位的准备？积极的应对，避免不好事情造成的影响或把影响降到最低；结合当前项目运作，分享下当前项目过程中对于测试风险控制的实践过程。

　　一、认识风险

　　在项目活动中风险是指项目活动过程中的一种不确定的事件或条件，一旦发生会对具体的项目的单个或者多个目标产生影响，例如：

　　·研发过程中，特性需求临时变更，代码修改，但测试时间不足，存在质量风险

　　·版本交付，存在外部依赖不满足，交付受阻；

　　·版本测试，测试工作量估算不合理，测试不充分

　　这些交付过程中存在的动态的、静态的、已知的、未知的不确定性因素影响测试交付目标，无法满足外部市场需要；那如何做呢？

　　二、风险管理

　　在项目的测试活动过程中，我们通过一系列风险控制活动对不确定因素进行及时识别、有效评估、积极应对，以保证项目测试活动的正常进行，从而达到价值交付；

　　1.风险识别：

　　在风险识别阶段通过树立团队整体的风险意识，大家一起讨论制定风险识别维度、在对应的研发阶段、利用一定的工具方法进行风险数据收集，从而进行有效识别。

　　1)风险识别维度

　　根据项目的实际运作团队讨论，通过收集如下四个维度的信息作为风险识别的输入，来进行识别

　　项目：项目的维度主要考虑：

　　·项目规划需求的计划：在项目迭代开始初期，规划的需求内容、提交的计划点；如果在过程中发生需求加塞、提交计划变更和一开始的计划出现偏差，则作为风险进行及时上报；

　　·相关的制约因素：是否存在对外部依赖，比如对外围的软硬件版本存在依赖，需要提供后，集成完成才能满足交付条件；

　　·里程碑时间点：时间点要求也是一个识别依据，临近里程碑时间点，现状和目标存在较大偏差；

　　·工作量的估算；工作量估算的合理性，有些是项目强行压下的，存在较大的工作量偏差；

　　·以及隐形因素项目内各团队之间的合作协作关系

　　资源：资源的维度主要考虑人力资源是否充分，设备环境资源是否能满足相应的测试活动；比如组网场景、容量上对资源的要求，是否具备；

　　技术：技术的维度主要考虑当前是否存在新领域不熟悉、所需的技能存在盲区。

　　质量：质量维度主要是要了解确认对任务质量的要求，是仅满足预研穿刺基本测试，还是需要按交付标准的DOD严格执行，以达到交付要求；

　　2)风险识别阶段

　　风险识别活动贯穿在整个测试活动的始终，从测试SE参与需求分析开始、编写测试策略、跟踪特性实现过程、交付系统测试以及其他（维护）各阶段都需要识别；

　　3)风险识别方法

　　·专家判断：了解项目和业务各领域的人员，考虑单个风险的方方面面，以及整体项目风险的各来源；

　　·头脑风暴：参考一定的风险识别维度，进行相关的脑暴；

　　·访谈：对领域专家、资深参与者访谈；

　　·会议讨论：团队成员对当前所承接的任务，观察了解到的信息进行专门的会议讨论，审查识别的风险；

　　·风险检查单：各阶段的风险点，用作提醒（坚持单及时审查，定期更新调整）

　　风险识别经验小结：

　　1、团队树立风险意识，鼓励所有人相关人员参与风险识别

　　2、除了显性可见风险，同时也要注意隐性的团队协作，氛围的风险

　　2.风险评估

　　通过有效描述风险，明确风险类别后合理定义风险级别来评估风险，以确认风险影响以及为后续的风险应对措施提供依据；

　　1)风险描述：

　　风险包含起因、时间、概率及影响四要素，在了解风险4要素后，使用结构化SQCA描述方法，把风险本身与风险愿意及风险影响区分开来，描述清楚；

　　S(Situation):背景起因

　　C（Complication）:事件冲突

　　Q（Question）：问题影响

　　A（Answer）;答案

　　描述结构化方式：在某个背景（起因）之下，遇到了复杂（事件）情况，产生了什么样的（问题）影响，然后我们如何去解决它（答案）

　　其中风险描述中风险影响和解决方案是关键，建议描述要领：

　　·Q（问题影响）：描述清楚波及的范围、问题的重要、紧迫程度

　　·A（解决方案）：遵循3W原则，解决方案具体内容，包含所需要的资源等（What）、具体的责任主体（Who），由谁负责解决、期望解决的具体时间点（When）

　　·风险描述案例：

　　·技术风险描述举例：

　　随着公司业务的快速发展（S），我们的IT系统无法满足现状产品的需求（C），这将导致我们无法满足我们的客户（Q），当务之急的应对措施是需要***立刻安排升级IT系统（A）

　　·质量风险描述举例：

　　临近迭代交付（S），测试自动化无法稳定运行（C），导致守护不完善，存在质量风险影响发布（Q），当务之急***尽快在迭代交付前完成自动化执行守护修复（A）

　　2)风险分类

　　在有效的描述清楚风险后，进行风险分类，明确风险类别；这个过程主要是便于把注意力和精力集中到风险最大的领域，或者针对一组相关的风险制定通用的风险应对措施，从而更有效的开展应对；

　　·按风险来源分：技术风险、管理风险、外部风险、内部风险等

　　·或者按受影响的项目工作分：方案设计、编码实现、验收测试等

　　目前我们项目运作过程中，风险分类主要还是以风险的来源来分，根据分类出的风险，发现外部依赖类风险占据比例较高，针对此类风险讨论通用的应对措施，比如通过一开始的协作规划项目计划来约束、过程中每日的日报、周报来跟踪外部依赖提供的进展等

　　3)风险定级

　　在描述清楚风险、做好分类后，团队根据具体的研发过程，对风险偏好和风险临界讨论制定风险影响和概率的定义，从而进行风险定级评估；

　　比如通过风险出现的概率情况、对测试目标的影响程度来综合判断风险级别，具体定级示例：

　　根据定级结果，高以上风险：立即行动 ；中风险：立即关注；低风险：定期关注

　　3.风险应对：

　　在风险评估定级完成后，进行对应的风险应对；在实际的项目运作过程中根据不同的场景，采用不同的应对措施；

　　·风险上报：当超出个人或团队处理的能力时，需要进行风险上报，一般风险级别为高以上类风险；比如涉及到外部依赖类风险，需要项目协调，否则版本无法正常集成制作；通过面对面、电话沟通、或者日报周报的方式上报反馈；

　　·风险规避：发生的概率较高，具有严重负面影响的高优先级风险；比如在临近版本发布时，某些特性由于测试不充分，波及不明确，合入后存在对现有商用版本存在未知隐患，通过裁剪、调整特性合入周期来规避版本发布质量风险；

　　·风险转移：应对风险，把责任外包给第三方；比如在研发过程中，对于新领域不熟悉，但第三方存在成熟的技术，可以通过购买服务、签约合同；和第三方达成合作，把风险转移第三方；

　　·风险减轻：降低风险出现的概率和影响；比如在临近版本发布时，合入了故障，但该故障的波及范围交广，测试又不充分；经过分析故障影响，回退合入故障，来规避影响；

　　·风险接受：对于低优先级的风险或者其他任何策略已无法加以应对；

　　三、经验总结

　　最后的话：

　　1、测试过程中，当好测试“操盘手”，综合进行风险控制，做好全方位准备，积极应对，避免或降低坏事出现后造成的影响；

　　2、加强团队风险意识，风险管理控制需要全员参与

　　3、作为一名优秀的测试人员养成风险数据收集、整理、分析习惯；

　　4、善于总结经验，练就一副识别风险的“火眼金睛”

　　5、作为测试人员,要“未雨绸缪”，从源头控风险，不要当“救火队员”

作者：梧桐苑落   

来源：51Testing软件测试网原创