软件测试基础知识
一、测试介绍
-
什么是软件测试:使用技术手段验证软件是否满足需求
-
测试主流技能
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机余额够用--》取款成功
补充扩展
冒烟测试:批量开始测试之前,执行业务正向用例,验证软件是否具备可测性。
6.5错误推测法
-
定义:通过经验推测系统可能出现的问题。
-
思想:根据经验列举出可能出现问题的清单,根据清单分析问题可能原因,推测发现缺陷。
-
应用场景:当项目用例都执行完毕,且BUG修复完成, 离上线还有一段时间,在这段时间中可是使用错误推荐法复测主要业务或测试未覆盖的功能。
-
做法:
- 时间紧任务量大时,根据之前项目类似经验找出易出错的模块重点测试。
- 时间宽裕时,通过该方法列出之前出现问题较多的模块再次测试。
七、缺陷管理
7.1定义
软件在使用过程中存在的任何问题都叫软件的缺陷,简称bug。
7.2缺陷标准
- 软件未实现需求(规格)说明书中明确要求的功能 -少功能
- 软件出现了需求(规格)说明书中指明不应该出现的错误 -功能错误
- 软件实现的功能超出需求(规格)说明书指明的范围 -多功能
- 软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求 -隐性功能错误
- 软件难以理解,不易使用,运行缓慢,用户体验不好 -不易使用
7.3缺陷产生的原因
-
需求阶段:需求描述不易理解,有歧义、错误等。
-
设计阶段:设计文档存在错误或者缺陷。
-
编码阶段:代码出现错误。
-
运行阶段:软硬件系统本身故障导致软件缺陷。
7.4缺陷的声命周期
1、回归测试:
- 常规项目回归:项目本次发布新增2个模块,最基本要测新增模块功能及新增模块关联的旧模块。
- 非常规项目(银行、 部队、航天) :新增功能,必须全部复测。
2、回归bug: 上一个版本发现的缺陷,开发修复完毕,在下个版本进行重新验证。
7.5缺陷核心内容【重点】
-
缺陷的标题【最难写的】:描述缺陷的核心问题
-
缺陷的预置条件【执行命令的条件】:缺陷产生的前提
-
缺陷的复现步骤【用例的步骤】:复现缺陷的过程
-
缺陷的预期结果:希望得到的结果
-
缺陷的实际结果:实际得到的结果
-
缺陷的必要附件:图片、日志等信息(证据)
7.6缺陷提交要素【重点】
7.7缺陷类型
1、功能错误
2、Ul界面错误(即图片错误,显显不出来)
3、兼容性(如在edge可以打开,在chrome中打不开)
4、数据(数据库)
5、易用性
6、改进建议
7、架构缺陷
7.8 工作流程
设计用例 —— 执行用例(执行测试)—— 缺陷(缺陷管理的过程:1. 提交、2. 验证、3. 关闭)
7.8缺陷编写
7.8.1缺陷报告实例
注意1:缺陷报告不一定是用Excel描述,也可以使用其他工具描述。
注意2:
7.8.2缺陷标题分析
7.8.3缺陷跟踪流程【重要,面试常问】
1、回归测试:
- 常规项目回归:项目本次发布新增2个模块,最基本要测新增模块功能及新增模块关联的旧模块。
- 非常规项目(银行、 部队、航天) :新增功能,必须全部复测。
2、回归bug: 上一个版本发现的缺陷,开发修复完毕,在下个版本进行重新验证。
注:
①提交缺陷,回归测试[验证缺陷],关闭缺陷是测试人员;处理缺陷是开发人员
②提交缺陷的缺陷状态是新建new;
③重新打开的缺陷状态是打开open。
7.8.4提交注意事项
- 可重现:缺陷可以复现
- 唯一性:一个缺陷上报一个问题
- 规范性:符合公司或者项目要求
面试题:发现缺陷后,首先回怎么办?
确定Bug可复现、确定是Bug。提交时,要检查缺陷是否已存在。
7.8.5缺陷的编写规范
- 准确:描述的信息是正确的。
- 具体:有细节且是真实特定的。
- 简洁易懂:描述简单容易理解。
- 次序清晰:描述缺陷过程有条件,有先后顺序。
7.9缺陷管理工具
项目管理工具有两种:1. 管理缺陷(禅道、JIRA、TFS、bugfree等),2. 使用Excel表格管理缺陷。
7.9.1禅道的介绍
-
地址: https://demo.zentao.net/user-login.html
-
特点:① 国产、免费、开源、简单、轻量级;② 三管融合(产品管理、项目管理、质量管理)。
-
三全分立:
- 产品部门—构想者
- 研发部门一执行者
- 测试部门一保证者
-
四角协同:产品经理、项目经理、研发团队、测试团队
7.9.2禅道的使用流程
使用的过程
1 登录。选择相应的登录
2 提交缺陷。点击bug,选择由我创建,点击提交bug
3 进入提交bug页面,填写相关缺陷信息
4 关闭缺陷
7.9.3禅道管理用例
1.选择功能测试,点击建用例。
2.填写用例的相关信息,点击保存,保存后如图所示。
3单击后结果如下