做过测试工作的人或许都知道，测试一个产品的工作量是比其开发的工作量要大得多的(在微软，一个团队测试人员的数目与开发人员的理想的比例是1.5 比1)。做过测试工作的人也一定知道，这个“1.5倍”的黄金比例由于开发进度，项目需求的原因常常不容易满足——即使是在微软，这样一个对软件测试有巨大投入的公司。可以想象，一边是紧迫的项目进度，一边又是必须提供给用户最高质量产品的不可侵犯的原则，这事儿对测试团队就是一个地地道道的“杯具”。所幸的是，微软的工程师们总能绞尽脑汁，螺蛳壳里做道场，榨干每一行代码、每一个测试用例的价值，最终把“杯具”变成“洗具”。下面就给大家讲一个我参与的项目中利用策略模式(Strategy Pattern)做更高效测试的例子。

　　首先介绍一下产品背景。该产品是典型的数据库 -> WebService -> Web三层架构，其中WebService和Web界面均是提供给用户的开放接口，而他们提供的操作都是针对对象的创建，读取，更新和删除。对我们测试团队而言，WebService和Web两种用户访问界面是必测无疑的。这两种界面的具体操作完全不同，譬如在Web界面上创建对象需要填写并提交表单，而在 WebService界面中则是一个WCF(Windows Communication Foundation)的调用，但是他们对后台而言则是完全相同的。可以用下面这个图来表示。

　　这时候工程师们就动起了脑筋：既然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上。

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