是否有用于数字软件开发的测试框架


10

我发现我的许多计算科学编程都具有标准测试框架未涵盖的测试要求:

  1. 计算时间测试

    • 为了确保算法不会变慢。我可以做一些类似的事情, assureSmallerEqual(RuntimeWrapper(algorithm),53)但是我希望在我从事算法工作时可以不断降低53秒的阈值,例如assureSmallerEqual(RuntimeWrapper(algorithm),'previousbest+noisetolerance')
  2. 性能测试

    • 为了确保以前找到与解析解近似良好的算法,仍然可以找到至少与之相当或更好的解。同样,这可以通过标准集成测试来模拟,但是我希望随着算法变得越来越好,公差会不断缩小。考虑替换assureAlmostEqual(foo(),1,places=3)assureAlmostEqual(foo(),1,places='previousbest')
  3. 物理需求测试

    • 为了确保算法不会突然需要更多的内存/硬盘空间。与1.非常相似。
  4. 抽象需求测试

    • 要确保对二次逼近很好的算法不会突然需要三次逼近,或者对时间步长为0.1很好的算法不会突然需要0.01的稳定性。同样,这些可以通过标准集成测试来模拟,但是目标是记住达到某个目标的最小需求参数,因此这将需要大量的手动更新。例如,如果foo(10)以前没有例外,我希望该框架确保foo(10)仍然有效,并尝试foo(9)现在是否有效(在这种情况下,所有将来的测试都将确保foo(9)仍然有效)。

有人可能会争辩说,我所要求的并不是从单元/集成测试的角度描述测试,因为例如可以增加运行时间来换取其他改进,这是可以接受的。
但是实际上,我知道如果我具有上述测试功能,那将节省很多调试时间,因为在95%的情况下,由于引入的错误导致要求和性能出现了问题。确实,我知道这样一个事实,即如果严格地应用了上述测试,可以避免使用外部数值软件库发现的许多错误(经过大量时间检查自己的代码)。

聚苯乙烯

命名类似的问题/programming/34982863/framework-for-regression-testing-of-numerical-code并非重复,因为它描述了使用标准回归测试框架更容易实现的功能。

问题“ 用于单元测试和测试驱动的开发的策略”要求使用策略,而不是帮助实现这些策略的框架(答案中所要求/提供的策略与我在此描述的内容不同)。


1
数字软件是用于仿真还是用于分析实验数据?
马修·冈瑟

1
@mathewgunther数值分析/数值代数。没有数据分析
Bananach

1
我知道许多大型的模拟公司都使用自己创建的框架。基本上在python中。您需要具有由python脚本启动的测试用例,并写出一些结果。之后,可以将结果与某种参考进行比较并输出报告。该测试可以每天,每周或每月自动进行。不知道是否存在某种通用框架,因为模拟软件在实施中是否特别?
vydesaster

Answers:


4

1.在我看来,这种类型的测试定义不明确,因为其测试条件与您在开发中进行测试的特定机器有关。测试的要点之一是,在笔记本电脑上运行测试会告诉我所设置的代码或环境是否有问题。53秒是特定于您的开发计算机的,如果测试计算机承受其他工作负载或用户的负载,则运行时间也会增加。我不希望测试框架能够解决这个问题:“功能可以在53秒内在输入上运行”并不是一个很好的正确性规范。

2.我认为出于相同的原因,从软件测试的角度来看这是模棱两可和不可取的1,您失去了软件测试的通过或失败的理由。

3.这很普遍,让我描述一个解决方案。这并不是测试框架的全部工作,但是您可以使用Unix SE问题限制单个Linux进程的内存使用中所述的单独工具。首先尝试使用的标准工具是中的ulimit命令bash,该命令可让您运行进程并确保进程在尝试分配过多内存时崩溃。因此,如果您runtests使用内存限制运行脚本,它将崩溃,并且测试框架应能够将其作为常规测试失败进行处理。

4.大多数测试框架不认为单元测试这种方法在所有。运行测试套件(例如,在将代码提交到母版之前或在部署之前),结果为是或否,指示其是否起作用。测试框架并不认为要跟踪功能进度(例如,跟踪功能进度)是他们工作的一部分,而这通常不是测试。您在这里要做的是编写两个测试expect_succeeds(foo(10)); expect_fails(foo(9))。每次都运行两个测试,并且成功和预期的失败通过。当您实现foo(9)并成功执行后,expects-failure测试现在会失败,因此您需要重写expect_succeeds(foo(9)),这是所有框架的绝对标准功能。但是,您必须明确说明预期的行为,因为否则,它将与软件测试的基本思想背道而驰。

所有这一切都有另一种方法。您试图使测试框架在跟踪代码的迭代进度方面做更多的工作,但是测试框架在代码快照上可以正常工作,并且有望工作,给出通过或失败的答案。这可能是更容易采取一种算法,创建一个测试套件,因为它是那么做的完整副本,叫,有检查,只是继续工作。现在,(a)测试框架将可以轻松比较和AAABperforms_better(foo_A(), foo_B())BAB(b)不再有任何将代码与以前的代码进行比较的感觉,现在所有代码和测试都是不可变的和明确的。从本质上讲,这与处理系统重写的方式类似。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.