开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 开发测试 -> 软件测试分类、测试方法、测试模型、bug周期及其管理 -> 正文阅读

[开发测试]软件测试分类、测试方法、测试模型、bug周期及其管理

功能测试

测试分类

按测试阶段划分

单元测试

程序的最小模块完成后，进行的测试
- 可能是一个函数，也可能是一个类，也可能是一个界面

集成测试

组装测试，在单元测试的基础上，把多个模块组装到一起进行测试，终点关注模块和模块之间的接口

系统测试

把软件项目作为一个整体进行测试，测试的依据是需求说明书
- 到了系统测试阶段，软件基本是完成的

验收测试

站到最终用户的角度来测试
- alpha
  - 内测版本
- betta
  - 公测版本
- gamma
  - 接近于正式发布的版本

是否查看源代码分类

黑盒

只测试功能，不关注功能的具体实现方式

白盒

不但要关注功能，还要关注代码是如何实现的

灰盒

介于黑盒和白盒之间的一种测试

按是否运行分类

静态测试

不允许软件，静态的观察软件是否符合预期

动态测试

运行软件，在运行过程中测试

是否自动化

手工测试

通过测试工程师手工对软件进行测试

自动化测试

通过编写代码，通过程序自动测试软件是否有bug

其他分类

1. 冒烟测试

对软件最基本的流程和工作做一个粗略的测试，看最基本的流程是否能流通
测试拿到研发的第一个版本，一般先冒烟。

2. 回归测试

当修复一个bug后，把之前测试用例在新的代码下再进行测试

3. 随机测试

针对软件中的重要功能进行复测

4. 探索性测试

以便了解和学习项目，一边测试项目

软件质量模型

1. 功能性

功能的正确性
功能的安全性
功能的依从性

2. 可靠性

软件要有容错性
出现错误后，可以很快恢复

3. 易用性

软件界面是否流程
提示是否友好
用户使用功能是否得当

4. 效率

软件一定是要高效的

5. 维护性

6. 可移植性

适应不同的系统

开发模型–瀑布模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NwBKWPDf-1629001033825)(C:\Users\jss\AppData\Roaming\Typora\typora-user-images\image-20210708174401396.png)]

需求分析
- 研发分析需求说明书
- 判断需求的可实现性
概要设计
- 用到具体的技术点
- 大致模块划分
详细设计
- 详细到可以为编码做支持
- 类和类关系，类的设计
- 函数设计
- 各个接口的细节
- 数据库表的关系，字段关系
编码
- 依托于详细设计进行编码操作
软件测试
软件维护
- 上线后也是需要持续维护

1. 瀑布模型的特点

线性模型
- 每一步都是按顺序来执行
文档驱动
- 每一步都有文档产出

2. 瀑布模型优缺点

优点
- 每个阶段很清晰
- 只需要关注后续阶段
缺点
- 依赖于需求，不能适应需求的变化
- 风险到项目后期才体现，失去早期纠正机会

3. 快速原型模型（了解）

一边确定需求，一边实现
优点
- 避免瀑布模型的缺点，可以适应早期需求的变化
缺点
- 适合小型项目

4. 螺旋模型（了解）

优点
- 引入风险分析
缺点
- 风险分析需要专业的知识和人员

测试过程模型

v模型

从研发的瀑布模型来的

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3rB0BvOJ-1629001033826)(C:\Users\jss\AppData\Roaming\Typora\typora-user-images\image-20210706204838434.png)]

优点
- 包含了底层和高层的测试过程
- 每个步骤都是文档驱动的
缺点
- 和研发瀑布模型一样，不能适应需求的改变，灵活性较低

w模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-L4ZxKb6y-1629001033827)(C:\Users\jss\AppData\Roaming\Typora\typora-user-images\image-20210706205011012.png)]

优点
- 测试工作伴随着整个研发周期，测试对象不只是代码，文档也需要测试
- 更早的介入研发工作，可以尽早发现问题，及时处理
缺点
- 对测试工程师要求比较高，实践起来难度比较大

测试用例

八大要素

用例的编号
用例标题
测试项目
用例级别
预置条件
测试数据
执行步骤
预期结果

编写方法

1. 等价类划分法

有效等价类
无效等价类

2. 边界值划分法

上点
- 处于边界上的点
离点
- 离上点最近的点
内点
- 范围内的点
开区间，闭区间
- [开始值，结束值] —闭区间，包含开始值，包含结束值
- （开始值，结束值）— 开区间，不包含开始值，不包含结束值

