毕业设计-呼叫中心项目测试方案

一、背景介绍

  • 项目名称:呼叫中心
  • 项目简介:高效挖掘价值客服,快速筛选意向客户,提高业务员的电话沟通效率,为企业赢得更多商机。

二、 业务介绍

产品主要分为两个部分:
*坐席可使用pc、app、webrtc 、sip 的方式进行登录,根据主管分配外呼名单进行外呼
*主管使用的后台管理系统,主要用途为配置坐席外呼码号,分配坐席外呼任务

三、 架构介绍

由端发起外呼,上行saas,运营商线路外呼
image

四、测试方案

测试痛点一:

需求迭代较快,每周三 周五都为发布日,需求验证完成后如果需求影响主通路还需要回归主通路功能,这里的主通路用例为20条,根据用例复杂度区分简单用例为1分钟一条,复杂用例为3分钟一条,总执行时间预计为20分钟左右,加上平台区分单个环境三个平台预计一小时,大大增加了测试工作量,导致发布时间较长。

解决方案:

根据筛选出的主通路功能用例转化为自动化用例,主通路用例中对环境进行了区分,方便运行不同环境的用例,因为有平台的区分,这里根据不同平台分别搭建了用例,在发布日通过手动构建的形式,对指定环境的主通路进行覆盖。
部署自动化回归后总体发布时长缩短,有影响平台的需求发布时,三个平台主通路接近三小时的验证时间目前缩短为30分钟。

代码结构部分

image

  • 1, selnium封装与页面类存在至base层,采用Page Factory(页面工厂)+配置文件(yaml) → PageObject模式,读取data封装的页面元素提供方法至用例层进行调用。
  • 2,用例层采用链式调用的方式执行用例,对用例进行了环境的区分,保证单个环境下用例的执行通过率,不会应测试数据的问题导致用例失败。
  • 3,工具类,里面含有公共方法,比如文件读取,企微机器人调用,jenkins调用,黑名单元素处理
  • 4,其他公共文件,如配置文件pytest.ini,conftest.py,requirements.txt
  • 5, 采用jenkins进行持续集成
  • 6, 构建时执行分环境分平台运行
jenkins配置
  • 1, 采用参数形式指定运行环境与平台
    image
  • 2, 采用jenkins从节点运行,挂载windwos机器
    image
  • 3, 运行脚本与allure报告
    image
最终效果


image

测试痛点二:

需求发布时可能存在接口方面的bug,从功能方面无法验证,大版本合流验证时需求对接口进行全面回归,人工回归耗时耗力,线上服务可能存在导致功能无法正常使用,出现运营问题。

解决方案:

部署接口自动化测试流水线,线上环境通过定期执行自动构建 实现自动巡检,根据用户的使用时间,这里的定期执行的具体策略为每日9-21点 执行间隔为5分钟一次,21-8点为20分钟一次,同时结合企微机器人发送构建结果,确保线上环境正常,针对于灰度与测试环境部署流水线采用手动构建的形式,保证大版本合流后环境接口正常。

代码结构部分

image

  • 1, api层用于包含对requests封装,也是采用Page Factory(页面工厂)+配置文件(yaml) → PageObject模式,读取yaml封装的接口,提供方法至用例层进行调用。

  • 2,用例层对用例进行了环境的区分,token鉴权采用 Fixtures进行调用,用例的前后置封装至conftest,为保证单个环境下用例的执行通过率,不会应测试数据的问题导致用例失败,这里也对环境进行了区分


    image

  • 3,工具类,里面含有公共方法,比如文件读取,企微机器人调用,jenkins调用,JsonSchema效验

  • 4,其他公共文件,如配置文件pytest.ini,conftest.py,requirements.txt

  • 5, 用例断言采用assert进行关键数据效验,结合jsonschema进行类型效验

  • 6 采用jenkins进行持续集成

  • 7, 构建时支持分环境运行,分模块 分级别

jenkins配置

image
image
image

效果

image

五、问题汇总
1.当前接口根据openapi文档接口进行录入,如何统计接口的覆盖率
2.当前接口框架类似po模式,对接口调用进行了封装,如何向平台转化