测试流程注意事项

 

一 需求分析阶段

二 设计分析阶段

三 开发联调自测阶段

四 提测阶段

五 测试执行

六 上线阶段

七 运营阶段

 

 

一 需求分析阶段

 

1.业务修改

现有业务修改是否清晰 核心逻辑是否遗漏

有无业务冲突

 

2.用户体验和影响

交互是否合理

会不会拉长交易流程

干扰用户选择

下单和支付响应时长

 

3.周边业务线的影响 是否清晰描述上下游系统的影响

 

4.安全

黑白名单

反作弊

开关

规则和阈值

 

5.旧数据兼容

 

 

二 设计分析阶段

 

系统结构：

针对项目需求，结合业务现状来评估RD设计的系统修改点是否合理

模块、系统间使用了什么接口、中间件进行通讯（http、dubbo、mq、缓存、数据库、定时任务等），是否合理，例如dubbo循环依赖等

- 画出当前的系统结构图

- 标注出系统结构的改动点

 

数据流：

能不能拿到自己想要的数据，做出的修改是否会对现有系统造成负面影响，例如数据结构不兼容，缓存结构不兼容等

- 接口和接口字段的CUD（增、改、删）

- 数据存储的变化（表、字段）

 

三 开发联调自测阶段

 

1.根据需求和设计文档进行case设计和评审（后续自动化case同步进行？）

 

2.测试环境准备

分支 sql ng 权限配置等

 

3.跨团队项目的上下游沟通

 

测试计划沟通

和上下游模块沟通各自负责的测试计划安排、测试范围、测试重要场景、跨团队 测试数据的构造、配合的方式，把团队间的影响降到最低。

环境对接

我们需要了解上下游关系，相互之间接口的调用问题，接口是否沟通清楚，接口是否满足需求等，确保联调环境的进度。

熟悉业务

跨团队项目需要了解对方的业务、申请权限等，避免后续影响测试进度。

 

4.测试策略沟通

 

提测方式

核心功能的单元测试

测试工具提供（dubbo、定时任务封装http，异步转同步，后门工具等）

 

注：关注联调阶段出现的问题

在后面测试阶段有可能遇到的问题，绝大部分都会在这个阶段暴露，并对case进行补充

 

 

四 提测阶段

 

1.开发自测case执行,pm测试前置？

 

2.自动化通过

 

3.code review通过

 

4.code diff 前置？

 

1、为什么要code diff？

 

评估影响面

补充测试点

确认需求实现

提前发现问题

确认发布步骤

QA加深对技术实现的理解

 

2、何时进行code diff？

 

code diff 需要贯穿整个测试过程，主要是一下三个时间点。

提测时：得到本次代码的改动范围、使用branch代码与master代码全量diff

改bug后：确认开发代码的提交量、测试的回归量，使用修改前后打出的btag进行增量diff

发布前：确保本次发布的代码与测试代码一致，使用测试通过的btag与master代码全量diff

 

3、code diff关注点

 

接口变更

提供方，入参和返回值发生变化需要，确认所有调用方是否可以满足

调用方，调用新接口。需要注意是否添加异常处理？是否重试？超时时间是否合理？

 

代码层面

循环结构、递归调用，要检查退出条件，避免死循环

全局考虑代码实现是否与需求文档一致，功能是否都已经覆盖，条件分支结构，结合业务判断是否有遗漏分支；逻辑是否都是完整闭合的，注意边界值，条件判断语句参数为空是否发生空指针异常

运算表达式，需注意精度计算问题

针对复制了一段代码，确认业务逻辑

某个数据对象改了， 需要找到该数据对象被用在哪些地方，验证其展示、存储、对对外接口的影响；尤其考虑模块下游是否有影响，是否也应该做相应的变更。

基础类修改，要检查所有调用方，一层一层直到找到对应可进行验证的UI或系统功能，补充对应的功能测试点

缓存使用，补充测试点

有没有多改（搭车无关代码）,少改（少改方法、少改入口等等）？

 

配置相关

确认第三方服务的配置，包括dubbo、mq、地址、超时时间等

prod配置是否正确。包括被调用方的地址，数据库地址

beta的配置禁止使用的线上地址，反之亦然

pom.xml文件，版本号是否正确，线上不能有snapshot版本

 

监控

监控通常分为系统监控和业务监控，在diff时需要与开发和产品充分讨论哪些事件发生是需要技术/运营实时知道或每隔一段时间都需要了解状态的

系统监控：通常虚机提供时，无需在代码中添加

业务监控：通常在关键业务节点上添加，比如常见的接口调用次数、响应时长、任务成功/失败/异常监控

