这个java案例是否做了敏感性测试？

wen java案例 2026-08-13 2

本文目录导读：

这个java案例是否做了敏感性测试？

敏感性测试：Java开发中的“隐形守门员”
案例复盘：一个支付模块的“漏网之鱼”
四大敏感场景实测：并发、数据、异常、安全
为什么“没报错”不等于“没风险”？
实战问答：如何用JUnit+JMH打造敏感测试闭环？
结论：敏感测试不是“可选项”，而是“必答题”

**
《Java案例的敏感性测试“生死局”：你以为的“安全”可能只是假象》

目录导读

敏感性测试：Java开发中的“隐形守门员”
案例复盘：一个支付模块的“漏网之鱼”
四大敏感场景实测：并发、数据、异常、安全
为什么“没报错”不等于“没风险”？
实战问答：如何用JUnit+JMH打造敏感测试闭环？
敏感测试不是“可选项”，而是“必答题”

敏感性测试：Java开发中的“隐形守门员”

在Java开发者的日常工作中，功能测试、单元测试往往占据视线焦点，而“敏感性测试”却常常被忽视，所谓敏感性测试，指的是在极端条件、边界输入、异常并发、资源受限等场景下，验证系统是否依然保持正确性、稳定性与安全性的测试行为，它不直接验证“功能对不对”，而是验证“在极限拉扯下，功能会不会崩”。

很多团队在交付时都会拍胸脯说：“我们做了完整的JUnit测试，覆盖率90%以上。”但一旦问及“是否做了敏感性测试”，往往陷入沉默，这并非个例，而是行业通病——因为敏感性测试没有固定范式，且投入产出比难以量化，容易被划入“非紧急任务”。

案例复盘：一个支付模块的“漏网之鱼”

来看一个真实的伪代码案例（基于常见电商系统重构）：

public class PaymentService {
    private final AccountDao accountDao;
    public boolean transfer(Long fromId, Long toId, BigDecimal amount) {
        if (amount.compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException("金额必须大于0");
        }
        Account from = accountDao.findById(fromId);
        Account to = accountDao.findById(toId);
        // 直接扣减与增加
        from.setBalance(from.getBalance().subtract(amount));
        to.setBalance(to.getBalance().add(amount));
        accountDao.update(from);
        accountDao.update(to);
        return true;
    }
}

功能测试下，单线程、单用户、整数金额——一切完美，但敏感性测试却暴露出三个致命问题：

并发敏感：当同一账户同时收到两笔转账请求，未加锁的“先读取后写入”导致丢失更新,余额凭空多出或减少。
数据精度敏感：如果金额为 1 + 0.2 这样的浮点陷阱，虽然此处用了BigDecimal，但若传入 Double 类型则直接翻车。
事务敏感：两步 accountDao.update 之间若发生异常，事务未回滚,导致账实不符。

这恰恰说明：没有敏感测试的代码，就像没有保险丝的电闸，平时安静，一遇浪涌就火光四溅。

四大敏感场景实测：并发、数据、异常、安全

（1）并发敏感性测试

通过 CountDownLatch 模拟100个线程同时进行转账操作，预期结果：总余额守恒，且无死锁，实际测试中，如果不加 synchronized 或乐观锁版本号,必然出现余额异常。

（2）数据边界敏感性测试

测试金额为 001 与 -0.001,验证正负边界处理逻辑。
测试账户余额恰为 0 或 00,验证是否允许透支。
测试超长字符串ID（如100个“A”）,验证数据库字段长度截断是否引发SQLException。

（3）异常敏感性测试

在 accountDao.update 中强制抛 DataAccessException,验证事务是否整体回滚。
模拟数据库连接池耗尽,验证等待超时机制与线程池拒绝策略。

（4）安全敏感性测试

输入 ' OR '1'='1 作为ID，验证是否触发SQL注入（使用预编译则安全）。
传入超大数据量 List<Account>,验证内存溢出风险。

为什么“没报错”不等于“没风险”？

很多开发者对敏感测试的第一反应是：“我运行了，没报错啊。”但敏感性测试恰恰反其道而行之——它强行制造错误，观察系统反应。

在正常功能测试中，你永远不会用 -1 当用户ID，因为业务逻辑禁止，但敏感测试会故意传入 -1，看系统是返回友好提示，还是直接空指针崩溃，再如，正常请求下，并发量是10，敏感测试直接压到1000,看系统是否出现内存溢出或响应超时。

“没报错”只能证明在特定路径下系统没崩，但无法证明在奇点路径下不会崩。 正如汽车测试，正常路况驾驶顺畅，和紧急制动、爆胎情况下的车身稳定,是完全两码事。

实战问答：如何用JUnit+JMH打造敏感测试闭环？

问：我该如何在现有项目中引入敏感性测试？

答：建议采用“三步走”策略：

基于JUnit的边界断言：使用 @Test(expected = XxxException.class) 验证非法输入的异常抛出；利用 assertThrows 验证异常类型。
基于JMH的并发压力模拟：通过 @Benchmark 注解，模拟高并发场景，结合 Thread.sleep 与 CyclicBarrier 模拟线程同步竞争。
基于故障注入的依赖模拟：使用 Mockito 强行让 accountDao.update 失败,验证事务回滚是否生效。

示例代码：

@Test
public void testConcurrentTransfer() throws InterruptedException {
    int threadCount = 100;
    CountDownLatch latch = new CountDownLatch(threadCount);
    ExecutorService pool = Executors.newFixedThreadPool(10);
    for (int i = 0; i < threadCount; i++) {
        pool.submit(() -> {
            try {
                transfer(1L, 2L, new BigDecimal("1.00"));
            } finally {
                latch.countDown();
            }
        });
    }
    latch.await();
    // 断言最终余额
    assertEquals(new BigDecimal("0.00"), accountDao.findById(1L).getBalance());
}

如果这个测试不通过,说明你的锁机制或乐观锁版本号根本没有生效。