软件质量守护――测试管理(2)

　　首先，若将测试工作细分，有许多工作是可以提前先期执行的，如：需求书与设计书的学习、测试计划的制定、测试人员的培训、测试脚本的建立、测试资源的搭建、测试模板的创建、测试工具的选择等等，都是可以与其他阶段并行处理的，这将大大缩短项目开发时间，为测试提供充分的时间保障，提高测试质量。

　　其次，软件缺陷发现的越晚，修改、补救所耗费的成本越高。引用Boehm在《Software Engineering Economics》一书中的话――“平均而言，如果在需求阶段修证一个错误的代价是1，那么，在设计阶段就是它的3-6倍，在编程阶段是它的10倍，在内部测试阶段是它的20—40倍，在外部测试阶段是它的30-70倍，而到了产品发布出去时，这个数字就是40-1000倍。”由此可见，测试目标的最佳定位应该是：在错误第一次出现的时候就捕捉到它。所以，在尽可能的情况下，测试越早展开越好。

　　在项目的各个进行阶段，都有不同的项目产品产生，他们质量的好坏，对后续开发影响重大，所以，现在国际上比较流行的做法是：将测试融合到各个开发环节中去，尽早测试。

　　5、 测试案例、测试方案的重用率低下。

　　传统的测试过程，测试管理不严密，测试人员未建立完整的测试库，未将测试案例、测试程序、测试方案进行有效保存，等到回归测试时，相关测试程序等往往已不知所终，无处可寻了;即使能找到这些程序、案例，可往往因为回归测试过于频繁、项目期限日益迫近，已经没有时间余量来修改、完善这些程序及案例，只能凭借经验、记忆及技术人员的口述对程序修改过的地方草草重测一遍而已，缺乏正规化的测试过程，造成测试的虎头蛇尾。

　　正常的测试案例使用方式如上图，测试设计阶段，相关测试设计人员会对测试对象进行了解、分析，为保证测试顺利进行，保证测试覆盖尽量多的测试对象，会设计测试案例、测试方案，在测试期间进行使用;测试发现错误时，软件技术人员会根据测试的缺陷反馈结果及技术人员的软件修改信息对测试程序进行修改，完毕后再进行回归测试。

　　6、 测试人员素质低，缺乏相关知识培训。

　　项目管理人员对测试存有偏见，对于测试的重要性认识不足，导致其严重忽略测试人员的选拔和知识培训。许多软件项目让软件用户或新招收的技术人员来完成测试工作，他们认为测试人员的工作很简单，就是技术人员让测什么就测什么，它基本是一个动手不动脑的工作。

　　这样做的后果进一步导致了测试工作的无序和混乱，测试过程缺乏计划性，测试人员缺乏技术能力，缺乏对架构的了解，相关素质的缺失使他们成为技术人员的附庸。测试对于他们来说，是一种枯燥的“手+眼”式的工作，他们唯一渴望的，是将无聊的测试尽快完成，从而远远的逃离。这样的测试结果可想而知。

　　其实，软件工程对测试人员的素质要求是很严格的，比如：要有相关计算机知识背景、具备软件工程基本知识、熟悉项目编程语言、熟悉项目技术架构及需求内容、工作有责任感、独立分析能力及团队精神等等。真正规范的软件项目对于测试人员的要求是不会低于技术人员的，而且会为测试人员提供进一步的知识培训机会，以应对各种项目的复杂情况。

　　7、 测试进度的错误估算。

　　在项目开发中，领导为督促测试的进程，往往会让项目组汇报工作进度，了解已经完成的工作占比，从而对工作进度做出判断。我对这种工作方式完全拥护，只是觉得这种方式还有不足。

　　测试进程不是简单的1+1过程，不能武断地认为“我用8天干完了80%的工作，那么，剩余工作便能在2天内干完”。著名的Pareto80/20规律告诉我们：测试发现的所有错误中的80%很可能集中在20%的程序模块中，另外20%很可能集中在80%的程序模块中。

　　所以，没有对测试对象认真分析的基础，单凭工作完成数量而对工作进度做出的的判断往往是错误的。

　　我认为，“工作实际进度=工作完成量占比+测试对象的错误占比分析”才是一个较合理的测试进度估算方式。

　　测试新思路：

　　项目的开发风险来自于对需求的误解，来自于设计与开发过程及产品的缺陷，只有尽早发现这些缺陷，才能降低并控制项目风险。基于这种思想，软件业出现了一些新的测试思路，主要有二：

　　1、测试驱动开发(Test-Driven Development，简称TDD)。这种测试思想被最近流行的XP(Extreme Programming)极限编程方式所大力提倡。它的基本思想是，通过测试来为编程做指导，在某个要开发的需求对象明确之后，在编码之前，先进行相关测试代码(测试代码的内容和需求规格说明书描述是相同的，有人把它称为“可执行的需求规格说明书”)的编写工作，完成之后针对测试代码进行编程，然后再用测试程序对开发代码进行测试，验证其正确性，若程序通过了测试，就说明它是符合需求规格说明书要求的。周而复始，通过这样的过程，开发进程得以层层深入，直到开发完成。而这时单元测试也基本完成了。

　　这种测试方式的最大的好处是，尽早地发现设计、开发中存在的问题，避免传统开发模式中的“测试过程中发现代码不能满足需求而导致的大量返工”。降低项目风险;同时可以尽早地将“半成品”展示给客户，使客户对需求进行验证、补充及完善，另外测试代码的表达方式相对准确、无二义性，可以降低因需求理解错误而导致的项目风险。

　　2、迭代测试。这种测试是IBM所推崇测试方式之一，它从迭代式开发模式演变而来。在迭代开发模式中，每个迭代都包含需求、设计、编码、集成、测试等过程。在每一次迭代完成之后，便会开始新的迭代过程。通过一次次迭代的累进，系统会增量式集成一些新的功能，直至整个系统功能的完成。其中，每个迭代周期的测试工作由两方面内容构成：

　　· 对当前迭代周期产品的增量测试。

　　· 对前迭代周期已完成功能的回归测试。

　　随着迭代周期的累进，测试工作内容随之不断变化。早期迭代测试重点在于新功能的测试，后期迭代测试重点在于累积功能的回归测试。

原文转自：http://www.ltesting.net