【测试准备】软件测试问题发现模型

Suumi.Sun

已于 2025-05-20 15:05:50 修改

阅读量192

点赞数

分类专栏：软件测试开发文章标签：模块测试集成测试

于 2021-09-14 10:05:13 首次发布

本文链接：https://blog.youkuaiyun.com/qingdaoyin/article/details/120281504

版权

7 篇文章

订阅专栏

结论先行：需从用户操作链路与异常场景覆盖度评估需求合理性。

用户故事覆盖度：
需站在使用者的角度，考虑用户会遇到的各种情况，反观各种情况在需求中是否都能找到对应描述。并完整描述核心场景（如电商订单支付、物流状态同步）及异常场景（如网络中断重试、重复支付拦截）。
- 拆解用户角色、操作路径、业务目标（如：用户下单→支付→库存扣减→物流通知）
- 验证需求是否覆盖核心场景（如：正常流程、异常流程、边界场景）
- 示例：电商场景中，是否考虑“库存不足时取消订单”“支付超时自动退款”等场景？
业务流程图合理性：
根据用户故事构思出简单的流程图，各种路径之间的约束关系、执行条件是否有明确合理的定义。

业务流程图
- 根据用户故事构思出简单的流程图，各种路径之间的约束关系、执行条件是否有明确合理的定义。
  - 绘制流程图（泳道图/时序图），标注系统间交互节点
  - 检查路径约束（如：流程分支条件、状态跳转规则）
  - 示例流程：

结论先行：需明确系统边界，评估新方案对原有架构的侵入性。

系统边界清晰度：

系统类型	示例系统	接口协议	数据交互内容
内部系统	订单系统、库存系统	RPC（Dubbo）	订单创建、库存锁定
外部系统	支付宝、微信支付	HTTP/HTTPS	支付请求、回调通知

架构侵入性评估：
- 新方案是否需修改原有系统接口？（如：新增字段、调整协议）
- 是否引入新中间件？（如：新增MQ组件对现有架构的影响）
- 评估维度：代码改动量、部署复杂度、兼容性风险
  ⚠️ 反例：直接修改原有同步接口为异步调用（侵入性100%）；
  💡 最佳实践：通过MQ解耦（如订单系统发送消息至Kafka，支付系统消费消息），侵入性<20%。

梳理新流程是否有遗漏的外部系统需要改动。
- 调用第三方接口时是否设计 熔断/重试机制？
- 数据格式是否兼容历史系统？（如：旧系统返回XML，新系统需支持解析）
梳理已有的数据特性，检查新逻辑是否兼容所有类型的数据，包括历史数据。
接口设计是否合理
- 接口设计原则
  - 遵循 RESTful 规范（如：GET 查询/POST 创建/PUT 更新/DELETE 删除）
  - 响应结果标准化（统一错误码格式，如）：
```
{
  "code": "40001",
  "msg": "参数缺失"
}
```
设计是否能够通用
- 公共逻辑抽象为工具类/微服务（如：支付逻辑可独立为支付服务）
设计对原有系统侵入是否最小，是否做到充分解耦。

结论先行：需对全链路进行故障注入测试，重点解决消息队列核心问题。
假想每一个产生数据交换的环节失败

故障注入测试场景：

测试项	模拟方法	预期结果
MQ消息丢失	主动删除Kafka分区数据	生产者重试≤3次，消息不丢失
Redis缓存穿透	发送10w+无效user_id查询	布隆过滤器拦截率≥99.9%

消息队列健壮性方案：

Redis技术栈检查套路
架构测试，Redis容灾、数据穿透等原理
- Resdis是否考虑数据的主动刷新、数据穿透、容灾、数据全量恢复等问题。 --需要在设计初期就对这些情况进行计划

MQ丢消息、时序性等问题。（Kafka、ActiveMQ、RabbitMQ、RocketMQ）

几种常见的MQ总结对比: https://blog.youkuaiyun.com/anita9999/article/details/106981035/
- 测试方法：积压，统一放出来，查看时序性
task：任务防重措施、防漏措施、处理结果幂等性。
DB：普通索引合理性、唯一索引合理性、锁表问题、数据线程安全。
…