软件测试 - 功能测试（测试理论+用例设计）

1.软件的定义软件：是计算机程序、程序所用的数据以及有关文档资料的集合软件分为系统软件和应用软件系统软件：是生成、准备和执行其他程序所需要的一组文件和程序，比如：操作系统应用软件：计算机用户为解决某些具体问题而购买的、开发或研制的各种程序或软件包，比如APP2.应用架构C/S架构：必须安装一个客户端才能使用的软件（client-server）缺点：每次更新，必须更新服务端和客户端B/S架构：

奋斗吧，青年！

41741人浏览 · 2021-12-24 13:16:36

奋斗吧，青年！ · 2021-12-24 13:16:36 发布

一、测试理论基础

1.软件的定义

软件：是计算机程序、程序所用的数据以及有关文档资料的集合
软件分为系统软件和应用软件
系统软件：是生成、准备和执行其他程序所需要的一组文件和程序，比如：操作系统
应用软件：计算机用户为解决某些具体问题而购买的、开发或研制的各种程序或软件包，比如APP

2.应用架构

C/S架构：必须安装一个客户端才能使用的软件（client-server）
缺点：每次更新，必须更新服务端和客户端
B/S架构：只需要一个浏览器，就可以访问的服务（browser-server）

3.什么是软件测试

软件测试：
使用人工和自动手段来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别；

测试目的：
(1).发现程序(软件)存在的代码或者业务逻辑错误
(2).检验产品是否符合用户需求
(3).提高用户体验

以最小的人力、物力和时间，找到软件中潜在的错误和缺陷。

4. 测试的分类 *

(1).按测试技术划分：黑盒测试、白盒测试、灰盒测试

黑盒测试
- 黑盒测试：也称功能测试或数据驱动测试，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
- 黑盒测试方法：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。
白盒测试
- 白盒测试：也称为结构测试或逻辑驱动测试，白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法。
- 白盒测试原则：
  - （1）保证一个模块中的所有独立路径至少被测试一次；
  - （2）所有逻辑值均需要测试真（true）和假（false）两种情况；
  - （3）检查程序的内部数据结构，保证其结构的有效性；
  - （4）在上下边界及可操作范围内运行所有循环。
- 白盒测试方法：
  - 语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
灰盒测试
- 大概知道代码逻辑实现，不需要看懂所有的代码

(2).按测试对象是否运行划分：动态测试、静态测试

静态测试
- 不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。
动态测试
- 需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。

(3).按不同的测试手段划分：手工测试、自动化测试

手工测试
- 点工
自动化测试
- 工具+代码

(4).按测试包含内容划分：功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试

功能测试
- 测试软件的功能是否符合需求，通常采用黑盒测试方法，一般由测试人员独立执行。
界面测试
- 也称UI测试，测试用户界面布局是否合理，整体风格是否一致，界面文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。
安全性测试
- 验证应用程序的安全等级和识别潜在安全缺陷的过程。目的是为了查找软件自身程序设计中存在的安全隐患，并检查应用程序对非法侵入的防范能力（登录、防攻击、sql注入）
兼容性测试
- 兼容性测试是指检查被测软件在不同的硬件平台上、不同的应用软件之间、不同的操作系统中、不同的网络环境中是否可以正常运行的一种测试。
易用性测试
- 这种测试方法，不是去测试软件能不能用，而是去测试软件好不好用，用户学习成本高，所以主观性比较强烈。一般要根据多个用户的测试反馈信息，才能评价易用性到底好不好。（人性化、舒适、是否符合用户使用习惯、比较主观）
性能测试
- 一般性能测试：相应速度，对资源（CPU/内存）的利用
- 压力测试：高负载的情况下进行的，目的不是为了获取性能指标，而是想要了解系统是否稳定。
- 负载测试：通过不断调试并发数获取性能瓶颈。（极限）
- 强度测试：为了确定系统在最差工作环境的工作能力，或用于验证在标准工作压力下的各种资源的最下限指标。

(5).按测试阶段划分：单元测试、集成测试、系统测试、验收测试（α测试、β测）

单元测试
- 完成最小的软件设计单元（模块、类、函数、方法）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒测试，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。
集成测试
- 通过测试发现与模块接口有关的问题（模块与模块之间的调用）。目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构，应当避免一次性的集成，而采用增量集成。（接口测试）
系统测试
- 是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。
验收测试
- 是一项确定产品是否能够满足合同或用户所规定需求的测试。验收测试包括α测试、β测试、γ测试。
- α测试
  - 是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为β版本。（内测版本，bug多）
