需求分析
1. 需求人员需要何时参加需求分析？
如果条件循序原则上来说是越早介入需求分析越好因为测试人员对需求理解越深刻对测试工作的开展越有利 可以尽早的确定测试思路 减少与开发人员的交互 减少对需求理解上的偏差原则上，测试人员对需求了解得越深入对测试工作越有利，所以最好一开始就应该参加需求分析工作。这样做可以 带来如下好处：
- 测试人员全程参与需求分析，对需求了解得很深入，减少了很多与开发人员的交互，节省了时间。测试人员参与前期开发讨论，直接掌握了不清晰的需求点。
- 早期确定测试用例的编写思路，为测试打好基础
- 可以获取一些测试数据，为测试用例设计提供帮助
- 可以发现需求不合理的地方，降低了测试成本。
- 测试人员主要的工作之一就是确认系统是否正确实现了需求。
2. 如果需求一直在变化怎么办？
这是一个常见的令人头疼的问题。
- 如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试 计划和策略。
- 如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再 为改变做很多事情了。
- 好的代码注释和好的文档有助于开发人员作出相应的改变。
- 只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。
- 在项目的时间表中应当留出余量，以应付可能出现的变更。
- 尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。
- 通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。
- 要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金 消耗。
- 在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。
- 在设计自动测试剧本时，试图使其有一些灵活性。
- 在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。
- 对变更进行适当的风险分析，以减少回归测试的要求。
- 在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。
- 少注意详细的测试计划和测试案例，要把重点放在专门的测试上。