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.4 | 2022年10月4日 |
#50 in 测试
459次每月下载
1.5MB
7.5K SLoC
必要主义
运行移除语句和方法调用的测试,以帮助识别损坏的测试
必要主义目前支持Anchor (TS)、Foundry、Go、Hardhat (TS)和Rust。
关于必要主义的论文(《Test Harness Mutilation》)将在Mutation 2024上发表。( 论文,幻灯片,预印本)
内容
安装
系统要求
在您的系统上安装pkg-config
和sqlite3
开发文件,例如,在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
的最弱前件P
与S
的后置条件Q
具有相同的上下文(例如,作用域中的变量),并且P
不意味着Q
。
(*
)试图捕捉的概念是:影响后续断言的语句。在本节中,我们将解释并说明这一选择。为了简洁起见,我们专注于语句,但本节的注释也适用于方法调用。
回忆两种谓词转换语义:最弱前件和最强后件。前者涉及在给定语句之后的后件成立的情况下,推理在语句之前可能成立的最弱前件。后者涉及在给定语句之前的前件成立的情况下,推理在语句之后可能成立的最强后件。一般来说,前者更常见(参见Aldrich 2013中的解释),这是我们在这里使用的方法。
从这一视角考虑一个测试。测试是一个没有输入或输出的函数。因此,确定测试是否通过的另一种方法如下。从True
开始,迭代地通过测试的语句向后工作,计算每个语句的最弱前件。如果到达测试第一个语句的前件是True
,则测试通过。如果前件是False
,则测试失败。
现在,假设我们应用这个程序,并考虑一个违反(*
)的语句S。我们认为删除
S
可能没有意义。
案例1:代码S
向或从作用域中添加或删除变量(例如,S
是一个声明),或者S
更改了变量的类型。那么移除S
可能会导致编译失败。(此外,由于S
的前置条件和后置条件具有不同的上下文,因此不清楚如何比较它们。)
案例2:S
的前置条件比其后置条件更强(例如,S
是一个断言)。那么S
对其执行环境施加了约束。换句话说,S
正在测试某些内容。因此,移除S
可能会削弱测试的整体目的。
相反,考虑一个满足(*
)的语句S
。以下是移除S
可能合理的原因。将S
视为移动有效环境集,而不是对其施加约束。更准确地说,如果S
的最弱前置条件P
不蕴含Q
,并且如果Q
是可满足的,那么存在一个赋值给P
和Q
的自由变量的赋值,该赋值同时满足P
和Q
。如果这样的赋值来自S
实际执行的每个环境,那么S
的必要性就值得怀疑。
(*
)的主要用途在于帮助选择Necessist忽略的函数、宏和方法调用。Necessist默认忽略其中的一些。假设对于某个框架,我们正在考虑是否应该忽略某些函数foo
。如果我们想象框架测试语言的谓词变换语义,我们可以问:如果语句S
是foo
的调用,那么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] = Q
和Q ^ 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
绑定) break
、continue
或return
- 测试的最后一条语句
同样,如果
- 它是包含语句的主要效果(例如,
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.log
,console.logInt
) - 以
console2.log
开头的内容(例如,console2.log
,console2.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和固有方法,以下为添加项
clone
(例如std::clone::Clone::clone
)cloned
(例如std::iter::Iterator::cloned
)copied
(例如std::iter::Iterator::copied
)expect
(例如std::option::Option::expect
)expect_err
(例如std::result::Result::expect_err
)into_owned
(例如std::borrow::Cow::into_owned
)success
(例如assert_cmd::assert::Assert::success
)unwrap
(例如std::option::Option::unwrap
)unwrap_err
(例如std::result::Result::unwrap_err
)
配置文件
配置文件允许用户根据项目定制Necessist的行为。该文件必须命名为necessist.toml
,出现在项目的根目录中,并且是toml编码。该文件可以包含以下选项之一或多个。
-
ignored_functions
、ignored_methods
、ignored_macros
:字符串列表,被解释为模式。一个函数、方法或宏(分别)的路径与列表中的任何模式匹配时将被忽略。注意,ignored_macros
目前仅由Rust框架使用。 -
ignored_path_disambiguation
:字符串“Either”、“Function”或“Method”之一。对于可能指代函数或方法的路径(见下文),此选项影响是否忽略函数或方法。-
Either
(默认):如果路径与ignored_functions
或ignored_methods
模式匹配,则忽略。 -
Function
:只有当路径与ignored_functions
模式匹配时才忽略。 -
Method
:只有当路径与ignored_methods
模式匹配时才忽略。
-
-
ignored_tests
:一个字符串列表。名称与列表中的字符串完全匹配的测试会被忽略。对于基于Mocha的框架(例如Anchor和Hardhat),测试名称被认为是传递给it
的消息。
模式
模式是由字母、数字、.
、_
或*
组成的字符串。除了*
之外的每个字符都被当作字面意义处理,仅匹配自身。一个*
可以匹配任何字符串,包括空字符串。
以下是一些模式的示例
assert
:仅匹配自身assert_eq
:仅匹配自身assertEqual
:仅匹配自身assert.Equal
:仅匹配自身assert.*
:匹配assert.Equal
,但不匹配assert
、assert_eq
或assertEqual
assert*
:匹配assert
、assert_eq
、assertEqual
和assert.Equal
*.Equal
:匹配assert.Equal
,但不匹配Equal
注意
路径
路径是由标识符通过.
分隔的序列。考虑以下示例(来自Chainlink)
operator.connect(roles.oracleNode).signer.sendTransaction({
to: operator.address,
data,
}),
在上面的示例中,operator.connect
和signer.sendTransaction
是路径。
然而,路径如operator.connect
是模糊的
- 如果
operator
指的是包或模块,那么operator.connect
指的是一个函数。 - 如果
operator
指的是一个对象,那么operator.connect
指的是一个方法。
默认情况下,Necessist在路径匹配ignored_functions
或ignored_methods
模式时会忽略该路径。将上述ignored_path_disambiguation
选项设置为Function
或Method
会导致Necessist仅在路径匹配ignored_functions
或ignored_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