一，为什么要对软件测试进行分类
软件测试是软件生命周期中一个重要的环节，具有较高的复杂性，对于软件测试，可以从不同的角度来进行分类，使开发者在软件开发过程中的不同层次，不同阶段对测试工作进行更好的执行和管理测试的方法
二，按照测试目标分类
2.1 界面测试
软件只是⼀种工具，软件与人的信息交流是通过界⾯来进行的，界面是软件与用户交流的最直接的一层，界面的设计决定了用户对我们设计的软件的第⼀印象；界面如同人的面孔，具有吸引用户的 直接优势，设计合理的界面能给用户带来轻松愉悦的感受
界面测试（简称UI测试)，指按照界面的需求（一般是UI设计稿）和界面的设计规则，对我们软件界面所展示的全部内容进行测试和检查，⼀般包括如下内容：
- 验证界面内容显示的完整性，⼀致性，准确性，友好性。比如界面内容对屏幕大小的自适应，换行，内容是否全部清晰展示
- 验证整个界面布局和排版是否合理。比如不同板块字体的设计，图片的展示是否符合需求
- 对界面不同控件的测试。比如对话框，文本框，滚动条，选项按钮等是否可以正常使⽤
- 有效和无效的状态是否设计合理
- 界面的布局和色调符合当下时事的发展
2.2 功能测试
根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的⼀样。功能测试是为了确保程序以期望的方式运行而按功能要求对软件进行的测试，通过对⼀个系统的所有的特性和功能都进行测试确保符合需求和规范，功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能
如何进行功能测试呢：
设计功能测试用例，参考产品规格说明书进行用例的编写，具体的测试用例需要使用黑盒设计测试用例的方法，如等价类、边界值、判定表法、正交法、场景法、错误猜测法等。
2.3 性能测试
我们在使用软件的时候有时会碰到软件网页打开时越来越慢，查询数据时很长时间才显示列表，软件运行越来越慢等问题，这些问题都是系统的性能问题引起的
要进行软件产品的性能问题，要对产品的性能需求进行分析，然后基于系统的性能需求和系统架构，完成性能测试的设计和执行，最后要进行持续的性能调优
2.4 可靠性测试
可靠性（Availability）即可用性，是指系统正常运行的能力或者程度，⼀般用正常向用户提供软件服务的时间占总时间的百分比表示。
可靠性 = 正常运行时间/（正常运行时间+非正常运行时间）*100%
2.5 安全性测试
安全性是指信息安全，是指计算机系统或网络保护用户数据隐私，完整，保护数据正常传输和抵御黑客，病毒攻击的能力
安全性测试属于非功能性测试很重要的⼀个方面，系统常见的安全漏洞和威胁如下
- 输⼊域，如输⼊恶性或者带有病毒的脚本或⻓字符串；
- 代码中的安全性问题，如SQL/XML注⼊
- 不安全的数据存储或者传递
- 数据⽂件，邮件文件，系统配置文件等里面有危害系统的信息或者数据；
- 有问题的访问控制，权限分配等
- 假冒ID：身份欺骗
- 篡改，对数据的恶意修改，破坏数据的完整性
2.6 易用性测试
许多产品都应用人体工程学的研究成果，是产品在使用起来更加灵活和，舒适。软件产品也始终关注用户体验，让用户获得舒适，易用的体验，针对软件这方面的测试称之为易⽤性测试。
易用性指容易发现，容易学习和容易使用。易用性包含七个要素：符合标准和规范，直观性，⼀致性，灵活性，舒适性，正确性和实⽤性。
1，标准性和规范性 ：对于现有的软件运行平台，通常其UI标准已经不知不觉地被确立了，成为大家的共识。多数用户已经习惯并且接受了这些标准和规范，或者说已经认同了这些信息所代表的的含义。测试⼈员需要把与标准规范，习惯不⼀致的问题报告为缺陷
2，直观性 ：用户界面的直观性，要求软件功能特性易懂，清晰。用户界面布局合理，对操作的响应在用户的预期之中。
3，灵活性 ：软件可以有不同的选项以满足不同使用习惯的用户来完成相同的功能。但是灵活性的设计要把握好度， 不然可能由于太多的用户状态和方式的选择，增加了软件设计的复杂性和程序实现的难度。
4，舒适性：主要强调界⾯友好，美观，操作过程顺畅，色彩用运恰当，按钮的立体感等。
三，按照执行方式分类
3.1 静态测试
所谓静态测试（static testing）就是不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。不以测试数据的执行而是对测试对象的分析过程，仅通过分析或检查源程序的设计、内部结构、逻辑、代码风格和规格等来检查程序的正确性。
常见的静态测试方式有代码走查，代码扫描工具等。
3.2 动态测试
动态测试（dynamic testing），指的是实际运行被测程序，输入相应的测试数据，检查实际输出结
果和预期结果是否相符的过程。大多数软件测试工作都属于动态测试
判断⼀个测试属于动态测试还是静态的，唯⼀的标准就是看是否运行程序。
四，按照测试方法分类
4.1 白盒测试
白盒测试又称为结构测试或逻辑测试，它⼀般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试。
白盒测试的测试目的，通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否⼀致
白盒测试主要分为静态测试 和动态测试两种。
静态测试常见于桌面检查、代码审查、代码走查、代码扫描工具
动态测试方法主要包含六种测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖，路径覆盖
举栗子：
if A and B
then act1
if C or D
then act2语句覆盖：每个语句至少执行一次 （A-T B-T C-T D-F）
判定覆盖：if语句就是判定语句，if条件为真或假 （ A-T B-T C-T D-T / A-T B-F C-F D-F）
条件覆盖：每种条件都覆盖到 （A-T B-T C-T D-T / A-F B-F C-F D-F）
判定条件覆盖：结合判定覆盖和条件覆盖来设计测试用例，用例即可以覆盖判定，也可以覆盖到条件 （A-T B-T C-T D-T / A-F B-F C-F D-F）
条件组合覆盖:(A-T B-T C-T D-T / A-T B-F C-T D-F / A-F B-T C-F D-T / A-F B-F C-F D-F ）
白盒测试主要应用于单元测试阶段
先执行静态设计用例的方法，再执行动态设计测试用例的方法
设计用例⼀般使用路径测试，重点模块追加使用逻辑覆盖方法
4.2 黑盒测试
黑盒测试就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用，是否能适当的接收输入数据而输出正确的结果，满足规格需求
黑盒测试优点 ：不需要了解程序内部的代码以及实现，不关注软件内部的实现。 从用户角度出发设计测试⽤例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维
测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。
黑盒测试缺点：不可能覆盖所有代码。黑盒测试用到的测试方法有，等价类，边界值，因果图，场景法，错误猜测法等
4.3 灰盒测试
灰盒测试，是介于白盒测试与黑盒测试之间的⼀种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。
但是，灰盒测试没有白盒测试详细和完整，黑盒测试是覆盖产品范围最广的测试，因此灰盒测试基本是不能够替代黑盒测试，否则需要很大的代价，设计非常多的用例。
五，按照测试阶段分类
5.1 单元测试
与编码同步进行，针对软件最小组成单元进行测试，主要采用白盒测试方法，从被测对象的内部结构出发设计测试用例（白盒测试）
5.2 集成测试
集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确 （黑盒测试与白盒测试相结合）
5.3 系统测试
对通过集成测试的系统进行整体测试，验证系统功能性和非功能性需求的实现 （黑盒测试）
5.3.1 冒烟测试
在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会影响整个版本的稳定性
5.3.2 回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错
误。在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
回归测试主要由人工测试和自动化测试进行。
|----|---------------------------------------|---------------------------------------------------|
| | 冒烟测试 | 回归测试 |
| 阶段 | 通常在软件开发的早期阶段进行，主要用于验证基本功能是否正常工作 | 在软件开发的后期，通常在每次代码修改或新增功能后执行 |
| 目的 | 确保软件的主要功能能够基本运行，以便在后续的详细测试阶段发现更深层次的问题 | 确保已有的功能仍然正常工作，并且新的更改没有引入新的错误。目的是防止已有功能因为代码修改而出现问题 |
虽然它们都属于系统测试，但冒烟测试注重最基本的功能，而回归测试关注全面的功能，包括已有功能和新添加的功能。这两种测试类型在测试策略中起到了不同的作用，帮助确保软件质量和稳定性。
5.4 验收测试
针对用户需求，对通过系统测试的软件进行交付性测试，以确定系统是否满足验收标准，由用户或其他授权机构决定是否接受系统。验收测试是部署软件之前的最后⼀个测试操作。它是技术测试的
最后⼀个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、
双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求
六，按照是否手工测试
6.1 手工测试
手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的⼀个步骤。
6.2 自动化测试
自动化测试是把以⼈为驱动的测试行为转化为机器执行的一种过程。 自动化测试比如功能测试自
动化、性能测试自动化、安全测试自动化。 自动化测试按照测试对象来分，还可以分为接口测试，UI测试等。
| 对比维度 | 手工测试 | 自动化测试 |
|---|---|---|
| 执行主体 | 人工手动操作 | 代码 / 工具机器执行 |
| 上手成本 | 低，无需编码 | 高，需写脚本、搭环境 |
| 重复回归效率 | 低，耗时长 | 极高，一键批量执行 |
| 需求频繁变更适配 | 适配强，无维护成本 | 适配差，脚本频繁失效 |
| 探索性、体验测试 | 优势明显，擅长 | 短板，只能固定流程 |
| 性能 / 并发测试 | 完全不支持 | 完美支持高并发、压测 |
| 缺陷发现类型 | 视觉、偶现、体验 bug | 流程、逻辑、并发类 bug |
| 长期项目成本 | 持续消耗人力，成本高 | 一次编写多次复用，成本递减 |
| 适用场景 | 新功能测试、探索测试、小项目、UI 视觉校验 | 版本回归、接口压测、长期稳定产品、CI 流水线校验 |
七，按照实施组织划分
7.1 α测试
α测试又叫内测 或者叫a测
α测试通常是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的
FLURPS(即功能、可使用性、可靠性、性能和支持)。 α测试不能由程序员或测试员完成
7.2 β测试
β测试又叫公测 或者叫b测
β测试由软件的最终用户们在⼀个或多个场所进行，这里就可以理解为，β测试是正式用户中的⼀部分，他们在任意的场合来使用软件，目的是为了发现软件是否存在⼀系列的问题
测试的场所不同：α测试是在公司内部进行测试的,但是β测试是在用户环境下进行测试的
α测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。
β测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
测试执行时机不同：α测试先于β测试执行。通常是α测试通过后，在进行β测试
测试持续时间长短不同：α测试时间没有β测试持续时间长
八，小结
目前是6月12号，估计明天这篇文章才会发布，但是我想现在也写一点小结。明天要考六级了，我也不知道能不能过，诶，无所谓了，明天开开心心去然后开开心心写完，奖励自己开一个小榴莲，第二天再带猫猫去查身体。有时候觉得很累，虽然断断续续坚持在学，但是并不清楚自己到底掌握多少，也不知道能不能找到实习，好难啊。谁说20岁是人生最美好年纪的，我感觉我现在站在无数个十字路口，我也不知道这样选择对不对，我也不知道能不能把这个选择做好，想要的太多但是能抓住的又太少。加油吧。现在是17号，哈哈哈又拖了那么久，心累啊心累，找房子看了几天还是没租到满意的，工作也没有，六级也不知道能不能过，老铁们好难啊