高效率测试之巧用策略模式

发表于:2015-04-29来源:uml.org.cn作者:不详点击数: 标签:功能测试
做过测试工作的人或许都知道,测试一个产品的工作量是比其开发的工作量要大得多的(在微软,一个团队测试人员的数目与开发人员的理想的比例是1.5 比1)。

  做过测试工作的人或许都知道,测试一个产品的工作量是比其开发的工作量要大得多的(在微软,一个团队测试人员的数目与开发人员的理想的比例是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上。

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

原文转自:http://www.uml.org.cn/Test/201005062.asp