Testing 图书馆多久更换一次？库和程序一样需要回归测试吗？

我在IEEE上发表的一篇研究论文中读到了这篇文章，文章说库不会经常改变，因此不需要太多的回归测试。我想找人核实一下这句话。 此外，它还说Randoop是较早开发的，并在库上进行了评估。有人能证实吗

[论文]说Randoop是较早开发的，并在图书馆上进行了评估

这在很大程度上不仅适用于Randoop，也适用于其他测试生成工具，如ARTOO、Check'n'Crash、EvoSuite、GRT、QuickCheck等

---

论文名为“扩展自动测试生成：为程序自动生成可维护的回归单元测试”（ASE 2011）。它的问题在于，测试生成工具经常被应用到库中，这比程序更容易处理。它的贡献是展示如何将测试生成工具（Randoop）扩展到程序

将Randoop应用于库的早期论文的一个例子是“反馈导向的随机测试生成”（ICSE 2007）。它报告发现了几十个重要的、以前未知的错误

我在IEEE上发表的一篇研究论文中读到了这篇文章，文章说库不会经常改变，因此不需要太多的回归测试

这篇论文并没有说图书馆“不需要太多的回归测试”。它实际上说，“库不太可能需要回归测试套件。库很少改变，库可能已经有了一些测试。”主要的一点是Randoop工具生成测试，没有测试的组件更需要这样的工具。一般来说，库通常已经有了一个人工编写的测试套件。库也由使用它的每个程序执行。相比之下，存在的许多程序没有测试套件，或者其测试套件忽略了程序行为的大部分。这类组件更需要测试生成

这是激励将Randoop扩展到程序的6个原因列表末尾的第5点。该评论在该上下文中是有意义的，但在断章取义或被错误引用时是没有意义的。列表以

Randoop最初的目标是检测数据结构库中现有的bug，比如JDK的

java.util

。相反，我们希望扩展Randoop，为复杂的工业软件系统生成可维护的回归测试

数据结构库往往更易于工具以多种方式处理

回到您的一个问题，每个软件组件——无论是程序还是库——都需要在发生变化时运行回归测试套件。运行测试可以让您确信您的更改没有破坏其功能。如果您从不更改组件，那么您就不需要为其提供回归测试套件

---

有些库永远不会更改（因为策略，或者因为不需要更改它们），而其他库则在不断更新。

这篇文章是怎么说的？扩大自动测试生成：自动为程序生成可维护的回归单元测试