浅谈软件测试风险管理

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

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

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

  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

时间: 2024-10-09 17:45:58

浅谈软件测试风险管理的相关文章

浅谈软件测试流程

[摘要] 软件测试从哪里开始到哪里结束?中间要经过哪些环节以及各环节要注意哪些事项.本文就有关问题结合个人实际工作经验进行阐述,鉴于每个环节都可以做为一个专题来进行探讨,所以受篇幅和时间限制,本文对有关问题未做深入剖析,只做一个宏观上的介绍. [关键词]测试流程.需求分析.测试用例.测试计划.缺陷管理 一.概述 一般而言,软件测试从项目确立时就开始了,前后要经过以下一些主要环节: 需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM. 在进行有关问题阐述前,

[转]浅谈软件测试流程

[摘要] 软件测试从哪里开始到哪里结束?中间要经过哪些环节以及各环节要注意哪些事项.本文就有关问题结合个人实际工作经验进行阐述,鉴于每个环节都可以做为一个专题来进行探讨,所以受篇幅和时间限制,本文对有关问题未做深入剖析,只做一个宏观上的介绍. [关键词]测试流程.需求分析.测试用例.测试计划.缺陷管理 一.概述   一般而言,软件测试从项目确立时就开始了,前后要经过以下一些主要环节: 需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM. 在进行有关问题阐述

浅谈软件测试流程(转)

[摘要]软件测试从哪里开始到哪里结束?中间要经过哪些环节以及各环节要注意哪些事项.本文就有关问题结合个人实际工作经验进行阐述,鉴于每个环节都可以做为一个专题来进行探讨,所以受篇幅和时间限制,本文对有关问题未做深入剖析,只做一个宏观上的介绍. [关键词]测试流程.需求分析.测试用例.测试计划.缺陷管理 一.概述   一般而言,软件测试从项目确立时就开始了,前后要经过以下一些主要环节: 需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM. 在进行有关问题阐述前

浅谈软件测试团队规范建设

一些已经从事测试工作三到五年的朋友正在积极的向QA Manager 角色转型,他们对于将来的发展方向也很一致,普遍观点大都是组建一支出色高效的测试团队.最近我也想了一些团队规范和成为具有出色团队称号的必要条件,自己从事测试工作也接近四年了,有些是我在原先工作中遇见并且总结出来的,写的我认为还谈不上全面以后还会逐渐补全. 条件: 缺陷管理 首先正规测试团队至少会有一个缺陷管理系统,不管是Bugzilla还是Mantis 或是其它系统,因为软件测试过程本身就是围绕着缺陷进行的,这也是测试工作的一个重

【测试管理_浅谈软件测试的价值及如何做】

最近思考测试人员对于项目的价值,后来归纳为3个阶段: 提测前: 价   值: 促使项目需求.实现功能无遗漏,需求与功能实现保存一致 如何做: 1. 重视文档评审,系统软件一般由多个大的软件模块组成,而各软件模块存在单独的文档,在文档评审时,以需求为参照物,审查文档是否一致 2. 若有条件,建议进行接口测试,避免由于缺少沟通导致的软件问题 3.测试人员认真阅读文档,进行测试用例设计 测试中: 价   值: 1.从客户的角度验证产品与用户期望保证一致 2.测试软件,目标软件在用户使用过程中不会出现问

浅谈项目管理之风险管理

浅谈项目管理之风险管理 IT项目经理.建筑项目经理.医疗项目经理等等不同项目类型都有一个管理者,通常这个管理者被称为“项目经理”(PM),项目经理的职责就是在有限的资源约束条件下,运用系统的理论.观点和方法对项目涉及的各个过程进行有效的管理,通常需要管理者运用专门的知识.技能.工具和方法,实现或者超过设定的目标,并且满足客户的需求和期望.涉及的管理我总结起来就是10个字“狗子整范进,成人风采干”,对应的10大管理域,分别就是沟通管理.质量管理.整体管理.范围管理.进度管理.成本管理.人力资源管理

浅谈自动化测试流程

浅谈AST(自动化测试)流程,欢迎大家多多指点,多提宝贵意见. AST阶段一:需求收集——分析自动化测试需求 1.举行启动会议,对SUT(被测试的系统)进行总体描述 2.SUT的要求是可测试和可自动化的 3.评估哪些测试可以自动化 4.分析当前生命周期中SUT使用的工具和复用现有的AST工具 5.对AST和测试中需要的工具进行评估,并提出建议 6.确定和讨论测试环境,包括测试环境的采购和安排,列出测试环境的概要 7.与开发相关人员一起走查一遍AST测试需求,最后达成一致意见 8.给出可以自动化的

浅谈敏捷软件开发与传统软件开发

本文将介绍传统软件开发与敏捷软件开发,并简单分析二者的优缺. 首先我查阅相关资料大致了解了下为什么会爆发"软件危机"和什么是"软件危机".由于在早期的软件开发活动中有明显的个体化特征,开发流程不规范,人们没有将软件与程序加以详细的区别,对程序之外的数据和相关文档资料没有给予重视,对编写程序之外的软件活动也没有给予重视,因此出现了"软件危机"."软件危机"的特点有:开发成本急剧上升.不能按时交付软件.软件难以维护.无法保证软件质

单元测试之覆盖率浅谈

一.什么是代码覆盖率 代码覆盖是软件测试中的一种度量,描述程式中源代码被测试的比例和程度,所得比例称为代码覆盖率.一般我们用工具做的代码覆盖率的计算方法是: 代码覆盖率 = 被测代码行数 / 参测代码总行数 * 100% 二.度量方式 代码覆盖程度的度量方式是有很多种的,这里介绍一下最常用的几种: 1. 语句覆盖/行覆盖(StatementCoverage) 这是一种较为常用且具有代表性的指标,度量的是被测代码中所有语句是否被执行到. 2.判定覆盖(DecisionCoverage) 度量程序中