随着需求不断变更、补充，业务、技术人员忙于应付，无法腾出精力来进行文档内容的修改及完善，往往是将包含需求变更内容的工作联系单往需求文档后一附了事，而不去更新需求与其他相关文档；另一方面，项目变更管理还不够完善，管理重点往往集中于开发，而轻视文档质量管理，未留出充分的文档更新时间，导致文档更新严重滞后于编码进度。为保证文档质量，必须定期进行文档测试，但测试要花成本，项目高层不愿意付此代价。项目管理者联盟
文档若可读性低，便会影响用户的理解；若与编码不一致，便起不到参考作用，编码测试没有可靠的测试依据。路都看不清楚，怎么往前走呀？所以，强烈建议进行文档测试，并将其置于测试管理的首位。当前文档测试的方法没有什么特别的形式，还缺乏测试工具支持，通常是通过静态审查方式――“走查”来进行的，主要查看文档的可读性，内容真实性、可靠性、全面性。另外，在项目里程碑时期召集相关领域专家对重要文档进行集中审核，也是一种检查方式。
 
3、 单元测试应引入交叉测试方法；
单元测试是对软件基本组成单元进行的测试，测试对象是软件模块。通常，单元测试是由开发人员来完成，而且往往是各人测各人的。这存在问题隐患。
为什么呢，技术人员是软件模块的制造者，自己来测自己的软件的话，角色便从制造者变成了审查者，而前一个角色的目的是为了保证软件正确，后一个角色的目的是为了发现更多的缺陷，让一个人同时来扮演两种目的不同的角色，好比让他既当裁判员又当运动员，怎么能做好呢？解决方法通常有两种，一种是：由测试人员来进行单元测试，这种方式要求测试人员要有较高的软件技术知识；另一种是：将软件人员分组，在模块开发告一段落时进行交叉测试，这种方法只需要测试者了解被测方的软件需求，不需要另外的知识培训，而且测试出发点较为客观，所以被较普遍的推广使用。

4、 测试在开发基本完成才启动；项目管理培训
在传统的瀑布型开发模式中，软件测试位于编码阶段之后，是作为一个独立阶段存在的，许多人便一刀切地认为应该将所有的测试工作在编码完成后再开始。这个观点要不得，原因有二：
首先，若将测试工作细分，有许多工作是可以提前先期执行的，如：需求书与设计书的学习、测试计划的制定、测试人员的培训、测试脚本的建立、测试资源的搭建、测试模板的创建、测试工具的选择等等，都是可以与其他阶段并行处理的，这将大大缩短项目开发时间，为测试提供充分的时间保障，提高测试质量。

其次，软件缺陷发现的越晚，修改、补救所耗费的成本越高。引用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所推崇测试方式之一，它从迭代式开发模式演变而来。在迭代开发模式中，每个迭代都包含需求、设计、编码、集成、测试等过程。在每一次迭代完成之后，便会开始新的迭代过程。通过一次次迭代的累进，系统会增量式集成一些新的功能，直至整个系统功能的完成。其中，每个迭代周期的测试工作由两方面内容构成：
? 对当前迭代周期产品的增量测试。
? 对前迭代周期已完成功能的回归测试。
随着迭代周期的累进，测试工作内容随之不断变化。早期迭代测试重点在于新功能的测试，后期迭代测试重点在于累积功能的回归测试。