[2o，30] 大于等于20，小于等于30         闭区间
20和30是上点
25内点
―19和31是离点，这里的离点是无效数据
(20，30)大于20，小于30                 开区间
20，30是上点23内点
21，29是离点，这里的离点是有效数据
(20，30]大于20，小于等于30左开右闭
区间[20，30)大于等于20，小于30，左闭右开区间

对于闭区间上点是有效数据,离点是无效数据
对于开区间，上点是无效数据,离点是有效数据
不管开和闭区间,内点都是有效数据

3. 判定表法

1. 判定表

条件桩
- 列出所有输入，顺序无关
动作桩
- 列出所有的输出，顺序无关
条件项
- 把条件桩中所有能出现的组合都罗列出来
动作项
- 根据不同条件项的组合产生的动作结果

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-06Owdfys-1629001033827)(C:\Users\jss\AppData\Roaming\Typora\typora-user-images\image-20210707143136116.png)]

2. 使用判定表步骤

先明确需求
画判定表
- 先画条件桩
- 然后动作桩
- 罗列条件项的不同组合
- 根据条件项完成动作项
编写测试用例
- 判定表中的一条规则对应一条测试用例

不能直接用判定表去执行测试用例+

通过判定表编写测试用例，用测试用例去执行测试操作

测试用例有很重要的两个原则

能看懂
能执行

4. 因果图

恒等
非
或
与

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vcNhOCsL-1629001033830)(C:\Users\jss\AppData\Roaming\Typora\typora-user-images\image-20210707143524007.png)]

使用因果图步骤

明确需求
画因果图
根据因果图画判定表
根据判定表写测试用例

5. 正交表

$L_n(m^k)$
n表示行数
k标识列数
m表示列的取值个数

$L_9(3^4)$

表示：9行4列，每列有3种取值个数叫4因素，3水平

使用正交表步骤

明确需求
绘制正交表
- 先确定列数
- 确定正交表每列的取值个数
- 根据因素和水平可以确定行数
根据正交表编写测试用例
- 正交表的一行代表一条测试用例

6. 场景法

用流程图描述用户的使用场景
用覆盖流程路径来设计测试用例
- 从流程图开始到结束，有几条路就是几条路径
- 一个路径对应一条测试用例

使用步骤

明确需求
画出流程图
根据流程图编写测试用例
- 流程中有多少路径，就对应多少测试用例

7. 错误推测法（了解）

瓶测试工程师的直觉和经验来推测项目中可能出现的bug，进行测试。
时间紧张，突发事件

缺陷

缺陷定义

软件或者程序中存在的各种问题

缺陷判定标准

软件没有达到需求说明书表明的功能
软件出现了需求说明书指明不会出现错误的地方
软件超出了需求说明书指明的范围
软件出现了需求说明书虽未指明，但应该达到的目标
软件难以使用，效率低下

缺陷产生的根源

需求变更
交流不充分
软件的复杂性
进度压力

缺陷信息

缺陷编号
缺陷的状态
- new-新建
- open-打开
  - reopen-关闭的缺陷，再次打开
- fixed-修复
- closed-关闭
- rejected-拒绝
- postpone-拖延
缺陷标题
严重程度
- 5-critical 最高优先级
- 4-veryhigh 非常高优先级
- 3-high 高
- 2-medium 中
- 1-low
优先级
- 5-urgent 最高
- 4-veryhigh 非常高
- 3-high 高
- 2-medium 中
- 1-low
所属模块
缺陷的详细描述

缺陷报告注意事项

缺陷报告不能有缺陷
表达和描述简洁，准确
一个缺陷一个报告
缺陷一定是可重现的
避免出现模糊的词汇
不能有个人感情色彩
出现bug过程一定要详细

缺陷跟踪流程

new新建状态
- 要提交一个缺陷，首先就是新建状态
open打开状态
- 确认缺陷有效后，为打开状态
fixed修复状态
- 由缺陷的处理人，把缺陷处理完成之后设置为修复状态
closed关闭状态
- 验证缺陷确实修复成功后，一般由缺陷的发起人设置状态为关闭状态
reopen重新打开状态
- 一个已经关闭的缺陷在此出现，就要设置为重新打开状态

bug的生命周期

bug的生命周期，就是一个bug被发现到这个bug被关闭的过程

新建–>指派–>已解决–>待验–>关闭
发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG
- 如果待验的BUG在验证时没有解决好，我们需要重新打开–指派—已解决—待验，循环这个过程。
- 中间其他状态：拒绝、延期等

