根据业务发展需要，按照宁波银行股份有限公司采购相关管理办法，我行拟对《测试管理平台2025年能力提升项目》面向社会公开征集供应商，诚邀符合条件的供应商参与方案洽谈。

一、资质要求

1、注册资金人民币200万元（含）以上，财务状况良好；

2、公司经营正常并存续2年（含）以上；

3、企业或者其法人近两年内无行贿犯罪记录，未被列入失信执行人名单，无限制高消费、限制出入境等行为；

4、公司具备完善的组织架构和制度规范，拥有充足的技术、人员和设备资源；

5、同一法定代表人的两个及两个以上法人、母公司、全资子公司及其控股公司不得在同一次项目中参加报名；

6、参与报名的供应商能作为签约主体参与后期的商务流程；

7、设备和产品应满足《网络安全法》等法律法规要求；

8、报名供应商应符合宁波银行供应商管理相关要求；

9、如报名供应商为首次与我行合作供应商，请按附件格式提供“供应商尽职调查报告”。

二、技术要求

1、供应商需具测试管理相关项目建设经验，拥有同业测试管理平台相关项目实施案例；

2、供应商需具备较强的测试管理类系统的建设能力，具备测试管理平台相关项目完成案例，技术方案具有较强的前瞻性和可落地性；

3、供应商具备系统集成能力，支持按照行方框架进行研发，能支持个性化需求，并能提供完备完全的解决方案，且具备较强的架构设计能力，能够完成强复用性的业务组件设计；

4、供应商产品或方案必须符合我行技术规范准入要求，能适配我行的平台建设策略、接口设计标准，兼容性强，能满足行内功能性或安全性等非功能性上的要求；

5、供应商需具备一定技术沉淀，对常用的基础框架或引擎有完善的集成解决方案，并具备二开的能力；

6、供应商产品或方案必须覆盖监管相关发文要求；

7、公司持有CMMI评估认证、IOS体系认证、TMMI二级以上认证；

9、供应商中标后应有足够人力立即投入研发，保障部署上线的及时性；

10、供应商同意本次项目开发所形成的相关成果，包括应用系统和技术文档归属我行，我行是该成果的著作权、专利申请权、专利权、技术秘密及其其他相关知识产权的所有人。

11、公司拟参与项目人员必须通过宁波银行面试，人员面试不合格的公司不予准入。

三、报名方式及起始时间

请符合条件的供应商在2025年4月4日之前,通过报名链接“点击报名”方式进行报名，报名链接如下：https://cpms.nbcb.com.cn/cpms/ananymous/cms/，并按要求填写相关报名材料。

四、联系方式

联系人：张学辉 0574-83050673（采购部）

陆燕怡 13588031254（科技部）

刘晓慧 18392527160 （业务部）

测试管理平台2025年能力提升项目主要需求概述

2.项目需求2.1监管和审计类平台改造2.2.1案例评审流程整改

1. 案例评审发起增加控制，控制逻辑：

仅冒烟/系统/版本测试下所有测试任务为【执行完成】或【已终止】 且 测试计划下有报告状态为生成成功的总体报告，不能发起三方线上线下评审，组内评审还能发起； 控制范围：仅总行的系统且非特定业务意向下的计划；

不符合要求点击按钮（案例评审按钮、批量案例评审按钮和草稿中的待评审按钮、退回评审的待评审按钮）时，提示："存在属于总行系统且冒烟/系统/版本测试下所有测试任务为【执行完成】或【已终止】 且 测试计划下有报告状态为生成成功的总体报告，不能发起三方线上线下评审。"；

单个和批量案例评审均控制，批量的时候只要选择的一个计划属于总行的系统就会进行强控，其中一个属于总行的计划下冒烟/系统/版本测试的所有测试任务为【执行完成】或【已终止】且测试计划下有报告状态为生成成功的总体报告就进行强控；

2.总体报告生成按钮修改

【仅总行系统进行控制】【非特定业务意向用于回归的】的总体报告的【生成报告】按钮校验：计划下的所有三方线上/线下案例评审流程需为已通过/已关闭/未通过/草稿中（撤回是已关闭），不能为待评审 。组内评审不校验。且至少包含一个已通过的三方线上/线下评审。且，如果有未通过的三方评审，其后必须有一个已通过的三方评审(未通过评审的点未通过的时间<=已通过评审的评审所有人通过时间，即，第一个未通过的时间<=最后一个人通过的时间)；没有的话，提示：当前计划下需要有已通过的三方线上/线下案例评审且未通过的三方线上/线下案例评审需重新发起至通过，因此无法生成总体报告；

总体报告生成按钮后面加一个问号提示：

（1）仅测试小组长，测试负责人，测试助理 ，可以生成总体报告；

（2）仅冒烟，系统，版本测试下所有测试任务为【执行完成】或【已终止】， 才可以生成总体报告，没有测试任务的也无法生成；

（3）计划下所有的三方线上/线下案例评审均为已通过/已关闭/未通过/草稿中，且至少有一条已通过的三方线上/线下评审，且未通过的三方线上/线下评审需重新发起至通过；

3. 测试计划-总体报告，仅总行的系统且非特定业务意向下的测试计划，点击生成报告按钮时增加信息确认弹窗【绿色的部分为新增的逻辑】：

若无高危投产风险，弹窗提示：若【生成总体报告成功】且【冒烟/系统/版本测试下所有测试任务都执行完成或已终止】后，测试计划下不再允许发起三方线上/线下案例评审！请确认是否生成总体报告？ 【取消】：关闭弹窗，【确认】：生成总体报告，关闭弹窗；

如有高危投产风险，进行二次弹窗确认，弹窗内容：报告中存在高危投产风险内容，故事上线时会升级相关经理审批，请先和组长及测试分管经理进行确认，谨慎填写！【其中谨慎填写四个字为红色】 【取消】 【继续生成】

点击继续生成后，弹窗二次确认弹窗，弹窗提示：若【生成总体报告成功】且【冒烟/系统/版本测试下所有测试任务都执行完成或已终止】，测试计划下不再允许发起三方线上/线下案例评审！请确认是否生成总体报告？ 【取消】：关闭弹窗，【确认】：生成总体报告，关闭弹窗。

2.2.2案例类型、正反案例比规范执行整改

1.测试设计-手工案例新增字段 【案例分类】

批量编辑/案例详情内编辑，数据列表，新增字段【案例分类】；

首页/ 案例推荐/案例分配，新增查询字段【案例分类】；数据列表，新增字段【案例分类】；

案例入库页面，新增【案例分类】字段；

测试执行-手工案例，首页/分配-测试设计/分配-案例管理，数据列表，新增字段【案例分类】；

测试执行-手工案例详情页新增字段【案例分类】；

测试设计-手工案例，新增按钮弹窗，新增字段【案例分类】；

测试设计-手工案例，导入的模板变更，新增字段【案例分类】；

	选项	含义
案例类型	界面	界面要素检查，包括界面组件、文字、控件等页面元素显示是否正常，页面排版显示是否正常
功能	验证单一业务动作是否正确处理。常见的业务动作有：办理、新增、申请、撤销、审批、确认、查询等。
流程	验证多个业务动作按序执行后，是否正确实现某业务流程，侧重于界面的跳转、业务场景的串联
报表类	验证报表数据计算及展示是否正确
批处理类	涉及运行批处理的流程案例
定时器类	涉及运行定时程序的流程案例
案例分类	联机	测试系统业务功能、系统间报文交互的案例
批量	测试批量执行或定时执行的案例，如：日终对账、定时/延时清算、批量文件处理
异常	测试代码中异常场景处理的案例，如：超时、网络异常

2.资产库新增字段 【案例分类】

资产库（总库，回归库，关联库，关键库，风险库），新增查询字段【案例分类】；

资产库（总库，回归库，关联库，关键库，风险库），批量编辑/案例详情内编辑，新增【案例分类】字段，有悬浮提示，必填项；

资产库（总库，回归库，关联库，关键库，风险库），新增按钮弹窗，新增【案例分类】字段，有悬浮提示，必填项；

资产库（总库，回归库，关联库，关键库，风险库） ，导入的模板变更，新增字段【案例类】，填写的话进行当前分类合法值校验；

资产库（总库，回归库，关联库，关键库，风险库） ，新增一个字段【案例分类 】，默认不隐藏，案例类型默隐藏，可以勾选放开；

3.项目级管理-案例管理新增字段 【案例分类】

项目级管理-案例管理，新增查询字段【案例分类】；数据列表，【案例分类 】，默认不隐藏，案例类型默认隐藏，可以勾选放开；

