软件Software迅猛发展凸现软件Software测试问题

软件Software迅猛发展凸现软件Software测试问题疯狂代码ĵ:http:/CrazyCoder.cn/SoftwareTesting/Article34652.html随着软件Software业蓬勃发展各种软件Software需求纷繁而来在潮起潮落IT洪流中软件Software项目越来越凸现大型化、复杂化发展趋势几十人上百人开发团队(Team)、成千上万模块和接口、跨地域、跨系统使用用户等情况早已屡见不鲜所有这些对项目质量管理提出了更高要求如何满足各方需求做出更好软件Software系统？测试管理逐渐成了大家目光焦点软件Software质量靠什么靠管理、靠各个软件Software过程严密配合但勿庸置疑质量守护是靠测试它就象只看门狗认真守护着软件Software质量这个“家”软件Software测试重要性测试是什么？测试就是对项目开发过程产品(编码、文档等)进行差错审查保证其质量种过程软件Software业迅猛发展也就是近几十年过程时间虽短但许多误解似乎已根深蒂固对测试偏见也是如此“软件Software重点在于需求、在于分析、在于设计、在于开发而测试容易没什么技术含量找些用户对照需求尽力去测就行了；有时间多测点没时间就少测点”这种看法在许多项目经理(projectmanager)、软件Software负责人心中固守着难以改变这种观念结果有目共睹是什么？很简单是大量软件SoftwareBUG、缺陷“流失”从测试人员手中悄然而过流失到用户手中流失进项目维护阶段随的而来便是用户无休止抱怨、维护人员无休止“救火”、维护成本无休止增加这是软件Software人员梦魇！恶梦总有醒来时经过无数教训重击在不堪回首而不得回首经历中软件Software业管理者发现:是他们错了软件Software测试是不可忽视“所有这些问题假如在项目中测试到话便不会有造成不可收拾结果了”――人们终于意识到测试简单而纯真真谛软件Software测试软件Software测试从直观上来讲是对测试对象进行检查、验证似乎很简单但实际不然它是由许多处理环节构成根据测试目标、质量控制要求它被划分为以下各类环节(如下图)并被设置了区别准入、准出标准er\alt=qsrc=\/Files/BeyondPic/2008-2/19/1.jpg\_disibledevent=测试主要过程及活动如上图所示内容目了然在此就不详述了只希望通过对测试重点问题、关注热点介绍帮助大家对测试管理有个总体把握测试方式中普遍存在问题和点评谈到测试我们无法回避是当前软件Software过程普遍存在测试问题:1、手工过多缺少测试工具自动化测试方式缺失传统项目测试还是以手工为主测试人员根据需求规格介绍说明书要求和测试对象进行“人机对话”随着软件Software业不断发展及软件Software规模扩大这种测试弊端日益明显:·大量手工使项目人力成本、沟通成本居高不下；·人工操作低效率使项目耗时增加带来进度风险；·人员素质及其他不确定原因会影响手工测试结果导致差错率增加·在测试过程中需要对测试案例库进行统配置管理项目规模激增使手工管理案例库难度日益加大尤其是在需求变更、回归测试频繁发生时候[Page]从古到今当生产率阻碍了生产力发展时候必然会引入更高级生产工具及方式项目测试也是这个道理引入工具引入自动化测试及管理是项目测试大趋势2、缺乏文档测试、检查文档是项目重要产品的产品需求、功能分析、架构设计、详细设计、用户手册、维护手册等等对于项目测试、上线、维护等过程起到至关重要参考、指导作用所以它们质量应该是项目重点关注点的令人遗憾是许多软件Software项目对于文档重视只停留在口头上“编码第”观念似乎根深蒂固随着需求不断变更、补充业务、技术人员忙于应付无法腾出精力来进行文档内容修改及完善往往是将包含需求变更内容工作联系单往需求文档后附了事而不去更新需求和其他相关文档；另方面项目变更管理还不够完善管理重点往往集中于开发而轻视文档质量管理未留出充分文档更新时间导致文档更新严重滞后于编码进度为保证文档质量必须定期进行文档测试但测试要花成本项目高层不愿意付此代价文档若可读性低便会影响用户理解；若和编码不致便起不到参考作用编码测试就没有可靠测试依据路都看不清楚如何往前走呀？所以强烈建议进行文档测试并将其置于测试管理首位当前文档测试思路方法没有什么特别形式还缺乏测试工具支持通常是通过静态审查方式――“走查”来进行主要查看文档可读性内容真实性、可靠性、全面性另外在项目里程碑时期召集相关领域专家对重要文档进行集中审核也是种检查方式3、单元测试应引入交叉测试思路方法；单元测试是对软件Software基本组成单元进行测试测试对象是软件Software模块通常单元测试是由开发人员来完成而且往往是各人测各人这存在问题隐患为什么呢技术人员是软件Software模块制造者自己来测自己软件Software话角色便从制造者变成了审查者而前个角色目是为了保证软件Software正确后个角色目是为了发现更多缺陷让个人同时来扮演两种目区别角色好比让他既当裁判员又当运动员如何能做好呢？解决思路方法通常有两种种是:由测试人员来进行单元测试这种方式要求测试人员要有较高软件Software技术知识；另种是:将软件Software人员分组在模块开发告段落时进行交叉测试这种思路方法只需要测试者了解被测方软件Software需求不需要另外知识培训而且测试出发点较为客观所以被较普遍推广使用4、测试在开发基本完成才启动；在传统瀑布型开发模式中软件Software测试位于编码阶段的后是作为个独立阶段存在许多人便刀切地认为应该将所有测试工作在编码完成后再开始这个观点要不得原因有2:[Page]首先若将测试工作细分有许多工作是可以提前先期执行如:需求书和设计书学习、测试计划制定、测试人员培训、测试脚本建立、测试资源搭建、测试模板创建、测试工具选择等等都是可以和其他阶段并行处理这将大大缩短项目开发时间为测试提供充分时间保障提高测试质量其次软件Software缺陷发现越晚修改、补救所耗费成本越高引用Boehm在SoftwareEngineeringEconomics书中话――“平均而言如果在需求阶段修证个代价是1那么在设计阶段就是它3－6倍在编程阶段是它10倍在内部测试阶段是它20—40倍在外部测试阶段是它30－70倍而到了产品发布出去时这个数字就是40－1000倍”由此可见测试目标最佳定位应该是:在第次出现时候就捕捉到它所以在尽可能情况下测试越早展开越好在项目各个进行阶段都有区别项目产品产生他们质量好坏对后续开发影响重大所以现在国际上比较流行做法是:将测试融合到各个开发环节中去尽早测试5、测试案例、测试方案重用率低下传统测试过程测试管理不严密测试人员未建立完整测试库未将测试案例、测试、测试方案进行有效保存等到回归测试时相关测试等往往已不知所终无处可寻了；即使能找到这些、案例可往往回归测试过于频繁、项目期限日益迫近已经没有时间余量来修改、完善这些及案例只能凭借经验、记忆及技术人员口述对修改过地方草草重测遍而已缺乏正规化测试过程造成测试虎头蛇尾er\alt=wsrc=\/Files/BeyondPic/2008-2/19/2.jpg\_disibledevent=　　正常测试案例使用方式如上图测试设计阶段相关测试设计人员会对测试对象进行了解、分析为保证测试顺利进行保证测试覆盖尽量多测试对象会设计测试案例、测试方案在测试期间进行使用；测试发现时软件Software技术人员会根据测试缺陷反馈结果及技术人员软件Software修改信息对测试进行修改完毕后再进行回归测试6、　　测试人员素质低缺乏相关知识培训　　项目管理(projectmanagement)人员对测试存有偏见对于测试重要性认识不足导致其严重忽略测试人员选拔和知识培训许多软件Software项目让软件Software用户或新招收技术人员来完成测试工作他们认为测试人员工作很简单就是技术人员让测什么就测什么它基本是个动手不动脑工作　　这样做后果进步导致了测试工作无序和混乱测试过程缺乏计划性测试人员缺乏技术能力缺乏对架构了解相关素质缺失使他们成为技术人员附庸测试对于他们来说是种枯燥“手＋眼”式工作他们唯渴望是将无聊测试尽快完成从而远远逃离这样测试结果可想而知　　其实软件Software工程对测试人员素质要求是很严格比如:要有相关计算机知识背景、具备软件Software工程基本知识、熟悉项目编程语言、熟悉项目技术架构及需求内容、工作有责任感、独立分析能力及团队(Team)精神等等真正规范标准软件Software项目对于测试人员要求是不会低于技术人员而且会为测试人员提供进步知识培训机会以应对各种项目复杂情况[Page]7、　　测试进度估算　　在项目开发中领导为督促测试进程往往会让项目组汇报工作进度了解已经完成工作占比从而对工作进度做出判断我对这种工作方式完全拥护只是觉得这种方式还有不足　　测试进程不是简单1＋1过程不能武断地认为“我用8天干完了80％工作那么剩余工作便能在2天内干完”著名Pareto80/20规律告诉我们:测试发现所有中80％很可能集中在20％模块中另外20％很可能集中在80％模块中　　所以没有对测试对象认真分析基础单凭工作完成数量而对工作进度做出判断往往是　　我认为“工作实际进度＝工作完成量占比＋测试对象占比分析”才是个较合理测试进度估算方式　　测试新思路:　　项目开发风险来自于对需求误解来自于设计和开发过程及产品缺陷只有尽早发现这些缺陷才能降低并控制项目风险基于这种思想软件Software业出现了些新测试思路主要有2:　　1、测试驱动开发(Test-DrivenDevelopment简称TDD)这种测试思想被最近流行XP(ExtremeProgramming)极限编程方式所大力提倡它基本思想是通过测试来为编程做指导在某个要开发需求对象明确的后在编码的前先进行相关测试代码(测试代码内容和需求规格介绍说明书描述是相同有人把它称为“可执行需求规格介绍说明书”)编写工作完成的后针对测试代码进行编程然后再用测试对开发代码进行测试验证其正确性若通过了测试就介绍说明它是符合需求规格介绍说明书要求周而复始通过这样过程开发进程得以层层深入直到开发完成而这时单元测试也基本完成了　　这种测试方式最大好处是尽早地发现设计、开发中存在问题避免传统开发模式中“测试过程中发现代码不能满足需求而导致大量返工”降低项目风险；同时可以尽早地将“半成品”展示给客户使客户对需求进行验证、补充及完善另外测试代码表达方式相对准确、无2义性可以降低因需求理解而导致项目风险　　2、迭代测试这种测试是IBM所推崇测试方式的它从迭代式开发模式演变而来在迭代开发模式中每个迭代都包含需求、设计、编码、集成、测试等过程在每次迭代完成的后便会开始新迭代过程通过次次迭代累进系统会增量式集成些新功能直至整个系统功能完成其中每个迭代周期测试工作由两方面内容构成:·对当前迭代周期产品增量测试·对前迭代周期已完成功能回归测试　　随着迭代周期累进测试工作内容随的不断变化早期迭代测试重点在于新功能测试后期迭代测试重点在于累积功能回归测试　　有人不喜欢XP编程开发方式认为其没有明确阶段性划分不利于计划管理模式过于灵活不好掌握迭代式开发模式为这些人提供了新选择这种开发方式继承了瀑布式开发模式优点――全面、严谨、有计划性、易管理更重要是这种模式将测试工作分布到每个迭代周期中使测试工作提前进行从而使将发现软件Software缺陷周期提前大大降低软件Software风险及开发成本[Page]测试过程衡量　　测试过程在不断地改进但效果如何如何来衡量测试效果呢？我们需要引入把尺子个度量标准这样才能把握测试过程改进方向那么怎样来收集数据如何来度量？这是我们长久以来直困惑地方　　我们不妨借助“他山的石”来想想办法CMMI是当今国际流行软件Software过程衡量模型它在这方面是有自己独到的处:1、　　面向全局CMMI测试度量面向不仅仅是测试