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

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

需求评审：

需求评审问题示例：（业务角度）

序号	用户故事
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技术栈检查套路
是否存在锁表问题、数据线程安全。一当前读条件是否添加索引，共享数据争抢的逻辑是否加线程锁和分布
式锁。