《豆瓣Python测试开发经验分享孙雅丽豆瓣测试开发工程师》由会员分享，可在线阅读，更多相关《豆瓣Python测试开发经验分享孙雅丽豆瓣测试开发工程师（8页珍藏版）》请在金锄头文库上搜索。
1、Part 1 孙雅丽： 谢谢大家，我这边主要跟大家分享一下在豆瓣这边做的测试。今天主要来的都是开发，有没有是做测试的同事，有没有接触过持续集成的同事。首先先分享一下豆瓣的测试，主要分两个方向，一个是Web的测试，其实就是以phython为主的测试。第二个是APP的测试，主要分为两个方向，一个是IOS的方向，一个是安卓的方向，今天主要分享的是WEB的测试。 豆瓣这边主要是用phython做持续集成，刚刚有些同事对持续集成有些了解，我大概介绍一下。为什么会选择phython做持续集成，这边主要是用JAVA开发做动画的部署或者是自动化持续集成的数据，豆瓣主要用这个做持续集成和软件的发布或者是代码的自
2、动化测试。做持续集成主要可以有下面五个优点，一是可以减少风险，每一次上线之前或者是在合并之前会跑一次自动化的责实，这样会反馈一个测试结果，每一个开发都知道他本次写代码的测试结果会给他增加一些上线的信心。二是他可以有减少重复的过程，因为我想可能大家都有经历，所有的自动化测试在公司都有开发或者是测试进行构建，其实用这个做自动化的部署可以自动化的完成这些东西，不需要人为的干预。三是可见性，大家可以看到某一个项目在一段时间之内产品的质量，有一个趋势图，可以看到什么时候是好的，什么时候是不好的。 我想大家都是开发，有的时候应该会有这种问题，首先可能本地服务有的时候起不来或者提交了以后才发现自己以前写的代
3、码有问题。但是可能代码已经合并到骨干，然后你才会看到一些BUG去修改。还有一些依赖的问题，因为在本地进行开发，所以会装一些依赖包，合并的时候会发现线上并没有依赖包到时候会有问题或者是开发服务器的网速非常慢，这样的话没有本地开发比较快，会影响开发这边的质量。 关于这种问题，其实这边做了一些分析，首先是因为开发环境复杂，并且不统一，每一个开发都有自己的开发环境，并且他会在自己的开发环境里面装一些他们自己丢的包或者是库。第二种就是本地构建比较困难，以及一些测试，WEB的测试如果外部搭建一些环境更加复杂，所以会削弱开发做测试的积极性。第三种是本地没有很快的反馈机制，这样的话其实它自己本地做过测试以后不
4、用很快的了解他自己测试的结果。 关于这个问题，我们这边有一些解决方案，首先是我们这边提供了虚拟的开发环境，而且大家都统一的本地开发环境，这样的话可以确保每一个开发他们所用的开发环境是统一的，并且是一致的。第二个是他可以订阅上游的依赖变更用PUPPTE管理，我们也会有专门的工程师维护虚拟的开发环境。第三个是基准的开发包和简单便捷的本地ci，这两个东西都可以让开发对于他自己本地做测试有很高的积极性，也可以减轻他每一次在这上面做测试的尴尬。 针对这两种情况，前面大概是我们的现状，后面是目前的情况，通过用了现在的本地开发环境，大概也有一些优势，也改掉了之前一些问题。比如说在我们之前，只能在服务器开发，
5、之前也有人说他的服务器开发网速非常慢，会影响本地的开发效率。现在是可迁移、可定制完整的本地开发环境，这样的话对于一些新人或者新同事也可以非常好的上手。之前会先提交，然后跑集成测试改BUG，其实跑集成测试相当于把它的代码提供到这上面，现在可以在他本地进行一些测试，然后再提交，可以更快的知道一些结果，不需要去等。之前的WEB测试只能在中心服务器，现在可以在本地进行测试，因为本地已经搭好了一套完整的测试环境。 可能各位开发也会有第二种问题，如果增加了一些新的代码，可能diff特别大，可能会有问题，不知道这个东西究竟被谁搞挂的，刚才清风讲过了，或者是因为大脑太多会懒得review。对于出现这种情况，大
6、概主要的问题是因为review流于形式，最早的时候我们做代码的评审，开发或者是其他人坐在一个小屋里面大家把代码打出来看有什么问题，大家发现这种效率很慢，而且到后期的时候看的不是很认真，所以经常会有一些问题。第二种是分支合并成本很高，因为第一次提了很多diff，但是合成以后其实他不知道那里面到底有没有问题，如果有问题去改，他会再提交，这样花费的时间非常紧。因为提交代码太多，会导致问题很困难，大家不会立刻发现哪些代码出了问题，重新找很麻烦，而且会影响上线。 我们这边第一个解决方案是用reequest，我听清风很详细的讲了Code，大家知道这基本是一个什么东西。现在豆瓣主要是用Code做代码管理。主
7、要需要开一个新的分支，然后会跑一些测试，知道代码的测试结果，如果OK的话就可以了。 第二个如果以快速的以review为单元的话，review覆盖的面比较广，而且每次在提交pull的时候都有测试，对于他本人的信心也比较大。当他merge的时候出了问题，如果Pull有了BUG或者挂掉了，我们会自动发邮件给相关的提交人，他会发一份测试报告，他知道具体哪行代码出了问题，哪些测试挂掉了。相对于之前的对比，现在我们的情况是每一个pull都必须要review，组里面的每一个人都要参与进来，每一个人都在里面发表个人的意见。 现在基本上每天都会有合并提交，也不会之前写一大堆再提交的情况，就会把之前很多代码切到现
8、在一小片一小片提交，这样让大家很容易的找到哪些代码有问题。最后一种是现在每一次merge会跑一次测试，知道是谁搞挂的，然后发邮件批评他。 左边这个图跟刚才清风截的差不多，我们同事在review里面写一些review的意见。右边是针对这次的测试跑一次自动化的测试，反馈测试的结果，具体怎么做我后面会跟大家简单的介绍，它跑测试的时间比较久使服务器有排队的情况，或者跑的时间比较久，最后跟开发说这个没有通过，他那边再改也比较耗时，鼓励各位开发在本地做测试，不要把所有的东西完全依赖到集成这边。 关于这种问题，首先就是分支的集成不足和cisuiete反馈速度慢和无法获取阶段结果，因为我们把现在的跑的测试拆分
9、了，他在这边提交pull的时候和做合并的时候跑两次测试，确保他这边的代码主干所有的功能都是OK的。 这个是我们第一个解决方案，就是基于openingpull做的分支集成，下面的图在每一次提pull或者触发的测试，只需要开发提供一个测试的模板。第一个是测试flow，第二个是pylint的测试，第二个是unittest的测试，第四个是webdriver的测试。 下面具体介绍一下豆瓣的测试类型，豆瓣的测试其实是分为静态测试、单元测试和集成测试。因为各位开发可能不太了解Web这边的测试，在豆瓣主要由测试这边来做。这是sleleenium，它主要模拟用户的点击，写一些测试的脚本，每一次提交代码的时候会提
10、交一些脚本，这些都是用phython做的。这个例子其实主要的作用，它会打开浏览器输入phython的网址获取页面的抬头，他给页面的Q元素发送一个P，他会判断页面的返回是不是对的，之后关闭浏览器。 这部分其实是豆瓣这边做测试的历史变迁，左边是豆瓣之前做测试的方式，右边是豆瓣现在做测试的方式，豆瓣之前其实一直在用Shiretest，它需要开发配置很多的环境，包括一些端口的分配和配置。到目前为止我们一直在用daetest，开发只需要提供一个测试的模板，把想要测试的东西写进去，dae都可以写好。dae刚才清风业介绍了，我不再介绍了。 这是豆瓣这边的测试场景，大概只有三种情况触发集成测试，第一种是上线之
11、前，第二种是master合并的时候出发一次。这是上线前的测试，是保证在master测试通过以后，如果不通过需要改，再做上线。这是我们上线的页面截图，大家看到在右边第二个有一个绿色的标志，那个证明跑测试通过了，如果通不过这个地方是红色的，是不允许上线的。这边是我们在上线之前所要必跑的测试，就是我们的主干代码跑的测试，包括web的测试和静态检查。 这是master测试，这跟之前上线测试情况差不多，只有当pull合并的时候再会跑一遍master的测试。在右边向下边都有master测试的结果，让大家都可以看到现在的测试情况。Part 2 这个是我们之前新做的peer的work flow,当这边做了新的
12、分支以后首先会把peer发出来,发出来以后会做同级的代码评审,同时会触发它目前所有的测试。如果测试通过的话这个peer就会被merge,如果不行就会被修改。 我们这边有几个原则，一是peer测试必须是绿色的，否则不能合并。Master flow必须是绿色的，所以我们要保证所有代码测试通过的情况下。这个是peteris，是我们自己做的，主要作用是执行相关的job，开发那边写一份模板，它会根据模板分配，这个和travis ci有点像。这个是开发那边需要提供的模板，这个模板只需要开发这边把它的类型标出来，在下面选一下要去跑的服务器，它只需要把它要执行测试的脚本写进去，剩下的它就可以用自己的模板。比如
13、这个job超时了发一些邮件报告，或者其他的报告形式，它自己可以做一些配置。开发这边只需要提供这个就可以了。 这个是我们pull request的截图，像flow是集成的job，后面会跑unitest。这个小绿点是在peer的时候我们会反馈，如果测试通过的话这边会变成绿色。我们当时发现有一个问题，因为它过分依赖于cod，如果cod不稳定就会引发一些问题，我们之前就遇到了服务器空间不够的问题。所以我们自己写了一些脚本，做了定期清理的机制。Part 3 最后说一下。我们豆瓣正在热招，如果大家感兴趣的话欢迎投简历，如果大家有一些问题的话可以现在提问，关于测试这边的问题。 提问1：你们这些测试都是拿Py
14、thon做的还是有不同层面不同技术做的？ 孙雅丽：Web这边都是用Python做的。 提问2：你说统一一致的本地虚拟开发环境，我想问一下它是基于技术吗？ 孙雅丽：对。 提问2：当你们上DAE的时候它改变了你们原来ci流程中哪一个步骤？ 孙雅丽：这部分，我们之前会配置他们做一些配置，里面包括端口和企业页面，但是现在包在里面去了，只需要一个脚本就可以了。 提问2：有一些改变，在推动的时候开发那边阻力是什么？ 孙雅丽：之前如果做config配置他们也觉得非常麻烦，但是现在是好的东西大家都愿意用，而且它会更简单。其实豆瓣非常好的一点是豆瓣开发会自己做测试，而且也非常支持做测试。 提问3：你们研发提交的
15、测试模板是不需要QA可以自动生成吗？ 孙雅丽：不是这样，开发这边如果写了测试模板的话一般会让QA来看一下，具体测试用力可能是大家互相协商来写的。 提问4：也就是没有完全实现自动化？ 孙雅丽：是自动化的，但是刚开始和别人共同用一下没关系，这是两个概念。 提问5：你们的App是怎么做测试的？ 孙雅丽：我们更多的是做一些打包，或者是内部的发布。 提问5：更多是手工来测？ 孙雅丽：他们也做了自动化测试，但是因为App这边太大了，以至于自动化这边需要投的人力很多。它可以真实的打开网页，大家感兴趣的话可以看一下这个。 提问6：豆瓣更新一两张图片，我想问一下流程过程，已经在测试通过了。 孙雅丽：那就直接上线。 提问6：用什么工具？ 孙雅丽：我们这边有上线工具，直接上线。 提问6：原理是直接把这些东西扔到服务器上？ 孙雅丽：对，你把它传上去，然后用DAE上线。