- β测试
  - 是由软件的多个用户在实际使用环境下进行的测试，这些用户返回有关错误信息给开发者。一般只提供给特定的用户群来测试使用。（公测版本）
- γ测试
  - 此时产品已经相当成熟，只需在个别地方再做进一步的优化处理即可上市发行。（候选发布版本）

其他测试：回归测试、冒烟测试、探索性测试/自由测试

回归测试
- 回归测试是指在代码发生修改之后重新测试先前的测试用例以保证修改的正确性。
冒烟测试
- 指针对最基本的功能或最主要的业务流程（核心功能）进行测试。比如电商购物流程：注册、登录、选商品、加入购物车、支付、订单管理。
探索性测试
- 是敏捷世界里的一种重要测试方法，作为一个研究性的工具，它是用户故事测试和自动化回归集的重要补充。（靠经验、积累、测试思维）

5.测试的原则

1.证明软件中存在缺陷
2.不能穷尽测试
3.测试应用尽早介入
4.28原则
5.不存在缺陷谬论
6妥善保存一切文档

6.测试的流程

(1).需求分析
- 阅读需求文档，熟悉项目；参与需求评审
(2).制定测试计划和测试方案
- 测试计划：测试整个项目的总体规划，比如：测试范围，进度安排，人力物力安排，整体的测试策略，风险评估，风险规避..
- 测试方案：被测目标，测试工具选取，测试方法，测试重点
- 遵循 5W 1H 原则：why when who what where how
(3).设计测试用例
- 常用测试方法：等价类，边界值，场景法...
(4).测试用例评审
- 参与人员一般有：产品经理，开发，测试
(5).执行测试用例
- 开发完成后，开始执行测试用例，发现Bug，提交给开发人员，开发人员修复完成后，重新指派给测试人员，测试人员开始回归测试，通过就关闭，没有通过就继续修复Bug；
(6).编写测试报告
- 对测试情况做个总结（发现了多少bug，修复了多少bug，还有哪些没修复...）
软件测试的生成周期：
需求分析 --> 制定测试计划 --> 设计测试用例 --> 测试用例评审 --> 执行测试用例 --> 编写测试报告

软件的生命周期：是软件开始研制到最终被废弃不用所经历的各个阶段。

计划阶段 --> 需求分析 --> 设计阶段 --> 编码 --> 测试 --> 运行与维护

7.软件开发模型

开发模型（软件生命周期模型）：是指软件从开始研制到最终被废弃所经历的各个阶段。在不同的阶段里，由不同的组织和人员执行不同的任务。软件测试与软件的开发模式有着紧密的联系，作为一名测试人员，应该充分理解软件的开发模型，以便找准自己在其中的位置，从而发挥自身的价值。

7.1 瀑布模型 *

特点：线性模型，在所有的开发模型中占有重要地位，是其他模型的基础以文档驱动，每个阶段执行一次，按线性顺序进行软件开发。
优点：开发的各个阶段比较清晰当前阶段完成后，只关注后续阶段
缺点：依赖于在其的需求分析，不适应需求的变化，风险往往在后期显露，失去及早纠错的机会；
典型应用场景：需求清晰的大型项目，如：银行、保险、建筑等；

7.2 增量模型

把瀑布模型的顺序特征与快速原型法的迭代特征相结合，将软件看作一系列相互联系的增量，在开发过程的各次迭代中，每次完成其中的一个增量。

7.3 快速模型

特点：快速模型是快速建立起来的可以在计算机上运行的程序；

7.4 螺旋开发模型

7.5 迭代开发模型

7.6 敏捷开发模型

8.软件测试模型

在软件测试的实施中，针对于测试过程出现的问题，通过经验总结得到测试过程模型，旨在提高软件开发测试过程中的效率与效果。

8.1 V模型

优点：展示测试由底层（代码）到高层（用户业务）按阶段测试的实现过程
缺点：不适用于需求变化，灵活性差

8.2 W模型

W模型，简称“双V”模型，即以开发主导的一个“V”，和以测试主导的另一个“V” - 为了克服V模型的缺点，引入了W模型。

优点：测试伴随整个产品开发周期，测试对象不仅是程序还有需求、设计文档测试介入较早，及早发现问题，降低修复成本
缺点：实施起来比较复杂，难度大，对于需求阶段和设计阶段的测试设计要求较高（计算机技术、业务知识、管理能力、测试素质等）

9.软件质量模型

9.1 软件质量

软件质量，就是软件与明确地和隐含地定义得需求相一致得程度。

