与编译器的集成

　　与编译器的集成需要注意两点。一点是允许测试框架（Test harness）进行自动编译和链接，不需要用户去设置编译器所需的选项。另一点是允许测试工具兼容编译器所使用的任何特定的扩展语言。尤其是交叉编译器，它们提供非C / C + +语言标准的扩展是很常见的。一些工具使用宏定义方法（＃）将这些扩展定义为空字符串。这种拙劣的方法是非常不好的，因为它改变了编译器产生的目标代码。例如，考虑下面的带有GCC属性的全局外部变量：

　　如果你的候选工具在定义全局变量MyGlobal时不能维持其属性不变，那么因为内存边界对齐不一样，代码在测试时和实际部署时将会表现得不一样。

　　要点

　　> 工具是否能自动编译和链接测试框架？

　　> 该工具是否能兼容并实施编译器特定的语言扩展？

　　> 编译器有什么类型的接口（IDE，CLI等）？

　　> 工具是否提供接口用来从你的开发环境中导入项目设置，还是必须手工导入？

　　> 如果该工具导入了项目设置，该导入功能是通用的还是局限于特定的编译器或编译器系列的？

　　> 测试工具是否和调试器集成以允许你调试测试用例？

　　支持嵌入式目标测试

　　在这一节中，我们将使用术语“工具链”来表示整个交叉开发环境，包括交叉编译器、调试接口（模拟器）、目标板和实时操作系统（RTOS）。重要的是要考虑候选工具是否能很完善地与你的工具链集成，并且要清楚如果你迁移到一个不同的工具链上，该工具中需要改变些什么。

　　此外，了解目标环境集成的自动化水平和健壮性也很重要。正如前面提到的：如果某个厂商说：“我们支持所有的编译器和目标板。”他们的意思是说：“你需要自己去完成让我们的工具能在你环境中运行的所有工作。”

　　理想情况下，你选择的工具将允许你只需点击一个“按钮”即可完成“测试执行”所涉及的所有复杂工作，包括将测试用例下载到目标环境，并将测试结果捕获到主机平台，，从而不需要用户再做任何特殊的操作。

　　嵌入式目标测试的另一个难题是硬件的可用性。通常情况下，硬件与软件是并行开发的，或者硬件的可用性是有限的。一个关键的特征是能否先在一个本地的环境开始测试，后期再过渡到实际的硬件环境。理想情况下，工具的使用是不受硬件条件限制的。

　　要点

　　> 能支持我的工具链吗？如果不能，那它能有办法被支持吗？“支持”是什么意思呢？

　　> 我能在主机系统上建立测试，然后将它们用于目标环境的测试？

　　> 测试框架是怎样下载到目标上的？

　　> 测试结果是如何被获取并返回到主机的？