项目级管理-案例管理 ，新增按钮弹窗，新增【案例分类 】字段，有悬浮提示，必填项；

项目级管理-案例管理 ，导入模板变更，新增字段【案例分类】，必填，填写的话进行当前分类合法值校验；

普通导入/ 无效案例导入模板变更；

项目级管理-案例管理 ，批量编辑/案例详情编辑，新增【案例分类】字段，有悬浮提示，必填项；

4.奋进号测试信息-测试案例跳转链接，数据列表，新增【案例分类】，默认不隐藏，案例类型默认隐藏，可以勾选放开；查询条件增加案例分类；

5.【案例分类】数据初始化，刷数规则如下：批处理类、定时器类刷为批量，界面、流程、功能、报表类刷为联机

6.根据案例类型整改：新增案例分类的，相应的对正反案例比的强控进行调整；校验sit阶段下的所有的测试任务下的案例（剔除废弃案例），联机类的案例反案例与正案例的比大于等于1:4；

2.2.3覆盖非计划和补丁回归测试

测管支持非计划和补丁回归测试，具体内容

1.自动创建自建项目并分配案例任务

增加接口，定时对新增的非计划和补丁的某一个上线日期的自建项目，并增加系统信息，如果已经存在直接复用，自动评估通过，通过的参数部分配置部分直接获取；增加回归测试轮次，参数默认或者自动获取；添加执行人；此流程加锁，保证不会重复操作；后续需要将该系统中的回归库案例全部引入并分配执行人；分配分场景，根据案例等级自动分配。

2.支持提交缺陷

支持手工/接口/UI案例关联缺陷，新增测试缺陷，新增生产缺陷，并关联案例与缺陷的信息。支持批量提交，单条提交；

3.自动化报表分析

针对非计划和补丁的回归测试按照版本出报表进行分析，包括实时查询，数据归档，跑批查询，导出

版本

系统

测试小组

测试部门

测试人员

类型

执行案例数

案例等级

成功率

缺陷个数

缺陷所在系统

缺陷发现系统

缺陷基础信息解析

缺陷编号

4.总体报告

总体报告简报，支持快速截图，包括指标执行用例数、成功案例数、失败用例数、成功率、缺陷总数、缺陷状态、测试分析

总体报告完整，支持导出，包括指标测试基础信息，回归库覆盖率，未覆盖案例数，案例执行通过率，缺陷数据，截图未截数据等

总体报告的明细数据，包括未覆盖案例明细，案例回归明细（回归方式，回归人），缺陷清单（缺陷编号，缺陷名称，缺陷基础内容），截图未截案例信息（案例编号，回归人，部门/全部未截）

2.2.4待办流程完善

当前平台的待办流程不完善，需要增加退回和授权功能，以方便用户按需使用，具体流程如下：

验收通知	备注
案例执行检查	增加手机工作平台待办通知
未测风险提醒	-
回归测试确认	增加手机工作平台待办通知
案例入库	-
风险入库	-
标签入库	-
案例评审	增加手机工作平台待办通知
案例管理	-
案例变动评审	增加手机工作平台待办通知
自动化案例删除	-
接口自动化案例需求	-
接口自动化案例入库	-
UI自动化案例需求	-
UI自动化案例入库	-
自建项目	-
知识评审	-
预警确认	增加手机工作平台待办通知

2.2测管集团化改造2.2.1测试流程集团化

当前测试流程仅针对测试中心的人员定制，因此要适配集团化的用户使用，需要针对流程和控制做黑白名单，保证整个集团的用户可顺畅使用测管进行测试。

类型	内容
校验	测试任务创建
校验	案例分配
校验	案例推荐
校验	案例执行
校验	执行完成
校验	门禁控制
校验	正反案例比校验
校验	截图未上传校验
校验	执行完成流程校验
流程	案例变动评审
流程	案例评审强控
流程	总体报告强控
流程	入库流程
流程	执行完成后通知
流程	不登记缺陷原因必填
流程	回归库修改后通知自动化人员
流程	是否已替代等字段必填项
数据	特殊场景数据不可见调整

2.2.2 测试数据隔离

集团化用户使用时，为保证测试数据安全合规，需要进行总子分行的区分隔离，包括两大模块的数据，包括测试执行过程数据，以及资产库的数据。

测试进度（3个报表）	类型
驾驶舱（4个报表）	报表
缺陷统计报表（2个报表）	报表
指标预警视图（（17个指标，2个项目维度，3个人员维度））	报表
案例执行检查（2个报表）	报表
qa报表（7个报表）	报表
覆盖率报表（4个报表）	报表
测试规范（2个报表）	报表
案例库使用情况（1个报表）	报表
指标预警（17个指标，2个项目维度，3个人员维度）	报表
覆盖率接入（1个报表）	报表
人员画像（1个主报表）	报表
上线信心	报表
全系统回归报告	报表
单系统回归报告	报表
缺陷清单	报表
替代率报表	报表
测试计划	测试数据
测试设计	测试数据
测试任务	测试数据
案例管理	测试数据
执行管理	测试数据
缺陷管理	测试数据
资产库-手工案例库	测试数据
资产库-自动化案例库	测试数据
资产库-统一案例视图	测试数据
资产库-设备库	测试数据
资产库-标签树	测试数据
资产库-风险点库	测试数据

2.2.3 报表数据集团化

当前报表只针对测试中心或者总行，没有完全的集团化，需要针对报表的查询范围，定时任务的跑批范围，查询条件的范围进行开放，功能清单如下：

测试进度（3个报表）
驾驶舱（4个报表）
缺陷统计报表（2个报表）
指标预警视图（（17个指标，2个项目维度，3个人员维度））
案例执行检查（2个报表）
qa报表（7个报表）
覆盖率报表（4个报表）
测试规范（2个报表）
案例库使用情况（1个报表）
指标预警（17个指标，2个项目维度，3个人员维度）
覆盖率接入（1个报表）
人员画像（1个主报表）
上线信心
全系统回归报告
单系统回归报告
缺陷清单
替代率报表

2.2.4 角色和权限配置

当前角色配置不够灵活，角色不可以控制菜单权限以及按钮权限，整改实现角色灵活分配菜单和按钮权限；

