关键词：需求分析,测试准备

01 第一个坑：把“需求文档”当圣旨，不质疑、不追问

较高的测试人员，拿到需求文档的第一反应是：“好的，我看看怎么测。” 然后埋头写用例，写到一半发现逻辑不通，回头问产品经理，产品说“这里我写错了”——你已经白干三天。

不质疑需求，就是对自己职业生涯最大的浪费。

需求文档不是圣经。它是产品经理在有限信息下输出的“草稿”。你看到的是文字，背后是无数个未定义的边界、未说清的逻辑、未确认的异常。

案例： 一个电商订单系统，需求文档写“用户下单后30分钟内未支付，订单自动取消”。听起来没问题。但你追问一句：“如果用户在29分59秒发起支付，但支付网关响应延迟了10秒，订单状态怎么处理？” 产品经理当场愣住，然后说：“这个场景我们没考虑，需要和技术确认。”

这个追问，直接避免了线上一个“支付成功但订单被取消”的P0级bug。这个bug一旦上线，用户投诉、退款、赔偿，成本至少是5人*3天的修复+验证时间。

怎么做？ 拿到需求后，先做“需求三问”：

1. 边界在哪里？ 比如金额上限、时间阈值、并发数量。

2. 异常怎么处理？ 网络超时、数据冲突、用户操作中断。

3. 默认值是什么？ 用户不选、不填、不操作时，系统怎么走？

每一条需求，至少追问3个“如果”。不追问，你测的就是别人的错误。

02 第二个坑：只关注“功能路径”，忽略“数据流和状态机”

很多测试人，画流程图只画“正常流程”：注册-登录-下单-支付-发货-收货。流程走通了，就觉得测试完了。但线上出bug，较高出在状态转换和数据处理上。

功能路径是表象，数据流和状态机才是系统的灵魂。

案例： 一个任务管理系统，需求说“任务状态有：待处理、进行中、已完成”。正常流程：待处理→进行中→已完成。测试人员走了一遍，通过。上线后，用户反馈：我把任务从“进行中”拖回“待处理”，系统报错了。

为什么？因为需求文档没写“状态回退”的逻辑。测试人员也没测这个场景。但用户真实操作中，就是会“改主意”。你漏测一个状态转换，用户就多一次报错。

怎么做？ 画状态机图，穷举所有状态转换路径。不要只画直线，要画网格。

每一条记录，都是你测试用例的种子。状态机图不画完，用例不写第一行。

代码示例（伪代码逻辑）：

def change_task_status(current_status, action):
    # 状态转换规则表
    transitions = {
        '待处理': {'开始': '进行中'},
        '进行中': {'暂停': '待处理', '完成': '已完成'},
        '已完成': {'回退': '进行中', '删除': '已删除'}
    }
    if current_status in transitions and action in transitions[current_status]:
        new_status = transitions[current_status][action]
        return new_status
    else:
        raise ValueError(f"状态转换不允许：从{current_status}执行{action}")

测试用例就是遍历这张表，验证每个组合是否返回预期结果。不穷举，就是给自己埋雷。

03 第三个坑：只测“单一用户”，不测“并发和冲突”

需求文档里写的都是“单个用户操作”。但线上是1000个用户同时操作。你测单用户没问题，多用户一上，数据就乱了。

单用户测试是及格线，并发测试是生存线。

案例： 一个库存管理系统，需求说“用户下单扣减库存”。测试人员手动测：先查库存100，下单1件，库存变99。正确。上线后，双十一活动，100件商品瞬间被抢光，但系统显示库存还有50件。为什么？因为两个用户同时下单，都读到库存100，同时扣减，都扣成99。实际卖了2件，库存只减了1件。这就是典型的“并发扣减”bug。

怎么做？ 需求分析阶段，就要识别出“共享资源”和“临界区”。库存、余额、名额、优惠券——这些都是多线程操作的高危区域。针对这些场景，设计并发测试用例。

代码示例（并发扣减的错误写法）：

# 错误写法：先读后写，不锁
def deduct_stock(product_id, quantity):
    stock = get_stock(product_id)  # 读
    if stock >= quantity:
        new_stock = stock - quantity
        update_stock(product_id, new_stock)  # 写
        return True
    return False

并发测试用例设计：

1. 两个线程同时读取库存（100件）

2. 线程A扣减1件，线程B扣减1件

3. 预期结果：库存变为98件

4. 实际结果：库存变为99件（bug暴露）

正确做法： 使用数据库行锁或乐观锁。

# 正确写法：原子操作
def deduct_stock_safe(product_id, quantity):
    # SQL: UPDATE products SET stock = stock - ? WHERE id = ? AND stock >= ?
    result = execute_safe_update(product_id, quantity)
    return result > 0

需求分析时，问产品经理：“这个数据是共享的吗？多个用户同时操作会冲突吗？” 如果产品回答“不会”，你要反问：“为何不会？有锁吗？有版本号吗？” 不回答清楚，这个需求就是一颗定时炸弹。

---

总结金句： 需求分析不是读文档，是给系统做“压力测试”——在代码还没写之前，先把逻辑压垮。