9.2 质量模型标准

对于测试作用：提供测试设计的不同角度和思路

ISO/IEC 25010

功能性：满足某种功能需求的一种属性或能力
性能效率：在规定条件下，相对应所用资源的数量，软件产品提供适当性能的能力
兼容性：在一定条件下兼容其他软硬件产品的能力
易用性：在指定使用条件下，产品被理解、学习、使用和吸引用户的能力
可靠性：产品在规定条件下，在规定的时间内完成规定功能的能力
信息安全性：信息在传输或者存储过程的安全程度
可维护性：（四规），在规定条件下，规定的时间内，使用规定的工具或方法修复规定功能的能力
可移植性：从一种环境迁移到另一种环境的能力

10.测试用例

10.1 生活中的测试用例

比如：购买一台电脑或者手机，如何验证其是否满足自己的需求？

是否能够正常的开关机、运行速度是否快、屏幕大小是否适合、存储空间是否满足要求 ......

例如：购买手机是否满足其中两个目标

10.2 测试用例的定义

测试用例又叫 test case，是为了某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定的需求。(验证产品功能实现是否满足用户需求)

10.3 测试用例的八大要素 *

用例编号：表示用例的唯一性，有时也叫用例ID，由字符和数字组合成的字符串
用例标题：表示要测试或验证的目的，对测试用例的简单描述，用概括的语言描述该测试用例的测试点（如何测试+测试内容）
测试项目：当前测试的功能所属范围
用例级别：表示用例测试功能的重要程度或者影响力
- 高级别：保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例
- 中级别：重要程度介于高和低之间的测试用例
- 低级别：实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例
预置条件：验证该功能需要的前提条件
输入数据：必要的输入数据
执行步骤：验证该功能需要的先后操作步骤
预期结果：希望得到的结果
其他要素
- 用例的设计者
- 用例设计日期
- 对应的开发人员：出现Bug后能及时找到相应的开发人员进行修复
- 测试结果：执行测试用例后的实际结果，包括：pass、fail、block
- 测试类型

测试模板：

10.4 测试用例设计原则

明确性
- 测试人员要尽量避免测试用例存在含糊的因素，在测试过程中，测试用例的测试结果是唯一的。
代表性
- 尽量将具有相似功能的测试用例抽象合并，功能相似的用例要合并。
简洁性
- 测试用例简洁，可读性良好，测试过程目的明确，测试结果唯一。

10.5 测试用例的编写流程

需求分析 --> 提取测试点 --> 测试用例设计 --> 测试用例评审 --> 修改测试用例

二、测试用例设计方法

1.等价类划分法 *

定义
- 等价类划分法将所有可能输入的数据，即程序的输入域，划分为若干部分，然后从每一部分中选取少数有代表性的数据作为测试用例。使用等价类划分方法设计测试用例需要经历划分等价类和选取测试用例两步，他将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。
作用
- 从穷举测试中解放出来，找到具有共同特性的测试输入子集。
类型划分
- 有效等价类
  - 对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。(满足需求)
- 无效等价类
  - 对于程序的规格说明来说是不合理的、无意义的输入数据构成的集合。(不满足需求)
基本步骤
- 1.需求分析
- 2.划分等价类
  - 有效等价类
  - 无效等价类
    - 规则（需求本身）
    - 长度
    - 类型
    - 是否为空（必填项）
    - 是否重复
- 3.设计测试用例
  - 尽可能多的覆盖尚未覆盖的有效等价类
  - 仅覆盖一个尚未覆盖的无效等价类
应用场景
- 针对需要数据量大，有测试数据输入的地方
- 典型代表：页面级的输入框类测试
案例
- 案例1：验证QQ账号的合法性
- 案例2：验证某城市电话号码正确性
- 案例3：新浪邮箱登录

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

案例2：验证某城市电话号码正确性

区号：非空或者是三位数字
前缀码：非“0”且非“1”开头的三位数字
后缀码：四位数字

案例3：新浪邮箱登录

要求输入（邮箱名）@sina.cn 和（密码）
邮箱名：4-16 位字符，支持英文、数字、下划线（不能全是数字或者下划线）
密码：6-18 位字符

2.边界值分析法 *

定义
- 边界值法是对输入或输出边界值进行测试，通常作为等价类划分法的补充。
- 因为大量错误是发生在输入或输出范围的边界上，而不是输入范围的内部。
- 基于边界值【有效等价类和无效等价类的分界点】设计测试用例的一种【黑盒】方法
原则
- 确定边界：应该选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据
- 两点法三点法四点法
- 次边界值：IP地址（0-255）时间格式（0-23）...（常识）
- 特殊边界值：0，负数，空值，空格
边界值
- 上点：边界之上的点
- 内点：边界之内的点
- 离点：离边界最近的左右两点

