正文
2.1、配置文件不可少，经常要变动的参数，不能写死在脚本里的参数，都可以放到data下面，比如说服务器地址，由于多个迭代并行开发，经常会分配不同的ip地址，如果写死ip就会导致在其他迭代中不能正常运行，所以要先提炼出来放配置文件中。当配置文件中的参数一多时，那么命名规则就尤为重要了，配置文件的规则要有明确定义，比如说我们把服务器地址统一配置成URL=192.168.*.*，而不要出现多个表示服务器地址的配置名，如又出现一个叫IP=192.168.*.*。
2.2、写一个脚本的时候会用到很多方法，此时不要写到具体的case里面，而是要实现公共的类和函数，放到public。当不同的人去写case时，就可以不用重复代码，去public找就可以，日积月累，将越来越丰富。
2.3、执行具体case时，我们必须要有前置条件，比如说我的case要在登录后才能执行，那么这个登录的帐号我必须确保它是存在的，如果不存在我就自动添加进去，这样脚本的回访率就很高了，所以这个inital.py 就是干这个的。
2.4、在执行脚本的过程中，我们产生了一些数据，但是这些数据是我们不想要保留的，那么我还可以进行场景恢复，这个restore.py就可以干这个。
3、具体的框架出来后，接下来就是各位自动化测试的工程师们按照既定的规则进行填充用例，覆盖更多的场景。
千万不要零散的写脚本，你一脚本我一个脚本，没有规范，这样其实对做持续集成来说会是一个非常难的事情，你可能会花很多的时间去调整脚本，所以一开始就要先搭设框架。
搬走法二：脚本会经历拆拆合合，不断的整合出最适合
脚本case还不多的情况下，往往是整在一起比较方便，一个脚本测试一个项目，感觉维护起来很方便，但是当case多了以后，发现会出现维护难，甚至是性能有问题，比如SoapUI会出现out of memeroy的情况，此时就不得不拆。还有当脚本过于庞大时，一旦出现问题时，就要打开一大段代码进行调试，着实也让人很头疼。
那是不是拆的很细呢，一个case一个脚本？这个也有弊端，那么多脚本，维护也不方便。所以还是要把握一个度，可能一开始这个度把握不准，那就慢慢的进行拆或整合，就像程序员也要经常的进行重构是一样的道理，总结出一个合适的度，就可以。
比如说我们要做网页的自动化测试case，可以根据页签或者抽屉来拆分脚本，这样会更加清晰一些。
搬走法三：不断的优化，从半自动变成全自动
之前做SoapUI接口时，将配置的参数写到了SoapUI脚本里面，这样导致每次修改配置文件，都要去打开具体的脚本，然后修改，非常麻烦。所以就进行了解耦，把需要配置的参数放到Global，这样只要改这个文件即可，无需打开脚本文件，维护和操作性带来大大的便捷。但是问题来了，当集成到jenkins上后，很多的团队在同一台测试机器上跑脚本，SoapUI只有一个，所以Global经常被改的面目全非。这样每次在jenkins上跑之前，还要去远程测试机，把Global改成正确的才行，很繁琐，且也无法利用jenkins的功能，实现一旦代码更改就触发运行脚本的自动化机制。所以导致脚本回放次数低，每次手动执行。对于这个问题大家虽然觉得麻烦，但都习以为常。变成了一个半自动化的自动化测试。
