软件质量守护-测试管理

1、软件质量守护一一测试管理前言：软件迅猛开展凸现软件测试问题随着软件业蓬勃开展，各种软件需求纷繁而来，在潮起 潮落的IT洪流中，软件工程越来越凸现大型化、复杂化的发 展趋势。几十人上百人的开发团队、成千上万的模块与接 口、跨地域、跨系统的使用用户等情况早已屡见不鲜，所有 这些，对工程质量管理提出了更高要求，如何满足各方需 求，做出更好的软件系统？测试管理逐渐成了大家目光的焦 点。软件的质量靠什么，靠管理、靠各个软件过程的严密配 合。但勿庸置疑，质量的守护是靠测试。它就象一只看门 狗，认真守护着软件质量这个“家”。软件测试的重要性测试是什么？测试是检查产品（代码、文档等）错误的过 程。）在工程开发

2、过程中确保其质量。软件业的迅猛开展也就是近几十年的过程，时间虽短,但许多误解似乎已根深蒂固，对测试的偏见也是如此。“软 件的重点在于需求、在于分析、在于设计、在于开发，而测 试，容易，没什么技术含量，找一些用户，对照需求尽力去 测就行了；有时间多测点，没时间就少测点。”这种看法在 许多工程经理、软件负责人的心中固守着，难以改变。这种观念的结果有目共睹，是什么？很简单，是大量软 件BUG、缺陷的“流失”，从测试人员手中悄然而过，流失到 用户手中，流失进工程维护阶段。随之而来的，便是用户无 休止的抱怨、维护人员无休止的“救火”、维护本钱无休止 的增加。这是软件人员的梦魇！馈过程。作为软件质量的守护

3、者，它可以发现缺陷，但无法 防止缺陷。我们不能把软件质量的平安放在测试的重量上。曾看过一个比喻，还记忆犹新，它将软件开发比喻成制作一桌盛宴，工程经理比作大厨，测试人员比作品尝师，用 户那么比作就餐者。为保障饭菜质量，上菜之前，先由品尝师 对满桌的半成品、准成品逐个品尝，发现缺乏的地方要及时 通知大厨进行改进，完善质量，直至品尝师觉得：全部的饭 菜已经色、香、味俱佳，满足用户要求了，才通过审查，允 许饭菜上桌，供就餐者品尝。我想说的是：坂菜质量靠品尝 师的监督，但主要靠的是大厨的技术，同理，软件的质量那么靠各个工程管理过程的互相配合及工程经理的整体控制和 把握，测试只是其中的一份子。所以，请不要

4、将软件的质量 都交给测试过程来承当，那样将是“生命不能承受之重，噩梦总会醒来，经过无数次的教训，软件行业的管理者发 现他们错了，软件测试不可忽视。“所有这些问题，假如在工程中测试到的话，便不会有 造成不可收拾的结果了。“一一人们终于意识到测试简单而 纯真的真谛。软件测试直观地说，软件测试就是对测试对象进行检查和验证。看 似很简单，其实不然。它由许多加工环节组成。根据考试目 标和质量控制的要求，分为以下几个环节（如下列图所示），设 置不同的准入和退出标准。测试的主要过程及活动如上图所示，内容一目了然，在 此就不一一详述了，只希望通过对测试重点问题、关注热点 的介绍，帮助大家对测试管理有一个总体的

5、把握。测试方式中普遍存在的问题与点评谈到测试，我们无法回避的是当前软件过程普遍存在的 测试问题：1、手工过多，缺少测试工具，自动化测试方式缺失传统的工程测试还是以手工为主，测试人员根据需求规 格说明书的要求，与测试对象进行“人机对话”。随着软件业的不断开展及软件规模的扩大，这种测试的弊端日益明显： 下； 风险； 的结果,大量的手工使工程人力本钱、沟通本钱居高不人工操作的低效率使工程耗时增加，带来进度人员素质及其他不确定因素会影响手工测试导致过失率的增加。在测试过程中，需要对测试案例库进行统一配置管理，工程规模的激增使手工管理案例库的难度日益加大，尤其是在需求变更、回归测试频 繁发生的时候。从古

6、到今，当生产率阻碍了生产力的开展的时候，必然 会引入更高级的生产工具及方式。工程测试也是这个道理， 引入工具，引入自动化测试及管理，是工程测试的一大趋 势。2、缺乏文档测试、检查文档是工程的重要产品之一，产品需求、功能分析、架 构设计、详细设计、用户手册、维护手册等等，对于工程的 测试、上线、维护等过程起到至关重要的参考、指导作用， 所以它们的质量应该是工程重点关注点之一。令人遗憾的 是，许多软件工程对于文档的重视只停留在口头上，“编码 第一”的观念似乎根深蒂固。随着需求的不断变化和补充，业务和技术人员忙得不可开 交，无暇对文件内容进行修改和完善。通常，他们将包含变 更需求的工作联系表附加到需

