测试管理之项目软件测试风险管理实践

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

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、作为测试人员,要“未雨绸缪”，从源头控风险，不要当“救火队员”

以上笔者的经历更像一张横向的知识网，创建了一个交流平台 914172719 ，群内有各种技术同行交流、学习资料、面试经验等。其中用到jenkins、docker、moutebank、python编程等，还需要花更多的精力去深入学习，当每项技能都能掌握到一定深度，才能称为一个完整的知识体系。

最后： 可以关注公众号：伤心的辣条 ！ 进去有许多资料共享！资料都是面试时面试官必问的知识点，也包括了很多测试行业常见知识，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！

好文推荐

转行面试，跳槽面试，软件测试人员都必须知道的这几种面试技巧！

面试经：一线城市搬砖！又面软件测试岗，5000就知足了…

面试官：工作三年，还来面初级测试？恐怕你的软件测试工程师的头衔要加双引号…

什么样的人适合从事软件测试工作？

那个准点下班的人，比我先升职了…

测试岗反复跳槽，跳着跳着就跳没了…