软件测试基本技术第二版-R包在系统中的测试和使用情况的比较情况

文|苏荨墨

编辑|苏荨墨

前言

编写科学软件已经从早期开拓者的工作发展为一系列计算机专业人员、计算研究人员和自学成才的个人。

计算机科学教育学科在多年前通过计算机协会 (ACM) 的推荐标准化，多年来在广度和深度上都有所发展。

软件工程是计算机科学中的一门学科，寻求开发和使用系统模型和可靠的技术来生产高质量的软件。

这些软件工程关注点从理论和原则扩展到对学科外的人最明显的开发实践”。

随着计算研究人员、统计学家和类似专业人员的成熟，他们需要通过采用软件工程原理来提高他们的技能。

R包在系统中的测试

为了估计 R 软件中常见的测试水平，我们分析了通过 CRAN 提供的所有 R 包。

尽管在过去进行了类似的分析软件测试基本技术第二版，但由于 CRAN 整体的快速变化，重新评估是必要的。

在 Nolan 工作的时候，CRAN 包含 10,084 个包；它现在包含 13,509 个。

此外，Nolan 的分析有一些缺点，在本次分析中已经解决了这些缺点：也想分析其他测试框架的使用情况；并非所有测试框架和 R 包都将其测试代码存储在名为“tests”的目录中。

尽管解决了分析 R 代码以使用测试最佳实践的一些缺点，但我们选择的分析域确实有一些局限性。

并非所有的研究软件都是用 R 编写的；对于那些确实使用 R 的人来说，并不是所有的软件开发都会在 CRAN 上发布一个包。

虽然其他软件语言也有测试工具，但还需要进行额外的研究来评估这些语言的测试水平，以了解它与该分析的比较情况。

尽管已注意确定 R 的标准测试用例和实践，但可以通过使用核心功能，此外，开发人员在开发软件时可能有自己的测试用例，但没有将它们包含在 CRAN 上提供的包中。

单元测试可以被视为可执行文档，是传达如何正确使用软件的关键方法，涉及软件的已发表研究不像 CRAN 包那样容易访问和评估测试代码的使用。

虽然一些期刊有存储和共享代码的标准化方法，但许多期刊将代码的存储和共享留给了个人作者，从而创建了一个代码分析需要大量手动工作的环境。

如图所示图1，对存在非空测试目录的评估表明，测试 R 包的趋势越来越大，更新包中有 44% 有一些测试。

图1

如图所示图 2，随着时间的推移，对测试框架的依赖在数量和占所有包的百分比上都在增加。

有 16 个包列出了对多个测试框架的依赖项testthat，因此直方图中显示的包总数包括 16 个被重复计算的包，所以生成的数据如图 2所示。

图2

系统的软件分析需求

对于优化相关的依赖项，为了帮助视觉理解，仅显示在给定年份具有 15 个或更多依赖包的那些包。

自动分析软件以获得优化证据与前面提到的与自动检测软件测试技术和工具的使用相关的困难类似。

软件优化的最佳证据是提交历史、时间功能单元测试和程序包错误报告。

虽然所有 R 包都有可用的源代码，但并非所有包都有可用的开发历史或单元测试。

此外，对列出的优化包之一的明确依赖可能意味着包创建者建议将其与他们的包一起使用，而不是他们实际上在他们的包中使用它。

尽管存在这些缺点，但估计 src 目录的存在或特定包的使用表明对包进行了一些优化工作。

如图所示图 3，对非空 src 目录存在的评估表明，按计数，在 R 包中使用编译代码的趋势有所增加。

图3

然而，当以所有 R 包的百分比来评估时，变化在过去几年中只是略有增加。

如图所示图 3，在 2018 年，Rcpp 是最常见的优化相关依赖项，其次是parallel和foreach。

在所示的整个期间内，这些相同的软件包在上次更新的软件包中最受欢迎。

有 699 个包列出了对多个优化框架的依赖项（407 个有 2 个依赖项，220 w/3、53 w/4、16 w/5、2 w/6、1 w/7），所以包的总数直方图中显示的包括一些被重复计算的。

提高质量和性能的建议

每当将软件作为研究项目的一部分编写时，都应仔细考虑如何验证软件是否执行了所需的功能并产生了所需的输出。

与基准科学一样，软件在实施过程中经常会因为小问题甚至大问题而产生意想不到的结果。

软件测试是任何软件开发生命周期中公认的组成部分，也应该是研究软件的关键组成部分。

即使在旨在与他人共享和由他人使用的 R 软件包中，大多数 R 软件包（67-73%，取决于指标）也没有随软件包一起提供的测试。

存在用于软件测试和验证以及如何将软件与软件开发生命周期集成的各种方法和策略。

一些常见的测试策略是无策略、临时测试 ( Agruss & Johnson, 2000 )、测试驱动开发 (TDD)。

还有一些常见的项目方法论，其中测试适合项目生命周期；两个常见的例子是瀑布式项目管理方法，其中测试是在特定时间点发生的主要阶段，以及敏捷项目管理方法，其中有许多小的迭代，包括测试。

但提出了三个关键概念：何时开始测试、测试什么以及如何测试。

近年来流行的运动之一是先开发测试，然后实现代码以满足所需的功能，这种策略称为 TDD。

虽然 TDD 策略在提高软件工程界对测试的关注度方面做了很多工作，但一些人发现它并不适用于所有开发风格。

