技术领导力实战笔记_87_第69讲_|_茹炳晟：QE团队向工程效能团队转型的实践之路
你好，我是朱炳生，目前担任一贝中国研发中心，测试基础架构技术主管。
今天想跟大家分享的话题是QE团队向工程效能团队转型的实践之路。
在软件开发和项目执行中，工程效能问题一直是技术管理者考量的关键，加快研发效能和提升工程师团队效率及质量，需要在软件智能化上迈出创新步伐。
目前包括google、易贝等跨国互联网公司的研发团队，都在尽力去除QE的组织架构转变。
为此呢google也暂停了二零一七GTAC,并寻求向engineering、 productivity及工程效能的转型。
相应的QE团队也正在逐渐向工程效能团队转型。
工程效能团队的好处在于，假如你的研发团队规模为一百人，那么工程效能团队可能需要十五个人。
但当你的开发团队翻了十倍，达到一千人规模的时候，工程效能团队的人数可能仍旧是十五个到二十个之间。
所以，随着开发团队人员的增多，规模的增大，工程效能团队的输出和价值会越来越大。
这也是为什么很多大型互联网公司，尤其是全球性的互联网公司都热衷于采用这种模式。
如今，谷歌等国外大的互联网公司已经基本实现了向工程效能的转型。
国内虽然具体的时间还不多，但很多公司都在做类似的尝试。
在这种模式下，整个测试策略发生一个变化。
传统的测试由三个部分组成，底层是单元测试，中间是API测试，最上面是GUI,测试，是一个类似金字塔的三角形。
其中，单元测试由开发人员来负责，API测试和GUI测试都由专职的q一或QA来做。
但到了工程效能模式下，除了单元测试，API测试和GUI测试也将由开发人员来做。
这意味着开发人员需要兼任测试的角色克服从开发到测试的思维局限性，同时还需要一个很高效的测试平台基础架构，提供一个便捷的测试执行环境，以支持开发人员方便的获得测试数据执行测试。
原本的功能测试团队则退化成现在比较热门的探索式测试，测试开发人员则转变成工程效能开发的角色去做测试平台相关的开发。
在这个转型过程中，如何运用原本QE团队积累的技术优势，来设计和构建高效的测试，基础架构就变得尤其重要。
本文将着重分享如何通过架构演进来改善测试执行环境，以达到工程效能的提升，测试执行环境之疼。
为了提升工程效能，一般会对测试执行环境提出以下要求。
第一点，对使用者而言，测试执行环境的透明性。
所谓透明，是指假如我今天要用测试环境跑一个mobile的native测试，需要某个版本、某个分辨率，甚至某个品牌的手机。
但这些设备不需要自己准备，只要提供相关的参数，后台就会帮我把其他事情准备好，并且把相应的测试分发过去。
对使用测试环境的人来说，他希望整个测试执行环境是透明的。
第二点，对维护者而言，测试执行环境的易维护性。
所谓易维护，是指不希望有上千甚至上万台机器的测试，执行环境需要人工维护。
因此，我们引入了容器化技术，用docker来准备整个测试执行环境。
第三点，对于大量测试用例的执行而言，执行能力的可扩展性，引入容器化技术之后，可扩展性自然而然就解决了。
我们会根据单位时间内测试用例的排队数量，通过算法来决定这个集群里需要多少台机器，才能在规定的时间内执行完全部测试用例。
这样整个集群的伸缩也全部由自动化工具来完成，能做到对使用者完全透明。
第四点，mobile移动终端的多样性与碎片化，这使得搭建一个包含各种IOS和android设备的集群成为挑战。
这些都是测试执行环境会面临的问题。
我会分享一些我们的实践，以及我们是如何通过架构演进来不断完善测试执行环境的。
第一版基于jenkins触发测试执行，这是最早也是最典型的测试执行环境。
即基于jenkins触发测试执行，我们把测试用例放在geteup中，jinkys会去获取这些用例，再在远程固定的测试执行环境中去跑这些用例。
第二版基于test runner test execution system,因为jinkins中跑测试的脚本会越来越多。
因此基于第一个版本，我们在jinkins脚本的基础上封装了一个test execution service.这个服务会对jinkins中的job进行版本管理、用力管理等，以方便发起所有测试。
同时，这个服务不仅提供UI界面，以方便开发的使用和对用力的管理，还提供racstful API接口，用于与CICD的无缝集成第三版基于selenium bridge,提高测试并行执行能力。
原本在整个架构中远程测试执行环境，这一部分是一个固定的测试环境，都是VM.而在这个版本中，我们用selenium grade搭建了一个herb可以容纳上百台机器，下面挂了很多包含不同OS和浏览器版本的node. Selenium bridge其实是一个小的集群。
这个集群通过一个中央节点来接收所有的测试请求。
拿到请求后，他会先去查看该测试请求是要跑在什么操作系统上的什么浏览器上面，再去查看自己的节点里面有没有相应的机器。
如果有，他就会把这个测试发到机器上去，执行第四版。
基于jenkins cluster,提高测试并行执行能力。
随着测试用例变多，原本远程测试执行这一块呢瓶瓶，但有了sellinum gragrade之后，这里的瓶颈问题已经被解决。
现在当有大量测试请求集中到来的时候，所有的测试用例都开始在jenkins这边排队，jenkins的单节点就成为了瓶颈。
基于这个问题，在第四个版本中，我们把jenkins打造成了一个集群解决掉了系统的瓶颈。
点第五版基于测试负载，用docker实现selenium grid的动态扩展与收缩。
经过前面四个版本的演进，看似整个测试执行环境的基础架构已经比较完善了。
但是在ebay内部有个很现实的问题，相信不少有全球性业务的公司也会遇到，即我们一套测试用例可以在全球各个站点上执行测试。
同一个测试用例，如果呈上支持的国家数量之后，用例数据就会暴增。
在这种情况下，selenium grade里放多少台node合适就成为了问题。
多了的话，平时会浪费，少了的话，等用例来了又需要排队。
我们的做法是用docker实现selenium grid的动态扩展与收缩，做了一个auto scaling的服务。
根据前面的用力排队情况，来决定需要多少node动态的去扩张整个node的数量级。
这样做还带来另外一个好处，docker化之后自然而然就解决掉了。
测试执行环境的维护难题，可以通过docker主要维护image镜像，后面的东西全部是自动化的，不需要做太多管理。
除了以上提到的架构演进，我们还通过app m和selenium grede搭建了一个移动终端的测试执行集群。
集群里面放了各种各样的手机设备，开发人员指定要哪个品牌，哪个型号的机器测试系统就会自动到这个集群中搜索。
如果有符合要求的机器，系统就会自动把测试发上去，执行完成之后再自动结束。
执发人员都不需要知道这个集群搭建在哪里，他只要调用服务就可以使用。
这样一来，对于开发人员来说，他们做测试时就完全不需要考虑测试执行环境的问题，他们只要弄清楚自己的需求就可以了。
整个测试执行环境对他们而言是非常透明的。
同时，这样一个基础架构的维护成本也非常低，只需要工程效能团队定期维护就可以了。
结宇为了进一步提高软件开发效率，测试环节也是需要技术管理者们重点关注的方向。
如今，测试正在经历去除QE向工程效能转型的过程。
在这一过程中，开发人员将更多的介入测试环节。
因此，如何提供给开发团队简单易用、高效的测试基础架构就变得尤为重要。
本文分享了测试执行环境架构的演进过程，希望能给有意向转型的团队提供参考。
不知道你的团队目前在采用怎样的测试策略呢？测试执行环境又是如何搭建的呢？欢迎留言分享，感谢你的收听，我们下期再见。