守护着软件software质量这个 家

《守护着软件software质量这个 家》由会员分享，可在线阅读，更多相关《守护着软件software质量这个 家（7页珍藏版）》请在金锄头文库上搜索。

1、守护着软件Software质量这个 家 疯狂代码 http:/CrazyC :http:/CrazyC 软件Software测试重要性 测试是什么？测试就是对项目开发过程产品(编码、文档等)进行差错审查保证其质量种过程 软件Software业迅猛发展也就是近几十年过程时间虽短但许多误解似乎已根深蒂固对测试偏见也是如此“软件 Software重点在于需求、在于分析、在于设计、在于开 发而测试容易没什么技术含量找些用户对照需求尽力去 测就行了；有时间多测点没时间就少测点”这种看法在许多项目经理(project manager)、软件Software负责 人心中固 守着难以改变 这种观念结果有目共睹

2、是什么？很简单是大量软件SoftwareBUG、缺陷“流失”从测试人员手中悄然而过流失 到用户手中流失进项目维护阶段随的而来便是用户无休止抱怨、维护人员无休止“救火”、维护成本无休止增 加这是软件Software人员梦魇！ 恶梦总有醒来时经过无数教训重击在不堪回首而不得回首经历中软件Software业管理者发现:是他们错了软件 Software测试是不可忽视 “所有这些问题假如在项目中测试到话便不会有造成不可收拾结果了”人们终于意识到测试简单而纯真真谛 软件Software测试 软件Software测试从直观上来讲是对测试对象进行检查、验证似乎很简单但实际不然它是由许多处理环节构成 根据测试目

3、标、质量控制要求它被划分为以下各类环节(如下图)并被设置了区别准入、准出标准 er“ alt=“软件Software测试“ src=“http:/ 93e3-20606b845f90.jpg“ border=“0“ / 测试主要过程及活动如上图所示内容目了然在此就不详述了只希望通过对测试重点问题、关注热点介绍帮助大 家对测试管理有个总体把握 测试方式中普遍存在问题和点评 谈到测试我们无法回避是当前软件Software过程普遍存在测试问题: 1、 手工过多缺少测试工具自动化测试方式缺失 传统项目测试还是以手工为主测试人员根据需求规格介绍说明书要求和测试对象进行“人机对话”随着软 件Softwar

4、e业不断发展及软件Software规模扩大这种测试弊端日益明显: 大量手工使项目人力成本、沟通成本居高不下； 人工操作低效率使项目耗时增加带来进度风险； 人员素质及其他不确定原因会影响手工测试结果导致差错率增加 在测试过程中需要对测试案例库进行统配置管理项目规模激增使手工管理案例库难度日益加大尤其是在需 求变更、回归测试频繁发生时候 从古到今当生产率阻碍了生产力发展时候必然会引入更高级生产工具及方式项目测试也是这个道理引入工 具引入自动化测试及管理是项目测试大趋势 2、 缺乏文档测试、检查 文档是项目重要产品的产品需求、功能分析、架构设计、详细设计、用户手册、维护手册等等对于项目测 试、上线、

5、维护等过程起到至关重要参考、指导作用所以它们质量应该是项目重点关注点的令人遗憾是许多软 件Software项目对于文档重视只停留在口头上“编码第”观念似乎根深蒂固 随着需求不断变更、补充业务、技术人员忙于应付无法腾出精力来进行文档内容修改及完善往往是将包含 需求变更内容工作联系单往需求文档后附了事而不去更新需求和其他相关文档；另方面项目变更管理还不够完 善管理重点往往集中于开发而轻视文档质量管理未留出充分文档更新时间导致文档更新严重滞后于编码进度为 保证文档质量必须定期进行文档测试但测试要花成本项目高层不愿意付此代价 文档若可读性低便会影响用户理解；若和编码不致便起不到参考作用编码测试就没有可

