当我使用ctest接口cmake（add_test(...)）并运行make target make test时，我的几个测试都失败了。当我直接在二进制构建文件夹的命令行上运行每个测试时，它们都能工作。
我可以用什么来调试它？
要调试，可以先直接运行ctest而不是make test。
然后可以将-V选项添加到ctest中以获得详细输出。
cmake开发人员的第三个巧妙技巧是让ctest启动xtermshell。所以添加
add_test(run_xterm xterm)
在CMakeLists.txt文件的末尾。然后运行make test，它将打开一个xterm。然后，看看是否可以通过从xterm运行测试来复制失败的测试。如果它确实失败了，那么请检查您的环境（即从xterm运行env > xterm.env，然后从正常会话再次运行env > regular.env并比较输出）。
我发现我的测试是通过连线来寻找在二进制cmake输出文件夹（即键入make test的文件夹）的顶部的相对路径上传递的外部文件。但是，当您通过ctest运行测试时，当前工作目录是该特定子目录的二进制文件夹，因此测试失败。
换句话说：
这起到了的作用
test/mytest
但这不起作用
cd test; ./mytest
我不得不修复单元测试，以使用它所需的配置文件的绝对路径，而不是像../../../testvector/foo.txt这样的路径。
ctest和googletest的问题是，它假设为每个测试用例运行一个命令，而在一个测试可执行文件中可能会运行许多不同的测试用例。因此，当您将add_test与Google Test可执行文件一起使用时，无论失败的测试用例的实际数量是1还是1000，CTest都会报告一次失败。
既然你说孤立地运行测试用例可以让它们通过，我首先怀疑的是你的测试在某种程度上是耦合的。您可以通过使用--gtest_shuffle随机化测试执行顺序来快速检查这一点，并查看是否会出现相同的失败。
我认为调试失败测试用例的最佳方法不是使用CTest，而是使用命令行选项运行测试可执行文件，以过滤正在运行的实际测试用例。首先，我只运行第一个失败的测试，然后在整个测试套件运行之前立即运行测试。
调试测试用例的其他有用工具可以是SCOPED_TRACE和使用附加信息扩展断言消息。