1、质量保证将不可控。如果长期对测试用例的维护不及时，会导致用例的不完善及不完全正确性。逐渐地，用例也失去了本身的意义。

　　2、不利于工作的交接

　　3、不利于工作完善及总结

　　下面我简单谈谈实际工作中，对于整个维护项目的测试管理流程。

　　首先，维护项目也会有需求文档，不过相对产品项目而言，一般都比较零散。所以，对于维护项目的需求准备 要求更高。因为文档中不会描述新需求对原系统产生的影响，而这个影响有可能是极不易于发现的。如果时间允许，建议先熟悉原系统，再充分理解新需求，了解各 个点对原系统存在的关联。理清了所有这些，下一步便是编写测试用例了。

　　或许有不少同行会认为，维护项目的工作量不大，也许简单的几轮测试就结束了，何必写测试用例这么麻烦 呢。那你就错了。写用例，不但在测试之前，可以督促我们充分理解需求，理清思路进行测试准备，它还可以提供给需求进行评审，进一步保证测试完整性、正确 性，还可以为将来测试提供参考等等。写用例的好处之多，在此不再赘述。

　　在了解需求过程中，PM有可能在做项目进度计划。作为测试人员，我们需要综合考虑开发的难度系数、开发强度、开发人员对系统的熟悉程度等。以此估计送测质量，做好测试部分的进度计划，提供给PM。与PM协商出更具可执行的计划。

　　我个人感觉，整个维护项目的工作重心就是写用例、做计划。如果做好这两件事，后面的工作则轻松很多。基本按步就班进行即可。开发完成，送测，按用例执行测试。

　　每一轮测试结束后，我们也要花点时间去整理自己的思路，这样测是否已经完善了，是否还有测试点没有考虑到，抱着怀疑的态度去思考，或许你会发现一些亮点。 如果条件允许，我还建议进行交叉测试。当我们发现需要补充测试用例时，千万记住：记下要点，测试完成后，完善用例，使其逐渐强壮。每一次的完善，我们的思 维也得到相应提升。周而复始，直到项目质量达到预期结果。如果这个结果与计划基本吻合，那基本上可以说这个维护项目的测试任务完成得很完美。