思考：🤔
如何保证房屋建筑的质量
如何保证汽车的质量
各环节 各组件 各资源 端到端
功能性和非功能性
功能性 可靠 易用 效率性能 灵活性 可测 可维护 互用 安全
基于风险的测试
BDD
1. 业务逻辑:
1.1 通用判断
数据结构 字段交互 枚举类型 数据取值 鲁棒性/健壮性 完整性 幂等性 异常结构
a、数据结构 -> 边界值、每层数据是否判空、必传参数
b、数据结构(不完整) -> 参数字段不完整或者value为空时，取值是否保护？或者影响其它逻辑，比如重新请求是否会陷入死循环
c、数据结构 -> 判断条件下字段影响逻辑
d、数据结构扩展性
1.2 存储数据类型 -> 安全性 性能
a、 Maps.newHashMap()
b、Sets.newHashSet()
c、Lists.newArrayList()
......
1.3 数据获取/下发:
a、构造请求参数
b、上下游数据
c、数据判空、数据完整性、数据联调
d、多种交互数据结构是否具备鲁棒性 数据结构是否存在转义情况，数据结构联调是否完整
e、所有下发数据包装，配置逻辑穿插、排序、置顶....
f、前端根据后台下发code值，判断状态或者身份。关注code值改动
g、外部系统可用性
1.4 逻辑之间相互依赖影响 商品N种状态或者期它内容状态形式
1.5 是否存在重复判断
1.6 多路径 多状态的数据处理，清空/保存、穿插、排序....
1.7 状态逻辑复杂 数据结构复杂 判断条件复杂 逻辑判断是否合理
1.8 新增业务逻辑位置，是否对既有逻辑判断产生影响
1.9 数据存储是否合理，数据量是否会爆炸式增长
其他复杂，嵌套过深的业务逻辑等等....
了解业务模式，业务形态，业务组成，业务趋势
2. 异步场景 事件编排 异步任务 超时设置 线程池+Future ListenableFuture
3. 缓存策略、兜底数据 缓存key的约束设置 重置缓存的策略 缓存时间 缓存key的更新(多个用户，多个key，值应该不同)，分片机制 参考redis常见问题以及策略
缓存存储，不合理或者不完整数据进入缓存，下游判断数据完整性，如果数据不完整再次请求，有可能造成死循环
4. 各种开关配置数据，日志开关、数据开关(下发/不下发)、降级开关、过滤/排序开关、兜底开关、比例配置数据，A/BTest，版本控制......
5. mq同步机制 ：是否存在数据大量堆积返回 队列，推挤导致部分业务还未处理(如满减的减)
6. 埋点数据拼接下发
7. 监控合理性，监控日志上传是否会阻塞业务的调用
8. 复用模块是否抽出，非业务通用逻辑是否抽出制成模版，
9. 结构是否抽象(面向接口，AOP)，耦合度是否过高
10. 线程池配比是否合理 队列设置策略
11. 环境配置部署
12. 降级熔断限流机制是否完善
13. 分布式场景
14. 配置文件(jar包，配置文件),发布，每台机器都应发布，否则在分布式场景下，可能有些机子还是老逻辑
15.是否满足业务需求
16. 是否满足某些设计模式
以上内容是根据当前工作中业务代码的梳理(基于某些环境配置正常，业务逻辑按需实现无删减)，抽取出的相似相近模块点，只考虑了业务的单向性以及单系统状态，未考虑性能以及高并发场景下的设计(如数据量过大，计算逻辑过于沉杂 FGC 、cpu。。。)，具体测试点，需求实现的完整性、合理性还是要根据产品特性以及系统结构以此来制定测试计划，并且可持续性完善
domain层
关注表结构设计的合理性，是否具备可扩展性
字段 -> 字段类型
- 扩展字段表 -> 扩展详细信息表
- 多用户及权限管理的设计
https://blog.csdn.net/jack__frost/article/details/72672252
dao层
实现组件，实现结构
redis es mysql
故障注入
需求的合理性 完善性 可持续性
不同阶段有不同的关注点，不同的策略，明确产品处于生命周期哪一阶段
了解产品的形态， 功能交互只是与用户交互的具体细节逻辑 ，系统是维持着整个产品输出的发动机
测试计划
数据流转，数据形态
网友评论