测试基础知识

小橙子*

已于 2022-12-10 16:50:43 修改

阅读量231

点赞数

分类专栏：理论基础文章标签：单元测试

于 2022-12-06 21:02:11 首次发布

本文链接：https://blog.csdn.net/m0_62091240/article/details/128210202

版权

理论基础专栏收录该内容

6 篇文章 2 订阅

订阅专栏

软件测试基础知识

文章目录

软件测试基础知识
一、测试介绍
二、测试常用分类
三、模型
- 3.1质量模型
四、软件测试流程
五、测试用例
六、用例设计方法
七、缺陷管理

一、测试介绍

什么是软件测试：使用技术手段验证软件是否满足需求
测试主流技能

1、功能测试
2、自动化测试
3、接口测试
4、性能测试

主流方向建议:
1、功能测试+接口测试
2、自动化测试+接口
3、功能+性能

软件测试目的：减少软件缺陷(bug)，保障软件质量!

1.1功能测试

说明:功能测试主要验证程序的功能是否满足需求

1.2自动化测试

说明：使用代码或工具代替手工，对项目进行测试

1.3接口测试

说明:使用代码或工具对服务端提供的接口进行测试

1.4性能测试

说明:模拟多人使用软件查找服务器缺陷。

就业方向

方向(一) :功能测试+接口测试
方向(二) :功能测试+性能测试
方向(三) :功能测试+web自动化

二、测试常用分类

分类:
- 阶段划分(阶段:软件产出过程顺序)
- 代码可见度

2.1阶段划分

单元测试：

■ 说明:针对程序源代码进行测试(单元:最小独立功能代码段)

■ 提示:
■ 1、国内单元测试一开发自测
■ 2、单元测试可以解决-快速定位缺陷
■ 3、提高测试执行效率
集成测试

■ 说明:针对单元与单元之间的接口进行测试

■ 提示:又称接口测试。
系统测试

■ 说明:针对系统整体功能+兼容+文档(说明、安装文档)
验收测试
■ 内测:公司内部人员使用，发觉缺陷并修复。
■ 公测:让用户帮忙测试
■ 提示:验收测试,一般要根据项目类型决定是否使用。

2.2代码可见度划分

黑盒测试:主要针对功能(阶段划分->系统测试)
灰盒测试:针对接口测试(阶段划分->集成测试)
白盒测试:针对程序源代码进行测试(阶段划分->单元测试)

2.3总结

1、按阶段划分
①单元测试:针对程序源代码进行测试
②集成测试:针对程序接口进行测试
③系统测试:针对程序功能、非功能进行测试
④验收测试:使用不同用户(内测、公测)进行测试

2、按代码可见度划分
①黑盒测试:不关注源代码，针对程序UI功能进行测试。
②灰盒测试:针对程序部分代码进行测试(接口)
③白盒测试:针对程序源代码进行测试

3、其他
①性能测试:归属专项测试
②自动化测试:归属功能测试

三、模型

3.1质量模型

说明：衡量一个优秀软件的维度

功能性：

例如需求:10个功能，功能详情

测试：功能数量为10个，功能正确实现，错误处理情况
性能：

例如需求：预计每日在线人数20W

测试：1、服务器每秒处理请求数 2、服务器硬件配置是否满足
兼容性：浏览器（谷歌、IE、火狐、欧朋、苹果）；操作系统（Win系统: Wind7. wind8. wind10其他）；手机（分辨率、品牌、系统、网络、其他）
易用性：简介、友好、流畅、美观
可靠性：死机：系统奔溃；无响应；卡顿：响应时间慢
安全：账户密码安全性
可维护性：可以时长维护
可移植性：网络数据迁移

四、软件测试流程

需求评审

前提:阅读1遍需求文档，记录不明确之处。
参与人员:前端、后端、测试、产品
目的: 
1、确保各部门需求理解致
2、各角色对需求进行查漏补缺
3、了解软件有些功能
提示:需求分析阶段- >软件还未实现(刚立项)

计划编写

说明:指导测试执行的文档(重要)
测什么(目标、范围)
谁来测(人员进度及安排)
怎么测(测试工具、测试策略)

