如上图左上部分是买房的业务场景与电商业务场景的对比，电商经过选购、下单、接单、配送、完成，几步就能把商品买了，但房产交易中的环节就非常复杂。
比如处理二手房，先四处寻找房源，找到后进行委托，让经纪人去代看，房子合适了会签约，再房屋核验、资质审查，对方可能会进行解抵押，再网签，这时需要做房屋评估，之后面签、批贷、缴税、过户，领取房产证，客户还会抵押到银行，再放款，最后还有一个物业交割才会结束。这其中有多类角色协同，跨部门，跨组织，甚至和政府打交道。
二手房只是其中一个业务领域，贝壳的业务还有新房、装修、租赁等各种业务形态；从业务视角来看它贯穿业务前台、中台、saas服务、基础设施多个领域，共同完成一次房产交易。
下面是SaaS中台，围绕着房源、客源、经济人，多个环节一起工作。最下面是基础设施，有楼盘字典、安全风控、大数据、基础架构，有各种各样的技术设施支撑房产交易的运营。
最右边是技术架构上，我们现在用户触达层有android，iosapp，小程序，PC/M站，IoT，接入层是网关，流量和业务网关，服务层多使用微服务架构，存储层等以redis，mq，hadoop等开源的组件为主。
通过对贝壳业务架构、技术架构以及业务场景来分析，贝壳的业务特点如下：
链路长，线上线下角色多，数据量多且复杂。
从IoT到直播领域，VR，到大数据，机器学习，到服务亿万用户的各种应用，横跨多种领域和应用形态。
贝壳业务发展非常快，伴随着业务组织调整也多；同时也有非常多的框架和组件版本；伴随着业务发展需要需要非常多的重构，升级工作。
贝壳的一个变化流程从采购软件到自研单体到微服务，业务底层基础设施日均几十亿的调用，也让技术迭代非常快，基本已全面拥抱微服务。由于业务的特点，所以我们在高性能，高可用和安全上有特别的要求。
上述详细了介绍贝壳业务特点，这样的特点会带来各种挑战：
微服务从soa发展过来，被越来越多的企业it生态所采用，它高内聚，低耦合的特征，丰富的开源组件，确实可以让业务需求快速被交付出去。但对测试来说挑战更大了，模块变多了，发布变多了，测试一次任务变复杂了，回归轮次和范围变多，环境更不稳定，同时我们还要保持高性能，高可用。
多种技术栈，多类重构，会持续放大我们的回归工作量，不一样的研发工作，协同交流方式，都会加大我们的质量损耗。
产业互联网由于线上线下的结合，再加上微服务的技术体系，测试数据，环境搭建和回归的难度更加大了，一次测试需要有房源，客源，经纪人，合同，楼盘等多个系统配合，严重的情况会涉及到几百个字段联调，怎么快速构造环境和数据验证逻辑正确性，这些都非常挑战我们的基础设施建设。
由于形态多样，和之前提到的组织变化快，我们在历史上有很多质量领域的问题和解决方案尝试，如：移动端的，页面的，服务端的，性能的，接口等等，如何复用能力和抽象共性，而不是不是散点的解决，非常考验我们的质量架构设计能力。
质量问题涉及各环节、各角色，系统全面且高可用的提升质量和效率要靠体系化建设。
贝壳质量体系的建设，分成理论、策略和信息来进行讲解。
各类业务、产品形态的质量保障的底层逻辑都是类似的，分成看的见的质量，难看见的质量和看不见的质量。
看的见的质量好感受，比如这个工厂流水线的成品，是好的，坏的。
难看见的是中间这个车床的过程工艺，机械臂的规格，抓取的力度，流水线的速度，这些因素可能会导致最后的成品的好坏，这是需要仔细观察才能看见的部分。跟古代的行军打仗一样，一次战役的胜利，可能在兵操演练，沙盘推演这些过程细节中决定了，最后打的一刻只是过程的检验，好的质量也是一样的，这一部分难看见，但需要被看见。
最后是看不见的那一部分，也是很关键的一部分。好的质量在最初的设计，研发的编码，架构选型，产品的交互，需求设计，异常的考虑在最开始被设计好的。质量意识能力会带来好的过程，最后是好的质量、好的交付物，好的交付物又会通过平台通过中间的过程工艺平台和交付物质检的平台推动整个质量意识的提升。
我们的质量体系建设也是围绕这几部分展开的，技术，产品形态有千种变化，这个背后的逻辑是一致的。质量体系也是按这个来构建。
我们通过这个框架策略明确了质量部的目标，做事原则，和岗位角色，分工协作机制。
最下面的是大家做事的原则层，我们希望通过标准化，线上化，平台化来做质量建设，以平台带动组织的质量能力，并且通过各项指标让组织能自我迭代。
最终大目标是通过业务QA推进组织转型升级，通过技术促进商业价值健康快速交付，组织最后的质量要高，而质量是所有人努力才得到的。
细节方面，最底层的质量意识会标准化贝壳产业的全流程规范，从需求到发布，全流程规范化、标准化，质量赋能体系也会有质量分、质量培训等等，提高质量意识。
这里有四张网，分别对应看得见的质量检查平台KeTest，难被看见的过程工艺部分KeOnes，和质量意识提升部分，以及线上运营能力部分。
KeTest平台统一质量和解决方案标准，把各专项能力一站式提供，为全集团赋能，整体对各业务做质量保障，尤其产业互联网在自动化回归，数据，环境，高性能，高可用等部分做深入的能力建设。
KeOnes平台从开发编码到发布全环节打通协同能力，解构了产研28个环节，数十个系统信息孤岛，并通过ci，cd流水线能力，集成KeTest的质检能力建设4道质量闸门，在各环节快速反馈质量问题，通过KeTest，KeOnes绝大部分质量问题能在线下环节发现。
在线上环节，我们通过自动化巡检，监控，预案演练，熔断，限流，降级等能力保障线上运行的稳定性。
在线下环节，我们会持续做质量意识提升的事项，标准制定，考试通过，培训，活动从源头提升人和组织的质量能力。
每一部分具体怎么做呢？下文将会详细为大家展开。
KeTest是为贝壳集团整体质量提供的一站式解决方案平台，类似QA的工作舱，核心提供5大能力，解决方案层面，为各业务形态，提供工具，测试策略，环境，执行计划，结果通知，帮助各业务团队快速搭建质量解决方案,质量能力能快速到一个标准水位。
质量学院是整体大家的知识大脑和经验仓库，也和质量素养具体活动，认证等打通。质量开放服务提供api辅助在消息，指标统计，基础测试框架等通用逻辑部分，质量工具提供10余种专项能力，比如自动化，性能，数据构造等，质量度量通用分析质量建设能力水位线。接下来会把里面核心中比较有特色产能功能、特色专项的进行介绍。
微服务化架构下接口特别多，链路长，模块也多，回归成本，自动化建设成本都很高，sosotest提供了多模式的使用方式适合不同能力的测试人员，和不同场景的业务，能快速编写自动化用例。
目前用例数有4.6W，全集团87%的业务线在使用sosotest，其中也有不少研发贡献的用例,某些业务线近30%用例由研发贡献。基础类的服务100%已经接入。
Diff测试在大型互联网系统比较常用，所以我们调研了业内的流量回放方案后，自助研发了基于流量回放的Diff测试平台-KeDiff。
截止目前，Diff平台承接了贝壳65个子系统，110个服务的业务，完成数2600+次回归测试，执行过1370万+条Case，测试效率提升50%。
未来，Diff平台还有三大规划；第一拓展更多协议的支持，例如Dubbo协议、Rpc协议；第二Diff报告的完善，通过代码覆盖率进行更精准的测试分析；第三Diff平台与质量中台和KeOnes系统的打通，成为QA测试中的质量卡点和更便捷的提效工具
虚拟城市是另外一个解决产业互联网线上线下链路长，角色多，非标体系环境比较有特色的建设。
google之前有sandbox沙盒测试的概念，贝壳打造了一个全业务的沙盒，从数据底层，到终端业务，这个环境贯穿始终，涉及几十个系统，有超过5000+测试账号，线上巡检，验收，问题复现都可以用这个环境来验证，同时也应用在新业务，比如开城等全线上测试，运营同学也利用该环境来宣讲、演示。
微服务架构下，环境治理也是老大难的问题：配置维护难、扩展成本高、环境使用乱。
我们构建了测试容器云平台，提供统一的环境治理能力，底层封装了K8S，在编译构建，配置管理，测试数据管理及环境扩展等方面有相应的支持。也在借鉴泳道的模式，有一套主干环境，每次特性修改，只拉起对应工程的环境，其他模块去连主干环境。目前接入的项目有1000+，有效环境1600+。
首先，配置管理上，平台提供多语言类型配置标准化模板抽象方案，配合各业务方进行配置改造，平台实现一套环境内的配置模板自动实例化。
其次，环境扩展上，结合容器化技术，实现服务及外部资源无需申请，提供配置管理和服务基准库解决方案，实现环境一键复制，快速扩展，动态伸缩。
最后，在环境管理上，提供不同类型环境的使用规范和约束，统一管控，包括路由配置，环境占用，自动部署，回滚等机制。
目前全公司接入项目1000多个，有效环境套数1600多套。
长链路，多角色，非标的业务特性，让一次测试的数据构造变得比一般业务更加麻烦，海豚平台一站式提供测试所需数据的平台。通过这个平台，把所有测试同学的数据准备的经验和复杂的流程沉淀下来，让一个普通的qa，以及rd、pm都能直接使用，快速的构造出数据，使数据构造工作变得更轻松和高效。
平台的优势：
第一，是低门槛。熟悉业务的测试同学添加功能后，其他不熟悉业务的人也可以方便的造数据，他只要知道自己想要什么数据，就可以构造出来。
第二，是灵活性。平台有多种构造数据的方式，灵活组合数据配置单。并且平台有提供给外部的接口调用，用于自动化case等。
第三，是可视化。所有人构造的数据内容和执行情况、平台的使用情况的流量统计，都能一目了然。
平台的整体架构：主要的3个组成部分：环境信息部分、构造方式部分，数据生成部分。
贝壳服务端性能测试平台KePTS是面向贝壳服务端业务的一站式性能测试数据构造和性能测试执行的压测平台。
KePTS的优势：
KePTS底层依赖的发压能力了来自开源压测工具grinder，发压使用groovy脚本。为降低压测执行门槛，方便非JAVA背景同学快速上手，KePTS封装了多种典型的压测场景作为模板，并根据压测数据自动生成压测脚本，降低压测工具的使用门槛。
压测数据节点和发压节点灵活可扩展，适合全链路级别的线上压测，赋能贝壳多个方向的核心服务端业务。
基于KePTS，服务端性能测试效率提升超30%，执行和支持了104次全链路及线上容量，支持超过300次各类线下压测和故障演练，拦截150+性能问题拦截，助力贝壳服务端性能容量类故障数的持续收敛，打造高质量的贝壳服务端中后台。
KeMTC平台是贝壳移动端测试一站式工具平台，为贝壳移动端提供通用的自动化测试方案。
从上至下看，数据化度量是衡量KeMTC的效果和业务应用平台的程度的，主要用来指导平台解决问题的能力和平台的升级改进。
如通过发现Crash问题数量，来衡量客户端的稳定性；通过自动化case数，来衡量客户完成自动化的能力；通过云真机的使用次数，来衡量云真机的提效能力；通过平台的访问量、项目接入量，来衡量平台的认可程度。
App稳定性、自动化等4个专项平台是KeMTC的核心能力工具，每个工具平台又有其针对的解决问题的手段。
拓展能力和公共能力，作为核心能力的补充项。拓展能力指在开发这4个工具过程中，延伸出的非计划内的功能，可以作为未来更多工具项的切入点。公共能力是指几个工具项通用的一些功能，也是可以给其他工具可使用的功能。底层就是公司内的一些基础设施了。
以上是一站式平台一部分的能力项做的介绍，接下来会对难看见产业协同过程的平台做介绍，包括对它的应用也重点讲讲CI/CD的部分。
中间是CI/CD流水线的建设，下面是数据AI，从需求、测试、线上目标，CICD流水线分四五个阶段，拆分出来几十个环节，为什么要做KeOnes这件事？
首先是协同方式不同，有时不停开站会，对质量来说，过程质量损失特别多，信息传递会失真，所以我们统一搬到了线上，对CI/CD也重新做了标准化的建设。
需求阶段项目迭代、需求做了管理，研发阶段会支持CR、环境搭建、测试准入，测试阶段会做自动化测试、专项测试，发布阶段之前发布也有多个系统，把它统一到一个发布系统，为这个发布系统导入各项能力。
比如怎么去做发布、健康度检查，如何预发、销售量、全量。线上运营跟线上监控打通，这是CI/CD的流水线，他的各种能力项跟它是深度结合的，包括性能测试等等跟它也有深度的结合。
CI/CD内部也有个迎合项目，从需求、创建、拉一个分支、合并、发布上线各个环节拆分开都出流水线，每个动作都自动验证，分支拉出来跑一些Case，从中间到要发布上线人工卡点完成后又在另外环境跑，就是把结果反馈快速回馈出来。
比如每次构建会在统一在一个群里，失败也会及时发出通知，群里每天可以看到多少分支创建、拉取，构建有没有问题，是不是可以通过。
规则是代码扫描、自定义的规则进行检查，包括第三方的业务上的规则，都可以里面去检查，也应用了Diff等等各方面的能力项。
中间是贝壳发布的质量指标白皮书，定义了如何看全环节的质量，各个环节指标究竟要看哪些，这个指标也会跟各个团队的研发对齐。
质量意识建设上也有双环驱动，一部分驱动团队、一部分驱动个人、团队会对其进行质量诊断，由QA对双周的各种质量做诊断，数据是怎么样的、有什么风险、实时的告诉大家，也会展开多种质量活动。
比如去扫描谁改得最多、单测自测怎么样，也会发质量认证。个人会被分配一些质量任务，这些任务完成得好会有质量积分，目前已经开始在启动这件事，找Bug、对ADC进行培训，双环联动，对员工有一些激励和认证和荣誉晋升的加分。
前面介绍了KeOnes、质量意识提升和工具平台的细节，这部分讲讲保障体系未来的发展。前面做过总结，经过这一年多的建设，从19年的测试研发1：5提升到了1：9.2，故障率下降了74%，SLA达到4个9，吞吐量增长142%。
未来会做些什么？首先是智能化测试，包括做用于自动生成图像的自动化识别，未来更多的去往智能化应用做优化或者是AI、机器学习等方面。
混沌工程也会加强，QA会做故障演练预案，跟研发团队一起做一些提高，看熔断、降级是否足够好，够不够快速，未来也会体系化这件事。
第三部分是Devops升级，借助一些平台上的工作机制来做，目前做了一部分，让线上化之后也有数据，各种指标都可以看到，未来会对devops成熟度去做更精细化的认证管理等。
Q：出现故障贝壳如何追责、如何防止甩锅？
Q：系统发布会自动更新配置库吗？
A：在发布时我们也有变更的流程，不管是一次代码变更、配置变更、数据库变更都会通过一个线上平台发布出去。配置库是不是可以管理起来是吗？这是线上化管理起来的，有一些配置平台去负责，坦率的说我们的配置的平台也有在收敛，我们做太多了，在配置平台比较多的情况下，整个微服务里面在配置中心来做，有些是业务封装是业务线上的平台，所有这些都是可以追溯的。
Q：质量监控体系如何建立？
A：监控有多种监控，前端监控研发团队也有灯塔、海神，QA也有自动化运维，偏业务的监控线上跑。端上有QA的自动化，后端搜集各个服务，服务也有监控、日志也会搜集，查看日志的异常，流量监控检测各种反馈码、定制监控指标，测试的阶段自动化能力通过持续集成跑、自动去跑，有问题可以及时告警出来。
Q：混沌工程什么时候开始，实现效果怎么样？
Q：质量意识建设应该从哪入手？贝壳现在取得了哪些成效？
A：质量意识的建设需要自上而下，需要有团队的氛围。我刚CTO面试的时候谈到百度工程师文化、谷歌工程师文化，好的工程师文化下的质量意识一定是天然好的，如果不是那就需要有很多手段，比如刚来的时候不停普及质量三段论，要参加考试，做完之后85分以上才是通过，甚至要求高层也参与考试，所以入手应该是自上而下的形成团队氛围。
Q：贝壳取得哪些成效？
Q：混沌工程实现自动化和智能化在贝壳有规划吗，实现难点和关键点有哪些？
A：混沌工程和做的各项Diff、引流，它的实现难点都是不是在质量本身，而在于整个研发体系IT生态是怎样的，监控是不是足够好，对线上的服务运维调度是不是足够的牢固很关键，如果连线上发生的情况都不知道，也无法做降级熔断，我们如果去做混沌工程就是不停埋炸弹，这肯定是不行的，IT生态里面微服务的架构，各方面组件使用得是否规范，关键点是突破这些基础设施。
智能化是有规划的，在移动端的自动化的时候，对图像的识别包括未来做Diff也用一部分的AI，也是开源的，智能化应用场景非常多，包括Diff如何筛选线上流量，流量跟最后运行的代码关系如何关系得上，性能如何自动识别性能优先，这次性能是否通过，也有很多应用场景我们是有规划的我们也在招人。
Q：选择jenkins而不选择其他的如k8s等的原因是什么？
A：选择jenkins是历史上就用得比较多，持续集成做得比较好的还是jenkins。
k8s是容器化的集成平台，上层的应用平台，包括也有团队最开始没有k8s，直接用原生的去做事，但是后面逐渐统一。前几年也用docker做环境隔离，其实用docker做事情也依赖于基础架构、IT生态，做容器化需要找好路由关系，这些解决得好就好推进，做路由的时候用各种服务目录，把每个分组做好，标签对应就比较容易。
Q：虚拟城市是不是可以替换预发布环境？
A：虚拟城市没有准备替换预发布环境，虚拟城市有各种用途，预发布各个模块之间也有预发布，虚拟城市是完全从B端、C端到后端完全的打通，线下和线上的应用都非常的成熟，各个业务线、各个模块预发布，比较封闭的环境都无法这样做，所以不能去替换，虽然预发布虚拟城市可以用来做演示，但他们的关系不是完全的一样的，所以没有准备做替换。
Q：贝壳质量部的文化建设是如何进行的，目前还在招聘哪方面的人才，期待加入？
A：这个问题太好了，我们贝壳质量部成立一年多，文化建设非常好，我们有很多活动：去年质量部的活动是去做飞盘，两人三组，包了一个体育场去PK，分了二十个组，各个组PK，大家玩得高兴，组队玩王者荣耀，也有篮球社区，也可以组队踢足球。