测试开发之路—-CI (开发部分的持续集成)

背景

如今软件行业发展到今天，大家都有一个共识就是产品质量光靠测试来保证是扯淡的。应该从团队的各个角度都对产品质量做一层保障。我们架构师和CTO也总是跟我说：不要总从技术角度着手，你要想办法从流程上提高效率，增加质量保证。想办法让所有人都参与到测试当中去，只是你自己在测试不叫QA，你只是测试人员。能从各个方面保证产品质量你才是QA。虽然他们没怎么做过测试工作，但不得不说他们的方向是正确的，在这样的领导下面干活确实痛快。我说要搞CI就支持我搞CI，我说让开发人员写单元测试就帮我去游说开发的同学们写UT。从毕业到现在第一次干活干的这么痛快过。领导给个正确的方向，然后就让小弟们自由发挥，他全力支持。这样的模式真的是我梦寐以求的工作环境。据说06年我们老板在ACM夺冠的时候，就是我们架构师负责测试的。所以他特别重视测试，每一个测试的候选人都要他面一次。 我只能说我是走运的。在这样的环境下工作能避免很多在其他公司碰到的无形的屏障。
好了，说了很多废话。我这人啊，一上了年纪就喜欢啰嗦。咳咳，说正题。之前我和领导一直在游说开发的同学写单元测试。效果不错，API模块的覆盖率已经到36%了。但是仍然需要一套CI的机制来辅助单元测试的执行和bug定位等工作。我之前就说过测试开发很重要的工作之一就是帮助其他人更容易的进行测试工作。所以这个活理所应当的在我身上了。

测试框架的选型

首先从框架选型开始吧。开发的同学们着实不了解这些。所以需要我向他们推荐一些东西。

1. Junit:本来想用我熟悉的testng，但是开发的同学说测试springmvc只能用Junit。所以只能这样了
2. mockito：大名鼎鼎的java mock框架。解耦，提高覆盖率，行为测试的神器（专门开会培训了一下开发怎么用）。
3. mockmvc：想测试springMVC的controller的话，只能用这玩意了
4. hsqldb：java的memoryDB，能够模拟真实的数据库，但是运行在内存中。单元测试的不二神器，提高运行速度，跟真实环境解耦。

OK,从上面可以看到，我们通过各种mock和memoryDB，已经跟真实的环境彻底解耦了。这样其实在CI非常重要的一步自动化部署环境，我们已经可以忽略不做了。同时还提高了覆盖率和运行速度。

CI工具（Jenkins）

这个不用说了，大部分用的都是这个。需要装一些插件，我列几个主要的吧。

1. git hub
2. gitlab
3. jacoco
4. extend email
5. HTML report publisher
6. 。。。等等各种跟git相关插件，我现在想不起来了

我们的需求其实是这样的。由于之前框架选型的时候我们跟真实的环境彻底分离，所以其实我们的运行速度是十分快的。所以我们要求每一次开发push或者merge代码的时候都触发执行一次。每一次拉取最新的代码（需要开发有良好鲜明的分支策略）。然后生产测试报告，覆盖率报告，git状态，代码变化记录等等。所以我就按下面的步骤开始工作了。

具体步骤

首先源码管理是必须的，在源码管理里面使用git

构建触发器

注意上图中后面的URL，那是Jenkins当前job的service的URL，是需要你加到git的webhooks中的， 如下图

这样当你勾选push和merge的events的时候，git就会通知Jenkins触发job。这就是webhook的作用，这样避免了SCM的那种轮询式监控git的低效率

覆盖率设置

github设置

github的设置，可以让你得到详细的代码变更信息，这个也很重要

我们看看效果

OK，主要的设置我们了解了，下面我们看看运行的效果吧。

首先，我们从build的历史中可以看到，是哪个开发的同学的哪个push或者merge操作触发了我们的build

然后，我们看看job的整体信息。上面有历史的测试结果趋势和代码覆盖率的趋势图。最新的测试结果和代码变更

每个build的详细信息

我们点进去一个运行记录后，发现我们可以得到一些信息：*这次push或merge的代码变更信息，单元测试的结果，fail的case的详细信息，代码覆盖率的信息，这次build的分支信息等 *。 我们点进去每一个信息后都有详细的信息，例如：如果我点击changes中的代码变更信息。我们就跳到了git的commit的详细信息中去了，如下图。

这个功能满重要的，如果开发的单元测试突然失败的话，我们可以看一下这次运行相对于上一次都有哪些代码改动。很可能就是这些代码改动造成了单元测试的失败。bug定位的利器

总结

其实大家还可以扩展很多功能，Jenkins还是挺强大的。例如你可以控制一旦执行成功就merge到其他分支中等等策略。不过这有点配置管理工程师的意思了。我暂时还不关注。其实大家也看到了，这过程中我一行代码没写。做的事情无非就是推行单元测试的CI，制定一个流程，推荐和培训开发人员怎么使用测试框架，怎么设计代码可测试性比较好，在Jenkins上配置一些job。看上去有点打杂的架势。跟我们想的测试没什么关系。但是我觉得，我们这些人之后的发展，也许会越来越靠这方面，现在各个企业都在缩减专职测试人员的数量，全民测试的时代，也许不远了。我也算给大家踩踩坑，看看这种模式可行不。目前来说发现的bug还是挺可观的，只是开发一直编写UT和维护这些UT的成本我们以后要控制一下，增加一些更有用的策略，不盲目追求覆盖率，协商比较合理的流程和规范等等，不过这些就让我去慢慢的踩坑吧

,