一级菜单	二级菜单	三级菜单	预期	页面的按钮	预备哪些角色可见
个人工作台			按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
版本管理			按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
测试管理	需求分析		按照用户所在的角色的权限控制是否可见	查询、分配、删除等	默认角色等所有角色可见
测试计划		按照用户所在的角色的权限控制是否可见	查询、编辑、报告生成等	默认角色等所有角色可见
测试设计		按照用户所在的角色的权限控制是否可见	查询、导入、新增、编辑、入库、分配、推荐等	默认角色等所有角色可见
测试执行		按照用户所在的角色的权限控制是否可见	查询、分配、编辑、执行、检查等	默认角色等所有角色可见
项目级测试管理	案例管理		按照用户所在的角色的权限控制是否可见	查询、导入、新增、编辑等	默认角色等所有角色可见
执行管理		按照用户所在的角色的权限控制是否可见	查询、分配、编辑、执行、检查等	默认角色等所有角色可见
缺陷管理		按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
自动化管理	自动化报表	替代率报表	按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
全系统回归报告	按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
单系统回归报告	按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
全系统回归缺陷清单	按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
自动化需求		按照用户所在的角色的权限控制是否可见	查询、新建、执行等	默认角色等所有角色可见
定时任务		按照用户所在的角色的权限控制是否可见	查询、新建、执行等	默认角色等所有角色可见
错误规则库		按照用户所在的角色的权限控制是否可见	查询、新建、删除等	默认角色等所有角色可见
执行器监控		按照用户所在的角色的权限控制是否可见	查询、终止等	超级管理员，测管运维人员
资产管理	案例库	总库	按照用户所在的角色的权限控制是否可见	查询、新增、编辑、删除等	默认角色等所有角色可见
关键库	按照用户所在的角色的权限控制是否可见	查询、新增、编辑、删除等	默认角色等所有角色可见
回归库	按照用户所在的角色的权限控制是否可见	查询、新增、编辑、删除等	默认角色等所有角色可见
风险库	按照用户所在的角色的权限控制是否可见	查询、新增、编辑、删除等	默认角色等所有角色可见
关联库	按照用户所在的角色的权限控制是否可见	查询、新增、编辑、删除等	默认角色等所有角色可见
接口自动化	按照用户所在的角色的权限控制是否可见	查询、新增、编辑、删除等	默认角色等所有角色可见
UI自动化	按照用户所在的角色的权限控制是否可见	查询、新增、编辑、删除等	默认角色等所有角色可见
案例库统一视图		按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
风险点库		按照用户所在的角色的权限控制是否可见	所有人	默认角色等所有角色可见
标签树		按照用户所在的角色的权限控制是否可见	查询、新增、编辑、删除等	默认角色等所有角色可见
设备库		按照用户所在的角色的权限控制是否可见	查询、新增、编辑、删除、借出、归还等	默认角色等所有角色可见
知识库		按照用户所在的角色的权限控制是否可见	查询、新增、编辑、删除等	默认角色等所有角色可见
人员画像	人员画像		按照用户所在的角色的权限控制是否可见	查询、新增、编辑、删除等	默认角色等所有角色可见
培训管理		按照用户所在的角色的权限控制是否可见	查询、新增、编辑、删除等	培训管理员，超级管理员，测管运维人员
测试看板	驾驶舱		按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
测试进度		按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
缺陷统计报表		按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
指标预警视图		按照用户所在的角色的权限控制是否可见	查询、编辑	默认角色等所有角色可见
人力预估		按照用户所在的角色的权限控制是否可见	查询、编辑	默认角色等所有角色可见
案例执行检查登记簿		按照用户所在的角色的权限控制是否可见	查询、复核等	默认角色等所有角色可见
QA报表		按照用户所在的角色的权限控制是否可见	查询	QA，超级管理员，测管运维人员
p类项目测试简报		按照用户所在的角色的权限控制是否可见	查询、配置等	默认角色等所有角色可见
覆盖率报表		按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
测试规范	门禁检查	按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
案例检查	按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
TMMI质量评价	配置管理	上线信心	按照用户所在的角色的权限控制是否可见	查询、编辑等	超级管理员，测管运维人员
上线信心		按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
第三方平台	覆盖率平台		按照用户所在的角色的权限控制是否可见	跳转	默认角色等所有角色可见
数据洞察平台		按照用户所在的角色的权限控制是否可见	跳转	默认角色等所有角色可见
系统管理	角色管理		按照用户所在的角色的权限控制是否可见	新增、删除、编辑等	超级管理员，测管运维人员
反馈记录		按照用户所在的角色的权限控制是否可见	新增、删除、编辑等	默认角色等所有角色可见
定时任务		按照用户所在的角色的权限控制是否可见	新增、删除、编辑等	超级管理员，测管运维人员
案例库使用情况		按照用户所在的角色的权限控制是否可见	查询	超级管理员，测管运维人员
指标预警管理		按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
覆盖率接入情况		按照用户所在的角色的权限控制是否可见	查询	默认角色等所有角色可见
用户管理		按照用户所在的角色的权限控制是否可见	新增、删除、编辑等	超级管理员，测管运维人员
数据字典		按照用户所在的角色的权限控制是否可见	新增、删除、编辑等	超级管理员，测管运维人员
造数需求		按照用户所在的角色的权限控制是否可见	新增、删除、编辑等	默认角色等所有角色可见
案例删除配置		按照用户所在的角色的权限控制是否可见	新增、删除、编辑等	超级管理员，测管运维人员
我的下载			按照用户所在的角色的权限控制是否可见	查看、下载等	默认角色等所有角色可见

2.3蚂蚁平台工具对接2.3.1测试项目数据对接

与蚂蚁平台工具对接，实现平台与当前流程的适配，包括测试人员，测试数据，测试结果，测试报告，测试日志与监控信息等，确保测试数据准确入平台，出平台，同步测试过程，测试情况等信息。

2.3.2 测试数据安全管理

测试数据，测试报告等安全管理，确保数据合规保密不外泄。

2.4自动化执行管理2.4.1自动化案例日常维护与执行

1.资产库支持执行，提供日常案例维护与执行功能，确保案例能够正常入库与日常执行，并进行分析，报告解读，查看日志等。执行后端接口、数据库与测试管理处保持一致为同一套。但测试管理和资产管理的接口自动化页面的数据不互通。执行机和测试管理是一个。

资产管理->案例库->接口自动化->Feature，删除批量执行，删除单条案例执行，添加一键执行。Feature执行的后端逻辑和测试管理->测试执行->接口自动化->Feature的逻辑一致。后续测试管理的feature执行改动，资产管理的feature执行也要同步改动。

一键执行处的执行控制保持一致：有处于队列中/执行中的案例，不能重复发起执行；废弃的案例不可执行；不可选多仓库或多系统同时执行；执行人控制：系统所属小组下的所有人；

资产管理->案例库->接口自动化->Runner。Runner执行的后端逻辑和测试管理->测试执行->接口自动化->Runner的逻辑一致。后续测试管理的runner执行改动，资产管理的runner执行也要同步改动。增加一键执行按钮，runner执行支持多线程跑包含以下限制：

runner支持多个勾选，点击一键执行；没有勾选，默认全部一键执行；一键执行进行二次弹窗确认："是否要发起一键执行？"；一键执行要对每个runner生成一条执行记录；

校验顺序1：勾选runner后，点击一键执行，如果不是系统所属小组下的人，不能发起执行，提示：仅案例对应的系统所属测试小组下人员发起执行；

校验顺序2： 勾选runner 存在废弃案例，报错提示： 仅案例状态为正常的案例可以发起执行

校验顺序3： 勾选的runner中有正在执行的案例，报错提示：存在执行中、队列中的runner，无法发起一键执行；

校验顺序4： 勾选runner ，如果确实方法名，报错提示: 仅包含方法名的runner可以发起执行, 请先设置方法名

多个runner跑，每个runner返回各自的执行记录和执行记录明细；

资产管理->案例库->接口自动化，新增执行记录页面。后端逻辑和测试管理->测试执行->接口自动化的逻辑一致。

资产管理与测试执行的执行记录页面数据不互通。

资产管理的执行记录不开放提交缺陷的接口。不用进行案例分析，如果有该功能也没事；

资产库的案例全部都可以查看，但是测试执行的权限控制为组内所有人,执行记录是所有人都可以看到，执行记录的终止，复测权限是所有组内的人。

执行记录和测试执行处保持一致，只保留近3个月的执行记录（按照执行记录首次执行的时间）

执行记录处增加系统的筛选条件，展示默认展示左侧勾选的系统，下拉展示该人所在的小组的系统，其他系统需要自行搜索

1.自动化需求处增加执行记录

所有的feature和runner执行会在执行记录处生成一条执行记录，执行记录逻辑与测试执行处一致。feature勾选的案例算一个执行，为一条执行记录，runner是一个runner一条执行记录。执行记录中包含执行记录统计，日志分析，cucumber报告，可进行复测等。

2.4.2自动化执行覆盖特殊场景2.4.3持续交付测试能力

开发流水线每次部署之后，通过案例录制和变动代码，精准匹配涉及的案例并发起执行。

（1）按照工程，配置一个测试负责人、一个执行人、以及自动化测试的执行环境信息，一个是否自动执行的开关；支持只到案例分配，不到案例执行；

（2）工程打版后，案例推荐出所有的自动化案例，并选择一个最小的计划上线日期；自动化案例过滤非该系统的案例（系统是打板工程的系统，案例的系统：资产库案例的所属系统）；并按照工程获取系统配置的测试负责人，执行人，测试环境信息，执行开关等，然后发起后续操作；

（3）创建自建项目，承载持续测试的相关信息。通过系统+自建项目干系人中的测试负责人+上线日期，且自建项目名称符合规则【持续测试_YYYYMMDD】作为唯一键，支持自建项目的复用，自建项目自动评估通过；轮次如果没有回归测试第一轮，则进行轮次创建，否则进行执行人添加，已经添加的，继续下一步；

创建项目到添加执行人的操作加锁处理；自建项目信息：

项目名称：持续测试_YYYYMMDD (YYYYMMDD为覆盖率传过来的上线日期)

所属系统：部署工程所在系统

测试项目类型：回归测试

上线日期：计划上线日期

故事干系人：小组为覆盖率传过来的负责人所在的小组（如果执行人对应了多个测试小组，选择其中一个即可），小组长为默认小组长，负责人为覆盖率传过来的人，助理空；

评估信息：预估工时为1；自动创建测试计划：是；评审意见：同意；

计划执行日期：如果上线日期小于当前日期，则为当天-当天；如果上线日期大于当天，则为当天-计划上线日期；

（4）案例引入和案例分配，已经引入和分配的，不再引入和分配，最后发起执行； 废弃的案例过滤；

（5）案例发起执行：是否自动执行为否不执行案例，结束；如果是否自动执行为是发起执行，如果传过来的案例属于一个系统，按照git源和分支分组，分别发起多次执行；

执行参数：系统选择传过来的系统

线程数、复测次数为系统+git源确认的仓库管理的默认配置

