Hello , 大家好 , 又给大家带来新的专栏喽 ~
这个专栏是专门为零基础小白从 0 到 1 了解软件测试基础理论设计的 , 虽然还不足以让你成为软件测试行业的佼佼者 , 但是可以让你了解一下软件测试行业的相关知识 , 具有一定的竞争实力 .
那也欢迎大家订阅此专栏 : https://blog.csdn.net/m0_53117341/category_12427509.html
希望大家都能够拿到好的 Offer

那在最开始 , 我们先把这篇文章的大体脉络以思维导图的形式展现出来

测试分类.xmind

一 . 按照测试对象划分

1.1 文档测试

实际工作中 , 也很少进行文档测试 , 最主要的一个原因就是 : 人们想的往往跟写出来的南辕北辙 , 产品经理表达的意思是他要餐巾纸 , 你听成了三斤屎 , 每个人理解问题的角度和表述能力是不一样的 , 所以通过文档测试的方式不适合于日常开发

1.2 可靠性测试

可靠性（Availability）即可用性 , 是指系统正常运行的能力或者程度 , 一般用正常向用户提供软件服务的时间占总时间的百分比表示 , 实际表达的意思就是程序正常使用多长时间

可靠性 = 正常运行时间 / (正常运行时间 + 非正常运行时间 ) * 100%
= 正常运行时间 / 总时间 * 100%

举个例子 :

可用性指标一般要求达到 4 个或 5 个 “9” , 即 99.99% 或者 99.999% , 最高可达到 100%

如果想要达成 4 个 9 (99.99%) 以及 5 个 9 (99.999%) , 对于全年无休的系统来说 , 不可用的时间是多少呢 ?

1.3 容错性测试

容错性测试是指系统能够处理异常 , 用户的错误操作而不至于系统崩溃 , 从而能够提高系统的可用性

容错性测试与可靠性测试非常相似 , 但是并不相同 , 容错性指的是出问题了还能不能用 , 可靠性指的是程序出不出问题

举个栗子 :
有一架飞机 , 他有四个引擎 , 假如说有一个引擎坏掉了 , 但是飞机还能正常运行
那么这架飞机他的容错性非常好 , 有一个引擎坏掉了 , 这就是不可靠性的体现

1.4 安装卸载测试

应用的安装和卸载在任何一款 APP 中都属于最基本功能 , 一旦出错 , 就属于优先级为紧要 Critical 的缺陷

在工作中 , 很容易就遗忘了安装卸载测试

1.5 内存泄漏测试

有一些语言会自动帮我们进行内存释放 , 但是有一些语言 , 动态开辟的内存要程序员手动释放的 , 比如 C 语言 .

那么程序员也不是神 , 我们很容易就会造成内存泄漏 .

在工作中 , 会有两种方法测试 :

1. 人工肉眼观察 : 费力不讨好 , 先大概看一眼有没有明显问题
2. 借助工具对代码进行扫描 : Visual Leak Detector / sonar , 记录每次内存分配 , 清楚告诉用户内存是如何泄漏的

1.6 弱网测试

智能手机在网络不好的情况下 , 一直获取不到内容的时候 , 基本都会给予弹窗提醒 ( ANR 弹窗 )

某一时间段内 , 如果网络状况不太好 , 客户端就会对服务器频繁地发送请求 , 造成服务器有一定的压力

我们可以模拟 WIFI 环境、5G、4G、3G、2G 环境等等 , 针对这些环境分别测试我们的产品能否在这些环境正常运行

我们可以去看后台数据 , 哪种网络环境使用人数多 , 优先测试哪种网络环境

我们可以通过 Fiddler 工具进行弱网环境模拟

工作中还有可能使用 Charles , 会更方便一点

1、打开弱网设置选项

2、打开弱网设置的脚本 , 找到以下位置

这里的 300 150 代表传输 1 KB 需要多少 ms
我们通过设置上行速率和下行速率来模拟不同的网络环境
那么怎么知道上行速率和下行速率我们该设置多少呢 ?
百度即可

