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

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

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

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

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

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

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

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

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

　　测试新思路

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

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

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

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

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

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

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

　　有的人不喜欢XP编程的开发方式，认为其没有明确的阶段性划分，不利于计划管理，模式过于灵活，不好掌握。迭代式开发模式为这些人提供了新的选择。这种开发方式继承了瀑布式开发模式的优点――全面、严谨、有计划性、易管理，更重要的是，这种模式将测试工作分布到每个迭代周期中，使测试工作提前进行，从而使将发现软件缺陷的周期提前，大大降低软件风险及开发成本。

　　测试过程的衡量

　　测试过程在不断地改进，但效果如何，如何来衡量测试的效果呢？我们需要引入一把尺子，一个度量标准，这样才能把握测试过程的改进方向。那么，怎样来收集数据，如何来度量？这是我们长久以来一直困惑的地方。

　　我们不妨借助“他山之石”来想想办法，CMMI是当今国际流行的软件过程衡量模型，它在这方面是有自己的独到之处的：

　　1、面向全局。CMMI的测试度量面向的不仅仅是测试过程的改进，测试效果的加强，它面向的是整个开发过程，并始终将质量监督放在工作首位。比如，它度量工作产品规模（例如代码行数），度量工作量和成本（例如人工小时数）。我们从中搜集的数据对整个开发过程的改进都有指导作用。更高的起点可使我们避免项目管理改进过程中常见的“头痛医头、脚痛医脚”毛病。

　　2、建立度量数据库，从而对搜集的数据、分析的方式及结果进行完整、规范的保存。这个数据库面向的是软件开发过程的持续改进，它的数据是可复用的，可供多个项目参考使用，不随当前项目的结束而消失，而是会作为历史信息持续保存，从而为测试及其他软件过程的改进提供更客观、更全面的度量数据。

　　3、关注度量、分析过程的改进。度量过程是为了对测试及其他软件过程的改进提供参考依据，它自身运作方式的合理性直接会影响度量结果的准确性。CMMI避免了 “灯下黑”现象的出现，它没有忽略测量分析度量过程的改进，它会定期召集受影响的受益者一起审查初始分析结果，总结本过程运作中遇到的经验教训，从而对度量过程方式进行改进，保证度量结果的正确性，可参考性。

　　CMMI度量方式的优点往往是我们所忽略的，我们应尽力学习它的这些长处，这对软件测试过程的改进会很有帮助。

　　结束语

　　测试很重要，它是检验开发结果是否接近预期目标的重要手段，但我们应清楚地认识到：它毕竟只是一种信息反馈过程，作为软件质量的守护者，它可以发现缺陷，但无法避免缺陷的发生，我们不能将软件质量的安危都押在测试这个砝码上。

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