环境为自动化执行环境

wp通知人为覆盖率传过来的执行人；

（6）平台支持案例录制，并将案例与代码方法的关联关系记录下来：

测管测试执行/资产库的执行发起处（feature执行，runner执行）增加【执行并录制】的按钮，案例执行的时候，在工程下增加文件，同时修改runner执行的方式，增加hooker；

场景处理：案例卡住，点击终止按钮时，案例录制自动废弃，案例执行卡超过24小时无人处理时，案例录制自动废弃；案例执行失败的时候废弃录制案例执行成功保留录制记录；

案例执行记录下增加链接查看覆盖率录制情况

名称	目录层级	案例类型	系统名称	分支	仓库地址	关联方法
a.f	/../a.f	场景	A	sit	×××.git	/nubla-free-api/audirecord /foundcoupon/grant方法
b.f	/../b.f	单接口	B	uat	×××.git	/foundcoupon/search方法

（7）环境信息关系，支持环境联动配置，查看，删除和新增

2.4.4自动化案例管理

1.入库管理

接口自动化案例入库时，runner执行标准为非编译失败即可，因此此处可以进行优化，不一定要等到执行完成才返回状态

接口自动化案例入库时，只能通过runner执行的feature，分批无法入库。因此建议已经入库的runner支持再次执行，支持新交付的feature案例继续入库；

快捷入库功能：

runner可以不走自动化需求，直接在资产库处发起执行，并满足案例编译成功即可的原则执行入库；feature快捷入库，可以不走自动化需求，直接在资产库处发起案例执行并满足入库标准后直接入库。

2.资产库管理

关联关系管理

资产管理->案例库->回归库，【接口自动化案例数】【UI自动化案例数】，点击跳出的自动化案例列表中，新增【取消关联】【新增关联】按钮

①【取消关联】【 新增关联】按钮的权限：自动化团队以及系统对应的测试小组人员（系统和小组为多对多关系），无权限的人不展示按钮

②点击【新增关联】按钮，跳出关联自动化案例弹窗，弹窗中展示接口/UI自动化案例【界面复用案例推荐页面，已经勾选的不可再勾选，已关联的展示在最上面；系统默认填充为手工案例所属系统】

③点击取消关联按钮，二次确认弹窗：是否确定取消关联关系？ 按钮：确认、取消

④新增关联时的标签处理：取新增完的接口/UI自动化案例关联的所有手工案例的所有标签，需去重

⑤取消关联时的标签处理：删除手工和接口/UI自动化案例的关联关系时，接口/UI自动化全部刷成删除后关联的剩余所有的手工案例的所有标签，需去重。要保留批处理 标签。

⑥标签的存量数据处理：接口/UI自动化全部刷成关联的所有的手工案例的所有标签，需去重。

资产管理->案例库->接口自动化/UI自动化

点击手工案例的弹窗，增加取消关联的按钮; 增加二次确认弹窗：是否确认取消关联关系？

1)点击取消关联按钮，二次确认弹窗：是否确定取消关联关系？ 按钮：确认、取消

2)【取消关联】【 新增关联】按钮的权限：自动化团队以及系统对应的测试小组人员（系统和小组为多对多关系），无权限的人不展示按钮

3)新增关联时的标签处理：取新增完的接口/UI自动化案例关联的所有手工案例的所有标签，需去重

4)取消关联时的标签处理：删除手工和接口/UI自动化案例的关联关系时，接口/UI自动化全部刷成删除后关联的剩余所有的手工案例的所有标签，需去重。要保留批处理 标签。

5)标签的存量数据处理：接口/UI自动化全部刷成关联的所有的手工案例的所有标签，需去重。

是否已替代管理

手工测试案例库（包括总库、回归库、关键库、风险库、关联库等）->是否自动化全替代/接口自动化案例数/UI自动化案例数关联数量实时取数，筛除已废弃自动化案例，但关联清单中显示正常+废弃案例。接口自动化案例数/UI自动化案例数 数字进去的关联案例清单中，正常案例在前，废弃案例在后，且弹窗中增加文字：自动化案例数仅统计正常状态的案例；

替代字段与关联数量变动逻辑【备注：自动化案例包含接口和UI案例，数量变动为有效自动化案例（剔除废弃），且包括接口和UI】：

1)批量入库/手动入库自动化案例，如果有关联的手工案例，入库时（不管是自动化首次入库/非首次），如果自动化案例为非废弃的状态，则关联手工案例都置为【已替代】，否则不进行变更；

2)自动化案例单条删除时，同时删除手自关联关系，当其关联的手工案例关联的自动化案例量由1->0：【已替代】 ---> 【空】

3)自动化案例批量删除时，同时删除手自关联关系，当其关联的手工案例关联的自动化案例都在删除清单中：【已替代】 ---> 【空】

4)自动化案例库中，自动化案例状态由正常转为废弃时，且其关联的手工案例关联的有效自动化案例量仅为1时：实时统计关联数量变为0，【已替代】 ---> 【空】；

5) 自动化案例库中，自动化案例状态由废弃转为正常时：关联手工案例都置为【已替代】

6) 手动逐一取消关联，且该手工案例关联的有效自动化案例量由1->0：【已替代】 ---> 【空】

7) 手动逐一新增关联，且该手工案例关联的有效自动化案例量由0->1：【空】/【无法替代】 --->【已替代】

特殊场景：48平台/泽众平台替代的：走数据维护，备注字段：UI自动化案例位于老平台48平台/UI自动化案例位于老平台泽众平台

8)手动设置字段状态改变【批量编辑（无法替代无法选择），单条详情内编辑】：

【空】和【无法替代】之间互相更改允许页面手工维护。

【空】/【无法替代】---> 【已替代】；【已替代】 ---> 【空】/【无法替代】这四种情况不允许页面手工维护。

9)批量入库手工案例时，表格中存在"是否自动化全替代"字段，只允许填写空/无法替代，非必填项，不填默认为空，在模板表格的表头给出批注：是否自动化全替代只允许填写空/无法替代。如填写已替代上传，报错是否自动化全替代只允许填写空/无法替代。和当前报错形式保持一致，和其他报错拼起来;

案例修改后通知相关人员维护：

1）手工案例（总库/关联库/回归库/风险库/关键库）修改后wp通知：手工测试案例被修改并由小组长审批通过时（包含小组长修改提交确认时），进行判断，如该手工案例的“前提条件、测试步骤和预期结果”中任意字段有修改，且该手工测试案例有关联的自动化测试案例（包含废弃的），则向该自动化测试案例所在的仓库的仓库管理人推送一个wp消息，消息内容根据不同类型的编辑内容不同：

案例详情修改：wp消息内容为“以下手工案例内容有修改，请关注。系统名称：案例编号"（系统名称为手工案例所在系统名称，案例编号为手工案例编号）

发送人：该条手工案例对应的所有自动化案例的系统+仓库地址，对应的仓库下的所有仓库管理人，去重；

批量导入修改：wp消息内容为"多个手工案例内容有修改，请关注。具体手工案例内容详见文件：文件链接地址",链接打开该文件，内容为两个字段：系统名称 案例编号

发送人：按照手工案例对应的所有自动化案例的系统+仓库地址，对应的仓库下的所有仓库管理人，去重，按照人维度进行通知；比如4个手工案例，其中3个案例关联的自动化案例的仓库管理人为A，则A收到一条wp通知消息，文件里面为3个手工案例编号；

2）接口自动化案例有变更内容后，通知相应的业务老师，支持界面查看分析；

新增表：

（1）新增 仓库提交commitid表，表结构为系统、仓库地址、分支、本次commitid、上次commitid，其中系统+仓库地址+分支是唯一键值，“本次commitid”记录当次保鲜发起时的commitid，“上次commitid”记录上次保鲜发起时的commitid，便于问题排查。

（2）新增自动化案例更新表。表结构见下文。

发起方式：

（1）自动化管理->仓库管理，每行数据的操作位置后面新增“案例保鲜发起”按钮，点击后，选择该仓库配置的分支，发起。

（3）特定业务意向（回归测试业务意向）上线时间T日24点，自动发起所有仓库案例保鲜。

发起后逻辑：

（1）代码获取到当前奋进号中该分支的最新一次提交commitid，并更新表：上次commitid=本次commitid，本次commitid=最新commitid，获取两次commitid的中间有修改或删除，且路径位于src/test/java/TestCase下的feature文件清单。

（2）逐一对比两个版本中的文件差异，记录于自动化案例更新表：

仓库、分支、自动化案例路径、自动化案例最后修改时间、查询日期区间、操作类型、修改记录、修改内容

其中：

