（目前已离职，上一份工作其实是以测试管理的身份入职的但回溯起来管理做得并不好，应该就是缺少老师所说的“自上而下”的思考与测试方案设计。借此作业的机会，重新把时间拨回当初入职的时候，进行一次测试方案的设计。可能多少带点上帝视角的意思在里头hhh）
背景介绍
XXXXX是国内首个创新型机械设计版本控制管理平台，借鉴 Git 的版本控制理念支持对工业/机械设计图纸进行历史追踪，并提供云端实时查看机械模型等功能。该平台旨在解决工业/机械设计师杂乱无序、难以回溯的图纸管理工作，为国内工业/机械设计流程提效。
业务介绍
XXXXX系统同时提供云端、客户端两套软件，云端负责模型实时查看、图纸审批等功能，客户端负责工程师的日常图纸版本管理。
架构介绍
测试目标
当前问题
- 项目从0到1，缺少测试体系
- 产品已面世4年，此前从未有过专职测试，测试债务很重，用户投诉率≥1次/天
- 刚融完资，急需快速开发上线MVP需求去抢占市场
- 当前只有本人一个测试，无法同时应对测试债务和MVP需求两条主线任务
- 开发侧存在对需求还原度不高、对用户体验要求低等问题
- 产品解决方案层和核心引擎层的测试没有区分开，业务测试不具备引擎测试的专业知识，且解决方案层转测时还需要把引擎层的冒烟测试走一遍
| 四象限 | 紧急 | 不紧急 |
|---|---|---|
| 重要 | 1. 建设测试体系，规范测试流程 2. 清空测试历史债务，降低用户投诉率 3. 招聘1名高级性能测试+1名具备敏捷DevOps经验的高级测试开发 4. 对MVP需求进行迭代测试 5. 提高开发的需求还原度和产品用户体验 |
1. 建立测试团队分享机制，每月N次性能测试/自动化测试的团队赋能 2. 将引擎测试任务从业务侧剥离 3. 搭建分层自动化测试体系 4. 针对开发对需求还原度不高、对用户体验要求低等问题，建立需求串讲环节 |
| 不重要 | 1. 与运营、开发一同承接用户投诉反馈，修复并验证Bug上线（不太确定放在不重要一栏会不会不妥，因为感觉清理历史债务的时候这些Bug都会清理掉） | 无 |
测试方案的主要目标为
| 阶段 | 目标 | 时间 |
|---|---|---|
| 阶段一 | MVP迭代上线（功能+性能） 历史债务清除，降低用户投诉率（功能+性能） 解决开发需求还原度低、对用户体验要求低等问题 将引擎测试任务从业务侧剥离 |
Q1+Q2 |
| 阶段二 | 分层自动化测试体系搭建 自动化测试开发 团队赋能 |
Q2 |
| 阶段三 | 自动化测试开发 团队赋能 效能提升 |
Q3+Q4 |
测试策略
1. 测试人员招聘
- 【性能测试】招聘一名5年经验以上、能够提供完整性能测试方案的性能测试人员，主要负责业务测试、性能压测，后期进行自动化赋能。
- 【测试开发】招聘一名5年经验以上、能够完成分层自动化测试体系搭建的测试开发，主要负责业务测试、自动化测试，后期进行性能测试赋能。
2. 测试流程体系搭建
【流程原则】
- 是测试但又不止测试，倡导岗位模糊化，发挥测试左移、右移价值。
- 以两周为迭代周期，进行合理、小粒度的feature迭代；如果feature预估周期大于两周，则需要提前向团队负责人报备、或继续进行feature拆分。
- 测试流程同时适用于MVP新需求和历史债务需求的测试。历史需求需要多加一步确认，确认是否需要进行重测，比如将要下线的历史功能不予重测，使用量低的历史功能重测优先级降低。
【流程详情】
- 【需求评审】深度参与需求评审环节，站在用户视角对需求中模糊、不合理的内容提出改进建议。在这一阶段需要提前识别项目风险，并做好应对策略。同时，这一阶段需要强调数据埋点的设定。
- 【设计评审】走查UI设计原型图，站在用户视角对设计稿中不合理的交互点提出改进建议。
- 【技术方案评审】参与技术方案评审，与研发达成约定，明确输出技术方案产物（如架构图、接口文档等）。同时，这一阶段需要尽可能确认开发对需求的理解与产品、测试已达成一致。
- 【测试排期】根据需求、设计、技术方案的综合情况进行测试排期，输出产物为测试排期表（包括功能测试、性能测试、自动化测试开发等）。
- 【测试设计/评审】结合需求文档、设计原型图和技术方案，对新需求进行测试设计，输出产物为测试点脑图（包括功能、性能、接口用例）。拉通产品、开发等同事，对测试点脑图进行评审，并根据评审意见进行测试点修改。同时，选取冒烟测试用例。
- 【接口测试】这一步可以根据前后端开发情况，如后端开发较快则可以提前进行接口测试，否则可以在功能测试之后、自动化测试之前开展。
- 【冒烟测试】转测前执行冒烟测试，通过后方可转测。
- 【提测/功能测试】先执行第一轮功能测试并提交Bug，再对Bug进行回归，最后根据Bug整体情况决定是否需要执行第二轮功能测试。
- 【性能测试】当Bug趋势趋于收敛或完全解决之后，开始性能压测（这一步可选，不一定每个迭代都会涉及到后端业务的增改）。
- 【自动化测试】当Bug趋势趋于收敛或完全解决之后，开始自动化测试脚本开发。其中，UI自动化选取冒烟测试用例进行开发，接口自动化测试则尽可能全部开发，如果时间赶就先开发P0和P1用例，P2和P3可以延后开发。
- 【回归测试】（可选）如果性能测试过程中发现较严重Bug而对后端业务逻辑进行了修改，则需要重新选取部分功能测试用例进行回归。
- 【灰度发布】在灰度环境进行feature发布，并验证冒烟测试用例（可自动化验证）。
- 【产品验收】产品经理（项目经理）在灰度环境上进行feature验收。
- 【测试报告】根据测试情况，编写测试报告，阐述测试质量与项目风险。
- 【正式上线】灰度环境发布没有问题之后，正式将feature上线到生产环境，并在生产环境上验证冒烟测试用例（可自动化验证）。
- 【生产监控】上线后一周内，通过Prometheus、埋点系统对feature情况进行持续监控。
- 【迭代复盘】针对产研团队在此feature周期中的各个情况进行表扬或复盘，如有值得后续团队赋能的技术案例则需要进行归档。
发布质量要求 ：feature质量需要达到用例通过率95%、且无致命严重问题遗留的标准，方可上线。
3. 建立开发串讲需求环节
具体实施步骤如下
- 先在若干个feature迭代过程中，收集开发对于需求还原度低、对用户体验要求低的案例
- 拉上开发负责人，针对当前情况进行沟通交流
- 提出“需求评审后，开发需要在设计方案前对需求进行串讲演示”这一环节
预计效果：转测一次通过率由0%提升到80%
4. 搭建分层自动化测试体系
UI自动化
- 明确UI自动化测试开发范围：冒烟测试用例
- 以pytest+selenium/playwright为基础，配合PO模式，搭建E2E自动化测试框架
- 对自动化测试框架补充make入口封装、数据驱动、飞书结果通知、用例筛选等功能
- 将UI自动化测试集成到CI/CD中，在开发集成feature分支、合并feature到master分支、发布master分支到生产环境等重要节点上自动触发UI自动化测试；同时，设置schedule每日定期自动巡检
- 支持分布式测试、并发测试，至少5个并发同时执行UI自动化测试
- 无论历史需求还是MVP新需求，都应该在feature迭代周期内完成相应的脚本开发
接口自动化
- 明确接口自动化测试开发范围：全部接口测试用例
- 明确接口自动化测试开发优先级：按照P0/P1优先开发，P2/P3最后开发的原则推进
- 以pytest+requests+mysqldb为基础，搭建接口自动化测试框架
- 对自动化测试框架补充make入口封装、数据驱动、飞书结果通知、用例筛选等功能
- 将UI自动化测试集成到CI/CD中，在开发集成feature分支、合并feature到master分支、发布master分支到生产环境等重要节点上自动触发UI自动化测试；同时，设置schedule每日定期自动巡检
- 支持分布式测试、并发测试，至少20个并发同时执行UI自动化测试
- 无论历史需求还是MVP新需求，都应该在feature迭代周期内完成相应的脚本开发
自动化测试预期效果
- 将冒烟测试时长从1人/天缩短至20分钟
- 如冒烟测试发现Bug，1分钟内相关开发和测试可以接收到反馈
5. 将引擎测试与业务测试剥离
具体实施如下：（核心思想为引擎组独立运作）
- 向上阐述业务测试与引擎测试耦合在一起不利于快速迭代，且引擎测试的专业度较高，业务测试人员无法cover
- 与引擎组负责人合作 ，招聘一位同时具备测试领域知识和工业建模领域知识的专项测试人员，专门负责引擎需求测试
- 引擎迭代改为以月为单位的瀑布模式，不参与业务层的敏捷迭代
- 用户投诉信息区分处理，业务侧归业务组负责跟进，引擎侧归引擎组负责跟进
6. 团队赋能
自动化测试赋能
- 组织单月4次、每次2小时的UI自动化测试分享培训，培训结束时进行验收，预计测试组3人+前端1人能掌握规范开发UI自动化测试脚本
- 组织单月2次、每次2小时的接口自动化测试分享培训，培训结束时进行验收，预计测试组3人+后端1人均能掌握规范开发接口自动化测试脚本
性能测试赋能
- 收集团队内部性能问题案例
- 搜寻业内性能测试案例
- 组织单月2次、每次1小时的性能测试分享培训，覆盖JVM内存溢出、JVM线程阻塞、MySQL连接数、MySQL慢索引等场景
- 培训结束时进行验收，预计测试组3人+后端2人能够达到30分钟内定位性能瓶颈点的水平
7. 效能提升
搭建测试资产管理平台
团队使用飞书作为日常沟通渠道，面对测试组员经常抱怨“开发经常不看TAPD上的Bug”这一问题,透过问题看到核心原因是“TAPD不能发送Bug通知到飞书用户”，并以飞书多维表格搭建起新一套测试资产管理系统Testhub，利用飞书消息通知直接将Bug发给开发。
提效效果：开发的响应Bug时间从最长2天缩短到最多10分钟。
启用一站式压测平台MeterSphere
团队前期在性能测试方面，压测是使用Jmeter，压力端监控是influxDB+Prometheus，服务端监控是node_exporter+Prometheus。这一套方案有一个问题是，做容量测试过程中需要频繁地在发压端和监控端之间来回切换，还要手动记录各个并发下的TPS值。通过调研一站式压测平台并选择MeterSphere作为团队后续使用的压测平台。（兼容Jmeter脚本，自动生成容量测试模型，集成所有指标监控等）
提效效果（预计）：单个接口的压测时长预计减少30分钟
搭建QA知识库
搭建QA知识库，持续输出产品业务知识测试要点文档+测试心得文档。
提效效果：
- 帮助缩短测试新人上手时间（1周=>2天）
- 大幅降低测试设计遗漏率（从前期评审过程中出现一大块功能遗漏到后期基本无遗漏）