unit-testing - 我怎么能说测试（软件）是正确的？

我正在与一家制造硬件/固件的大公司进行技术面试。

对于他们的一个产品，他们成立了一个团队来测试固件，因为固件是不可升级的（你不想运送你知道的 3000 万个有 bug 的设备）。

所以他们的客户给了他们“规范”，固件团队开发固件，最后这个团队在 C#、CANoe 和一些开发板的帮助下开始测试它。

因此，例如，他们将固件刷入电路板，然后验证电路板（固件）的行为是否符合规范（例如，它必须返回特定消息，或者它必须在 Y 之后执行 X 等......通常的单元测试东西）。

这些“单元测试”或“集成测试”实际上是软件本身（用 C# 编写），因此可能存在 BUGS（例如 C 内存泄漏）或“误报”。

例如，这是一个错误的测试：

public bool TestEngineOffAfterTime(int timeToWait) {
  return true;
}

形式上是正确的，可以编译，但它是错误的。

我得到的问题是：你怎么能说测试是正确的？

我离开了面试，但不知道答案。

请问社区可以帮忙吗？我自己找不到答案。

标签： unit-testingtestingqa

这听起来像是一个技巧问题或所谓的“开放式”问题。

我会说一般来说，没有办法 100% 确保测试在现实的开发环境中是正确的。你只能减少那些误报的机会。您可以进行参数测试并生成大量测试用例来探索被测例程的输入空间。您需要有良好的测试实践来减少测试中的人为错误。您还需要有良好的开发实践（如 Block X 所述）

但是，我认为没有一种方法可以正式“确保”测试是正确的。是的，您可以使用形式验证来确保算法有效。要确保一段代码正常工作，要困难得多。显然，由于测试是一个程序，它不能决定“不可判定的问题”，从黑盒测试的角度来看，甚至不可能决定一个输入输出空间有限的例程。（如果例程不是无状态的怎么办？）