报告说它不会增加与其他测试方法相比，开发人员生产力、减少整体测试工作量，也没有提高代码质量。

一种更符合基于理论的软件开发周期和研究软件的灵活性的方法是在实现需求或功能后创建测试。

由于在单个时间点开发软件功能的综合测试可能会成为一个巨大的负担，因此更务实的方法是在开发新功能和设计测试以验证新功能之间交替进行。

与敏捷软件开发策略类似，构建测试周期可以实现经过验证的功能的快速循环，有助于为软件生命周期的其他阶段提供输入。

在理想的世界中，任何开发的软件都将伴随着 100% 的测试覆盖率，以验证所有代码行、功能的所有方面、所有输入以及与其他软件的所有交互。

然而，由于研究压力，有时间构建一个完美的测试套件是不现实的。

简约应用将在不增加测试负担的情况下大大提高整体软件质量，微软等大公司将传统的科学方法应用到 bug 研究中。

发现帕累托原理符合现实：20% 的 bug 导致 80% 的问题；此外，Zipfian 分布也可能适用：1% 的错误会导致 50% 的问题。

要将 Pareto 原则应用于测试，请花一些时间进行思想实验以确定以下问题的答案：该软件最重要的功能是什么？如果这个软件坏了，最有可能的坏结果是什么？对于计算密集型组件——这需要多长时间才能运行？

一旦知道了这些问题的答案，开发人员就应该花时间设计测试来验证关键特性软件测试基本技术第二版，避免重大负面影响，并确保软件充分运行。

“软件优化”部分介绍了优化和性能建议，测试设计过程的一部分应该包括如何“测试”不仅仅是代码。

非代码测试的一些特定方面包括与导师或同事一起验证方法和实施选择。

作为如何应用上述测试原则的简要示例，我们提供了一些有关 pccc 包开发过程中遵循的测试步骤的信息。

编写的第一个测试是手动开发的，并随着开发的进行手动运行，这种形式的关键测试用例是包含在自动化测试中的理想候选者。

第一个测试采用已知数据集，运行我们的流程来确定有多少输入行具有复杂的慢性，然后报告发现的总百分比；然后将该结果与公布的值进行比较。

# read in HCUP KID 2009 Database

kid9cols

kid9core

fwf_positions(

start = kid9cols$start,

end = kid9cols$end,

col_names = tolower(kid9cols$name)),

col_types = paste(rep(“c”, nrow(kid9cols)),

collapse = “”))

# Output some summary information for manual inspection

table(kid9core$year)

dim(kid9core)

n_distinct(kid9core$recnum)

# Run process to identify complex chronic conditions

kid_ccc

ccc(kid9core[, c(2, 24:48, 74:77, 106:120)],

id = recnum,

dx_cols = vars(starts_with(“dx”), starts_with(“ecode”)),

pc_cols = vars(starts_with(“pr”)),

icdv = 09)

# Output results for manual inspection

kid_ccc

# Create summary statistics to compare to published values

dplyr::summarize_at(kid_ccc, vars(-recnum), sum)

%>% print.data.frame

dplyr::summarize_at(kid_ccc, vars(-recnum), mean)

%>% print.data.frame

对于该pccc包，有大量 ICD 代码和代码集模式，用于确定输入记录是否满足任何复杂的慢性病标准。

为了验证软件的正确运行，需要验证 ICD 代码分组是否正确并且相互排斥（视情况而定）。

作为pccc现有 SAS 和 Stata 代码的重新实现，我们需要验证之前开发和发布的软件应用程序中的代码是否相同并且是否按预期执行。

通过结合人工审查和自动比较代码，检查代码是否存在重复和重叠，任何处理输入验证或具有用于关键功能的大量内置值的软件都应遵循类似的数据验证过程。

作为配置测试的示例，这里是一些用于自动查找重复项和已包含在另一个代码中的代码的简短代码片段：

icds

unlist(lapply(icds, function(i) {

tmp

output

# add the matched element into the output

if(length(output) != 0)

output

output

}))

大多数编程语言都有大量的测试工具和框架可用于帮助开发人员进行软件测试。

由于编程语言之间常见的重复模式，大多数语言都有一个 SUni派生测试工具，通常称为“xUnit”测试框架，专注于验证单个代码单元以及必要的输入和输出满足期望的要求。

根据使用的软件语言，单元测试可能在类或函数过程级别。

一些常见的 xUnit 样式包R是RUnit和testthat，单元测试应该自动化并定期运行，以确保错误被快速发现和解决。

结语

对于 R，很容易将单元测试集成到包构建过程中，但其他方法（例如版本控制系统中的提交后挂钩）也很常见。

除了通常由软件开发人员编写的单元测试外，用户还应执行验收测试或高级功能测试，以验证软件是否满足要求。

由于验收测试的高级性和主观性，它们通常是手动执行的，可能不会遵循一系列有条理的步骤。

用户将如何实际使用软件的详细文档（称为用户故事）被转化为人们遵循的逐步测试，以验证软件是否按预期工作。

除了已经提到的基于工具的方法之外，还应该仔细检查其他更难测试的项目，例如算法和解决方案方法。

虽然自动化测试可以验证数学运算或其他逻辑步骤是否正确，但它们无法验证通过软件操作隐含的方法或假设是否正确。

这个级别的测试可以通过代码审查和设计审查会议与其他了解该领域或相关领域的人一起完成。