41次发布

0.6.4 2024年8月20日
0.6.3 2024年7月23日
0.6.1 2024年6月28日
0.4.6 2024年3月19日
0.1.0-beta.42022年10月4日

#50 in 测试

Download history 134/week @ 2024-05-01 51/week @ 2024-05-08 5/week @ 2024-05-15 11/week @ 2024-05-22 310/week @ 2024-06-05 51/week @ 2024-06-12 167/week @ 2024-06-19 141/week @ 2024-06-26 138/week @ 2024-07-03 12/week @ 2024-07-10 116/week @ 2024-07-17 207/week @ 2024-07-24 44/week @ 2024-07-31 92/week @ 2024-08-14

459次每月下载

AGPL-3.0

1.5MB
7.5K SLoC

必要主义

运行移除语句和方法调用的测试,以帮助识别损坏的测试

必要主义目前支持Anchor (TS)、Foundry、Go、Hardhat (TS)和Rust。

关于必要主义的论文(《Test Harness Mutilation》)将在Mutation 2024上发表。( 论文幻灯片预印本)

内容

安装

系统要求

在您的系统上安装pkg-configsqlite3开发文件,例如,在Ubuntu上

sudo apt install pkg-config libsqlite3-dev

crates.io安装Necessist

cargo install necessist

github.com安装Necessist

cargo install --git https://github.com/trailofbits/necessist --branch release

概述

Necessist会迭代地从测试中移除语句和方法调用,然后运行它们。如果一个测试在移除语句或方法调用后仍然通过,这可能表明测试存在问题。或者更糟糕的是,它可能表明正在测试的代码存在问题。

示例

此示例来自rust-openssl。测试verify_untrusted_callback_override_ok检查失败的证书验证是否可以通过回调来覆盖。但如果回调从未被调用(例如,因为连接失败),测试仍然会通过。必要主义通过显示测试在调用set_verify_callback的情况下仍然通过,揭示了这一事实。

#[test]
fn verify_untrusted_callback_override_ok() {
    let server = Server::builder().build();

    let mut client = server.client();
    client
        .ctx()
        .set_verify_callback(SslVerifyMode::PEER, |_, x509| { //
            assert!(x509.current_cert().is_some());           // Test passes without this call
            true                                              // to `set_verify_callback`.
        });                                                   //

    client.connect();
}

在此发现之后,测试中添加了一个标志,以记录回调是否被调用。该标志必须被设置,才能使测试成功。

#[test]
fn verify_untrusted_callback_override_ok() {
    static CALLED_BACK: AtomicBool = AtomicBool::new(false);  // Added

    let server = Server::builder().build();

    let mut client = server.client();
    client
        .ctx()
        .set_verify_callback(SslVerifyMode::PEER, |_, x509| {
            CALLED_BACK.store(true, Ordering::SeqCst);        // Added
            assert!(x509.current_cert().is_some());
            true
        });

    client.connect();
    assert!(CALLED_BACK.load(Ordering::SeqCst));              // Added
}

与传统的突变测试比较

点击展开

传统的突变测试试图识别测试覆盖的差距,而Necessist试图识别现有测试中的缺陷

传统的突变测试工具(如universalmutator)会随机向源代码中注入故障,并查看代码的测试是否仍然通过。如果它们仍然通过,这可能意味着代码的测试不充分。

值得注意的是,传统的突变测试是关于发现测试集合中的缺陷,而不是单个测试的缺陷。也就是说,对于任何给定的测试,随机向代码中注入故障不太可能揭示该测试中的错误。这是不幸的,因为有些测试比其他测试更重要,例如,确保某些代码部分的正确性比其他部分更重要。

相比之下,Necessist通过迭代删除语句和方法调用的方法,确实针对单个测试,因此可以揭示单个测试中的错误。

当然,这两种方法可以揭示的问题集合有重叠,例如,未能找到注入的故障可能表明测试中存在错误。尽管如此,由于上述原因,我们认为这两种方法是对补充的,而不是相互竞争的。

可能的理论基础

点击展开

以下标准(*)几乎描述了Necessist旨在删除的语句

  • *)语句S最弱前件PS的后置条件Q具有相同的上下文(例如,作用域中的变量),并且P不意味着Q

