测试开发之路 进击的 2019 (一个小小工程师的又一次回首)

孙高飞 · January 17, 2020 · Last by zailushang replied at February 16, 2020 · 2808 hits

前言

3个月前在测试活动的时候写过一篇总结, 里面总结我过去4年的在公司在社区的事情。 所以本来是不打算写总结了。 不过那篇文章写了不少与工作无关的事情, 也没有聚焦在2019年。 所以想想正好后天部门就要做年终总结了, 我也就趁着这个机会写一写,权当是演讲稿了。

k8s技术栈

就先说说我最爱的k8s吧, 我在很多场合都表达了我对k8s对容器生态的热爱,我也把16年第一次接触docker当做我技术生涯中最重要的里程碑之一。 我在公司内推行的技术方案几乎都与k8s有关。 我画了一个容器技术的成长路线图

从图上可以看到,我们每一年都会有新的成长并成就新的项目。 我简单列一下我这边主要利用到了k8s的解决方案。

  • 浏览器集群:浏览器集群化部署在k8s中,提升资源利用率并可同时提供数百浏览器的服务支持
  • 持续集成:先知2项目中,编译,出包,部署,测试全部容器化并利用k8s自动化部署与运维,提升资源利用率并可同时提供70套测试环境的支持。同时今年的大部分测试服务也使用k8s部署
  • 自动化:多数自动化测试项目中都引入了k8s client,在测试中操作k8s来完成较难的测试场景。
  • 稳定性测试:扩展k8s的client-go来自定义k8s控制器,监控集群中所有的相关事件。同时对接普罗米修斯的push-gateway。弥补了普罗米修斯在实时监控能力上的不足(普罗米修斯是pull 架构,无法做到实时监控的效果) 这样再调用jenkins client,我们就创造了可以持续数周的自动化测试和监控效果。这种测试也成为浸泡测试,验证产品在长期的全链路业务测试下的稳定性。
  • 混沌工程:自定义k8s operator(CRD+自定义控制器), 自定义k8s admission webhoook, 在扩展一下k8s的client-go。 封装封装实现了故障注入,测试分析,恢复,监控这一套的自动化解决方案。

恩,主要的就这些了。 我再自己思考的时候其实也发现了一个规律,就是在上面图里写的。 很多时候这些解决方案并不是我们事先规划好后才去学习实践的, 而是在更深入的了解容器和k8s后才发现,原来我们可以利用k8s的能力来做这些事情。 所以我有一个很深的感受就是--技术创新取决于对技术理解的深度。 早期觉得k8s只能解决解决部署问题,后面才知道原来k8s可以做的远远不止这些,以前想不到要做这些,完全是因为我对k8s的理解不够深。 好了这里就聚焦的说一说稳定性测试(也叫浸泡测试)和混沌工程吧。 因为他们两个是我今年主要的成绩了。也是我在更深入的理解k8s的机制后在去年年末开始开发的方案。

  • 稳定性测试(浸泡测试):归功于全团队的小伙伴在UI自动化上的努力,我们在年末已经达到了2000+ 的自动化测试用例,所以我才能有这样的全链路的业务自动化测试用例集,我从中挑选了1200个测试用例,覆盖产品所有的主要业务场景。 然后我根据k8s的client-go 自定义了k8s的控制器, 监控了所有产品模块的事件和状态变化。虽然我们已经有了普罗米修斯,但由于普罗米修斯是pull架构,监控的目标也太多。 设置的是1分钟pull一次数据。 这样的话就有个问题,在1分钟内发生的事件会丢失,普罗米修斯监控不到。 并且我们在事件发生时还需要抓取额外的信息, 比如crash事件发生时是希望抓取到瞬间的容器日志和crash原因以帮助研发人员分析代码。 所以利用k8s的client-go就能做到这些,达到报警并发送日志的效果。同时为了能够显示在普罗米修斯的grafana仪表盘上,我们也专门部署了push gateway进行对接,将我们自己收集的监控数据push上去。 通过这种测试方法,我们在今年发现了70个有效的bug,这些bug都是在功能测试中无法发现的,比如OOM,并发缺陷,以及很偶然的缺陷,举个例子我们有个bug是在系统设置的日志清理的cronjob和某些离线任务一起运行的时候才会触发。 而这种bug只有在稳定性测试中持续数周的不停的测试才能够发现。
  • 混沌工程:同样归功于小伙盘们在UI自动化上的努力。在混沌工程中我仍然使用了跟在稳定性测试中一样的测试用例集合,覆盖产品所有主要业务场景。市面上的混沌工程实践多是故障注入后观察QPS等方式,甚至是直接在线上模拟故障后来观察QPS影响。 这显然不是我想要的。 我希望能在测试环境中就准确的分析出故障的影响,精确到影响到哪些模块哪些业务,什么样的故障发生后是对业务完全无影响的,什么样的故障发生后会有多久的业务空洞期等等。 所以全链路的业务测试是必要的。 同时为了实现灵活的故障注入,我们开发了自己的chaos模块。在引入常见的物理故障(CPU过载,网络丢包,网络延迟等)外还引入了jvm-sanbox和proxy server。 jvm-sandbox注入字节码的方式可以动态修改产品代码逻辑来达到故障注入的逻辑,甚至是模拟系统临界点。 比如我们的产品中有非常多的提交到hadoop上的离线大数据和机器学习任务。 而我们的调度模块有一个保护机制, 就是任何一个executor只能同时维护100个离线任务的运行。如果超过100个的话请求必须转移到其他executor上以保证单个executor的稳定。 这种场景的实现成本是很高的, 如果真的发送100个运行任务的话,切不说编写这部分代码的成本,100个大数据任务对hadoop集群的资源消耗也是很恐怖的。而我们恰巧就想知道当系统中有一个executor达到了这个临界点后,是否能正确的触发请求转移等后续机制。 所以jvm-sandbox帮助我们很好的解决了这个问题。 以字节码注入技术直接让系统误以为同时运行的任务数量已经达到了100个。 在第四范式的混沌工程中,除了要模拟故障外,还会模拟系统中的各种临界点。以保证在这些极端的临界点场景下,系统依然能稳定高效的提供服务。而proxy server 通过劫持目标服务的请求并进行篡改来达到另外一种形式的故障注入,比如我们的审计模块要求所有底层组件的审计请求在失败后不会影响底层任务的运行, 也就是即便审计失败任务依然可以继续运行下去, 而业务层的审计失败则要求业务中断。 但他们又是访问的同一个接口,使用jvm-sanbox的话想要如此精确的模拟特定模块的请求的异常成本是很高的。 所以我们注入代理服务, 这个服务能够精确的制定http请求规则,包括如果请求中带了什么样的参数,cookie,header等信息,精准的规则匹配就能使我们拦截到所有底层组件的请求,并直接返回500 来达到故障注入的效果。 所以这样我们就可以模拟出同一个接口,所有业务模块会正常返回,但是底层模块会返回500的故障。 这样我们通过针对每一个服务,反复的故障注入,测试,恢复。 自动化的遍历所有服务的所有故障,完成了自动化混沌工程的实践。

