项目测试以及bug处理

项目测试以及bug处理

测试步骤

juejin.cn/post/714469…

juejin.cn/post/712782…

juejin.cn/post/700107…

1、测试全过程

• 需求分析和评审：确保自己理解需求并且对需求无疑义，能够支撑后续的测试用例设计。

• 编写测试计划和测试方案

  测试计划：描述要进行的测试活动的范围、方法、资源和文档进度，核心内容包括测试范围与目标、角色和职责、进度和资源、风险和应对方法、准入准出标准；

  测试方案：从测试的技术角度分析需求，在方向上明确怎么测，重点在于测试策略和技术实现。

• 设计测试用例和评审

  由测试人员根据需求文档设计测试用例，然后由测试组内成员或者项目组成员共同对测试用例进行评审。

• 执行测试用例

  执行测试用例就需要有对应的测试环境，测试环境部署之后才可以执行测试用例，首先需要进行环境搭建，前提是需要熟悉项目使用环境：

• • 运行的操作系统：linux windows-server
  • web服务器：Nginx tomcat apache
  • 项目数据库：MySQL Oracle SQLserver Redis MongoDB
  • 编程语言：Python go java PHP

  知道了项目所使用的环境就需要根据项目实际所需环境进行搭建，也可以使用docker进行环境部署，比较方便，具体需要根据不同的公司有不同的情况，环境搭建成功之后，就可以执行测试用例了。

• 缺陷bug管理，使用禅道等工具对已经发现的缺陷进行跟踪管理。

• 编写测试报告

• 当程序满足发布上线标准之后，就可以将程序进行发布上线了

2、具体测试内容

（1）四层测试策略体系

第一层：单元测试层（基础层）

• 目标：验证代码最小单元的正确性

• 范围：函数、类、工具方法、工具类、纯逻辑组件

• 执行频率：每次代码提交时自动执行

• 工具作用：

  • Jest：提供测试运行环境、断言库、Mock功能、覆盖率报告
  • React Testing Library：专门用于React组件测试，鼓励从用户角度测试
  • Vitest：更快的测试运行器，兼容Vite生态

• 质量标准：

  • 代码覆盖率要求：语句覆盖率>80%，分支覆盖率>75%
  • 测试用例必须覆盖正常路径、异常路径、边界条件
  • 每个测试用例保持独立，不依赖执行顺序

第二层：集成测试层（连接层）

• 目标：验证多个模块协同工作的正确性

• 范围：

  • API接口调用与响应处理
  • 组件与Redux/Vuex状态管理的交互
  • 多个服务/模块之间的数据流
  • 数据库操作与事务处理

• 工具作用：

  • Supertest：专门测试HTTP API，模拟请求并验证响应
  • MSW（Mock Service Worker） ：拦截网络请求，提供可控的模拟响应
  • Jest集成配置：在Jest基础上扩展集成测试能力

• 执行策略：

  • 在CI/CD流水线的构建阶段执行
  • 使用真实的数据库连接，但在隔离的测试数据库中运行
  • 每个测试用例执行后清理测试数据，保持环境干净

第三层：端到端测试层（用户视角层）

• 目标：模拟真实用户操作，验证完整业务流程

• 范围：

  • 用户注册、登录、退出流程
  • 核心业务路径（如电商的购物车到支付流程）
  • 关键用户交互路径
  • 跨页面、多步骤的复杂流程

• 工具作用：

  • Cypress：提供完整的E2E测试解决方案，包含测试运行器、断言库、Mock工具
  • Playwright：支持多浏览器自动化，提供更丰富的浏览器控制API
  • Puppeteer：Chrome官方无头浏览器控制工具

• 执行策略：

  • 在预发布环境或类生产环境中执行
  • 测试数据使用专门准备的测试账号和测试数据
  • 测试用例设计遵循"用户旅程"模式
  • 执行频率：关键路径每日执行，全量测试在发布前执行

第四层：专项测试层（质量保障层）

• 性能测试：

  • 目标：验证系统在预期负载下的性能表现
  • 工具：Lighthouse（网页性能）、k6（API负载测试）、JMeter（综合性能）
  • 指标：响应时间、吞吐量、并发用户数、资源利用率
  • 执行时机：每次大版本发布前，重要功能上线后

• 安全测试：

  • 目标：发现潜在的安全漏洞
  • 工具：OWASP ZAP（动态应用安全测试）、Snyk（依赖漏洞扫描）
  • 内容：SQL注入、XSS、CSRF、敏感信息泄露等
  • 执行时机：每周自动化扫描，每次发布前深度扫描

• 兼容性测试：

  • 目标：确保应用在不同浏览器、设备上的兼容性
  • 工具：BrowserStack、Sauce Labs（云端真机测试）
  • 范围：主流浏览器（Chrome、Firefox、Safari、Edge）的最新两个版本
  • 执行时机：每次发布前执行关键路径的兼容性测试

• 无障碍测试：

  • 目标：确保残障人士也能正常使用应用
  • 工具：axe-core、Lighthouse无障碍审计
  • 标准：遵循WCAG 2.1 AA级别标准
  • 执行时机：设计阶段和开发阶段持续关注，发布前专项检查

