会员登录
会员注册
这样做的后果进一步导致了测试工作的无序和混乱，测试过程缺乏计划性，测试人员缺乏技术能力，缺乏对架构的了解，相关素质的缺失使他们成为技术人员的附庸。测试对于他们来说，是一种枯燥的“手+眼”式的工作，他们唯一渴望的，是将无聊的测试尽快完成，从而远远的逃离。这样的测试结果可想而知。
其实，软件工程对测试人员的素质要求是很严格的，比如：要有相关计算机知识背景、具备软件工程基本知识、熟悉项目编程语言、熟悉项目技术架构及需求内容、工作有责任感、独立分析能力及团队精神等等。真正规范的软件项目对于测试人员的要求是不会低于技术人员的，而且会为测试人员提供进一步的知识培训机会，以应对各种项目的复杂情况。
7、 测试进度的错误估算。
在项目开发中，领导为督促测试的进程，往往会让项目组汇报工作进度，了解已经
完成的工作占比，从而对工作进度做出判断。我对这种工作方式完全拥护，只是觉得这种方式还有不足。
测试进程不是简单的1+1过程，不能武断地认为“我用8天干完了80%的工作，那么，剩余工作便能在2天内干完”。著名的Pareto80/20规律告诉我们：测试发现的所有错误中的80%很可能集中在20%的程序模块中，另外20%很可能集中在80%的程序模块中。
所以，没有对测试对象认真分析的基础，单凭工作完成数量而对工作进度做出的的判断往往是错误的。
我认为，“工作实际进度=工作完成量占比+测试对象的错误占比分析”才是一个较合理的测试进度估算方式。
测试新思路：
项目的开发风险来自于对需求的误解，来自于设计与开发过程及产品的缺陷，只有尽早发现这些缺陷，才能降低并控制项目风险。基于这种思想，软件业出现了一些新的测试思路，主要有二：
1、测试驱动开发(Test-Driven Development，简称TDD)。这种测试思想被最近流行的XP(Extreme Programming)极限编程方式所大力提倡。它的基本思想是，通过测试来为编程做指导，在某个要开发的需求对象明确之后，在编码之前，先进行相关测试代码(测试代码的内容和需求规格说明书描述是相同的，有人把它称为“可执行的需求规格说明书”)的编写工作，完成之后针对测试代码进行编程，然后再用测试程序对开发代码进行测试，验证其正确性，若程序通过了测试，就说明它是符合需求规格说明书要求的。周而复始，通过这样的过程，开发进程得以层层深入，直到开发完成。而这时单元测试也基本完成了。
这种测试方式的最大的好处是，尽早地发现设计、开发中存在的问题，避免传统开发模式中的“测试过程中发现代码不能满足需求而导致的大量返工”。降低项目风险;同时可以尽早地将“半成品”展示给客户，使客户对需求进行验证、补充及完善，另外测试代码的表达方式相对准确、无二义性，可以降低因需求理解错误而导致的项目风险。
2、迭代测试。这种测试是IBM所推崇测试方式之一，它从迭代式开发模式演变而来。在迭代开发模式中，每个迭代都包含需求、设计、编码、集成、测试等过程。在每一次迭代完成之后，便会开始新的迭代过程。通过一次次迭代的累进，系统会增量式集成一些新的功能，直至整个系统功能的完成。其中，每个迭代周期的测试工作由两方面内容构成：