在过去的一年，项目组推行自动化测试工作，从目前的实际成果上看，感觉效果不是很理想。我们的系统是基于J2EE B/S架构的软件系统，目前的问题主要具体体现在以下几个方面：

1. 自动化用例脚本编写复杂费时。以前一个人一天只能写6个用例，目前一天最多也只能编写20个用例。一个Story的开发周期是3到5天（含简单设计、编码及开发自测）。一个Story平均有80个测试用例，测试人员的精力大部分都要花在自动化脚本的编写上，而不是更应该关注的“测试用例设计”上。

2. 基于B/S的自动化用例脚本编写复杂。虽然有工具支撑，但目前的前台界面技术也是日新月异，对于一些界面元素工具不能很好的支撑，有针对工具的二次开发工作量。且很多复杂的组合界面，即使进行二次开发也无法很好的支撑。基于界面驱动的自动化测试很容易遇到瓶颈与阻塞。

3. 受需求影响，界面不稳定，经常变化。这点可能不具有普遍意义，但目前我们的系统受需求影响较大，界面经常变化，界面稳定度不高。这也导致每个新版本都会导致大量的自动化用例脚本维护工作量。

4. 开发与测试配合不顺。由于一个Story只有开发完毕后，界面才会稳定下来（在当前版本内），此时，测试人员已无太多的时间去进行自动化测试脚本的编写。这也是导致自动化用例覆盖率不高的原因。

5. 基于界面的自动化脚本运行效率低。大致80多个自动化用例就需要执行5个小时。如果2000多个用例都进行了自动化，那么执行时间将非常不可接受。根本无法做到每日持续集成的快速、完整测试。

6. 软件架构上的问题。另外，我个人认为更为关键的问题是，现有的自动化测试都是基于现有的系统架构开展的。很多解决方案都是基于现有架构做适配的。也就是说，系统的架构从一开始就没有考虑到对可自动化测试的支撑考虑。并且，我认为在架构上进行适当的重构，甚至是可以解决前面5个主要问题中的大部分场景。（系统架构是我在05年中制定的，几年下来，已不能适应最新的要求了）

基于以上目前存在的问题，初步设定了以下自动化测试优化的目标：

*目标一：自动化测试用例覆盖率要能提高到至少80％以上，且所有的自动化测试脚本的执行时间能控制在5小时以内；

*目标二：测试人员在自动化用例脚本编写上花费的时间要减少30％，以便有更多的精力能投入在测试设计上；

*目标三：在Story的开发阶段，编码及自动化用例脚本能同步进行，Story开发完毕后即可开始每天持续的自动化测试；

*目标四：解决b/s架构下界面不稳定，自动化用例脚本维护工作量大的问题；

在前文中，主要是描述了一下目前在自动化测试工作开展中主要面临的问题与困难，并设定了一个初步的目标。在接下来的文章中，我将重点阐述一下在系统架构方面应该如何考虑自动化测试要求，即DFX中的可测试性要求。

在对系统架构优化和动手之前，我们首先要做的是对自动化测试进行深入的理解。对基于B/S架构的J2EE系统，大部分人在做自动化测试时，基本都是在做和研究如何从界面驱动进行一次业务测试。这其实是一种误区，自动化测试是需要分层分级的。我们可以从下表中看出测试的分类：

测试类型	白盒/黑盒
ST	黑盒
IT	黑盒
UT	白盒

* UT是单元测试，是基于方法级的，属于白盒测试；

* IT是集成测试，是基于业务服务级的，属于黑盒测试；层次要比UT高；

* ST是系统测试，是基于业务服务及功能使用场景下的测试，也是属于黑盒测试；层次要比IT高；

UT的测试关注主体是开发人员，而且也每什么难度，UT的自动化也非常容易，这里就不再阐述。

如果软件架构不清晰，那么IT和ST之间的界限将会比较模糊，自动化测试往往就会跳过IT直接进入ST测试自动化中。而ST是基于复杂使用场景下的测试，这又导致ST的自动化脚本编写异常复杂，且易随着场景的变化而变化。

举个例子：各位可以通过登陆www.blogger.com登陆自己的博客撰写博文，也可以iphone上的博客客户端方式来写博文，其使用场景在例子中就有两种：1、登陆blogger提交博文 2、通过客户端程序提交博文。并且，更为头疼的是，我们不知道这种使用场景还有多少，这是无法穷举的。但google是怎么做到无论使用场景有多少，形式如何，最终仍能提供优质、稳定的博客服务呢？

从上面这个例子中，你是否悟出了些什么呢？