参考链接

二 . 按是否查看代码划分

2.1 黑盒测试

黑盒测试是纯功能测试 , 不关心产品是怎样实现的 (不看代码)
一般在执行系统测试阶段 , 会进行黑盒测试的方法

2.2 白盒测试

白盒测试就需要关注程序的具体实现了 (看代码) , 他一般是在单元测试阶段使用的方法

2.3 灰盒测试

灰盒测试是介于黑盒测试和白盒测试之间的测试方法 , 灰盒测试多用于集成测试阶段 , 不仅关注输出、输入的正确性 , 同时也关注程序内部的情况 . 灰盒测试没有黑盒测试用例覆盖面积大 , 又没有白盒测试对于代码的分析那么详尽

面试题 : 哪种测试方法用的多 ?

黑盒测试和白盒测试测试人员都会用的到 , 在工作中根据具体情况来结合黑盒测试和白盒测试
通常情况下 , 黑盒测试对于测试人员会用的多一点

三 . 按照开发阶段划分

3.1 单元测试

单元测试是对程序的 “最小单元” 测试

基本情况下 , 就是对我们程序中每一个小功能进行测试

3.2 集成测试

集成测试也称联合测试 , 把程序中不同的模块采用适当的方法组装起来 , 对系统的接口以及集成后的功能进行测试

3.3 冒烟测试

开发人员完成开发任务后 , 交给测试人员测试的第一步 , 评估 软件 / 系统 是否具有测试的条件

冒烟测试成功 -> 进行系统测试
冒烟测试失败 -> 打回开发重做

3.4 系统测试

将软件系统看成是一个系统的测试 , 包括对功能、性能以及软件所运行的软硬件环境进行测试

系统测试就是测试人员详细测试的阶段

3.5 回归测试

回归测试一般是系统测试中的一环 , 他是对历史版本、历史功能进行测试 , 保证功能都是符合要求的

可以借助自动化来进行回归测试

📌 不用人工测试 , 完全使用自动化测试可以吗 ?
🈲 不可以 !
📌 自动化测试可以替代人工测试吗 ?
🈲 不可以 ! 现在不行 , 将来也不行

自动化测试也是测试人员去写的 , 自动化测试是有局限性的 , 而且只是辅助测试人员进行测试的一个工具

3.6 验收测试

验收测试是部署软件之前的最后一个测试操作 . 它是技术测试的最后一个阶段 , 也称为交付测试 . 验收测试的目的是确保软件准备就绪 , 按照项目合同、任务书、双方约定的验收依据文档 , 向软件购买方展示该软件系统满足原始需求

四 . 按照测试实施组织划分

α 测试和 β 测试的区别

1. 环境 : α 测试是在公司内部进行测试 , β 测试环境是不确定的
2. 测试人员类型 : α 测试是公司内部人员 , β 测试人员是用户
3. 测试人员数量 : α 测试测试人员数量较少 , β 测试人员较多
4. 阶段 : α 测试是在 β 测试之前测试的
5. 测试时间 : α 测试周期较短 , β 测试周期较长

我们通过一个例子来理解
百度官网测试 :
环境 : α 测试是在百度公司进行 , β 测试是让一些用户先进行测试
测试人员 : α 测试人员是整个百度员工 , β 测试是每天一般抽出来 500 个用户
阶段 : 百度员工测试结束之后再让用户进行测试
周期 : 百度员工测试了 1 周时间 , 用户们持续了一个月

五 . 按照是否运行划分

静态测试 : 比如 : code review , 就光看看代码有没有问题

动态测试 : 把代码运行起来看看有没有问题

六 . 按照手工进行划分

一般分为手工测试和自动化测试

七 . 按照地域进行划分

国际化测试 : 测试在不同的国家使用问题 , 可以考虑一些其他的用例 : 时间、语言、日期、货币等

本地测试 : 就是在本地进行测试