方式模拟实际业务的运行逻辑生成测试数据，一种方法是通过 GUI 构造测试数据，这是 最常见、最可靠的方式，直接通过客户端或界面完成数据构造，缺点是成本高、效率低； 另一种方法是通过数据库构造数据，缺点是直接修改数据库容易产生脏数据，全量导入 数据有评估和操作成本。“找”数是通过某种方式去查找已经存在的测试数据，一种方法 是通过数据库去查找可用数据，缺点是数据共用导致数据属性频繁变化，会相互影响； 另一种方法是通过找项目组或者是相关系统的对应开发人员配合提供，缺点是需要熟悉 38 《51 测试天地》七十四 www.51testing.com 各自模块，沟通成本高。这两种方式无疑都能够满足基本测试数据准备需要，但往往都 伴随着“造”数难和“找”数难的问题，而对于信贷业务来说，其长链路的特点使得“造” 数更难和“找”数更难，如何快速构造测试数据就成为了影响测试进度及质效的关键。 三、方法探索 较高要求； 大部分情况下数据构造流程伴随着业务状态的变化，数据状态是不可逆的，只能按 需不断构造新的数据； 链路越长整体成本越高； 数据间依赖性强，往往需要做数据的串联，例如下一个请求的入参需要上一个请求 的返回值； 找谁造数、造什么样的数，时间往往都消耗在沟通上。 基于以上痛点和难点，并结合对测试数据实际准备过程中相关问题的探索和研究形 成了长链路业务测试数据快速构造方法论，主要包括场景梳理、功能编排、数据构造、

从一加的 「故事」开始 一加的故事 国家和地区 1/40+ 业务发展太快 办公地点 1/10+ 跨区域办公和协作 人员 <10/900+ 沟通磨合成本高 系统 0/30+ 开发压力巨大 不到一年的时间 0 25 50 75 100 14Q1 14Q2 14Q3 14Q4 15Q1 15Q2 部门人数 系统数量 聚焦，聚焦，集中火力开火 业务优先，区分核心业务，重要性四象限 业务先行，基础建设适当的平衡和取舍，一步一步来 重视规划和系统思维的作用，根据现状随时调整轻重缓急 充分的沟通机制和反馈机制，让大家都能有一致的理解 聚焦与系统思维 技术和管理比重随时调整和平衡 技术、业务和管理的平衡 技术管理者大多对技术热衷，对管理忽视 技术、业务、系统花费精力和时间太多，团队管理精力太少 除了专业能力，文化和创业精神很重要 辞退要迅速，过程要明确和清晰 永远不要忽视沟通的作用和力量 沟通的力量 观念和思维的碰撞，不同文化不同背景快速聚集带来的必然摩擦 不就是这里改一下么，不就是流程调整一下么？ 沟通、沟通、沟通、无他 不同的对象，沟通方式不一样，灵活处理，使用不同的技巧 沟通只是第一步，形成固定机制，落实并执行才最重要 Motivation

性能监控 注册发现 服务管理 www.163yun.com ZIP源码包 持续集成 重新开发 迭代修改 个性开发 统一模版 接口统一 利于复用 文档一致 减少沟通 某视频监控企业：IT资产沉淀与IT能力复用 持续集成 容器化 注册发现 服务管理 www.163yun.com 开发集群 测试集群 CICD (开发流程管理) 告警 认证 鉴权 统计 概览 知识 库 服务 告警 监控 大屏 账户 审计 注册，发现，调用都提供鉴权 认证鉴权 接口文档统一维护 文档与运行时一致 减少调用沟通成本 知识库 根据平台、租户、项目三个层次区分权限作用域 操作记录，审计日志，事件查询 账户审计 微服务框架负责服务之间的调用——企业级特性 www.163yun.com 某证券公司 线上 系统B 预发 环境 新上 线服 务 99% 1% 灰度发布 A/B测试 流量镜像 测试预发 新上服务 定时开关 接口文档统一维护 文档与运行时一致 减少调用沟通成本 可自行定制：路由插件，可开发插件拦截请求，进行定制化 API网关负责流量接入 www.163yun.com 微服务框架 (服务治理) 服务 目录 注册 发现 限流 熔断

代码质量责任应该左移 设计 代码 开发 代码 评审 入库 测试 发布 1. 非研发人员主导，沟通成本高，推动修复周期长 2. 很难形成标准推动研发实施 3. 形成技术债，偿债成本高 1. 代码签入前，研发人员有义务修复问题 2. 测试人员早期加入，更懂项目研发的情况，沟通成本低，加快上线 3. 能逐步形成好的编码规范和最佳实践 检查代码风格问题挺准，但是 我warning都不看，还看这个？ 无需额外操作，不改变程序员习惯的流程  只分析变化的代码引起的问题  使用频次高，可形成数据驱动的分析器改进和 代码质量监控  推动规范落地和培训教育新员工  提高人工评审效果  零培训成本强制使用 基于gitlab的自动代码评审演示

