这里有两个问题需要注意：

1）在软件频繁改变的时候，可能进行全面测试吗？

　　实际上这是不可能的。不过，这个问题本身就有问题^_^，因为很多时候甚至都不可能在一个完全稳定的环境中测试软件。这个问题其实是想问：“在软件频繁变化的时候，能否进行有效的测试？”我们能否期望通过更好的使用人力和其他资源来完成这种测试？我们能否找到所期望的那么多缺陷？
　　通过对使用RAD方法的项目的观察，我发现软件测试过程对于发现缺陷是非常重要的，不同的过程会表现出不同的效果。因为大多数时候我们的开发过程都不是简单的重复，所以在RAD环境中就不能象其他环境那样——尝试着用各种方法到处看看能不能找到一些缺陷。

2）在软件频繁改变的时候，有哪些策略可以使用？

　　应该花些时间学习怎样在不同的环境下开展工作，不过在软件频繁改变的时候有些一般的策略还是可以参考的。

　　首先，你必须接受这个事实——你不可能有6周的时间对一个每天都在变化的软件进行测试——或者说你的老板不会允许你在每次软件改变后都用这么长的周期来进行测试。唯一的办法是你要定义一个可以快速有效的完成测试任务的过程。
   
　　进行风险评估。能够区分不同测试对象的风险级别是非常重要的，因为这样你就可以通过对不同的测试对象排列优先级，在那些很简单的问题上只花费较少的时间，而对更高的风险则给予更高的优先级和更多的时间以及其他资源。
   
　　必须有一个确定的工作版本（基线版本），以便于你在将来进行测试的时候可以进行比较。

　　自动化测试。使用捕捉/回放工具可以借助一些自动化特性帮助你来对软件进行回归测试。应该考虑花些时间和资金把一些工具融入到你的团队中，让大家都学会如何使用这些工具会对你的工作有所帮助。对于一个不愿引入新技术的组织——比如自动化测试工具——是很难在软件频繁改变期间完成测试的。这就像盖一座房子，手头上必须要有些合适的工具才行。
   
　　自动化工具只能对你的操作进行记录和回放，这是不够的。你必须明确业务需求，设计测试用例和测试过程，制定测试计划。另外，如果人们想在长期工作过程中获得比短期工作更多的好处，就需要考虑测试用例和测试脚本。

　　在软件频繁改变的时候进行测试不是不可能的，但是需要快速的响应、努力工作和维护对改变的跟踪。
   
　　在软件频繁改变时进行测试同样需要一个有创新思维的团队和过程，工具自己不会工作，只有在工作中由最优秀的人员在合适的时机使用才会产生最好的效果。使工具、人员和过程达到一个最理想的结合是一件非常有挑战性的事情.