这个时候工程师们就动起了脑筋：既然Web界面和WebService界面对于后台而言是相同的，也就是说Web界面的测试和WebService界面的测试可以共享测试的过程（Scenario）和数据（Data），只是具体实施操作的时候有所不同。这不就是设计模式中的策略模式吗？没错，把逻辑操作（这里是测试步骤）抽象出来，可以在运行时切换具体实现的，就是策略模式。具体而言呢，对WebService的各种操作实现就是一个策略，对Web界面的操作实现也是一个策略。当工程师们实现自动化测试用例的时候，他们并不关心他在通过Web还是通过WebService做操作，他们只关心的是：用什么数据，做什么步骤。至于怎么做，是运行时根据环境决定的。这其中的关系可以用下面的图表示：

　　基于在我所在项目组的实践，我们发现利用策略模式的好处有：

　　1） 同样的自动化测试用例可以同时测试Web界面和WebService界面，成倍的简化了自动化测试代码的编写工作。

　　2） 清晰的分离了“做什么”和“怎么做”。编写测试代码可以更关注测试的步骤和逻辑。

　　3）在项目的初始阶段，WebService界面的操作会比较稳定，而Web界面往往会由于复杂度更高而不稳定。这时候可以使用WebService策略开发并运行自动化测试，等到Web界面稳定了，再把环境变量设为Web策略，就可以完全测试Web界面了。而常规的做法，如果Web界面不稳定，甚至只是某一个模块不稳定，就会减慢或阻碍整个团队的测试开发，进度大大受阻。

　　4） 当运行一个Web界面测试的时候，如果测试结果失败，可以动态调整为使用WebService策略重新测试。这样可以“自动”地帮助开发测试人员定位问题发生在Web层还是在WebService层。

　　5） 整体测试框架具有较高的扩展性。如果产品需要新增PowerShell作为另一个用户界面，那么只需要实现PowerShellTestStrategy，就可以让大多数测试用例运行在PowerShell上。

　　在微软，其实还有很多做高效测试的例子，下次有机会再拿出来晒吧。