*)试图捕捉的概念是:影响后续断言的语句。在本节中,我们将解释并说明这一选择。为了简洁起见,我们专注于语句,但本节的注释也适用于方法调用。

回忆两种谓词转换语义:最弱前件和最强后件。前者涉及在给定语句之后的后件成立的情况下,推理在语句之前可能成立的最弱前件。后者涉及在给定语句之前的前件成立的情况下,推理在语句之后可能成立的最强后件。一般来说,前者更常见(参见Aldrich 2013中的解释),这是我们在这里使用的方法。

从这一视角考虑一个测试。测试是一个没有输入或输出的函数。因此,确定测试是否通过的另一种方法如下。从True开始,迭代地通过测试的语句向后工作,计算每个语句的最弱前件。如果到达测试第一个语句的前件是True,则测试通过。如果前件是False,则测试失败。

现在,假设我们应用这个程序,并考虑一个违反(*)的语句S。我们认为删除S可能没有意义。

案例1:代码S向或从作用域中添加或删除变量(例如,S是一个声明),或者S更改了变量的类型。那么移除S可能会导致编译失败。(此外,由于S的前置条件和后置条件具有不同的上下文,因此不清楚如何比较它们。)

案例2S的前置条件比其后置条件更强(例如,S是一个断言)。那么S对其执行环境施加了约束。换句话说,S正在测试某些内容。因此,移除S可能会削弱测试的整体目的。

相反,考虑一个满足(*)的语句S。以下是移除S可能合理的原因。将S视为移动有效环境集,而不是对其施加约束。更准确地说,如果S的最弱前置条件P不蕴含Q,并且如果Q是可满足的,那么存在一个赋值给PQ的自由变量的赋值,该赋值同时满足PQ。如果这样的赋值来自S实际执行的每个环境,那么S的必要性就值得怀疑。

*)的主要用途在于帮助选择Necessist忽略的函数、宏和方法调用。Necessist默认忽略其中的一些。假设对于某个框架,我们正在考虑是否应该忽略某些函数foo。如果我们想象框架测试语言的谓词变换语义,我们可以问:如果语句Sfoo的调用,那么S会满足(*)吗?如果答案是“不”,那么Necessist很可能忽略foo

以Rust的clone方法为例。对clone的调用可能是多余的。然而,如果我们想象Rust的谓词变换语义,对clone的调用不太可能满足(*)。因此,Necessist不会尝试移除clone调用。

除了帮助选择Necessist忽略的函数等之外,(*)还有其他一些很好的后果。例如,测试中最后一条语句应被忽略的规则来自(*)。要理解这一点,请注意此类语句的后置条件Q始终是True。因此,如果该语句没有改变上下文,那么其最弱前置条件必然蕴含Q

尽管如此,(*)并不能完全捕捉Necessist实际上的事情。考虑像x -= 1;这样的语句。Necessist会无条件地移除此类语句,但(*)表示Necessist可能不应该这样做。假设启用了溢出检查,计算此语句的最弱前置条件的计算可能如下所示

{ Q[(x - 1)/x] ^ x >= 1 }
x -= 1;
{ Q }

请注意,x -= 1;并不会改变上下文,并且Q[(x - 1)/x] ^ x >= 1可能意味着Q。例如,如果Q不包含x,则Q[(x - 1)/x] = QQ ^ x >= 1意味着Q

鉴于*和Necessist当前行为之间的差异,人们可能会问:哪一种应该调整?换句话说,Necessist是否应该无条件地删除类似x -= 1;的语句?

一种看待这个问题的方式是:哪些语句值得删除,即哪些语句是“有趣的”?如上所述,*认为如果一个语句的删除可能会影响后续断言,则该语句是“有趣的”。但是,“有趣的”语句的其他可能的、有用的定义。例如,可以考虑最强的后置条件(如上所述),或者除了Hoare逻辑之外的框架。

为了明确,Necessist并没有正式地应用*,例如,Necessist实际上并不计算最弱前条件。当前*的作用是帮助指导Necessist应该忽略哪些语句,并且*在这个角色中似乎做得很好。因此,我们将解决上述差异留待未来的工作。

用法

Usage: necessist [OPTIONS] [TEST_FILES]... [-- <ARGS>...]

