信号处理单元测试？

Question

我遇到类似的问题来到像这样的： Test driven development for signal processing libraries

问题背后的事实是，信号处理的输出是很难完全和定性定义。

所以注入输入>运行程序>验证输出方法并不适用于信号处理。

满足规范中的性能要求是否意味着没有错误？ 当然不是。那么如果它符合要求，为什么要麻烦？因为缺陷会咬人，有一天他们会。

最终，唯一可行的解​​决办法是比较已知良好等效的输出，通常是MATLAB版本或一些广泛使用的库。

Matlab有一个很好的库集合，它具有边界检查，内存管理和双精度，因此与matlab代码相比，暴露了指针超出边界，堆栈溢出以及评估整数精度的充分性，但它不回答这样的问题，如“如果matlab相当于做了什么错误呢？”

我只能对自己说：尝试编写matlab相当简单，所以它接近“这么简单显然没有错误”

在我的球队，我有程序员在各种技能水平的，我至少需要某种措施来控制/强制执行代码的质量。

自从上一篇文章已经两年多了。我在这方面有一些新的发展。

请作为从业者分享您的想法和观点。

Answer 1

GNU Radio是一个面向流的信号处理框架附带的信号处理算法的大型文库，大部分时间封装在块。

当然，我们做了很多的单元测试中，我们经常发现基于这些错误，回归或角的情况下，所以这是GNU Radio的发展过程中是至关重要的。我并不完全相信我会称之为TDD，但我认为这不是重点。

的一点是，当然信号处理可以是单元测试。为什么不应该呢？您可以指定输入，并且有预期的输出，特别是如果您将步骤封装在信号处理模块中。现在，虽然这不像那种第一课assert(square(2)==4)的单元测试那样容易，但作为信号处理算法的开发者，您必须非常清楚您应该做什么以及如何以数学方式验证它，通常可以编写测试用例。

现在，我可以理解你的观点：“我的测试用例变得非常复杂，它可能有它自己的错误”，但这只是表明你还没有将问题构造成足够小的子问题。正如你所注意到的，我喜欢引用GNU Radio，所以我们再来做一次：一个好的测试驱动开发过程将尝试尽可能多地产生可重用的，经过良好测试的模块。 经过充分测试的意味着他们的行为如此明确以至于您可以对其进行测试。 GNU Radio以“multiply”之类的简单块的形式或者像“schmidl & cox OFDM sync”之类的更复杂的块的形式来执行此操作。您首先验证您的简单模块，然后验证整个系统，在这种情况下，“我输入到我的OFDM调制器中的信息位是从我的OFDM调制器中传出来的。这适用于信号处理以及任何其他类型 - 它只是需要高度的理解，这往往是具有纯计算机科学背景的人在编写信号处理软件（信号处理人员另一方面，经常为找到CS专家熟知并易于解决的问题找到好的解决方案而苦苦挣扎）;我总是希望这个事实能鼓励人们写出更好的测试（并阅读更多的书籍））。

Answer 2

这里有两个问题值得讨论：

1. 设计分解。
2. 实际实施和支持

他们是密切相关的，但不同的方面在DSP应用解决TDD。

如果原则上分解滤波器设计以“增加块”是合理的，但实现所需的测试实际上是非常不切实际的。它相当于要求将字符串搜索分解为字符比较，或将其分解为移位测试和添加块。这可能是可能的，但是测试实际上是否提供了测试有意义的单位或暴露可能的算法或编码错误的机会是值得怀疑的。

一个有趣的实际测试可能需要检查瞬态和稳态滤波器响应，这可能是滤波器实现中的最小向量运算，它执行有意义的整体代码块，并允许测试更细微的行为 - 滤波例如噪音数字。实际的挑战是在单元测试的背景下提供矢量数据输入和输出。

通过扩展来查看需要大量数据或状态信息的PR问题的自适应结果成为一个类似但异构的问题。

我的临时答案是建立一个测试循环，驱动DSP并测试定义测试用例的文件。目前，它固有地脱机并且仅限于非本地hw。民间是否有其他替代方案可以使测试更接近目标。