软件风险评估.doc

设计方面:
风险:(1)没有详细设计说明书;
解决方案:测试人员要在开发阶段对相关设计及需求文档进行分析,对大体模块功能进行分类,分析业务逻辑,在不清楚的地方及时与开发人员沟通。
风险:(2)没有统一的界面设计规范。
解决方案:与项目负责人确认测试标准。
开发方面:
风险:(1)所有模块开发没有统一设计,开发人员有自己的设计方式;
解决方案:与项目负责人确认标准方式,与标准方式不一致的地方全部以BUG形式提交。
风险:(2)需求变更开发。
解决方案:建议将需求变更形成文档,对没有文档的需求变更,在测试过程中发现及时与开发负责人确认,并存档相关变更文档。
测试本身:
风险:(1)人力资源;
解决方案:保证稳定的人员安排。
风险:(2)硬件资源;
解决方案:事先分析测试所需硬件资源,及时申请,保证测试工作顺利进行。
风险:(3)版本控制;
解决方案:严格控制版本,BUG以版本为单位进行提交。在测试过程中及BUG确认阶段禁止任何代码更新。
风险:(4)测试时间不足。
解决方案:动员测试人员完成测试任务,必要时,应给予相应物质奖励。
测试风险是不可避免的、总是存在的,所以对测试风险的管理非常重要,必须尽力降低测试中所存在的风险,最大程度地保证质量和满足客户的需求。在测试工作中,主要的风险有:
一、质量需求或产品的特性理解不准确,造成测试范围分析的误差,结果某些地方始终测试不到或验证的标准不对;
二、测试用例没有得到百分之百的执行,如有些测试用例被有意或无意的遗漏;
三、需求的临时/突然变化,导致设计的修改和代码的重写,测试时间不够;
四、质量标准不都是很清晰的,如适用性的测试,仁者见仁、智者见智;
五、测试用例设计不到位,忽视了一些边界条件、深层次的逻辑、用户场景等;
六、测试环境,一般不可能和实际运行环境完全一致,造成测试结果的误差;
七、有些缺陷出现频率不是百分之百,不容易被发现;如果代码质量差,软件缺陷很多,被漏检的缺陷可能性就大;
八、回归测试一般不运行全部测试用例,是有选择性的执行,必然带来风险。
前面三种风险是可以避免的,而四至七的四种风险是不能避免的,可以降到最低。最后一种回归测试风险是可以避免,但出于时间或成本的考虑,一般也是存在的。
针对上述软件测试的风险,有一些有效的测试风险控制方法,如:
测试环境不对可以通过事先列出要检查的所有条目,在测试环境设置好后,由其他人员按已列出条目逐条检查;
有些测试风险可能带来的后果非常严重,能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕,在某个不是很重要的新功能上发现一个严重的缺陷,如果修正这个缺陷,很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大,对策是去掉(Diasble)那个新功能,转移这种风险;