Arguments:
  [TEST_FILES]...  Test files to mutilate (optional)
  [ARGS]...        Additional arguments to pass to each test command

Options:
      --allow <WARNING>        Silence <WARNING>; `--allow all` silences all warnings
      --default-config         Create a default necessist.toml file in the project's root directory
      --deny <WARNING>         Treat <WARNING> as an error; `--deny all` treats all warnings as errors
      --dump                   Dump sqlite database contents to the console
      --dump-candidates        Dump removal candidates and exit (for debugging)
      --framework <FRAMEWORK>  Assume testing framework is <FRAMEWORK> [possible values: anchor, auto, foundry, go, hardhat, rust]
      --no-dry-run             Do not perform dry runs
      --no-sqlite              Do not output to an sqlite database
      --quiet                  Do not output to the console
      --reset                  Discard sqlite database contents
      --resume                 Resume from the sqlite database
      --root <ROOT>            Root directory of the project under test
      --timeout <TIMEOUT>      Maximum number of seconds to run any test; 60 is the default, 0 means no timeout
      --verbose                Show test outcomes besides `passed`
  -h, --help                   Print help
  -V, --version                Print version

输出

默认情况下,Necessist只在测试通过时向控制台输出。使用--verbose会使Necessist输出以下所有删除结果。

结果 含义(删除语句/方法调用之后...)
通过 构建并通过了测试。
超时 构建了测试但超时。
失败 构建了测试但失败。
不可构建 测试未构建。

默认情况下,Necessist将输出到控制台和sqlite数据库。对于后者,可以使用sqlitebrowser之类的工具来过滤/排序结果。

详细信息

一般来说,Necessist不会尝试删除以下任一语句:

  • 包含其他语句的语句(例如,一个for循环)
  • 声明(例如,局部或let绑定)
  • breakcontinuereturn
  • 测试的最后一条语句

同样,如果

  • 它是包含语句的主要效果(例如,x.foo();)。
  • 它出现在被忽略的函数、方法或宏的参数列表中(见下文)。

此外,对于某些框架,某些语句和方法将被忽略。点击一个框架以查看其具体信息。

锚点TS

