【测试】——测试分类-CSDN博客

📖 前言：在软件开发过程中，测试是确保产品质量和用户体验的关键环节。本篇文章将详细介绍各种测试分类，包括界面测试、可靠性测试、容错性测试等。通过这些测试方法，我们可以有效地发现和解决软件中的潜在问题，从而提升软件的稳定性和用户满意度。

请添加图片描述

🕒 1. 按照测试对象划分

🕘 1.1 界面测试（UI测试）☆

界面测试，指按照界面的需求（一般是 UI 设计稿）和界面的设计规则，对我们软件界面所展示的全部内容进行测试和检查，一般包括如下内容：

验证界面内容显示的完整性，一致性，准确性，友好性。比如界面内容对屏幕大小的自适应，换行，内容是否全部清晰展示；
验证整个界面布局和排版是否合理，不同板块字体的设计，图片的展示是否符合需求（参考标准：UI 设计稿）；
对界面不同控件的测试，比如，对话框，文本框，滚动条，选项按钮等是否可以正常使用，有效和无效的状态是否设计合理；
界面的布局和色调符合当下时事的发展。（例如灾难纪念日时配色为灰色）

常见的页面错误：

重叠，截断，文字不合理自动换行等；
图片展示颜色不符合预期；
文字大小不符合预期；
页面出现错别字

小技巧：Chrome进入开发者工具后可模拟各设备页面尺寸
在这里插入图片描述

🕘 1.2 可靠性测试

概念：可靠性（Availability）即可用性，是指系统正常运行的能力或者程度，一般用正常向用户提供软件服务的时间占总时间的百分比表示。

公式：可靠性 = 正常运行时间/（正常运行时间+非正常运行时间）*100

系统非正常运行的时间可能是由于硬件，软件，网络故障或任何其他因素（如断电）造成的，这些因素能让系统停止工作，或者连接中断不能被访问，或者性能急剧降低导致不能使用软件现有的服务等。

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

如果可用性达到99.99%，对于一个全年不间断（7*24的方式）运行的系统，意味着全年（252600min)不能正常工作的时间只有52min，不到一个小时。
如果可用性达到99.999%，意味着全年不能正常工作的时间只有5min。

不同的应用系统，可用性的要求是不一样的，非实时性的信息系统或一般网站要求都很低，99%和99.5%就可以了；但是军事系统，要求则很高。

🕘 1.3 容错性测试

容错性测试是指系统能够处理异常，用户的错误操作而不至于系统崩溃，从而能够提高系统的可用性。包含以下方面：

输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。比如数据级测试，校验测试，环境容错性测试，界面容错性测试。
灾难恢复性测试：通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。

区分容错性和可靠性：假设有一架配备四引擎的飞机

容错性：四引擎飞机即使一个引擎故障，其他引擎仍能保持飞机飞行的能力。
可靠性：这架飞机的引擎在长时间的飞行和使用过程中几乎不发生故障，显示了其高可靠性。

🕘 1.4 文档测试

计算机软件开发文件编制指南中共有14种文件，分为3大类。
在实际的测试中，最常见的是用户文件的测试，例如：手册说明书等。也会有一些公司对需求文档进行测试，来保证需求文档的质量。

🕘 1.5 兼容性测试☆

兼容性测试需求是指明确要测试的兼容环境，考虑软硬件的兼容，就软件兼容来说，主要考虑以下几个方面：

系统自身版本的兼容，用户已有数据的兼容，数据兼容是重中之重，对用户来说，数据是最有价值的
测试与应用环境的兼容性，比如操作系统，应用平台，浏览器的兼容
测试与第三方系统以及第三方数据的兼容性

对于环境（操作系统，应用平台）兼容性的测试不仅仅局限在操作系统，浏览器这两个因素，还包括以下，32位，64位CPU；手机/平板平台Android，iOS；支持不同的Internet连接速度，考虑不同的型号（屏幕尺寸，分辨率等）

🕘 1.6 易用性测试☆