7、求文档中，而不是更新需求和 其他相关文档。另一方面，工程变更管理不够完善，管理侧 重于开发，忽视文档质量管理，留给文档更新的时间缺乏， 导致文档更新严重滞后于编码进度。为了保证文档的质量， 需要定期进行文档测试，但是测试是要本钱的，工程的高层 不愿意付出这个代价。文档假设可读性低，便会影响用户的理解；假设与编码不一 致，便起不到参考作用，编码测试就没有可靠的测试依据。 路都看不清楚，怎么往前走呀？所以，强烈建议进行文档测 试，并将其置于测试管理的首位。当前文档测试的方法没有什么特别的形式，还缺乏测试 工具支持，通常是通过静态审查方式一一 “走查”来进行的，主要查看文档的可读性，内容真实性、可靠

8、性、全面 性。另外，在工程里程碑时期召集相关领域专家对重要文档 进行集中审核，也是一种检查方式。3、单元测试应引入交叉测试方法单元测试是对软件基本组件的测试，测试对象是软件模 块。通常情况下，单元测试是由开发人员来完成的，而且往 往是每个人来完成。有隐藏的问题。为什么？技术人员是软件模块的制造商。如果他们测试自 己的软件，他们的角色将从制造商变成审查者。前一个角色 的目的是保证软件的正确性，后一个角色的目的是发现更多 的缺陷。一个人怎么可能同时扮演两个不同的角色，比方当 裁判和运发动？通常有两种解决方案，一种是：由测试人员进 行单元测试，这需要测试人员具备较高的软件技术知识；另 一种方法是:将

9、软件人员分组，在模块开发接近尾声时对模块 进行交叉测试。这种方法只需要测试人员知道被测方的软件 需求，不需要额外的知识培训，测试的出发点是客观的，因 此应用广泛。4、测试在开发基本完成才启动在传统的瀑布型开发模式中，软件测试位于编码阶段之 后，是作为一个独立阶段存在的，许多人便一刀切地认为应 该将所有的测试工作在编码完成后再开始。这个观点要不 得，原因有二：首先，如果我们对测试工作进行细分，许多任务可以提前 执行，如：需求和设计的研究、测试计划的制定、测试人员的 培训、测试脚本的建立、测试资源的构建、测试模板的创 建、测试工具的选择等。，可与其他阶段并行处理，将大大缩短工程开发时间，为测试提供

10、充足的时间保障，提高测试 质量。其次，软件缺陷发现的越晚，修改、补救所耗费的本钱 越高。引用 Boehm 在Software Engineering Economics 一书中的话一一 “平均而言，如果在需求阶段修证一个错误 的代价是1,那么，在设计阶段就是它的36倍，在编程阶 段是它的10倍，在内部测试阶段是它的2040倍，在外部 测试阶段是它的3070倍，而到了产品发布出去时，这个数 字就是401000倍。”由此可见，测试目标的最正确定位应该 是：在错误第一次出现的时候就捕捉到它。所以，在尽可能 的情况下，测试越早展开越好。在工程的每个阶段，都会产生不同的工程产品，其质量对 后续的开发影响

11、很大。因此，将测试融入所有开发环节，尽 早测试，是国际上通行的做法。5、测试案例、测试方案的重用率低下传统的测试过程，测试管理不严密，测试人员未建立完 整的测试库，未将测试案例、测试程序、测试方案进行有效 保存，等到回归测试时，相关测试程序等往往已不知所终， 无处可寻了；即使能找到这些程序、案例，可往往因为回归 测试过于频繁、工程期限日益迫近，已经没有时间余量来修 改、完善这些程序及案例，只能凭借经验、记忆及技术人员 的口述对程序修改过的地方草草重测一遍而已，缺乏正规化 的测试过程，造成测试的虎头蛇尾。正常的测试案例使用方式如上图，测试设计阶段，相关 测试设计人员会对测试对象进行了解、分析，为

12、保证测试顺 利进行，保证测试覆盖尽量多的测试对象，会设计测试案 例、测试方案，在测试期间进行使用；测试发现错误时，软件技术人员会根据测试的缺陷反应结果及技术人员的软件修 改信息对测试程序进行修改，完毕后再进行回归测试。6、测试人员素质低，缺乏相关知识培训工程经理对测试存在偏见，对测试的重要性认识缺乏，导 致他们严重忽视测试人员的选拔和知识培训。许多软件工程 允许软件用户或新招聘的技术人员完成测试工作。他们认为 测试人员的工作很简单，就是技术员问什么就测试什么。基 本上是不用思考的动手工作。这样做的后果进一步导致了测试工作的无序和混乱，测 试过程缺乏计划性，测试人员缺乏技术能力，缺乏对架构的 了

