测试策略:测试对象分析和测试保障的思考

测试对象分析

在测试范围评估的过程中,有个很重要的问题:这个需求,我们要测试什么。其中有很大一部分是要需要分析这个需求的测试对象有哪些
我自己梳理了一份,大家可以参考下:

代码

前端
组件样式
操作交互
数据展示

后端
业务逻辑
定时任务
异步任务/多线程

数据

历史数据
缓存数据

中间件

消息中间件(消息队列)
缓存中间件(缓存效果、ES)
网络负载中间件
(并不是需要测试中间件自身能力,而是在业务中使用的方式方法是否正常)

配置

业务数据配置(例如全局环境变量之类的)
JVM配置

部署环境

后端服务部署方式(单机、微服务)
前端环境(操作系统、浏览器、移动端)

外部服务对接

我依赖别人的(OSS、算法服务、三方服务)
我提供出去的(对外HTTP接口、RPC服务)


在切换环境的时候,我们到底要关注什么呢?

从测试到预发

我们公司的测试环境和预发环境是完全隔离开的,区分的数据库、中间件、部署环境。
所以在这次切换时,除了代码以外:

  • 配置项/数据/中间件等相关的验证都是要做的
  • 外部服务这里可以暂不关注,但要提前注意一点,预发环境是否有对应外部服务

预发到生产

预发环境和生产环境之间,数据库是相通的(包括历史数据、新增数据和缓存数据),但是部署集群、中间件实例、配置项都是单独的。
所以除了代码bug外,要着重测试下

  • 配置项涉及的功能是否正确
  • 消息队列、oss地址等涉及到的功能是否正确
  • 和外部服务之间的交互部分

生产的稳定性保障

需要思考的两个个问题:
我们测试过的,发布上线的应用,运行过程中可能会有哪些问题?
我们的线上探针到底能捕获到什么原因导致的异常?

在我们线上环境没有发布的前提下:
代码:不变
数据:逐渐增多
中间件:逻辑不变,队列数据动态变化
配置:默认无人改动
部署环境:不变
外部服务:依赖服务稳定性不可知

可以看到,线上探针可能会捕获到的变化主要是

  • 存量数据变多,可能会有性能问题
  • 缓存数据实时变化,关注服务本身状态,防止内存溢出
  • 队列数据实时变化,防止队列过长导致的任务堵塞
  • 外部服务可能不可用或者响应慢
  • 和其他应用公用的基础服务、中间件、数据库,被其他服务搞的不稳定了
  • 某个偶现问题导致的基础服务、中间件、数据库不可用

了解这些原因后,我们再针对性的设计探针脚本,会效果好很多。遇到线上故障的时候,也可以优先从这几个角度去排查

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值