1 企业级全栈测试平台 RunnerGO
1.1 Flow流拖拽自由组合，实时协作和共享
Flow自由拖拽自由组合，可以实现在进行一个接口后并发执行后续的步骤
接口自定义权重，根据Flow流自由组合配合接口自定义权重可以模拟真实业务分流的场景
全链路场景，可以在一个场景中还原真实的全链路场景
1.2 内置六大压测模式
并发模式
阶梯模式
错误率模式
响应时间模式
每秒应答数模式
轮次模式
在压测过程中，我们需要实时监控rps/tps/错误率等测试指标，假如我们对业务的成功要求比较高，那么我们可以使用错误率模式，对接口设置错误率阈值，当错误率达到阈值后，任务会自动停止，避免测试人员一时不查，浪费了压测时间，导致需要重新或多次进行压测。
响应时间模式及每秒应答数模式也是相同的道理，解决我们实际测试过程中遇到的类似问题。
响应时间模式及每秒应答数模式也是相同的道理，解决我们实际测试过程中遇到的类似问题。
阶梯模式可以模拟我们逐渐加压的过程，还原我们从小量流量到大量流量时，被测应用的状态和响应机制，测出我们应用的性能情况。
1.3多报告同屏对比-数据对比
1.4报告多图表实时生成
图表实时性
数据可视性
测试可控性
2大模型时代质量工作的探索与思考
2.1大模型行业发展现状及挑战
发展现状：
1、横向拓面、纵向深化、重心逐步迁移至生态建设
2、与业务需求加速融合，全面赋能垂直场景
3、应用模式持续创新， 服务模式日益丰富
4、性能不断提升，逐步展现多维技术能力
关键挑战：
鲁棒性不足：训练数据由于多重因素干扰，模型鲁棒性不足。
可控性差：模型算法具备强不可控性，内容存在风险。
数据隐私：数据规模体量较大，数据泄露风险加剧。
恶意应用：模型能力逐步开放且成熟，用户恶意使用风险暴露。
透明度差：天然的黑盒属性，导致大模型难以保障透明度。
伦理偏见：数据来源不均衡，导致算法存在潜在的偏见风险。
2.2 大模型AIGC在蚂蚁财富质量与风险的探索与思考
数字化运营-业务特征：
数字化运营-内容防控架构设计
数字化运营-AIGC内容防控方案设计
数字化运营-分发推荐链路保障方案
分发链路保障方案
多样性保障方案
金融服务-金融大模型的评估体系
目标：通过指标评价矩阵驱动产研服务质量持续迭代、评价模型能力
金融服务-金融大模型评测集
FIN-EVAL金融AI任务评测集
5大场景：金融服务认知、金融内容生成、金融知识理解、金融逻辑加工、安全合规底线、共28个任务维度评测集。
金融服务-行业大模型评测能力总结
金融服务-大模型评测能力发展方向
专业化：在垂直领域完善更加权威且专业的评测框架
通用化：评估框架ToB产品化与平台化
延展性：渗透到大模型生产流程的各个环节
数字化资产-业务特点
数字化资产-理财业务与资产交易特点：
数字化资产-资产交易数智化保障
数字化资产-机构提效
数字化资产-机构提效
数字化资产-基于大模型的测试生产力提升
质量Copilot
在线风险防控体系升级
大冒险背景的业务需求下，风险防控中问题发现、定位和修复等体系能力需升级
2.3 质量工作的管理实践和展望
质量行业的趋势与思考
质量工作新阶段：确定性的业务缺陷校验工作向针对不确定的概率性问题的评测、评估到评价的转移。
新研发模式：研发流程重构，评测驱动，评测需求增多。
算法工程问题凸显：大冒险应用落地爆发、迭代加速，算法工程的质量和效能问题日益突出。
领域专业性提高：大模型产业应用加速，专业领域知识要求提高
质量角色重要度提高：产品应用后，产品缺陷和风险迁移，可解释性需加强，质量工作的重要性会提高。
质量流程标准化：大模型底座评测能力不断下沉，逐步标准化，上层业务应用需更加关注领域能力及构建业务属性的评测手段。
质量行业的趋势与思考-各方质量工作的变化：
3 百度单元测试智能生成实践：
3.1 百度的单测
背景介绍-单测保障代码质量
背景介绍-平台化建设路径
背景介绍-单测推广面临的问题
【书写成本高】据调研，单测的研发时间约占总研发时长的30%~50%
【项目开发周期紧】来不及写单测
【影响研发迭代效率】单位时间内交互的需求变少
3.2 单测生成的探索
传统的单测生成：
以追求代码高覆盖为目标，依托于代码解析技术+随机/SE符号执行/SBST搜索
明显的问题：
1、代码可读性差：很大随机性，用例数目庞大
2、断言质量差：泛断言
3、生成性能差：数分钟
4、支持语言单一：不同的技术栈
5、开发维护成本高：不同语言，不同版本
6、生成环境要求高：高配置，软件版本，运行环境等约束
传统与基于模型的单测生成对比：
3.3百度单测智能生成的具体实现
实现路径：用AI原生思想重构单元测试的生成
单测模型：模型精调整体流程
让模型会写单测，写好单测
单测模型：数据挖掘
数据要完善，包含足够的上下文
单测模型：数据处理
数据质量要高，要有各框架各场景用例书写样本
单测模型：模型效果评估
评估指标：
优点：
定制性-满足更多的书写风格，支持特定框架及库
生成能力-内容更丰富，mock处理更好
性能-响应更快
缺点：
多场景支持
用例的解释能力
单测模型-提示词：
遵循规则：
与精调数据格式一致，提供足够的上下文
在token限制范围内
自适应上下文提示词：
代码解析获取被测方法相关信息
根据优先级与token限制，构造提示词内容
单测模型：提示词【无上下文信息】
单测模型：提示词【完善的上下文信息】
产品化：IDE人机协同模式
工程化：批量可用用例生成
自验证自修复
3.4 当前效果、挑战和未来展望
当前效果-IDE编码场景
当前效果-CR阶段用例批量生成
当前效果-CR阶段批量用例生成
挑战：
正确性的提升，更少的幻想：上下文
Mock技术的合理应用：特征提取与提示词构造
断言的正确性：mutation testing
高场景（分支）覆盖的用例生成： chain of think
多用例的写入文件合并：代码技术+模型
4 基于AIGC的蚂蚁新一代测试用例自动生成技术
4.1 测试用例自动生成的技术演进
测试用例自动生成：
【测试智能化】人工手写大量测试用例–>极致用户体验的用例编写方式：秒级智能生成高覆盖率、高有效性的测试用例
技术演进路线
4.2现有技术的问题和痛点
用例生成的难点与挑战
AIGC浪潮下用例生成的变革
以大模型为基础进行用例生成，很多已有的难点和挑战都有了新的解决方案
用例可读性：
大模型生成的测试用例可读性优于传统生成工具
全语言支持
大模型天然支持全语言，传统生成工具在跨语言支持时会遇到很多技术难点。以smartUnit为例，语句组装、运行时环境等都和语言紧密相关。
4.3 基于AIGC的蚂蚁新一代测试用例自动生成
产品能力：需求-to-测试用例
需求-to-测试用例，根据一句话需求来生成对应的测试用例（Java&Python）。帮助研发将测试环境前置，提高问题发现效率。
概括性需求：用Junit编写一个登录页面的自动化用例
聚焦性需求：编写一个单元测试来测试一个名为hasCloseElements的方法，该方法检查输入的列表中是否有任何两个数字之间的距离小于给定的阈值。
产品能力：被测代码-to-测试用例
被测代码-to-测试用例，根据被测代码来生成对应的测试用例，目前支持五种语言：Java、Python、JavaScript、C++、Go
产品能力：需求-测分-测试用例
根据需求描述生成对应的测试场景，再结合代码生成最终的测试用例，使得测试用例的校验能力与需求匹配，用于检查代码实现的逻辑错误
产品能力：测试用例补全
测试用例补全：对存量未包含Assert的测试用例进行补全，增强用例有效性
技术大图
高质量样本构建
模型训练使用的数据质量对效果至关重要，如何定义高质量测试用例训练数据？
模型效果评测
代码生成类任务评测集
代码生成类任务评测指标
模型效果评测
类比代码生成，使用HumanEval-X评测集进行评估，核心指标采用pass@1
测试用例生成评测数据集构建：
prompt使用HumanEval-X中的declaration+canonical_solution，针对prompt调用模型生成测试用例类（包含多个tests、多个assert），测试用例类中的全部tests都执行通过则认为pass
模型效果：
使用HunamEval-X评测集对模型的测试用例生成能力进行评估
模型效果评测
4.4 总结与展望
5 基于大模型分析需求生成自动化用例探索
5.1 议题背景
业务痛点：
优秀测试设计用例少，掌握测试设计方法能力少，随产品上量使用，产品问题逆向分析测试设计遗漏多。
自动化测试痛点：
开源大模型痛点：
5.2 解决整体方案
解决方案：
大模型解决方案业务架构：
5.3具体方法与技术实践
关键技术1：如何让大模型理解需求并给出相关测试验证点
测试专业语料仓库
关键技术2：如何根据大模型的测试验证点进行推荐输出相关复合要求的测试用例
关键技术3：页面控件提取构建积木仓库
文本测试用例生成UI自动化代码—积木仓构建背景
关键技术4：如何根据大模型输出相关UI代码生成相关的自动化用例代码
关键技术5：大模型的xpath如何探索变成产品自身的AW和正确的产品xpath
关键技术5背景–大模型的xpath为什么要替换
5.4 落地效果与总结
从需求到自动化用例生成页面
生成的一个完整需求大模型自动化用例–用例步骤敏感，不输出用例信息，只输出代码
测试步骤2大模型自动化代码生成
测试步骤3大模型自动化代码生成
1、场景级自动化用例建设效率由每人天4个提升到每人天15个【时间消耗在测试因子补充】
2、测试用例自动化率由50%提升到80%，解决了测试经理困惑，不会存在测试策略遗漏
3、产品漏测问题降低因大模型生成的验证点生成的测试用例增加
1、自动化建设人力由5个提升到100%，降低了自动化建设门槛，人人可以参与到自动化建设
2、大模型补充测试用例4000个，代码覆盖率由50%提升到65%，测试设计遗漏减少了
3、测试因子由5000个提升到8000个，测试因子利用率由15%提升到100%。资产和经验沉淀，积累到工具上。
5.5展望未来
在智能体检输出验证标准上利用大模型理解需求，输出需求的验收标准。
性能背景数据量构造方面发力，实现被测系统的数据跟镜像环境数据能够一致。
6 基于LLM提升测试效率的应用实践
6.1 测试用例生成的背景
编写测试用例遇到难题：
直接用GPT生成测试用例：
6.2用例生成难点与挑战
文本用例生成挑战
手工测试用例生成实践
前提介绍
大语言模型（LLM）获取信息的几个途径
预训练Pre-Training：利用大规模未标注数据进行的有监督学习前的初始训练，e.g. GPT-3.5有1750亿参数
微调Fine-Tune：对预训练好的模型进行微调
提示词Prompt：自然语言描述的文本，它作为AI模型的重要输入来指导模型生成内容，Prompt的质量对于模型生成效果有较大影响，为了生成复杂优质效果，通常需要对Prompt进行设计和反复调优
测试用例生成探索思路
无限制条件生成测试用例
聚焦主题式生成测试用例
prompt1：
生成示例1：生成了多个测试主题，总共生成了10个用例，用例覆盖更全，除基础功能外，增加了边界场景的测试，用例格式规范。
生成示例2：生成了多个测试主题，总共生成13个用例，用例格式规范，基础功能和第一次相似，但后续出现了“胡说”情况，联系出了不存在的功能。
优点：
LLM可根据测试内容生成多个测试主题，测试场景更丰富，有时可生成较好的边界测试场景。
每次生成的用例格式统一，方便后续处理。
缺点：
由于强制进行继续生成（强制扩充测试场景），导致出现模型幻觉，出现“胡说”的情况。
过程中生成的测试步骤过于冗余，测试可以根据测试场景直接进行测试
测试设计混合生成测试用例：
测试设计混合生成测试用例：
prompt1：
prompt2：请检查已经生成的测试场景是否有遗漏，如有遗漏，进行补充，如没有就返回：无需补充！
生成示例1：共10个场景，场景覆盖更全，使用了多种用例设计方法，并从测试分类方法出发，对测试场景进行了补充，如兼容性测试，在recheck场景阶段，LLM审阅了场景后，认为已经无需再补充。
生成示例2：共13个场景，场景覆盖更全，新增的用例主要集中在异常场景，少部分用例（6、12）出现重复，此时后补充的场景描述不全。
改进前后数据对比：
6.4接口测试用例生成实践
面临的挑战：
token限制：在token限制内，生成高覆盖场景的测试用例。
生成代码易维护性：生成复合业务风格的测试代码。
自动生成有效断言：请求、响应、断言字段无法精准生成。
问题解决思路：
分批次
注入框架结构
注入业务断言
方案基本流程：
代码生成加工-Prompt设计
代码结构设计：提升复用，减少重复，最终减少token消耗
同一个接口的请求头，请求体，URL基本都是相同的，可放在setup_class中提升复用。
每个测试用例在setup_method中深拷贝请求体达到数据隔离，在各自带用例代码中进行差异修改。
发送请求可单独抽象为send_request，避免原生requests调用，代码冗长。
代码生成加工-代码多次生成
首次生成Prompt
首次生成Response
后续生成Prompt
后续生成Response
代码生成加工-校验生成
生成的每一个用例中都会有一个#_case_end钩子，后续代码加工中会被替换成cheek_points方法调用，用于对请求，响应进行多维度的校验。
自校验Prompt：
外部校验Prompt：
外部校验示例：
清理Prompt：
清理示例：
接口自动化示例：
手工用例、接口用例生成后如何使用？
全流程测试准入准出：
6.4 落地效果与总结
功能展示：
应用效果：
7软件测试团队面向端到端价值流的自我革新与实践
7.1 背景
LSEG：
7.2 企业级敏捷转型及测试标准指定
企业级敏捷转型：
1、企业级敏捷策略优化，端到端业务价值流加入敏捷模型
2、加强技术团队交付的可预测性，成为组织级别年度目标之一。
3、将业务团队对于产品价值的持续观察和反馈融入到产品交付过程，加强产品需求模型迭代
4、从创新实验室到产品化实施，加大产品化成功率。
企业级测试标准的制定：
7.3业务端到端的质量保证机制及实践
案例-面向客户使用场景的端到端集成测试建立
案例-面向客户使用场景的端到端集成测试优化
基于公有云的端到端自动化测试解决方案
案例-端到端自动化测试方案赋能用户验收测试：
案例-人工智能赋能金融数据的端到端测试场景
案例-性能测试辅助业务增长或软件运行成本预估
1、新增用户量vs系统伸缩后的运行成本
2、业务用户自服务平台，基于性能指标特征对于业务增长进行预测
3、软件运行成本（峰值）分析vs系统架构设计缺陷
4、可持续发展，GreenIT
案例-测试设计反哺业务需求和架构设计
交付质量和效能指标评估
8 广发银行信创项目技术测试实践
8.1 信创项目背景与测试的思路和方法
银行信创项目测试特点：
测试时间少
测试资源投入少
被测应用应用层改动少
银行系统质量要求高
信创项目测试思路与方法：
测试思路与方法
针对银行信创项目的特点，我行功能测试的基本思路是不能简单的功能回归，既要保证效果还要成本较低，建立了这套技术测试方法，通过多场景的双发比对保证主要功能的正确性，通过自动生成的流量案例保证低频功能的正确性，两者结合覆盖了全量的功能，既保证了高效、高质量，又将成本控制在较低水平，下面分别介绍两种技术测试方式的技术实现和适用场景：
1、双发对比技术的运用
2、流量案例自动生成技术的运用
8.2 双发对比技术的运用
什么是双发？什么是比对？
双发工具：
1、采用javaagent的方式接入旧系统，旧系统无需代码改造，无业务入侵
2、双发agent拦截到流量经过序列化转发到双发工具后端
3、实时模式下，双发工具后端直接将流量转发新系统
4、回放模式下，双发工具后端将流量处理后存储在数据库中，再按要求的时间双发新旧系统
比对工具：
数据采集和数据加工：
比对功能：
结果统计：
双发比对遇到的问题与解决思路
1、不同应用比对规则不一致导致的工具通用性问题
2、如何提高比对效率
3、如何提高回放效率
4、如何提高出错排查效率
双发比对使用方式：
8.3流量案例自动生成技术运用
技术简介：
工具使用原理与使用方式：
流量录制回放的难点与解决思路：
流量录制回放平台作为测试工具在我行落地所面临的问题：
为了解决这些问题，平台重点做了些技术优化：
1、优化DB交互层子调用插件
2、增加子调用Mock匹配策略
3、补充入口重复检测机制
4、建立流量自动更新机制
5、利用IP染色实现UI流量录制
6、优化序列化与反序列化机制
8.4 信创项目测试技术实施成果：