缺陷分析需要注意的点

那个模块问题最多
哪个测试工程师测试的缺陷最多
各类缺陷数量占比
开发是否可以及时修复缺陷
开发人员一次修复缺陷占比
软件是否可以正常发布

项目测试流程

熟悉项目步骤

了解项目业务特性
了解项目的用户
了解项目的模块
了解项目技术栈

1. 需求评审

1. 什么是软件需求

描述软件功能

2. 需求评审

项目的相关人员就软件需求进行确认和评估的相关活动

3. 需求评审目的

保证需求的完整和准确
保证项目中相关人员对需求的理解达到一致

4. 需求评审的形式

会议

5. 需求评审的参与人员

产品人员
开发人员
测试人员
界面设计人员

6. 测试人员在需求评审中的作用

确认自己对需求清晰的理解，没有疑惑
确认需求文档的完整、准确，可以支持后期的测试工作
对需求中不合理的地方提出修改意见

2. 编写测试计划与测试方案

1. 测试计划核心内容

明确测试的目标与范围
执行计划的角色与职责
测试任务的进度和资源分配
风险的评估与应急计划
测试的准入准出标准

2. 测试方案

测试的策略
测试环境的规划
测试工具的设计和选择

3. 测试用例设计与评审

1. 测试用例需求来源

文档
- 需求文档，产品原型图、ui图
从用户角度
- 测试软件的易用性

2. 编写测试用例的步骤

需求分析
编写测试点
- 测试中需要关注的具体功能点
- 拆分需求，作为编写测试用例的辅助
编写测试用例

3. 编写测试用例的原则

能看懂—确保每个用例通俗易懂
能执行—测试用例清晰明确，用例中每个步骤都是可执行的

4. 测试结果的4种状态说明

pass------通过；
fail-----失败；
block------阻塞；
N/A------忽略；

4. 测试执行与bug跟踪

执行测试用例原则

严格按照测试用例书写的步骤执行
执行过程中遇到bug一定要及时提交

5. 编写测试报告

状态迁移法

找到被测对象的所有状态,和状态的转化过程,以此编写测试用例
状态迁移法不关注具体模块的具体功能,关注状态的转化过程流程是否正确

适用场景

涉及到了复杂的业务场景,需求说明书往往不能阐述清楚,如果只按照需求说明书测试单个功能点,容易出现疏漏

状态迁移法使用步骤

分析需求,找到所有的状态
绘制状态迁移图
根据图绘制状态迁移树
根据树编写测试用例
- 从根节点到一个叶子节点就是—条路径。
- —条路径对应一个测试用例
- 树中有多个叶子节点就对应多少测试用例

会员列表功能测试

熟悉会员列表功能需求
整理测试点

测试有很多输入项的用例测试数据整理

长度和范围
类型
规则
是否必填
是否可以重复

流程图

关注点

业务流程是否可以走通
不关注流程中具体的功能点

执行流程测试的时机

基本功能都完成后,进行业务流程测试
软件上线前,再次进行业务流程的回归测试

执行流程测试的步骤

分析需求,确定业务的流程
绘制流程图
根据流程图编写测试用例
- 流程图中有多少路径,就对应多少测试用例

执行流程测试用例注意项

要对测试用例的优先级排序
优先级高的测试用例先测

功能测试涉及到数据库的四种场景

执行用例过程中，有时需要到数据库验证数据的准确性与完整性

-- 数据库验证数据的准确性:后台'商城'->'统计>'会员统计功能的会员余额总额
select sum(user_money) from tp_users;

进行bug定位时，有时需要到数据库查看数据的详细信息

-- BUG定位:前台会员修改性别后，个人信息性别显示错误（筛选条件中nickname需要自己定义)
select nickname,mobile,email,sex from tp_users where nickname like 'user3%';

构造某种测试场景时，可以在数据库里直接修改数据，要比使用界面更有效率

--构造数据:使前台购物车商品总数显示出四位数（筛选条件中 id,user_id的取值需要自己定义)
update tp_cart set goods_num = 2200 where id =21;
select id,user_id,goods_name,goods_num from tp_cart where user_id = 2596;

软件升级过程中，有时会涉及到历史数据的处理，这种清空需要执行升级SQL ，并验证结果

--系统升级，给用户新增一个字段"信用分" credit_score，并把现有会员账号的信用分设置为100分
alter table tp_users add column credit_score int;update tp_users set credit_score = 100;
select user_id,nickname,credit_score from tp_users order by user_id desc limit 0,10;