上面着重说了我认为我今年对质量部做的最主要的贡献了, 也是我认为自己这一年在技术上最大的亮点了。 为了深入了解k8s今年我个人全面拥抱了golang语言, 学习容器的各种知识,k8s的内部源码。 这也是我在19年技术上最大的成长了吧。 以前的我是熟悉k8s,能在很多场景利用k8s的知识解决问题, 但我并无法扩展k8s的能力。 而19年我学会了编写k8s operator 和admission webhook。 前者可以自定义k8s资源对象并通过自定义控制器来操作k8s, 比如玩过k8s的都知道k8s的那些预制的资源对象,比如Pod。 而我则可以自己定义一个叫PodChaos的对象提交给k8s,并且我的自定义控制器可以接收到用户发送给k8s的这些请求做处理。 而admission 更像是一个拦截器, 它本身是一个https服务,但我们把它注册到了k8s的api server中。 它可以拦截用户发送到k8s的请求并加以篡改,注入我们想要的任何逻辑。 上面说的稳定性测试和混沌工程其实就是用到了这两个方案。

自动化测试体系

恩, 到了今天,我们形成了自己一套体系出来,大概的样子就是下面这样。

这个图几个月前画的了,有些数据已经不准确了(我也懒得更新了哈哈哈) 测试用例当时错误的只统计了UI自动化,现在加上其他的测试类型,估计大几千了吧。除了业务层和中间件层,下半年接手了最底层的算法的测试小组。 所以其实还应该把这些算上。 这些算是质量部成立4年以来积攒下来的家当了, 当然这些是大家共同努力的成果, 我没有打算一个人冒领这些功劳。今年我们努力让UI自动化突破了2000大关, 通过率还不错, 更新完脚本后一般在90%~95% (有些场景由于k8s原因实在是稳定不了)。 这2000+ case用100个浏览器运行也需要3个小时时间(我们业务里各种机器学习模型算法,大数据任务,一个case动辄跑半个小时,1个小时的都是不奇怪的)。直接让用人工测试需要至少1周的全功能回归测试缩短到了1天。而我们又有各种兼容性测试和升级测试, 比如兼容各种浏览器版本,兼容各种hadoop集群,兼容各种数据库版本,操作系统版本,这些都是需要运行大量的测试的。 引入UI自动化为我们提升的效率是无法估量的。 这算是我们对行业中大范围的关于UI自动化的质疑做的最有力的回击吧, 我一直是想为UI自动化正名的。 同样今年质量部在中间件层和底层的测试也都遍地开花, 测试用例数以千计。 只是我和我的领导都觉得仍然不够, 明年会开启产品组件化拆分项目, 我们会加大投入底层的测试粒度。

从上面那个图其实可以看出来,整个自动化体系大部分都是在k8s的支持下的, 这是我针对k8s异常的热爱导致的~~~

产品研发

