码迷,mamicode.com
首页 > 其他好文 > 详细

浅谈软件测试风险管理

时间:2015-11-20 17:22:55      阅读:294      评论:0      收藏:0      [点我收藏+]

标签:

摘要:软件测试作为保证软件质量的重要手段,越来越引起人们的重视,而软件测试项目中存在着风险,如果能预先重视风险的评估,并对可能会出现的风险制定积极的应对计划,就可以在风险到来的时候,最大限度的避免风险或者降低风险所带来的损失。

  关键词:测试风险测试管理;软件测试

  软件本身的复杂性以及测试本身的特性决定了测试活动实施过程中风险的大量存在,而风险会影响测试活动的成败,严重时还可能导致整个项目的失败。因此,对测试风险的管理越来越引起人们的重视。

  1、风险存在的必然性

  软件测试项目的风险来自于软件和测试自身的特点。

  1.1 软件的特点

  1)软件产品是不可见的:软件项目的开发进度和软件质量管控过程是否符合标准很难衡量,使得软件的管理也难于把握;

  2)软件生产过程形式多样,不存在绝对正确的形式:不同的软件开发项目,应采取不同的或者特定的软件开发过程。但在项目开发之初却不能确定正确的形式,只能根据项目的特点和开发经验选择,并在开发过程中不断的调整,真正适合该软件的开发过程只有在项目开发结束才能确定;

  3)大型软件项目往往是“一次性”:项目一次性的特点使得过去的经验不能被广泛的借鉴。控制软件管理风险的唯一途径是设立监测系统,开展有效的风险监控和管理。

  1.2 测试的特点

  1)完全测试是不可能的:在有限的资源和时间条件下,找出所有的软件缺陷和错误,使软件趋于完美是不可能的,主要原因为是输入量太大、输出结果太多、路径组合太多;

  2)测试具有病毒一样的免疫性:软件缺陷具有病毒一样可怕地免疫性,对其采用的测试越多,免疫能力就越强,软件测试工程师想要找出更多软件缺陷就更加困难;

  3)测试是“泛型概念”:软件测试涵盖需求分析、概要设计等在内的整个软件生命周期,以确保每一个阶段都经住考验;另外,测试自身也需要来自第三方的评估和监督,以确保测试的可靠性;

  4)80-20原则:80%的软件缺陷常常生存在20%的软件模块中。我们在系统分析、系统设计、系统实现阶段只能检测和规避80%的软件缺陷。在下一步的系统测试中,可以帮助我们找到剩余缺陷的80%,剩余4%的缺陷只有在系统交付使用后经过大范围长时间使用后才会暴露出来。所以,软件测试只能保证尽可能多的发现软件缺陷,却无法保证能够发现所有的软件缺陷;

  5)缺陷的必然性:由于软件测试中错误的相关性,并非全部的软件缺陷都能够被成功修复。在缺陷的修复过程中会不可避免的引入新的错误,另外,在修复的过程中,我们往往还会受到时间、成本等各方面因素的限制,导致最终不可能完全的修复所有的软件缺陷。

  2、风险的评估

  风险的管理基本的内容有两项:风险评估和风险控制。

  风险评估是在风险识别的基础上,对识别出来的风险进行评估,主要从下列四个方面入手:

  1)风险概率分析,即对风险发生的可能性设置一个尺度,如很高、较高、中等、较低、很低等;

  2)描述风险并预测风险发生后,对软件产品和测试结果可能产生的影响或造成的损失等;

  3)确定风险评估的正确性,要对每个风险的表现、范围、时间做出尽量准确的判断;

  4)根据损失(影响)和风险概率的乘积,来确定风险的优先级别,定制风险应对措施。

3、风险控制的原则

  风险控制是建立在风险评估的基础之上的,主要工作原则有:

  1)针对有些可以避免的风险,例如测试用例执行率未达到100%,可以通过制定测试规范,要求测试人员严格按照测试用例执行测试,并记录用例执行情况,来避免该类风险;

  2)有些不可避免的风险,采取措施降低风险,尤其是等级较高的风险,将其转化为不会引起严重后果的等级较低的风险;

  3)凡事预则立,事先做好风险管理计划,当风险成为现实时,可以更好的避免、转移或减低风险;

  4)对风险的处理制定应急、高效的解决方案。

  4、软件测试风险分析与管理方法

   软件生命周期包括问题定义及规划、需求分析、软件设计、程序编码、软件测试和运行维护六个阶段,而软件测试前面的任何一个环节的不严谨都可能增加软件测 试活动的风险。软件测试活动中也存在各种各样的风险,其中常见风险有需求变更风险、测试过程风险、测试组织和人员风险。

  4.1 需求变更风险

  在软件测试项目尤其是历时较长的大项目的实施过程中,总会不可避免的出现需求的变更。如何把握好需求的变更,减少需求变更带来的风险,成为影响整个项目成败的关键。

  4.1.1 软件测试项目需求变更的管理

  1)设定需求变更的参考标准,将需求基线。当软件测试项目组确认要产生需求变更时,用标准的变更申请表格将委托方的变更申请记录存档。每次的变更都应在需求基线的基础上进行。

  2)软件测试项目组收到委托方提交的需求变更申请后,成立项目变更控制委员会(CCB),负责对项目变更所带来的影响进行评估,包括测试项目的人力、物力、资金、管理、时间、质量、工作负荷等内部因素,以及资本、委托方要求的完工时间、项目负债情况等各个方面的影响。

  3)变更确定后,选择可行的实施方案。为了将项目变更的风险降低到最小,力求在尽可能小的变动幅度内对测试项目的目标、预算、团队以及项目的进度等主要的因素进行微调。

  4)需求变更后,要重新确定新的需求基线;受影响的软件计划、产品、活动等也要进行相应的变更,以保证和最新需求的一致性。

  4.2 测试过程风险

  在测试工作中,主要的风险有:

  1)需求的临时或突然变化,导致设计的修改和代码的重写,使得测试时间不够;

  2)测试用例没有得到100%的执行;

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

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

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

  6)测试环境与实际生产环境一般情况下都不可能完全一致,造成测试结果的误差;

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

  8)回归测试一般是选择性的执行部分测试用例,必然带来风险。

   前面3种风险可以通过前期调研人员或测试人员与客户加强沟通或者制定严格的制度来避免的,而针对有些不可避免的风险,采取一些有效的测试风险控制方法来 尽量降低风险,例如测试环境不正确,可以通过事先列出要检查的所有条目,在测试环境设置好后,由其他人员按已列出条目逐条检查;针对程序中总是存在的“未 发现的缺陷”,可以通过提高测试用例的覆盖率(如达到99.9%)来降低这种风险;针对经常出现的产品发布前夕,在某个不是很重要的新功能上发现一个严重 缺陷的问题,可以通过去掉该新功能来转移因为修改此缺陷可能引起的某个原有功能上的缺陷的风险。回归测试只执行部分用例带来的风险是可以避免的,但出于时 间或成本的综合考虑,一般是存在的。

