关于职业规划:面向价值编程低边际成本的自动化测试
版本日期备注 1.02022.11.14文章首发本文首发于泊浮目标掘金:https://juejin.cn/user/146860... 0. 前言17年刚退出ZStack时,ZStack正在经验从能用到好用的阶段。这个阶段会有更多的需要,对品质的要求也会更高。举个例子,toB的产品如果在一个行业里拓展开,个别都会想方法拿下龙头企业。大家都是这么想的,你会面临更多的竞争对手。抛去其余层面,单从技术层面来说,技术人员不仅须要提供相应的性能满足客户需要,还须要思考性能在不同的场景下还可能良好的运作。 1. 先兆周一日常周会,当研发们汇报完本人的工作后。PM开始盘点以后版本遗留的bug,这时张鑫发现bug比平常多了点,测试的负责人也开始说起了近期问题的增长。这让张鑫非常的苦恼,那时的我却没意识到什么。 直到过了几年我开始带团队了我才意识到这是一种先兆——零碎的复杂度正在失控,这种失控在后续的迭代中会带来越来越多的问题。 前面研发与测试独自拉了一个小会,探讨了一下目前的具体问题与细节。有人谈到了自动化测试——目前的自动化测试切实太难用了,java的代码,xml的数据配置:尽管数据和行为解耦,但写起来只感觉啰嗦,并没有感觉多不便,大家都不太乐意去写。这个会开完不久后,张鑫神速的撸出了一个测试框架。 这个框架具体的实现以及一些实用tips在本文中不会再介绍,这个在ZStack的Github Repo wiki里有介绍,我之前的文章也做过相干剖析,有趣味的读者能够自行翻阅。 2. Bug大整治测试框架入世之后,所有开发又被拉到了一个会议室。张鑫介绍了一下本人的测试框架以及应用办法,并开始调配之后的工作: 进行所有的开发工作,即日起整体开发投到测试库中工作。将之前的java写的测试用例全副迁到这个测试框架,如果测出bug顺便修复掉。安顿一个测试同学做Gitlab CI机器人,所有patch合入都要依赖这个机器人,判断所有case跑过了才能够合入。后续版本迭代中,每一个ZStack治理平台引起的bug,合入时必须有对应的测试笼罩。安顿一些测试同学来设计一些用例,并编写成测试代码。那时笔者也参加了其中,刚开始写用例的时候,其实是非常厌恶groovy的——动静类型的语言对开发者的要求相对来说高了一点,作为groovy老手是有点麻烦的——很多问题直到runtime才会报错。但groovy又是强类型的,因而在runtime时不会跑出很奇怪的后果(JS就会),只会报错。提供了肯定方便性的同时,也没减少多少debug老本。 强弱类型:强类型意味着确认了类型当前,如果强转一个谬误类型时,将会报错(编译期or runtime);而弱类型则容许强转,这种状况下则可能产生一些令人意想不到的事。 动静VS动态类型:动态类型须要在编译器就确定字段的类型;而动静类型则会在runtime时依据高低问推导类型——因而咱们能够在不晓得办法具体细节的状况下编写对象上的调用语句。在运行期间,对象会动静地响应办法或音讯。 在起初浏览测试框架实现时,笔者逐步发现了动静类型的魅力——尤其是在测试场景,能够轻松的mock相干办法的返回值,来造成针对性的case。 这部分次要体现在groovy对于元编程的反对上。 同时,groovy还有一些语法糖并反对操作符重载——这意味着能够轻松的创立DSL。这让测试代码写起来十分的难受,齐全没有了之前写java时的verbose。 3. 小结当测试框架齐全落地后,咱们开始了新一轮的迭代。这次迭代过程中,经QA统计,bug趋于收敛,这意味着测试框架产生了价值: bug通过case one by one笼罩,节俭了测试在回归上的人力耗费。从全局来看,防止了测试环节报bug的重复沟通与测试,优化了业务的吞吐量。回头看,这个测试框架做的事用Junit+Mockito也能够做到。但一个好的测试框架,还会带来更低的边际老本——每个开发可能疾速的编写测试代码,而因为测试框架自身提供的DSL与groovy的个性,让代码量相比原版java的test case无效缩小,从而有了更强的可维护性。 无关好的测试框架,在之后文章还会探讨——比方Spock通过语义标签以及DSL来加强测试用例的可读性和可维护性。