02. 项⽬实施-功能测试

• 目标

  • 针对金融项目，制定整体项目测试阶段的测试计划
  • 针对金融项目，编写系统测试用例并完成评审

• 测试流程

  • 功能测试和接口测试流程大体相似，但有差别。

    • 在大厂里面有功能组、接口组、自动化组、性能组、安全组

  • 功能测试流程

    1. 需求评审
    2. 测试计划
    3. 编写⽤例
    4. ⽤例执⾏
    5. 缺陷管理
    6. 测试报告

  • 接口测试流程

    1. 需求评审
    2. 测试计划
    3. 分析API⽂档
    4. 编写⽤例
    5. 搭建环境
    6. 编写脚本
    7. 执⾏脚本
    8. 缺陷管理
    9. 测试报告

1. 项目需求评审

01-金融P2P项目需求说明-借款和投资

image-20230330165136989

1. 需求评审前的准备

• 前置条件：阅读需求
  • 正常情况下阅读所有需求（测试主管）
  • 涉及到本项⽬测试⼈员全部参与
• 准备
  • 明确自己负责评审哪些需求
  • 提前熟悉需求，记录对需求的疑问，为评审会议做准备

2. 需求评审的目标

• 熟悉项目功能

• 站在不同角度对需求进行查漏补缺(评审需求说明是否有遗漏)

• 确保需求说明书清晰，准确，没有冲突，重复、歧义(各部门对需求理解一致)

• 评审⼈员：测试、开发、产品

项目需求评审时发现了哪些问题？

3. 案例

1. 个人借款

image-20230331191929996

image-20230331193419757

2. 投资业务

image-20230331192030636

业务测试用例

2. 项目测试计划

1. 测试计划介绍

• 软件测试计划的核心内容

  • 测试的目标与范围（测什么）
  • 执行计划的角色与职责（谁来测）
  • 任务的进度安排与资源分配（谁来测）
  • 风险控制与应急计划 测试准入/准出标准

• 软件测试方案的核心内容（怎么测）

  • 测试策略
  • 测试环境
  • 测试工具

  提示：软件测试计划和软件测试方案有所区别，但是两者可以合并在一个文档体现：软件测试计划
  
  合并后的软件测试计划
  - 测什么
  - 谁来测
  - 怎么测

2. 编写测试计划

金融P2P项目测试计划V1.0

1. 软件测试计划编写步骤

1. 找到 / 整合 / 制作合适的文档模板

2. 准备测试计划的核心内容

   1. 测试目标和范围

   2. 评估测试工作量

      提示：软件测试计划的进度安排要参照项目整体交付计划

   3. 测试人员和时间

   4. 测试方法和工具

3. 按照模板，编写软件测试计划文档

4. 测试团队内外，沟通，确认软件测试计划

注意：测试过程中，根据测试工作开展的实际情况及时调整测试计划！

3. 评审测试计划

• 评审测试计划的过程

  • 成员组内评审测试计划并记录评审问题
  • 成员两组之间相互评审测试计划
  • 导师挑选测试计划在班级范围内进行评审

• 评审测试计划的注意点

  • 测试计划文档涵盖了核心内容
  • 测试计划合理、可行，能够按时达到测试目标
  • 测试方法正确、有效，能够指导具体测试工作

1. 测试计划的核心内容是什么？
2. 软件测试计划编写步骤是什么？
3. 如何评审测试计划？

3. 系统测试用例的设计

1. 功能测试的步骤

1. 对所测功能进行需求分析
2. 根据需求，整理测试点
3. 根据测试点，编写测试用例

2. 测试用例模板

用例ID	功能模块	优先级	用例标题	前置条件	测试数据	执行步骤	预期结果

3. 评审测试点

• 评审测试点的过程
  • 成员组内评审测试点并记录评审问题
  • 成员两组之间相互评审测试点
  • 导师挑选测试点在班级范围内进行评审
• 评审测试计划的注意点
  • 测试点正确覆盖了所有的功能点，没有错误和遗漏
  • 测试点描述简练清晰，可读性强
  • 测试点能够指导测试用例的编写
  • 测试点没有重复和冗余

4. 评审测试用例

• 评审测试用例的过程
  • 成员组内评审测试用例并记录评审问题
  • 成员两组之间相互评审测试用例
  • 导师挑选测试用例在班级范围内进行评审
