软件测试的分类

Posted 2021-09-28 你这家伙

首先来看看软件测试有哪些分类

按开发阶段划分

问题来了：为什么测试金字塔越往上投入的产出比越小？
测试人员投入相同的精力，测试成果越来越小
（1）越往上定位问题越困难
（2）越往上层，测试效率越低
例如：比如有一个登录注册页面，那么如果是在UI层的话，如果出现问题，那么此时就要先去查看调用了业务逻辑层的那个接口，查出这个是由那个功能模块产生的，定位到那个功能模块产生的问题之后，然后再去数据库里面查找调用了哪一个业务处理，然后再看为什么会出现这个问题，这个问题的定位成本就很大；但是单元测试，我们就是测这个代码模块，那么出现问题就可以直接定位，然后解决

单元测试

针对系统的一个小的单元模块进行测试
测试阶段：编码后，编码前（TDD）
测试对象：最小模块
测试人员：开发工程师和白盒测试工程师(因为单元测试设计代码内部逻辑的一个测试，内部的测试就是白盒测试)
测试依据：代码和注释+详细设计文档，可以去查看V模型
测试方法：白盒测试
测试内容：

• 模块接口测试（输入参数，参数的个数，参数的模型，参数的顺序要符合接口文档）
• 局部数据测试，查看数据流转是否正确，虽然有时候输出的结果是正确的，但是数据的流转却不符合我们的逻辑（边界测试（for while），路径测试（if else，switch），错误处理测试（try catch finally））

集成测试

将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试，主要是检查软件单位之间的接口是否正确（注：不是所有的接口都是串联起来的，比如A B C D 不一定非得是A调用B，然后B调用C，也有可能是A调用B，满足条件去执行C，不满足条件去执行D）
测试阶段：单元测试之后
测试对象：模块间的接口
测试人员：白盒测试工程师和开发工程师
测试依据：单元测试的模块+概要设计文档
测试方法：黑盒测试和白盒测试相结合
测试内容：模块之间数据的传递，模块之前功能的冲突，模块功能的正确性，全局数据结构，单个模块的缺陷对整个系统的影响

系统测试

将软件系统看成一个系统的测试，他有哪些功能我们就测试哪些功能，（如：功能，性能，运行环境，网络环境），时间大部分在系统测试阶段（包括回归测试和冒烟测试）

测试阶段：集成测试之后，也就是开发完成之后
测试对象：整个系统（软硬件）
测试人员：黑盒测试工程师
测试依据：需求规格说明文档
测试方法：黑盒测试
测试内容：如界面，功能，性能，易用性，安全性，兼容性等

回归测试

当系统的代码进行了修改的时候，为了防止新添加的代码对系统引入新的错误而进行测试

• 添加新的需求
• 修改Bug

但是问题来了，当我们对系统修改的时候要怎么进行修改，比如微信突然想要添加一个功能，但是总不可能停服去修改把，而且对系统进行修改之后要不断的进行测试，就是新添加的功能会不会对其他功能造成影响，那么我们此时就使用自动化测试（使用脚本去测试）

冒烟测试

准入原则，对系统的核心功能和主要流程进行测试
决定测试人员是否接受系统进行正式测试的依据，如果冒烟测试通过，那么我们就可以进行测试，如果不通过，那么就无法测试，也就是系统的核心功能都没有实现，那么就无法进行测试（比如一个登录qq，假如登录都没有实现，那么我们怎么去测试登录会产生哪些情况）

验收测试

测试阶段：系统测试通过之后
测试对象：整个系统（软硬件）
测试人员：用户或需求方
测试依据：用户需求，验收标准
测试方法：黑盒测试
测试内容：如界面，功能，性能，易用性，安全性，兼容性等，但是这里还有一个文档也需要测试（功能文档，说明文档（系统说明书，因为有的系统可能比较麻烦））

测试的实施组织

α测试

把用户（包括除了开发和测试以外，公司的其他人）请到开发现场进行测试
优点：及时的解决发现问题，测试时间比较集中
缺点：环境手开发环境的限制

β测试

既用户在正常的使用环境进行测试，通常一个周期测试完成，把问题整理成文档，然后反馈给开发人员
优点：用户在真实的使用环境下进行测试
缺点：测试时间比较分散
注：β测试在α测试之后

第三方

既第三方软件测评机构，专门进行软件测试，根据行业里面的一些标准和规范进行测试，介于开发方和用户方间的组织的测试。

是否运行划分

静态测试

指不运行程序，近视分析或检查源程序的语法，结构，过程，接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。

检查项：代码风格和规则审核；程序设计和结构的审核；业务逻辑的审核；走查、审查与技术复审手册。
静态质量：度量所依据的标准是ISO9126。在该标准中，软件的质量用以下几个方面来衡量，即功能性、可靠性（系统的可靠性，也就是是系统在遇到问题的时候能够自我处理）、可用性、有效性、可维护性（系统好不好维护，添加功能好不好添加）、可移植性（就是在不同的平台上面都能够很好的使用）。

动态测试

这部分由三部分构成：构造测试用例，执行结果，分析程序的输出结果
指运行被测程序，检查运行结果和预期结果的差异，并分析其运行效率，正确性和健壮性等性能

多数软件测试工作都属于动态测试

是否手工测试

手工测试

手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤
缺点：如果进行大量的测试容易出错，执行效率慢
优点：比较灵活，可以发散性进行测试
比如在浏览器查询一个事务：我们需要手动在浏览器输入要查询的关键词然后点击查询，才能到达我们想要的界面看到信息

