前言👀~
上一章我们介绍了如何设计一个测试用例，接下来我们对测试类型进行分类以便更好的了解和分清不同测试测试的内容、对象、时间点等
如果各位对文章的内容感兴趣的话，请点点小赞，关注一手不迷路，讲解的内容我会搭配我的理解用我自己的话去解释如果有什么问题的话，欢迎各位评论纠正 🤞🤞🤞
个人主页：N_0050-CSDN博客
相关专栏：java SE_N_0050的博客-CSDN博客 java数据结构_N_0050的博客-CSDN博客 java EE_N_0050的博客-CSDN博客
按照测试对象划分
界面测试（也称UI测试）
什么是界面？用户肉眼直观看到的都属于是界面，软件只是一种工具，软件与人的信息交流是通过界面来进行的，界面是软件与用户交流的最直接的一层，界面的设计决定了用户对我们设计的软件的第一印象
对软件界面进行测试包含的以下内容：
1.验证界面内容显示的完整性，一致性，准确性，友好性
2.验证整个界面布局和排版是否合理，不同板块字体的设计，图片的展示是否符合需求
3.对界面不同控件的测试，比如，对话框，文本框，滚动条，选项按钮等是否可以正常使用
4.界面的布局和色调符合当下时事的发展
可靠性测试
可靠性即可用性，是指系统正常运行的能力或者程度
可靠性 = 正常运行时间/（正常运行时间+非正常运行时间）*100%，比例越高说明软件可靠性越高。可用性指标一般要求达到4个或5个“9”，即99.99%或者99.999%，前者就可以想象一个系统一年之间不正常运行时间为1个小时差不多，后者则为5分钟差不多
系统非正常运行的时间可能是由于硬件，软件，网络故障或任何其他因素（如断电）造成的，这些因素能让系统停止工作，或者连接中断不能被访问，或者性能急剧降低导致不能使用软件现有的服务等
例子：就好比一个人的可靠性，你托一个人给你处理某个事，它去给你处理，处理花费的时间以及反馈可以看出它的可靠性，如果一个很简单的事情给你搞上一个月那说明这人不是很可靠，可靠性低
容错性测试
容错性测试是指系统能够处理异常，用户的错误操作而不至于系统崩溃，从而能够提高系统的可用性，就是指系统处理异常的能力，在出现异常的情况下不会导致整个软件到不能使用或者严重影响使用的一个情况
对软件进行容错性测试包含的以下内容：
1.在用户输入异常数据或执行异常操作的时候，检验系统的保护性，来分析系统的容错性。如果容错性好就会显示提示信息或内部自动进行解决，不会导致系统出错或出现崩溃。
2.通过各种手段方法测试，让软件强制出现故障，看看系统的反应如何以及如何进行处理的，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复
还有界面容错性测试，就是我们处于的这个界面网址后加上一些七七八八的数字或符号啥的看看这个界面什么反应，如果是回到主页面或者不受影响就说明界面容错性好
文档测试
在实际的测试中，最常见的是用户文件的测试，例如：手册说明书等。也会有一些公司对需求文档进行测试，来保证需求文档的质量。在需求评审的时候测试人员需要进行需求分析（文档测试）
文档测试的三大类：开发文件、用户文件、管理文件
去公司接触最多的文件有测试文件（总结了很多测试的技巧和方法）、开发文件、产品文件
文档测试的关注点：文档的术语、文档的正确性、文档的完整性、文档的一致性、文档的易用性
兼容性测试
需要考虑用户使用的系统是否和我们的软件兼容，兼容性测试需求是指明确要测试的兼容环境，考虑软，硬件的兼容
就软件兼容来说，主要考虑以下几个方面：
1.测试与应用环境的兼容性，比如操作系统，应用平台，浏览器的兼容，以及还要针对移动端或PC端再进行考虑
2.测试与第三方系统以及第三方数据的兼容性，就比如运行一个A软件又运行一个B软件和A属于同一种类型或不同，此时B不能正常运行
易用性测试
关注用户体验，让用户获得舒适，易用的体验，针对软件这方面的测试称之为易用性测试。软件具备简单易上手、直观、舒适等属性
安装卸载测试
应用的安装和卸载在任何一款APP中都属于最基本功能，一旦出错，就属于优先级为严重Critical的缺陷
主要需要考虑以下方面：
1.安装软件和卸载软件的方式，例如系统自带的软件商城、第三方的软件商城、浏览器、命令
2.软件在不同系统下是否能进行安装（安装兼容性），以及考虑空间不足的时候会有怎样的反应呢
3.安装或卸载过程中环境出现问题，例如出现死机、关机、断网会有怎么样的反应以及如何进行处理的
安全测试
安全性是指信息安全，是指计算机系统或网络保护用户数据隐私，完整，保护数据正常传输和抵御黑客，病毒攻击的能力。安全性测试属于非功能性测试很重要的一个方面，系统常见的安全漏洞和威胁如下
性能测试
就是在使用一款软件的时候这个软件的响应时间给用户带来的体验是如何的，例如查询一条信息的时候响应时间过久就反应了软件性能方面的缺陷，反之说明性能方面不错，常见的性能问题比如资源泄露、线程死锁等
衡量一个系统性能好坏的关键性指标：用户响时间，事务平均响应时间（TPS），吞吐率，每秒点击次数，内存和CPU使用率等
内存泄漏测试
对于内存泄露用户感受不到是什么样的存在，随着内存泄露的不断累加内存空间会越来越紧张对系统造成一定的影响，会出现卡顿严重点导致无响应
内存泄漏的检测方法：
人工静态法：代码走读，人工查找未被回收的内存
自动工具法：借助相应测试内存泄漏的工具，记录每次内存分配，清楚告诉用户内存是如何泄漏的
按照是否查看代码划分
黑盒测试
就是在不关心程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用。测试人员通过输入数据，观察输出结果来验证软件是否满足需求
黑盒测试用到的测试方法：有等价类，边界值，判定表法，场景法，错误猜测法等
测试对象： 软件的功能和用户界面
测试依据： 软件的需求规格说明书和功能说明
优点：不需要关心代码内部的逻辑与实现，站在用户的角度设计测试用例，比较容易想到会涉及哪些功能，提升测试人员的思维，测试用例容易设计，能够发现功能上的缺陷
缺点： 无法检测到代码内部的逻辑缺陷或性能问题
白盒测试
又称为结构测试或逻辑测试，它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试。白盒测试关注的是代码逻辑，所以对业务功能会有一定的疏漏
白盒测试的测试目的：通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致
白盒测试主要包含六种测试方法：语句覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖、分支覆盖等
1. 语句覆盖： 确保代码中的每个语句至少被执行一次
2. 分支覆盖： 确保代码中的每个分支（如 if 语句的 true 和 false 分支）至少被执行一次
3. 条件覆盖： 测试每个条件表达式的所有可能结果（true 和 false）
4. 路径覆盖： 测试代码中的所有独立路径
5. 循环覆盖： 针对循环结构进行测试，验证循环的边界和执行次数
测试对象： 软件的代码逻辑和内部结构
测试依据： 软件的源代码和设计文档
优点： 可以检测代码中的逻辑错误和不完整的路径覆盖
缺点： 需要测试人员具有较强的编程能力和代码理解能力
灰盒测试
介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。就是不仅要关心程序内部还要关注功能是否符合要求
按照开发阶段进行划分
单元测试
单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。就是针对系统最小单元测试，就是一个个类一个个方法
测试阶段：编码后或者编码前（TDD，测试驱动开发）
测试对象：最小模块
测试人员：白盒测试工程师或开发工程师
测试依据：代码和注释+详细设计文档
测试方法：白盒测试
测试内容：模块接口测试、边界测试等
集成测试
对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件模块之间的接口是否正确
测试阶段：一般单元测试之后进行
测试对象：模块间的接口
测试人员：白盒测试工程师或开发工程师
测试依据：单元测试的模块+概要设计文档
测试方法：黑盒测试与白盒测试相结合
测试内容：模块之间数据传输、模块之间功能冲突
系统测试
将系统运行起来对软件上的所有功能模块以及所运行的硬件环境进行测试，以验证系统是否满足需求规格说明书中的所有要求
测试阶段：集成测试通过之后
测试对象：整个系统（软、硬件）
测试人员：黑盒测试工程师
测试依据：需求规格说明文档
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
回归测试
回归测试旨在确保软件在进行修改或更新后，之前已经测试过的功能仍然能够正常工作，不会因为新的修改或更新而出现新的问题或错误。就是对原先的代码做出修改后测试一下这些功能还能不能正常使用
回归测试通常采用黑盒测试方法，即测试人员不需要了解内部实现细节，只需要验证软件的功能是否符合用户需求和预期。在选择回归测试用例时，应该优先选择能够自动化的测试用例，以提高测试效率和准确性
冒烟测试
在正式进行系统测试之前执行。冒烟测试一般在开发人员开发完毕后先进行冒烟测试后，再提交给测试人员来进行测试时，先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。冒烟测试可以理解为系统测试前的预测试，如果冒烟测试通过，则测试人员开始进行正式的系统测试，如果不通过，则测试人员可以让开发人员重新修复代码直到冒烟测试通过，再开始进行系统测试
一个冒烟测试如何执行的？
首先一个测试流程从我们需求分析阶段->测试人员梳理测试点梳理完后也就是梳理测试用例->评审测试用例->测试->项目上线
在梳理测试点的时候如果这个测试点涉及到此次核心模块的话就可以标记为冒烟测试用例，在评审测试用例的时候，如果这个冒烟测试用例不通过则无法进入下一个阶段的测试，注意这个冒烟测试用例不仅是测试人员执行的，也会给到开发进行执行，先让开发执行一下看看能不能通过，如果通过了才给到测试人员进行测试
回归测试和冒烟测试都属于是系统测试
验收测试
验收测试属于是部署软件前最后一个测试，属于技术测试的最后一个阶段，也称为交付测试。通常指的用户来进行验收测试，目的是验证产品是否符合用户需求，实际上主要还是由产品/运维进行验收
测试阶段：系统测试通过之后
测试对象：整个系统（包括软硬件）
测试人员：主要是最终用户或者需求方
测试依据：用户需求、验收标准（测试人员写的）
测试方法：黑盒测试
测试内容：同系统测试(功能...各类文档等)
按照实施组织划分
α测试
α测试先于β测试之前，让用户或除了开发和测试人员外的公司内部人员在开发环境进行测试
β测试
用户在实际使用环境下进行测试，不限时间和地点
α测试和β测试的区别：测试环境和测试时间，α测试先于β测试之前。举个例子就是游戏的内测和公测的区别，内测的参与人员属于是除了开发和测试人员的其他人员以及少数被选中玩家等在开发环境下进行测试，公测的话则面向任何对这个游戏感兴趣的玩家来参与测试，收集更多的意见对产品做出调整，最后也就到了正式发布版
按是否运行划分
静态测试（code review）
不实际运行被测软件,仅通过分析或检查源程序的设计、内部结构、逻辑、代码风格和规格等来检查程序的正确性，就是看代码然后分析
动态测试
实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，就是把程序跑起来测试，大多数软件测试工作都属于动态测试
所以判断一个测试属于动态测试还是静态的，唯一的标准就是看是否运行程序
按照是否手工划分
手工测试
手工执行测试用例，模拟用户的操作，通过手动检查和验证软件功能
优点：
灵活性：适合探索性测试和用户体验测试，能够根据即时观察调整测试策略
直观性：测试人员可以通过观察界面和行为，更直观地发现问题
低初始成本：无需编写脚本和维护测试代码，适合小规模或一次性测试
缺点：执行效率低量大易出错，难以快速覆盖大量测试用例
自动化测试
自动化测试是利用自动化工具执行测试用例，以减少人工干预。自动化工具可以模拟用户操作，执行测试步骤，并自动记录结果分类：接口测试、UI测试等。接口测试的ROI（产出投入比）要比UI测试高
自动化的价值和意义是节省时间和人力，能够快速覆盖大量测试场景和数据集，自动化脚本使用率越高价值也越高。并不是所有测试都适用自动化测试，比如项目不稳定、功能频繁变动的项目。随着软件的变化，需要更新和维护测试脚本，所以缺点比较明显脚本不易快速适应测试场景的变化
自动化测试能否完全替代手工测试？
首先答案肯定是不行的，手工测试适合探索性测试和用户体验评估这些测试是自动化测试无法替代的，需要靠我们的直觉和想象，并且我们可以根据发现的问题及时进行调整。自动化测试适合回归测试和大量重复性测试，能节省时间提高效率，但是自动化测试需要编写脚本投入的时间和资源较多并且对于测试环境变化自动化测试无法做出很好的适应和调整，并且脚本需要随着应用程序的变化而更新保证其有效性
按测试地域划分
国际化测试
测试在各种语言环境下，应用程序是否能被正确地安装，各种操作系统和用户区域设置下，通用功能是否能正确地使用等根据不同国家的风格进行测试
本地化测试
上面我们所讲的全是本地化测试
以上便是本章内容，关于在不同场景下根据不同情况对测试进行划分，根据需求、场景、情况等选择对应的测试方法💕
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
