上篇文章《如何评估嵌入式软件测试工具？ -- 第一部分》介绍了当前一些自动化嵌入式测试工具的现状，本文将剖析和总结嵌入式测试工具，让各位总体上了解评估一个嵌入式测试工具时需要考察工具的哪些功能特性；
测试工具剖析
测试工具通常提供了各种各样的功能。对于不同的工具，厂商使用的名称是不同的，一些工具可能会缺失某些功能。作为一个公共的参考框架，我们为你评估的测试工具中可能存在的“模块” 选择了下面的名称：
嵌入式软件测试工具公共的参考框架
解析器（Parser） | 解析器模块让工具能够理解你的代码。它读取代码，并为代码创建一个中间表示（通常以树结构的形式）。基本上与编译器所做的相同。输出或”解析数据”通常被保存在一个中间语言（IL）文件中。 |
代码生成器 | 代码生成器模块采用“解析数据”来构建测试框架的源代码。 |
测试框架（Test harness） | 虽然测试框架不是工具中的专门部分;但在测试框架的体系结构中所作的测试会影响工具所有的其它功能。因此，评估工具时框架结构是非常重要的。 |
编译器 | 编译器模块允许测试工具调用编译器来编译和链接测试框架。 |
目标环境（Target） | 目标模块使测试可以在不同的运行时环境中轻松地运行，包括支持模拟器、仿真器、嵌入式调试器和商业RTOS。 |
测试编辑器 | 测试编辑器允许用户使用脚本语言或复杂的图形用户界面（GUI）为测试用例设置先决条件和预期值（通过/失败的标准） |
覆盖率 | 覆盖率模块使用户能获取执行每个测试所覆盖的代码部分的测试报告 |
报告 | 报告模块允许获取的各种数据被生成项目文档 |
命令行(CLI) | 命令行（CLI）使工具的使用进一步自动化，可以从脚本、makefile文件等来调用工具。 |
回归测试 | 回归测试模块允许针对一个应用程序的某个版本创建的测试用例在新版本中重新运行。 |
集成 | 与第三方工具的集成是一个充分利用你对测试工具的投资的有趣的方式。常见的集成有与配置管理工具、需求管理工具和静态分析工具的集成。 |
后面的部分将详细说明你应该如何评估这些候选工具中的每一个模块。
测试工具分类/自动化水平
由于所有工具不可能都包含上述所有的功能或模块，同时也因为不同的工具所提供的自动化水平有着很大的差异，因此我们对测试工具大致分为下面几类。你的候选测试工具将属于其中的一个类别。
测试工具分类/自动化水平
手工 | 手工”工具，通常创建一个空测试框架，并要求你手工编写执行测试用例所需的测试数据和逻辑。通常情况下，它们会提供一种脚本语言和/或一套库函数/方法，可以用来做一些常规的事情，比如测试断言，或创建格式化的测试报告文档。 |
半自动化 | “半自动化”工具可以把“手工”工具提供的一些自动功能加上图形界面，但仍然需要手工编写代码和/或脚本以测试更复杂的结构。此外，“半自动化”工具可能会缺少一些“自动化”工具具有的模块。仅仅内建支持在少数示例的嵌入式目标环境上部署。 |
自动化 | “自动化”工具，具有上一节中列出的每个功能区或模块的功能。这类工具将不需要手动编码，并支持所有语言结构，以及在各种不同的嵌入式目标环境上部署。 |
工具的微妙差异
除了比较工具的功能和自动化水平以外，评估和比较所使用的测试方法也是很重要的。例如，当你用一些工具创建一个测试项目时，除非你自己动手尝试去完成一些操作，否则这些工具仅仅将文件加载到它的IDE，而不会做任何创建测试框架或测试用例的工作。
这可能隐藏了工具的潜在缺陷，因此重要的是不仅要将你的代码加载到工具中，而且还要尝试为你正在测试的类中的每个方法建立一些简单的测试用例。工具是否会建立一个完整的测试框架？所有的桩函数（Stubs）都是自动创建的吗？你可以使用图形用户界面（GUI）来定义测试用例的参数和全局数据吗？或者如果你正在进行手工测试，你是否需要编写测试代码呢？
类似地，工具之间对嵌入式目标环境的支持也有很大的差异。如果一个厂商说：“我们支持所有的编译器和目标环境”，那你需要警惕了。这话的含义其实是说：“你需要自己去完成让我们的工具能在你环境中运行的所有工作”。
本章节完，下节将详细描述如何评估测试工具？敬请期待....
本文转载自：http://www.mytestlife.com/post/how-to-evaluate-embedded-software-test-tools-part2.html
