假如需求不断改变时该如何处理呢？

What can be done if requirements are changing continuously?
This is a common problem for organizations where there are expectations that requirements can be pre-determined and remain stable. If these expectations are reasonable, here are some approaches:

• Work with the project's stakeholders early on to understand how requirements might change so that alternate test plans and strategies can be worked out in advance, if possible.
• It's helpful if the application's initial design allows for some adaptability so that later changes do not require redoing the application from scratch.
• If the code is well-commented and well-documented this makes changes easier for the developers.
• Use some type of rapid prototyping whenever possible to help customers feel sure of their requirements and minimize changes.
• The project's initial schedule should allow for some extra time commensurate with the possibility of changes.
• Try to move new requirements to a 'Phase 2' version of an application, while using the original requirements for the 'Phase 1' version.
• Negotiate to allow only easily-implemented new requirements into the project, while moving more difficult new requirements into future versions of the application.
• Be sure that customers and management understand the scheduling impacts, inherent risks, and costs of significant requirements changes. Then let management or the customers (not the developers or testers) decide if the changes are warranted - after all, that's their job.
• Balance the effort put into setting up automated testing with the expected effort required to refactor them to deal with changes.
• Try to design some flexibility into automated test scripts.
• Focus initial automated testing on application aspects that are most likely to remain unchanged.
• Devote appropriate effort to risk analysis of changes to minimize regression testing needs.
• Design some flexibility into test cases (this is not easily done; the best bet might be to minimize the detail in the test cases, or set up only higher-level generic-type test plans)
• Focus less on detailed test plans and test cases and more on ad hoc testing (with an understanding of the added risk that this entails).

If this is a continuing problem, and the expectation that requirements can be pre-determined and remain stable is NOT reasonable, it may be a good idea to figure out why the expectations are not aligned with reality, and to refactor an organization's or project's software development process to take this into account. It may be appropriate to consider agile development approaches.

对于希望需求能够事先定义和保持需求稳定的企业来说这是一个普遍存在的问题。假如需求改变是合理的，这有一些方法：
1、尽早与项目管理员合作理解可能要改变的需求，及早采取相应地的措施调整测试计划和策略。
2、假如应用程序在开始设计时就考虑了需求改变时应用程序不需要做很大的调整的灵活设计则是很有益处的。
3、假如代码中有比较好的注释和文档，则开发人员改变起来比较容易一些。
4、使用一些快速原型的开发方法可以帮助客户确认需求，减少后期的改变。
5、在项目的计划中为可能的需求改变留出一些额外的时间。
6、尽量把新的需求放在应用程序的第二个版本中实现，而在第一个阶段中使用原来的需求。
7、在讨论中允许一些容易实现的新需求添加到项目中，而把一些难于实现的需求放在后面的版本中实现。
8、确保用户和管理者理解项目时间计划，潜在的风险和重大需求改变的价值。让管理者和用户（不是开发人员或测试人员）来决定改变是否批准－毕竟，这是他们的工作99、权衡需求改变时投入到设置自动化测试时重新构造期望结果的付出。
10、尽量在测试脚本中设计一些灵活的方式。
11、重点在应用程序最有可能不修改的地方使用自动化测试。
12、投入一定的精力进行需求改变的风险分析，减少回归测试。
13、设计灵活的测试用例（这通常不容易做到，最好的方式是在测试用例中减少细节或者建立高水平的通用测试计划）。
14、在设计测试计划和测试用例中少关注细节，而更多的关注异常测试（这样也要理解附加的风险）。

假如这是一个一直存在的问题，并且期望的需求能够前期决定和确保稳定是不可能的，规划出期望的结果与实际结果可能不一致是一个好主意，并且花时间详细重构一个公司或项目的开发过程。这可能是相当所谓的敏捷开发方法。

本FAQ的翻译有几处没有搞太明白，请大家只是参考或给出建议。