软件测试相关内容第四弹-测试用例与测试分类
软件测试相关内容第四弹 – 测试用例与测试分类
写在前：我们已经掌握了关于软件测试的相关内容，知道了基本的测试过程，在做了一段时间的基础测试，熟悉了相关的业务后，测试人员会进行测试用例的编写，在日常测试中，也需要补充测试用例到现有的案例库中。本篇文章将会重点梳理关于测试用例和测试分类相关知识。
在用例部分将会介绍： 测试用例的基本要素 与 测试用例的设计方法 。
在测试分类部分将会根据 测试对象 、 是否查看代码 、 开发阶段、实施组织计划 、 是否运行代码 、 是否手工 、 地域 等不同维度介绍不同的测试方法。
目录
1. 测试用例
1.1 测试用例的基本要素
测试用例在之前的文章中有过详细的介绍，这里将不再赘述，重点需要掌握关于测试用例的4个重要要素： 测试环境、操作步骤、测试数据、预期结果 。
1.2 测试用例的好处
（1）提高测试效率，节省测试时间
（2）测试用例是自动化测试用例的前提
1.3 测试用例的设计方法
1.3.1 基于需求的设计方法
需求文档 - 梳理需求（掌握要求）- 针对文档设计测试用例（基于需求设计测试用例）
基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就是要分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计。
分为功能测试和非功能测试。
1.3.1.1 功能需求测试分析
对于功能测试中，可以借助功能框架图来帮助我们进行测试的需求分析，一般包括以下几个方面：
（1）系统各个功能 界面 的验证
（2）借助业务把功能串起来进行测试
（3）功能的一致性，交互性(多功能互操作)的测试。
（4）系统的不同输入，结果输出的业务数据测试。
（5）功能的错误操作，异常操作的测试(属于负面测试)。
（6）功能实现用到的算法验证，有时需要用到代码评审。
（7）用户操作的 易用性 、用户体验，往往结合功能测试同时验证。
1.3.1.2 非功能需求测试分析
非功能测试需求主要涉及性能、安全性、可靠性、兼容性、易维护性和可移植性等，从需求分析来看，每一类非功能特性测试都需要根据需求单独分析，他们之间可能会存在相互影响，如安全性越高，就越有可能给易用性能带来更大的挑战。
1.3.1.3 案例：
163邮箱注册为原型，完成基于需求设计的测试用例
1.3.2 具体的设计方法
1.3.2.1 等价类
依据需求将输入(特殊情况下会考虑输出)划分为若干个等价类，从等价类中选出一个测试用例。如果这一个测试用例通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
（1）有效等价类
对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明书中所规定的功能和性能。
（2）无效等价类
根据需求说明书，不满足需求的集合。
等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。
（3）设计测试用例步骤：
a. 充分理解需求。
b. 划分有效等价类和无效等价类。
c. 从有效等价类抽取其中一个数据进行测试用例。从无效等价类中抽取一个进行测试用例。
（4）案例
1.3.2.2 边界值
（1）概念
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
| 上点 | 边界上的点 |
| 内点 | 边界内的点 |
| 离点 | 边界值附近的一个点（闭区间区间外距离上点最近的点，开区间区间内距离上点最近的点） |
（2）设计测试用例步骤
a. 充分理解需求
b. 找边界点
c. 针对边界点设计测试用例
（3）案例
1.3.2.3 判定表
（1）概念
判定表是另一种表达 逻辑判断 的工具，关系（与、或、非、恒等）
（2）设计测试用例步骤
a. 分析所有可能的输入和可能的输出
b. 找出输入与输出之间的对应关系
c. 设计判定表
d. 把判定表对应到每一个测试用例
（3）案例
业务单据处理规则为：购物场景、订单已提交、订单合计金额大于300元或有红包，则优惠。
分析：输入 - 订单已提交，订单金额大于300、有红包。
输出 - 优惠、不优惠。
1.3.2.4 正交表
（1）概念
因素： 变量。
水平： 变量的取值。
性质： a. 每一列中各个数字出现的次数一样多。b. 任何两列中的各有序数对出现的次数一样多。
（2）设计测试用例步骤
a. 充分理解需求
b. 确定因素水平
c. 画正交表
d. 补充正交表
e. 将正交表转换成测试用例
（3）案例
针对用户名注册完成测试：姓名、邮箱、密码、确认密码、验证码必须全部输入才能注册。
因素：姓名、邮箱、密码、确认密码、验证码。
水平：填写、不填写。
画正交表工具：allpairs的使用
a. 新建一张excel表，将对应的因素和水平填写到里面。
b. 新建记事本，并粘贴到记事本中
c. 将记事本中的内容另存为到allpairs下载目录下
d. 打开cmd控制台，找到文件所在位置
e. 执行对应的命令，生成正交表并重新对其进行命名
f. 查看形成的正交表
对正交表进行补充
最后将上述正交表转换成文字（对应的测试点，即可完成正交表的测试用例）。
1.3.2.5 场景设计
现在的软件几乎都是用事件来触发控制流的，事件触发时的情景形成场景，而同一事件不同的触发顺序和结果处理就形成事件流，该方法可以比较生动的描绘出事件触发时的场景，有利于测试者商业及测试用例。
典型应用是 用业务把各个孤立的功能点串起来 ，未测试人员简历整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。
1.3.2.6 错误猜测法
通过测试人员经验来进行测试。
2. 关于测试用例常见面试题梳理
2.1 面试题：如何模拟弱网
可以借助许多工具来模拟弱网，比如使用软件Fiddler软件打开限速模式来进行弱网模拟。
还可以找到对于上传和下载数据花费的时间
2.2 面试题：接口如何测试
借助工具Postman，针对接口测参数进行测试(传参数，不传参数，传入非法参数)
参数通过parameter,json传递
2.3 测试用例设万公式
功能+界面+易用+兼容+性能+安全+网络+中断
测试模块 物体 软件 功能 主要是用来做什么的 软件实现的功能 界面 外表、材质、大小、容量 界面字体大小、字体颜色、字体布局 易用 经验（操作简单、使用流畅） 人性化 兼容 物体除了本质功能外，还有没有其他功能 操作系统、设备、浏览器版本 性能 使用寿命 响应时间、吞吐量、并发数 安全 物体材质是否有毒 ，物体会不会对人体健康造成威胁 sql注入、xss漏洞、输入有毒的脚本 网络 2G-5G、弱网、Wifi — 中断 网络断开 —
2.4 面试题：水杯测试用例
2.5 面试题：微信发送朋友圈测试用例
这两道面试题就从”万能公式“里面套入即可，后面有时间的话我会将测试用例完整补齐。
3. 测试分类
3.1 按照测试对象划分
测试对象 ： 界面测试 、 可靠性测试、容错性测试、文档测试 、 兼容性测试 、 易用性测试 、 安装卸载测试 、 安全性测试 、 性能测试 、 内存泄漏测试 。
3.1.1 界面测试
简称 UI测试 ，用户和软件进行交互的时候，通常都是通过界面和软件沟通的，业界进行测试的时候，参考软件规格说明书，UI视觉稿，一般包括如下内容：
验证界面内容是否显示完整 ，一致性、准确性、友好性。界面内容对屏幕大小的自适应，换行，内容是否全部清晰展示；
验证整个界面布局和排版是否合理 ，不同板块字体设计，图片的展示是否符合需求；
对界面不同控件的测试，对话框、文本框、滚动条、选项按钮等是否可以正常使用，有效和无效状态是否设计合理；
界面的布局 和 调色 是否符合当下时事的发展。
3.1.2 可靠性测试
即 可用性 ，指系统正常运行的能力或者程度，一般用正常向用户提供软件服务的时间占总时间的百分比表示。
可靠性 = 正常运行时间 / (正常运行时间 + 非正常运行时间) * 100%
系统的非正常运行时间可能是由于硬件、软件、网络故障或者任何其他因素(如断电)造成的，这些因素都能让系统停止工作，或者连接中断不能被访问，或者性能急剧降低导致不能使用短剑现有的服务等。
可用性指标一般要求达到4个或5个9，99.99%，或者99.999%。
四个9表示全年不能工作的时间只有52min，不到一小时。
五个9表示全年不能工作的时间只有5min。
3.1.3 容错性测试
指 系统能够正常处理异常，用户的错误操作不至于使系统崩溃，从而提高系统的可用性 。 包含两方面：
（1） 输入异常数据 进行异常操作，以检验系统的保护性，如果系统的容错性好，系统只给出提示或者内部消化掉，而不会导致系统出错甚至崩溃。比如数据级测试、校验测试、环境容错测试、界面容错测试。
（2） 灾难恢复性测试 。通过各种手段让软件强制的发生故障，然后验证系统已经保存的用户数据是否丢失，系统和数据能否尽快恢复。【如果服务出现问题–重启大法】
3.1.4 文档测试
国家有关计算机软件产品开发文件编制指南中共有14种文件，可以分成3大类。
开发文件 – 可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
用户文件 – 用户手册、操作手册。用户文档作用：改善易安装性；改善软件易学性和易用性；改善软件可靠性；降低技术支持成本。
管理文件 – 项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
【测试文件、开发文件、产品文件】
文档测试关注点：术语、正确性、完整性、一致性、易用性。
3.1.5 兼容性测试
明确要测试的兼容环境，考虑软件、硬件兼容。
软件兼容： 系统自身的版本兼容 ，用户已有数据的兼容，数据兼容是对用户来说最有价值的； 测试与应用环境的兼容性： 操作系统、应用平台、浏览器兼容； 测试与第三方系统、数据的兼容性 。
对于环境（操作系统、应用平台）兼容性的测试不仅仅局限在操作系统、浏览器这两个因素，还需要包括：32位、64位CPU，手机平台Android、iOS、Windows、Phone；支持不同的Internet连接速度。
对于iOS和Android两个平台，还需要区分手机端和平板电脑。考虑不同的型号(屏幕尺寸和分辨率等)。
3.1.6 易用性测试
许多产品应用人体工程学的研究成果，使得产品在使用时更加灵活舒适，软件产品也始终关注用户体验。针对软件这方面的测试称为易用性测试。
主要包括七个要素：符合标准和规范、直观性、一致性、灵活性、舒适性、正确性和实用性。这里重点介绍其中四个。
（1）标准性和非规范性
对于现有的软件运行平台，UI标准不知不觉被确立并成为共识，多数用户已经认同这些信息所代表的含义，比如安装软件的界面外观，在何场合使用恰当的对话框等。所以用户界面的各种信息应该符合规范和习惯，测试人员需要把与标准规范和习惯不一致的问题报告为缺陷。
（2）直观性
要求软件功能特性易懂，清晰。用户界面布局合理，对操作的响应在用户在预期之中。比如统计数据结果用条形图或者扇形图等报表更清晰的展示。现在主流的很多引擎和日历设计也有直观性的特点。
（3）灵活性
软件可以有不同的选项以满足使用习惯不同的用户，但是需要注意灵活性的把握，不增加软件设计的复杂和程序实现的难度。例如：手机键盘的九宫格和全键盘，还支持手写和转文字等功能。
（4）舒适性
强调界面友好、美观、操作过程流畅。色彩运用恰当，按钮立体等。例如左手鼠标的设计。
3.1.7 安装卸载测试
应用的安装和卸载在任何一款APP种都属于最基本的功能。，一旦出错就属于Critical缺陷，需要紧急处理 ，需要考虑以下方面：
- 软件不同的安装和卸载方式；
- 是否可以在不同的系统版本下安装（兼容性）；
- 安装或者卸载是否可以手动暂停或者取消；
- 安装空间不足有无提示；
- 是否可以正常卸载以及不同卸载方式；
- 卸载和安装过程中出现环境问题，软件是否可以正常合理的应对（死机、断电、断网）
3.1.8 安全测试
安全性是指 信息安全 ，计算机系统或网络保护用户数据隐私、完整、保护数据正常传输和抵御黑客、病毒攻击的能力。 安全性测试属于非功能测试很重要的一个方面，系统常见的安全漏洞和威胁如下：
- 输入域，如输入恶性或者带有病毒的脚本或长字符串；
- 代码中的安全问题，如SQL/XML注入；
- 不安全的数据存储或传递；
- 数据文件、邮件文件、系统配置文件等里面有危害系统的信息或者数据；
- 有问题的访问控制、权限分配等；
- 假冒ID：身份欺骗；
- 篡改，对数据的恶意篡改，破坏数据的完整性
3.1.9 性能测试
我们在使用软件的时候有时会碰到软件网页打开时越来越慢，查询数据很长时间才能显示列表，软件运行越来越慢等问题，这些问题都是系统的性能问题引起的，要进行软件产品的性能问题测试，要对产品的新跟那个需求进行分析，然后基于系统的性能需求和系统架构完成性能测试的设计和执行，最后进行持续性的性能调优，常见的性能问题：
- 资源泄露（内存泄漏）
- 资源瓶颈（带宽）
- 线程死锁，线程阻塞（卡死）
- 查询速度慢或效率低
- 受外部系统的影响越来越大
衡量一个系统性能好坏的关键性指标有： 用户响应时间、事务平均响应时间(TPS)、吞吐率、每秒点击次数、内存和CPU使用率 等。
3.1.10 内存泄漏测试
从用户角度看，内存泄漏 本身不会造成什么危害，但是内存泄漏是会累计的，只要执行的次数足够多，最终会耗尽所有可用的内存，使软件执行的越来越慢，最后停止响应 ，可以把这种问题比作软件的“慢性病”。造成的原因：
- 分配完内存之后忘记回收
- 程序写法有问题，造成无法回收（如死循环）
- 某些API函数的使用不正确
检测方法：
- 人工静态法：代码走读，人工查找
- 自动工具法：借助相应的测试内存泄露的工具
3.2 按照是否查看代码划分
3.2.1 黑盒测试
黑盒测试就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用，是否能适当的接收输入数据而输出正确的结果，满足规范需求。
黑盒测又称数 据驱动测试 ，只注重软件的功能。
常见的黑盒测试用例方法 ：【在第一部分测试用例中介绍了黑盒测试用例的测试方法 – 等价类、边界值、判定表、正交表、场景设计、错误猜测】
黑盒测试的优点
- 不需要了解程序内部的代码及实现，不关注软件内部的实现【技术要求不高、产品思维高、发散高】
- 从用户角度出发设计测试用例，很容易知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维
- 测试用例是基于软件需求的开发文档，不容易遗漏软件需求文档中需要测试的功能
缺点
- 代码覆盖率低
3.2.2 白盒测试
白盒测试又称 结构测试或逻辑测试 ，一般用来分析程序的内部结构， 针对程序的逻辑结构 来设计测试用例进行测试 【关注代码的逻辑，对业务能力有一定的忽视】。 白盒测试的测试目的是，通过
检查软件内部的逻辑结构
，
对软件中的逻辑路径进行覆盖测试
，在程序不同地方设立检查点，检查程序状态，以确定实际运行状态与预期状态是否一致。
主要包含六种测试方法
： 语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
优点：
- 代码覆盖率高
缺点：
- 功能覆盖率低
3.2.3 灰盒测试
介于白盒测试和黑盒测试之间的一种测试，多用于集成测试阶段， 不仅关注输出、输入的正确性，同时也关注程序内部的情况 。
3.3 按照开发阶段划分
3.3.1 测试金字塔
3.3.2 单元测试
单元测试是对 软件组成单元进行测试 。其目的是 检验软件基本组成单元的正确性 ，测试对象是软件设计的最小单位：模块，又称模块测试，
- 测试阶段：编码后或者编码前（TDD）
- 测试对象：最小模块【Java - 类/ 方法 C - 函数】
- 测试人员：白盒测试工程师或开发工程师
- 测试依据：代码注释 + 详细设计文档
- 测试方法：白盒测试
- 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
Java通过Junit和TestNG进行单元测试。
3.3.3 集成测试
集成测试也称联合测试（联调）、组装测试。将程序模块采用适当的集成策略组装起来，对系统的 接口 及集成后的功能进行正确性检验的测试工作，集成主要目的是 检查软件单位之间的接口是否正确 。
- 测试阶段：一般在单元测试之后进行
- 测试对象：模块间的接口
- 测试人员：白盒测试工程师或开发工程师
- 测试依据：单元测试的模块 + 概要设计文档
- 测试方法：黑盒白盒测试相结合
- 测试内容：模块之间的数据传输、模块之间的功能冲突、模块组装功能的正确性、全局数据结构、单模块缺陷对系统的影响
3.3.4 系统测试
将软件系统看成一个系统测试。包括对 功能、性能以及软件所运行的软硬件环境进行测试 。
- 测试阶段：集成测试通过之后
- 测试对象：整个系统（软硬件）
- 测试人员：黑盒测试工程师
- 测试依据：需求规格说明文档
- 测试方法：黑盒测试
- 测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
3.3.5 回归测试
修改了旧代码后，重新进行测试以确定修改没有引入新的错误或导致其他代码产生错误。在整个软件测试过程中占比大，各个阶段都会进行多次回归测试，成本大， 需要选择正确的回归测试策略 改进效率和有效性。
3.3.6 冒烟测试
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是 确认软件主要功能和核心流程的正常 ， 测试点属于本次测试的主流程 ，一般发生在开发人员开发完毕提交给测试人员来进行测试时，先进性冒烟测试，保证基本功能正常，不阻碍后续测试。通过则进入正式系统测试，不通过则打回修改，直到通过再进行正式测试。
3.3.7 验收测试
部署软件之前的最后一个测试操作产品上线的最后一个流程 ，又称交付测试。
- 测试阶段：系统测试通过后
- 测试对象：整个系统（包括软硬件）
- 测试人员：主要是最终用户或者需求方
- 测试依据：用户需求、验收标准
- 测试方法：黑盒测试
- 测试内容：同系统测试【功能、界面、可靠性、易用性、性能、兼容性、安全性等】
3.4 按照实施组织划分
3.4.1 α测试
由一个用户再开发环境下进行的测试，也可以是公司内部的用户再模拟实际操作环境下进行的测试。大型通用的软件在正式发布之前通常要执行α测试和β测试，α测试不能由程序员或测试员完成。
3.4.2 β测试
是一种验收测试，由软件的最终用户们再一个或多个场所进行。
3.4.3 α测试、β测试区别
α测试和β测试的区别
| α测试 | β测试 | |
| 环境 | 公司内部 | 不确定 |
| 测试人员类型 | 公司内部人员 | 用户 |
| 测试人员数量 | 较少 | 较多 |
| 阶段 | 内测（ β测试之前 ） | |
| 测试周期 | 较短 | 较长 |
3.4.4 第三方测试
介于开发方和用户方间的组织的测试
3.5 按照是否运行代码划分
3.5.1 静态测试
不实际运行 被测软件，只是 静态检查程序代码 、 界面或文档 中可能存在的错误的过程，不以测试数据的执行而 对测试对象的分析过程， 仅通过分析或检查源程序的设计、内部结构、逻辑、代码风格等来检查程序的正确性。
3.5.2 动态测试
实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相等的过程。
判断一个cesium属于动态测试还是静态测试，唯一标准就是看是否运行程序。
3.6 按照是否手工划分
3.6.1 手工测试
由人去一个一个输入用例，然后观察结果，与机器测试相对应，属于比较原始但必须的一个步骤。
- 优点：自动化无法替代探索性测试、发散思维结果的测试
- 缺点：执行效率慢，量大易错。
3.6.2 自动化测试
在 预设的条件 下运行系统或应用程序，评估运行结果， 预先条件应包括正常条件和异常条件。 就是把以人为驱动的测试行为转化成机器执行的一种过程。
自动加测试比如：功能测试自动化、性能测试自动化、安全测试自动化。
按照测试对象分：接口测试、UI测试。
自动化测试实现步骤：
- 完成测试功能，版本基本稳定
- 根据项目特性选择适合项目的自动化工具，搭建环境
- 提取手工测试的测试用例转换为自动化测试用例
- 通过工具、代码实现自动化的构造输入，自动化检测出结果是否符合预期
- 生成自动化测试报告
- 持续改进，优化脚本
3.7 按照地域划分
分为国际化测试和本地化测试。
终于！写完啦哈哈哈，这部分的内容就介绍到这里啦，接下来将对测试框架Selenium进行介绍~