自动化测试

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
前提：在系统功能比较稳定的前提下才可以进行自动化测试
优点：脚本的重复利用了越高，价值越大
缺点：没有手工测试灵活

比如：我们可以写一个脚本，运行脚本，就可以直接自动在浏览器找到我们想要的信息

自动化实施步骤：
1.完成功能测试，版本基本稳定
2.根据项目特性，选择适合项目的自动化工具，并搭建环境
3.提取手工测试的测试用例转化为自动化测试的用例
4.通过工具、代码实现自动化的构造输入，自动检测输出结果是否符合预期
5.生成自动测试报告
6.持续改进，脚本优化。

按照是否查看代码划分

黑盒测试

不关心软件内部的逻辑，结构，只关心输入和输出是否达到我们的预期，相当于我们吧测试的软件看做成一个只有输入和输出的黑色的盒子；
黑盒测试用例方法：等价类，边界值，因果图，正交法，场景法，错误猜测法

白盒测试

研究软件内部的逻辑和结构，验证是否满足软件需求，相当于把软件看成一个内部可以看得见的白色的盒子去测试

白盒测试的方法：语法覆盖，逻辑覆盖，路径覆盖，判定覆盖，条件覆盖，判定和条件的组合，判定组合，条件组合

按照地域进行划分

国际化测试

软件的国际化和软件的本地化是开发面向全球不同地区用户使用的软件系统的两个过程。而本地化测试和国际化测试则是针对这类软件产品进行的测试。由于软件的全球化普及，还有软件外包行业的兴起，软件的本地化和国际化测试俨然成为了一个独特的测试专门领域。 比如下列一些测试的要点：

1. 本地化后的软件在外观上与原来版本是否存在很大的差异，外观是否墼齐、不走样。
2. 是否对所有界面元素都进行了本地化处理，包括对话框、菜单、工具栏、状态栏、提示信息（包括声音的提示）、日志等。
3. 在不同的屏幕分辨率下界面是否正常显示。
4. 是否存在不同的字体大小，字体设置是否恰当。
5. 日期、数字格式、货币等是否能适应不同国家的文化习俗。例如，中文是年月日，而英文是月日年。
6. 排序的方式是否考虑了不同语言的特点。例如，中文按照第一个字的汉语拼音顺序排序，而英文按照首字母排序。
7. 在不同的国家采用不同的度量单位，软件是否能自适应和转换。
8. 软件是否能在不同类型的硬件上正常运行，特别是在当地市场上销售的流行硬件上。
9. 软件是否能在Windows或者其他操作系统的当地版本上正常运行。
10. 联机帮助和文档是否已经翻译，翻译后的链接是否正常。正文翻译是否正确、恰当， 是否有语法错误。

按测试对象划分

业务测试

是测试人员把系统各个模块串接起来运行、模拟真实用户实际的工作流程，满足用户需求定义的功能来进行测试的过程

常用方法：业务场景法

界面测试

测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯 如 文字：大小，字体，排版，颜色，粗细 图片：清晰度，大小，排版，色彩 页面整体排版：信息提示弹出框 控件：对话框，查询框，滚动条，弹出框

响应测试：页面随和屏幕的大小的不同而变换

1. 文字在不同分辨率下能够完成并且清晰展示
2. 图片在不同分辨率下能够正确排版，清晰展示，不重叠
3. 界面的功能在不同的分辨率下可以正常使用
4. 界面在不同的分辨率下切换的时候，是平滑的过渡
5. 在不同的分辨率下，界面的展示要严格按照UI设计稿来进行展示

容错性测试

当系统出现一些异常，或者用户输入错误的信息，进行异常的操作，系统能够自我处理这些错误的情况，不会出现崩溃，页面异常这种情况，可以给用户一个很好的提示体验
数据容错性：时间，日期，数字
校验容错性：查询信息前后加空格 去掉，数据信息一致性的校验(信息级别：填写表单的时候，异常关闭（网络，没电，认为）是否自动保存；同一个数据被不同的人操作的时候，是否会被有锁定；同一个信息在不同的平台被操作（同一个账号），信息要同步。)
界面容错性：复杂的操作，有说明的提示 用户在执行有风险的操作的时候，会给出提示
环境容错性：网络，电源，服务器
灾难恢复性测试：认为的让服务器或者服务器所依赖的环境发生故障，测试系统的自我修复能力；还有系统恢复的时间用户是否能够接受

文档测试

• 开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
• 用户文件:用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。
• 管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
  在实际的测试中，最常见的是用户文件的测试，例如：手册说明书等。也会有一些公司对需求文档进行测试，来保证需求文档的质量。

兼容性测试

如web系统

• 操作系统 Windows ios 不同的操作系统要进行测试，不同操作系统的版本
• 本地也要测试，浏览器要装在不同的操作系统上
• 不同的浏览器下，网页是否能够正常展示和使用
• 不同的浏览器的市场上主流的版本
  ……
  如果是App
• 不同的机型
• 不同机型的操作系统
• 不同操作系统主流版本
  ……

软件本身向前或向后的兼容性
软件和其他相关软件的兼容性
数据兼容性

易用性的测试

遵循一定的易用性标准开发软件，是交互的适应性、功能性和有效性的集中体现
如直观性和软件的展示要和软件定位相关（如：微信删除聊天记录）

当然还有
安装卸载测试
安全测试
性能测试
内存泄漏测试
……
这里就不一一列举了