Google Breakpad 完全解析（二） —— Windows前台实现篇

原创文章，转载请标明出处：Soul Apogee (http://bigasp.com)，谢谢。

好，看完了如何使用breakpad，我们现在看看breakpad在Windows下到底是如何实现的呢？

代码结构

在我们来看breakpad是如何实现其强大的功能之前，我们先来看一下他的代码结构吧。

Google breakpad的源代码都在src的目录下，他分为如下几个文件夹：
client：这下面包含了前台应用程序中捕捉dump的部分代码，里面按照平台分成各个子文件夹
common：前台后台都会用到的部分基础代码，字符串转换，内存读写，md5神马的
google_breakpad：breakpad中公共的头文件
processor：用于在后台处理崩溃的核心代码
testing：测试工程
third_party：第三方库
tools：一些小工具，用于处理dump文件和符号表

我们先来看Windows下前台实现的部分，也就是client文件夹下的代码。

breakpad的崩溃捕获机制

在Windows下捕获崩溃，大家很容易会想到那个捕获结构化异常的Api：SetUnhandledExceptionFilter。

breakpad中也使用了这个Api来实现的崩溃捕获，另外，breakpad还捕获了另外两种C++运行库提供的崩溃，一种是使用_set_purecall_handler捕获纯虚函数调用产生的崩溃，还有一种是使用_set_invalid_parameter_handler捕获错误的参数调用产生的崩溃。

另外由于C++运行库提供的崩溃回调中，并不会提供当前的线程现场和崩溃信息，所以breakpad会自己生成好这些信息，然后请求生成dump。
这里值得一说的是，在非异常崩溃处理中，breakpad获取线程现场使用的函数是RtlCaptureContext而不是GetThreadContext。
RtlCaptureContext只能捕获当前线程的现场，而GetThreadContext可以捕获任意线程的现场，只要有这个线程的句柄即可。
但是GetThreadContext有两个不好的地方：不能获取当前线程的现场；获取现场前必须先用SuspendThread暂停目标线程。
而RtlCaptureContext虽然只能获取当前线程的现场，但是调用他时可以不用暂停线程的运行。
对于breakpad来说，崩溃发生后越早获取现场就越好，所以breakpad使用RtlCaptureContext函数作为他的线程获取函数。

breakpad中的C/S结构

由于breakpad是在进程外抓取dump，所以breakpad需要实现一个C/S结构来处理崩溃进程抓取dump的请求。

1. breakpad跨进程通信的实现
breakpad中使用了命名管道来实现IPC。

在客户端，初始化ExceptionHandler的时候，如果指定了PipeName，也就表示此时需要使用进程外的dump抓 取，ExceptionHandler，会建立一个 CrashGenerationClient的对象，由这个对象连接服务端，将自己注册到服务端上 去。
大家可以参看exception_handler.cc中的ExceptionHandler::Initialize函数。

在服务端，初始化CrashGenerationServer的时候，就会建立一个命名管道，并等待客户端来连接。一旦有客户端连接上来，服务端会 为每一个客户端生成一个ClientInfo的对象，之后用这个对象来管理所有的客户端，一旦有崩溃发生，服务端都会从这个对象中取出dump所需要的信 息。
大家可以参看crash_generation_server.cc中的CrashGenerationServer::HandleReadDoneState函数。

2. breakpad捕获崩溃生成dump的流程
breakpad进程外生成dump的流程大概如下：
google-breakpad-out-of-process-dump:

这段流程的代码就是crash_generation_client.cc和crash_generation_server.cc。

有两个简单的问题，这里说明一下，高手们就请直接忽略吧，咩哈哈：
在服务端如何为客户端生成事件句柄？
使用DuplicateHandle，即可把任意一个内核对象的句柄复制到其他进程，并且可以指定产生的句柄的权限。

如何异步的等待一个事件？
使用RegisterWaitForSingleObject，即可异步的等待一个事件，当事件发生的时候，就可以回调到一个指定的回 调函数中，但是要注意的是，RegisterWaitForSingleObject会在一个新的线程中来等待这个事件，此处很容易产生多线程的调用，需 要注意线程问题。

3. 服务端关键数据结构：ClientInfo
ClientInfo是服务端中最重要的数据结构，服务端通过它来管理所有的客户端。客户端注册时，会保存或生成里面所有的信息，在客户端请求生成dump的时候，服务端就会通过ClientInfo获取所有客户端的信息。ClientInfo中保存了如下信息：

• 客户端进程pid和句柄
• 生成Minidump的类型
• 自定义的客户端信息
• 客户端崩溃的线程ID
• 客户端崩溃的信息
• 客户端请求崩溃所使用的事件句柄

这里有一个问题：在客户端发生崩溃时，服务器如何通过ClientInfo获取到客户端的崩溃信息呢？

客户端中有几个用于保存崩溃信息的变量，在注册时，客户端会将这几个变量的地址发送至服务端，服务端将其保存在ClientInfo中，然后当崩溃 发生的时候，服务端就可以通过ReadProcessMemory读取客户端中的信息，从而生成dump。这样做就避免了每次发生崩溃，都要通过Pipe 将崩溃信息传递到服务端中去了。

这些变量分别是：崩溃的线程ID，EXCEPTION_POINTERS和MDRawAssertionInfo。
EXCEPTION_POINTERS和MDRawAssertionInfo的区别在于，异常崩溃的信息会被写入EXCEPTION_POINTERS，非异常崩溃（非法参数和纯虚函数调用）的信息会被写入MDRawAssertionInfo中。

dump文件的上传

在breakpad的工程中，有一个工程叫做：crash_report_sender，里面是一个上传崩溃文件的类，他的实现很简单，他使用Windows Internet Api来完成dump文件的上传。
在使用crash_report_sender时，可以为其指定一个checkpoint_file。

这个文件只有一个作用，就是用来保存上次上传崩溃的时间和今天上传过的崩溃的次数。通过这个文件，我们就可以来设置每日上传的崩溃的最大数量。

调整每日上传崩溃的最大数量的函数是set_max_reports_per_day。

需要注意的是：在上传dump文件的时候，crash_report_sender并不会对dump文件进行分析，而是直接上传整个dump文件， 如果你需要上传的dump文件非常大的话，可以考虑把崩溃分析处理的逻辑放入前台，通过去重或者直接上传分析结果，减少上传的文件大小。

breakpad存在的问题

进程外生成dump有很多好处，其中最大的好处就是不会被崩溃进程影响，这样dump的过程就不容易出错，但是这样也有一定的弊端。

1. 部分崩溃无法抓取
在一些极端的崩溃，如堆栈溢出之类的崩溃，进程外抓取dump有时候会失败。

2. 无法抓取死锁或者其他原因导致的进程僵死
breakpad现在没有检测进程死锁的代码，也没有在服务端控制客户端请求dump的代码，所以现在breakpad无法抓取死锁等进程僵死的问题。不过因为breakpad的定位是处理崩溃，如果有这种需要的童鞋，可以自行修改breakpad的代码，添加这些功能。

3. 对服务端有依赖
如果指定了在使用进程外抓取dump，breakpad对服务端就有依赖。主要体现在抓取dump时，如果服务端不存在，客户端将无法正常抓取dump，甚至有时会出现阻塞。

当然对于这些问题，随着breakpad的发展肯定会越来越完善。如果，你遇到了了这些问题，而又绕过不了，那就改代码，并且提交给breakpad吧，开源项目就是这么发展的。

好，到此breakpad的Windows实现就已经说完了，如果有神马问题，还请多多指教。谢谢大家。

北京德胜门中医院http://www.0531jsk.com/德胜门中医院

Google Breakpad 完全解析（一） —— Windows入门篇

原创文章，转载请标明出处：Soul Apogee (http://bigasp.com)，谢谢。

Google breakpad是 一个非常实用的跨平台的崩溃转储和分析模块，他支持Windows，Linux和Mac和Solaris。由于他本身跨平台，所以很大的减少我们在平台移 植时的工作，毕竟崩溃转储，每个平台下都不同，使用起来很难统一，而Google breakpad就帮我们做到了这一点，不管是哪个平台下的崩溃，都能够进行统一的分析。现在很多工程都在使用他：最著名的几个如 Chrome，Firefox，Picasa和Google Earth。另外他的License是BSD的，也就是说，我们即便是在商业软件中使用，也是合法的，哈哈，这么好的东西，我们能放过么？现在就让我们来 看看这个神奇的软件吧。

原理简介

breakpad抓取dump的方式和一般我们抓取dump的方式不一样。在breakpad的wiki上有一幅图可以很好的概括他的原理。

breakpad把应用程序分成三个部分，代码，breakpad客户端和调试信息。

1. 在build system中，通过symbol dumper用平台相关的调试信息生成平台无关的symbol文件。这样做的好处很明显，一旦平台无关了，所有平台的崩溃就可以做统一的分析了。
2. breakpad采取进程外转储和分析崩溃的方式，他使用C/S结构，客户端用来捕获当前进程中发生的崩溃，并通知服务端崩溃发生。服务端用来响应客户端，抓取dump文件。这样做的目的是为了减少崩溃进程对dump的影响。
3. Dump生成后转发到崩溃分析器中，这个部分可以在本地也可以在服务器上，他对Dump文件进行解析，生成可读的堆栈信息。

这就是breakpad处理dump大概的流程。

对于原理的介绍google写的已经相当好了。更多的详细信息，可以直接移步到breakpad的wiki。

安装和编译

breakpad的编译比较曲折，所以在此记录一下。

编译breakpad，请确认你的机器上装有以下的软件：
1. python 2.4.3
请不要使用python3，会报错。另外python2中推荐这个版本，使用新的版本在编译其他google的工程时有时会报错

2. Windows SDK 7
如果没有这个，编译会报错。另外这个是在线安装，时间很久，最好并行做其他的事情。

3. VS2005的补丁
KB918559
KB926601
KB935225
KB943969
KB947315

已经安装了以上软件的童鞋，就可以开始进行下面的工作鸟

1. 使用svn把代码checkout下来

2. 设置Windows SDK 7
装过其他版本Windows SDK的童鞋，记得一定要进行这一步，SDK的安装程序，并不会帮你设置VS。
运行开始菜单->程序->Microsoft Windows SDK v7.0->Visual Studio Registration->Windows SDK Configuration Tool，选择v7.0，点击Make Current。

3. 为python设置环境变量
由于breakpad使用python来生成Windows下的工程文件，所以需要将python所在目录，设置到环境变量PATH中去。

4. 生成Windows工程文件

此时，在src/client/windows下就可以看到生成好的breakpad_client.sln了。运行吧！

5. Hello World!
编译build all，现在一般是不会报错了，如果报错，请检查是不是漏了什么步骤，特别是补丁。
编译完成之后，运行crash_generation_app吧，这是他的测试程序，dump的默认位置保存在C:Dumps下，请注意先建立好目录，不然会无法使用。
启动测试程序之后，此时还不能抓取dump，因为这个是breakpad中的服务器端，需要再启动一个测试程序，在第二个测试程序中，我们就可以试验Client菜单中的各种崩溃了。这些崩溃都会被抓住转存到C:Dumps目录下。

如何使用breakpad

在Windows下使用breakpad的方法很简单，只需要创建一个ExceptionHandler的类即可，大家可以在crash_generation_app这个工程中找到示例代码，也可以直接移步Wiki，上面说的也很详细。

1.进程内抓取Dump文件

进程内抓取Dump文件是最简单的breakpad的用法。使用方法很简单：

2.进程外抓取Dump文件

使用进程外抓取Dump时，需要指定服务端和客户端，在服务端中需要创建CrashGenerationServer的实例，而在客户端中则只需要创建ExceptionHandler即可。此外，如果服务端自己需要抓进程内的Dump，请将pipe的参数置为NULL。

使用breakpad的时候，有两个地方需要注意：
1. 记得把breakpad的solution下的几个工程，包含到你开发的工程中，或者直接包含他们的lib。
common：基础功能，包含一个对GUID的封装和http上传的类。
exception_handler：用来捕获崩溃的类。
crash_generation_server：breakpad的服务端，用来在产生崩溃时抓取dump。
crash_generation_client：breakpad的客户端，用来捕获当前进程的崩溃。

2. 在初始化breakpad之前，记得先创建好dump文件的目录，不然breakpad服务端将不能正常的写dump，这会导致breakpad客户端在崩溃时无限等待服务端dump写完的消息，最后失去响应。

调试Release发布版程序的Crash错误 （转）

简介： Google 提供一种用于为 C/C++ 软件开发单元测试的开放源码框架，它很有意思，也很容易使用。本文介绍一些比较有用的 Google C++ Testing Framework 特性。本文基于 version 1.4。

为什么要使用 Google C++ Testing Framework？

使用这个框架有许多好理由。本节讨论其中几个。

某些类型的测试有糟糕的内存问题，这些问题只在某几次运行期间出现。Google 的测试框架为处理这种情况提供了出色的支持。可以使用 Google 框架重复运行相同的测试一千次。当出现故障的迹象时，自动地调用调试器。另外，这只需要在命令行上传递两个开关即可实现：--gtest_repeat=1000 --gtest_break_on_failure。

与其他许多测试框架相反，可以把 Google 测试框架内置的断言部署在禁用了异常处理（通常由于性能原因）的软件中。因此，也可以在析构函数中安全地使用断言。

运行测试很简单。只需调用预定义的 RUN_ALL_TESTS 宏，而不需要通过创建或驱动单独的运行器类来执行测试。这比 CppUnit 等框架方便多了。

只需传递一个开关即可生成 Extensible Markup Language (XML) 报告： --gtest_output="xml:<file name>"。在 CppUnit 和 CppTest 等框架中，需要编写很多代码才能生成 XML 输出。

创建基本测试

请考虑 清单 1 所示的平方根函数的原型。

清单 1. 平方根函数的原型

double square-root (const double);

对于负数，这个例程返回 -1。正数测试和负数测试对它都有意义，所以我们编写两个测试。清单 2 给出测试用例。

清单 2. 平方根函数的单元测试

#include "gtest/gtest.h"

TEST (SquareRootTest, PositiveNos) {

EXPECT_EQ (18.0, square-root (324.0));

EXPECT_EQ (25.4, square-root (645.16));

EXPECT_EQ (50.3321, square-root (2533.310224));

}

TEST (SquareRootTest, ZeroAndNegativeNos) {

ASSERT_EQ (0.0, square-root (0.0));

ASSERT_EQ (-1, square-root (-22.0));

}

清单 2 创建一个名为 SquareRootTest 的测试层次结构，然后在其中添加两个单元测试 PositiveNos 和 ZeroAndNegativeNos。TEST 是在 gtest.h（可以在下载的源代码中找到）中定义的预定义宏，它帮助定义这个层次结构。EXPECT_EQ 和 ASSERT_EQ 也是宏 — 对于前者，即使出现测试失败，测试仍然继续执行；对于后者，测试终止执行。显然，如果 0 的平方根是除 0 之外的任何数字，就没必要再执行测试了。因此，ZeroAndNegativeNos 测试只使用 ASSERT_EQ，而 PositiveNos 测试使用 EXPECT_EQ，来报告存在多少个测试用例是平方根函数失败而不终止测试的情况。

运行第一个测试

既然已经创建了第一个基本测试，现在就该运行它了。清单 3 是运行测试的主例程。

清单 3. 运行平方根测试

#include "gtest/gtest.h"

TEST(SquareRootTest, PositiveNos) {

EXPECT_EQ (18.0, square-root (324.0));

EXPECT_EQ (25.4, square-root (645.16));

EXPECT_EQ (50.3321, square-root (2533.310224));

}

TEST (SquareRootTest, ZeroAndNegativeNos) {

ASSERT_EQ (0.0, square-root (0.0));

ASSERT_EQ (-1, square-root (-22.0));

}

int main(int argc, char **argv) {

::testing::InitGoogleTest(&argc, argv);

return RUN_ALL_TESTS();

}

顾名思义，::testing::InitGoogleTest 方法的作用就是对框架进行初始化，必须在调用 RUN_ALL_TESTS 之前调用它。在代码中只能调用 RUN_ALL_TESTS 一次，因为多次调用会与框架的一些高级特性冲突，不支持这种做法。注意，RUN_ALL_TESTS 自动地探测并运行用 TEST 宏定义的所有测试。在默认情况下，结果输出到标准输出。清单 4 给出输出。

清单 4. 运行平方根测试的输出

Running main() from user_main.cpp

[==========] Running 2 tests from 1 test case.

[----------] Global test environment set-up.

[----------] 2 tests from SquareRootTest

[ RUN ] SquareRootTest.PositiveNos

..\user_sqrt.cpp(6862): error: Value of: sqrt (2533.310224)

Actual: 50.332

Expected: 50.3321

[ FAILED ] SquareRootTest.PositiveNos (9 ms)

[ RUN ] SquareRootTest.ZeroAndNegativeNos

[ OK ] SquareRootTest.ZeroAndNegativeNos (0 ms)

[----------] 2 tests from SquareRootTest (0 ms total)

[----------] Global test environment tear-down

[==========] 2 tests from 1 test case ran. (10 ms total)

[ PASSED ] 1 test.

[ FAILED ] 1 test, listed below:

[ FAILED ] SquareRootTest.PositiveNos

1 FAILED TEST

Google C++ Testing Framework 的选项

在 清单 3 中，InitGoogleTest 函数接受测试基础设施的参数。本节讨论可以通过测试框架的参数实现的一些功能。

通过在命令行上传递 --gtest_output="xml:report.xml"，可以把输出转储为 XML 格式。当然，可以把 report.xml 替换为您喜欢的任何文件名。

某些测试有时候会失败，但是在大多数时候会顺利通过。这是与内存损坏相关的问题的典型特点。如果多次运行测试，就能够提高发现失败的可能性。如果在命令行上传递 --gtest_repeat=2 --gtest_break_on_failure，就重复运行相同的测试两次。如果测试失败，会自动调用调试器。

并不需要每次都运行所有测试，尤其是在修改的代码只影响某几个模块的情况下。为了支持运行一部分测试，Google 提供 --gtest_filter=<test string>。test string 的格式是由冒号 (:) 分隔的一系列通配符模式。例如，--gtest_filter=* 运行所有测试，而 --gtest_filter=SquareRoot* 只运行 SquareRootTest 测试。如果希望只运行 SquareRootTest 中的正数单元测试，应该使用 --gtest_filter=SquareRootTest.*-SquareRootTest.Zero*。注意，SquareRootTest.* 表示属于 SquareRootTest 的所有测试，而 -SquareRootTest.Zero* 表示不运行名称以 Zero 开头的测试。

清单 5 中的示例用 gtest_output、gtest_repeat 和 gtest_filter 选项运行 SquareRootTest。

清单 5. 用 gtest_output、gtest_repeat 和 gtest_filter 选项运行 SquareRootTest

[arpan@tintin] ./test_executable --gtest_output="xml:report.xml" --gtest_repeat=2 --

gtest_filter=SquareRootTest.*-SquareRootTest.Zero*

Repeating all tests (iteration 1) . . .

Note: Google Test filter = SquareRootTest.*-SquareRootTest.Z*

[==========] Running 1 test from 1 test case.

[----------] Global test environment set-up.

[----------] 1 test from SquareRootTest

[ RUN ] SquareRootTest.PositiveNos

..\user_sqrt.cpp (6854): error: Value of: sqrt (2533.310224)

Actual: 50.332

Expected: 50.3321

[ FAILED ] SquareRootTest.PositiveNos (2 ms)

[----------] 1 test from SquareRootTest (2 ms total)

[----------] Global test environment tear-down

[==========] 1 test from 1 test case ran. (20 ms total)

[ PASSED ] 0 tests.

[ FAILED ] 1 test, listed below:

[ FAILED ] SquareRootTest.PositiveNos

1 FAILED TEST

Repeating all tests (iteration 2) . . .

Note: Google Test filter = SquareRootTest.*-SquareRootTest.Z*

[==========] Running 1 test from 1 test case.

[----------] Global test environment set-up.

[----------] 1 test from SquareRootTest

[ RUN ] SquareRootTest.PositiveNos

..\user_sqrt.cpp (6854): error: Value of: sqrt (2533.310224)

Actual: 50.332

Expected: 50.3321

[ FAILED ] SquareRootTest.PositiveNos (2 ms)

[----------] 1 test from SquareRootTest (2 ms total)

[----------] Global test environment tear-down

[==========] 1 test from 1 test case ran. (20 ms total)

[ PASSED ] 0 tests.

[ FAILED ] 1 test, listed below:

[ FAILED ] SquareRootTest.PositiveNos

1 FAILED TEST

临时禁用测试

可以临时禁用测试吗？可以，只需在逻辑测试名或单元测试名前面加上 DISABLE_ 前缀，它就不会执行了。清单 6 演示如何禁用 清单 2 中的 PositiveNos 测试。

清单 6. 临时禁用测试

#include "gtest/gtest.h"

TEST (DISABLE_SquareRootTest, PositiveNos) {

EXPECT_EQ (18.0, square-root (324.0));

EXPECT_EQ (25.4, square-root (645.16));

EXPECT_EQ (50.3321, square-root (2533.310224));

}

OR

TEST (SquareRootTest, DISABLE_PositiveNos) {

EXPECT_EQ (18.0, square-root (324.0));

EXPECT_EQ (25.4, square-root (645.16));

EXPECT_EQ (50.3321, square-root (2533.310224));

}

注意，如果禁用了任何测试，Google 框架会在测试执行结束时输出警告消息，见 清单 7。

清单 7. Google 警告用户在框架中有禁用的测试

1 FAILED TEST

YOU HAVE 1 DISABLED TEST

如果希望继续运行禁用的测试，那么在命令行上传递 -gtest_also_run_disabled_tests 选项。清单 8 给出运行 DISABLE_PositiveNos 测试时的输出。

清单 8. Google 允许运行已经禁用的测试

[----------] 1 test from DISABLED_SquareRootTest

[ RUN ] DISABLED_SquareRootTest.PositiveNos

..\user_sqrt.cpp(6854): error: Value of: square-root (2533.310224)

Actual: 50.332

Expected: 50.3321

[ FAILED ] DISABLED_SquareRootTest.PositiveNos (2 ms)

[----------] 1 test from DISABLED_SquareRootTest (2 ms total)

[ FAILED ] 1 tests, listed below:

[ FAILED ] SquareRootTest. PositiveNos

断言

Google 测试框架提供一整套预定义的断言。断言分为两类 — 名称以 ASSERT_ 开头的断言和名称以 EXPECT_ 开头的断言。如果一个断言失败，ASSERT_* 断言会终止程序执行，而 EXPECT_* 断言继续运行。当断言失败时，这两者都输出文件名、行号和可定制的消息。比较简单的断言包括 ASSERT_TRUE (condition) 和 ASSERT_NE (val1, val2)。前者期望条件总是成立，而后者期望两个值不匹配。这些断言也适用于用户定义的类型，但是必须覆盖相应的比较操作符（==、!=、<= 等等）。

浮点数比较

Google 提供 清单 9 所示的宏以支持浮点数比较。

清单 9. 用于浮点数比较的宏

ASSERT_FLOAT_EQ (expected, actual)

ASSERT_DOUBLE_EQ (expected, actual)

ASSERT_NEAR (expected, actual, absolute_range)

EXPECT_FLOAT_EQ (expected, actual)

EXPECT_DOUBLE_EQ (expected, actual)

EXPECT_NEAR (expected, actual, absolute_range)

为什么需要用单独的宏进行浮点数比较？使用 ASSERT_EQ 不行吗？使用 ASSERT_EQ 和相关的宏可能可以，也可能不行，但是使用专门用于浮点数比较的宏更好。通常，不同的中央处理单元 (CPU) 和操作环境以不同的方式存储浮点数，简单地比较期望值和实际值是无效的。例如，ASSERT_FLOAT_EQ (2.00001, 2.000011) 会顺利通过 — 如果直到小数点后四位都匹配，Google 就不会抛出错误。如果需要更精确的比较，应该使用 ASSERT_NEAR (2.00001, 2.000011, 0.0000001)，就会得到 清单 10 所示的错误。

清单 10. ASSERT_NEAR 产生的错误消息

Math.cc(68): error: The difference between 2.00001 and 2.000011 is 1e-006, which exceeds

0.0000001, where

2.00001 evaluates to 2.00001,

2.000011 evaluates to 2.00001, and

0.0000001 evaluates to 1e-007.

死亡测试

Google C++ Testing Framework 有一类有趣的断言（ASSERT_DEATH、ASSERT_EXIT 等），它们称为死亡断言。使用这种断言检查在例程的输入错误的情况下是否发出正确的错误消息，或者例程是否退出并返回正确的退出码。例如，在 清单 3 中，当执行 square-root (-22.0) 时应该产生错误消息，程序退出，返回状态应该是 -1 而不是 -1.0。清单 11 使用 ASSERT_EXIT 检查是否是这样。

清单 11. 使用 Google 框架运行死亡测试

#include "gtest/gtest.h"

double square-root (double num) {

if (num < 0.0) {

std::cerr << "Error: Negative Input\n";

exit(-1);

}

// Code for 0 and +ve numbers follow…

}

TEST (SquareRootTest, ZeroAndNegativeNos) {

ASSERT_EQ (0.0, square-root (0.0));

ASSERT_EXIT (square-root (-22.0), ::testing::ExitedWithCode(-1), "Error:

Negative Input");

}

int main(int argc, char **argv) {

::testing::InitGoogleTest(&argc, argv);

return RUN_ALL_TESTS();

}

ASSERT_EXIT 检查函数是否退出并返回正确的退出码（即 exit 或 _exit 例程的参数），对引号中的字符串和函数发送到标准错误的字符串进行比较。注意，错误消息必须发送到 std::cerr 而不是 std::cout。清单 12 给出 ASSERT_DEATH 和 ASSERT_EXIT 的原型。

清单 12. 死亡断言的原型

ASSERT_DEATH(statement, expected_message)

ASSERT_EXIT(statement, predicate, expected_message)

Google 提供预定义的谓词 ::testing::ExitedWithCode(exit_code)。只有在程序退出且退出码与谓词中的 exit_code 相同的情况下，这个谓词的结果才是 true。ASSERT_DEATH 比 ASSERT_EXIT 简单；它只检查标准错误中的错误消息是否是用户期望的消息。

理解测试装备

在执行单元测试之前，通常要执行一些定制的初始化。例如，如果希望度量测试的时间/内存占用量，就需要放置一些测试专用代码以度量这些值。这就是装备的用途 — 它们帮助完成这种定制的测试初始化。清单 13 给出一个装备类的示例。

清单 13. 测试装备类

class myTestFixture1: public ::testing::test {

public:

myTestFixture1( ) {

// initialization code here

}

void SetUp( ) {

// code here will execute just before the test ensues

}

void TearDown( ) {

// code here will be called just after the test completes

// ok to through exceptions from here if need be

}

~myTestFixture1( ) {

// cleanup any pending stuff, but no exceptions allowed

}

// put in any custom data members that you need

};

这个装备类派生自 gtest.h 中声明的 ::testing::test 类。清单 14 是使用这个装备类的示例。注意，它使用 TEST_F 宏而不是 TEST。

清单 14. 装备的使用示例

TEST_F (myTestFixture1, UnitTest1) {

….

}

TEST_F (myTestFixture1, UnitTest2) {

….

}

在使用装备时，要注意以下几点：

可以在构造函数或 SetUp 方法中执行初始化或分配资源。由用户选择具体方式。

可以在 TearDown 或析构函数例程中释放资源。但是，如果需要异常处理，那么只能在 TearDown 代码中进行，因为从析构函数中抛出异常会导致不确定的结果。

在以后的版本中，Google 断言宏可能会在平台上抛出异常。因此，为了便于维护，最好在 TearDown 代码中使用断言宏。

并不跨多个测试使用同一个测试装备。对于每个新的单元测试，框架创建一个新的测试装备。在 清单 14 中，由于要创建两个 myFixture1 对象，所以两次调用 SetUp 例程（请注意使用正确的拼写）。

结束语

本文仅仅触及了 Google C++ Testing Framework 的皮毛。可以从 Google 网站获得关于这个框架的详细信息。对于高级开发人员，我建议阅读 Boost 单元测试框架和 CppUnit 等开放回归框架方面的其他文章。更多信息参见 参考资料。

关于作者

Arpan Sen 是致力于电子设计自动化行业的软件开发首席工程师。他使用各种 UNIX 版本（包括 Solaris、SunOS、HP-UX、IRIX，以及 Linux 和 Microsoft Windows）已经多年。他热衷于各种软件性能优化技术、图论和并行计算。Arpan 获得了软件系统硕士学位。

最近读了《卓有成效的程序员》，感觉收获颇大。这是一本写给程序员的难得的好书。书中大都是一些浅显的道理，但作者将这些东西加以收集、归纳、总结，并最终成书。作者为了收集各种提高效率的工具和方法，东奔西走，可谓费了一番苦心。

我觉得此书第一部分总结的一些法则非常好，我提取了一下：

法则： 

1.加速法则

    关注本质，而非形式

    一个应用程序列表的有用程度与它的长度成反比 

    程序员的很多时间都浪费在找东西上 

    华而不实的东西中看不中用

    键盘输入总比导航快

    首选键盘而非鼠标

    地址栏是Windows资源管理器界面中最高效的部分

    花点时间来学习你手边的所有隐藏的快捷键

    环境切换会消耗时间

    成批复制粘贴要比反复多次复制粘贴快

    忘记历史就意味着你得再输入一遍

    嵌入图形化工具的命令提示符让你鱼与熊掌兼得

    在上下文中学习IDE快捷键，而不要去背长长的列表

    当你第二次输入一个复杂结构时，将它做成模板

    如果要对多行文本做同样的操作，就应该找出其中的模式，并把它记录为一个宏

    不要总是重复输入相同的命令

    每天花一点点时间来使每一天都更高效 

2.专注法则

    精力越集中，思维越缜密

    排除干扰：隔离策略，关掉不需要的提示，创造安静时间  

    草堆越大，从中找到一根针就越难

    不要问文件树，要搜索

    使用多显示器

    虚拟桌面可以让原本杂乱无章的一大堆窗口变得整洁 

3.自动化法则

    不要重新发明轮子

    用Selenium浏览网页

    不要浪费时间动手去做可以被自动化的事情

    用Windows Power Shell替代批处理文件

    驯服Subversion命令行

    以创造性的方式解决问题，有助于在将来解决类似的问题

    是否应该自动化的关键在于投资回报率和缓解风险

    研究性的工作应该放在时间盒里做

    别给牦牛剪毛 

4.规范性法则

    对于任何你不自己去构建的东西，只在版本控制中保存一份副本

    使用标准的构建服务器

    通过复制粘贴来复用是邪恶的，不论你复制粘贴的是什么

    利用虚拟平台使项目依赖标准化

    不要让对象 - 关系映射工具（O/R映射器）违反规范原则 

    通过扩展。开放类（open class），或者部分类（partial class） 来为生成的代码增加行为

    始终保持代码和数据结构的同步

    过时的文档比没有文档更糟，因为它会主动误导你

    任何需要费劲创造的东西，都让它的创造者欲罢不能

    白板 + 数码相机强过任何CASE工具

    尽量生成所有技术文档

    重复是软件开发中最大的阻力 

工具：

书中，还提到了大量的提高效率的工具，都是非常不错的。相信很多人都有自己的一个列表，下面是我电脑中必不可少的几款软件：

    1. FireFox 及其各类插件

    2. Launchy启动加速器

    3. Total Commander

    4. ClipX多重剪切板

    5. EmEditor文本编辑器 

    6. Vistual Studio的VA插件

    7. Search And Replace

    8. Everything

    9. Miranda IM

    10. .... 

感触： 

1. 愤怒的猴子 

在书中的第二部分，提到了很多实践相关的内容。让我感触最深的是“愤怒的猴子”的故事：

“早在20世纪60年代（那时候科学家们可以做任何疯狂的事情），行为科学家们进行了一项实验。他们把五只猴子和一架活梯放在一间屋子里，并在天花板上挂了一串香蕉。这些猴子很快就想到它们可以爬上梯子去吃香蕉，但每当它们靠近活梯的时候，科学家们就用冰水浸满整个屋子。我想你能猜到会发生什么：一群愤怒的猴子。很快，再没有一只猴子会去靠近那个梯子了。

之后，科学家们将其中一只猴子替换成另一只没有忍受过冰水折磨的新猴子。这只新猴子所做的第一件事就是直奔那架梯子，但当它这么做时其他所有猴子都痛打它。它不明白为什么，但很快就学乖了：不要去靠近那架梯子。科学家们逐渐将最初的那些猴子都替换成新猴子，直到这群猴子中谁都没有被水浸泡过，然而它们还是会去攻击任何靠近梯子的猴子。

这说明了什么？软件项目中许多惯例之所以存在，就因为”我们一直是那样做的“。换句话说，是因为愤怒的猴子。”

我们小组在制定C++相关的代码规范时就遇到过无数类似的问题。比如，在制定变量的命名规范时，我们针对是否采用匈牙利命名法争论了很久。有的人认为， 几乎以前看到的所有C++代码都采用了匈牙利命名法，甚至，微软定义的所有API都使用了此类命名法。刚开始，我也是有同样的疑惑。

后来，我们经过仔细分析C++匈牙利命名法由来，渐渐感觉我们就是那些愤怒的猴子，盲目跟从前人的方式，缺乏打破传统的勇气。C++有着其特殊的历史原因，很多标准一直沉淀下来并很少改变。我们再看看后来新生的那些编程语言，C#, Python…… 都抛弃了匈牙利命名法，同时再看看现在C++前沿的C++ 0x以及现在出版的一些书中，也渐渐放弃了对匈牙利命名法的使用。因为类型的意义在对象模型中越来越弱化。因此，最后我们放弃了匈牙利命名法这个老古董。 

2. 敏捷开发

这本书带有强烈的ThoughtWorks色彩，敏捷的思想贯穿全书，包括测试驱动设计，白板，结对编程。这也让我对敏捷产生了更加强烈的兴趣。 其中有一段测试驱动开发TDD的一段故事：

“记得第一次和一些已经习惯于单元测试的开发人员一起动手开始修改代码时，我也是非常紧张，因为大量的修改往往会破坏很多东西，但他们看起来丝毫没有犹豫。逐渐地，我也放下心来，因为我慢慢地认识到：有了测试的保证，完全可以放心大胆地去修改代码。” 

3. 有趣的故事 

书中还有一些有趣的故事，比如作者的一个朋友在和别人结对编程时，为了养成同伴使用快捷键的习惯，每当同伴未使用快捷键时，他都会要求将操作撤销，然后要求使用快捷键再重复操作3次。然后，在其凶狠的眼神中，同伴很快掌握了快捷键。 

总结：

这本书很薄，蕴藏的道理却不少，相信每个读过它的人都会从中收获。读过之后，我们不应该局限于书中提到的某些小技巧， 或是书中某一个细节，毕竟，提供效率的方法有很多很多，法则也有很多很多，一本书很难将其穷举完。我们应该从书中吸取其思想，并在实际工作和学习中不断总结，做一个真正的“卓有成效的程序员”！

玩转Google开源C++单元测试框架Google Test系列(gtest)(总)

刚接触单元测试时，我实在是搞不懂这种测试到底有多大的意义，无非都是一些简单的ASSERT，但近年积累一些经验教训之后我才发现，单元测试这玩意儿真的是一种保证程序质量的强有力手段。

为什么这样说？举个最典型的例子，无论是开发新功能还是维护老程序，都不可避免的要反复修改某些代码，那该怎么保证修改的代码不会引入新的问题？如果你说你用人品担保，那我服了。我们应该需要一种可靠的手段来保证修改一个BUG不会引入两个三个BUG，或者不会让之前正确的功能出错，甚至是不会引入之前已经修改过的其它BUG。测试无疑是一种很好的手段，在没掌握其它更好的方法之前，很多人喜欢用人工测试，即编译 – 运行 – 输入典型值 – 看程序运行结果 – 如果出错 – 修改后再编译……从长远来看，这种测试方法的缺点很明显：1、耗时耗力，每次修改代码后都需要人工重复测试所有的典型情况；2、容易出错、漏测，人脑太复杂，你很难记得几个月前的那个BUG到底是什么情况，因此没法测试，久而久之，N久前的那个BUG可能又神不知鬼不觉的重现了。相比之下，单元测试的优点就凸显出来了，把需要测试的典型情况编写为测试代码，然后编译运行即可完成自动化的测试，当发现BUG后，把它添加到测试用例，不仅可以提高测试覆盖率，还能保证以后不会再次引入同样的BUG，有了足够的单元测试（覆盖率），你就可以理直气壮的说代码没问题！当然引入单元测试会在前期花费不少的时间来编写测试代码，但相应的也会大大减少后期的维护工作，最主要的是能可靠的提高程序的质量，所以是值得的，甚至是必要的。（如果你编译过开源的Google Chromium浏览器，你会发现测试代码就占了不少，光是编译测试代码就得花很长的时间）

除了上面说的优点外，单元测试还有一些其它的好处，比如帮你理清设计。一些人反对单元测试就是因为说我们的应用太复杂了，没法做单元测试。其实不一定是应用复杂，而有可能是设计得有问题，导致了没有可测试性。比如有些人喜欢在CXXXDialog里编写所有的功能实现，要测试这样的代码，必须得创建出Dialog，可能还需要点击，这显然没法做单元测试，但如果把Dialog和业务逻辑分开设计，那至少业务逻辑是可测试的（暂不讨论UI的测试）。因此要做单元测试，就得设计好各个接口，保证某个接口只完成单一的功能，没有过多的耦合依赖。

前面只是泛泛而谈了一些单元测试的皮毛，鼓吹了一些优点，有兴趣的自己找更详细的资料看吧。另推荐一个Google的开源C++测试框架googletest。