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

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