单体测试简单的讲就是软件开发人员把开发完了单个画面或页面（web开发）提交给独立的测试人员进行的测试的过程。由于单体测试与其单体关联性不大甚至没有关联，所以会有不少人认为单体测试分量不重，太简单，从概念上讲单体测试确实简单，但是单体测试是以后系统测试的基础，如果单体测试不过关没有发现并曝漏出问题，那么对于整个系统来说将会存在很大的隐患和风险。

单体测试的目的是发现软件设计人员在设计单体时错误和漏洞，以及开发人员的Bug和漏洞。不同的公司，不同的项目都具有自己的测试规范和要求，并且以文档的形式记录在案，单体测试人员应该严格按照测试规范和要求进行测试。但是，在实际的测试中，即使测试人员拿着具体的测试要求往往好多基本问题仍然没有发现，那么原因何在呢？不是他的测试方法不对，也不是测试时间不充分，而是测试人员不够严谨和仔细。软件测试是一件很辛苦的工作，有些项目会专门配有测试团队，有些可能是因为项目规模不大或者团队人员不足而没有专门的测试人员，开发人员之间相互进行单体测试。这时候可能是相互之间由于个人关系存在私心,导致测试结果不理想不能达到预期的要求，因为大多数软件开发公司都会将测试出来的Bug记录在案，在项目结束时要统计分析，甚至年终时评定年终奖作为重要的指标。

因此如果条件允许尽可能建立独立的测试团队，实在没有这样的资源，那么对测试人员必须有严格的要求，至少做到以下几点： 单体测试时测试人员首先要根据测试式样书看逐项检查开发者是否实现；其次要按照开发式样书的要求测试开发人员所有功能和需求是否全部实现；最后要提交测试结果报告书，开发人员修改后再测试。项目管理者要对测试结果进行抽查，如果发现Bug没有测试出来的原因是测试人员不够认真，这时要建立相应的处罚机制，比如说这个Bug不仅要记在开发人员身上，同时也要记在对应的测试人员身上。

单体测试时需要注意几点：1、建立测试计划2、测试结果文档化 3、测试数据规范化 4、修改及时性。

为Objective-C代码创建测试用例

为C++代码创建测试用例

往工程中加入单体测试的第一步是创建一个新的目标，用于连编和运行相应的测试代码。在Xcode中，您可以创建类型为“单体测试程序包（Unit Test Bundle）”的连编目标。这种目标在连编时会对您的测试代码进行编译，并通过一个外壳脚本来运行该代码。在测试完成后，Xcode控制台会将所有失败的测试点报告为错误。

在配置测试目标的时候，您需要决定目标的工作方式。Xcode带有的单体测试程序包可以以两种方式集成到您的执行程序中。一种是将测试目标配置为一个单独的实体，您可以独立地连编和运行主执行程序；另一种是在目标中加入依赖关系，使目标在每次连编时自动地连编您的执行程序，并进行测试。

单体测试-比较依赖于执行程序的目标和独立的目标

在建立测试代码的时候，您需要决定测试目标是依赖于主执行程序，还是与执行程序相独立。这两种技术各有各的优

目标的建立比较简单，只在希望的时候运行。

必须手工运行，可能使用得不频繁。

测试的自动运行比较容易。允许开发者独立连编主执行程序。

目标的建立要求一些额外的步骤。不能使用零连接。

如果您正在写的是一个Objective-C的程序，配置一个依赖于主执行程序的目标需要的额外步骤最少。然而，如果是一个C或者C++程序，则需要更多的工作，当然，这些工作也比较直接。

您需要做的一个重要事情是决定执行测试的频繁程度。定期执行测试可以得到各个连编的错误报告。如果工程需要定期进行连编，则这种方式可以比较容易地跟踪导致问题的代码。

另外一个需要做的决定是在每个连编周期中希望进行哪些测试。如果您有几千个测试用例，则可能希望只在特定的检查点处执行测试，比如将修改提交到代码库之后的时刻，而不是每个连编都进行测试。将测试组合的名称作为命令行参数传递给定制的执行程序，就可以指定您希望运行的测试用例了。更多的信息请参见“运行测试代码”部分。

无论是依赖于主执行程序的目标，还是独立的目标，其初始的配置过程都是一样的：

打开Xcode工程。

选择工程＞新建目标（Project ＞ New Target）菜单，显示新建目标（New Target）助手窗口。

单体测试-选择您期望的目标类型

如果您正在写的是一个Objective-C程序，则选择Cocoa ＞ 单体测试程序包（Cocoa ＞ Unit Test Bundle）目标。

如果您正在写的是一个C/C++程序，则选择Carbon ＞ 单体测试程序包（Carbon ＞ Unit Test Bundle）目标。这种目标不必使用Carbon库。

指定目标的名称，并点击完成（Finish）键。

在目标被创建时，其初始状态是一个独立的目标。如果您需要的就是独立的目标，则可以将代码和测试用例直接加入到目标中，并开始连编。如果您需要的是依赖于主执行程序的目标，那么反过来，必须进行下面的配置：

必须使您的目标依赖于主执行程序的目标（请参见“使目标依赖于主执行程序”部分）。

如果您的程序是用C或者C++写的，则必须在应用程序中加入代码，来对测试进行初始化（请参见“在C和C++工程中执行依赖于主执行程序的测试”部分）。对于基于Objective-C的测试，则不需要初始化。

