83 lines
9.0 KiB
Markdown
83 lines
9.0 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
069 茹炳晟：QE团队向工程效能团队转型的实践之路
|
||
你好，我是茹炳晟，目前担任eBay中国研发中心测试基础架构技术主管，今天想跟大家分享的话题是QE团队向工程效能团队转型的实践之路。
|
||
|
||
在软件开发和项目执行中，工程效能问题一直是技术管理者考量的关键。加快研发效能和提升工程师团队效率及质量，需要在软件智能化上迈出创新步伐。
|
||
|
||
目前，包括Google、eBay等跨国互联网公司的研发团队都在经历“去除QE（Quality Engineer质量工程师）”的组织架构转变，为此Google也暂停了 2017 GTAC并寻求向Engineering Productivity即工程效能的转型。相应地，QE团队也正在逐渐向工程效能团队转型。
|
||
|
||
工程效能团队的好处在于，假如你的研发团队规模为100人，那么工程效能团队可能需要15个人，但当你的开发团队翻了10倍，达到1000人规模的时候，工程效能团队的人数可能仍旧是15个到20个之间。
|
||
|
||
所以，随着开发团队人员的增多、规模的增大，工程效能团队的输出和价值会越来越大，这也是为什么很多大型互联网公司、尤其是全球性的互联网公司都热衷于采用这种模式。
|
||
|
||
如今，谷歌等国外大的互联网公司已经基本实现了向工程效能的转型，国内虽然具体的实践还不多，但很多公司都在做类似的尝试。
|
||
|
||
在这种模式下，整个测试策略发生一个变化。传统的测试由3个部分组成，底层是单元测试，中间是API测试，最上面是GUI测试，是一个类似金字塔的三角形。其中，单元测试由开发人员来负责，API测试和GUI测试都由专职的QE或QA来做。
|
||
|
||
但到了工程效能模式下，除了单元测试，API测试和GUI测试也将由开发人员来做。这意味着，开发人员需要兼任测试的角色，克服从开发到测试的思维局限性。同时，还需要一个很高效的测试平台基础架构，提供一个便捷的测试执行环境，以支持开发人员方便的获得测试数据、执行测试。
|
||
|
||
原本的功能测试团队则蜕化成现在比较热门的探索式测试，测试开发人员则转变成工程效能开发的角色，去做测试平台相关的开发。
|
||
|
||
在这个转型过程中，如何运用原本QE团队积累的技术优势来设计和构建高效的测试基础架构就变得尤其重要，本文将着重分享如何通过架构演进来改善测试执行环境，以达到工程效能的提升。
|
||
|
||
测试执行环境之疼
|
||
|
||
为了提升工程效能，一般会对测试执行环境提出以下要求：
|
||
|
||
第一点，对使用者而言,测试执行环境的“透明性”。所谓透明是指，假如我今天要用测试环境跑一个Mobile的Native测试，需要某个版本、某个分辨率甚至某个品牌的手机，但这些设备不需要自己准备，只要提供相关的参数，后台就会帮我把其他事情准备好，并且把相应的测试分发过去。对使用测试环境的人来说，他希望整个测试执行环境是透明的。
|
||
|
||
第二点，对维护者而言，测试执行环境的“易维护性”。所谓易维护是指，不希望有上千甚至上万台机器的测试执行环境需要人工维护。因此，我们引入了容器化技术，用Docker来准备整个测试执行环境。
|
||
|
||
第三点，对于大量测试用例的执行而言，执行能力的“可扩展性”。引入容器化技术之后，可扩展性自然而然就解决了。我们会根据单位时间内测试用例的排队数量，通过算法来决定这个集群里需要多少台机器才能在规定的时间内执行完全部测试用例。这样整个集群的伸缩也全部由自动化工具来完成，能做到对使用者完全透明。
|
||
|
||
第四点，Mobile移动终端的多样性与碎片化，这使得搭建一个包含各种iOS和Android设备的集群成为挑战。
|
||
|
||
这些都是测试执行环境会面临的问题，我会分享一些我们的实践，以及我们是如何通过架构演进来不断完善测试执行环境的。
|
||
|
||
第一版：基于Jenkins触发测试执行
|
||
|
||
这是最早也是最典型的测试执行环境，即基于Jenkins触发测试执行。我们把测试用例放在Github中，Jenkins会去获取这些用例，再在远程固定的测试执行环境中去跑这些用例。
|
||
|
||
第二版：基于Test Runner／Test Execution System
|
||
|
||
因为Jenkins中跑测试的脚本会越来越多，因此，基于第一个版本，我们在Jenkins脚本的基础上，封装了一个Test Execution Service，这个服务会对Jenkins中的Job进行版本管理、用例管理等，以方便发起所有测试，同时这个服务不仅提供UI界面以方便开发的使用和对用例的管理，还提供Restful API接口用于与CI/CD的无缝集成。
|
||
|
||
第三版：基于Selenium Grid提高测试并行执行能力
|
||
|
||
原本在整个架构中，远程测试执行环境这一部分是一个固定的测试环境，都是VM，而在这个版本中，我们用Selenium Grid搭建了一个Hub，可以容纳上百台机器，下面挂了很多包含不同OS和浏览器版本的Node。
|
||
|
||
Selenium Grid其实是一个小的集群，这个集群通过一个中央节点来接收所有的测试请求。拿到请求后，它会先去查看该测试请求是要跑在什么操作系统上的什么浏览器上面，再去查看自己的节点里面有没有相应的机器。如果有，它就会把这个测试发到机器上去执行。
|
||
|
||
第四版：基于Jenkins Cluster提高测试并行执行能力
|
||
|
||
随着测试用例变多，原本远程测试执行这块是瓶颈，但有了Selenium Grid之后，这里的瓶颈问题已经被解决，现在当有大量测试请求集中到来的时候，所有的测试用例都开始在Jenkins上面排队，Jenkins的单节点就成为了瓶颈。基于这个问题，在第四个版本中，我们把Jenkins打造成了一个集群，解决掉了系统的瓶颈点。
|
||
|
||
第五版：基于测试负载，用Docker实现Selenium Grid的动态扩展与收缩
|
||
|
||
经过前面四个版本的演进，看似整个测试执行环境的基础架构已经比较完善了，但是在eBay内部有个很现实的问题，相信不少有全球性业务的公司也会遇到，即我们一套测试用例可以在全球各个站点上执行测试，同一个测试用例如果乘上支持的国家数量之后，用例数据就会爆增。在这种情况下，Selenium Grid里放多少台Node合适就成为了问题。多了的话平时会浪费，少了的话等用例来了又需要排队。
|
||
|
||
我们的做法是，用Docker实现Selenium Grid的动态扩展与收缩，做了一个Auto Scaling的服务，根据前面的用例排队情况来决定需要多少Node，动态的去扩张整个Node的数量级。
|
||
|
||
这样做还带来另外一个好处，Docker化之后自然而然就解决掉了测试执行环境的维护难题，可以通过Docker主要维护Image镜像，后面的东西全部是自动化的，不需要做太多管理。
|
||
|
||
除了以上提到的架构演进，我们还通过Appium和Selenium Grid搭建了一个移动终端的测试执行集群，集群里面放了各种各样的手机设备，开发人员指定要哪个品牌哪个型号的机器，测试系统就会自动到这个集群中搜索，如果有符合要求的机器，系统就会自动把测试发上去，执行完成之后再自动结束。开发人员都不需要知道这个集群搭建在哪里，他只要调用服务就可以使用。
|
||
|
||
这样一来，对于开发人员来说，他们做测试时就完全不需要考虑测试执行环境的问题，他们只要弄清楚自己的需求就可以了，整个测试执行环境对他们而言是非常透明的。同时，这样一个基础架构的维护成本也非常低，只需要工程效能团队定期维护就可以了。
|
||
|
||
结语：为了进一步提高软件开发效率，测试环节也是需要技术管理者们重点关注的方向。如今，测试正在经历去除QE，向工程效能转型的过程 ，在这一过程中，开发人员将更多的介入测试环节，因此如何提供给开发团队简单、易用、高效的测试基础架构就变得尤为重要。本文分享了测试执行环境架构的演进过程，希望能给有意向转型的团队提供参考。
|
||
|
||
不知道你的团队目前在采用怎样的测试策略呢？测试执行环境又是如何搭建的呢？欢迎留言分享。
|
||
|
||
感谢你的收听，我们下期再见。
|
||
|
||
作者简介
|
||
|
||
茹炳晟，eBay中国研发中心测试基础架构技术主管，具有超过12年的软件测试经验和3年开发经验，和丰富的测试框架设计与自动化测试经验。另外，他还在【极客时间】开设了专栏“软件测试52讲”，系统梳理软件测试的知识体系。
|
||
|
||
|
||
|
||
|