10月份的时候有机会轮岗到了数据智能部,这算是我第一次正式参与到了产品的研发中。 是一个用来为用户生成特征抽取规则的小组件,并不难。 直到前几天还在解自己的bug~~ 跟我一块开发的同事(也是QA) 还说呢, 自己开发自己测试给自己提bug,感觉好奇怪哈哈哈。 这算是一个小插曲吧, 因为功能并不难,也没花多久就结束了,记忆中好像就1周多? 真是有点忘了。 但是第一次做开发职能还是值得提上一笔的。

产品设计

年中的时候有幸被大家选中,负责设计数据治理专项的产品解决方案,算是第一次跨界做产品经理了, 当时很用心,做了很多调研和沟通。 写了3万字的文档。 可以说这是我今年第二用心做的项目了。 当时动力很足, 只可惜虽然方案被采纳了, 但是由于人力问题,我们总是有更高优先级的事情。 所以这个项目一直拖到了20年也没能落地。 感觉遥遥无期,算是今年最大的遗憾了, 不过人生不如意十之八九, 哪有一帆风顺的。

工作上其他的事

其他的事都不算大,边边角角的也就不想说了。无非就是一些日常项目的跟进。 唯一可以说的就是接受了算法团队的测试,带着两个人一起吭哧瘪肚的测试自研算法。不过也主要是他们两个在做了, 我算是打酱油,就前期调研了一下方案而已。

Testerhome社区

这篇一开始完全是想写工作上的事,不想掺杂其他的东西。所以社区和生活上的事就没仔细说, 这里还是提一下吧,毕竟社区对我的影响也是很大的。 19年参与了社区的北京大会和深圳大会,分别是高新专场和AI专场的主持人,也参与了幕后的准备工作。 索性没掉链子,没给大家丢人。 20年的北京大会我们也在准备中了。 我也推荐了我的同事报名了混沌工程和k8s相关的议题。希望能入选吧。

尾声

总的来说19年的收获也不算小, K8S能力有了大的突破, 各个自动化项目也都有声有色的。 还进军了研发和产品领域。 所以我的标题写的是进击的2019,意思是今年突破不小(而且我是进击的巨人的漫画粉~~哈哈哈)。 过去每年我都要求自己有新的突破,学习到新的技术或者能力。 但到现在我还没有找到20年主攻的方向(除了组件化拆分)。 希望20年末做总结的时候我依然能跟我自己说这一年没有白过哈~ 另外祝大家过年快乐。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 20 条回复 时间 点赞

总能从大佬的文章学到东西~

大佬太厉害了!

最直观的进步是,高飞你的绘图能力显著提高😁

simple 回复

process on 会员 135/年 你值得拥有~~~

飞哥牛逼,扎扎实实的做大工程

zailushang 回复

过奖了,规模都不大。没多少代码量的

请问文中“浏览器集群:浏览器集群化部署在k8s中,提升资源利用率并可同时提供数百浏览器的服务支持”
是指:用docker部署不同内核浏览器,便于各个浏览器进行兼容性测试?

阿三 回复

不是的。兼容性测试还是需要实际用Windows和mac操作系统部署浏览器注册到集群中的,这样才最真实。 那几百个容器化的浏览器是用来做与浏览器兼容性无关的测试的。 比如功能测试, Hadoop集群的兼容性测试,数据库版本的兼容性测试,k8s版本的兼容性测试。 ps:我们是to b的项目,产品要部署在客户场地。所以对接客户的Hadoop,k8s,数据库,操作系统等。 所以才延伸出了上面说的这些兼容性测试

孙高飞 回复

就是快速部署线上不同版本环境来复现及相关版本兼容性测试

阿三 回复

差不多把。 所以我们的浏览器集群有2种浏览器来源。 一种是部署在k8s中容器化的浏览器。 另外一种是部署在虚拟机中用来做浏览器兼容性的。 我们根据不同的测试目标可以选择使用特定的浏览器。 部署在k8s中的浏览器全部以linux系统驱动,优点是节省资源,利用k8s的分布式和自动化运维能力能很好的管理和迁移。降低了很大的运维成本。 但它的缺点是无法模拟windows和mac的内核。 所以做兼容性测试还是需要到windows和mac系统上部署浏览器再加入到集群的hub上来。但这种浏览器的缺点就是运维成本很高,并且极其占用资源,无法部署太多的浏览器。 不像部署在k8s上的浏览器,随随便便部署几百个是很轻松的。

看了下大神的ui自动化, 稳定性90%以上以为说的是app的ui自动化存在质疑,原来是web的,不过很厉害了。

小萨 回复

没做过移动端,移动端是非常不稳定么?

孙高飞 回复

是的,手机端UI稳定性远不如pc端

小萨 回复

原来如此

飞哥可以写写你们的测试平台吗?

zailushang 回复

其实都是大都都是开源东西拼起来的,没啥好讲的😂

孙高飞 回复

嗯嗯,看来你周末不休息啊

zailushang 回复

一个人在北京自我隔离, 无聊的要死,自己给自己加加班

孙高飞 回复

好吧,哈哈

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up