软件功能测试
第一章：软件测试概念和理论
1.1 测试的目的和原则
软件测试测目的
测试的目的是为了找到软件 / 网站存在的问题（ bug 、用户体验不好、界面丑陋、功能是否全面）
通过提前找到软件存在问题，可以降低商业风险【省钱】
软件测试的定义
软件测试就是用人工或者自动化对软件系统进行测试，通过测试需要找到预期结果和实际结果的差
异
预期结果：在测试之前我们就知道的结果 / 希望出现的结果
实际结果：测试之后得到的实际结果
软件测试基本原则
1 ）所有软件只能证明存在问题，不能证明不存在
辨证
所有的软件的都是有问题的，只是这些问题是否已经发现了
2 ）不能进行穷举测试，应该进行分类测试
穷举：将所有的可能都测试一遍
分类测试
可以被正常搜索的：也就是可以正常显示的哪些，比如男装
不能正常搜索的：也就是哪些不应该被显示的对象，比如各种违禁品
特殊情况：带有特殊符号、空格、什么都不输入，
3 ）测试工作应该尽早介入，可以降低修复成本
及早发现问题，及早解决
4 ）缺陷聚集原则，二八法则
一个项目中 80% 缺陷会集中中 20% 的功能模块中
越是有问题的地方，这里往往会有其他的问题
出现这个现象的原有
复杂这个模块的程序员技术水平一般
模块功能功能复杂
5 ）测试依赖环境
程序的架构： B/S C/S
B/S 架构： Broswer/Server ，通过浏览器访问服务
C/S 架构： Client/Server ，通过客户端程序访问服务
测试 B/S 架构准备三款浏览器：谷歌、火狐、 IE 【苹果、欧鹏、 QQ 、 360 、搜狗】
测试 C/S 架构准备： PC ： win7 、 8 、 10 ， mac ， linux
手机：安卓、苹果、鸿蒙
6 ）杀虫剂现象
测试人员在经过一段时间后会进入自己的固有的思维意识，很难在测试出其他的 bug ，这个时候可
以进行交叉测试，就是交互测试人员。
7 ）不存在缺陷谬论
同第一条重复的
1.2 软件开发模型
1.2.1 简介
软件的生命周期：软件开发模型
软件测试与软件的开发模式有着紧密的联系，作为一名测试人员，应该充分理解软件的开发模式，以便
找准自己在其中的位置，从而发挥自身的价值
在软件开发的几十年实践中，人们总结了很多软件开发模型用来描述和表示一个复杂的开发过程，软件
开发有三种模式：
瀑布模型
快速原型模型
螺旋模型
1.2.2 三种模型
瀑布模型
第一个阶段：项目立项阶段
1. 调研： 首先对项目进行可行性的研究，通过可行性的研究可以判断这个项目是否挣钱
调研完成后会得到一个可行性调研报告。
这个工作是有项目负责人来完成
2. 需求分析：
调研判断项目没问题以后，就可以进行需求分析。
这个工作是又项目经理完成。
最终会得到一个需求规格说明书。规格书中仅仅是需求大体说明。
第二个阶段：项目开发阶段
1. 概要设计：
就是将需求规格书中的内容落地。
概要设计完成后，会得概要设计文档。
这个是由经验丰富的前端和的后端程序员。
概要设计文档中会将整个项目分成若干个功能模块，而且会明确说明每个模块中的功能。
2. 详细设计：
在详细设计中，明确指定了模块具体实现的细节。
整个工作由一线程序员来完成。
最终会得到一个详细 设计文档。
3. 编码：
其实就是程序员写代码。
这个是由程序员完成的。
最终得到的是代码
4. 软件测试：
测试软件是否可以正常运行，是否达到了预期的功能。
这个是由测试工程师来完成。
最终会得到测试报告。
第三个阶段：项目运维阶段
1. 上线，用才能访问
瀑布模型的特点
是以文档驱动，后面所有的工作都是基于前面的文档的内容。
每个阶段执行一次，而且是线性依次进行的
开发模式中，瀑布模型是非常重要的一种
瀑布模型的优点
各个阶段非常清晰
每个人只需要关注自己的阶段
瀑布模型的缺点
下面的阶段是依赖上面阶段的分析结果的，一旦上面出现错误，那么下面全部都错了
整个流程过分依赖需求分析结果，这种模式不能适应变化频繁的项目
这种模式设传统项目和行业：银行、保险、建筑
快速原型模型
一个项目在很短时间能，就有一个版本上线了，这个版本往往功能不全，而且有 bug
在后续的版本中陆续修复 bug ，并添加完善功能 特点：
快速上线
支持用户参与
优点：
克服了瀑布模型的缺点，减少中间环境，可以及早发现问题并进行修复
缺点：
仅仅适合中小型项目，不适合大型项目
螺旋模型【不做要求】
1.3 软件测试模型
测试模型：所谓的模型就是这个行业的人总结出来的测试经验。
第一种： V 模型
这种模型其实就是在前面瀑布模型的基础上进行测试的
这种模型其实也是瀑布模型的变种
根据测试阶段不同，测试也同样分成四个不同的阶段 V 型的流程
用户需求 => 需求分析 => 概要设计 => 详细设计 => 编码 => 单元测试 => 集成测试 => 系统测试
=> 验收测试
优点：
整个流程比较清晰，即包含了底层测试，也包含了对高层进行测试
缺点：
这个本质上还是瀑布模型，因此具有瀑布模型的缺点
第二种： W( 双 V) 模型
这种模式主要是为了解决 V 型模型存在的问题，解决思路就是测试前移
W 型比 V 型多的部分
集成：每个程序员将自己负责的功能模块合并到一起
实施：将 开发好的软件安装到客户的服务器上
交付：教给用户如何使用软件
静态和动态测试
W 模型中，对各种的文档进行测试，都是静态测试
对程序进行测试，就是动态测试
总结： W 模型中的流程
开发 V ：用户需求 => 需求分析 => 概要设计 => 详细设计 => 编码 => 集成 => 实施 => 交付
测试 V ：验收测试设计 => 系统测试设计 => 集成测试设计 => 单元测试设计 => 单元测试 => 集成测试 =>
系统测试 => 验收测试 优点：
测试工作前移，可以今早发现存在的问题
缺点：
对技术和管理能力要求较高
1.4 软件质量模型
质量体系： ISO 9126
六大特性
功能性
可靠性
易用性
效率
维护性
可移植性
1.5 软件测试分类
第一种分类方法：按照阶段分类
单元测试
模块：程序的最小单位就是模块，比如用户登录模块、购物车模块
单元测试：就是检测这个模块是否满足测试用例的要求，仅仅是测试一个单独的模块是否能
正常运行
集成测试
集成测试又称为 组装测试
在单元测试完成以后，就是表示每个单独的模块已经正常
集成测试，就是将多个模块组合起来进行测试
系统测试
在集成测试完成以后，才能进行系统测试
系统测试，将软件作为一个整体来测试，测试的依据是软件需求说明书【就是检查软件是否
达到了当初想要的样子】
验收测试
主要是检查软件是否满足客户的要求，对软件做最后的测试
验收测试分为几个小类
α 测试【 Alpha 】：阿尔法测试的软件版本内存版本，软件 bug 较多，一般不让用户直接
使用，而是公司内部交流使用。
β 测试【 Beta 】：贝塔测试就是软件的公测版本，目的就是让更多的用户通过使用软件
来发现更多的问题。
γ 测试【 Gamma 】：伽马测试就是软件的正式候选版，这个版本和用户最后使用的正式
版几乎完全一致。
第二种分类方法：按是否查看源码分
白盒测试 不去执行程序，而是去直接读取程序的代码
黑盒测试：
又称之为数据驱动测试
这种测试就是直接使用软件，完全不考虑程序内部结构和代码
例如：输入账号、密码，一点就能登录成功，就表示测试通过
灰盒测试
即要去读程序的代码
也要去执行程序
既要做黑盒的工作，也要做白盒的工作
第三种分类方法：按照是否运行程序划分
静态测试
动态测试
第四种分类方法：是否自动运行
人工测试：所有的测试工作，由测试人员手动点击完成
自动化测试：通过 python 开发自动化工具，用工具完成测试工作
第五种分类方法；其他分类
冒烟测试
测试软件基础功能是否正常
回归测试
在测试工作种，一旦发现了 bug ，需要将这个 bug 提交给开发，开发修复完成后，需要重新进
行测试
测试人员必须对哪些曾经发生过的 bug 再次进行测试
随机测试
虽然叫做随机测试，但是不是真的随机
这里的随机其实是重复测试，包括测试之前的测试用例种没有涵盖的部分
探索测试
这个测试不是必要
1.6 软件缺陷
缺陷不等于 bug
bug 仅仅是缺陷中的很小的一个部分而已
什么是缺陷：只要让测试人员感觉不爽，那么这个就是缺陷
软件缺陷判定标准
1. 软件未能达到需求规格书中的要求
2. 软件的功能超出规格书中的要求
3. 软件出现了规格书中明确指定不能出错的地方
4. 软件出现了规格书中未明确指定，但是不应该出现的错误 软件缺陷产生的原因【缺陷只能减少、不能完全避免】
1. 对于需求文档等文等文件解释、理解错误【需求说明会】
2. 设计文档本身有错误
3. 程序代码错误
4. 硬件和软件系统有错
软件缺陷的类型
1. 功能错误：软件没有达到需求文档的功能要求，或者功能异常
2. 界面错误：软件功能正常，但是界面不好看或者未达到规格说明中的要求
3. 兼容性错误：软件和系统中的其他的程序冲突，导致软件无法运行
4. 易用性错误：软件用起来不好用
5. 改进建议：改了更好，不改也没事
第二章：测试用例设计方法
2.1 测试用例
测试用例：
将要进行的测试工作，具体化，并且记录到一个文件中，一般情况下是一个 excel 【表格】
在测试用例中，明确的指定了每一步做什么操作，期望得到什么结果
测试工作
等程序员完成代码，此时可以进行前期准备工作，就是编写测试用例，将需要测试的每一项都填写
到表格中
当程序员完成了代码，此时就可以开始进行测试，也就是根据表格中的内容一项一项的进行测试
测试用例的基本构成
第一部分：测试用例编号：
编号必须唯一
编号的构成可以写成： 项目名 - 模块名 - 编号
例如：测试网站登录模块，而且是第三条用例，编号可以这么写： web-login-03
第二部分：模块名
第三部分：优先级
用于测试正常的功能用例，优先级要更高一些
一般是用 P1 P2 P3 来表示优先级
数字越小，优先级越高 第四部分：用例标题
在用例标题中，需要说明这条测试用例的功能以及预期出现的结果
第五部分：测试步骤
这个是指定这个条测试用例如何操作和执行
第六部分：预置条件
第七部分：测试数据
在进行测试的时候，输入什么数进行测试
这些数据既有满足条件的数据，也有不满足条件的数据
第八部分：预期结果
这条用例希望得到的结果
2.2 等价类方法
设计测试用例的方法很多
穷举测试
将所有可能的数据都测试一遍
但是实际上，这种方法不可行
等价类：
分析测试的数据，找出其中的规律，然后从规律中找出有特点的数字进行测试就可以了
通过划分等价类，可以避免进行穷举测试
等价类的种类
有效等价类：
满足条件的数据，就是属于有效等价类
例如：找 6-10 位长度自然数： 123456
无效等价类：
不满足条件的数据，就是属于无效等价类
例如：找 6-10 位长度自然数： 12345 、 12345a
用等价类方法设计测试用例步骤
第一步：分析需求
通过分析需求，判断项目需要达到什么效果
第二步：划分等价类【找到有效 / 无效的数据】
案例：找 6-10 位长度自然数
有效等价类：比较好找， 123456 1234567
无效等价类：相对复杂，可以从以下几点来思考
数据长度不符合：过长、过短
数据内容不符合
数据是否为空
数据是否重复 第三步：结合等价类设计测试用例
有几条等价类，就根据等价类设测试用例
等价类的适用场景
搜索框
登录框
注册页面
案例 1 ：判断 qq 是否在合理的范围【 6-12 位】
案例 2 ：登录 qq 邮箱
要求用户输入账号和密码
邮箱的名字： 6-20 位字符，支持数字、字母、下划线，但是名字不能都是下划线
邮箱的密码： 6-10 位， 用数学表达是表示
数学表示
上点
内
点
离点
大于等于 -99 ，小于等于
99
[-99 , 99]
99
-99
30
100 98 -98 -100
大于 -99 ，小于等于 99
(-99 , 99] 等价于 [-98 ,
99]
-98
99
30
100 98 -97 -99
大于等于 -99 ，小于 99
[-99 , 99) 等价于
大于 -99 ，小于 99
(-99 , 99) 等价于
2.3 边界值方法
两位数加法器：
计算的范围： -99 ~ 99
计算的方法：加法
在日常的测试工作，经常发现，在数据的 临界值位置 是经常出现 bug 的，因此这种位置就应该作为我们
重点的测试对象
边界值：
有效等价类和无效等价类的边界
这也是一种黑盒测试方法
边界值的三个概念：
上点：边界值上面的这个点，就是上点
内点：有效等价类中的任意一个点
离点：边界值相邻的两个点
数学表示方法
[ 大于等于
] 小于等于
( 大于 用数学表达是表示
数学表示
上点
内点
离点
大于等于 6 ，小于等于 12
[6 , 12]
6 ， 12
8
5 7 11 13
) 小于
边界值的使用场景
项目中出现了 > < = 之类的符号
项目中出现了大于、等于、小于之类的描述
案例 1 ：判断 qq 是否在合理的范围【 6-12 位】，结合边界值设计测试用例
边界值的优化
必须保留的点：上点、离点中的无效等价类中的点、内点，一共是 5 个点
优化后结果如下 2.4 判定表方法
判定表 ：
以 表格的形式 来组合多个条件
通过判定表可以综合考虑多个条件的输入和输出结果之间的关系
案例：手机通话
条件：
是否欠费：欠费、不欠费
是否开机：开机、关机
条件组合
条件 1: 是否欠费 条件 2: 是否开机 结果
欠费 关机 不能通话
欠费 开机 不能通话
不欠费 关机 不能通话
不欠费 开机 能通话
转换为表格形式
概念：
条件桩：所有可能出现的条件，例如上例中，有两个条件：是否欠费、是否开机
动作桩：所有可能出现的值，例如上例中，有四个值：欠费、不欠费、开机、关机
条件项：这是条件桩中的一个或者多个
动作项：这是动作桩中的一个或者多个值
等价类：
有效
无效
在判定表中，表示有效和无效有两种表示方式
方式 1 ：用字母表示
有效等价类： Y
无效等价类： N
方式 2 ：用数字表示
有效等价类： 1
无效等价类： 0
基于判定表的方式设计测试用例的步骤
1. 第一步：首先确定条件桩
2. 第二步：确定动作桩
3. 第三步：对条件桩进行组合
4. 第四步：确定条件组合的结果
5. 第五步：根据结果写测试用例 案例：手机通话
条件：
是否欠费：欠费、不欠费
是否开机：开机、关机
第一步：首先确定条件桩
是否欠费
是否开机
这里是有两个条件，那么就是在表格中写入两行内容，每行代表一个条件
第二步：确定动作桩
一共有四种动作，每个条件桩中有 2 个，一共有四个动作
欠费、不欠费
开机、关机
第三步：对条件桩进行组合
将每个条件的每个值都和另外一个条件的每个值进行组合
第四步：确定条件组合的结果
第五步：根据结果写测试用例
略
思考：条件数量，和测试用例的数量是什么关系
条件越多，得到的测试用例的数量越多
有两个条件的话，得到的测试用例数 2**2 = 4
有三个条件的话，得到的测试用例数 2**3 = 8
有四个条件的话，得到的测试用例数 2**4 = 16
2.5 因果图方法
作为了解的部分
以图形的方式来表示多个不同的条件 / 输入以及对应的最终结果的关系
也是一种黑盒测试方法
适用场景：
有多个输入条件的情况下
概念：
因：条件 果：结果
符号：
结合因果图设计测试用例的步骤
第一步：分析需求
第二步：画因果图
第三步：将因果图转换为判定表
第四步：结合判定表写测试用例
案例：让用户输入内容，要求输入的第一个字符是数字 5 或 7 ，第二个字符是字母
如果第一个字符不正确，输出结果 L
如果第二个字符不正确，输出结果 M
如果都正确，输出 Q
绘制因果图
将因果图转换为判定表
2.6 正交方法
这种方法同样是用在多个输入和多个输出的情况
正交法：
本质上是用数学中的数据统计【统计学】中的方法进行测试。
通过正交法可以用少量测试用例来覆盖大多数的测试情况
概念：
因素【
k 】：表示的是输入的条件，每列是一个因素
水平【 m 】：表示的是输入的条件所得到的结果，表格中的每个小格是一个结果
- 恒等，表示当条件成立的时候，结果成立 ; 当条件不成立的时候，结果不成立
~ 相当于 NOT ，也就是逻辑非，表示当条件成立的时候，结果不成立 ; 当条件不成立的时候，结果成立
v 相当于 OR ，也就是逻辑或，表示当多个条件中，有至少一个条件成立的时候，结果成立 ; 当全部条件都不
成立的时候，结果不成立
^ 相当于 AND ，也就是逻辑与，表示多个条必须都成立，结果成立 ; 当有任意一个条件不成立的时候，结果不
成立 n ：测试用例数
表示正交表的： k 因素 m 水平，例如 5 因素 3 水平
基于正交表法设计测试用例的步骤
第一步：需求分析
第二步：确定因素和水平【其实就是找有几个输入和几个结果】
第三步：根据因素和水平的数量，确定选择哪个正交表
第四步：将具体的值替换掉正交表中的内容
第五步：根据正交表写测试用例
案例 1 ：设置字体属性
字体：仿宋、楷体、微软雅黑
字符样式：粗体、斜体、下划线
颜色：红色、黑色、蓝色
字号： 20 号、 30 号、 40 号
第一步：需求分析
要测试 4 个内容，也就是有 4 个输入
第二步：确定因素和水平 【其实就是找有几个输入和几个结果】
有 4 个输入，就是有 4 个条件，也就是有 4 个因素
每个因素都有三种结果，那么就是 3 水平
结论： 4 因素 3 水平
第三步：根据因素和水平的数量，确定选择哪个正交表
第四步：将具体的值替换掉正交表中的内容
字体： 仿宋 (1) 、 楷体 (2) 、 微软雅黑 (3)
字符样式：粗体 (1) 、 斜体 (2) 、 下划线 (3)
颜色： 红色 (1) 、 黑色 (2) 、 蓝色 (3)
字号： 20 号 (1) 、 30 号 (2) 、 40 号 (3)
第五步：根据正交表写测试用例
正交表中的每一行，都是一个测试用例 略
用工具生成正交表
2.7 场景法
又称为流程图法，用图形的方式来表示测试的条件和输出的结果
概念：模拟用户对软件进行操作的场景
这种方法更合适测试多个模块
适合用在测试过程中的哪个阶段？
集成测试
系统测试
验收测试
基于场景法设计测试用例的步骤
1. 第一步：分析需求
2. 第二步：绘制流程图
3. 第三步：根据流程图写测试用例
流程图中的符号
绘图软件：
visio
亿图
案例：电商平台购物流程
购物过程包括
1. 注册
2. 登陆
3. 商品列表
4. 购物车
5. 付款
6. 订单管理
流图图如下 设计测试用例
流程图中的一条先就是一个测试用例
1 - 2 - 3 - 4 - 5 - 5.1 - 6 1 - 2 - 3 - 4 - 5 - 5.2 - 6
1 - 2 - 3 - 4 - 5 - 5.3 - 6
1 - 2 - 2 - 2
1 -2 - 2 - 3 - 4 - 5 - 5.1 - 6
1 -2 - 2 - 2 - 3 - 4 - 5 - 5.1 - 6
2.8 错误推断法
凭借经验来做的
原理就是根据同类型的软件的具有的 bug ，判定这个目标软件也有这个 bug
使用场景：
时间、资源不充足情况才会是使用
使用这种方法，通常都是做初测
2.9 总结
等价类：测试的内容有输入功能，而且输入的内容之间没有关系
边界值：输入的内容有边界，有类型、大小、长度的要求
判定表 / 因果图：有多种输入的内容，而且有多种输出结果
正交法：测试的数据和条件特别多
场景法：整合测试多个功能，需要使用场景法
错误推断法：时间、资源补充足；仅仅需要做初测