操作类型：①修改：git diff返回的M类型，去除M类型但在“Feature:”字段前新增了“@abandon”；②删除：git diff返回的D类型文件，或M类型但在“Feature:”字段前新增了“@abandon”字段

修改记录：“Feature:”字段到“Background:”字段中间的新增内容，没有则为空；

修改内容：“Background:”字段到文档末尾的改动内容

（4）本次扫描存在差异数据时，为小组长+自动化测试仓库负责人生成待办：内容为：基于自动化测试案例的手工案例案例保鲜（日期），日期为扫描当天日期。

待办点击逻辑：

点击待办后，可选“下载文件”或“流转待办”，下载文件内容逻辑：

根据自动化案例更新表，仓库、分支、自动化案例路径三个字段唯一对应一个接口自动化案例，再找到该案例关联的手工案例，形成下表：

功能案例编号、功能案例标题、仓库、分支、自动化案例路径、自动化案例最后修改时间、查询日期区间、操作类型、修改记录、修改内容。

其中，如该接口案例对应3个手工案例，则出现3行数据，AB列内容不一致，C-H列内容一致；如3个接口案例同时对应到1个手工案例，也应有3行数据，AB列内容一致，C-H列内容不一致。

2.5平台性能提升2.5.1自动化执行分发策略升级

自动化案例的执行支持并行执行，且支持多仓库执行。

1.系统仓库目录个数可配置，数据库中存有多个系统仓库地址

2.原本并行任务改为单任务，分发至空余仓库

3.仓库占用情况数据库中存储

4.仓库被占用完后剩余任务队列等待

5.执行前清理仓库，然后运行执行任务

6.结果返回确保正常

要求：1.保证仓库目录个数可在系统页面配置，权限：超级管理员

2.修改原有终止功能，从终止线程改为终止进程的方式。

3.保持原有socket通信方式不变，原mvn 2G的内存分配不变，需要通过计算强行限制当前同时运行的进程数量（线程数量控制下次做） 仓库占用count（1）

3.1:修改取数方法，原有取数方法根据redis判断是否有执行队列判断是否可以发起执行，修改为可以取到目录就可以取数发起执行，并修改执行队列key

3.2 修改原有执行任务逻辑：所有一键执行和单个runner执行都任务是单个任务

4.当系统配置页面增加仓库数量时，数据库新增地址。磁盘超过85%不允许新增。

5.拉取代码时监控一下服务器的磁盘情况，不允许增加仓库数量（根据删除的功能修改）

6.自动复测保持原仓库运行逻辑，手动复测视作新任务执行。（直接修改模板，解析result类，获取失败的scenario执行）

7.feaute一批1000的分批去除限制

8.因feature一批不受限制，导致可能result结果通过http传输超时或超过容量，改为传输总feature-summary等总和json，发送给springboot解析

9.执行完成的仓库配备以及定时任务清理

10.融合定时任务、一键执行、feature和runner

11.优化表结构，去除冗余字段

2.5.2自动化执行机可拓展与并发执行策略

自动化案例执行实现执行机可拓展与复测并发执行。

执行机可拓展：

1.根据仓库占用情况，分发任务。根据执行机中的正在进行的任务数量、cpu情况、内存情况和磁盘情况分发任务

2.nacos可以增加配置执行机ip，配置完成后直接可拓展服务器

3.定时任务相关，当做普通任务。保证定时任务正常进行，每次定时任务被任务是一个普通任务的发起记录结果。

4.根据现有的功能整理表结构，减少冗余的表记录（原有的一键执行为了争取时间直接套用了定时任务的表结构和功能逻辑，需要优化表结构）

5.失效的，仓库配置加一列，区分正式执行和测试执行。确认失效功能正常，阶段一的仓库配置里面加一列属性区分正式执行和测试执行

6.确认自动化需求功能正常执行

7.定时清理长久没有被使用的仓库

8.执行器监控的对于cpu和内存等监控换做Prometheus的嵌入

9.任务处显示任务的进程列表，确认终止功能正常

复测并发执行：复测单线程改多线程，提高复测的效率

纯sftp连接改为springboot通信，在服务器上部署springboot操作

手动复测param参数修改，带入复测次数

执行机文件修改线程，线程执行Runner.path

修改report文件地址，防止同个feature的secio执行，导致文件覆盖

修改终止的地方，万一存在老代码的kill线程还存在

返回结果地方修改，返回修改后的结果文件地址

springboot接收结果地方修改，解析返回结果内容

2.5.3数据存储分级

1.存储数据分级

2.定时任务迁移数据

3.历史数据处理

2.5.4服务改造

1.内存泄漏问题修复

2.中间件版本升级

3.数据库版本升级

4.远程服务器连接方式升级和集中管理

2.5.5慢sql优化

针对测试管理，测试看板，项目级管理等常用的功能，响应速度的较慢的进行sql优化。

2.6质量指数应用场景2.6.1质量模型的优化

根据试点总结以及行内的数据发展，我们将新增2个指标，并对当前存在的指标进行优化。

类型	指标名称	内容
新增	缺陷等级占比	开发质量模块增加缺陷等级占比指标，严重度高的缺陷占比高打分要低
新增	缺陷轮次占比	其他模块增加缺陷轮次占比，标志缺陷的走势情况
调整	测试缺陷密度	在没有缺陷的情况下，根据质量门禁打分
调整	最后一轮案例缺陷率	在没有缺陷的情况下，根据质量门禁打分
调整	封板后代码变动频次(T-4到T-1)	代码变动频次从故事流转为业务验收开始算，并剔除无效的变动情况：sql提交，自动化仓库提交、格式问题、无关分支的提交
调整	首轮桌检一次通过率	桌检指标不按照批次来算，还是按照首次登记来算
调整	UAT有效缺陷修复率	缺陷按照等级加权限等调整
调整	SIT有效缺陷修复率	缺陷按照等级加权限等调整
调整	SIT分支覆盖率	分支覆盖率变更为代码行覆盖率

2.6.2场景应用扩展

1.代码提交预警相应的增加无效预警的过滤：无关分支，无关仓库，sql提交，格式变更等；预警维度提升到系统，针对系统发预警和待办，同时增加代码提交风险分析责任机制，开发需要填写提交的内容与是否有风险，提交完成后，测试老师确认并采取相应措施，处理完后提交内容；扩大预警使用的场景并保证风险内容不被遗漏。

2.上线信心增加数据风险分析与提示内容：首先后台增加表和数据归档机制，确保每个版本每个小组，每天的上线信心分数被记录下来，并分析趋势；其次针对上线信心展示一个预期的上线信心分数以及数据分析结果，展示当前异常指标数据分析原因与解决措施；

3.上线信心模型稳定后，在对应的门禁等处增加上线信心数据展示和提示：总体报告生成时，增加分数与跳转功能；uat门禁提交时，增加分数与跳转功能；发起上线时，增加分数与跳转功能；

2.6.3产能数据报表

按照版本展示人员维度的预估工时，报工工时，预估和报工差异率，等其他指标，并支持明细查看。

1）查询条件：版本，上线日期，测试小组，研发小组，工号

2）报表数据：

计划上线日期	某个上线日期
投入版本	投入人力版本
人员	人员姓名（工号）
计划投入人天	人力预估的人天
报工人天	实际报工的人天
案例编写数	该版本下案例编写数量
案例引用数	该版本下案例引用数
执行案例数	该版本下执行案例数
案例执行次数	该版本下案例执行次数
有效缺陷数	该版本下有效缺陷数
有效缺陷率	该版本下有效缺陷率
测试命中率	该版本下案例命中率
出勤天数	该版本的测试周期内的出勤天数
资产库积累	该版本的测试周期内的资产库积累数
案例检查不通过率	该版本下案例检查不通过率

3）明细数据

故事编号	-
故事名称	-
计划上线日期	-
预期交付测试日期	-
系统名称	-
是否主系统	-
研发小组	-
测试小组	-
投入版本	-
人员	-
计划投入人天	该故事的计划投入人天
报工人天	该故事的报工人天
案例编写数	该故事下案例编写数量
案例引用数	该故事下案例引用数
执行案例数	该故事下执行案例数
案例执行次数	该故事下案例执行次数
有效缺陷数	该故事下有效缺陷数
有效缺陷率	该故事下有效缺陷率
测试命中率	该故事下案例命中率
出勤天数	该故事的测试周期内的出勤天数
资产库积累	该故事的测试周期内的资产库积累数
案例检查不通过率	该故事下案例检查不通过率

2.6.4试点优化汇总

1.指标分数与预警保持一致

