T12 · Testing & Deployment

一个现实问题

你写了一份合约：用户把一种稳定币存进来，你的合约替他存进某个借贷协议，再把凭证发回给他。

测试写得很认真。你做了一份假的代币、一份假的借贷协议，用例 34 条，覆盖率 97%，全绿。

部署到主网，第一笔真实交易 revert。

你查了一下午才明白：真实的那种稳定币，在已有授权额度不为零时，第二次授权会直接失败。 你那份假代币没有这个行为——因为你是照着标准写的，而它不完全按标准（T9 里的那一整类坑）。

你改完重新部署。第二笔交易又 revert。这次是真实的借贷协议对这个资产设了一个最小存款额，低于它就拒绝。你那份假协议也没有这个行为。

第三次部署之后，你发现了最难受的一件事：合约的管理权限还留在部署脚本用的那个临时地址上。 移交权限那一步你写了，但没有任何东西验证它执行成功了。

三个问题有一个共同点：

它们都不在你的代码里，而在你对世界的假设里。而你的测试，恰恰是用你自己的假设写出来的。

97% 的覆盖率证明了你的代码被执行过，没有证明你的任何一条假设是真的。

所以问题是：怎样让测试跑在真实的世界上，而不是跑在你想象的世界上？

思想实验

把上线前的准备想成飞行训练，四个层次。

第一层：在纸上推演。 给定风速、重量、跑道长度，算出起飞距离。快、便宜，能验证你的公式对不对。它验证不了的是这些数字从哪来——你算得再对，风速填错了照样撞山。

第二层：在模拟器里飞。 把飞机、跑道、塔台全部搭出来，完整跑一遍流程。现在你能发现「起落架收上去之后襟翼收不了」这类零件之间的问题。它验证不了的是：模拟器里的跑道是你自己建的，真实跑道上有的坑，这里没有。

第三层：把真实的机场搬进模拟器。 不再自己建跑道，而是把某一个真实机场的跑道、地形、导航台原样导进来，在上面飞。

这一层是这一章的核心。 你的代码还在本地跑，但它交互的对象是真实世界的当前状态：真实的代币、真实的协议、真实的参数、真实的怪癖。前两层发现不了的那三个问题，在这里全都会现形。

第四层：真飞一次，但载沙袋。 在一个不花真钱的环境里走完整条上线流程，包括部署、验证、移交权限。

四层之间有一个清晰的分工：

• 前两层验证你的逻辑。
• 第三层验证你的假设。
• 第四层验证你的流程。

三者是三类不同的错误，用一种手段全覆盖是做不到的。

还有一件事，比上面任何一层都重要，而且和层次无关：

一份合约的每一个入口都是公开的。所以「它能不能正确拒绝」，比「它能不能正确执行」重要得多。

正确执行的路径只有一条，你一定会测。正确拒绝的路径有几十条，而且每一条漏掉都是一个可以被任何人直接调用的洞。

你来决定

你的合约要和一个真实协议交互。上线前怎么测？

观察结果

四个选项不是四个等级，是两个互相独立的维度。

这张表里藏着这一章最该带走的一句话：

覆盖率衡量的是你的代码被执行了多少，不衡量你的假设被检验了多少。

一份 100% 覆盖率、全部用替身的测试套件，可以对真实世界的行为一无所知；而一条跑在真实状态上的路径，可能只覆盖 20% 的分支，却挡住了会让你亏钱的那一类问题。所以答案不是选一个，是按层分工：

• 用替身测逻辑和拒绝路径，因为它快，你可以写很多条。
• 用真实状态测集成，因为只有它能检验假设。
• 用一次完整的流程演练测部署，因为部署是一段没有人写测试的代码。

还有一条推论，值得单独写下来：你没写的那条拒绝用例，就是别人会调用的那个入口。

建立模型

一条上线流水线

注意第一步：先写失败用例，再写成功用例。 这不是风格偏好，是顺序问题——先写成功用例的人，写完就觉得做完了。

拒绝清单：把每一个限制变成一条用例

打开你的合约，把每一处「不满足条件就拒绝」的地方列出来，每一处对应一条用例。

最后一行是一类特殊的用例：你需要专门写一个「恶意合约」当测试工具。它的唯一作用是在收到回调时做一件不该做的事。完整的重入模型在 T28，但那条用例现在就该有。

两个容易漏的检查点：

1. 断言的是「拒绝」，不是「随便报个错」。 断言具体的错误类型或错误信息。否则你的用例在合约因为另一个原因失败时，照样是绿的——这类假绿用例非常多。
2. 拒绝之后状态没有被改。 一条 revert 应该让整笔交易的所有改动全部撤销。顺手断言一下关键状态没变，能抓到一类很隐蔽的错误。

真实状态测试：三件必须做对的事

第一，固定高度。 从一个真实网络取状态时，必须把取数的高度写死在配置里。不写死，你的测试就依赖「当下的链上状态」，而那个状态每十几秒变一次：今天绿的用例下周变红，而你会花两天去查一个根本不在你代码里的问题。

