本条产品线基类指的是本次新增加的功能，但是其他大部分的测试类不会用到他的公有方法

　　该结构的好处是当测试的数据中心出现新的公共基类时（它的公共方法其他的新增测试类可能都需要），则扩展新比简单，只需要在终态基类和测试类A直接再添加一个基类即可

　　而当新增加的产品线基类不具有公共性时，则只需要使新的测试基类直接继承此新增的产品线基类，然后该新增的产品线基类直接继承终态基类即可以

　　保持良好的基类结构非常重要，当后续出现大规模的用例时，良好的基类结构可以避免很多重复性的公共方法的编写，同时防止由于用例的急速扩张而使后面失控，当开发工程一个方法变动时，测试由于公共方法东一块西一块而需要进行大规模更改

　　需要补充说明的是根据经验，测试用例的执行时间并不会因为继承的类特别多而速度显著下降，同时也要提醒，我们需要避免把所有的方法都放到基类，并不是说不好，而是因为基类的方法太多则后面不方便自己查找，所以我们还需要把一些方法放到Util中。

……………………

查看全文请点击下载：http://www.51testing.com/html/73/n-849173.html

　　简单一点的测试类的生命周期如上所示：

　　A，首先是基类static静态库准备（这个看开发工程而定，许多可扩展性较好的开发工程都需要动态的传入一些可配置的参数），这个步骤视开发工程而定

　　B，基类before方法准备，一些需要的before方法，不建议在基类before方法中进行类似于数据准备等工作，因为并不是所有的测试类都需要数据准备，所以当测试用例一旦多起来时会带来不少脏数据或者无用数据， 也不建议在基类的before方法中进行类似于数据清理等工作，因为在测试用例执行之前的数据清理一般是全量清理，比如需要将一张表的数据删除等，性能太差，当测试用例数量上来时，每次全量回归所需要的视觉较长。

　　C，测试类的数据准备有两种方法

　　 1）直接插数据库

　　 2）调用开发DAO的方法插入数据

　　方法1的优点是比较方便，想准备什么数据都能准备什么数据，但是缺点也比较明显，比如业务需求为发布一个商品，该动作需要操作多张表格 ，则插入数据准备的成本较高。

　　方法2的优点是准备的数据比较真实，为直接调用接口插入的数据，缺点则是插入的数据依赖开发所提供的接口参数，并不是所有的数据都能插入。

　　一般如果业务比较简单建议用第一种方式准备数据，业务比较复杂则建议用第二种方法准备数据

　　D，在插入数据的过程中，可以将一些全局参数设定好。本持续集成使用的是调用开发DAO插入数据，比如在基类中插入一个商品时，在插入方法结束后，会将商品ID设定为全局变量，方面后面测试用例使用

　　E，测试方法执行

　　F，需要处理的测试方法

　　G，数据删除操作，在基类的After方法中需要执行测试数据删除

……

　　查看全文请点击下载：http://www.51testing.com/html/73/n-849173.html

　　版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。