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

测试对象分析

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

代码

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

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

数据

历史数据
缓存数据
​

中间件

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

配置

业务数据配置（例如全局环境变量之类的）
JVM配置
​

部署环境

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

外部服务对接

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

---

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

从测试到预发

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

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

​

预发到生产

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

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

​

生产的稳定性保障

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

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

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

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

​

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