边界值附近用random测试易漏bug，因真随机不保证覆盖1、99等边界及0、100等越界值；边界问题需确定性覆盖，应显式列举最小、最大、空、None等用例。
为什么边界值附近用 random 测试反而容易漏 bug
因为真随机不保证覆盖边界——比如测试 range(1, 100) 时，random.randint(1, 99) 生成的数大概率绕开 1 和 99，更别说 0 或 100 这类越界值。边界问题本质是确定性场景，靠概率撞上等于赌运气。
实操建议：
- 把边界值（最小、最大、空、None、临界溢出点）单独列进测试用例，不依赖随机生成
- 若必须用随机辅助，先固定
random.seed()确保可复现，再人工注入边界值到样本池 - 对输入范围做分段：比如
[min, min+1, mid, max-1, max]强制覆盖，其余用随机补量
hypothesis 比 random 更适合边界探测的原因
hypothesis 不是随机乱试，它会主动收缩搜索空间、优先尝试小整数、空字符串、极值等“易出错”的输入，还能根据失败案例自动缩小范围做深度挖掘。
常见错误现象：用 @given(st.integers()) 测试函数却没触发 ValueError，其实是因为默认策略偏向中等大小整数；而加了 st.integers(min_value=0, max_value=1) 后立刻暴露逻辑漏洞。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 明确声明边界约束：
st.integers(min_value=-1, max_value=10)，比放任默认范围更可控 - 用
@example()显式插入关键边界值，比如@example(-1)、@example(2**31-1) - 避免在
@given中混用random.choice()，会破坏假设的收缩能力
手写随机测试时如何避免「假覆盖」
所谓假覆盖，是指测试跑过了、日志显示“1000次随机输入”，但实际所有输入都在安全区间内，根本没触达边界逻辑分支。
使用场景：CI 中跑快速模糊测试、本地验证函数鲁棒性、临时排查某次偶发 crash。
实操建议：
- 记录每次生成的输入极值：
print(f"min={min(samples)}, max={max(samples)}")，一眼看出是否碰过边界 - 给被测函数加断言钩子，例如在
if x 分支开头插 <code>print("hit negative branch")，确认路径真实执行 - 不要只看“没报错”，要检查返回值是否符合边界语义——比如传入空列表，函数该返回空还是抛异常？得比对预期
Python 单元测试里混用 random 和 pytest 的兼容陷阱
直接在 test_* 函数里调 random.random() 会导致测试不可重复，CI 失败无法复现；而用 pytest.mark.parametrize 静态展开又写死用例，失去探索性。
性能影响：每次调 random.seed(time.time()) 会导致同一秒内多个测试拿到相同种子，看似随机实则重复。
实操建议：
- 用
pytest-randomly插件替代手写random，它接管整个测试顺序和 fixture 初始化，不污染业务逻辑 - 若坚持手写，必须在每个测试开始前调
random.seed(os.getenv("SEED", "42"))，并把 seed 打印进日志 - 禁止在
conftest.py顶层执行random.seed()，否则所有测试共享一个状态，相互污染
边界条件不是靠“多试几次”就能兜住的，它需要你主动定义哪些值算边界、哪些分支必须执行、哪些返回值才算合理——随机只是工具，控制权始终得攥在人手里。
