测试的分类

Posted 2022-11-12 4612

目录

• 1、按开发阶段分
• • 测试金字塔模型
  • 1.1单元测试 ------Junit------白盒测试
  • 1.2集成测试------灰盒测试
  • 1.3系统测试------黑盒测试
  • 1.4回归测试
  • 1.5冒烟测试**
  • 1.6验收测试------纯黑盒测试
• 2、按测试实施组织分
• • 2.1 α测试
  • 2.2 β测试
  • 2.3第三方测试
• 3、按是否运行划分
• • 3.1静态测试
  • 3.2动态测试
• 4、按是否手工划分
• • 4.1手动测试(永远无法被替代)
  • 4.2自动化测试
• 5、按照是否查看代码划分
• • 5.1黑盒测试
  • 5.2 白盒测试
  • 5.3灰盒测试
• 6、按照地域划分
• • 6.1国际化测试
  • 6.2本地化测试
• 7、按测试对象划分
• • 7.1 业务测试
  • 7.2界面测试（UI测试）
  • 7.3容错性测试
  • 7.4文档测试
  • 7.5兼容性测试
  • 7.6易用性性测试（用户体验测试）
  • 7.7安装测试
  • 7.8安全性测试
  • 7.8性能测试
  • 7.8内存泄漏测试

1、按开发阶段分

---

前置知识：V模型-------左开发，右测试，左边是右边的依据

---

测试金字塔模型

特点：

• 从上到下三层中，投入相同的时间，人力资源等，回报率（产出越来越低），投入产出比越来越低

解释：
进行UI界面测试时，要先将服务启动、然后渲染页面，加载数据等之后才能展示到UI界面上
要是进行单元测试时，不用启动服务，直接进行单元测试

• 从下到上，测试效率越来越低
• 从上到下，定位问题越来越难

解释：
上传文件时，要显示在UI界面，就要知道调用的是哪个url,对应的是servlet的哪一个配置,对应的的是哪个方法，最后打断点进行debug调试
要是进行单元测试时，直接就可以进行debug调试

1.1单元测试 ------Junit------白盒测试

单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。又称为模块测试,不许启动项目、渲染页面…

1）测试阶段：

• 编码前（TDD）
  Test-Driven-Develop(测试驱动开发)：测试人员先写测试用例，编写脚本，跑代码，有问题后交给开发人员进行填充，直到程序跑通为止
• 编码后
  开发人员开发完成后，测试人员再开始进行测试
  2）测试方法：白盒测试
  3）测试内容：(选择题)
• 单元接口测试（按照接口设计文档，参数，输出）
• 局部数据结构测试（局部变量）
• 边界测试（for、subString…）
• 路径测试(条件语句if else、switch…)
• 错误处理测试（try catch,throws…）
  4） 测试对象：最小模块
  5）测试人员：白盒测试工程师或开发工程师
  6）测试依据：代码和注释+详细设计文档
  7)单元测试步骤：
• 在pom文件中加入依赖

<dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.11</version>
            <scope>test</scope>
        </dependency>

• 在file-settings-Plugins 搜索JUnit并安装
• 开始做单元测试：
  选中要进行单元测试的类名，Ctrl+shift+T，生成单元测试类
  涉及到的标签：

a) 如果只是想运行某一个方法时，可在其他方法的@Test之前加个@Ignore，可将该方法自动屏蔽掉
举例：

@Ignore
@Test
public static selectAll()

b) @Before-----用来做测试之前配置的初始化工作
在运行某一个测试方法方法之前都会运行
举例：

@Before
public static before()
System.out.println("before run test!")

c) @After-----用来做清理的一些工作
在某个测试方法运行完之后都会运行
举例：

@After
public static after()
System.out.println("after run test!")

1.2集成测试------灰盒测试

按照一定的策略把单元模块i组织起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。

1）测试阶段：一般单元测试之后进行
2）测试对象：模块间的接口
3）测试人员：白盒测试工程师或开发工程师
4）测试依据：单元测试的模块+概要设计文档
5）测试方法：黑盒测试与白盒测试相结合
6）测试内容：模块之间数据传输（输入输出、参数）、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

1.3系统测试------黑盒测试

对被测试的软件应用系统进行全面的系统的测试
1）测试阶段：集成测试通过之后
2）测试对象：整个系统（软、硬件）
3）测试人员：黑盒测试工程师
4）测试依据：需求规格说明文档
5）测试方法：黑盒测试
6）测试内容：功能、非功能性测试（界面、可靠性、易用性、性能、兼容性、安全性、可移植性等）
接口调用的时候

1.4回归测试

1）适用场景：
当系统引入新代码（出现了新功能、修改了BUG…）的时候，就要进行回归测试（新旧功能都要测试）
2）当是大型系统，不停迭代，每次都要进行回归测试时—自动化回归

1.5冒烟测试**

在正式测试之前对系统的主要流程和核心功能进行测试，即针对软件版本包进行详细测试前的预测试
1）目的：快速验证软件基本功能是否有缺陷

2）准入原则：如果对冒烟测试的测试用例不能通过，则不必做进一步的测试

