一、测开的质量保证体系 

1. 需求与设计阶段：预防 “源头性质量问题”

• 需求评审与 “可测试性” 把关：

  • 参与需求文档评审，用 “测试思维” 提问，倒逼产品和研发明确边界场景。
  • 对模糊的要求和功能具体，产品量化标准

• 测试策略设计：

  • 提前规划 “该功能需要哪些测试类型”（功能 / 性能 / 兼容性 / 安全）
  • 输出 “测试点清单”：基于需求拆解核心场景（正常流程、异常流程、边界条件）

关键工具 / 方法：需求管理工具（Jira/Confluence）、思维导图（梳理测试点）、用例管理平台（TestRail / 自研平台）。

2. 开发阶段：拦截 “代码级质量问题”

⭐ 推动单元测试落地：

• 制定覆盖标准：如核心模块覆盖率≥80%、必须覆盖异常场景，并将标准嵌入 CI 流水线（不达标则代码无法合并）。
• 代码质量走读：在 CI 流水线中集成静态代码分析工具（SonarQube），自动检测代码中的 “坏味道”（如空指针风险、冗余代码、安全漏洞）。比如代码扫描发现 “高危漏洞” 时，CI 自动阻断构建，研发必须修复后才能继续。
• 开发辅助工具：比如为研发提供 “单元测试模板”“Mock 工具使用指南”，降低写单元测试的成本。

 

⭐ 接口契约测试：

• 推动研发和测试基于 OpenAPI/Swagger 定义 “接口契约”（输入参数、输出格式、错误码），测开用工具（如 Pact、YApi）自动校验 “研发实现的接口是否符合契约”（避免接口开发完才发现格式不对）。

关键工具 / 方法：CI 工具（Jenkins/GitLab CI）、单元测试框架（JUnit/pytest）、静态扫描工具（SonarQube）、契约测试工具（Pact）。

3. 测试阶段：系统化验证 “功能与非功能质量”

• 自动化测试框架搭建：

  • 开发接口自动化框架（如基于 Python 的 Requests+Pytest）、UI 自动化框架（如 Selenium/Appium 封装）
  • 设计 “数据驱动” 模式：将测试数据（如不同账号、不同输入值）与脚本分离，通过配置文件或数据库管理，方便用例扩展（比如一个登录脚本可覆盖 10 种输入场景）。

• 非功能测试体系建设：

  • 性能测试：搭建性能测试平台（基于 JMeter/Gatling 二次开发），预设 “高频场景压测模板”（如秒杀、登录峰值），自动生成性能报告（响应时间、吞吐量、错误率）。
  • 兼容性测试：集成云测试平台（BrowserStack/Testin），实现 “一套脚本在多浏览器 / 多机型上自动运行”，输出兼容性报告（如某机型按钮错位）。
  • 自动化用例管理平台：搭建自动化用例管理平台，支持用例批量执行、报告自动生成。每次回归可以做到全量回归，精准回归等回归模式。还有其他的各种功能。

• 测试环境与数据管理：

  • 搭建 “一键部署测试环境” 的工具：通过 Docker/K8s 快速拉起包含后端服务、数据库、中间件的完整环境，避免因环境不一致导致的测试问题。
  • 开发 “测试数据生成工具”：自动生成符合业务规则的测试数据（如模拟 10 万条订单数据），避免手动造数的低效和错误。

关键工具 / 方法：接口自动化框架（Requests+Pytest）、UI 自动化工具（Selenium/Appium）、性能测试工具（JMeter）、云测平台（BrowserStack）、Docker（环境管理）。

4. 上线阶段：控制 “发布风险” 

• 发布流程自动化与校验：

  • 设计 “发布流水线”（基于 CD 工具如 ArgoCD/Jenkins）：自动执行 “部署前检查”（如配置文件是否正确、数据库脚本是否合规）、“灰度部署”（先发布 1 台机器验证）。
  • 开发 “冒烟测试脚本”：部署完成后，自动运行核心流程（如登录→下单→支付），验证基本功能是否正常，异常则自动回滚。很多团队会将核心冒烟用例自动化，配置在 CI/CD 流程中（如通过 Jenkins、GitLab CI 触发）。当代码合并到测试分支并部署后，自动化脚本自动执行冒烟测试，测试人员负责查看结果并判断是否通过，这种情况下测试人员是结果的审核者

• 配置与权限管控：

  • 搭建配置中心：统一管理不同环境的配置（如测试 / 生产的数据库地址），避免人工修改配置导致的错误，测开负责配置变更的自动化校验（如配置格式是否正确）。

关键工具 / 方法：CD 工具（ArgoCD）、灰度发布平台（自研 / 开源工具）、冒烟测试脚本、配置中心（Apollo/Nacos）。