忽略的函数

  • assert
  • assert.开头的内容(例如,assert.equal
  • console.开头的内容(例如,console.log
  • expect

忽略的方法

  • toNumber
  • toString
Foundry

除了以下内容外,Foundry框架还会忽略

  • 紧随vm.prank或任何形式的vm.expect(例如,vm.expectRevert)之后的语句
  • emit语句

忽略的函数

  • assert开头的内容(例如,assertEq
  • vm.expect开头的内容(例如,vm.expectCall
  • console.log开头的内容(例如,console.logconsole.logInt
  • console2.log开头的内容(例如,console2.logconsole2.logInt
  • vm.getLabel
  • vm.label
Go

除了以下内容外,Go框架还会忽略

  • defer语句

忽略的函数

  • assert.开头的内容(例如,assert.Equal
  • require.开头的内容(例如,require.Equal
  • panic

忽略的方法*

  • Close
  • Error
  • Errorf
  • Fail
  • FailNow
  • Fatal
  • Fatalf
  • Log
  • Logf
  • Parallel
  • Skip
  • Skipf
  • SkipNow

* 此列表主要基于testing.T的方法。然而,为了避免与其他类型的冲突,省略了一些常用名称的方法。

Hardhat TS

忽略的函数和方法与上述Anchor TS相同。

Rust

忽略的宏

  • assert
  • assert_eq
  • assert_matches
  • assert_ne
  • eprint
  • eprintln
  • panic
  • print
  • println
  • unimplemented
  • unreachable

忽略的方法*

  • as_bytes
  • as_encoded_bytes
  • as_mut
  • as_mut_os_str
  • as_mut_os_string
  • as_mut_slice
  • as_mut_str
  • as_os_str
  • as_path
  • as_ref
  • as_slice
  • as_str
  • borrow
  • borrow_mut
  • clone
  • cloned
  • copied
  • deref
  • deref_mut
  • expect
  • expect_err
  • into_boxed_bytes
  • into_boxed_os_str
  • into_boxed_path
  • into_boxed_slice
  • into_boxed_str
  • into_bytes
  • into_encoded_bytes
  • into_os_string
  • into_owned
  • into_path_buf
  • into_string
  • into_vec
  • iter
  • iter_mut
  • success
  • to_os_string
  • to_owned
  • to_path_buf
  • to_string
  • to_vec
  • unwrap
  • unwrap_err

* 此列表基本上是Dylint的unnecessary_conversion_for_trait lints的watched trait和固有方法,以下为添加项

配置文件

配置文件允许用户根据项目定制Necessist的行为。该文件必须命名为necessist.toml,出现在项目的根目录中,并且是toml编码。该文件可以包含以下选项之一或多个。

  • ignored_functionsignored_methodsignored_macros:字符串列表,被解释为模式。一个函数、方法或宏(分别)的路径与列表中的任何模式匹配时将被忽略。注意,ignored_macros目前仅由Rust框架使用。

  • ignored_path_disambiguation:字符串“Either”、“Function”或“Method”之一。对于可能指代函数或方法的路径(见下文),此选项影响是否忽略函数或方法。

    • Either(默认):如果路径与ignored_functionsignored_methods模式匹配,则忽略。

    • Function:只有当路径与ignored_functions模式匹配时才忽略。

    • Method:只有当路径与ignored_methods模式匹配时才忽略。

  • ignored_tests:一个字符串列表。名称与列表中的字符串完全匹配的测试会被忽略。对于基于Mocha的框架(例如Anchor和Hardhat),测试名称被认为是传递给it的消息。

模式

模式是由字母、数字、._*组成的字符串。除了*之外的每个字符都被当作字面意义处理,仅匹配自身。一个*可以匹配任何字符串,包括空字符串。

以下是一些模式的示例

  • assert:仅匹配自身
  • assert_eq:仅匹配自身
  • assertEqual:仅匹配自身
  • assert.Equal:仅匹配自身
  • assert.*:匹配assert.Equal,但不匹配assertassert_eqassertEqual
  • assert*:匹配assertassert_eqassertEqualassert.Equal
  • *.Equal:匹配assert.Equal,但不匹配Equal

注意

  • 模式匹配路径,而不是单个标识符。
  • .被当作字面意义处理,如同在glob模式中,而不是正则表达式。

路径

路径是由标识符通过.分隔的序列。考虑以下示例(来自Chainlink

operator.connect(roles.oracleNode).signer.sendTransaction({
    to: operator.address,
    data,
}),

在上面的示例中,operator.connectsigner.sendTransaction是路径。

然而,路径如operator.connect是模糊的

  • 如果operator指的是包或模块,那么operator.connect指的是一个函数。
  • 如果operator指的是一个对象,那么operator.connect指的是一个方法。

默认情况下,Necessist在路径匹配ignored_functionsignored_methods模式时会忽略该路径。将上述ignored_path_disambiguation选项设置为FunctionMethod会导致Necessist仅在路径匹配ignored_functionsignored_methods模式时忽略该路径(分别对应)。

局限性

  • 慢。修改测试需要重新构建它们。在即使是中等规模的代码库上运行Necessist可能需要几个小时。

  • 分级需要深入了解源代码。一般来说,Necessist不会产生“明显的”错误。根据我们的经验,决定一个语句/方法调用是否是必需的需要对被测试的代码有深入的了解。Necessist最好在拥有(或打算拥有)此类知识的代码库上运行。

语义版本控制策略

我们保留更改以下内容并考虑此类更改不会中断的权利。

  • 默认情况下Necessist忽略的语法

对以下内容的更改将伴随至少Necessist的次版本号的升级

  • 删除候选者输出的顺序
  • necessist.db中记录存储的顺序

目标

  • 如果一个项目使用了受支持的框架,那么进入项目的目录并输入necessist(不带任何参数)应该会产生有意义的输出。

非目标

  • 成为通用目的的突变测试工具。已经存在一些这样的工具(例如,universalmutator)。

参考文献

  • Groce, A., Ahmed, I., Jensen, C., McKenney, P.E., Holmes, J.: 我的代码是如何验证(或测试)的?错误驱动验证和测试。Autom. Softw. Eng. 25, 917–960 (2018)。可以找到预印本。参见第2.3节。

许可证

Necessist在AGPLv3许可下授权和分发。如果您希望获得许可条款的例外,请联系我们:Contact us

依赖关系

~65MB
~1.5M SLoC