易用性在ISO25020标准中指容易发现、容易学习和容易使用。易用性包含七个要素：符合标准和规范、直观性、一致性、灵活性、舒适性、正确性和实用性。

🕘 1.7 安装卸载测试

应用的安装和卸载在任何一款APP中都属于最基本功能。一旦出错，就属于优先级最高的缺陷。主要需要考虑以下方面：

软件不同的安装和卸载方式（应用市场、浏览器APK包、ADB命令）；
应用是否可以在不同的操作系统版本下安装（安装兼容性）
安装或者卸载过程中是否可以手动暂停，或者取消
安装空间不足的时候系统是否有提示
是否可以正常的卸载，以及应用软件的各种卸载方式
卸载和安装过程中出现环境问题，软件是否可以正常并且合理的应对，比如死机，断电，断网等

🕘 1.8 安全测试☆

安全性是指信息安全，计算机系统或网络保护用户数据隐私完整，保护数据正常传输和抵御黑客或病毒攻击能力。安全性测试属于非功能性测试很重要的一个方面，系统常见的安全漏洞和威胁如下：

输入域，如输入恶性或者带有病毒的脚本或长字符串；
代码中的安全性问题，如SQL/XML注入
不安全的数据存储或者传递
数据文件，邮件文件，系统配置文件等里面有危害系统的信息或者数据；
有问题的访问控制，权限分配等
假冒ID：身份欺骗
篡改，对数据的恶意修改，破坏数据的完整性

🕘 1.9 性能测试☆

我们在使用软件的时候有时会碰到软件网页打开时越来越慢，查询数据时很长时间才显示列表，软件运行越来越慢等问题，这些问题都是系统的性能问题引起的。
要进行软件产品的性能问题，要对产品的性能需求进行分析，然后基于系统的性能需求和系统架构，完成性能测试的设计和执行，最后要进行持续的性能调优。常见的性能问题如下：

资源泄露
资源瓶颈
线程死锁，线程阻塞
查询速度慢或效率低
受外部系统影响越来越大

衡量一个系统性能好坏的关键性指标有，用户响时间，事务平均响应时间（TPS），吞吐率，每秒点击次数，内存和CPU使用率等。

🕘 1.10 内存泄漏测试

造成内存泄露的原因有很多，最常见的有以下几种：

分配完内存之后忘了回收。
程序写法有问题，造成没办法回收（如死循环造成无法执行到回收步骤）。
某些API函数的使用不正确，造成内存泄露。

工作中内存泄漏检测方法：

人工静态法：人工查找代码未被回收的内存
自动工具法：借助相应测试内存泄露的工具，如Visual Leak Detector，记录每次的内存分配，清楚的告诉用户内存是如何泄露的

🕘 1.11 弱网测试

安卓手机如果一直刷不到内容，可能会出现无响应弹窗，如果有时网不太好，可能会造成客户端频繁地去发送请求，造成服务器压力过大

【面试题】如何实施弱网测试？
1）网络环境：wifi、5G、4G、3G、2G
2）此时就需要借助fiddler进行环境的模拟：
① 打开弱网设置：打开fiddler -> Rules -> Performance -> Simulate Modern Speeds

在这里插入图片描述

② 打开设置弱网的脚本：打开fiddler -> Rules -> Customize Rules… -> 找到弱网设置的代码

在这里插入图片描述
注：数值的单位是传输1KB需要多少ms，也就是ms/KB

3）如何计算2G和3G的上下行速率？

🔎 2G、3G、4G网络制式上下行频率、速率比较

注：B是指Byte字节，b是指bit比特；则：1B=8b
运行商的x kb/s我们需要转换成KB/ms，也就是1/x/8*1000)KB/ms。

如果计算太麻烦，直接搜即可：【关键词：弱网模拟2G和3G】

🕒 2. 按是否查看代码划分

🕘 2.1 黑盒测试

黑盒测试即纯功能测试：不关心代码内部具体怎么实现，只关心产品最后是否符合产品需求说明书的要求。一般用在系统测试阶段。黑盒测试又称之为数据驱动测试，只注重软件的功能。