1.6验收测试------纯黑盒测试

验收测试不仅是对系统进行全面测试，也要验收文档（开发文档，软件设计文档，需求分析文档，功能使用文档，用户使用手册）
测试内容同系统测试+文档

2、按测试实施组织分

2.1 α测试

将用户或者非测试和非开发人员请到开发现场进行测试
1）优点：时间比较集中，在开发现场好沟通产品的问题
2）缺点：容易受开发环境的影响（使用该产品的用户和操作都具有多样性，有可能有些用户在使用时会寻求他人帮助）

测试环境：开发环境

2.2 β测试

用户在实际使用环境下进行测试（在新产品发布之前，会邀请活跃用户进行测试）
优点：参与测试的活跃用户测试出的结果更加接近于大部分用户实际使用情况的反馈

优先级：α测试>β测试

测试环境：实际使用环境

在进行β测试前要进行很长一段时间的α测试

2.3第三方测试

由既非开发方又非使用方的人来对软件进行测试
优点：立场客观、公平公正、不偏向开发方或者使用方，使得许多问题可得到比较客观的处理

3、按是否运行划分

3.1静态测试

不运行程序，根据需求规格说明书，软件设计文档，程序设计文档等，分析或检查代码的风格，语法，逻辑等来检查程序的正确性

3.2动态测试

写测试用例，运行系统（程序），执行测试用例，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能
1）这种方法由三部分组成：构造测试用例、执行程序、分析程序的输出结果
2）大多数软件测试工作都属于动态测试。

4、按是否手工划分

4.1手动测试(永远无法被替代)

手动点击某些功能
1)优点；灵活，发散性测试
2)缺点：执行效率慢，量大的话易出错

4.2自动化测试

按照预设的条件去执行测试，收集测试结果，设置正常验证和异常验证（eg:断言）

1）自动化测试的前提：项目的功能相对稳定
2）自动化的价值：脚本的重复使用率（利用率）越高，自动化越有价值

5、按照是否查看代码划分

5.1黑盒测试

不关注程序内部的具体实现，只关注功能的输入和输出是否满足需求

• 黑盒测试设计测试用例的方法：
  等价类划分法、边界值、因果图、正交法、场景法、错误猜测法

5.2 白盒测试

测试时关注功能内部程序实现的逻辑、结构、语法等

• 白盒测试设计测试用例的方法：
  1）语句覆盖法
  2）循环覆盖法（把循环代码块的每一个语句都要覆盖到）
  3）路径覆盖法（switch、if else）
  4）逻辑覆盖法
  包括：
  判定覆盖
  条件覆盖
  判定组合覆盖
  条件组合覆盖
  

5.3灰盒测试

介于白盒和黑盒测试之间的测试

6、按照地域划分

6.1国际化测试

软件国际化：开发软件的时候使用的一种工程技术，使得软件可以适用不同国家的语言，文化和风俗习惯，不用修改源码就可以使用，这种工程技术叫做软件国际化（eg:不同国家的人下载谷歌时界面是按照该国家的语言展示出来的）

6.1.1本地化和国际化测试 的一些要点：

• 本地化后的软件在外观上与原来版本是否存在很大的差异，外观是否整齐、不走样

• 是否对所有界面元素都进行了本地化处理，包括对话框、菜单、工具栏、状态栏、提示信息（包括声音的提示）、日志等

• 在不同的屏幕分辨率下界面是否正常显示（不通过家用的显示器、硬件设备可能存在差异）

• 是否存在不同的字体大小，字体设置是否恰当。

• 日期、数字格式、货币等是否能适应不同国家的文化习俗。例如，中文是年月日，而英文是月日年

• 排序的方式是否考虑了不同语言的特点。例如，中文按照第一个字的汉语拼音顺序排序，而英文按照首字母排序

• 在不同的国家采用不同的度量单位，软件是否能自适应和转换。

• 软件是否能在不同类型的硬件上正常运行，特别是在当地市场上销售的流行硬件上

• 软件是否能在Windows或者其他操作系统的当地版本上正常运行

• 联机帮助和文档是否已经翻译，翻译后的链接是否正常。正文翻译是否正确、恰当， 是否有语法错误软件本地化和国际化测试是一个综合了翻译行业和软件测试行业的测试类型。它要求测 试人员具备一定的翻译能力、语言文化，同时具备测试人员的基本技能

6.2本地化测试

• 本地化测试的对象：软件的本地化版本

• 本地化测试的目的：测试特定目标区域设置的软件本地化质量

• 本地化测试的环境：在本地化的操作系统上安装本地化的软件

• 分类
  从测试方法上可以分为基本功能测试，安装/卸载测试，当地区域的软硬件兼容性测试

• 测试内容
  测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量，包含软件、文档和联机帮助等部分

7、按测试对象划分

7.1 业务测试

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

• 测试方法：场景法

• 举例（查看邮件）
  登录网站-输入用户名、密码登录-进入收件箱-查到邮件-点击打开-查阅-关闭邮件-退出邮箱-关闭网站