阶段	由谁负责	目的
开发自测	开发人员	确保基本流程不崩、不报错
测试用例设计	测试人员（QA）	全面覆盖功能场景
功能测试	QA	检查功能是否符合需求
兼容性测试	QA	手机型号、浏览器系统等是否正常
回归测试	QA	本次变更是否影响到旧功能
性能测试	QA	是否扛得住大量用户访问
安全测试	安全/QA	破解/越权/数据泄露风险
UAT 验收测试	产品 & 业务	最终业务端确认可上线

3、Bug处理全流程详解

一、前端项目的测试类型与流程

前端项目的测试是保障上线质量的核心环节，会根据测试粒度和测试目标分为多个层级，不同规模项目的测试策略略有差异，整体可分为基础功能测试和专项测试两大类：

（一）基础功能测试（按测试粒度从细到粗）

1. 单元测试（测 “最小功能单元”）

• 核心目标：验证独立的函数、组件、hooks 等最小单元的逻辑是否符合预期，比如一个表单校验函数、一个 React 自定义 hook、一个 Vue 组件的渲染逻辑。

• 适用场景：开发阶段的 “自测”，保障基础代码块的稳定性，尤其适合工具函数、通用组件。

• 常用工具：

  • 框架适配：React 用Jest + React Testing Library，Vue 用Vitest + Vue Test Utils；
  • 断言库：Jest 内置断言、Chai。

• 具体做法：

  • 对工具函数：测试入参边界值（如空值、异常值）、正常入参的返回结果；
  • 对组件：测试组件的渲染、props 传递、事件触发（如按钮点击是否调用回调）。

2. 集成测试（测 “模块间协作”）

• 核心目标：验证多个关联单元 / 模块组合后的功能是否正常，比如 “登录组件 + 接口请求模块 + 状态管理（Redux/Pinia）” 的完整登录流程。
• 适用场景：单元测试通过后，验证模块间的交互逻辑，避免 “单个单元可用，组合后失效”。
• 常用工具：同单元测试工具（Jest/Vitest），搭配接口 Mock 工具（如MSW、Mock Service Worker模拟后端接口）。
• 具体做法：模拟真实业务场景，比如测试 “用户输入账号密码→点击登录→接口请求→状态更新→页面跳转” 的全链路是否顺畅。

3. 端到端（E2E）测试（测 “真实用户场景”）

• 核心目标：模拟真实用户操作，验证整个前端应用的核心业务流程是否可用，覆盖从页面访问到功能完成的全链路。
• 适用场景：上线前的最终功能验证，重点覆盖核心链路（如登录、支付、下单、数据提交）。
• 常用工具：Cypress（易用性高、适合前端）、Playwright（支持多浏览器、多平台）。
• 具体做法：编写自动化脚本模拟用户操作，比如 “打开网站→进入登录页→输入账号密码→登录成功后跳转到首页→验证首页用户名是否正确显示”。

（二）专项测试（保障体验与安全）

1. 兼容性测试

• 核心目标：验证应用在不同浏览器、不同设备上的显示和功能一致性。

• 测试范围：

  • 浏览器：Chrome、Safari、Edge、Firefox（国内需覆盖 IE11 兼容版本，若有需求）；
  • 设备：PC 端（不同分辨率）、移动端（iOS/Android 不同机型、横竖屏）。

• 常用工具：BrowserStack（云端多设备测试）、Chrome DevTools 设备模拟器、真机测试。

2. 性能测试

• 核心目标：验证页面加载速度、交互流畅度是否符合预期，提升用户体验。
• 测试指标：首屏加载时间、LCP（最大内容绘制）、TTI（交互就绪时间）、FID（首次输入延迟）、资源加载大小。
• 常用工具：Lighthouse（Chrome 内置，生成性能报告）、WebPageTest（专业性能分析）、Chrome DevTools Performance 面板。

3. 安全测试

• 核心目标：排查 XSS、CSRF、依赖漏洞等安全风险。

• 具体做法：

  • 输入验证：测试表单输入特殊字符（如<script>）是否会触发 XSS；
  • 依赖扫描：用npm audit、Snyk 检测第三方依赖的高危漏洞；
  • 接口安全：验证 CSRF Token、接口权限校验是否生效。

4. 人工验收测试（UAT）

• 核心目标：由产品、测试、业务人员模拟真实用户场景，验证功能是否符合产品需求，兼顾 “功能正确性” 和 “用户体验合理性”。
• 适用场景：所有测试完成后、上线前的最终验收，重点关注业务流程的连贯性和交互体验。

（三）不同规模项目的测试策略

项目规模	测试重点	工具选型
小型项目（个人 / Demo）	核心功能自测、基础兼容性	Jest（简单单元测试）、Chrome 模拟器
中型项目（团队协作）	单元 + 集成 + E2E、兼容性	Jest/Vitest + Cypress、BrowserStack
大型项目（企业级）	全链路自动化测试、专项测试、批量兼容性	流水线集成测试（GitLab CI）、Sentry（预发环境错误监控）、专业安全工具

二、测试中遇到 bug 的处理流程

