豆瓣Python测试开发经验分享孙雅丽豆瓣测试开发工程师.doc

Part 1 
      孙雅丽:
      谢谢大家,我这边主要跟大家分享一下在豆瓣这边做的测试。今天主要来的都是开发,有没有是做测试的同事,有没有接触过持续集成的同事。首先先分享一下豆瓣的测试,主要分两个方向,一个是Web的测试,其实就是以phython为主的测试。第二个是APP的测试,主要分为两个方向,一个是IOS的方向,一个是安卓的方向,今天主要分享的是WEB的测试。
      豆瓣这边主要是用phython做持续集成,刚刚有些同事对持续集成有些了解,我大概介绍一下。为什么会选择phython做持续集成,这边主要是用JAVA开发做动画的部署或者是自动化持续集成的数据,豆瓣主要用这个做持续集成和软件的发布或者是代码的自动化测试。做持续集成主要可以有下面五个优点,一是可以减少风险,每一次上线之前或者是在合并之前会跑一次自动化的责实,这样会反馈一个测试结果,每一个开发都知道他本次写代码的测试结果会给他增加一些上线的信心。二是他可以有减少重复的过程,因为我想可能大家都有经历,所有的自动化测试在公司都有开发或者是测试进行构建,其实用这个做自动化的部署可以自动化的完成这些东西,不需要人为的干预。三是可见性,大家可以看到某一个项目在一段时间之内产品的质量,有一个趋势图,可以看到什么时候是好的,什么时候是不好的。
      我想大家都是开发,有的时候应该会有这种问题,首先可能本地服务有的时候起不来或者提交了以后才发现自己以前写的代码有问题。但是可能代码已经合并到骨干,然后你才会看到一些BUG去修改。还有一些依赖的问题,因为在本地进行开发,所以会装一些依赖包,合并的时候会发现线上并没有依赖包到时候会有问题或者是开发服务器的网速非常慢,这样的话没有本地开发比较快,会影响开发这边的质量。
      关于这种问题,其实这边做了一些分析,首先是因为开发环境复杂,并且不统一,每一个开发都有自己的开发环境,并且他会在自己的开发环境里面装一些他们自己丢的包或者是库。第二种就是本地构建比较困难,以及一些测试,WEB的测试如果外部搭建一些环境更加复杂,所以会削弱开发做测试的积极性。第三种是本地没有很快的反馈机制,这样的话其实它自己本地做过测试以后不用很快的了解他自己测试的结果。
      关于这个问题,我们这边有一些解决方案,首先是我们这边提供了虚拟的开发环境,而且大家都统一的本地开发环境,这样的话可以确保每一个开发他们所用的开发环境是统一的,并且是一致的。第二个是他可以订阅上游的依赖变更用PUPPTE管理,我们也会有专门的工程师维护虚拟的开发环境。第三个是基准的开发包和简单便捷的本地ci,这两个东西都可以让开发对于他自己本地做测试有很高的积极性,也可以减轻他每一次在这上面做测试的尴尬。
      针对这两种情况,前面大概是我们的现状,后面是目前的情况,通过用了现在的本地开发环境,大概也有一些优势,也改掉了之前一些问题。比如说在我们之前,只能在服务器开发,之前也有人说他的服务器开发网速非常慢,会影响本地的开发效率。现在是可迁移、可定制完整的本地开发环境,这样的话对于一些新人或者新同事也可以非常好的上手。之前会先提交,然后跑集成测试改BUG,其实跑集成测试相当于把它的代码提供到这上面,现在可以在他本地进行一些测试,然后再提交,可以更快的知道一些结果,不