指标分数格式统一，按照分数段展示相应的颜色，5大主页面风格保持一致；同时预警逻辑变更，采用上线信心跑批数据预警，使得预警和跳转链接展示的分数保持一致。

2.指标门禁展示

12个指标的详情页，在首页增加门禁信心，取打分使用的那个门禁，一般为最新登记的门禁。

指标详情页-指标1	增加门禁字段，展示打分使用门禁
指标详情页-指标2	增加门禁字段，展示打分使用门禁
指标详情页-指标3	增加门禁字段，展示打分使用门禁
指标详情页-指标4	增加门禁字段，展示打分使用门禁
指标详情页-指标5	增加门禁字段，展示打分使用门禁
指标详情页-指标6	增加门禁字段，展示打分使用门禁
指标详情页-指标7	增加门禁字段，展示打分使用门禁
指标详情页-指标8	增加门禁字段，展示打分使用门禁
指标详情页-指标9	增加门禁字段，展示打分使用门禁
指标详情页-指标10	增加门禁字段，展示打分使用门禁
指标详情页-指标11	增加门禁字段，展示打分使用门禁
指标详情页-指标12	增加门禁字段，展示打分使用门禁

3.指标导出和排序优化

页面	优化内容
首页	导出和导出文件排序默认按照分数低到高的顺序
故事列表	故事按照总分由低到高排序
指标详情页-总分	按照总体分数由低到高排序，导出也一样
指标详情页-模块	按照模块分由低到高排序，导出也一样
指标详情页-指标1	按照指标分由低到高排序，导出也一样
指标详情页-指标2	按照指标分由低到高排序，导出也一样
指标详情页-指标3	按照指标分由低到高排序，导出也一样
指标详情页-指标4	按照指标分由低到高排序，导出也一样
指标详情页-指标5	按照指标分由低到高排序，导出也一样
指标详情页-指标6	按照指标分由低到高排序，导出也一样
指标详情页-指标7	按照指标分由低到高排序，导出也一样
指标详情页-指标8	按照指标分由低到高排序，导出也一样
指标详情页-指标9	按照指标分由低到高排序，导出也一样
指标详情页-指标10	按照指标分由低到高排序，导出也一样
指标详情页-指标11	按照指标分由低到高排序，导出也一样
指标详情页-指标12	按照指标分由低到高排序，导出也一样

2.7日常优化汇总2.7.1测试流程便捷化

1.测试设计，测试任务数据过滤

手工测试/接口自动化/UI自动化各个tab页都要增加过滤条件：

测试设计和测试执行处，增加过滤条件“过滤历史故事”，默认勾选。勾选时，如果用户故事上线日期＜当前日期，则用户故事下的测试计划和测试任务均不显示。如果用户填写“计划上线日期”筛选条件，则支持查询历史用户故事，“过滤历史故事”字段默认不勾选；计划上线日期为空的认为不是历史故事。

测试执行处，增加过滤条件“过滤无分配的任务”，默认不勾选。勾选时，将没有分配案例的测试任务过滤掉。

2.分配推荐等操作简化前端样式

案例分配和推荐页面，不再有下拉的操作，当前在什么类型的测试页面，点击分配和推荐直接跳到对应页面的分配和推荐详情中

3.增加查询字段，支持多场景案例执行

测试执行分配页面，增加模块路径字段，支持根据模块路径快速查询分配案例。

测试执行分配页面，全部/人维度，增加查询字段【是否关联缺陷】，默认为空，可选择是/否，或者全选；用于查询关联测试缺陷的案例，便于再次分配；关联缺陷不限轮次，查询该案例所关联的所有缺陷（剔除已否决的，问题和优化类全部算）

问号提示：案例是否关联了测试缺陷（问题和优化类，剔除已否决）

4.支持轮次以及以上目录的快速案例检查通知

项目级测试管理页面的轮次层级以及其上的层级，导出按钮左边增加“检查通知”按钮 。发送该目录下的未发送的案例检查通知。

5.案例执行增加统一入口

①在测试设计-案例-执行记录处，可以直接点击对应的记录，跳转到对应的执行内容页面

项目级管理的案例管理，案例详情增加执行记录模块，与测试执行-测试设计处保持一致;

②执行记录增加字段【测试轮次】【测试小队】

对应路径：测试设计-案例-执行记录

截图示意：

点击后跳转到测试案例执行详情页面

6.部分数据精简

测试执行完成按钮，取消交付日期的填写

测试计划，测试执行时间取消必填项填写

案例评审的时间取消填写

案例评审的人员默认下拉调整，使其命中率更高

测试总体报告取消冗余信息

7.增加批量操作

1）批量验收通知

测试计划页面增加批量验收通知人员，勾选多个测试计划，批量发起验收通知，验收通知内容为同样数据，仅填写一次。控制：相同测试小组的计划才可以发起批量验收通知。测试计划数量展示所有的勾选的计划信息，对接工作平台，需要展示测试计划的列表。

2）批量提交缺陷

批量勾选案例，批量执行失败时，弹窗变更为如下，右侧的叉号为加粗红色的：

是否登记缺陷？是，登记缺陷（第一条案例挂测试缺陷其余案例不登记缺陷，原因为其他）；否，则请填写不登记缺陷原因。关闭窗口可取消本次案例操作。

选择否，跳到批量不登记缺陷原因弹窗，当前已有该功能。

选择是，跳出登记缺陷弹窗，登记缺陷的弹窗为正常单条登记缺陷的弹窗，不是特定业务意向的登记测试缺陷的弹窗；

点击确认：登记缺陷成功后，案例全部置为已失败，第一条案例登记缺陷，其余案例走不登记测试原因类型选择其他，内容备注：批量失败已登记缺陷：issue_id；

登记缺陷失败时，案例状态不做任何操作，提示用户对应的失败原因；

点击取消：案例状态不做任何操作 ，返回到案例界面；

3）批量设备归还

设备库增加批量归还功能，位置如图

a)仅设备负责人、设备的借用人 和设备所属小组的小组长可归还设备 ，当前登录用户点击时有不符合的设备提示 “设备名称1、2、3：仅设备的负责人、借用人和所属小组小组长可以归还设备 ”(最多展示10个设备)

b)归还人下拉框展示所有设备的【组内的所有行员外包+设备的借出人 】的并集去重，提交时如果设备归还人不对提示 “设备名称1、2、3：仅设备的负责人、借用人和所属小组小组长可以归还设备 ”(最多展示10个设备)

回退：批量操作时，有一个设备归还失败，则全部设备借出失败。 归还弹窗不关闭。

2.7.2基础数据来源变更

配合奋进号的工程平台的能力提升项目，测管的基础数据来源和同步方式变更。其中系统信息将从cmdb中获取，人员以及人员关系还是通过奋进号进行同步，但是由库同步变更为传文件。测管自行拆解数据。

数据信息	当前方式	预期方式
系统信息	直接奋进号推送入库	调cmdb获取信息，自行解析处理入库
用户信息	直接奋进号推送入库	奋进号同步文件，自行处理入库
部门信息	直接奋进号推送入库	奋进号同步文件，自行处理入库
用户与部门的关系信息	直接奋进号推送入库	奋进号同步文件，自行处理入库
小组信息	直接奋进号推送入库	奋进号同步文件，自行处理入库
人员与小组关系信息	直接奋进号推送入库	奋进号同步文件，自行处理入库
小组与系统关系信息	直接奋进号推送入库	奋进号同步文件，自行处理入库

2.7.3代码行覆盖率指标相关改造

1.测管平台-测试计划-关联工作项-覆盖率情况

1）界面删除4个列名：方法级覆盖率、行级覆盖率、分支级覆盖率、未覆盖方法。

2）新增一个列名：增量行覆盖率（位于分析环境和任务状态之间）。

数据展示：四舍五入保留两位小数；整数不保留；界面无数据时/(斜杠)展示。

3)点击链接地址到覆盖率平台-用户故事级覆盖率-点击系统名称。

跳转覆盖率平台将任务编号和系统名称带过来

任务报告详情

用户故事级方法页面

新增1个列名：增量行覆盖率（位于分支覆盖率和增量类型之间）

数据展示：四舍五入保留两位小数；整数不保留；界面无数据时/(斜杠)展示。

界面仅有类型为新增和修改的代码

系统级增量方法页面

1）新增1个列名：增量行覆盖率（位于分支覆盖率和增量类型之间）。

数据展示：四舍五入保留两位小数；整数不保留；界面无数据时/(斜杠)展示。

2）界面仅有类型为新增和修改的代码

任务报告

点击增量版本号 跳转页面 工程级增量覆盖率

sit环境跑完后的覆盖率数据会更新到流程中心，验证流程中心处sit页面覆盖率数据。