dubbo监控：需要在代码中添加dubboFilter对dubbo的调用进行监控（增加dubbo的Filter）

其他需求：通常不方便进行测试或线上验证的业务场景，可以考虑添加监控验证

 

日志

业务日志：一般在请求入参、出参处都要打印日志方便排查问题，线上日志需考虑性能相关问题（数据量、磁盘io问题、清理时间等）

异常日志：需要在diff过程明确catch住可能存在异常的部分，打出异常堆栈以及重要参数，注意空指针；如果是正常业务的异常分支，那么就需要有明确的业务输出或记录，而不是抛出exception

分级：日志分级别，调试使用debug，运行时日志使用info，系统遇到问题使用warn，系统遇到异常使用error

 

发布相关

第三方服务发布、以及权限申请

上线前发布依赖jar包不含snapshot

根据调用依赖关系，确认发布和回滚顺序

 

安全

日志、数据库、缓存中不允许出现身份证号、手机号等敏感信息

鉴权，是否需要再校验

 

异常

需要在diff过程明确catch住可能存在异常的部分，打出异常堆栈以及重要参数，注意空指针

如果是正常业务的异常分支，那么就需要有明确的业务输出或记录，而不是抛出exception

 

性能

代码中多重循环和if判断不要超过三次

获取大量数据时，分批次获取；尽量采用批量SQL语句

 

4、code diff产出

 

测试范围/checklist

bug

发布和回滚步骤

系统结构设计改进意见

 

 

五 测试执行

 

业务

1.检查工具或者抓包工具看接口

2.服务器日志

3.数据库和缓存变化

 

接口

方法：http postman等。 dubbo 业务覆盖、转http、单元测试、工具

 

测试点：

功能：

 

数据

类型

a. 类型使用是否正确（尤其是http接口）,例如使用String还是原始类型

b. 枚举的常量选项是否正确

精度

a. 是否符合要求，通常金额为2位小数

b. 得到的数据是否会自行调整精度(截断或者四舍五入不可取，应该直接校验传入的精度)

时间

a. 该使用日期(2015-11-12), 还是时间(2015-11-12 14:00:00), 还是时间戳(1449849600000)

b. 时区：服务器的日期是否会根据请求者的时区进行转换；或者在request中和response中直接带上时区信息

单位

a. 时间单位时秒还是毫秒

b. 金额单位是分还是元

 

长度 是否够长，超过部分是否截断还是发出警告

 

 

数据流

通过系统结构和数据流了解数据的流向、转换、落地等，考虑数据传递过程中的转换、封装、组装、数据丢弃、精度丢失等情况

1. 数据库到bean

2. bean处理后(例如，filter)向下层吐数

a. bean之间的转换

b. dubbo之间的传递

等等

 

接口异步和无序

对于一些依赖前后接口返回的逻辑，考虑接口异步、读写库时间差、读写接口时间差是否造成业务异常

 

兼容和影响

前后端兼容（字段变更、返回值变更、枚举等）

接口上下游兼容（包括外部系统的影响）

安全

权限

水平越界

垂直越界

敏感信息

 

mq消息

1.发送的mq消息内容是否正确

2.消费者是否成功

3.重复消费的幂等

4.消息无序

5.消息的积压

 

缓存

缓存的更新时机有哪些（task定时更新、MQ消息推送、业务操作触发、手动触发后门接口、重启应用加载等），是否存在未更新缓存时出现脏数据

缓存数据是否正确

缓存是否生效

缓存有效和失效时，业务是否正常

缓存的失效时间

缓存被击穿后的处理

内存缓存多部署机器的数据同步

缓存容量

缓存的命中率

 

 

性能

1.正常的性能测试

2.分析：从业务量估算接口的调用次数，通过上线前监控得到的接口访问次数、时间、服务器负载，分析本次上线增加的调用量是否有性能问题

 

定时任务

测试点无需过多阐述

需要考虑的点：

1.执行时间

2.被打断后，业务是否允许

 

 

六 上线阶段

 

过程中一般是开发观察日志、QA关注监控和业务数据

 

上线阶段一般考虑的点：

 

1.ng

2.sql（确保跟测试环境一致）

3.db redis 申请或者执行

4.洗数据脚本

5.topic申请

6.菜单/权限等配置

7.收权限 周知相关人等

8.接口或者机器白名单

9.机器权限 发布权限等

10.btag检查

11.模块发布步骤

12.验证步骤

13.回滚步骤

 

 

七 运营阶段

 

1.核心监控和报警（新上线业务 数据稳定后检查报警是否合理添加阈值）

2.日志、功能巡检或者邮件报警

3.问题反馈渠道

4.业务数据变化