在自动化测试的过程中，你是否遇到过以下问题？
1、一个人做自动化的时候挺和谐的，啥毛病没有，多人自动化的时候就发现有很多冲突。
2、脚本到底是拆分好，还是合在一起好，如果拆，要怎么拆？
3、自动化脚本做好了，但是做持续集成后，发现有的地方却又不那么自动化，还是很繁琐。变成了一个假的自动化，这也往往导致自动化脚本执行的次数少，价值没有体现的问题。
这些问题在走自动化路上的童鞋应该多少都遇到过，那么如果顺利的去搬走这些绊脚石呢？
搬走法一：搭设框架并制定多人协同的规则
1、我们在做自动化时，确认要用什么框架，比如说采用Python的UnitTest框架
2、由一个人来负责搭设框架，如下图
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的情况，此时就不得不拆。还有当脚本过于庞大时，一旦出现问题时，就要打开一大段代码进行调试，着实也让人很头疼。
... ...
查看全文内容，请点击下载：http://www.51testing.com/html/28/n-3719628.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
