李敬林

【摘要】随着移动互联网业务的急速发展，软件测试项目的管理也日新月异，传统的测试项目管理方式也随之接受新的挑战。业务需求讯息万变，开发测试周期缩短，敏捷开发，先商用再优化，各种各样的新模式，新问题随之而来摆在测试管理者和工程师面前，如何应对这些新问题，新风险呢？ 这就是此文需要阐述的。

【关键字】 移动互联网 软件测试 风险管理

引言

本文将从风险识别，风险影响评估，风险处理，风险监控四个方面来阐述测试项目的风险管理的观点和概念。

我们先看看如何识别风险。首先，我们搞清楚什么样的问题可以上升为风险，风险分为哪几种类型。我们先看下面一个风险描述的例子：

一般来说，风险包括这么几个要素，它属于那种类型的，具体问题是什么，级别高低，谁负责跟踪处理，当前状态如何，还有应急措施是什么。

对应互联网测试项目来说，风险的类别从来源来看，一般可以分为这么几类：需求变更，测试人力，测试环境（软件和硬件），测试周期，沟通协调，流程制度，缺陷管理。

当我们知道风险包括了哪些要素和风险的分类后，我们就可以在项目中发现和识别那类的问题需要列为风险对象进行管理。

我们先看需求变更类的风险，在移动互联网项目中，来自客户业务发起方的需求往往变化比较快，比如说，为了在某个节日举行营销活动，需要推出一款新的产品和业务，需要在软件层面进行配合实现，当销售市场部决定需要定制软件或者修改软件实现时，往往留给后台研发人员的时间已经比较少，时间带来风险压力是不容置疑的。

对于此类风险，我们应该及时和市场业务部获取最新的策略信息，从而根据当前测试人力和设备资源做好准备，同时要根据自己测试能力进行客观评估，哪些功能需求是必须实现的，哪些功能需求是可选的，必须实现的功能需求里哪些功能是最重要的。在这里，可以通过建立需求跟踪矩阵，确定功能实现的优先级，然后在短时间内实现最重要最有价值的功能需求。

另外，还有测试人力类的风险，这一类风险一般是多个测试项目同时启动，测试人力需求在短期内剧增，或者是测试的核心骨干请假等情况。我们在测试人员的管理和复用上，往往都是一个测试人员从事多个项目或者多个业务的测试，若多个项目同时开展就会出现此类问题。 对于此类风险，我们在做测试计划时就可以预见并识别，并纳入到我们的风险管理表中。

同时，我们应该提前做好测试人力资源的储备，培养一些备用的测试人力。测试团队组成应该是有一定梯度的，骨干，普通测试人员和新手都要有人员。这样，当测试人力需求高峰期来临时，就可以充分的灵活应对。另外，在测试人员技能培养方面，也需要注意全面的发展和学习，可以建立测试人员的技能树，记录每个测试人员的对产品测试的掌握程度，利用项目的间歇期让测试人员进行自我的学习和练习，最后让其实现技能的全面发展。

下面我们再看看测试环境（软件和硬件）类的风险，这类风险主要来源于测试硬件设备和软件工具，license等。测试硬件设备容易理解，这里就包括了功能测试设备，性能测试设备，硬件设备的配置是否跟硬件需求匹配，数量是否足够完成。

软件类的就包括功能测试仿真工具，性能测试工具，数据库，中间件和第三方软件的license，这些都归纳为测试软件环境带来的风险。例如，某个项目需要使用oracle数据库，但是license有效期将要结束，需要采购部门配合购买新的license。

还有，某个项目需要性能测试，但是现有的业界性能测试工具没法满足，需要开发一个适合本项目本产品的性能测试工具或者脚本，这些都是风险点所在。

在测试项目管理的过程中，我们需要全面考虑测试的软硬件需求，从繁杂的项目管理中发现此类影响测试工作开展的风险问题。

鉴于篇幅的原因，后面还有测试周期，沟通协调，流程制度和缺陷管理类的风险就不再一一阐述了。然后我们看看如何评估风险的影响范围。

