如今软件行业发展到今天，大家都有一个共识就是产品质量光靠测试来保证是扯淡的。应该从团队的各个角度都对产品质量做一层保障。我们架构师和 CTO 也总是跟我说：不要总从技术角度着手，你要想办法从流程上提高效率，增加质量保证。想办法让所有人都参与到测试当中去，只是你自己在测试不叫 QA，你只是测试人员。能从各个方面保证产品质量你才是 QA。虽然他们没怎么做过测试工作，但不得不说他们的方向是正确的，在这样的领导下面干活确实痛快。我说要搞 CI 就支持我搞 CI，我说让开发人员写单元测试就帮我去游说开发的同学们写 UT。从毕业到现在第一次干活干的这么痛快过。领导给个正确的方向，然后就让小弟们自由发挥，他全力支持。这样的模式真的是我梦寐以求的工作环境。据说 06 年我们老板在 ACM 夺冠的时候，就是我们架构师负责测试的。所以他特别重视测试，每一个测试的候选人都要他面一次。 我只能说我是走运的。在这样的环境下工作能避免很多在其他公司碰到的无形的屏障。
好了，说了很多废话。我这人啊，一上了年纪就喜欢啰嗦。咳咳，说正题。之前我和领导一直在游说开发的同学写单元测试。效果不错，API 模块的覆盖率已经到 36% 了。但是仍然需要一套 CI 的机制来辅助单元测试的执行和 bug 定位等工作。我之前就说过测试开发很重要的工作之一就是帮助其他人更容易的进行测试工作。所以这个活理所应当的在我身上了。
首先从框架选型开始吧。开发的同学们着实不了解这些。所以需要我向他们推荐一些东西。
OK,从上面可以看到，我们通过各种 mock 和 memoryDB，已经跟真实的环境彻底解耦了。这样其实在CI非常重要的一步自动化部署环境，我们已经可以忽略不做了。同时还提高了覆盖率和运行速度。
这个不用说了，大部分用的都是这个。需要装一些插件，我列几个主要的吧。
我们的需求其实是这样的。由于之前框架选型的时候我们跟真实的环境彻底分离，所以其实我们的运行速度是十分快的。所以我们要求每一次开发 push 或者 merge 代码的时候都触发执行一次。每一次拉取最新的代码（需要开发有良好鲜明的分支策略）。然后生产测试报告，覆盖率报告，git 状态，代码变化记录等等。所以我就按下面的步骤开始工作了。
注意上图中后面的 URL，那是 Jenkins 当前 job 的 service 的 URL，是需要你加到 git 的 webhooks 中的， 如下图
这样当你勾选 push 和 merge 的 events 的时候，git 就会通知 Jenkins 触发 job。这就是 webhook 的作用，这样避免了 SCM 的那种轮询式监控 git 的低效率
github 的设置，可以让你得到详细的代码变更信息，这个也很重要
OK，主要的设置我们了解了，下面我们看看运行的效果吧。
我们点进去一个运行记录后，发现我们可以得到一些信息：*这次 push 或 merge 的代码变更信息，单元测试的结果，fail 的 case 的详细信息，代码覆盖率的信息，这次 build 的分支信息等 *。 我们点进去每一个信息后都有详细的信息，例如：如果我点击 changes 中的代码变更信息。我们就跳到了 git 的 commit 的详细信息中去了，如下图。
这个功能满重要的，如果开发的单元测试突然失败的话，我们可以看一下这次运行相对于上一次都有哪些代码改动。很可能就是这些代码改动造成了单元测试的失败。bug 定位的利器
其实大家还可以扩展很多功能，Jenkins 还是挺强大的。例如你可以控制一旦执行成功就 merge 到其他分支中等等策略。不过这有点配置管理工程师的意思了。我暂时还不关注。其实大家也看到了，这过程中我一行代码没写。做的事情无非就是推行单元测试的 CI，制定一个流程，推荐和培训开发人员怎么使用测试框架，怎么设计代码可测试性比较好，在 Jenkins 上配置一些 job。看上去有点打杂的架势。跟我们想的测试没什么关系。但是我觉得，我们这些人之后的发展，也许会越来越靠这方面，现在各个企业都在缩减专职测试人员的数量，全民测试的时代，也许不远了。我也算给大家踩踩坑，看看这种模式可行不。目前来说发现的 bug 还是挺可观的，只是开发一直编写 UT 和维护这些 UT 的成本我们以后要控制一下，增加一些更有用的策略，不盲目追求覆盖率，协商比较合理的流程和规范等等，不过这些就让我去慢慢的踩坑吧
