核心 Perl 附带的 cpan 工具包括一个 -l 选项，它指示它提供已安装模块的列表。例如，我系统列表中的最后 10 项：
$ cpan -l 2>/dev/null |tail -10
Test2::Event::Encoding 1.302073
Test2::Event::Bail 1.302073
Test2::Event::Exception 1.302073
Test2::Event::Subtest 1.302073
Test2::Event::Skip 1.302073
Test2::Event::Info 1.302073
Test2::Event::Diag 1.302073
Test2::Event::TAP::Version 1.302073
JSON::PP 2.27400_02
JSON::PP::Boolean undef
如此处所示，您将获得一个模块列表和版本号。有时该工具在 META 中找不到版本，因此将返回 undef 以获取版本号。 CPAN 作者应该注意这些错误，因为它们使那些希望在不编译模块本身的情况下识别版本的工具变得更加困难。
获得模块和版本号后，您可以使用cpanm 工具（由App::cpanm 提供）及其--test-only 选项来拉取特定版本的模块并对其进行测试。您可以像这样请求特定版本：
cpanm Some::Module@0.9990
（仅下拉目标模块的 0.9990 版本）。
事情变得棘手的地方如下：Perl 附带了一堆模块，其中一些还通过 CPAN 接收更新。 cpan -l 工具将列出所有已安装的模块，包括 Perl 附带的模块。
此外，列出的一些模块只是更大分布的一部分。
另一个对您有用的工具是corelist，它自 5.8.9 以来就与 Perl 捆绑在一起。如果你运行这个：
corelist File::Temp
你会得到：“File::Temp was first released with perl v5.6.1”
如果你这样做：
corelist JSON
你会得到：“JSON was not in CORE (or so I think)”
因此，确定您在列表中查看的模块是否是 Perl 附带的模块非常简单。使用您认为合适的信息。
您必须解决的另一件事是如何处理共享依赖项。如果您测试的第一件事是 Moose 升级，那么您将占用一半的 CPAN（这是夸大其词），这会弄脏您测试其他模块的环境。为了减轻这种影响，您有几个选择。一种是利用App::perlbrew 及其lib 选项来设置一次性图书馆空间。这样您就可以在perlbrew lib 和perlbrew use 指定的目标中安装模块及其依赖项，然后在完成后将其丢弃以继续进行下一个库进行测试。
但是，可能有一个更好的解决方案，我对这里的文档不太熟悉：CPAN 烟雾测试人员使用的工具链。如果您希望采用此策略，请参阅CPAN::Testers。冒烟测试人员已经制定了相对轻量级的方法来以自动化的方式下拉和测试模块及其依赖项。
最后，您会遇到的另一个问题是 CPAN 作者决定了哪些版本的模块存在于 CPAN 上，哪些版本会被删除。几年前，CPAN 作者被鼓励通过删除旧版本来保持其 CPAN 存储库的清洁。我不知道是否仍然鼓励这种做法，但这确实意味着您不能指望仍然存在的特定版本号。为了解决这个问题，您可能应该为您在给定时刻安装的所有版本维护自己的 tarball 存储库。 CPAN 模块框架Pinto 有助于保持模块的版本、固定一些不更新，以及其他有用的技巧。