黑盒测试的优点：

不需要了解程序内部的代码以及实现，不关注软件内部的实现；
从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维；
测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。

黑盒测试的缺点：

不可能覆盖所有的代码。
黑盒测试用到的测试方法有：等价类，边界值，因果图，场景法，错误猜测法等。

🕘 2.2 白盒测试

白盒测试又称为结构测试或逻辑测试，它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试。关注程序内部的实现，保证代码的逻辑以及状态符合预期。一般用在单元测试阶段。

优点：代码覆盖率比较高。

缺点：由于白盒测试只是针对某个单元进行测试，当每个单元测试无误时，并不能保证整合在一起的最终业务也测试无误，即白盒测试业务功能覆盖不高。

主要包含六种测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

🕘 2.3 灰盒测试

灰盒测试，介于黑盒和白盒之间的测试，多用于集成测试阶段（开发），不仅关注输出、输入的正确性，同时也关注程序内部的情况。

Q：为什么不让灰盒测试直接取代黑盒测试和白盒测试？

A：灰盒测试没有白盒测试那么详尽。没有黑盒测试覆盖产品的广度大，所以黑盒测试不能取代黑白盒。

【面试题】常见的测试方法有哪些？哪种测试方法用的多？
1）黑盒测试、白盒测试、灰盒测试
2）黑盒测试和白盒测试测试人员都会使用到，在工作中根据具体情况来结合黑盒测试和白盒测试。通常情况下，测试人员使用黑盒测试会相对多一些。

🕒 3. 按照开发阶段划分

单元测试：对程序的“最小单元”进行测试。
集成测试：集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。
系统测试：开发人员为整个系统的功能等进行测试
回归测试：
- 对历史版本、历史功能进行测试，保证功能都是符合要求的。
- 借助自动化来进行回归测试：自动化也是测试人员写的，自动化的测试是有局限性的，只是协助测试人员进行测试的一个工具。

【注意：自动化是不会取代人工测试的】

验收测试：甲方或用户进行验收测试
冒烟测试：开发人员完成开发任务后交给测试人员进行测试的第一步。评估软件/系统是否具备可测试的条件。（一般是在系统测试之前的）

需求 → 设计测试用例（包含冒烟测试用例） → 测试用例评审 → 开发提测（开始测试） → 执行测试（执行冒烟测试） → 正式测试 → …

测试类型	测试阶段	测试对象	测试人员	测试依据	测试方法	测试内容
单元测试	编码后或编码前（TDD）	最小模块（在C语言中是函数）	白盒测试工程师或开发工程师	代码和注释+详细设计文档	白盒测试	模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
集成测试	一般单元测试之后	模块间的接口	白盒测试工程师或开发工程师	单元测试的模块+概要设计文档	黑盒测试与白盒测试结合	模块之间数据传输、功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
冒烟测试	开发人员开发完成后	新编译的软件版本	测试人员	-	-	确认软件主要功能和核心流程正常，不阻碍后续测试。如果冒烟测试通过，则进行系统测试；否则，要求开发修复代码。
系统测试	集成测试通过之后	整个系统（软、硬件）	黑盒测试工程师	需求规格说明文档	黑盒测试	功能、界面、可靠性、易用性、性能、兼容性、安全性等
回归测试	开发的各个阶段	旧代码及其变更	测试人员	-	自动化测试与人工测试	确认代码修改没有引入新错误或导致其他代码错误。自动化测试协助但不能完全取代人工测试
验收测试	系统测试通过之后	整个系统（包括软硬件）	最终用户或需求方	用户需求、验收标准	黑盒测试	确保软件符合项目合同和验收依据文档的要求，满足原始需求。测试内容与系统测试类似。

🕒 4. 按照实施组织划分

🕘 4.1 α测试

α 测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。
α测试的目的是评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）。
大型通用软件，在正式发布前，通常需要执行 Alpha 和 Beta 测试。 α 测试不能由程序员或测试员完成。