我正在开发一个渲染引擎(一个很小的引擎啊哈(
我想写回归测试，以确保在添加新功能时不会引入bug。
若我开发了一个计算着色器，或者将数据从缓冲区传输到缓冲区的东西，测试很容易。我们填充第一个缓冲区，并在传输后检查第二个缓冲区是否有相应的数据。
然而，对于渲染来说，这似乎很困难。。。我最终得到了几个解决方案
- 根本没有测试
- 取一张屏幕截图，当测试开始时显示屏幕截图和渲染，并要求用户(测试人员(检查结果是否良好
- 取一张屏幕截图，当测试开始时，将渲染与屏幕截图进行比较
第一个解决方案…不是解决方案。第二个解决方案看起来不错，但我认为我们失去了自动的东西是令人难过的。。。
第三种解决方案似乎是最好的。然而，要想真正有效，就意味着一种算法，如果它在英伟达卡、AMD、英特尔或。。。必须产生完全相同的结果。
所以问题来了，我们能依靠屏幕截图和一点一点的比较来进行回归测试吗？还是取决于驾驶员和制造商？
Vulkan和OpenGL都不能保证不同实现之间的二进制结果相同。即使是同一张卡的驱动程序更新也会产生不同的结果。
对于这样的事情，你能做的最好的事情就是得到一个"；关闭"；达到预期结果。
老实说，硬件实现之间的固有差异是一个相对较小的问题，更大的问题是为逐点回归测试创建测试数据所需的时间。
正如您所说，测试套件的真正功能是在添加新功能或解决错误时快速检查回归。使用您的示例，如果您更改了实现缓冲区的方式，那么在需要时可以很容易地相应地修改单元测试，例如，缓冲区的内存类型可能发生了变化，为此重构单元测试是微不足道的。
将相同的方法应用于软件的视觉输出需要付出更多的努力，尤其是如果您进行的更改需要重新生成预期输出，即在单元测试中更改预期值比更改整个场景容易几个数量级或多个数量级。
即使对于大多数web开发人员来说，他们也不愿意尝试"测试"视觉效果并专注于功能，只是不值得维护测试。