软件测试过程当中应注意的风险

在编写测试计划的时候要考虑可能发生的风险，并提出应对措施。那么到底都有哪些风险要注意呢?如何解决呢?如下列出了一些方案：

　　设计方面：

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

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

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

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

　　开发方面：

　　风险：(1)全部模块开发没有统一设计，开发人员有本身的设计方式;

　　解决方案：与项目负责人确认标准方式，与标准方式不一致的地方所有以BUG形式提交。

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

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

　　测试自己：

　　风险：(1)人力资源;

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

　　风险：(2)硬件资源;

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

　　风险：(3)版本控制;

　　解决方案：严格控制版本，BUG以版本为单位进行提交。在测试过程当中及BUG确认阶段禁止任何代码更新。

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

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

　　测试风险是不可避免的、老是存在的，因此对测试风险的管理很是重要，必须尽力下降测试中所存在的风险，最大程度地保证质量和知足客户的需求。在测试工做中，主要的风险有：

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

　　2、测试用例没有获得百分之百的执行，若有些测试用例被有意或无心的遗漏;

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

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

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

　　6、测试环境，通常不可能和实际运行环境彻底一致，形成测试结果的偏差;

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

　　8、回归测试通常不运行所有测试用例，是有选择性的执行，必然带来风险。

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

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

　　测试环境不对能够经过事先列出要检查的全部条目，在测试环境设置好后，由其余人员按已列出条目逐条检查;

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

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

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

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

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

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

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

　　对全部工做多进行互相审查，及时发现问题，包括对不一样的测试人员在不一样的测试模块上相互调换;

　　对全部过程进行平常跟踪，及时发现风险出现的征兆，避免风险。

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