关于职业规划:面向价值编程低边际成本的自动化测试

本文首发于泊浮目标掘金:https://juejin.cn/user/146860…

0. 前言

17 年刚退出 ZStack 时，ZStack 正在经验从能用到好用的阶段。这个阶段会有更多的需要，对品质的要求也会更高。举个例子，toB 的产品如果在一个行业里拓展开，个别都会想方法拿下龙头企业。大家都是这么想的，你会面临更多的竞争对手。抛去其余层面，单从技术层面来说，技术人员不仅须要提供相应的性能满足客户需要，还须要思考性能在不同的场景下还可能良好的运作。

1. 先兆

周一日常周会，当研发们汇报完本人的工作后。PM 开始盘点以后版本遗留的 bug，这时张鑫发现 bug 比平常多了点，测试的负责人也开始说起了近期问题的增长。这让张鑫非常的苦恼，那时的我却没意识到什么。

直到过了几年我开始带团队了我才意识到这是一种先兆——零碎的复杂度正在失控，这种失控在后续的迭代中会带来越来越多的问题。

前面研发与测试独自拉了一个小会，探讨了一下目前的具体问题与细节。有人谈到了自动化测试——目前的自动化测试切实太难用了，java 的代码，xml 的数据配置：尽管数据和行为解耦，但写起来只感觉啰嗦，并没有感觉多不便，大家都不太乐意去写。这个会开完不久后，张鑫神速的撸出了一个测试框架。

这个框架具体的实现以及一些实用 tips 在本文中不会再介绍，这个在 ZStack 的 Github Repo wiki 里有介绍，我之前的文章也做过相干剖析，有趣味的读者能够自行翻阅。

2. Bug 大整治

测试框架入世之后，所有开发又被拉到了一个会议室。张鑫介绍了一下本人的测试框架以及应用办法，并开始调配之后的工作：

1. 进行所有的开发工作，即日起整体开发投到测试库中工作。
2. 将之前的 java 写的测试用例全副迁到这个测试框架，如果测出 bug 顺便修复掉。
3. 安顿一个测试同学做 Gitlab CI 机器人，所有 patch 合入都要依赖这个机器人，判断所有 case 跑过了才能够合入。
4. 后续版本迭代中，每一个 ZStack 治理平台引起的 bug，合入时必须有对应的测试笼罩。
5. 安顿一些测试同学来设计一些用例，并编写成测试代码。

那时笔者也参加了其中，刚开始写用例的时候，其实是非常厌恶 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 来加强测试用例的可读性和可维护性。