软件质量之道：gtest之一

我和谁都不争，和谁争我都不屑。我爱大自然，其次就是艺术。我双手烤着生命之火取暖，火萎了，我也准备走了。

兰德 《生与死》

 

1 愉快的写生课

周六（或者说是周日），高兴的难以入眠，迷迷糊糊睡着时，天已经有些发亮。然后又在迷迷糊糊之间，被闹钟叫醒。

首先跑去公司，确认一下后台程序稳稳的执行着，然后就愉快的去参加2345小伙伴们的写生课了。

嘛，原谅我这无聊的流水帐，但是我也“爱大自然，爱艺术”，发现生活中的美与乐趣，收获也是蛮多的。

作品如上，是世纪公园的云帆桥，后面那团黄色是大黄鸭，原谅我这第一次的写生。

瞎扯结束，开始正文。正如闯爷所说，如果不知道如何开始，那么先确定范围，确定目标，定下主要框架，就可以开始画图了。

 

2 范围、目标与框架

前面几部分话题，主要是借助于外部工具，进行代码的静态分析，获取质量控制的目标。其实这么说起来，质量还是一个很空的话题，毕竟工具不是万能的，不能百分之一百的确定代码的质量。现在，需要确定“范围”，确定“目标”，确定“框架”。

“范围”，是如何精确控制代码的质量。“目标”，是控制代码质量的标准是什么。“框架”，是使用什么方式来进行控制。

针对于软件来说，控制代码的质量的根本，是Bug率（包括性能部分的Bug），那么我们的“范围”基本可以定为：如何降低Bug率。从这个“范围”出发，“目标”也就很明确了，那就是Bug率。至于“框架”怎么办，那么问题来了。

降低Bug率，那么就要让Bug可控，让Bug可控就是让代码可控，代码可控自然就是UT增强，UT增强则又要分析代码覆盖率问题，等等等等，总之软件质量的问题从来就很多，谁说不是呢。

说了这么多，“框架”问题，可以理解为“UT框架”问题，所以本文主要介绍C++UT框架，google test，简称gtest。

PS：UT为Unit Test，中文为单元测试，详细信息请参考百度百科等说明，这里不详细展开解释。

本来打算全部写在一篇里面，考虑到看起来过长不是很方便，所以也打算拆成两篇来讲。第一篇主要为gtest测试框架搭建，第二篇则主要为gtest测试框架的使用。当然，可能不会面面俱到，如果遇到什么问题，可以Google一下，或者直接留言，我会第一时间帮助解决，并添加Q&A部分内容。