我在IEEE发表的一篇研究论文中读到这篇论文，该论文称图书馆不经常改变，因此不需要进行大量的回归测试。我希望有人验证声明。 此外，它说Randoop早期是在图书馆开发和评估的。有人可以验证吗？
答案 0 :(得分：0)
[论文]说，Randoop早期是在图书馆开发和评估的。
这不仅适用于Randoop，还适用于其他测试生成工具，如ARTOO，Check'n'Crash，EvoSuite，GRT，QuickCheck等。
该论文是“扩大自动化测试生成：自动为程序生成可维护的回归单元测试”（ASE 2011）。它的问题陈述是测试生成工具经常应用于库，它比程序更容易处理。它的贡献是展示如何将测试生成工具（Randoop）扩展到程序。
将Randoop应用于图书馆的早期论文的一个例子是“反馈导向的随机测试生成”（ICSE 2007）。它报告发现了许多重要的，以前未知的错误。
我在IEEE发表的一篇研究论文中读到这篇论文，该论文表示图书馆不经常改变，因此不需要进行大量的回归测试。
论文不说库“不需要太多的回归测试”。它实际上说，“图书馆不太可能需要回归测试套件。图书馆很少改变，图书馆可能已经有一些测试。”重点是Randoop工具生成测试，对于没有测试的组件，更需要这样的工具。作为一般规则，图书馆通常已经有一个人工编写的测试套件。该库也由使用它的每个程序执行。相比之下，许多程序存在没有测试套件，或者其测试套件省略了程序行为的大部分内容。这些组件更需要测试生成。
这是第5点附近的6个理由列表的结尾，以激励将Randoop扩展到程序。评论在这种情况下是有意义的，但不是在脱离背景或错误引用时。该列表以
开头Randoop最初的目标是检测数据结构库库中的现有错误，例如JDK
java.util。相反，我们希望扩展Randoop，以便为复杂的工业软件系统生成可维护的回归测试。数据结构库往往更容易让工具以多种方式处理。 ...
回到您的一个问题，每个软件组件 - 无论是程序还是库 - 都需要在更改时运行回归测试套件。运行测试可以确保您的更改没有破坏其功能。如果您从未更改过组件，那么您不需要回归测试套件。
有些图书馆永远不会改变（因为政策，或者因为没有必要改变它们），而其他图书馆也在不断更新。