一、背景介绍
- 项目名称：呼叫中心
- 项目简介：高效挖掘价值客服，快速筛选意向客户，提高业务员的电话沟通效率，为企业赢得更多商机。
二、 业务介绍
产品主要分为两个部分：
*坐席可使用pc、app、webrtc 、sip 的方式进行登录，根据主管分配外呼名单进行外呼
*主管使用的后台管理系统，主要用途为配置坐席外呼码号，分配坐席外呼任务
三、 架构介绍
由端发起外呼，上行saas，运营商线路外呼
四、测试方案
测试痛点一：
需求迭代较快，每周三 周五都为发布日，需求验证完成后如果需求影响主通路还需要回归主通路功能，这里的主通路用例为20条，根据用例复杂度区分简单用例为1分钟一条，复杂用例为3分钟一条，总执行时间预计为20分钟左右，加上平台区分单个环境三个平台预计一小时，大大增加了测试工作量，导致发布时间较长。
解决方案：
根据筛选出的主通路功能用例转化为自动化用例，主通路用例中对环境进行了区分，方便运行不同环境的用例，因为有平台的区分，这里根据不同平台分别搭建了用例，在发布日通过手动构建的形式，对指定环境的主通路进行覆盖。
部署自动化回归后总体发布时长缩短，有影响平台的需求发布时，三个平台主通路接近三小时的验证时间目前缩短为30分钟。
代码结构部分
- 1, selnium封装与页面类存在至base层，采用Page Factory(页面工厂)+配置文件(yaml) → PageObject模式，读取data封装的页面元素提供方法至用例层进行调用。
- 2，用例层采用链式调用的方式执行用例，对用例进行了环境的区分，保证单个环境下用例的执行通过率，不会应测试数据的问题导致用例失败。
- 3，工具类，里面含有公共方法，比如文件读取，企微机器人调用，jenkins调用，黑名单元素处理
- 4，其他公共文件，如配置文件pytest.ini，conftest.py，requirements.txt
- 5, 采用jenkins进行持续集成
- 6, 构建时执行分环境分平台运行
jenkins配置
- 1， 采用参数形式指定运行环境与平台
- 2， 采用jenkins从节点运行，挂载windwos机器
- 3， 运行脚本与allure报告
最终效果
测试痛点二：
需求发布时可能存在接口方面的bug，从功能方面无法验证，大版本合流验证时需求对接口进行全面回归，人工回归耗时耗力，线上服务可能存在导致功能无法正常使用，出现运营问题。
解决方案：
部署接口自动化测试流水线，线上环境通过定期执行自动构建 实现自动巡检，根据用户的使用时间，这里的定期执行的具体策略为每日9-21点 执行间隔为5分钟一次，21-8点为20分钟一次，同时结合企微机器人发送构建结果，确保线上环境正常，针对于灰度与测试环境部署流水线采用手动构建的形式，保证大版本合流后环境接口正常。
代码结构部分
-
1, api层用于包含对requests封装，也是采用Page Factory(页面工厂)+配置文件(yaml) → PageObject模式，读取yaml封装的接口，提供方法至用例层进行调用。
-
2，用例层对用例进行了环境的区分，token鉴权采用 Fixtures进行调用，用例的前后置封装至conftest，为保证单个环境下用例的执行通过率，不会应测试数据的问题导致用例失败，这里也对环境进行了区分
-
3，工具类，里面含有公共方法，比如文件读取，企微机器人调用，jenkins调用，JsonSchema效验
-
4，其他公共文件，如配置文件pytest.ini，conftest.py，requirements.txt
-
5, 用例断言采用assert进行关键数据效验，结合jsonschema进行类型效验
-
6 采用jenkins进行持续集成
-
7, 构建时支持分环境运行，分模块 分级别
jenkins配置
效果
五、问题汇总
1.当前接口根据openapi文档接口进行录入，如何统计接口的覆盖率
2.当前接口框架类似po模式，对接口调用进行了封装，如何向平台转化
