灵活 敏捷 迭代。
自动化测试 辩思
测试必不可少
想想看没有充分测试的代码, 哪一次是一次过的? 哪一次不需要经历下测试的鞭挞? 不要以为软件代码容易改, 就对于质量不切实际的自信—那是自大!
不适用自动化测试的case
- 遗留系统。
- 太多的依赖方, 不想用过多的mock => 逻辑核心能力就是那些不容易测试的
- 大量依赖 第三方商业服务、自己的rpc服务/http服务
- IO 操作密集的
- (注意) 容易测试的一般是 无状态的(无IO状态的), 就内存中存储了状态
- 对应的代码在线上的时间比较短, 属于实验性代码。
- 越是早期, 自动化测试的必要性就越弱。靠手工测试就可以支持一定水平的质量。
无自动化测试系统设计方法论
这一切都需要 一点代价, 但是相对于 单元测试来说, 代价还是轻微很多。
无自动化测试, 也要关注可测试
- 模块、组件间的边界情况
- 使用 “谦虚对象” 设计模式来隔离可测试和不可测试的领域, 划定边界。
划分边界 注意耦合关系
需要更审慎的对对应的模块做足够的前置思考:
- 重写的风险增大了 必不可少, 重构的能力了大大降低了!
常见的分层边界有 GUI层、 逻辑层 、网络层…
- 如果逻辑层代码比较复杂, 那么可以将逻辑层代码单独摘离出来进行测试
- GUI 层可以拆分 容易测试的部分和不容易测试的部分==> by “谦虚对象”
模块测试
落地到具体的测试行为上, 还是按模块测试比较好。
使用测试api
更多参考: 架构敏捷之道 P220
在自动化测试工作流里: 如果测试架构设计不好、测试代码和生产代码耦合过高的话, 可能出现脆弱的测试。修改一个api需要修改大量的测试代码。
如果使用无自动化支持， 那么测试API必不可少。类似于一个超管API，能够跳过各种权限验证、逻辑验证, 直达核心逻辑。
用 测试API 和 合理的mock能力 来更灵活的撬动 软件质量
- 对于IO密集型应用 需要的测试API能力:
- clear : 清除 所有的缓存影响
- remove : 删除指定影响、删除指定字段
- set(指定值) : 给指定值设置状态
- get(查询): 查询指定值
- 环境隔离:
- 测试API甚至需要运行时隔离 乃至 编译器隔离，避免污染线上环境。
简短 手动测试 反馈时间
哪怕是手动测试, 也需要注意测试反馈时间。
影响程序员的效率的两大因素: 调试和验证反馈时长。
- 足够的测试大大减少调试的次数
- 验证反馈时长缩短, 每个小迭代反馈都更容易、效率更高。
必要情况下 使用自动化测试
自动化测试有代价, 对于不爱写测试的同学需要重视测试, 对于狂热的TDD爱好者, 也要警醒测试代码也是需要花费人力的。
对于经常出现问题的、非IO密集型的逻辑, 可以使用自动化测试来防御之后可能导致的问题。
- 频繁出现问题的区域, 使用自动化手段防御 ROI很高
- IO密集型的逻辑, 本质上复杂性和风险都在依赖的IO组件方—无论是文件还是数据库, 都是更为稳定、健壮的代码。
覆盖率不一定要很高, 但是验收测试要通过。一般来说冒烟测试是最基本的。
让表现结果 明显 可视化
- 错误的路径 异常日志打出来,
- 正确的路径 可以日志 绿色高亮
- 可以使用 侵入式的 Assert 临时代码
- 更为认真的撰写日志, 能够容易的阅读出 对应的流程
- 日志可以关注下 关键字, 和 验收注释 里面的关键字对应
- 可以用 关键字起头 => 扩展下: 越明显的单词越先出现
框架? 和框架耦合的代码要薄薄的
如果和框架过度耦合的代码很多, 那么测试就必须依赖框架的行为。
这时候想要就某个模块进行测试就比较难。例如 高度使用springboot框架的 @resource
编码工作步骤
- 主要逻辑 用 日志填充。
- 逐步更换为 具体的 IO调用。
- 集成测试
- 增加埋点
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
