在自动化测试逐渐普及，测试越来越向专业化和职业化发展的今天，接口测试和单元测试成为一个测试人员必备的技能，但是随之而来的却是高维护成本。特别是在互联网公司，测试的业务和逻辑变化和更新特别频繁。如何让自己的接口测试代码维护方便，快速编写和持续回归呢？

　　首先抛开接口测试不说，看一个测试用例的执行过程，无非分为3个步骤：数据准备，执行操作和校验结果。那么在一个接口测试的用例中同样有这些步骤，可以将他们进行模块化。

　　下面用一个例子来说明。例如要测试的类UserManager有一个接口是addUser(User user);其中User 类 有3个属性：Long userId,  int sex; int age,String name; 返回结果保存在Result 对象里面。

　　假设业务规则如下：

　　1、userId 不能为空，不能重复

　　2、name 不能为空，且不能重复

　　3、sex ，age 可以为空  其中sex 取值范围[0,1] age[0,150] 默认为0

　　如果要对这个接口进行测试,如何写测试用例会比较快的呢？

　　可以想象得到这些用例会有哪些操作？

　　1、如果为了校验重复肯定需要有数据库的清理操作

　　2、要初始化参数

　　3、调用接口

　　4、校验结果，分为成功校验和失败的校验

　　那么可以模块化出来以下方法：

　　cleanUser()从数据库清理掉用户

　　initUser() 在数据库里面进行用户初始化，为了校验已经存在用户名的

　　initParam() 参数初始化

　　checkIsSuccessful(Result re)校验增加用户成功

　　checkIsFaild(Result re)校验增加用户失败

　　那么对于具体的一个用例只需要选择以上方法中的一些方法就好了。例如：

　　这样进行模块的好处是，写用例非常快，基本一个写好，其他都是复制就行了。另外修改时也非常快。这里说下几种可能修改的应对策略：

　　1、User 对象增加了一个属性String work；那么为了不影响目前的脚本运行，我们可以增加一个参数 String work 并赋上一个初值，再修改下initParam 方法就ok了。

　　2、返回的结果对象Result 改变，只需要修改Check的两个 方法。

　　3、业务规则改变，原来成功的可能要失败了，例如sex变成了必选，那么只需要把checkIsSuccess 改成checkIsFailed

　　模块化的思想可以把一个整体抽象成相对独立的模块，根据具体的需要进行模块化的组合。