对测试人员来讲，最受困扰的问题之一莫过于测试的设计工作都做完了，结果需求又发生了变化，原来做的很多工作不得不重新开展，一方面测试的进度受到了影响，另一方面，也让测试人员身心疲惫。我们是否分析过：这种现象产生的原因是什么？面对这样的风险，我们采取怎样的策略来应对，从而最好完成测试任务？

一般需求变更以后，都要遵循下面的一些做法：

需求变更后，首先要向需求人员及开发人员了解，为什么需求要做变更，了解客户真正的需求。

其次，向开发人员了解本次需求变更，都改却了哪些模块。会影响到哪些模块。

询问开发进度

整理测试计划及测试用例，确认哪些模块应该重点测试。

展开下一步的测试工作。并确定测试时间。

通过本次需求变更，测试人员要总结经验，尽量站在客户的角度进行测试。在客户没有发现不能满足需求时，测试人员先提出来。当然，需求人员及开发人员也要从中吸取教训。

在项目的时间表中应当留出余量，以应付可能出现的变更。

尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。

通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。

 

要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。

对变更进行适当的风险分析，以减少回归测试的要求。

在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。