5. 上线后：监控 “线上质量” 与快速响应 

• 全链路监控与告警：

  • 集成 APM 工具（如 SkyWalking/Pinpoint）：监控接口响应时间、错误率、数据库慢查询等，设置阈值告警（如接口错误率＞1% 时触发告警）。
  • 开发 “用户行为追踪” 工具：记录用户操作路径和异常（如页面崩溃、按钮点击无响应），辅助定位前端问题。

• 故障复盘与自动化回归：

  • 线上故障修复后，测开补充 “针对性测试用例”（如复现故障的场景），并加入自动化脚本（包：cyf_线上问题），避免同类问题再次出现。
  • 定期分析 “线上问题类型”（如接口超时、UI 兼容性），反推体系漏洞（如性能测试未覆盖高并发场景），优化前序环节。

关键工具 / 方法：APM 工具（SkyWalking）、日志分析平台（ELK）、告警系统（Prometheus+Grafana）、故障复盘流程（5Why 分析）。

6. 持续优化：让体系 “自适应” 业务变化 

目标：质量体系不是一成不变的，需要随业务迭代（如从单体到微服务）、团队规模扩大而进化。

• 质量数据看板建设：

  • 收集各环节数据（单元测试覆盖率、自动化用例通过率、线上故障数），生成可视化看板，暴露体系瓶颈（如某模块覆盖率持续低于标准）。

• 工具链迭代：

  • 当业务从 Web 扩展到 App 时，测开扩展自动化框架支持 App 测试；当微服务拆分后，补充 “服务间调用链测试” 能力。

⭐ 总结：体系的核心是 “闭环” 

这个体系的每个环节都不是孤立的：

• 需求阶段的测试点会转化为开发阶段的单元测试用例、测试阶段的自动化脚本；
• 线上故障会反推到开发阶段补充单元测试、测试阶段增加覆盖场景；
• 测开的角色是 “体系的搭建者和维护者”—— 通过工具将流程标准化，通过数据发现问题，最终实现 “质量问题越来越少，解决成本越来越低”。

二、什么是全链路 

⭐ 全链路的核心特点

1. 覆盖完整流程：从用户操作的起点（如点击 App 按钮、输入网址）到最终结果（如页面加载完成、订单提交成功），包含所有参与的技术组件和业务环节。
   例如：一个电商 App 的 “下单” 全链路可能包括：
   前端页面（用户点击下单）→ 后端接口服务（接收请求）→ 订单系统（创建订单）→ 支付系统（处理支付）→ 库存系统（扣减库存）→ 消息队列（发送通知）→ 前端页面（显示下单成功）。

2. 跨系统 / 跨服务协同：在分布式系统（如微服务架构）中，全链路往往涉及多个独立服务、数据库、缓存、第三方接口（如支付网关、物流系统）等，需要这些组件协同工作。

3. 可追溯性：全链路强调对整个流程的追踪能力，通过日志、链路追踪工具（如 Jaeger、Zipkin）等，可定位某个环节的问题（如哪个服务响应超时、哪次数据库查询出错）。

⭐ 全链路在不同场景中的应用

1. 全链路压测（性能测试）
   模拟真实用户流量，对整个业务链路（而非单一服务）进行压力测试，验证系统在高并发下的整体性能。例如：大促期间测试电商平台的 “浏览商品→加入购物车→下单→支付” 全链路，观察在 10 万用户同时操作时，整个链路的响应时间、吞吐量、各节点的资源占用（CPU、内存等）是否符合预期。

2. 全链路追踪（分布式追踪）
   在微服务架构中，一个请求可能经过多个服务，通过全链路追踪工具，可记录请求在每个服务中的流转路径、耗时、状态等，快速定位跨服务问题。
   例如：用户反馈 “支付后订单状态未更新”，通过全链路追踪可发现：支付系统已完成扣款，但通知消息未通过消息队列发送到订单系统，从而定位问题出在消息队列或支付系统的通知逻辑。

3. 全链路灰度发布
   在系统更新时，通过全链路控制，让部分用户流量先经过新版本的链路（包含新服务、新功能），其他用户仍走旧链路，验证新版本在完整链路中的稳定性，再逐步扩大范围。

4. 全链路测试
   测试团队从用户视角出发，验证整个业务流程的端到端正确性，确保各环节协同无误。例如：测试 “用户注册→登录→修改个人信息→退出” 全链路，确认每个步骤的衔接没有漏洞（如注册后能否正常登录、信息修改后数据库是否同步更新）。

三、CICD

CI 和 CD 是 DevOps（开发与运维一体化）体系中的核心概念，用来描述软件从开发到上线的自动化流程

