01. 功能测试

基础

1. 认识软件测试行业
2. 掌握测试常用分类/能够对测试技能进行分类
3. 了解软件测试流程/知道工作中测试的流程
4. 理解测试质量模型/能够为设计测试考虑方面
5. 掌握测试用例编写要素/能够说出用例设计书写模版

一. 软件测试的基本了解

1. 什么是软件测试

使用技术方面的手段来检测软件是否满足需求

2. 软件测试的目的

用最少的人力,物力和财力找到软件的问题并修复,从而降低商业风险

二. 测试的技能分类

1. 功能测试

验证程序的功能是否满足需求
\ 作为测试人员,除了要考虑正常操作结果意外,还需要异常或者错误操作对应情况

2. 自动化测试

使用代码或者是工具替代人工验证项目功能
\ 主要作用是提高测试执行效率

3. 接口测试

针对模块与模块之间或系统与系统之间的数据请求地址进行测试
\ 是基于数据层面的一种测试

4. 性能测试

模拟多人使用软件,查找服务器缺陷
\ 区别其他测试技术,核心是大量用户

三. 测试的分类

1. 按照测试阶段划分

a. 单元测试 --- 针对程序源码进行测试
b. 集成测试 --- 接口测试,针对模块之间访问地址进行测试
c. 系统测试 --- 对整个系统进行测试,包括功能,兼容,文档等测试
d. 验收测试 --- 主要分为内侧,公测使用不同人群来发掘项目缺陷

2. 按照代码可见度划分

a. 黑盒测试(功能测试)
	看不见代码,主要针对程序功能进行测试
b. 白盒测试(单元测试)
	看间全部代码,主要针对程序源码进行测试
c. 灰盒测试(接口测试)
	看见部分代码,主要对程序接口进行测试

3. 测试策略

冒烟测试 --- (重点)
针对系统最基本的功能进行测试,保证基本的功能和流程能走通
测试人员制定要求,由开发去执行(冒烟测试用例)(自测),目的是作为提测的标准使用
ps: 如果开发人员精力不足,也会由测试人员执行测试过程

回归测试 --- (重点)
当修复一个bug之后,把之前的测试用例在新的代码下进行再次测试
回归场景:
a. 正常的测试流程,发现问题,提交给开发,开发修复后,测试再次测试的验证过程(测试步骤不变)
b. 基于现有功能推出新功能时(版本迭代),对原有功能再次进行校验(测试步骤不变)
ps: 是工作中最频繁的一个情况

随机测试
主要是针对被测软件的一些重要功能进行复测,也包括测试那些当前没有被测到的部分
ps: 在有一定的测试经验的基础上,对关键内容进行抽检

探索测试
设计测试和执行测试是同时进行的,它要求测试人员通过测试来不断学习被测系统
同样需要大量的测试经验支撑

4. 总结

a. 系统测试和黑盒测试重点核心是功能测试
b. 集成测试和灰盒测试又称为接口测试
c. 单元测试和白盒测试是对代码进行测试
d. 自动化测试归属功能测试
e. 性能测试,安全测试归属专项测试

四. 模型

1. 质量模块

质量模型提供测试设计的不同角度视野和验证方向

2. 测试模块

测试模型主要体现的是测试人员和开发人员在工作中对应关系问题(理想状态下,开发与测试步骤应该同步进行), 但是具体实施是有很大难度,尤其是测试的设计阶段

优点: 测试伴随着整个产品开发周期,测试对象不进是程序还有需求,设计文档.测试介入较早,及早能发现发问题,减少损失

缺点: 实施起来比较复杂,难度大,对于需求阶段和设计阶段的测试设计要求较高

五. 测试流程

1. 需求分析

确保各部门需求理解一致

2. 计划编写

测什么,谁来测,怎么测

3. 用例设计

验证项目是否符合需求的操作文档

4. 用例执行

项目模块开发完成开始执行用例文档实施测试

5. 缺陷管理

对缺陷进行管理的过程

6. 测试报告

实施测试结果的文档

六. 测试用例

1. 什么是测试用例

为了测试项目而设计的执行文档

2. 测试用例的作用

a. 防止漏测
b. 实施测试的标准

3. 用例测试编写格式

用例编号 => 标题 => 模块 => 优先级 => 前置条件 => 测试步骤 => 测试数据 => 预期结果

用例编号: 项目+模块+序号
用例标题: 预期结果+操作步骤
项目/模块: 所属项目或者模块
前置条件: 要执行此条用例,有哪些前置操作
优先级: 表示用例的重要程度或者影响力P0~P4(P0最高)
测试步骤: 描述操作步骤
测试数据: 操作的数据,没有的话可以为空
预期结果: 期望达到的结果

4. 如何编写测试用例

等价类划分

说明

在所有测试数据中,具有某种共同特征的数据集合进行划分

分类

有效等价类:满足需求的数据集合
无效等价类:不满足需求的数据集合

步骤

1. 明确需求
2. 确定有效和无效等价类
3. 提取数据编写测试用例

注意:

1. 一条测试用例尽可能多的覆盖多个有效等价类
2. 一条测试用例只能覆盖一个无效等价类

使用场景

针对: 需要有大量数据测试输入,但是没有穷举测试的地方
输入框
下拉列表
单选框
典型代表: 页面级输入框测试

边界值分析

边界范围节点

选取正好等于,刚好大于,刚好小于边界的值作为测试数据
上点: 边界上的点(正好等于)
离点: 距离上点最近的点(刚好大于或者刚好小于)
内点: 范围内的点(区间范围内的数据)
提示: 边界值分析法需要在等价类的基础上,增加校验以下几个点对应数据

