目前我的C ++项目有一堆单元测试，但我还没有（还）测试代码覆盖率。我正在使用-O3优化标志编译测试以暴露潜在的微妙错误，但似乎我想使用gcov等工具收集覆盖率信息，必须禁用任何优化标记。我应该两次构建测试（一个使用-O3，另一个没有）？这个问题通常是如何处理的？
答案 0 :(得分：4)
通常会有多种测试来确保软件的质量，以及编译器选项的不同标准。
通常，构建系统提供两种或更多种构建选择，例如：
使用断言调试：-O0（无优化）
发布：“更高优化”（-O2，-Os或-O3取决于您项目的“最佳”），无需断言。这通常是您向客户提供代码的模式。
有时会出现“Release + Asserts”，这样您仍然可以在运行时看到代码中的正确性。
以下是我认为可以将测试归类的一些类别：
功能正确性（又名“阳性测试”）。这是您检查“代码在正常情况下正常工作”的地方。运行Debug和Release。
否定测试。检查错误条件是否正常 - 传递应该给出错误的垃圾值（“不存在的文件”应该给出E_NO_SUCH_FILE）。典型的是调试和发布。
压力测试 - 运行严酷的测试，检查软件在长时间运行，大量线程等情况下是否正常运行等。通常是调试模式 - 可能两者兼而有之。
覆盖。运行一组测试以确保“覆盖所有路径”（通常具有“未覆盖”程度，例如应覆盖95％的功能和85％的分支 - 因为某些条件可能极难实现无需手动检测代码 - 只有在磁盘完全填满或OS无法创建新进程时才会出现错误。通常编译为Debug。
容错测试。一种形式的“否定测试”，其中为内存分配和类似插入“模拟”功能，可以按顺序或随机模拟故障，以发现未检测到错误且代码失败的情况作为后续结果较早的错误，而不是在正确的位置产生正确的错误。同样，通常使用Debug运行 - 但也可能值得在Release中运行。
性能测试。在哪里测量程序的性能 - 生成的每秒帧数，编译器中的每秒行数或文件下载系统中每小时的千兆字节数等。这应该按照发布进行编译，因为“未优化”代码中的运行性能是几乎总是毫无意义。
对于复杂的软件产品，您经常必须在“运行所有内容”和“花费时间”之间做出妥协 - 例如，在调试和发布模式下运行ALL 4000功能测试可能需要12个小时，仅运行调试模式7个小时，所以最好。这种妥协是通常的“工程决策” - “在一个理想的世界中，你会做到这一点，但在现实世界中，我们必须妥协，这就是为什么我认为这种测试配置是正确的”。
许多测试系统正在对源代码的每次更改进行轻量级测试[在“我觉得这工作”来自工程师他/她之后]，每晚更重的测试，以及例如周末的更多测试。这样可以在运行所有测试所需的时间与一名工程师进行小幅更改所需的时间之间进行折衷。