我发现我的许多计算科学编程都具有标准测试框架未涵盖的测试要求:
计算时间测试
- 为了确保算法不会变慢。我可以做一些类似的事情,
assureSmallerEqual(RuntimeWrapper(algorithm),53)
但是我希望在我从事算法工作时可以不断降低53秒的阈值,例如assureSmallerEqual(RuntimeWrapper(algorithm),'previousbest+noisetolerance')
- 为了确保算法不会变慢。我可以做一些类似的事情,
性能测试
- 为了确保以前找到与解析解近似良好的算法,仍然可以找到至少与之相当或更好的解。同样,这可以通过标准集成测试来模拟,但是我希望随着算法变得越来越好,公差会不断缩小。考虑替换
assureAlmostEqual(foo(),1,places=3)
为assureAlmostEqual(foo(),1,places='previousbest')
- 为了确保以前找到与解析解近似良好的算法,仍然可以找到至少与之相当或更好的解。同样,这可以通过标准集成测试来模拟,但是我希望随着算法变得越来越好,公差会不断缩小。考虑替换
物理需求测试
- 为了确保算法不会突然需要更多的内存/硬盘空间。与1.非常相似。
抽象需求测试
- 要确保对二次逼近很好的算法不会突然需要三次逼近,或者对时间步长为0.1很好的算法不会突然需要0.01的稳定性。同样,这些可以通过标准集成测试来模拟,但是目标是记住达到某个目标的最小需求参数,因此这将需要大量的手动更新。例如,如果
foo(10)
以前没有例外,我希望该框架确保foo(10)
仍然有效,并尝试foo(9)
现在是否有效(在这种情况下,所有将来的测试都将确保foo(9)
仍然有效)。
- 要确保对二次逼近很好的算法不会突然需要三次逼近,或者对时间步长为0.1很好的算法不会突然需要0.01的稳定性。同样,这些可以通过标准集成测试来模拟,但是目标是记住达到某个目标的最小需求参数,因此这将需要大量的手动更新。例如,如果
有人可能会争辩说,我所要求的并不是从单元/集成测试的角度描述测试,因为例如可以增加运行时间来换取其他改进,这是可以接受的。
但是实际上,我知道如果我具有上述测试功能,那将节省很多调试时间,因为在95%的情况下,由于引入的错误导致要求和性能出现了问题。确实,我知道这样一个事实,即如果严格地应用了上述测试,可以避免使用外部数值软件库发现的许多错误(经过大量时间检查自己的代码)。
聚苯乙烯
命名类似的问题/programming/34982863/framework-for-regression-testing-of-numerical-code并非重复,因为它描述了使用标准回归测试框架更容易实现的功能。
问题“ 用于单元测试和测试驱动的开发的策略”要求使用策略,而不是帮助实现这些策略的框架(答案中所要求/提供的策略与我在此描述的内容不同)。