• CI（Continuous Integration，持续集成）：
  指 “开发人员频繁地将代码提交到共享仓库（比如 Git），每次提交后自动触发一系列检查（如编译代码、运行单元测试、代码风格扫描等），快速发现代码合并时的问题”。
   

• CD 有两种常见解释：

  • Continuous Delivery（持续交付）： CI 通过后，自动把代码部署到测试服务器，供测试人员验证。
  • Continuous Deployment（持续部署）：比持续交付更彻底，代码通过所有检查后，自动部署到生产环境（无需人工干预）。比如大厂的一些后台服务，每天几十次迭代，都是通过持续部署自动上线的。

四、什么是质量左移？

质量左移（Quality Shift Left）是软件开发生命周期中一种强调将质量保障活动提前到开发早期阶段的理念。

简单说，就是 “把问题解决在萌芽状态”—— 比如开发人员在写代码时就通过单元测试、代码评审等手段保证质量，而非等到测试阶段才发现 bug。

根据开发提出的测试金字塔，越远离代码的测试起来越越慢，解决成本越高。

要想提升效率，在代码走读和单元测试环节自测去预防是最好的。

五、测试人员需要懂单元测试 

测开不需要 “替研发写单元测试代码”，但需要 “懂单元测试的规则、工具和价值”

 因为测开的核心是 “通过体系化的方法保障质量”

而单元测试是这个体系中最基础、最关键的一环。

CI/CD 则是这个体系的 “自动化载体”，测开需要把单元测试等质量要求 “嵌入” CI/CD 流水线，让质量保障从 “人工督促” 变成 “自动执行”—— 这正是大厂测开的核心价值之一。

1. 设计单元测试覆盖率标准和要求

规定哪些场景必须覆盖，覆盖率值

指出没覆盖到的怎么补充
 

• 测开需要知道 “哪些场景必须被单元测试覆盖”（比如支付金额的边界值、用户权限的校验逻辑）；
• 测开需要用工具统计覆盖率，判断研发的单元测试是否 “凑数”（比如只覆盖了简单流程，漏掉了异常场景）；
• 如果研发的单元测试没达标，测开要能指出 “具体哪里没覆盖”“应该怎么补充测试用例”

2. 帮研发解决单元测试的痛点

使用甚至研发单元测试工具解决：模拟依赖，辅助单元测试，优化代码可测性

• 教研发用 Mock 工具模拟依赖（比如模拟数据库返回值，让单元测试不依赖真实环境）；
• 开发辅助工具（比如自动生成单元测试模板、批量执行测试用例的脚本），降低研发写单元测试的成本；
• 甚至优化代码的 “可测试性”（比如建议研发把一个 500 行的大函数拆分成多个小函数，方便单独测试）。
   

3. 测开需要将单元测试 融入质量体系流程

CI自动化执行单元测试，阻断不合格的代码提交。

单元测试没覆盖到的，记录下来后续黑盒测试流程保证覆盖到。
 

• 测开搭建的 CI 流水线，需要自动触发单元测试（如用 Jenkins 调用 JUnit 跑测试），并将测试结果（覆盖率、失败用例）同步到质量平台（供研发和测试查看）；
• 当单元测试覆盖率低于阈值时，测开需要配置流水线 “阻断代码合并”，强制研发补充测试；
• 测开还可能需要分析单元测试和后续测试的关联（比如 “单元测试没覆盖的分支，在接口测试中是否被覆盖了”），避免质量盲区。

六、web和移动的兼容性区别 

⭐ Web 端兼容性测试：核心是 “浏览器 + 操作系统” 的组合

Web 应用运行在浏览器中，而浏览器本身依赖操作系统，因此兼容性问题主要来自两个层面：

• 浏览器差异

  • 不同浏览器的内核（如 Chrome 的 Blink、Firefox 的 Gecko、Edge 的 Chromium、Safari 的 WebKit）对 HTML/CSS/JavaScript 的解析规则存在差异，可能导致：
    • 页面布局错乱（如按钮错位、文字重叠）；
    • 功能失效（如 JavaScript 脚本在某浏览器中报错，导致点击无响应）；
    • 样式不一致（如 CSS 动画在 Safari 中不生效）。

• 操作系统影响

  • 操作系统会影响浏览器的渲染细节（如字体渲染、滚动条样式），以及浏览器对系统资源的调用（如文件上传控件在 Windows 和 macOS 上的外观和交互逻辑不同）。
  • 极端情况下，某些老旧操作系统（如 Windows 7）可能不支持新版本浏览器，而低版本浏览器又不支持 Web 应用的新特性（如 ES6 语法），形成 “系统 - 浏览器” 的连锁兼容性问题。

⭐ App 端兼容性测试：核心是 “机型 + 系统版本” 的组合

