清晰得记得，2007年的测试组例会，我们讨论的多的问题是，需求变更太多，导致我们测试工作量增多，产品发布日期一再拖延。

　　花费时间编写了详细的测试用例，可是突然重要功能需求变更了，那么需要重新修改；

　　构造好了测试数据，可是计算规则发生了变更，整个数据有需要重新来设计构造；

　　临近产品发布了，需求变更，加入了影响重要的功能，导致产品稳定性变差，需要全部回归测试；

　　......

　　导致了无休止的加班，发布日期不断的延迟。

　　后来我们项目组开始敏捷，测试组也提倡“拥抱需求的变更，更主动地去参与变更”。测试组的具体措施是：用例简化、程序员按照测试要点开发功能、自动回归测试、积极沟通等。取得了一定的效果。

　　现在，我们的项目开发团队在印度，测试团队在我们公司。怎么处理这样的问题：

　　花了一个星期理解了需求、完成了用例、构造了测试数据。这时候，那边过来新版本需求文档，更改了计算规则，那么需求需要重新理解、用例和数据需要重新构造。这需要大量的时间。这种问题以前常出现，以后还会常出现，我们如何解决。

　　用例：开发编码的时期，我们工作量的好体现是测试用例，可是如果简化了用例，如何来体现我们的工作量。

　　测试数据：版本发布后，我们的测试时间会很紧张，所以要提前构建好大量的测试数据，等待版本发布测试更快些。可是这些构造好的测试数据一旦面临变更，那么维护起来也甚是麻烦。

　　如果让程序员按照测试要点来开发功能，那么我们测试人员对于需求的掌握要不低于程序员，可是目前还是比较难实现，因为我们的需求相关问题全是从程序员哪里获取的。除非我们可以直接面对客户，而且还要有深厚的业务背景知识。

　　那么我想可以从以下几个方面着手解决：

　　● 测试数据构造，减少手动操作，尽量自动构造；

　　● 用例编写，每个用例都沟通明确，且记录变更，准确计算需求变更导致的用例维护时间，可以分清责任；

　　● 提高自动测试程度，由于需求变更，需要进行的大量回归测试自动执行，节约时间和人力；

　　● 沟通：不怕麻烦，确认细节，减少理解误差造成的问题。

　　● ......

　　当然光靠上面几点可能不是很好解决问题的，刚参与这个项目，需要了解的东西还很多，因此还需要根据实际情况来解决问题。时刻记住“测试是不要怕麻烦”，问题总会解决。