10%~15%。 未来我们还将在以下技术方向继续进行探索： 1. 多场景知识迁移 到店广告场景众多，不同广告位维护不同的图召回模型带来的维护成本较大。多场景 的联合训练既能丰富图数据，提升用户兴趣的刻画，又能将单个图召回模型应用到不 同广告位，降低维护成本。但是用户在不同广告位下的行为存在差异，数据融合不当 可能导致引入噪声，影响模型训练结果。如何在模型设计中刻画用户在不同广告位下 行为的共同点和差异点，是需要重点考虑的内容。 Cube 的概念下，开展通过一个序列统一建模用户所处情境偏好的探索工作。 下文继续介绍长序列工程优化实践。长序列模型会为线上服务带来一系列工程挑战， 序列长度变长极大增加了服务时数据传输成本与模型推理成本，需要针对这两个方面 做专门优化。 ● 数据传输优化：重复检索信息压缩。以 tag_id 检索为例，由于方案中采用的 是较为粗的品类划分，tag_id 本身数量是非常有限，一次请求 batch MMOE（64Experts） +0.44pp +0.41pp +0.23pp +0.48pp 引入大数量级 Experts 的 MMOE 结构可带来较显著的离线收益，但同时也会相应带 来离线训练以及线上服务成本的增加，需要做效果与效率之间的权衡。我们在保持一 定离线训练时长与在线 Latency 约束下，选择了 4Experts MMOE 版本作为新的基 线模型，并做详细的探索，进行较为细致的优化，包括：

微服务架构是⼀一种架构模式，它提倡将单⼀一应⽤用程序划分成⼀一组⼩小的服务，服务 之间互相协调、互相配合，为⽤用户提供最终价值。每个服务运⾏行在其独⽴立的进程 中，服务与服务间采⽤用轻量级的通信机制互相沟通（通常是基于HTTP协议的 RESTful API）。每个服务都围绕着具体业务进⾏行构建，并且能够被独⽴立的部署到 ⽣生产环境、类⽣生产环境等。另外，应当尽量避免统⼀一的、集中式的服务管理机 制， 部署成功率很低，部署时经常 有⼀一堆环境修改需求，运维⼈人 员出错机会增加，运维效率极 低。 ⽆无法快速有效定位问题，⽆无法 快速有效知晓服务运⾏行状态， 服务资源浪费。 回到问题 3.服务拆分 微服务的附加成本 3.服务⾃自演进 2 1 2 3 划分合适的业务边界 进⾏行合适模块化 可测试的 4 拒绝跨上下⽂文的 数据表连接 交付畅通 环境⼿手⼯工维护，频频出错 缺乏有效监控 服务过⼤大，堵塞交付 ⽆无法快速有效定位问题，⽆无法 快速有效知晓服务运⾏行状态， 服务资源浪费。 回到问题 11 8 5 3 所有⼈人？ 康威定律 设计⼀一个系统的任何组织所产⽣生 的设计和架构都等价于其组织间的 沟通结构。 —Melvyn Conway, 1967 康威逆定律 逐渐改进你的团队和组织结构 来促进你所渴望的软件系统架构。 —Sam Newman • 服务足够小  • 独立运行

LTS 发布 1500 + 社区贡献者 3 + 开源运营年数 7800 + Issues 数 10 + 功能迭代 19 个城市 125 ⽤户参与调研 15 家企业测试团队 1350 分钟沟通 注：LTS（Long Term Support）版本 2023 年 5 ⽉ 25 ⽇，MeterSphere v2.10 LTS 版 本正式发布。此版本在 测试能⼒、⽤户体验、系 统架构、系统安全 缺点： 维护与编写成本⾼，更加依赖测 试⼈员个⼈能⼒； 场景： 灵活的业务场景与测试⽅式。 02 03 04 优势： 适合团队，⽅便度量和集成； 缺点： 闭源商业化平台价格较贵，开源 平台的稳定性⽋佳和功能较少； 场景： 适合团队和集成 DevOps 等。 优势： 需求满⾜度⾼，⾃主可控； 缺点： 投⼊产出⽐低，研发⼈⼒成本级 别⾼； 场景： eterSphere 开源社 区调研了的 219 份企业表单，其中 82.19% 的报名者所在的团队正在建设 Web 端 UI ⾃动化测试系统。 UI ⾃动化的价值与问题 维护成本 + 学习成本 GUI 测试 接⼝测试 单元测试 ⾼ 低 业 务 覆 盖 快 慢 测 试 速 度 不是不想做 UI ⾃动化，⽽是如何解决两⼤核⼼问题？ UI 测试 MeterSphere

较慢 较快 故障隔离范围 线程级 进程级 整体可用性 较低 更高 架构持续演进 困难 简单 沟通效率 低 高 技术栈选择 受限 灵活 可扩展性 受限 灵活 可重用性 低 高 实现业务复杂性分解难度 困难 容易 产品创新复杂度 困难 容易 一致性实现成本 低 高 时延 低 高 资源成本 低 高 关联查询复杂度 简单 复杂 远程调用 不涉及 涉及 服务治理 不涉及 涉及 对开发人员的要求

apache.org [Github ] https://github.com/apache?q=servicecomb • 自底向上构建，通过原型快速迭代验证 • 全方位开放，分布式开发，跨公司沟通协作 • 开源项目是新技术的试验场 • 开源依托于社区不断发展壮大 • 一群热爱开源的人们，全身心投入自己的时间来进行开发 开源项目形成 [社区网站] http://servicecomb servicecomb-mesher 生产级的Service Mesh sidecar实现，帮助用户领侵入业务代码实现微服务化 Golang servicecomb-kie 语义型的配置中心，解决常规配置中心的语义学习成本高、管理成本高、拼接复杂和无法扩展问题 Golang servicecomb-toolkit 遵循OpenAPI的微服务开发工具，一键式生成微服务代码 Java servicecomb-fence 高性能、安全的微服务认证鉴权框架

Scaled Agile 大规模敏捷 ·王勉· 2018.12.13 环境 单一产品，逐步扩大敏捷团队。 问题1 敏捷团队太大，沟通成本太高。 问题1 问题2 团队部门化，团队成员缺少认同感。 问题2 产品 UE 前端 后端 测试 敏捷团队 问题3 团队成员缺乏使命感，开发更多感觉自己是资源 。 Scaling Agile@Spotify