软件风险评估

设计方面：

风险： (1) 没有详细设计说明书 ;

解决方案： 测试人员要在开发阶段对相关设计及需求文档进行分析， 对大体模块功能进 行分类，分析业务逻辑，在不清楚的地方及时与开发人员沟通。

风险： (2) 没有统一的界面设计规范。

解决方案：与项目负责人确认测试标准。

开发方面：

风险： (1) 所有模块开发没有统一设计，开发人员有自己的设计方式 ;

解决方案：与项目负责人确认标准方式， 与标准方式不一致的地方全部以

风险： (2) 需求变更开发。

解决方案： 建议将需求变更形成文档， 对没有文档的需求变更， 在测试过程中发现及时 与开发负责人确认，并存档相关变更文档。

测试本身：

风险： (1) 人力资源 ;

解决方案：保证稳定的人员安排。

风险： (2) 硬件资源 ;

解决方案：事先分析测试所需硬件资源，及时申请，保证测试工作顺利进行。

风险： (3) 版本控制 ;

解决方案：严格控制版本， BUG以版本为单位进行提交。在测试过程中及

BUG确认阶段

禁止任何代码更新。

B

风险： (4) 测试时间不足。

解决方案：动员测试人员完成测试任务，必要时，应给予相应物质奖励。

测试风险是不可避免的、 总是存在的， 所以对测试风险的管理非常重要， 必须尽力降低 测试中所存在的风险， 最大程度地保证质量和满足客户的需求。 在测试工作中， 主要的风险 有：

一、质量需求或产品的特性理解不准确， 造成测试范围分析的误差， 结果某些地方始终 测试不到或验证的标准不对 ;

、测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏

三、需求的临时 / 突然变化，导致设计的修改和代码的重写，测试时间不够 ;

四、质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智 ;

五、测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等 ;

六、测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差 ;

七、有些缺陷出现频率不是百分之百， 不容易被发现 ; 如果代码质量差， 软件缺陷很多， 被漏检的缺陷可能性就大 ;

八、回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。

前面三种风险是可以避免的， 而四至七的四种风险是不能避免的， 可以降到最低。 最后 一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。

针对上述软件测试的风险，有一些有效的测试风险控制方法，如：

测试环境不对可以通过事先列出要检查的所有条目， 在测试环境设置好后， 由其他人员 按已列出条目逐条检查 ;

有些测试风险可能带来的后果非常严重， 能否将它转化为其他一些不会引起严重后果的 低风险。 如产品发布前夕， 在某个不是很重要的新功能上发现一个严重的缺陷， 如果修正这 个缺陷， 很有可能引起某个原有功能上的缺陷。 这时处理这个缺陷所带来的风险就很大， 对 策是去掉 (Diasble) 那个新功能，转移这种风险 ;

有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在， 我们就要通过提高测试用例的覆盖率 ( 如达到 99.9%)来降低这种风险 ;

为了避免、 转移或降低风险， 事先要做好风险管理计划和控制风险的策略， 并对风险的 处理还要制定一些应急的、有效的处理方案，如：

在做资源、时间、成本等估算时，要留有余地，不要用到 100%;

在项目开始前， 把一些环节或边界上的可能会有变化、 难以控制的因素列入风险管理计 划中 ;

对每个关键性技术人员培养后备人员， 作好人员流动的准备， 采取一些措施确保人员一 旦离开公司， 项目不会受到严重影响，仍能可以继续下去 ;

制定文档标准，并建立一种机制，保证文档及时产生 ;

对所有工作多进行互相审查， 及时发现问题， 包括对不同的测试人员在不同的测试模块 上相互调换 ;

对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。

要想真正回避风险，就必须彻底改变测试项目的管理方式 ; 针对测试的各种风险，建立 一种“防患于未然”或“以预防为主”的管理意识。 与传统的软件测试相比， 全过程测试管 理方式不仅可以有效降低产品的质量风险， 而且还可以提前对软件产品缺陷进行规避、 缩短 对缺陷的反馈周期和整个项目的测试周期。