边界值法设计用例步骤

1. 确定需求
2. 确定有效和无效等价类
3. 确定边界值
4. 提取数据编写测试用例

优化

结论: 7个优化为5个
上点: 必选(不考虑区间开闭)
内点: 必选(建议选择中间范围)
离点: 开内闭外(考虑开闭区间,开区间选择内部离点,闭区间选择外部离点)
注意:!!!!!! 有些公司认为内点是重复性选项,两个内离点如果没有问题,则内点也不应该有问题,因此需要根据公司具体要求进行取舍即可

使用场景

在等价类的基础上针对有边界范围的测试数据输入的地方(重点关注边界)
常见词语描述: 大小 尺寸 重量 最大 最小 至多 至少等修饰词语
典型代表: 有边界范围的输入框测试
提示: 凡是存在范围的数据,才需要考虑使用边界值分析法.该方法一般情况下多和等价类划分法配合使用
注意: 一般的工作中最常用的两个用例设计方法就是等价类和边界值

判定表法

应用场景

存在条件约束.对应条件有对应结果时可以考虑使用

快速估计用例数量方法

假设有n个条件,每个条件的取值有m个,全组合有m的n次方种规则
例如: 现有2个条件,么个条件取值2个值,全套组合一共: 2 的 2 次方 4 种

场景法

说明

场景法也可以叫(流程图法),是用流程图描述用户的使用场景,然后通过覆盖流程路径来设计测试用例

意义

用户使用角度: 用户平时使用的不是单个功能,而是多个功能组合起来进行使用
测试人员教辅: 平时测试的都是单个功能点进行测试,容易忽略多个功能

步骤

1. 明确需求
2. 画流程图
3. 编写测试用例(一条流程图路径就是一条测试用例)

注意: 将来测试工作进行过程中,一般先处理业务流程,再处理单个功能模块
例如: 购物流程,应该先处理"登陆 -> 添加商品 -> 提交订单 -> 支付"的业务流程,然后再处理"登陆 -> 添加商品 -> 提交订单 -> 支付"单个模块

错误推测法

定义

根据经验推测系统可能出现的问题

思想

根据经验列举出可能出现问题的清单,根据清单分析问题可能原因,推测发现缺陷

场景

1. 时间紧任务量大,根据之前项目类似经验找出易出错的模块重点测试
2. 时间宽裕时通过该方法列出之前出现问题较多的模块再次测试

面试题: 任务量大 时间紧该如何完成任务

1. 梳理任务优先级: 优先确保高优先级的任务能够被完成(高优先级: 核心功能或业务)
2. 选择性放弃部分内容: 在后续版本(更新/迭代)中进行处理
3. 城市申请延期或增加测试时长
4. 申请加派测试人手

七. 缺陷管理

缺陷的定义

软件在使用过程中存在的任何问题都可以叫软件的缺陷.简称bug

缺陷的判定标准

1. 软件未实现需求(规格)说明书中明确要求的功能 -- 少功能
2. 软件出现了需求(违规)说明书中知名不应该出现的错误 -- 功能错误
3. 软件实现的功能超出需求(规格)说明书指定范围 -- 多功能
4. 软件为实现需求(规格)说明书中虽未明确需求但应该实现的要求 -- 隐性功能 -- 注册业务
5. 软件难以理解,不易使用,运行缓慢,用户体验不好 -- 不易使用

缺陷产生的原因

1. 需求阶段 -- 需求描述不易理解, 有歧义错误等
2. 设计阶段 -- 设计文档存在错误或者缺陷
3. 编码阶段 -- 代码出现错误
4. 运行阶段 -- 软硬件系统本身故障导致软件缺陷

软件缺陷的生命周期

软件缺陷的核心内容

1. 缺陷的标题 -- 描述缺陷的核心问题
2. 缺陷的预期结果 -- 希望得到的结果
3. 缺陷的预置条件 -- 缺陷产生的前提
4. 缺陷的实际结果 -- 实际得到的结果
5. 缺陷的复现步骤 -- 复现缺陷的过程
6. 缺陷的必要附件 -- 图片,日志等信息

缺陷提交要素

1. 编号
2. 严重程度
3. 优先级
4. bug类型
5 缺陷状态

软件缺陷类型

1. 功能错误
2. 界面错误
3. 兼容性
4. 数据
5. 易用性
6. 改进建议
7. 架构

八. 缺陷编写

组成要素

1. 缺陷id
2. 缺陷标题 -- 能够体现问题所在的模块以及对应问题的内容
3. 缺陷状态 -- 在不适用缺陷管理工具情况下, 需要根据问题实际状态填写合适的状态
4. 严重程度 -- 描述问题的严重程度,可以和缺陷优先级使用相同的描述方式(P0~P4)
5. 优先级 -- 缺陷优先级,开发人员需要关注
6. 所属模块 -- 问题归属模块
7. 缺陷描述 -- 可以包含: 前置条件/测试步骤/预期结果/实际结果 作用: 尽最大程度保证开发人员梳理复现缺陷
8. 附件 -- 可选项 作用: 问题的证据,辅助开发复现问题

缺陷的跟踪流程

提交缺陷注意事项

1. 可重现
2. 规范性
3. 唯一性

缺陷编写规范

1. 准确
2. 具体
3. 简单易懂
4. 次序清晰

九. 缺陷管理

通过Excel管理缺陷

注意: 缺陷标题可以直接判断问题所在模块已问题内容,缺陷面熟无比确保开发人员能够复现bug

通过缺陷管理工具管理缺陷

禅道工具官方演示地址： https://demo.zentao.net/user-login.html

十. 功能测试的基本流程小结