现在在测试行业，对测试人员来讲，最受困扰的问题之一就是测试的设计工作都做完了，结果需求又发生了变化，原来做的很多工作不得不重新开展，一方面测试的进度受到了影响，另一方面，也让测试人员身心疲惫。我们是否分析过：这种现象产生的原因是什么？面对这样的风险，我们采取怎样的策略来应对，从而最好完成测试任务？欢迎大家讨论交流！
回答：
我现在也是常为需要变更感觉头疼。
1、需求变更后，首先要向需求人员及开发人员了解，为什么需求要做变更，了解客户真正的需求。
2、其次，向开发人员了解本次需求变更，都改却了哪些模块。会影响到哪些模块。
3、询问开发进度
4、整理测试计划及测试用例，确认哪些模块应该重点测试。
5、展开下一步的测试工作。并确定测试时间。
6、通过本次需求变更，测试人员要总结经验，尽量站在客户的角度进行测试。在客户没有发现不能满足需求时，测试人员先提出来。当然，需求人员及开发人员也要从中吸取教训。
我相信，如果每一次都能从需求变更中吸取教训，相信以后开发及测试出来的软件质量会更好的。
回答：
这是一个常见的令人头疼的问题。
如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。
如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。
好的代码注释和好的文档有助于开发人员作出相应的改变。
只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。
在项目的时间表中应当留出余量，以应付可能出现的变更。
尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。
通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。
要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。
在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。
在设计自动测试剧本时，试图使其有一些灵活性。
在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。
对变更进行适当的风险分析，以减少回归测试的要求。
在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。
少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。
PS
需求变更测试人员应怎样进行有效的处理
每个公司，甚至每个项目都有可能有不同的方式来处理这个问题。
对于测试人员来说，最为重要的一点其实就是心理的适度调整。
诚然，需求的变更导致自己的很多工作都成了无用功，很多东西要从头做起。
但是一定不要抱怨，因为那样解决不了问题，事实就是事实。已经无法更改。需求方开发方任何一个都希望项目从立项一开始就按部就班的做下去，不会有任何的变化。没有人喜欢需求的变化，但是计划总是没有变化快的。所以首先要调整的就是心态。要有积极地心态，全新的去面对新的需求。分析，设计，一切重来。
文章来源于领测软件测试网 https://www.ltesting.net/