使目标依赖于主执行程序

为了使您的目标依赖于主执行程序，必须在Xcode工程中为其建立依赖关系：

选择您的单体测试程序包目标。

打开该目标的查看器。

选择一般（General）页签。

点击位于窗口底部的+按键。

在出现的对话框中，选择代表主执行程序的目标，并点击增加目标（Add Target）键。

如果您正在连编的是一个应用程序，则还必须在程序包装载器（Bundle Loader）和测试宿主（Test Host） 这两个连编设置中指定应用程序的执行程序。举例来说，如果要设置MyApp.app的执行程序路径，需要执行如下的步骤：

选择单体测试程序包目标。

打开该工程的查看器。

选择连编（Build）页签。

选择连接（Linking）集合。

将程序包装载器设置赋值为$(BUILT_PRODUCTS_DIR)/MyApp.app/Contents/MacOS/MyApp。

选择单体测试（Unit Testing）集合。

将测试宿主设置赋值为$(BUILT_PRODUCTS_DIR)/MyApp.app/Contents/MacOS/MyApp。由于它们使用的是同样的值，所以也可以将这个设置赋值为$(BUNDLE_LOADER)。

请注意：如果您正在测试的是一个框架或者共享库，则不必为测试宿主设置指定值。

缺省情况下，程序包装载器和测试宿主设置是没有赋值的。对程序包装载器进行设置告诉连接器在连接时将指定的执行程序处理为额外的框架（这种处理方式有助于在连编测试目标的时候避免产生应用程序类的引用无法识别的错误）。对测试宿主进行设置则告诉RunUnitTests脚本（在最后的连编阶段执行）启动指定的应用程序，并将您的测试程序包注入到该程序中。

在测试目标配置完成之后，应该将它设置为活动目标，并往目标中加入包含测试用例代码的源文件。在下次编译的时候，Xcode会考察测试目标的依赖性，并首先连编您的主执行程序，之后再连编测试目标，并在完成之后运行您的测试用例。这个过程确保主程序被连编，且对应的测试用例被运行。

请注意：对于依赖于主执行程序的测试目标，只需要把将测试代码的源文件加入到工程中就可以了。不要将主执行程序的任何源文件加入到测试目标中。在测试代码运行的时候，测试目标程序包会被注入到主执行程序中，并可以访问测试需要的任何源代码。

在C和C++工程中执行依赖于主执行程序的测试

如果您在C++工程中使用依赖于主执行程序的测试目标，则需要在测试工程中加入一些额外的代码，才能执行测试。由于Objective-C的动态本质，依赖于主执行程序的测试目标产生的程序包可以被自动地注入到执行程序中。而在C++中，这是不可能的。相反，您必须显式告诉CPlusTest框架什么时候可以安全地运行测试代码。在Carbon应用程序中，实现这个目标的方法之一是建立一个定时器，使其处理函数在应用程序启动完成后马上启动测试组件，而且具有处理事件的能力。当定时器触发时，相应的处理函数就可以运行已经注册完成了的测试组件，并记录测试过程的输出（有关如何注册测试用例的信息，请参见“为C++代码创建测试用例”部分）。

列表1显示了Carbon程序中用于启动定时器的类定义。我们需要在初始化时构造该类的一个实例（参见列表2），目的是安装一个定时器。当定时器最终被触发时，程序就会调用firedTimerBridge和firedTimer方法来执行实际的测试。

单体测试（白盒测试）阶段，不但要保证，程序能跑到和跑通所有对应本机能的开发的代码，同时也必须保证代码的质量（机上レビュー），是否符合规约，是否已经是最好，这个非常重要。遇到bug，及时进行确认和相关开发人员修正。单体测试完了，并将遇到bug进行修正完了，确认单体测试完毕，随后进入结合测试阶段。

结合测试(SI测试或称为黑盒测试)，不是重复的单体测试。单体测试的时候，我们是站在理解业务的开发人员的角度上看的，能debug着进行测试，一旦进入结合测试阶段，我们就是站在客户观点上来对应测试了（除非非得debug解决不了的测试点，特殊！）。（与开发没有任何关联的人，可以进入这个阶段的测试。缘由是，已经不是程序的想法，而是业务的想法了。）结合测试的任务量应该至少是coding与单体测试量之和，应该最大限度做到不重复不漏。

测试的既包括单体的内容，也得把所有的异常通过case跑出来（在业务业面上正确显示出来），该错，不该错，能输入，不能输入，多次longin不入进行lock，多人同时更新一个表，排他测试（比如，测试数据库连接时候，可以断网测试一下，看是否是出现我们理想的提示信息）等等。（式样书的做成阶段）在做测试票与测试点或者测试case的时候，原则上大约1K的开发内容，要出六十到七十左右的测试点，多了或许就重复了，少了是不够用的或者不全面的。各个机能（画面）之间比较巧妙的连接，各个测试票之间的连接巧安排，包括联动，所有的CHECK，做尽量少的重复，尽量大的不漏。在真正进行结合测试的时候，可能会对应BUG修正的，这个时候，一定一定要控制好版本（管理）。对库（服务器代码所在）的进出严格控制。

每天的进度统计与把握对项目的顺利进行也非常重要。如果遇到式样变更，一定要有专门的式样变更管理，控制好限度，如果超过限度，要进行相应的协商，以免对纳品日期（工期）和品质产生大的影响。