接口测试流程 mail_企业接口测试流程分析（一）

接口测试流程 以企业微信分析为例

需求评审：

需求评审问题示例：(业务角度)

序号用户故事1添加一个部门2给一个部门添加子部门3修改子部门的相关信息4删除一个包含成员的部门5删除一个不包含成员的部门6删除一个不包含子部门的部门7删除一个包含子部门的部门8查询某部门下子部门的树状结构

用户故事整理出的需求问题：

1，添加部门信息是否包含父子关系

2，删除部门时是否校验包含了子部门

3，无部门查询功能 ---缺陷

需求评审问题示例：(交互角度)

得到的需求问题：

考勤异常系统个性化逻辑不应该放在企业微信平台中，应该是一套通用的开放接口

需求评审问题示例：(功能点角度)
1、数据约束。
添加的成员电话、邮件、是否可以重复。-需补充。
2、分支逻辑
添加员工后是否自动邀请该员工使用企业微信，邀请和不邀请逻辑是什么? -需明确。
3、权限相关
没有对各项操作的权限进行准确的说明。-需补充说明。

开发设计评审

ER图

​

接口文档评审

开发设计问题发现模型​

开发评审问题示例：(数据角度)

问题举例:
1、数据对象完整性。
成员对象缺少部门]负责人标识。--需调整表结构。
2、多余数据属性
在user表中存储这个用户所在群聊的list，用户与群聊的关系应该是chat数据对象要负责的关系,
user表存储了不属于自己的数据字段。--调整表结构。
3、字段的单一职责
定义一个字段即标识成员是否为部门门]负责人，又标识是否有踢出权限，则该字段违背了单一职责
原理，当想扩展为某些普通员工也能拥有踢人权利时，无法扩展。--增加一个单独的管理员标识。
4、字段二义性
定义一个字段，当用户登记手机号时存手机号，当没有手机号时存邮箱。一应该调整为两个字
.段，每介字段只负责存储一种数据

开发评审问题示例：(编辑角度)

问题举例: .
1、数据特性兼容。
有些企业，一个员工兼顾与几个部门，但是接口校验一个员工只能属于一个部门。--与产品沟通后放开限制。
2、功能的通用性
经过沟通，某企业希望部门中职务信息带“部长”后缀的自动识别为部门负责人。--不是所有企业 都遵循这一规律，此功能不通用，应该单独给定参数指定负责人。

开发评审问题示例：(特定技术栈)

问题举例:
1、Redis技术栈检查套路 。
Redis是否考虑数据的主动刷新、数据穿透、容灾、数据全量恢复等问题。--需在设计初期就对这些情况进行
计划。
2、MQ技术栈检查套路
MQ丢消息、时序性等问题。--循环推送和成功状态回写、接收消息回调获取最新消息。
3、Task技术栈检查套路
任务防重措施、防漏措施、处理结果幂等性。-首先要确定任务处理幂等性，调整合适的偏移量和执行频率。
4. DB技术栈检查套路
是否存在锁表问题、数据线程安全。一当前读条件是否添加索引，共享数据争抢的逻辑是否加线程锁和分布
式锁。

开发评审问题示例：(异常情况)

测试用例编写

基本流程测试

边界值测试

​

故障注入测试

线程安全测试​

​

线程安全的原理

什么是线程安全?

通俗的说，就是保证多个线程同时对某一对象进行操作时不会出错。比如两个客户端，同时对某个课程进行报名操作并记录总数，如果不加以并发控制，那么就会出现对当前报名总数脏读的情况。

分布式线程安全的原理

当服务器是分布式集群时，会产生一个问题，当多个订课请求打到不同的服务器上，而多个服务器对已定课程总数的读取过程中产生脏读的问题，就叫做分布式锁问题。

问题特征分析

线程安全性问题出现的三个必要条件:
1、多线程环境下
2、多个线程共享同一个资源
3、对资源进行非原子性操作

当多个线程同时对某一对象 当多个线程同时对某一对象进行读写操作时，比如读减 进行读写操作时，比如读减库存，排重写入逻辑需要注 库存，排重写入逻辑需要注意线程安全和分布式锁问 意线程安全和分布式锁问题，

需要对读写操作进行一 题，需要对读写操作进行一个分布式的并发场景测试。

数据库锁原理

1、表锁定:更新/删除操作会添加排它锁。此类操作的
where条件如果未添加索引|会升级为表级锁定，导致其他逻
辑对该表的操作失败。2、事务中死锁:两个事务都持有对方需要的锁，并且在
等待对方释放，并且双方都不会释放自己的锁。

当多个逻辑同时处理某个表的数据时，需要考虑这些逻辑并行处理的场景。