提前做好风险管理计划和风险控制策略,可以更好的避免、转移或者降低风险:

  1)在执行项目计划,做资源、时间、成本等的估算时,要留有余地;

  2)在项目开始前,制定风险管理计划,重点把握边界上可能会出现变化、难以控制的因素;

  3)重视人员队伍的培养,对每个关键性技术岗位人员培养后备人员,确保项目不受人员流动的严重影响;

  4)制定工作机制和文档标准,保证文档的及时产生,便于项目知识的分享和移交;

  5)对工作进行相互审查,不同的测试人员在不同测试模块上相互调换,及时发现问题;

  6)日常跟踪所有工作过程,及时发现风险的迹象,以避免风险。

  4.3 测试组织和人员风险

  4.3.1 测试组织风险

  测试人员不独立于开发者,测试人员独立与开发者的程度将影响测试结果。

  1)成立专门的测试组织;

  2)制定专门的测试管理流程和质量保证手册,规范测试过程,保证测试的质量;

  3)委托专门的测试组织执行测试活动。

  4.3.2 人员风险

  测试项目尤其是周期较长的项目几乎不可避免的要面临人员的流动,从而增加项目失败的风险系数。及早预防是降低这种人员风险的基本策略。下面从第三方测试的角度具体介绍一下人员风险的控制方法:

  1)指派一名项目副经理或项目经理助理协调项目经理管理项目工作,降低关键岗位人员流动的风险。但是一般只建议在项目经理这种比较重要的岗位采用这种冗余复制的策略来预防人员风险,否则将大大增加项目成本;

  2)建立良好的文档管理机制,包括项目组进度文档,个人进度文档(测试日志)、版本控制文档、整体技术文档(测试策略、测试用例)、个人技术文档(测试执行记录、缺陷报告)等。一旦出现人员的变动,替补组员能够根据完整的文档尽早接手工作;

  3)控制项目团队中外包或兼职人员的比例,且项目核心部分的工作应该尽量由全职人员来担任,以减少兼职人员对项目组人员不稳定性的影响;

  4)加强测试项目组内的技术交流,定期召开项目例会,使测试组成员能够相互熟悉对方的工作和进度,能够在必要的时候接替对方工作;

  5)为项目测试工作的开展提供尽可能好的基础环境,比如待遇、项目组内良好的人际关系和工作氛围等。良好的工作环境对于稳定项目组人员以及提高生产效率都有不可忽视的作用。

  4.3.3 外包人员风险

  1)制定相关的管理流程文件,规范外包人员的活动,防患于未然,规避外包风险;

  2)通过外派监管团队的方式对整个测试活动进行监控;

  3)通过对测试活动的中间交付物进行检查保证测试的质量,例如:对设计的测试用例进行评审、对编写的测试代码进行抽查、检查测试执行的日志等;

   4)对于外包测试的形式,除了避免承包方项目人员的泄密,还要注意双方数据传输过程中的信息保密。在采用外包测试的时候,不可避免地要进行各种信息的传 送,可能是双方的电话、E-Mail交流,也可能是软件版本的传输,在条件允许的情况下要尽量使用VPN等方式。如果有必要,对传输的数据要进行加密。

  5、结束语

   测试过程中的风险总是存在的,该文对测试活动中主要的风险进行识别和控制,并确定针对性措施,避免风险发生,或者把风险降到最小。要想做好风险管理工 作,就必须彻底改变测试项目的管理方式,建立防患于未然的管理意识,并结合具体的实践工作不断地分析遇到的风险,总结各种风险的应对措施,指导实践,降低 产品质量风险。

 

转载:http://blog.chinaunix.net/uid-16844439-id-3379355.html

浅谈软件测试风险管理

标签:

原文地址:http://www.cnblogs.com/zhangyublogs/p/4981187.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!