手工项目阶段--个人笔记

鸳鸯蝴蝶
147 阅读7分钟

手工测试流程

  • 需求评审：确保各部门需求理解一致
  • 计划编写：测什么、谁来测、怎么测
  • 用例设计：验证项目是否符合需求的操作文档
  • 用例执行：项目模块开发完成开始执行用例文档实施测试
  • 缺陷管理：对的缺陷进行管理的过程
  • 测试报告：实施测试结果文档

1. 需求评审

  • 评审前：根据需求文档，梳理出疑问点
  • 评审形式：会议(产品，开发，测试，项目经理)

评审目的

  1. 明确测试范围，确认项目组成员对于需求的理解一致
  2. 站在不同角度对需求进行查漏补缺
  • 评审后产出
    • (产品)最终需求文档
    • (测试)编写测试计划

查漏补缺-案例

- 比如1：产品针对注册功能没有对于密码安全性进行需求设计
- 解决办法：长度限制(必须大于等于8位数，且包含大、小写和数字中的两种)
- 比如2：用户登录成功之后，过了XX时间，必须重新登录(用户信息有效时间限制)
- 比如3：上传文件，必须完成文件类型的校验(图片只能是jpg，png，gif，bmp)
- 比如4：关键用户信息修改(手机号)，必须加上手机短信验证码校验(用户信息安全性)

2. 编写测试计划

  • 目的

  1. 指导测试人员顺利完成的测试工作
  2. 让测试组以外的成员，了解的测试工作

  • 核心内容

  • 测试范围和测试对象

    • 测试对象：文档(需求文档，接口文档，系统部署文档)，代码(系统功能)，数据(项目中在数据库存储数据)
    • 测试范围：此次迭代需要被实现的需求

  • 测试进度安排

    • 各个阶段开始、结束时间
    • 各个阶段执行人--测试人员

  • 准入和准出标准

    • 准入--提测标准：通过冒烟测试(执行通过业务流程的正向测试用例)
    • 准出--上线标准：
      1. 用例执行率100%
      2. 没有中级及以上BUG，缺陷整体修复率达到95%以上

3. 编写测试用例

  • 规范和要求
  1. 用例编号：项目简称+模块简称+编号
  2. 用例标题：预期执行结果(测试点)
  3. 项目/模块名称
  4. 优先级
  5. 前置条件：用例执行前的准备工作
  6. 执行步骤
  7. 测试数据
  8. 预期结果：预期执行结果，当前页面展示结果，隐性需求(各个使用方结果展示)
业务流程

业务流程测试介绍

  • 业务流程测试目的

    1. 保证项目的可测性
    2. 保证用户体现

  • 业务流程测试对象：业务流程(操作一系列的单功能模块，测试执行场景是否能够被实现)

    • 业务流程的方法：流程图法也叫场景法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。
    • 适用场景：在业务场景中涉及多功能的组合逻辑
    • 使用步骤：根据流程图找出路径
    • 编写测试用例（从开始到结束为一条路径，有多少条路径就有多少条用例）

注意：流程图法测试不需要深入功能内部详细测试，主要测试流程

思路：

  1. 根据流程图梳理测试点
  2. 测试点的梳理
    • 正向(用户每一个步骤执行正确，校验该业务流程一定能够被实现)
    • 反向(用户某一个步骤错误，校验该业务流程一定不能被实现)
  3. 将测试点转化为完整的测试用例
单功能
  1. 提交类的单功能 思路：
  • 梳理测试维度(功能，非功能--UI界面校验、兼容性)
  • 功能的用例编写
  1. 梳理功能点(该页面从上到下，从左到右可操作的选项)
  2. 针对每一个功能点，结合需求文档，使用用例设计方法(等价类，边界值，判定表)，梳理测试点
  3. 将每一个功能点对应的测试点进行整合
    • 一条正向测试用例，覆盖多个正向测试点
    • 一条反向测试用例，仅覆盖一个反向测试点
  1. 简单的单功能-搜索功能

  • 根据需求文档，逐字逐句梳理出用户使用场景，一个使用场景对应一条测试用例

  • 注意点：用例写得跟需求一样(贬义)

错误示范：支付金额默认保留两位小数

正确示范：

  1. 当支付金额为整数
  2. 当支付金额为一位小数
  3. 当支付金额为两位小数
  4. 当支付金额为三位小数
  1. 较为复杂的单功能-支付功能
  • 从正、反向两个方面梳理测试点，根据需求文档梳理出可能有的动作
  1. 复杂的单功能-购物车
  • 静态展示
    • 在不同前提条件下，进入该页面，结果展示不同；一个前提条件对应一条测试用例
  • 动态操作
    • 梳理该单功能下，用户的不同操作，展示结果可能不一样，针对每一个操作结合需求文档，整理出对应使用场景

4. 执行测试用例

5. 缺陷管理

  • 编写缺陷

    • 缺陷核心内容（证明这确实是一个BUG）
  • 缺陷标题：测试数据+预期结果+实际结果
  • 所属模块
  • 前置条件
  • 复现步骤
  • 预期结果
  • 实际结果
    • 缺陷提交要素（提高与开发针对BUG修复沟通的效率）
    • 严重程度：项目是否能够上线

s1+s2：缺陷不修复，项目不能上线

s3+s4：缺陷不修复，项目也有机会上线

    • 优先级：修复时间
  1. P0：24小时
  2. P1：48小时
  3. P2：上线之前
  4. P3~P4：看心情
    • 缺陷状态
    • 缺陷类型

  • 缺陷管理流程

  1. 测试人员：缺陷提交
  2. 开发人员：确认缺陷
  3. 开发人员：修复确认--修复完成
  4. 测试人员：缺陷回归测试
  5. 测试人员：回归测试通过--关闭缺陷；回归测试失败--重新打开

6. 编写测试报告

  • 目的：
    1. 向项目组同步测试结果，确认项目是否能够上线
    2. 统计此次迭代开发的代码质量
  • 核心内容：
    1. 用例统计：用例数量，用例执行率，用例通过率
    2. 未修复BUG的统计：未修复BUG的数量，各优先级别的数量，未修复BUG的清单列表
    3. BUG的统计：总BUG数，各优先级别的数量，各模块的数量
  • 其他内容：
    1. 测试进度回顾(实际几个阶段的开始、结束时间)
  • 测试结果：各个模块测试是否通过

独立负责项目测试工作

1、熟悉项目
	a.项目未成形，还没有UI界面---熟悉成本低(功能少)直接看需求文档，顺便把你测试的模块编写测试用例
	b.项目已初步成形/已完全成形，可以有UI界面访问部分功能
		熟悉成本高(功能多)，通过UI界面梳理项目功能(建议使用X-mind)
2.正式开展测试工作(测试流程的六个步骤)
	需求评审
		前：问产品要需求文档，进行阅读提出疑问点
		中：让产品解答疑问点，并且记录：
			产品-给出最终需求文档时间--编写手工测试用例；
			后端-给出接口文档时间--编写接口测试用例，后端提测时间--进行接口测试；
			前端-给出提测时间--执行手工测试用例；
			确定1：验收测试时间--测试环境测试结束时间
			确认2：上线时间
		后：准备编写测试计划
	编写测试计划
	编写测试用例(用例评审--产品、前后端开发)
	执行测试用例
	缺陷提交和管理
	编写测试报告
avatar
文章
阅读
粉丝