用例设计

说明:保证能准确验证软件测试点执行的文档。验证项目是否符合需求的操作文档
1、分析需求
2、提取测试点
3、设计用例覆盖测试点

用例执行

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

缺陷管理

提交-》验证-》关闭

测试报告

1、bug分析及统计
2、测试中遇到的问题
3、测试总结(本次测试中的优点和不足)

五、测试用例

5.1什么是用例

用例:用户使用的案例
生活中的用例，例如手机

1、是否能开机:打开手机按下电源键3秒钟，看是否能开机。
2、验证内存:打开手机设置查看内存是否为64G。
3、验证屏幕:打开手机在白屏背景下检查屏幕是否黑色点。
4、检查运行速度:打开手机下载吃鸡游戏，是否运行流畅。

测试用例：是为测试项目而设计的执行文档
测试用例的作用

1、防止漏测
2、实施测试的标准

5.2用例设计编写规格-说明

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

5.3测试用例练习

需求: QQ登录(4条)
1.账号为空 2.账号朱注册
3.密码为空 4、密码错误

六、用例设计方法

目标

能对穷举场景设计测试点【等价类划分】
能对限定边界规则设计测试点【边界值分析法】
能对多条件依赖关系进行设计测试点【判定表法】（难度最大）
能对于项目业务进行设计测试点【场景法】（重点）

6.1等价类划分-能对穷举场景设计测试点

6.1.1说明

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

6.1.2分类

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

6.1.3用例设计步骤

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

6.1.4 使用场景

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

6.1.5 案例

案例 1：需求验证QQ账号的合法性；要求：6~10位自然数

案例2：电话

要求:
1.区号:空或者是三位数字
2.前缀码:非“0”且非“1" 开头的三位数字
3.后缀码:四位数字

6.2边界值-解决边界位数限制问题

6.2.1边界范围节点

选取正好等于、刚好大于、刚好小于边界的值作为测试数据

➢ 上点:边界上的点(绿色)
➢ 离点:离边界最近的点(黄色)
➢ 内点:范围内的点(蓝)

提示:
1、有关范围限制，最多7条用例(暂时未优化)
2、边界值能解决位数限制问题，但是不能解决类型问题(要结合等价类)

6.2.2用例设计步骤

1、明确需求
2、确定有效和无效等价
3、确定边界范围
4、提取数据编写用例

6.2.3优化(7 点优化5点)

重点:开内闭外(开区间选包含的点，闭区选不包含的点)
开区间:不包含边界上的点(没有等号)。如: a<10
闭区间:包含边界上的点(有等号)。如:a<=10

6.2.4使用场景

➢ 在等价类的基础上针对有边界范围的测试数据输入的地方(重点关注边界)
➢ 常见词语描述:大小、尺寸、重量、最大、最小、至多、至少等修饰词语
➢ 典型代表:有边界范围的输入框类测试

6.2.5案例

案例1：需求验证QQ账号的合法性；要求：6~10位自然数

1明确需求	6~10位自然数
2 划分等价（类型）	有效类型	无效类型
	自然数	非自然数
3 确定边界值	上点	离点	内点
	6,10	5,7,9,11	8
4 提取数据设计用例	123456	12345	12345678901
1234567a	1234567890	1234567	12345678

案例2：需求:通过边界值法验证标题长度的合法性
要求:标题长度大于0，小于等于30个字符

1 明确需求	标题长度大于0，小于等于30个字符
2 划分等价（类型）	有效类型	无效类型
	（0,30]个字符	非字符、空
3 确定边界值	上点	离点	内点
	0，30	1,29,31	15

6.3判定表-解决多条件有依赖关系测试

6.3.1判定表法的引用

案例:验证“若用户欠费或者关机，则不允许主被叫”功能的测试
说明:
➢等价类边界值分析法主要关注单个输入类条件的测试
➢并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试。

6.3.2判定表定义及组成部分