以文章开头第一个风险例子为例，我们看看如何评估具体某个风险的影响范围。例如性能测试设备到位比较晚，那么就可能影响性能测试和调优的启动的时间点，而一般产品发布都要求完成性能测试且性能指标达到要求，那么这个问题的影响范围估计就是产品的发布。

这个影响范围有时候不仅仅是项目内部的，还可能是项目外部的，例如，由于整个项目延期，测试人员没法及时释放，导致其他项目的测试受到影响，这也是风险的影响范围。

我们在做风险评估的时候，要秉着客观的态度，实事求是，这样，我们做出的评估判断才比较客观实在，也比较让项目组成员和公司领导接受。另外，这个影响范围也决定了风险的级别，让大家在茫茫的项目风险列表里找出重点解决的问题。

对于风险的影响范围，有的影响仅限于测试组内的，有的会影响到开发组和需求组，设计组和客户验收，比如产品的系统测试完成时间延期，会影响客户的验收，产品的发布时间，从而对采购验收也产生影响，所以，当我们评估时，需要考虑问题对项目组每个团队小组的影响，以便其他团队成员做好相应的准备和应对措施。

下面，我们谈谈风险的处理。当我们识别了风险，评估了风险的影响范围后，我们就需要着手处理风险。再以第一个例子为例，当我们发现性能测试设备到位时间比较晚，影响性能测试的执行后，我们该怎么办呢？ 是被动的等待，还是积极的想其他办法，将风险降低到最小的影响吗？ 当然不是，在这个例子中，项目组成员讨论后，决定我们可以采用配置较低的设备先进行性能测试，提前发现一些基本的性能问题，待符合规格的硬件设备到位后再次进行性能测试，虽然前期的性能测试没有在标准的服务器进行测试，但是这样测试会提前完成测试脚本的开发，测试工具的准备，统计脚步的准备。

而且，虽然设备配置跟商用不完全一致，也有可能发现一些常见的性能问题，可以提前发现并解决，这样，为后面用标准服务器的测试打下了铺垫，扫除了一些障碍。

我们再看看一个人员方面的风险处理，也就是制订应急措施。

例如，某个业务线需要规划一个大版本，修改商用环境出现的各类问题，依据测试人员的技能和熟悉程度，我们安排测试人员A负责版本的回归测试，A一直负责这个产品业务的测试，是最熟悉此产品的测试人员。可是，第一个版本测试到一半时，A提出了离职申请，问题单已经验证了一半，还有的问题是验证不通过，返回给开发重新修改了。上线时间已经确定了，版本测试剩余时间不多了，质量和进度风险明显的出现了，怎么办？

在此情况下，我们第一步是找一个对此业务相对熟悉的人接替A，例如测试人员B， A已经完成了第一轮的测试，有的问题单已经验证过一次，虽然如此，我们还是需要B把已经验证的问题单重新验证一次，同时把相关案例再跑一次，这样比较稳妥一点。同时，召集开发，测试一起，对所有的问题单重新梳理一次，分析每个问题单的修改点，哪些地方已经修复，哪些地方还需要继续修改，做好会议记录和会后的问题跟踪。

当然，A测试人员还不能立马离开，需要待B完全接手版本测试才可以离职。由于现在软件外包服务比较常见，研发人员的变动是常见事情，所以我们尽量在某些产品业务上储备2-3个核心的测试骨干，以便应对这种人员变动带来的风险。

另外，若测试人员要离职，其工作质量是有所影响的，因为他（她）往往已经身在曹营心在汉，需要对其工作质量进行一个补充检查。

最后，我们来谈谈如何监控管理风险。首先我们需要建立一张风险控制的跟踪表，如文章开始所列的例子，记录每个风险点的内容，影响范围和状态，同时要给每个风险分配责任人，也就是谁负责跟踪解决此问题，推动问题的解决，更新风险的状态和最新信息。

综上所述，我们在参与移动互联网测试项目时，需要学会识别风险点，评估风险的影响范围，制订风险的应对措施，然后对所有风险进行跟踪和监控，达到高质量高效率的测试管理效果。