两位数加法器：

边界范围取值优化
结论： 7个点优化为 5个点
- 上点：必选（不考虑区间开闭）
- 内点：必选（建议选择中间范围）
- 离点：开内闭外（考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）
设计测试用例步骤
- 需求分析
- 划分等价类
- 确定边界
  - 上点
  - 内点
  - 离点
- 设计测试用例
应用场景
- 存在边界 > >= < <=
- 典型代表：有边界范围的输入框类测试
案例
- 案例1：验证标题长度的合法性
- 案例2：验证QQ号码的合法性
- 案例3：新浪邮箱登录

案例1：验证标题长度的合法性，要求标题长度大于0，小于等于30个字符 (0, 30]

案例2：验证QQ号码的合法性，要求 6~10位自然数

测试用例：

边界值分析法，与等价类分析法对比来看，会有重复的用例

案例3：新浪邮箱登录

要求输入（邮箱名）@sina.cn 和（密码）
邮箱名为：4-16 位字符，支持英文、数字、下划线（不能全是数字或者下划线）
密码：6-18 位字符

3.判定表分析法 *

定义
- 判定表也称决策表，它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。
- 存在多个输入条件、多个输出结果，输入和输入之间有组合关系，输入和输出之间有依赖或制约关系。
- 判定表是因果图的最终结果。
判定表的组成
- 条件桩：所有输入条件，如欠费状态、关机状态
- 动作桩：所有的可能的输出结果，如允许主被叫 (打通)、不允许主被叫 (打不通)
- 条件项：单个条件的取值范围，一般都是有效等价类和无效等价类
  - 表示方式
    - 字符
      - 真/有效等价类（Y）
      - 假/无效等价类（N）
    - 数字
      - 真/有效等价类（1）
      - 假/无效等价类（0）
- 动作项：基于每一种条件的组合，得到确认的结果，如打不通等
设计测试用例步骤
- 1. 明确条件桩（找到所有的输入条件）
- 2. 明确动作桩（找到所有的输出结果）
- 3. 对条件桩进行全组合
- 4. 明确每个组合对应的动作桩（基于每一种条件的组合情况，确定本组合下的输出结果）
- 5. 设计测试用例，每行数据对应一条测试用例
真假表示说明
假设有N个条件，每个条件的取值有两个(0,1)，全组合有 2^N 种规则
应用场景
- 有多个输入条件，多个输出结果，输入条件之间有组合关系
- 输入条件和输出结果之间有依赖 (制约) 关系
案例
- 案例1：用户呼叫
- 案例2：订购单检查
- 案例3：文件修改规则

案例1：用户呼叫

若用户欠费或关机，则不允许主被叫

案例2：订购单检查

订单检查，如果金额大于500元，又未过期，则发出批准单和提货单；
如果金额大于500元，但过期了，则不发批准单与提货单；
如果金额小于500元，则不论是否过期都发出批准单和提货单；
在过期的情况下，不论金额大小还需要发出通知单；

案例3：文件修改

输入的第一列字符必须是A/B，第二列字符必须是一个数字；
如果第一列字符不正确，则给出信息L；
如果第二列字符不正确，则给出信息M；
如果两列字符输入正确，则修改文件成功；
如果两列字符都输入错误，则给出信息 L 、 M；

4.因果图法

定义
- 用图解的方法表示输入的各组合关系，写出判定表，进而设计测试用例的一种【黑盒测试】方法；
- 因果图的结果就是判定表，所以一般就直接使用判定表分析法即可；
核心
- 因：条件
- 果：结果
适用范围
- 适用于分析程序输入条件的各种组合情况，以及输入和输出之间的依赖关系。
基本符号
- 恒等（-）：条件成立，结果成立。
- 非（~） NOT ：条件成立，结果不成立；条件不成立，结果成立。
- 或（V） OR ：只要有一个条件成立，结果就成立；所有条件都不成立时，结果才不成立。
- 与/ 且（^） AND ：多个条件必须同时成立，结果成立；只要有一个不成立，结果就不成立。
- 通常在因果图中用Ci表示原因，用Ei表示结果，各节点表示状态，可取值“0”或“1”；
- 0：表示某状态不出现，1：表示某状态出现；