第二，准备身份和余额。 你的测试账户在真实状态里是没有钱的。两条路：

• 找一个持有大量目标资产的真实地址，让测试用它的身份发交易。大多数测试框架都提供「以任意地址身份调用」的能力。
• 直接改写存储，把余额写进去。更快，但你得知道那个余额存在哪个槽里（T8 讲过存储布局）。

第三，断言真实的结果，而不是断言没报错。 「交易没 revert」是一个几乎没有信息量的断言。要断言的是：我的余额少了多少、对方给了我什么凭证、协议里的记账变成了什么。

一条完整的集成测试路径长这样：

1. 从真实网络的某个固定高度取状态
2. 部署你的合约
3. 给测试账户准备真实资产
4. 记录交互前的所有相关余额与状态
5. 调用你的合约，走完整条业务路径
6. 断言：你的余额、对方的余额、凭证数量、协议记账，逐项对上
7. 再走一遍反向路径（提取、赎回），断言能回到起点

第 7 步最容易被跳过，也最容易出事。存得进去不等于取得出来，而取不出来这件事，只有走一遍才知道。

随机与不变量：把「对所有输入」写成可执行的断言

普通用例是「给定这个输入，输出应该是那个」。随机测试反过来：给定任意输入，有一条性质必须始终成立。

常用的几条性质，几乎适用于任何持有资金的合约：

合约实际持有的资产  不小于  所有用户记账之和
所有持有人余额之和  等于    总供应量
任何账户在任意操作序列之后，能取走的  不多于  它存入的
一次「存入再立刻提取」的净效果  不优于  什么都不做
一个只应由管理员改变的参数，在一万次随机调用之后  没有变

最后一条是被低估的：把随机调用器指向你的全部公开入口，让它乱打一万次，然后检查不变量。 这是一种成本极低、回报极高的测试——它找到的问题，往往是你根本没想过的调用顺序。

两个实践细节：

• 失败时要能重现。 记下让它失败的那个随机种子和那串输入，然后把它固化成一条普通用例。
• 不变量的范围要划清。 「合约余额不小于记账之和」在收到直接转账（不经过你的入口）时可能被打破，这时要么调整不变量，要么承认这是一个真实的缺陷。

部署是一段没人写测试的代码

部署脚本通常是整个项目里唯一一段「只跑一次、跑错了改不了、而且没有测试」的代码。开头那第三个问题就出在这里。

一份合格的部署脚本要做到这几件事：

第三行是最关键的一条。部署脚本的最后一段应该是一串断言，而不是一句「部署完成」：

assert 合约的 owner == 配置里的多签地址
assert 合约的 admin != 部署者地址
assert 关键参数 == 配置里的值
assert 合约已暂停（如果你的上线流程是先暂停后开放）
assert 依赖的外部地址 == 配置里的地址，且那个地址上有代码

最后一条特别容易漏：传进去的外部地址，可能在这条链上根本没有合约。 一个指向空地址的依赖，在部署时不报任何错，在第一笔用户交易时才炸。

还有一条流程上的规矩：部署脚本必须先在真实状态的本地环境里演练一遍。 同一套配置、同一段脚本，在搬来的真实状态上跑一次完整部署加断言——它能在花任何钱之前，抓住配置错误、地址错误、权限错误这三类最贵的问题。

它叫什么

动手

<你的测试框架的分叉参数> --fork-url <你的归档 RPC 地址> --fork-block-number <一个你选定的高度>

方法一：以持有人身份调用
  找一个持有大量目标代币的真实地址
  用你的框架提供的「模拟任意地址发交易」能力
  从它那里转一些到你的测试账户

方法二：直接改写存储
  找到余额映射所在的存储槽（T8 讲过布局规则）
  用你的框架提供的「写任意存储槽」能力直接写入

用例 1：金额为 0 时调用，断言被拒绝，且状态没有改变
用例 2：没有授权额度就调用，断言被拒绝
用例 3：用一个非管理员地址调用管理函数，断言被拒绝

打开合约，数一数总共有多少处「不满足条件就拒绝」。
再数一数你的测试里有多少条用例在断言拒绝。
两个数字应该接近。

合约实际持有的资产数量  不小于  所有用户记账之和

AI Lab

第一步：
这是我的合约源码。为它生成一套测试用例。
要求：先列出所有会导致拒绝的条件，每一条给一个断言被拒绝的用例，
再写成功路径的用例。每条用例说明它在验证什么。

第二步：
把你刚才生成的用例和我的合约逐行对照，列一张表：
合约里每一处 require / revert / 权限检查，对应哪一条用例？
没有对应用例的，单独列出来。

第三步：
现在假设这份合约要和一个真实的外部协议交互，而我用替身代替了它。
列出：我的替身和真实依赖之间，有哪几类行为差异可能让测试通过但线上失败？
每一类给一个具体的例子，并说明在分叉环境里怎么验证它。

真实案例

改一个变量

带走的问题

本章自测