App 直接安装在设备上，依赖设备的硬件和系统，因此兼容性问题更复杂，除了系统，还与硬件强相关：

• 机型适配（硬件差异）

  • 屏幕尺寸 / 分辨率：不同机型的屏幕大小（如 6.7 英寸 vs 5.5 英寸）、分辨率（如 720P vs 2K）可能导致 UI 元素被截断、拉伸或排版错乱（比如按钮在小屏手机上被遮挡）。
  • 硬件性能：低端机型的 CPU、内存、显卡性能较弱，可能导致 App 卡顿、闪退（如复杂动画在低配手机上无法流畅运行）。
  • 设备特性：如不同品牌手机的摄像头权限、传感器调用逻辑不同，可能导致依赖这些功能的 App 出现异常。

• 操作系统版本（软件差异）

  • Android：各品牌（华为、小米、OPPO）会对原生 Android 系统进行定制（如 EMUI、MIUI），且系统版本迭代快（从 Android 10 到 Android 14），不同版本的 API 接口、权限管理规则可能不同（如 Android 13 对通知权限的严格限制）。
  • iOS：虽然系统统一性强，但不同版本（如 iOS 15 vs iOS 16）也可能存在 API 变更（如暗黑模式适配逻辑），且老旧机型（如 iPhone 8）可能无法升级到最新系统，需要单独适配。

⭐ 补充：两者的共性与测试策略

• 共性：都需要覆盖 “正常场景 + 边缘场景”（如 Web 端的低版本 IE、App 端的低配安卓机），且越来越依赖自动化工具（Web 用 Selenium+BrowserStack，App 用 Appium+Testin 云测）。
• 差异策略：
  • Web 端：优先覆盖市场占有率高的浏览器（如 Chrome、Edge）和主流操作系统（Windows 10/11、macOS Ventura），对低占有率的浏览器（如 IE）可降低测试优先级。
  • App 端：除了覆盖主流机型（如 iPhone 14、小米 13），还要重点关注目标用户群体的设备分布（如下沉市场多为中低端安卓机），并通过 “灰度发布” 收集真实用户的兼容性反馈。

七、web端和移动端的自动化区别 

UI 自动化依赖 “前端载体的物理特性”，而接口 / H5 依赖 “通用的网络协议或网页标准”

⭐  ui自动化的区别（前端载体的物理特性不同）

• Web 端：元素是浏览器渲染的 HTML 标签（如<button> <input>），用 Selenium 定位时依赖id xpath css selector等，操作是click() send_keys()等浏览器 API；
• App 端（原生）：元素是系统控件（如 Android 的TextView、iOS 的UIButton），用 Appium 定位时依赖accessibility_id uiautomator xpath（原生控件的 xpath），操作是tap() send_keys()（但底层调用的是系统手势 API）。

但可以通过 封装抽象层 减少重复：比如设计一个统一的 “操作接口”（如click_element()），底层分别实现 Web 版（调用 Selenium）和 App 版（调用 Appium），脚本层只需调用抽象接口，无需关心底层是 Web 还是 App。这种方式能复用脚本的 “业务逻辑”，但仍需维护两套底层实现。

⭐ 接口自动化：修改请求头即可复用，因为接口与前端无关

接口自动化的核心是 “调用后端 API”，而 Web 和 App 本质上是 “不同前端调用同一批接口”（除非 Web 和 App 用了完全独立的后端，这种情况极少）。

接口脚本只需发送 HTTP 请求，通过修改 请求头（Header） 即可模拟不同客户端：

• 比如设置User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/114.0.0.0 模拟 Web 端浏览器；
• 设置User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; MI 13 Build/TKQ1.221114.001) 模拟 Android App；

后端会根据User-Agent判断客户端类型（Web/App），返回对应数据。因此，接口脚本无需大幅修改，仅调整请求头即可覆盖 Web 和 App 的接口场景，复用性很高。

⭐H5

当 H5 在 App 的 WebView 中运行时，测试步骤是：

用 Appium 启动 App，进入包含 H5 的页面（此时需要 Appium 的基础能力，比如启动 App、点击进入 H5 页面的按钮）；

通过 Appium 切换到 WebView 上下文（driver.context("WEBVIEW_com.xxx.app")），此时 Appium 会把 WebView 当成一个 “内嵌浏览器”；

切换后，就可以用 Selenium 的 API 定位 H5 元素（id xpath等和 Web 端完全一样），操作逻辑也和 Web 端脚本一致（click() send_keys()）。

也就是说：测试 H5 时，仅需 Appium 做 “启动 App + 切换上下文” 的铺垫，核心操作复用 Web 端的 Selenium 脚本，无需学习 Appium 的原生控件定位（如uiautomator），因此给人 “不用 Appium” 的感觉。