7.2界面测试（UI测试）

原则：
完整性、准确性、一致性、易用性

• 布局
  测试点：字体、图像
• 控件
  测试点：对话框（是否可正常显示）、文本框、按钮(高亮/置灰)、滚动条（页面是否可根据滚动条的上下移动滚动到相应的内容）、CheckBox（勾选）、确认框（确定/取消）
• 不同页面大小的自适应测试（在不同大小的屏幕上是否可完整显示所有功能）
  页面从大到小：文字、图片有没有消失、重叠
  页面从大到小：功能有没有消失
  页面从大到小：是否可正常使用
  页面从大到小：衔接是否丝滑

7.3容错性测试

当系统由于外界异常或者认为错误引起的错误，系统可以自我消化掉，而不把这些错误或者异常直接展示给用户
7.1 容错性测试测试点
7.1.1 数据级别
数字类型超出应用设定最大值
数字类型超出类型最大值
数据类型填写非数据类型
时间类型超出引用设定限制（ios32位的设备在测试时间相关的功能时经常会出现1970年，需要让开发单独做处理喔）
时间类型填写其他类型数据
文本类型超出应用设定长度
数据不符合实际规则（例如输入不存在的日期，或货币内容可以输入小数点后多于2位以上等）
是否对输入内容的大小写进行自动转换，以防止用户对于大小写敏感内容出现输入错误

7.1.2校验级别

• 填写不符合校验的数据，例如不能以数字开头的输入，输入数字开头的数据验证码，填写错误的验证码
• 需重复一致填写时，填写不一致数据
• 对于文本框输入类型内容有要求是否进行了键盘输入检测
• 上传不符合类型的文件
• 是否对输入内容的前后空格进行自动去除，以防止用户输入不该存在的前后空格

7.1.3环境级别
1）服务器故障、断网、断电，如果出现问题，都会有备份服务器，不影响用户体验（让用户感知不到），或者有一个友好的提示
2）断网断电时，系统自动保存数据，环境恢复时，数据依然会存在
7.1.4界面级别

• 不按正常流程操作
• 使用非正常手段访问（例如直接使用内部链接地址访问，直接使用访问协议访问）
• 对于不应该进行的操作或违法操作是否进行了相关的屏蔽
• 对于一些存在限定条件的输入参数，在界面或页面上是否有输入要求提示
• 若只能对于某些固定的输入的内容进行处理时，应该使用下拉框或选择框控件，以防止用户输入错误
• 对于一些操作较复杂或较容易造成错误的界面，系统是否有明确的说明或向导提示，以减少用户输入或操作错误

7.1.5灾难恢复性测试
通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复

7.4文档测试

文档测试的关注点：

• 文档的术语
• 文档的正确性
• 文档的完整性
• 文档的一致性
• 文档的易用性

7.5兼容性测试

1）应用平台

• 手机端（android、iOS）：
  不同网络运营商
  不同型号手机
  屏幕适应性

• PC端
  Windows、Mac、Unix、Ubuntu（对不同系统的不同版本进行测试）

• web系统
  不同浏览器不同版本

2）软件向前向后的兼容性（前后版本）
3）软件和其他相关软件的兼容性（eg：利用第三方软件登录（调用同一个接口））
4）数据的兼容性

7.6易用性性测试（用户体验测试）

1）遵循的标准（行业标准）
要以用户的习惯为基准
2）直观性
要让用户直观地看到显示的内容
3）灵活性
针对不同习惯的用户有相应的功能（九宫格和全键盘、设置不同背景），复杂性略高
4）舒适性（进度条）
5）实用性

7.7安装测试

1）应用是否可以正常安装 （命令行安装（测试人员）；应用商店等第三方软件安装；apk/ipa安装包安装）
2）应用是否可以在IOS和Android不同系统、版本、机型上进行安装（有的系统版本过低，应用不能适配）----（安装兼容性的测试）
3）安装过程中是否能暂停，再次点击，是否继续安装
4）安装空间不足时，如何表现，是否有相应提示，提示是否友好
5）安装过程中断网或网络不稳定的情况下，是否有相应提示
6）是否可以正常删除（卸载）应用(桌面删除；第三方软件删除；命令行删除)
7）应用卸载后所有的安装文件夹是否全部删除
8）卸载过程中出现死机、断电、重启等紧急意外情况，待环境恢复后是否可以继续正常卸载
9）卸载是否支持取消功能，单击取消后软件卸载情况是否正常
10）移除APP，类似于删除快捷方式

7.8安全性测试

数据泄漏、黑客攻击、SQL注入（某些操作使得库数据被清空/信息泄漏），XSS注入、病毒…

7.8性能测试

资源泄漏、资源瓶颈、线程阻塞、数据库查询效率慢效率低…

• 测试指标
  资源利用率（CPU、带宽、硬盘）、点击率、响应时间、每秒事务处理量…

7.8内存泄漏测试

• 内存泄漏引起的原因
  分配的内存没有释放
  使用API函数的时候不正确
  代码写的有问题，导致最终无法释放内存
• 测试方案
  代码评审、使用工具