遇到 bug 后，核心原则是 “精准定位→分级处理→闭环验证→复盘预防”，具体流程如下：

1. 记录 bug（信息完整是前提）

首先要在 bug 管理工具（如 Jira、禅道、TestLink）中记录完整信息，避免信息缺失导致定位困难，必填内容包括：

• 基础信息：bug 标题（简洁描述问题，如 “登录页输入特殊字符后页面崩溃”）、所属模块、测试环境（dev/test/pre）、浏览器 / 设备型号；
• 复现步骤：详细的操作流程（如 “1. 打开登录页；2. 账号输入框输入<script>；3. 点击登录按钮”），必须能 100% 复现；
• 预期结果：页面正常校验，不崩溃；
• 实际结果：页面白屏，控制台报语法错误；
• 辅助信息：控制台报错截图、网络请求日志、录屏等。

2. 定位 bug（区分责任边界）

根据 bug 现象，先判断是前端问题、后端问题，还是环境 / 配置问题：

• 前端问题：控制台有 JS 报错、样式错乱、逻辑计算错误（如表单校验规则失效），可通过 Chrome DevTools 断点调试定位代码位置；
• 后端问题：接口返回数据异常（如登录接口返回 500、数据格式不符），需联调后端同学确认接口逻辑；
• 环境问题：仅生产 / 测试环境出现，本地无法复现（如 CDN 资源未同步、环境变量配置错误），需排查环境差异。

3. 分级处理（按优先级排序）

根据 bug 的影响范围和严重程度分级，优先解决高危问题，常见分级标准：

优先级	严重程度	示例	处理时效
P0（阻断）	核心流程无法使用，影响所有用户	登录功能失效、支付流程报错	立即处理，暂停上线
P1（高）	核心功能异常，影响部分用户	部分机型登录后跳转失败	24 小时内修复
P2（中）	非核心功能异常，不影响主流程	个人中心头像上传后显示模糊	下个迭代修复
P3（低）	体验类问题，无功能影响	按钮样式轻微错位、提示文案不规范	可延后到优化迭代

4. 修复与验证

• 开发修复：前端开发根据定位结果修改代码，修复后需在本地自测，确保 bug 解决且不引入新问题；
• 代码评审：大型项目需提交代码到feature/hotfix分支，通过 CR（代码评审）后再合并到测试分支；
• 回归测试：测试人员根据 bug 单重新验证，确认问题修复，同时还要测试关联功能（避免修复一个 bug 引发新 bug）；
• 闭环标记：验证通过后，在 bug 工具中标记 “已修复 / 已关闭”，未通过则打回 “重新修复”。

5. 紧急 bug 的特殊处理（生产环境 bug）

若上线后发现 P0/P1 级 bug，需启动紧急修复流程：

1. 立即触发版本回滚（如 K8s 回滚到上一稳定版本、Nginx 切换旧产物目录），先恢复服务；
2. 开发人员在hotfix分支紧急修复 bug，完成后走快速测试流程（仅验证该 bug）；
3. 测试通过后，通过 CI/CD 流水线做紧急发布，并通知用户服务已恢复；
4. 事后组织复盘，分析上线前未发现的原因。

6. 复盘预防（避免重复出现）

bug 修复后，需总结原因并优化流程，预防同类问题：

• 技术层面：补充单元测试 / 集成测试用例（如针对 “特殊字符输入” 的校验场景加测试），避免回归；
• 流程层面：若因测试覆盖不全导致，需完善测试用例；若因环境差异导致，需统一多环境配置；
• 知识沉淀：将典型 bug 整理成案例库，在团队内分享，提升全员避坑能力。

三、

1. 项目测试的核心方式

首先会分三个层级做功能测试：

• 单元测试：用 Jest/Vitest 测试独立的组件、函数，比如表单校验逻辑、自定义 hooks，保障基础代码块的稳定性；
• 集成测试：搭配 MSW 模拟接口，验证模块间的协作，比如 “登录组件 + 状态管理 + 接口请求” 的全链路；
• E2E 测试：用 Cypress/Playwright 模拟真实用户操作，覆盖登录、支付等核心业务流程。

此外还会做专项测试：用 Lighthouse 测性能、BrowserStack 做多端兼容性测试、Snyk 扫依赖漏洞，最后通过 UAT 验收测试确认产品需求匹配度。

2. 遇到 bug 的处理流程

第一步是完整记录，在 Jira 里写清复现步骤、环境信息和报错截图，确保能精准复现；

第二步是定位边界，通过 DevTools 断点或接口联调，判断是前端逻辑、后端接口还是环境配置问题；第三步是分级处理，按影响范围分为 P0-P3 级，优先解决阻断核心流程的 P0 级 bug；第四步是修复验证，开发修复后需通过 CR 评审，再由测试做回归验证，确认问题闭环；

如果是生产环境紧急 bug，会先触发版本回滚恢复服务，再走紧急修复和快速发布流程，事后还要复盘原因、补充测试用例，避免重复出现。

整个过程的核心是 “先止损、再解决、后预防”，既保障用户体验，也能通过复盘持续优化测试和开发流程。