上篇文章《如何评估嵌入式软件测试工具？ -- 第三部分 测试工具详细功能评估之一》详细描述在软件测试工具的评估过程当中你应该研究的一系列问题，限于篇幅原因，还有一些评估的要点比如：“代码覆盖率”、“回归测试”、“报告”、“与其他工具集成”、“测试工具其他不错的功能”、“真正的集成测试/多单元测试”、“动态状”、“库和应用程序级线程测试（系统测试）”、“敏捷测试和测试驱动开发（TDD）”、“与需求管理工具的双向集成”、“工具认证”等部分内容将在本章详细介绍。

　　代码覆盖率

　　大部分“半自动化”工具和所有的“自动化”的工具都内置了一些代码覆盖率分析功能，使你能看到测试用例所覆盖的那部分应用程序的指标。一些工具以表格形式展示这些信息，一些展示为流程图，还有一些以在源代码中添加标注的形式展示。表格用于汇总是很方便的，但如果你想实现100％的代码覆盖率，在源代码中标注才是最好的。这种形式通过对已覆盖、部分覆盖和未覆盖的结构标注不同的颜色，来展示最初的源代码文件。它使你可以轻松地看出要达到100％覆盖率所需要补充的测试用例。

　　了解插装（instrumentation）的影响也很重要。额外的源代码添加到你的应用程序中。有两方面需要考虑：一是目标代码的增加，还有就是运行时系统开销。重要的是要明白，你的应用程序是内存受限的还是实时受限的（或是两者）。这将有助于你了解哪个问题对你的应用程序是最重要的。

　　要点

　　> 每种类型的插装，代码增加的大小是多少？

　　> 每种类型的插装，运行时系统开销的增加是多少？

　　> 插装过程可以集成到你的编译系统（“make” system 或 “build”system）吗？

　　> 呈现给用户的覆盖率结果如何？是否有带标注的图形化的覆盖率浏览列表，或只是度量表？

　　> 从目标环境获得的覆盖率信息如何？过程灵活吗？数据能缓存到RAM中吗？

　　> 是否支持语句、分支（或判定）和修正条件/判定（MC / DC）覆盖？

　　> 能在一次执行中获取多种覆盖类型信息吗？

　　> 覆盖数据能跨多个测试环境进行共享吗（例如一些系统测试过程中获取的覆盖率信息，和从单元和集成测试中获取的覆盖率信息相结合）？

　　> 你可以使用覆盖率数据单步遍历测试执行过程，在不使用调试器的情况下观察通过你的应用程序的控制流程吗？

　　> 你可以在单个报告中获得执行所有测试用例的总的覆盖率吗？

　　> 工具符合DO-178B标准和FDA对医疗器械的“Intended use”标准吗？

　　回归测试

　　使用测试工具有两个基本的目的。首先是为了节省测试时间。如果你读到这里，我想你会同意这一点！其次是使创建的测试可作用于应用程序的整个生命周期。这意味着，建立测试所花费的时间和金钱产出的应该是可重用的和易于配置管理（版本管理）的测试用例，即使应用程序随时间有所改变也不例外。你的候选工具要评估的主要问题是需要“保存”哪些具体的内容，以便将来能运行相同的测试，以及如何控制测试的重运行。

　　要点

　　> 为了回归测试，需要对哪些文件做配置管理？

　　> 工具是否有一个完整的，文档化的命令行接口（CLI）？

　　> 这些文件是纯文本的还是二进制的？这会影响你使用diff工具来评估这些文件随时间的变化情况的效率。

　　> 必须要对工具生成的架构文件（harness）做配置管理吗？

　　> 能与配置管理工具的集成吗？

　　> 为一个单元创建一个测试用例，现在改变一个参数的名称，并重建你的测试环境。需要多长时间？复杂吗？

　　> 工具是否支持数据库技术和统计图表来分析测试执行和代码覆盖率随时间变化的趋势。

　　> 你是否可以用同一组测试用例自动测试多个不同版本的代码？

　　> 是否支持分布式测试，允许各部分测试用例在不同的物理机上运行，以加快测试速度？