• 评审测试用例的注意点
  • 用例覆盖了所有测试点
  • 用例容易看懂，方便执行
  • 用例没有重复和冗余

1. 针对金融项目，制定整体项目测试阶段的测试计划
2. 针对金融项目，编写系统测试用例并完成评审

• 目标
  • 能够对金融项目完成系统测试用例的执行工作
  • 能编写系统测试报告

4. 执行测试用例并提交缺陷

• 用例写完就要执行吗？
  • 等前后端开发、联调完成以后执行用例

1. 软件缺陷报告模板

• 软件缺陷报告模板
  • 基本内容
    • 缺陷标题
    • 前置条件
    • 复现步骤
    • 实际结果
    • 期望结果
  • 其他信息
    • 缺陷ID
    • 严重程度
    • 优先级
    • 缺陷类型
    • 缺陷状态

2. 评审缺陷报告的注意点

• 评审缺陷报告的注意点
  • 软件缺陷能够重现
  • 缺陷报告完整清晰，容易理解
  • 确保一个缺陷报告只描述一个BUG

3. BUG定位

1. BUG定位的引入

• BUG示例

  

  image-20230330172414907

• BUG描述

  • 【BUG标题】12位的手机号码也能注册成功
  • 【前置条件】手机号码未注册
  • 【复现步骤】
    1. 进入前台用户注册页面；
    2. 填写12位手机号码；
    3. 正确填写其他信息，点击注册
  • 【结果】注册成功，自动登录
  • 【期望】注册失败，给出对应提示

• BUG定位的价值

  • 找到BUG的本质（必现路径）
  • 提升开发修复BUG的效率
  • 提升自身的逻辑思维与技术能力

2. BUG定位的技巧

• BUG定位的技巧

  • 逻辑分析
    • 分析所有可能，逐个排查
    • 找到最短复现路径
  • 技术手段
    • 查看数据库
    • 抓包分析
    • 查看服务器日志

• 如何定位缺陷是前端还是后端bug?

  • 关键字:抓包

  • 前端bug ①请求错误（⽅法、URL、参数、信息头类型） ②显示错误（响应数据正常，前端解析提取错误）

  • 后端bug

    • ⽆响应或响应数据不正确

  • 如果缺陷不能复现怎么办？ 1、提交缺陷，挂起。 2、跟进⼏个版本，找开发协助定位。 3、上线之前评估缺陷带来的影响。

5. 软件测试报告

1. 软件测试报告

• 软件测试报告的目标

  • 汇报近期的测试工作，体现工作过程和成果
  • 评估当前软件质量，为团队决策提供依据
  • 改进自身测试工作，持续提升测试效率和质量

• 软件测试报告的核心内容

  • 测试工作的经过与结果
  • 缺陷汇总与分析
  • 软件上线风险
  • 测试工作总结与改进

2. 编写软件测试报告

• 软件测试报告的编写步骤
  1. 找到 / 整合 / 制作合适的文档模板
  2. 收集，汇总材料
     1. 每位团队成员的工作记录和成果
     2. 测试用例的数量和执行结果
     3. BUG的状态和数量
     4. 团队成员的反思与改进建议等
  3. 按照模板，编写软件测试报告文档

3. 评审软件测试报告

• 评审软件测试报告的过程
  • 成员组内评审测试报告并记录评审问题
  • 成员两组之间相互评审测试报告
  • 导挑选测试报告在班级范围内进行评审
• 评审软件测试报告的注意点
  • 测试报告文档涵盖了核心内容
  • 测试报告准确有效，达到测试报告的目标

1、测试⽬标、范围
2、测试环境
3、总⽤例数：xx 单模块⽤例数：yy
4、缺陷统计及分析（模块发现的缺陷、缺陷严重程度分布、开发与缺陷）
5、测试总结（1、测试结论总结 2、缺陷修复程度总结 3、剩余缺陷总结 4、测试收获总结）

项⽬组群：
xxx项⽬总报告：
执⾏组：XXX测试组（4⼈）
执⾏⽤例总数量：800条
缺陷总数量：（240条）
严重缺陷：54条
中级缺陷：126条
UI缺陷：28条
测试结论：总修复193条，其中中级以上bug全部修复完毕，剩余缺陷XXX条，不影响V1.5版本发布上线，本次测试通过。