这段时间在 OKR 的驱使下，我们团队在业务测试和目标达成的路上专注的奔跑，战线拉的越来越长，担心积压的内容太多，走得太远而忽略了前进路上遇到的经验教训的归纳和沉淀。恰逢团队再次调整，借此机会来回顾一下从 2018 年团队下半年到 2019 年底，第一次调整后我们团队总共做了哪些事情，取得了什么样的进展，遇到了哪些坑。
专栏文章，写的比较随意。
2018 年下半年，团队从 6 个人增加到 21 个人，支持的业务类型也从单一的移动端方向，扩展了模型算法、Web 端、服务端产品线，业务线方向跨度很大。盘点下来，我们团队的业务主要分四个方向：
三条不同的业务线，面临的情况各不相同，基本上涵盖了测试行业各种业务的通病。（效能平台本文先不做介绍）
托尔斯泰说：“幸福的家庭都是相似的，不幸的家庭各有各的不幸”。看了上面的问题，是不是多少能找到自己项目的影子？团队整合后，面临的问题形形色色，没办法挨个细说，我们团队对现有问题进行了拆解和讨论，并形成了三个大的目标来达成。
团队推行 OKR 后有很多好处，具体参看团队之前写的文章：https://testerhome.com/articles/17888
围绕着上面提到的目标，我们拆解为四个季度要完成的 OKR，可以给大家看一下部分的 OKR 系统的截图：
补充一下：这个 okr 系统是奇效平台花一周时间做出来的，之前都是管理在 Excel 中
围绕着总体的三个目标，我们对项目流程进行了分解，分而治之，每个阶段要完成的事情都罗列了出来，大致如下：
从项目立项到发布上线，总共可以划分为五个阶段：
我们推动开展测试的左移和右移工作，除了技术方案外，我们与研发团队一起协商了许多规范和检查机制，其中让我们受益颇多的有几个值得提一下（大厂同学可能觉得很诧异，不是本来就该这样么？）：
在扫平了项目前期的人为障碍后，我们强化了测试能力建设，其中收效最大的主要是两件事：
可能有人要问了，代码覆盖率检查已经是很多年前提到的概念了，并且在 2018 年已经很多公司已经建立了这样的测试手段，这里我想重点介绍一下我们是怎么用的。
提到代码覆盖率，社区里面大大小小可以找到几十篇类似的原理、搭建、使用等介绍的帖子，在这里我重点说一下我们团队的技术历程和思考。
前面提到的，我们团队三个业务线，用的语言分别是Java、C++、PHP。也就是说从一开始我们就不能集中技术力量去解决某个语言的覆盖率方案。好在现在互联网信息的便利，有 TesterHome 社区和 MTSC 大会这样的平台，让我们可以获取到很多优秀团队和公司的做法，这里简单罗列一下我们参考到的方案：
2018 年 MTSC 大会：
2019 年 MTSC 大会：
我们的业务并没有比其他公司的业务独特到哪里去，只不过我们团队要同时解决三个语言的代码覆盖率设计，仅此特殊而已。
在投入去做代码覆盖率的时候，我们明确了一个原则和几个期望：
为什么这么说呢？我这里简单举几个例子：
function test(int a, int b){
return a/b;
}
输入：a=3，b=6；
// 行覆盖率：100%
// 漏测b=0
function test(int a, int b){
if(a < 5 || b < 10) {
return a/b
} else {
return 0
}
}
//输入1：a=3，b=6；
//覆盖率：50%
//输入2：a=10，b=11；
//覆盖率：50%
// 漏测b=0
这里不论是行覆盖率还是 branch 覆盖率为 100% 都说明不了任何问题，这个我们内部进行过认真的讨论，实际上我们在做代码覆盖率的时候，希望能把目光锁定到那些本次新增的代码、方法、类，但是覆盖率为 0 的情况，是什么情况导致我们覆盖为 0？冗余代码？预埋逻辑？覆盖不到？还是漏测了？
几种语言的代码覆盖率方案没办法写在一篇文章中，如果感兴趣的话在社区里都可以找到。这里简单介绍一下我们的方案设计：
PHP 代码覆盖率方案
php-code-caverage 并不支持增量报告的展示，如果需要展示的话也比较简单，只需要做如下事情：
C++ 代码覆盖率方案
C++ 代码覆盖率是我们另外一个组来实现的，其中的一些细节可以去搜一下 Qtest 测试之道里面的两篇文章《gcov C++ 代码覆盖率测试工具》原理篇和实践篇：
原理篇
实践篇
Java 代码覆盖率方案
Java 代码覆盖率的文章，社区里不胜枚举，这里就不再介绍了。
在完成代码覆盖率统计并集成到 Jenkins 后，我们每周的周会都会追踪一下代码覆盖率对业务测试的帮助，一开始大家对覆盖率还是比较赞同，觉得可以辅助测试，假如发现覆盖率数据偏低会主动去检查是否是设计的用例没有执行到。后来有一些同学反馈说，他们通过覆盖率结果反推 case 非常的困难，流程太长。通过了解，我们发现业务测试在补充用例到时候需要做几件事：
在调试一条 case 的时候，整个反馈的链路太长，响应不及时，业务测试同学需要逐条的尝试 case 是否有效，耗费大量的时间。怎么解决这个问题？蚂蚁金服的议题启发了我们！
在跟蚂蚁的讲师沟通后，我们发现要做到他们那样的程度对我们这样的小团队来说不太可能，因为我们不具备这样的技术力量来修改编译器，而且我们还有多语言的需求。于是我们开始尝试了自己的野路子方式，伪实时代码染色系统。
C++ 代码染色系统具备几个功能点：
环境随时切换和锁定
代码树实时更新，绘制完代码树结构后，再在树节点上追加 diff 信息和覆盖信息
增量代码返回结果只渲染代码树的相关增量文件，高亮显示已覆盖的行
支持精确生成单模块、单目录、单文件的覆盖率信息
支持远程操作覆盖率数据
当然系统功能远不止于此，截图太多会影响阅读体验，这里就不详细的介绍。目前我们在做 case 的录制回放，case 推荐等功能，目前效果还在观察，暂时不提。
按测试设备和版本作为 index 来隔离数据
支持全量数据和增量数据切换
伪实时返回覆盖率数据，从测试完成到覆盖率数据返回，渲染代码树大约需要 0.5~2 秒，所以叫伪实时
功能测试完成后要手动刷新数据
这里做了覆盖率数据和流水线打通，关联到触发人员、BuildID 等信息。我们会关注几个点：
总结
参考了业界的进展，我把精准测试的规划拆成了三个阶段：
当下我们刚刚把第一阶段的基础能力建设做完，第二阶段很多事情还在进行中，有些已经完成了但是在观察效果，有些还在建设中，很多大厂已经进入到第三个阶段智能化时代，小团队只能仰望和模仿。
待补充
