党弘扬 百度外卖开发测试环境搭建最佳实践.pptxVIP

百度外卖开发测试环境搭建最佳实践 自我介绍党弘扬2011年加入百度。先后工作在百度旅游、百度电影2014年至今百度外卖，负责在线架构工作。一个故事：关于开发测试的环境1 Day10 Minutes服务的演进实际上随着业务越来越复杂，团队越来越多，配合一次完整的环境搭建的时间近乎要 1 Day。迭代效率骤降测试质量骤降、线上问题频发潜在的弱安全性迭代效率骤降测试原则： 每测试一轮，需要重新搭建环境 + 部署新代码，重新验证Test Case一个2周的迭代，花在环境上就要至少2天。 一个迭代周期内 1/5 时间的都在搭环境。测试质量骤降、线上问题频发搭建成本升高使得 —— 规避搭建环境，能对付就对付。非常规手段：已有环境，敝帚自珍，不忍重来没有环境，拷贝别人的没有环境，借别人的 .. 测试质量骤降、线上问题频发搭建成本升高使得 —— wiki和脚本开始不好使了 —— 搭出来的环境也是坏的误测： 测出一堆bug发现其实是环境问题漏测：测试环境没问题，上线就有问题潜在的弱安全性私人数据库，缺乏管理，敏感信息进入测试环境分析问题 – 四个痛点团队壁垒可维护性差测试数据库不便捷分析问题 - 团队壁垒一个用户端的项目想测试全流程分析问题 - 团队壁垒不要团队合作，赋予每个人相同的权利分析问题 - 可维护性差环境搭建脚本维护的是哪些东西？差异分析问题 - 可维护性差搭建环境 1.0 怎么维护差异？以人为主，所有的都差异规则都依赖于人的自觉性新服务狂引入分析问题 - 数据库问题不安全 —— 站库分离不彻底、任性的导数据不够便利 ——上千张表，几十个数据库可用性差 ——本地服务、单点。分析问题 - 不够便捷分析问题 - 不够便捷从产品上，它必须是这样的回顾问题有团队壁垒可维护性差测试数据库不便捷有团队壁垒成立横向的技术团队，面向所有人做平台，屏蔽业务的技术细节，提供整套服务。平台化横向技术团队平台技术架构提高可维护性提高可维护性 - 整顿不合理的差异原则：线下要尽可能接近线上创造线下逻辑省略认为不必要的一些校验绕过觉得麻烦的登录直接连接服务图方便写死结果..提高可维护性 – 自动化和个性化RPC配置本地化要求线上服务端口唯一。远程BNS直接做本地映射数据库配置私有化根据用户数据库信息自动生成数据库配置。个性差异插件化Data测试数据库解决方案前提Test = 1 测试数据库解决方案自动创建数据库 - 统一导出条件 - 集中集群管理便捷如何做到一键更新测试机解决方案并行更新全选增量更新服务方式耗时用户端服务（LNMP） 大小： 900M 替换600s用户端服务（LNMP） 大小：900M 增量30s平台技术架构解决问题成立了横向维护部队，负责横向的调研分析、制定方案、落地、售后服务。抽象并重构了所有业务团队的搭建流程，并使之标准化，可扩展。形成了一个统一的平台，我们给它起了一个简单可爱的名字叫“乐高”它大部分的交互都是这样的任何人都可以通过点一点，在10分钟内，拥有一个全套的、标准化的、互不干扰的脱敏的环境。后续计划 后续计划大家下午好。已经5点了，一下午面对这么多干货大家一定已经饿了。那我就快开始。我这次分享的内容是一个非常非常小的点，虽然我的标题比较长。 就讲讲我们怎么搭建测试环境。首先自我介绍一下。我的名字 —— 党弘扬确实这个姓氏比较少见。总之大家应该可以看出 这是一个很正能量的名字哈哈我的经历也比较简单，基本就是一直在百度。过程中做过一些业务。现在主要负责百度外卖的在线架构部分。所以我不得不先在这里承认，我其实不是搞测试方向的，我是做后端架构的，也就是写php的。是正好做了这个事情，符合了测试的这个topic，而在座的各位都是测试领域的专业，说实话我其实内心很忐忑。这里我要感谢腾讯的潘老师，昨晚和潘老师沟通过以后，发现潘老师在测试领域非常非常的专业，给了我很多的启发和鼓励，聊过之后潘老师就说没事，只要搞定事情就好。所以我快速进入正题。我要分享的是一个什么样的内容呢：就讲一个我们如何从一群人搭建一套环境要一整天 —— 到10分钟之内让一个新人自助完成整个环境的快速部署，满足一人一套、互不干扰、数据脱敏的标准化环境。我将会用发现问题、分析问题、解决问题的顺序讲述刚才的这个过程。我相信很多的企业最初始的时候都是像左图一样，是以这种简单架构为主，可能就1、2个服务 —— 然后通过比如说 团队中这种技术高超的大师来通过口述、wiki、脚本等方式，然后达到线下测试环境的搭建。那么大家都在讲服务的演进（应该有很多大会都在讲自己企业的架构之路），那么直接的影响就是产生了更多细分的服务、团队上产生了更多细分的团队。那么此时搭建实际上就变成了团队协作，用户端搞定用户端的环境、商户端搞定商户端、物流搞定物流端，手段上都是口述、wiki、脚本等方式、然后再合