13、解，相关素质的缺失使他们成为技术人员的附庸。测试对 于他们来说，是一种枯燥的“手+眼”式的工作，他们唯一 渴望的，是将无聊的测试尽快完成，从而远远的逃离。这样 的测试结果可想而知。实际上，软件工程对测试人员的素质有着严格的要求，比 如具备相关的计算机知识背景、软件工程基础知识、熟悉项 目编程语言、工程技术框架和要求、责任心、独立分析能力 和团队精神等。真正的软件工程对测试人员的要求并不低于 技术人员，他们会为测试人员提供进一步的知识培训机会, 以应对各种工程的复杂性。7、测试进度的错误估算在工程开发中，为了监督测试过程，领导经常要求工程组 汇报工作进度，了解已完成工作的比例，从而对工作进度做

14、出判断。我完全支持这种工作方式，但我认为这还不够。测试进程不是简单的1 + 1过程，不能武断地认为“我用8天干完了 80%的工作，那么，剩余工作便能在2天内干 完”。著名的Pareto80/20规律告诉我们：测试发现的所有错误中的80%很可能集中在20%的程序模块中，另外20%很 可能集中在80%的程序模块中。因此，没有对测试对象进行仔细分析的基础，仅凭完成工 作的数量来判断工作的进度往往是错误的。我认为，“工作实际进度=工作完成量占比+测试对象 的错误占比分析”才是一个较合理的测试进度估算方式。测试新思路工程的开发风险来自于对需求的误解，来自于设计与开 发过程及产品的缺陷，只有尽早发现这些缺

15、陷，才能降低并 控制工程风险。基于这种思想，软件业出现了一些新的测试 思路，主要有二：1、测试驱动开发(Test-Driven Development,简称 TDD) o这种测试思想被最近流行的XP (ExtremeProgramming)极限编程方式所大力提倡。它的基本思想是, 通过测试来为编程做指导，在某个要开发的需求对象明确之 后，在编码之前，先进行相关测试代码(测试代码的内容和 需求规格说明书描述是相同的，有人把它称为“可执行的需 求规格说明书”)的编写工作，完成之后针对测试代码进行 编程，然后再用测试程序对开发代码进行测试，验证其正确 性，假设程序通过了测试，就说明它是符合需求规格说

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

17、的迭代过程。通过一次次迭代的累 进，系统会增量式集成一些新的功能，直至整个系统功能的 完成。其中，每个迭代周期的测试工作由两方面内容构成： 对当前迭代周期产品的增量测试。对前迭代周期已完成功能的回归测试随着迭代周期的进展，测试工作的内容也在不断变化。早 期的迭代测试侧重于新函数的测试，后期的迭代测试侧重于 累积函数的回归测试。有的人不喜欢XP编程的开发方式，认为其没有明确的阶 段性划分，不利于计划管理，模式过于灵活，不好掌握。迭 代式开发模式为这些人提供了新的选择。这种开发方式继承 了瀑布式开发模式的优点一一全面、严谨、有计划性、易管 理，更重要的是，这种模式将测试工作分布到每个迭代周期 中，

18、使测试工作提前进行，从而使将发现软件缺陷的周期提 前，大大降低软件风险及开发本钱。测试过程的衡量测试过程在不断改进，但效果如何？我们如何衡量测试的 效果？我们需要引入一把尺子，一个衡量标准，从而把握测 试过程的改进方向。那么，如何收集数据，如何衡量呢？这 是我们困惑了很久的。我们不妨借助“他山之石”来想想方法，CMMI是当今 际流行的软件过程衡量模型，它在这方面是有自己的独到之 处的：1、面向全局。CMMI的测试度量面向的不仅仅是测试过程的改进，测试效果的加强，它面向的是整个开发过程，并 始终将质量监督放在工作首位。比方，它度量工作产品规模（例如代码行数），度量工作量和本钱（例如人工小时 数）。我们从中的数据对整个开发过程的改进都有指导 作用。更高的起点可使我们防止工程管理改进过程中常见的“头痛医头、脚痛医脚”毛病。2.建立测量数据库，完整、规范地保存提供的数据、分析 方法和结果。该数据库旨在持续改进软件开发过程。它的数 据是可重用的，可以被很多工程借鉴。而不是随着当前工程 的结束而消失，而是作为历史信息保存下来，从而为测试和 其他软件过程改进提供更加客