6、靠测试依据路都看 不清楚如何往前走呀？所以强烈建议进行文档测试并将其置于测试管理首位 当前文档测试思路方法没有什么特别形式还缺乏测试工具支持通常是通过静态审查方式“走查”来进行 主要查看文档可读性内容真实性、可靠性、全面性另外在项目里程碑时期召集相关领域专家对重要文档进行集 中审核也是种检查方式 3、 单元测试应引入交叉测试思路方法； 单元测试是对软件Software基本组成单元进行测试测试对象是软件Software模块通常单元测试是由开发人 员来完成而且往往是各人测各人这存在问题隐患 为什么呢技术人员是软件Software模块制造者自己来测自己软件Software话角色便从制造者变成了审查者

7、 而前个角色目是为了保证软件Software正确后个角色目是为了发现更多缺陷让个人同时来扮演两种目区别角色 好比让他既当裁判员又当运动员如何能做好呢？ 解决思路方法通常有两种种是:由测试人员来进行单元测试这种方式要求测试人员要有较高软件Software技 术知识；另种是:将软件Software人员分组在模块开发告段落时进行交叉测试这种思路方法只需要测试者了解被 测方软件Software需求不需要另外知识培训而且测试出发点较为客观所以被较普遍推广使用 4、 测试在开发基本完成才启动； 在传统瀑布型开发模式中软件Software测试位于编码阶段的后是作为个独立阶段存在许多人便刀切地认为 应该将所有

8、测试工作在编码完成后再开始这个观点要不得原因有 2: 首先若将测试工作细分有许多工作是可以提前先期执行如:需求书和设计书学习、测试计划制定、测试人员 培训、测试脚本建立、测试资源搭建、测试模板创建、测试工具选择等等都是可以和其他阶段并行处理这将大 大缩短项目开发时间为测试提供充分时间保障提高测试质量 其次软件Software缺陷发现越晚修改、补救所耗费成本越高引用Boehm在Software Engineering Economics书中话“平均而言如果在需求阶段修证个代价是1那么在设计阶段就是它36倍在编程阶段是它 10倍在内部测试阶段是它2040倍在外部测试阶段是它3070倍而到了产品发布

9、出去时这个数字就是 401000倍”由此可见测试目标最佳定位应该是:在第次出现时候就捕捉到它所以在尽可能情况下测试越早展 开越好 在项目各个进行阶段都有区别项目产品产生他们质量好坏对后续开发影响重大所以现在国际上比较流行做 法是:将测试融合到各个开发环节中去尽早测试 5、 测试案例、测试方案重用率低下 传统测试过程测试管理不严密测试人员未建立完整测试库未将测试案例、测试、测试方案进行有效保存等 到回归测试时相关测试等往往已不知所终无处可寻了；即使能找到这些、案例可往往回归测试过于频繁、项目期限日益迫近已经没有时间余量来修改、完善这些及案例只能凭借经验、记忆及技术人员口述对修改过地方草 草重测遍

10、而已缺乏正规化测试过程造成测试虎头蛇尾 正常测试案例使用方式如上图测试设计阶段相关测试设计人员会对测试对象进行了解、分析为保证测试顺 利进行保证测试覆盖尽量多测试对象会设计测试案例、测试方案在测试期间进行使用；测试发现时软件 Software技术人员会根据测试缺陷反馈结果及技术人员软件Software修改信息对测试进行修改完毕后再进行回 归测试 6、 测试人员素质低缺乏相关知识培训 项目管理(project management)人员对测试存有偏见对于测试重要性认识不足导致其严重忽略测试人员选 拔和知识培训许多软件Software项目让软件Software用户或新招收技术人员来完成测试工作他们

11、认为测试人员 工作很简单就是技术人员让测什么就测什么它基本是个动手不动脑工作 这样做后果进步导致了测试工作无序和混乱测试过程缺乏计划性测试人员缺乏技术能力缺乏对架构了解相 关素质缺失使他们成为技术人员附庸测试对于他们来说是种枯燥“手眼”式工作他们唯渴望是将无聊测试尽 快完成从而远远逃离这样测试结果可想而知 其实软件Software工程对测试人员素质要求是很严格比如:要有相关计算机知识背景、具备软件Software工 程基本知识、熟悉项目编程语言、熟悉项目技术架构及需求内容、工作有责任感、独立分析能力及团队 (Team)精神等等真正规范标准软件Software项目对于测试人员要求是不会低于技术人

