测试方法

本章讨论了可供执行的各种测试策略，以便充分利用 Coco 工具。

覆盖率击中与计数

如果我们想要对应用程序设定非常严格的标准，以确保其质量尽可能高，仅仅执行其代码的一部分或只执行一次代码是不够的。

为了解决这个问题，Coco 工具提供了两种可能的途径

代码覆盖率计数：我们可以要求仪表化代码的每一部分至少执行一定次数。这可以通过向仪表化代码中添加计数每次执行的代码来实现。这可以通过使用《 CoverageScanner》的 --cs-on 命令行选项来完成。
自然地，设定这样的最低标准以及额外的账本本身，可能会使应用程序消耗更多的内存并且运行得稍微慢一些。这种方法的一个重要缺点是，源代码中的循环最终只有一个执行，计数很高，因此以这种方式计数并不总是有用的。
测试覆盖率计数：我们可以要求仪表化代码的每一部分至少被一定数量的测试项目执行。这避免了代码覆盖率计数在循环方面的缺点，因为我们通过为仪表化代码的每一部分设定最低的测试执行次数，使得循环、递归和只执行一次的指令具有同等的价值。

Coco 可以根据许多不同的测试策略进行适配，从早期开发中的单元测试到完整产品的验证（例如，验收测试）。《 CoverageBrowser》支持在测试的每个阶段合并代码覆盖率结果，因此提供了软件总体质量的精确概述。

白盒测试（又称清盒测试、玻璃盒测试或结构测试）使用系统的内部视角设计测试用例，基于内部结构。它需要编程技能来识别软件中的所有路径。测试者选择测试用例输入来考查代码路径并确定适当的输出。

使用 Coco 执行交互式白盒测试非常容易：一旦将应用编译为 CoverageScanner，测试工程师就可以执行它，每次执行后，他们可以将执行报告导入 CoverageBrowser 进行分析。

黑盒测试从测试对象的外部视角来推导测试用例。这些测试可以是功能性的或非功能性的，尽管通常是功能性的。测试设计者选择有效的和无效的输入并确定正确的输出。不对测试对象内部结构有认知。

黑盒测试假定测试工程师对应用程序内部没有了解——他们完全基于输入和相应预期的输出（无论是数据还是错误报告）进行工作。

对于此类测试，可以遵循与白盒测试相同的模式，但不向测试工程师提供由 CoverageScanner 生成的仪器数据库（.csmes 文件）。应用程序本身将生成执行报告，可以在测试周期之后进行分析。然而，这种方法有一个缺点，测试工程师无法管理自己的执行报告（例如，添加注释）。

Coco 提供了一个使黑盒测试成为可能而不对测试工程师产生不利影响的设施。 CoverageBrowser 工具可以生成一个不包含任何源代码或源代码浏览信息的仪器数据库（.csmes 文件）。这允许测试工程师管理测试列表并查看统计数据，但它不提供任何源级覆盖率信息。

单元测试 是一种通过测试单个源代码单元来确定其是否适合使用的路线。单元是应用程序中最小的可测试部分。在过程式编程中，单元可以是整个模块，但更常见的是单个函数或过程。在面向对象的编程中，单元通常是整个接口，如一个类，但也可以是单个方法。

CoverageScanner 采用其库支持保存由每个单元测试生成的代码覆盖率数据。

只要所有对象都 正确编译，就可以将单元测试的仪器数据库合并到真实应用程序的数据库中，并查看单元测试在主应用程序上的代码覆盖率。正确编译意味着源文件不会编译两次或者至少不会用不同的预处理器选项编译。

Coco 允许我们在执行报告中添加执行名称和状态注释。这不需要任何特定的库——信息可以通过在测试项目执行前后直接编辑执行报告来插入。这使得将报告集成到自动测试框架或用于测试执行脚本成为可能。有关更多信息，请参阅测试套件和 Coco。