对于刚开始做自动化测试的新手，一个很大的烦恼是如何开始的问题。面对心中澎湃的激情和老板殷切的希望，很容易陷入两个极端。

第一个极端是“over design”，是试图在一个framework里解决所有的问题。这样的后果一是framework必然要引入更多的抽象层导致framework变得复杂而丑陋，第二个是前期工作量非常大，可能很长时间连一个可以跑的demo都拿不出来。

另一个极端是不讲设计，没有任何framework，一个script是一个case。这样快倒是快，但很多重复的代码分布在各个script里完成类似的功能，后期维护简直是灾难。。

这里问题的核心是，你如何来界定一个自动化测试程序的范围呢？一个程序解决所有case不行，一个case一个程序也不行。你必须要确定一个自动化测试程序要解决的范围。在这个范围里，既能设计一个framework能兼容所有的testcase，取得大的代码重用效果，又不至于把framework搞成一个复杂难懂的怪物。

其实这里有一个很简单好用又有效的方法。那是根据“数据驱动”的testcase来定义你的自动化测试程序。如果你发现了一套testcase可以用，或者已经用，数据驱动的形式定义的，那么把它作为你自动化的对象。

说这个方法简单好用是因为它一点也不复杂，testcase是已经现成设计好的，不用花心思来决定“留”和“舍“那些testcase的问题。说它有效是因为

1）一套testcase既然能设计成使用数据驱动的形式，那么他们必然有类似的测试逻辑。因此framework也不会很复杂，那么做出来第一个能跑demo也相应会比较快。

2）第二个好处是有大量的testcase能自动化起来。因为有类似的测试逻辑，如果自动化了1个case，那么剩下的9个case差别相当小。自动化10个case显然比自动化1个case更能获得老板的认可。。。

3）第三个好处是，一般来说越是核心的功能，测试越彻底，那么数据驱动集也会越大。如果你首先挑上这样的一套testcase，那么自动化程序的价值也相应的更大。

不仅仅是对于新手。任何时候当出现“狗咬乌龟，无从下口“的时候，都可以应用这个方法。我在前段时间做的一个项目，也采用了这种方法。原因是测试的需求不清楚。我得到的任务是对某个包含多个子功能的功能开发自动化测试程序，但具体要自动化哪些case，有什么样的milestone根本不清楚。这个时候，我选择了一个用data driven的大的一个testcase集合。我能确定这一套testcase肯定是要自动化的，所以我不会花时间在错误的地方；然后我能很快拿出一个可以跑的demo给客户看看，让他对自动化测试的效果有了实际的认识，帮助他更好的提出自己的需求。