2.测管平台-测试看板-覆盖率情况

1)将系统级未覆盖方法（UAT）页面隐藏

2)新增一个页面 名称为：系统增量行覆盖率 （页面参考系统级未覆盖方法）

3)筛选框不变:系统中文名称或编号和系统变更日保持原功能不变；

新增筛选框“所属测试小组”页面展示登录者所属的测试小组下的所有系统的覆盖率。

可将小组清空展示所有小组的数据，也可选择其他小组的数据进行展示

4)重置和查询保留

5)删除"通知"，可勾选的框也删除

6)页面位置：第三个位置

列表如下图：

1)列表展示的数据为覆盖率平台-流程中心-功能测试任务的页面的方法数据，显示系统和变更日里方法的任务数据

2)未覆盖方法修改为“方法名”

3)新增字段：增量行覆盖率、增量类型、用户故事、研发部门、研发小组、研发小组长、研发负责人、测试部门、测试小组、测试小组长、测试负责人；默认展示 增量行覆盖率、增量类型、用户故事、测试部门、测试小组、测试小组长、测试负责人；剩余字段：研发部门、研发小组、研发小组长、研发负责人默认收起不展示，也可将其放开展示。界面字段排序如下图展示：

4)删除：研发确认未覆盖类型/研发确认未覆盖原因/研发备注/测试确认情况/测试备注/操作

5）若覆盖率平台有隐藏的方法，该页面方法也将隐藏。

3.测试计划覆盖率

1）界面删除1个列名：未覆盖方法。

2）新增一个列名：增量行覆盖率（任务状态后面）

数据展示：四舍五入保留两位小数；整数不保留；界面无数据时 / (斜杠)展示。

4.用户故事级覆盖率

1）新增一个列名：增量行覆盖率（任务状态后面）

数据展示：四舍五入保留两位小数；整数不保留；界面无数据时/(斜杠)展示。

5.覆盖率分析趋势页面

覆盖率趋势 增加：“增量行级”，分析数据，位于第一个位置。

2.7.4移动端截图上传功能优化

移动端截图上传功能进行优化，将技术创新大赛的成果转现。

1)针对当前的移动端上传功能进行优化：

案例版本号支持填写多个，最多填写五个，中间中文/英文逗号隔开；提示“案例版本号可以填5个，用逗号隔开”，同时增加虚拟机密码的填写框，方便进行案例执行为已通过。

查看案例标题逻辑变更：将案例版本号分割后（空格部分自动剔除 ），查询所有的案例标题并返回；重复的传回重复的案例标题；

上传（没有勾选上传到测试过程）逻辑变更：将上传的图片上传到填写的每个案例的附件上（空格部分自动剔除）；

上传（勾选上传到测试过程）逻辑变更：将上传的图片上传到填写的每个案例的附件上，以及测试过程中（空格部分自动剔除）；

增加【上传并执行通过】勾选项，位于自动上传到测试过程右侧，勾选后点击上传按钮，图片上传到指定案例后，再将案例置为【已通过】，已通过调原有的已通过接口，该接口的已通过有对是否能执行进行控制，会增加一条执行记录并置为已通过，同时如果是第一条案例执行会将测试任务由待执行变为执行中；

2）支持界面查询任务和任务下的案例，勾选案例后，支持上传截图：

增加工号和虚拟机密码的输入框，密码加密，支持查看明码，查看任务，可查询该用户下的【待执行】【执行中】的测试任务；支持按照任务名称模糊查询；

如果输入的工号或者密码错误，那查询任务的时候提示：工号或者密码错误，请输入正确的工号和密码！

选择任务后，跳到下一页，展示第一页选择得任务下的所有案例，按照测管当前的排序展示，案例仅展示案例编号和案例标题，案例状态，案例版本号（后端也传，只是前端不展示），支持分页查看，支持通过案例编号或者名称查询；

案例支持勾选，支持多选，然后上传截图到勾选的案例上；同当前功能。

页面设计图：

第一页：查看任务页面

任务只能单选，然后点击下一步

第二页：我的案例页面

我的案例页面可以返回到选择任务页面，保持上一次查询的结果；

选择任务后，跳到我的案例界面，可以勾选案例，支持勾选多个，然后上传截图；

上传截图后，保持在我的案例页面，我的案例列表刷新，可以继续勾选案例上传截图；

2.7.5新增待办确认流程

1、回归测试确认待办

（1）新增回归测试执行范围表。表格内容由自动化测试组提供，可能会每月维护。

系统	负责测试部门	负责测试小组	回归测试类型 （手工测试/接口自动化/UI自动化，三种字段择一）
核心业务系统四代	基础业务测试部	核心测试组	手工测试
柜员系统二代	基础业务测试部	核心测试组	手工测试
企业网上银行系统	公司业务测试部	公司公共测试组	接口自动化
企业网上银行系统	个人业务测试部	个人公共测试组	UI自动化

（2） 增设定时任务，特定业务意向下的用户故事的T-1早上8点触发：

对特定业务意向下T日上线的所有用户故事，以回归测试执行范围表中的系统、测试部门、测试小组、回归测试类型，关联查到该测试计划（系统+测试部门+测试小组确认故事，故事+系统确认计划）应当确认的回归测试类型（可能有多条），再逐一判断tm_regression_test_validation表中该测试计划（用户故事+系统）+回归测试类型是否存在确认信息。如无确认信息的，在该测试计划对应的测试组长、测试负责人与测试助理名下生成待办，并发送wp通知。关联回归测试执行范围表时，如无数据，跳过。

wp通知格式：您有一条【xxxx（测试计划）_xxxx（回归测试类型）回归测试确认】流程待处理，请及时处理。链接（点击后跳转到到待我流转的这条待办）

（3）个人工作台--待我流转

新增“回归测试确认”类型的待办。待办字段：

标题	类型	所属系统	状态	当前处理人
xxxx（测试计划）_xxxx（回归测试类型）回归测试确认	回归测试确认	测试计划对应的系统	待确认/已确认	姓名(工号)

流转逻辑：

点击待办名称后跳出弹框，确认xx版本字段，取上线月日；测试计划和测试类型行自动填充，不可修改；是否需要回归测试，选择“是”后，下方出现填写执行环境（必填）、系统版本是否已更新（必填）、备注框（非必填）。选择“否”后，下方提示填写不回归测试原因（必填），确认按键显示。弹窗复用测试设计处的回归测试确认弹窗，后续逻辑与测试设计处的回归测试确认逻辑一致，即在下图逻辑基础上+选择是的情况增加一个非必填备注框。

如某一测试计划（用户故事+系统） + 回归测试类型的所有待办下，测试组长、测试负责人与测试助理中有任意一人将待办内容填写，点击确认，在tm_regression_test_validation表中新增回归测试确认信息（如果已经存在确认信息，不进行提示，直接插入），并流转该测试计划+回归测试类型在测试组长、测试负责人与测试助理生成的所有待办至结束（已确认）。后续点击测试设计下该测试计划的该回归测试类型，不再跳出弹框提示填写。

测试管理->测试设计->回归测试确认弹框，点击确认后

原逻辑：存至tm_regression_test_validation，重复确认覆盖

预期逻辑：存至tm_regression_test_validation，重复确认时，插入一条新的，并判断待办中是否存在该测试计划+回归测试类型下的待办。如有，将该测试计划+回归测试类型下的所有待办均流转至结束（已确认）。

测试管理->测试设计->回归测试确认弹框，手工/接口/ui三处的弹窗：选择“是”时，增加备注字段，展示已经登记的回归确认信息时，按照登记时间选择最新的一条展示；

测试计划-总体报告，回归测试信息按照登记时间选择最新的一条进行展示，包括生成报告时；

2.7.6测试项目简报

新增报表：p类项目测试简报

1、位置：测试看板-p类项目测试简报，可见权限：和测试看板菜单可见权限保持一致 。

a)查询：业务意向+上线版本日期（有上线版本的日历）+所属轮次;业务意向查询框必填，不支持多选；上线版本日期非必填，不支持多选；查询范围：金融科技+子公司的故事，只要P类项目;默认值：为空；

b）右上角配置所属轮次按钮可打开配置页，QA、超级管理员可点击，其余人按钮置灰，悬浮提示“仅QA和超级管理员可配置”

c)上线日期要做单元格合并。

d)增加跑批按钮和跑批时间字段。增加提示，业务意向下只要有没配的轮次，提示用户先去配或者直接跑批（可能没数据缺数据）

