在过去的一年，项目组推行自动化测试工作，从目前的实际成果上看，感觉效果不是很理想。我们的系统是基于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架构下界面不稳定，自动化用例脚本维护工作量大的问题；