测试管理

1、你如何搭建或管理测试团队？团队分工怎么定

按业务线/模块划分测试Owner + 专项角色（自动化、性能、安全）
【老员工带新员工】新人配对导师，周会同步进度，用例/bug规范统一。推行冒烟准入、提测单、回归基线，定期做漏测复盘。

2、如何制定测试流程和提测规范

开发自测通过 → 提交提测单 → QA冒烟（P0用例）→ 不通过打回
测试周期按排期×风险系数预留缓冲
上线前需完成：回归覆盖 ≥ 设定比例、严重Bug清零、产品/开发签字

3、怎样衡量测试团队绩效

Bug有效发现率、漏测率（线上严重Bug数）【线上事故、投诉】
用例覆盖率、自动化用例增长率
提测打回率、版本延期次数（协同指标）【工作完成进度，是否经常版本延期】
专项：压测报告完整性、线上故障跟进闭环率【问题跟进推到能力】

4、你们公司质量保障体系是怎样的

需求评审（测试提前介入）→开发技术方案评审→测试设计（等价类/边界/场景法）+用例评审→ 接口测试先行 → UI自动化回归 → 
预发灰度验证 → 线上监控（日志告警+用户反馈跟踪）→ 事故复盘（5Why分析法）

5、如何降低线上漏测？

关键路径自动化覆盖 + 探索性测试补充
用例评审由产品+开发+测试共同参与
上线后线上巡检 + 用户行为埋点监控
重大故障写复盘报告，反哺用例库
版本上线前推行公司内测，让公司不同角色体验上线版本提出意见和反馈，测试跟踪

6、测试和开发就Bug等级/是否修产生分歧怎么办

以影响范围+重现概率+用户场景为准，引用日志/录屏佐证；无法达成一致时由PM或技术负责人仲裁，不情绪化对抗，保持质量底线

7、自动化测试如何规划？什么该自动化什么不该

适合：主流程回归（登录-Pay-播放-下单）、接口层、稳定模块
不适合：频繁变更UI、一次性活动页、未定稿原型
分层策略：接口自动化 > UI自动化，接口用 pytest+requests，UI用 Selenium/Appium（PO模式）

8、接口测试和UI测试的占比你怎么把控

接口覆盖核心业务逻辑 70%~80%，UI只覆盖主流程回归 + 兼容性关键点，避免大量脆弱UI用例拖慢迭代。

9、性能/安全测试你们怎么做

性能：JMeter/Locust 压测核心接口（QPS/TPS/RT/错误率），找到拐点；数据库慢查询分析
安全：SQL注入/XSS/CSRF基础扫描，敏感信息脱敏，权限越权测试

10、项目工期紧、开发提测晚，你怎么应对

提前拆分：接口测试先写（Mock）、P0用例优先
评估风险上报PM，申请延长或砍非核心测试范围
上线后补测 + 加强线上监控

11、推动开发写单测或改善提测质量，你怎么做

制定提测检查清单（自测截图/单测覆盖率）
数据说话：展示提测打回率与后续返工成本
纳入研发规范，和TL达成共识

12、漏测率（线上缺陷漏测率）

衡量测试未发现的线上 Bug 占比，是最受老板关注的质量指标

漏测率 = 线上发现的缺陷数（严重/主要等级）
        ————————————————————————————————————
        测试阶段发现的缺陷数 + 线上发现的缺陷数
        × 100%

分子：上线后一定周期内（如 30 天）发现的 线上 Bug 数
通常只统计 Major / Critical，不包含提示性小 Bug

分母：测试阶段提交的 Bug 数 + 线上 Bug 数
统计维度可按：版本 / 季度 / 产品线

示例：
测试中提交 190 个 Bug
上线后 30 天内线上发现 10 个 Major Bug
漏测率 = 10 / (190 + 10) ≈ 5.0%

线上 Bug 需经过复盘确认确属测试遗漏，而非需求变更引入
目标值一般：≤ 3%~5%（核心系统），≤ 5%~8%（普通业务）

13、自动化测试覆盖率

用例自动化覆盖率（管理视角常用）
自动化用例覆盖率 = 已实现自动化执行的用例数
                  ————————————————————————
                  总用例数（或回归用例总数）
                  × 100%

一般只算回归用例集（P0/P1）
示例：回归用例 300 条，自动化 180 条 → 60%

代码覆盖率（技术视角）
代码覆盖率 = 被自动化/单测执行到的代码行数
             ————————————————————————————
             总代码行数（或方法/分支）
             × 100%

工具：Jacoco（Java）、coverage.py（Python）、Istanbul（JS）
通常关注增量代码覆盖率（新需求 diff 行）

14、Bug 打回率（提测打回率 / 冒烟不通过率）

衡量开发提测质量，也是测试经理推动开发自测的重要抓手
Bug 打回率 = 冒烟测试不通过被打回的提测次数
            ————————————————————————————
            总提测次数（同一版本多次提测累计）
            × 100%

判定标准（建议说明）
冒烟用例（P0）有不通过 → 打回，不进入正式测试
需在提测单中记录是否打回及原因

示例：
某版本共提测 5 次（含重新提测）
第 1 次冒烟失败打回，第 2 次通过
打回率 = 1 / 5 = 20%

管理目标：
逐步降低打回率（目标 < 20% 或首提通过率 > 80%）
配套：开发自测清单 + 单元测试要求 + 提测卡点