e)翻页：默认20页一行；排序：数据按照轮次排序：冒烟（1/2/3轮），系统（1/2/3 阶段，再1/2/3轮 ），版本（1/2/3 阶段，再1/2/3轮 ），专项（1/2/3/4/5/6轮），业务（1/2/3 阶段，再1/2/3轮 ），回归（1/2/3轮）；

f)支持导出，当前页下载excel，名称“QA报表_p类项目测试简报_年月日时分秒”

g)排序：如果有上线日期，按上线日期正序排序最新的在下面。

2、数据口径-都是测试任务维度，任务内取并集去重

上线版本：奋进号用户故事卡片右侧的“计划上线日期”；

所属轮次：配置页自己定义的所属轮次，没有所属轮次则不展示；

开始时间：第一条案例执行记录的时间（包含失效废弃），年-月-日；

完成时间：最后一条案例执行记录的时间（包含失效废弃），年-月-日；

计划执行案例数：有效案例数。去重：轮次间去重，多人多轮次 执行只计一条；（有效案例定义：正常案例【执行结果包括未执行、进行中、成功、失败、阻塞中、已失效（失效原因就仅为阻塞案例、无测试条件、无时间测试、其他的案例）】+ 废弃案例【废弃原因仅为阻塞案例、无测试条件、无时间测试、其他的案例】）

已执行案例数：成功+失败案例数（去重）（有一个人执行了就算执行了）；

案例通过数：最终状态是已通过的案例数（去重）；（轮次下所有人都要执行成功）

执行率：通过+失败案例数/计划执行案例数，保留两位小数，百分比；只要有一个人执行为成功或失败就可以；

通过率：案例通过数/已执行，保留两位小数，百分比；已执行：多人执行时有一条执行结果为成功/失败即可。

有效缺陷数： 问题类且未被否决的缺陷，包含游离缺陷+案例下的缺陷；挂在案例下的缺陷按照配置的用户故事+案例所在系统+测试轮次 对应统计，游离缺陷按照配置中的用户故事+缺陷所属系统+测试轮次跟缺陷进行匹配计算； （即缺陷创建时的故事系列轮次）

案例加权缺陷率：[有效缺陷数（高）*1+有效缺陷数（中）*0.5+有效缺陷数（低）*0.2]/（已执行案例数+阻塞中+进行中）；

缺陷修复率：有效缺陷中（已修复+已关闭）/有效缺陷数，去掉暂时保留；

缺陷关闭率：（有效缺陷中“已关闭”）/有效缺陷数，去掉暂时保留；

严重缺陷遗留数：有效缺陷数（高），“打开”+“已修复”+暂时保留；

暂时保留数：有效缺陷中“暂时保留的”；

3、配置页面，配置页面支持测试轮次配置所属轮次配置权限：QA和超级管理员可进行配置

宁波银行股份有限公司测试管理平台2025年能力提升项目供应商召集公告.doc

（1）报表右上角增加配置按钮，点击【配置所属轮次】按钮进入配置页面。

（2）进入默认全部不填，业务意向字段必填，单选; 业务意向支持意向编号和名称模糊搜索，查询范围：金融科技+子公司的所有的项目，只要P类项目;上线版本为测管的日历，范围选择，非必填；

所属轮次，测试轮次，用户故事，系统非必填，可多选；所属轮次为业务意向和上线版本下的存在的所属轮次，测试轮次为故事下存在的测试轮次，过滤掉没有分配任何测试案例的轮次；用户故事为业务意向下的故事，支持故事编号和故事名称模糊搜索；系统为业务意向下的系统，支持模糊搜索；所属轮次支持“空”这个查询条件；

（3）查询业务意向下的对应计划上线日期的所有的故事+系统+测试轮次（三者一起去重，有小队情况）的数据，据按照计划上线日期正序排，再按照测试轮次排序：冒烟（1/2/3轮），系统（1/2/3 阶段，再1/2/3轮），版本（1/2/3 阶段，再1/2/3轮），专项（1/2/3/4/5/6轮），业务（1/2/3 阶段，再1/2/3轮），回归（1/2/3轮）；

支持分页

（4）数据库中存储用户故事，系统，测试轮次和所属轮次的关联关系；

关联所属轮次：勾选查询出的数据，点击关联所属轮次，所属轮次为当前数据字典所拥有的全部轮次（单选），将上线版本+用户故事+系统+测试轮次与所属轮次关联；如果勾选的数据存在已有所属轮次，报存在数据拥有所属轮次，请先取消轮次关联再重新关联所属轮次；

取消轮次关联：勾选查询出的数据，点击取消轮次关联，则将上线版本+用户故事+系统+测试轮次与所属轮次的关联关系取消；如果全部所属轮次为空，报：没有数据需要取消轮次关联；忽略勾选的所属轮次对应测试轮次为空的数据；

2.7.7对接环境平台环境链路

测试执行页、执行管理页 测试任务下，添加 【测试环境】【 链路总灯】字段，选择测试环境，可以展示该故事，系统和测试环境的链路灯，链路灯为绿色代表环境可用，黄色代表有问题但不影响使用，灰色代表无数据反馈；测试老师可以根据此确认是否要继续执行测试案例，防止环境信息通知不及时导致测试返工。

链路总灯右侧增加问号提示，提示内容：根据用户故事，展示环境实况，仅作为参考。

链路总灯为：一盏灯（绿/黄/红），由环管提供；点灯跳到环境平台的链路图中，将系统，和用户故事代入查询条件中；

测试环境 ：支持下拉，单选，下拉清单由环管提供；

（1）测试环境如果有存上一次环境信息，使用该环境，否则根据任务当前阶段，随便选择一个环境（测管传用户故事，系统，测试环境sit1，环境由测管从环境清单中选择一个，轮次对应环境阶段：冒烟、系统算SIT，版本测试、回归、业务验收、专项测试按UAT，若对应的类型没有环境，按照sit/uat/其他顺序类型，选择类型中的一个）；若环境返回的链路灯信息为空，则展示空灯；上一次存储的环境已经不存在的话，返回空灯；

（2）用户下拉可选范围为此系统下的全部环境，可以不选保留环境为空；

（3）环境修改后点击空白保存并刷新，只修改这个测试任务不影响其他，下次这个测试任务打开展示保存的环境，链路总灯跟随测试环境修改，从环境平台获取。

用户故事状态为故事草稿中，故事确认中、验收完成、待投产、已关闭、已终止、已暂停则，不展示【测试环境】【链路总灯】（测管平台区分）；

故事符合状态，定时刷新展示链路总灯（5分钟一次），环境为空的不刷新；

附件：

宁波银行信息科技服务提供商尽职调查报告

一、基本信息

1.1服务提供商基本信息

服务提供商全称
成立日期		法人代表
公司类型		注册资本&币种
统一社会信用代码
公司地址
联系人		联系人电话
公司主营业务

1.2监管评价

（是否出现在监管机构的黑名单中）

（最近二年在政府或金融同业合作过程中是否受到处罚）

（是否存在未决诉讼）

1.3关联公司或附属机构信息

（关联公司或附属机构是否存在经营危机，该危机是否危及该服务提供商的正常经营）

1.4主要客户清单列表

（主要客户群体）

二、服务提供商持续经营能力

2.1财务情况

（近三年经审计的财务报表）

三、服务提供商内部控制和管理能力

3.1服务提供商内控评估报告

（评估报告内容如覆盖以下3.2-3.6内容，则将评估报告内容对应填写至各个部分）

3.2服务提供商的组织结构

(内部控制部门，如是否建立了内部的使用工具的安全测试部门、内控部门、审计部门)

3.3 IT制度体系建设

（是否对其公司及项目的安全管理及流程管理建立了相应的制度）

（项目过程中的项目管理（PMO）体系，包括例会、沟通渠道等）

（服务质量控制方法）

3.4培训体系建设

（是否对其员工定期开展技术技能以及安全防范相关的培训，提供培训计划或培训材料）

3.5服务提供商人员离职率

（了解公司技术人员的离职率）

3.6IT风险管控

（包括对公司本身的IT风险管控及所承接外包项目的IT风险管控情况）

四、服务提供商信息技术能力

4.1服务能力和支持技术

（服务提供商的技术能力资质证明，专业认证等）

（描述使用的工作方法、应用软件、技术文档、评估模型、评估工具等使用情况、知识产权等）

4.2服务经验与市场评价

（服务提供商主要的服务行业、主营业务、服务客户）

（类似的服务项目经验及项目合同证明材料）

五、服务提供商的网络和信息安全保障能力

（该项评估内容用于非驻场信息科技外包）

（描述内容可包括网络与信息安全管理体系建设情况、网络与信息安全技术防护体系建设情况、安全事件响应和恢复能力、实践经验等）