定义:是一种以表格形式表达多条件逻辑判断的工具
组成:
➢ 条件桩:列出问题中的所有条件，列出条件的次序无关紧要。
➢ 动作桩: 列出问题中可能采取的操作，操作的排列顺序没有约束。
➢ 条件项:列出条件对应的取值，所有可能情况下的真假值。
➢ 动作项:列出条件项的、各种取值情况下应该采取的动作结果。
规则:
➢判定表中贯穿条件项和动作项的一列就是一条规则
➢假设有n个条件，每个条件的取值有两个(0,1),全组合有2的n次方种规则

6.3.3判定表法设计用例步骤

1.明确需求
2.画出判定表
1)、列出条件桩和动作桩
2)、填写条件项，对条件进行全组合
3)、根据条件项的组合确定动作项
4)、简化、合并相似规则(有相同的动作)
3.根据规则编写测试用例

6.3.4使用场景

有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖(制约)关系
判定表一般适用于条件组合数量较少的情况(比如4个条件以下)
提示:
1、多条件之间有依赖关系，使用判定表来进行测试覆盖。
2、判定表一般适合4个以内条件依赖关系
3、如果条件超过4个，就不适合覆盖所有条件，应采用(正交法)来解决。

6.3.5案例

案例1：订购单检查
规则:
1)、如果金额大于500元，又未过期，则发出批准单和提货单;
2)、如果金额大于500元，但过期了，则不发批准单与提货单; .
3)、如果金额小于等于500元，则不论是否过期都发出批准单和提货单;
4)、在过期的情况下不论金额大小还需要发出通知单。

是否大于500	是	是	否	否
是否过期	是	否	是	否
批准单	×	√	√	√
提货单	×	√	√	√
通知单	√	×	√	×

用例：

案例2：文件修改规则
规则:
1)、输入的第一列字符必须是A或B
2)、第二列字符必须是-个数字
3)、如果第一列字符不正确，则给出信息L
4) 、如果第二列字符不正确，则给出信息M
5) 、如果两列字符输入正确，则修改文件成功

第一列是否是A或B	是	是	否	否
第二列是否是一个数字	是	否	是	否
L	×	√	×	√
M	×	×	√	√
修改文件成功	√	×	×	×

用例:

6.4场景法-业务测试覆盖

重点
1、覆盖业务测试,需要使用流程图法
2、先测试业务，在测试单功能、单模块、单页面

6.4.1 流程图

提示:业务用例是根据流程图来梳理的，需要先了解流程图

使用标准图形和箭头来表达程序或业务的走向

作用:梳理业务用例
流程图对测试人员有什么作用?
1.能够看懂流程图，设计业务用例
2.当需求文档信息不全是，能够根据需求，梳理出流程
练习流程图工具：

	1、线上工具: https://processon.com/
	2、离线工具: visio
	3、其他工具: Excel

6.4.3介绍

说明:
➢场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。
意义:
➢用户使用角度:用户平时使用的不是单个功能，而是多个功能组合起来进行使用
➢测试人员角度:平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试

6.4.4使用场景

根据实际的应用场景，来测试业务用例，可以使用场景法

6.4.5案例

案例1：需求：1.用户名为admin \密码为: 123456，输出:登录成功。
2、登录、搜索商品、添加购物车、去结算、支付，如果支付成功，则提示下单成功，否则提示支付失败。

案例2：

1 开始 --》插入银行卡--》银行卡失败--》结束
2 开始 --》插入银行卡--》验证银行卡成功-》输入密码三次--》吞卡--》结束
3 开始 --》插入银行卡--》验证银行卡成功-》密码正确--》选择“取款”和金额--》账户余额不足--》结束
4 开始 --》插入银行卡--》验证银行卡成功-》密码正确--》选择“取款”和金额--》验证总取款金额---》不满足--》结束
5 开始 --》插入银行卡--》验证银行卡成功-》密码正确--》选择“取款”和金额--》验证账户余额--》验证总取款金额--》ATM机余额是否够用--》结束
6  开始 --》插入银行卡--》验证银行卡成功-》密码正确--》选择“取款”和金额--》验证账户余额--》验证总取款金额--》ATM机余额够用--》取款成功