基本步骤
- 1.找出所有的原因，原因即输入条件或输入条件的等价类；
- 2.找出所有的结果，结果即输出结果；
- 3.明确所有输入条件之间的制约关系以及组合关系。哪些条件不能组合到一起，哪些条件可以组合到一起；
- 4.明确所有输出结果之间的制约关系以及组合关系。哪些输出结果不能同时输出，哪些输出结果可以同时输出；
- 5.找出什么样的输入条件组合会产生哪种输出结果（画因果图）；
- 6.把因果图转换为判定表/决策表；
- 7.为判定表/决策表中的每一列表示的情况设计测试用例；
案例
- 案例1：交通一卡通自动充值软件
- 案例2：文件修改

案例1：交通一卡通自动充值软件

第一步：找出所有的输入条件与输出结果

第二步：明确所有的输入条件和所有的输出结果之间的制约关系以及组合关系

第三步：画因果图

第四步：列决策表/判定表

第五步：编写测试用例

案例2：文件修改

输入的第一列字符必须是A/B，第二列字符必须是一个数字；
如果第一列字符不正确，则给出信息L；
如果第二列字符不正确，则给出信息M；
如果两列字符输入正确，则修改文件成功；
如果两列字符都输入错误，则给出信息L、M；

总结：一般不会用到，因为直接使用判定表分析法即可！

5.正交法 *

定义
- 正交法，也叫正交实验法或正交排列法；
- 核心：使用最小的测试过程集合获得最大的测试覆盖率。
正交表
- 一种特制的表，一般的正交表标记为：Ln( $m^{k}$ )
说明
- k：代表因素（输入参数）
- m：表述水平（输入参数的取值）
- n：代表测试用例数
- 读法：k因素 m水平
基于正交表设计测试用例
- 需求分析
- 确定因素k与水平m（因素：控件名称；水平：每个控件对应的取值）
- 确定要采用的正交表
- 将正交表中的字母用文字代替
- 设计测试用例（一行就是一条测试用例）
基于allpairs设计测试用例
- 需求分析
- 确定因素与水平（因素：控件名称；水平：每个控件对应的取值）
- 将确定的因素与水平复制到txt 文件中
- 打开DOS 窗口，进入 allpairs 目录，运行命令： allpairs.exe test.txt > result.txt
- 根据生成的新文件编写测试用例（一行就是一条测试用例）
allpairs 工具的使用
- 1.将数据填到excel表格中
- 2.将表格中的内容（包括表头）粘贴到txt文本中（比如a.txt）
- 3.通过allpairs命令，生成测试用例
  - 打开终端（cmd）
  - 进入 allpairs.exe 的存放路径中
  - 执行 allpairs.exe a.txt > b.txt
案例
- 案例1：字符属性设置程序
- 案例2：用户筛选按钮

案例1：字符属性设置程序

窗体中有多个控件（字体、字符样式、颜色、字号），每个控件有多个取值
字体：仿宋、楷体、华文彩云
字符样式：粗体、斜体、下划线
颜色：红色、绿色、蓝色
字号：20号、30号、40号

问题：共有 3^4=81 种组合，此时不可能一一列举出来

解决方案：使用正交表或 allpairs 工具

第一种：使用正交表

第二种：使用 allpairs 工具

第一步：将数据填到excel表格中

第二步：将表格中的内容（包括表头）粘贴到txt文本中（比如a.txt）

第三步：通过allpairs命令，生成测试用例

第四步：核对结果，生成的 b.txt 内容如下

案例2：用户筛选按钮

假设有一个用户筛选功能，有3个输入分别是体型、年龄段、性别，
体型有3个取值：胖、适中、瘦；
年龄段有3个取值：老人、青年、儿童；
性别有2个取值：男，女；

6.场景法 *

定义
- 通过场景描述的业务流程（业务逻辑），也包括代码的实现逻辑，设计用例来遍历场景（路径），验证软件系统功能的正确性。主要用于冒烟测试。
- 场景法就是模拟用户操作软件时的场景，主要用于测试多个功能之间的组合使用情况。
- 场景法，也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。
意义
- 用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用
- 测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试
使用阶段
- 集成测试
- 系统测试
- 验收测试
使用场景
- 对于多个功能之间的组合逻辑测试，可以使用场景法。
基本步骤
- 1.需求分析
- 2.绘制流程图
  - 矩形：表示步骤，比如操作、输入、输出结果
  - 菱形：表示判断条件
  - 箭头：表示流向
- 3.遍历场景，提取测试用例（一条流程路径就是一条测试用例）
  - 覆盖正常的路径
  - 覆盖分支路径
流程图常用符号