12、员而且会为测试人员提供 进步知识培训机会以应对各种项目复杂情况 7、 测试进度估算 在项目开发中领导为督促测试进程往往会让项目组汇报工作进度了解已经完成工作占比从而对工作进度做 出判断我对这种工作方式完全拥护只是觉得这种方式还有不足 测试进程不是简单11过程不能武断地认为“我用8天干完了80工作那么剩余工作便能在2天内干完”著 名Pareto80/20规律告诉我们:测试发现所有中80很可能集中在20模块中另外20很可能集中在80模块 中 所以没有对测试对象认真分析基础单凭工作完成数量而对工作进度做出判断往往是 我认为“工作实际进度工作完成量占比测试对象占比分析”才是个较合理测试进度估算方式 测

13、试新思路 项目开发风险来自于对需求误解来自于设计和开发过程及产品缺陷只有尽早发现这些缺陷才能降低并控制 项目风险基于这种思想软件Software业出现了些新测试思路主要有 2: 1、测试驱动开发(Test-Driven Development简称TDD)这种测试思想被最近流行XP(Extreme Programming)极限编程方式所大力提倡它基本思想是通过测试来为编程做指导在某个要开发需求对象明确的 后在编码的前先进行相关测试代码(测试代码内容和需求规格介绍说明书描述是相同有人把它称为“可执行需求 规格介绍说明书”)编写工作完成的后针对测试代码进行编程然后再用测试对开发代码进行测试验证其正确

14、性若 通过了测试就介绍说明它是符合需求规格介绍说明书要求周而复始通过这样过程开发进程得以层层深入直到开 发完成而这时单元测试也基本完成了 这种测试方式最大好处是尽早地发现设计、开发中存在问题避免传统开发模式中“测试过程中发现代码不 能满足需求而导致大量返工”降低项目风险；同时可以尽早地将“半成品”展示给客户使客户对需求进行验证 、补充及完善另外测试代码表达方式相对准确、无 2义性可以降低因需求理解而导致项目风险 2、迭代测试这种测试是IBM所推崇测试方式的它从迭代式开发模式演变而来在迭代开发模式中每个迭代都 包含需求、设计、编码、集成、测试等过程在每次迭代完成的后便会开始新迭代过程通过次次迭代

15、累进系统会 增量式集成些新功能直至整个系统功能完成其中每个迭代周期测试工作由两方面内容构成: 对当前迭代周期产品增量测试 对前迭代周期已完成功能回归测试 随着迭代周期累进测试工作内容随的不断变化早期迭代测试重点在于新功能测试后期迭代测试重点在于累 积功能回归测试 有人不喜欢XP编程开发方式认为其没有明确阶段性划分不利于计划管理模式过于灵活不好掌握迭代式开发 模式为这些人提供了新选择这种开发方式继承了瀑布式开发模式优点全面、严谨、有计划性、易管理更重要 是这种模式将测试工作分布到每个迭代周期中使测试工作提前进行从而使将发现软件Software缺陷周期提前大 大降低软件Software风险及开发成本 测试过程衡量 测试过程在不断地改进但效果如何如何来衡量测试效果呢？我们需要引入把尺子个度量标准这样才能把握 测试过程改进方向那么怎样来收集数据如何来度量？这是我们长久以来直困惑地方 我们不妨借助“他山的石”来想想办法CMMI是当今国际流行软件Software过程衡量模型它在这方面是有 自己独到的处: 1、面向全局CMMI测试度量面向不仅仅是测试过程改进测试效果加强它面向是整个开发过程并始终将质量 监督放在工作首位比如它度量工作产品规模(例如代码行数)度量工作量和成本(例如人工小时数)我们从中搜集数 据对整个开发过程改进都有指导作用更高起点可使我们避免项目管理(p