软件质量守护——测试管理[3]

　　软件质量守护——测试管理[3]  软件测试

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

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

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

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

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

　　7、 测试进度的错误估算

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

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

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

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

　　测试新思路

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

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

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

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