本文共 9394 字，大约阅读时间需要 31 分钟。

测试分类

测试金字塔(属于测试开发阶段划分)

测试金字塔定义

“测试金字塔”是一个比喻，它告诉我们要把软件测试按照不同粒度来分组 , 它也告诉我们每个组应该有多少测试。 测试金字塔是自动化测试分层覆盖情况的一个参考模型

ROI：投入产出比(测试投入时间和资源与测试成果关系)

为什么测试金字塔越往上投入产出比越小？

1. 越往上定位问题越困难
2. 越往上层测试效率越低

(1)单元测试

单元测试要求在开发中对每个功能模块(函数、类方法)进行测试，如检测其中某一项功能是否按预期要求正常运行。单元测试中通常采用白盒测试，主要对代码内部逻辑结构进行测试。

(2)接口测试

接口测试要求对数据传输、数据库性能等进行测试，从而保证数据传输以及处理的完整性。接口功能的完整运作对整个项目功能扩展、升级与维护有着重要的作用，接口测试通常使用黑盒测试和白盒测试相结合的方式进行。

(3)UI测试

UI测试以用户体验为主，软件的所有功能都是通过这一层展示给用户的，因此UI测试的工作也很重要。由于UI界面以最终的用户体验为主，因此在UI测试中并不是100%地使用自动化测试，其中需要人工操作来确定UI界面的易用程度。

按开发阶段分

1. 单元测试
2. 集成测试
3. 系统测试
4. 验收测试

单元测试

定义：是对软件组成单元进行测试

目的：检验软件基本组成单位的正确性

测试阶段：编码前或编码后(TDD) ; TDD:测试驱动开发。Test-Driven-Development(先写测试用例，再跑测试用例，然后开发人员分解根据测试用例产生的异常区补充开发代码)

测试对象：最小模块

测试人员：白盒测试工程师或开发工程师

测试依据：代码和注释+详细设计文档(V模型)

测试方法：白盒测试

测试内容：模块化接口测试，局部数据结构测试，路径测试，错误处理测试，边界测试

java单元测试框架Junit

• 模块接口测试：主要注意输入参数，参数个数，参数类型，参数顺序要符合接口文档，输出要与预期一致

• 局部数据测试： 检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，局部功能是整个功能运行的基础。

1. 不合适或不相容的类型说明
2. 变量无初值
3. 变量初始化或省缺值有错
4. 不正确的变量名
5. 出现上溢下溢或地址异常

• 边界测试：比如for while等有边界

• 错误处理测试：try catch finally

• 路径测试：if else switch等有路径

集成测试

定义：将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作

目的：检查软件单位之间的接口是否正确

测试阶段：单元测试之后

测试对象：模块间的接口

测试人员：白盒测试工程师或开发工程师

测试依据：单元测试的模块+概要设计文档

测试方法：黑盒测试与白盒测试结合

测试内容：接口之间的数据传输，模块之间的数据传输，模块之间的功能冲突，模块组装功能正确性，全局数据结构，单模块缺陷对系统的影响

系统测试

定义： 是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方。 包括对功能，性能，以及软件所在运行的软硬件环境进行测试，包括回归测试和冒烟测试

目的： 主要目的是为了检测产品是否能正常地运行工作及尽可能多的发现已编程序中存在的错误。

测试阶段：开发完成后，集成测试之后

测试对象：整个系统(软硬件)

测试方法：黑盒测试

测试人员：黑盒测试工程师

测试依据：需求说明文档

测试内容：功能，界面，可靠性，易用性，性能，兼容性，安全性等

回归测试

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

使用场景：添加新需求和修改BUG时

回归测试策略：评估回归测试的范围，自动化测试

冒烟测试

**定义：**对系统的核心功能和主要流程进行测试;是指在对一个新版进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，**是否具备可测试性。 **

准入原则：(决定测试人员是否接受系统进行测试的依据) 选择全部案例数的 40%-50% 测试通过率在 80% 左右即可视为冒烟测试通过，允许测试准入，

如何选取冒烟测试用例

1. 选取重要功能案例

对软件功能实现具有重要影响的功能模块测试案例例如：一个业务的增加删除修改查询计算结果的效验

2. 选取主流程

一个审批流程未能通过，整个流程环节出现阻塞，无法完成完整的审批，就表示冒烟未通过

3. 筛选数据案例

筛选与主流程重要功能相关度高的数据测试案例，原则确保数据满足主流程重要功能测试条件，例如想效验一个商品购买的正确性就离不开商品种类单位库存价格购买数量等数据相关案例

回归测试和冒烟测试的对比

1. 测试范围不同

冒烟测试测试范围是项目中核心业务的正向流程，冒烟测试未通过则必须要求开发进行修改，然后在进行冒烟测试。通过后才能进行其它类型测试

回归测试：对迭代中的项目，当新功能测试完成后对老功能进行回归，目的是验证新增加的功能是否会对老功能产生影响

2. 测试阶段不同

冒烟测试：在正式测试之前

回归测试：在正式测试之后

3. 验收标准不同

冒烟测试：开发做好之后，对其是否支持正常操作或主业务流程是否能够实现的验证

回归测试：验证新的功能对成熟的功能是否有影响

验收测试

定义：在软件产品完成了功能测试和系统测试之后，产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段也称为交付测试

目的：确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务

测试阶段：系统测试之后，主要是用户进行测试

测试对象：整个系统(软硬件)

测试方法：黑盒测试

测试人员：黑盒测试工程师

测试依据：用户需求、验收标准

测试内容：功能，界面，可靠性，易用性，性能，兼容性，安全性，文档(功能说明文档，开发文档，使用说明书)

按测试实施组织

1. a测试
2. B测试
3. 第三方

a测试

**定义：**把用户(除开发和测试以外，公司其他人)请到开发现场进行测试

**目的：**评价软件产品的功能，局域化，可使用性，可靠性，性能，支持

**优点：**能及时解决发现的问题，测试时间比较集中

**缺点：**环境受开发的限制

**举例：**手机出厂前的最后一次测试开发和测试人员不参与

B测试

**定义：**是一种验收测试，用户在正常使用的环境下进行测试通常在一个周期内完成，把问题整理成文档，反馈给开发人员

**优点：**用户在真实的使用情况下进行测试，测试结果更加可靠

**缺点：**测试时间比较分散

a测试和B测试的对比

1. 地域不同

a测试把用户请到开发方场所测试，在开发环境下；

B测试是指字一个或多个用户的场所进行的测试是在用户实际使用的环境下

2. 时间集中程度不同

a测试环境受开发方控制，用户的数量比较少，时间比较集中

B测试环境不受开发方控制用户数量相对较多，时间不集中

a测试先于B测试，通用的软件产品需要较大规模的B测试，测试周期比较长

第三方

第三方软件测评机构，根据行业里的标准和规范进行测试

按是否运行划分

1. 静态测试·
2. 动态测试

静态测试

**定义：**不运行被测程序本身，仅通过分析或检查源程序的语法，结构，过程，接口来检查程序的正确性

对需求说明书，软件设计说明书，源程序做结构分析，流程图分析，符号执行来找错

**检查项：**代码风格和规则审核；程序设计和结构的审核，业务逻辑的审核，走查，审查与技术复审手册

**软件质量衡量标准：**功能性，可靠性，可用性，有效性，可维护性，可移植性

动态测试

**定义：**运行被测程序，检查运行结果与预期结果的差异，并分析运行效率比，正确性，健壮性，

**动态测试组成：**构造测试用例，执行程序，分析程序的输出结果

按是否手工划分

1. 手工测试
2. 自动化测试

手工测试

**定义：**设计测试用例，运行程序，一步一步手动执行测试用例，对系统进行测试

**优点：**比较灵活，可以进行发散性的测试

**缺点：**如果进行大量测试就容易出错，执行效率慢

**手工测试不可以被自动化测试替代， 自动化测试可以很大程度辅助手工测试，能够把测试工程师从繁杂的测试工作中解放出来，但是她无法完全取代手工测试。手工测试和自动化测试各有优缺点，比如易用性测试(是否好用这肯定只有我们人才能体验到机器哪知道什么好用不好用)，界面测试()，探索测试(认识有思维的机器哪有思维)还是需要人来直接测试。 **

自动化测试

**定义：**把手工测试的测试用例转化为自动化脚本，让机器去执行脚本，给定预先设计好的条件和结果的预判去执行

**目的/意义：**提高测试效率，节省大量的人力和时间资源

**前提：**在系统功能比较稳定的前提下才可以进行自动化测试

**自动化测试分类：**接口自动化，性能自动化，web自动化，app自动化，通常说的自动化都是功能自动化

**自动化测试按照测试对象：**接口测试，UI测试等

**自动化测试的最大价值：**脚本的重复利用率，重复利用率越高价值就越大

自动化步骤：

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

**什么项目可以使用自动化：**项目周期长，需要不停的迭代；适用于需求比较稳定的项目

优点：

1. 提高测试效率缩短回归测试时间
2. 可以运行更繁琐的测试
3. 可以执行手工或者不可能进行的测试比如：对大量用户的测试不可能同时让足够多的测试人员进行测试但是却可以通过自动化测试模拟许多用户，
4. 测试具有一致性和可重复性，测试是自动化执行，每次测试的结果和测试内容的一致性可以保证从而达到测试1复用性的效果

缺点：

1. 不能代替手工测试
2. 手工测试比自动化发现的缺陷更多，自动化测试不容易发现新的BUG
3. 对测试质量的依赖性大，自动化脚本运行的前提就是系统功能比较稳定
4. 工具本身是没有思维和想象力的所以自动化完成不了的手工测试可以弥补，两者的有效的结合是测试质量的保证

按是否查看代码划分

1. 黑盒测试
2. 白盒测试
3. 灰盒测试

黑盒测试(不看代码)

**定义：**不关心软件内部的逻辑，结构，只关心输入和输出是否达到我们的预期，相当于把测试的软件看成一个只有输入和输出的黑色盒子

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

白盒测试(看代码)

**定义：**研究软件内部的程序，逻辑和结构，验证是否满足软件需求，相当于把软件看成一个白色透明的能看见内部结构的盒子

白盒测试方法

1. 语句覆盖：把每一条语句都执行
2. 逻辑覆盖：创造一个异常看是否能catch异常或者不能创造异常看是否执行finally,switch
3. 路径覆盖： 覆盖程序中的所有可能的执行路径。if else;switch每一条路径都走过去
4. 判定覆盖： 每个判断的取真分支和取假分支至少经历一次
5. 条件覆盖： 每个判断中每个条件的可能取值至少满足一次。
6. 判定和条件组合： 判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果至少执行一次。
7. 判定组合：
8. 条件组合： 每个判断的所有可能的条件取值组合都至少出现一次。

灰盒测试

介于白盒和黑盒之间，既关心输入输出，又关心程序内部结构（集成测试、接口）

按测试地域划分

1. 国际化测试
2. 本地测试

国际化测试

软件国际化： 软硬件产品对多语言、多文化的支持；以及产品界面和信息的可翻译性。

定义： 是保证产品可被翻译，且翻译后不会影响界面和功能。就是说比如是美国开发的Microsoft系列，那么肯定界面这些都是英文的，那么推广到中国，则需要按照中国的国情和文化，翻译成汉语，并且人们能够理解。

测试方法

1. 通用功能： 各种语言环境下，应用程序是否能被正确地安装； 各种操作系统和用户区域设置下， 通用功能是否能正确地使用 ; 应用程序是否能被正确地卸载。
2. 文本处理功能： 不同区域的输入法编辑器交互式输入文本时，系统的反应；
3. 区域支持功能
4. 文字镜像

本地测试

所讲的测试都是本地测试

定义： 对翻译后的版本去检查 ， 翻译的内容是否正确； 界面显示是否正常； 功能是否正常。

测试方法：

1. 多语言测试
2. 区域文化
3. 数据格式
4. 热键

按测试对象划分

1. 业务测试
2. 界面测试
3. 容错性测试
4. 文档测试
5. 兼容性测试
6. 易用性测试
7. 安装测试
8. 性能测试
9. 内存泄露测试

业务测试

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

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

**测试方法：**场景设计法

**对测试人员要求：**了解业务

界面测试：

测试内容

文字：大小，字体，排版，颜色，粗细，是否加下划线，是否是链接

图片：清晰度，大小，排版，是否重叠，色彩

页面整体排版，空间，对话框，滚动条，弹出框

响应式测试：

**响应式测试：**页面可以随屏幕大小的不同而变换

响应式页面的测试:

1. 文字在不同的分辨率下能够完成并且清晰展示
2. 图片在不同分辨率下能够正常排版，清晰展示，不重叠
3. 届满的功能在不同分辨率下可以正常使用
4. 不同的分辨率下，界面的展示要严格按照UI设计来展示

容错性测试

**定义：**当系统出现一些异常，或者输入错误的信息，进行异常的操作，系统可以自我处理这些错误情况，不会出现崩溃，页面异常情况可以给用户一个很好的体验

**数据容错性：**时间，日期，数字

**效验容错性：**查询信息前后空格会去掉，大小写转换，验证码，数据信息一致性的效验

信息一致性：

填写表单时异常关闭（网络，电力，人为），是否会自动保存

同一个数据被不同人操作的时候是否会锁定

同一个信息在不同平台上被操作（同一账号），信息是否会同步

**界面容错性：**复杂操作会有说明提示，用户在执行风险操作的时候有提示，或者把这些功能处理掉

**环境容错性：**网络，电源，服务器，无缝切换网络设备不会断网

**灾难恢复性测试：**人为的让服务器或服务器所依赖的环境发生故障，测试系统的自我修复能力

1. 系统能不能恢复
2. 系统碰到这些极端的情况的时候胡恢复系统功能和信息所需的时间用户是否能接受

文档测试

文档分类：

1. 开发文档

可行性研究报告，软件需求说明书，概要设计说明书，详细设计说明书，数据库设计说明书，模块开发卷宗

2. 用户文档

用户手册，操作手册，

用户文档的作用：改善易安装性，改善软件的易学性与易用性，改善软件的可靠性

3. 管理文档

项目开发计划，测试计划，测试分析报告，开发进度月报，项目开发总结报告

文档测试的关注点/测试内容：

1. 文档的术语
2. 文档的正确性
3. 文档的完整性
4. 文档的一致性
5. 文档的易用性

兼容性测试：

**定义：**软件之间是否能很好的运作会不会有影响，软硬件之间能否发挥很好的效率工作，会不会影响导致系统的崩溃

测试内容：

1. 平台测试
2. 浏览器测试(内核不同数据解析可能不同)
3. 软件本身是否向前或向后兼容
4. 测试软件能否与其它相关软件的兼容（淘宝和支付宝）
5. 数据兼容性测试

易用性测试：

用户体验性测试，遵循一定的易用性标准（经过前期积累经验，越来越符合人的使用习惯和使用需要）开发软件测试符合标准规范，直观性，灵活性，舒适性、实用性等

安装测试：

安装和卸载

安装：应用商店，命令行，安装包,官网的安装

安全测试：

病毒，SQL注入，xSS,，OS攻击

性能测试：

目的：

1. 能够快速的响应用户的请求
2. 系统能够负载所需的用户数量
3. 能够处理系统所需的事务数量
4. 在负载和事务处理的高峰期，系统可以稳定运行
5. 在系统能够处理的最高用户负载和用户数量的时候，用户可以获得良好的体验

测试内容：

CPU,GPU,内存，硬盘，网络，电源，耗电量

**响应时间：**用户发送请求到用户所期待的响应(页面，信息)展示出来

**吞吐量：**系统在单位时间处理的信息量

分类

1.基准测试

基准最简单的理解就是有基础的标准，这样能通过对比发现系统的不同点与变化。一般情况下，基准测试有以下几种应用场景。

1）可以在制定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化之后，再进行一次相同标准下的测试，即可看出变化对性能的影响。例如，数据库的基准性能测试。

2）系统进行基准测试可以在较早的阶段发现性能问题。例如，如果对BestTest网站进行10个用户并发测试时，系统出现了死机的现象，那么就没有必要进行后续的测试了。

3）某系统从来没有进行过任何性能测试，需要对该系统做一次性能评估作为后续开发调优的参考。这是基准测试常见的一种场景，也是大部分没有做过性能测试的公司最需要的。

虽然基准测试不难理解，但实践起来常常被误解。以对某个系统的数据搜索进行性能基准测试为例，这个系统的数据量会随着时间的增长而增长，所以必须频繁地进行基准测试，这样才能准确地把握数据量的增长对系统性能的影响。但因为进行的基准测试又恰恰是在应用程序级别的，并不能客观地反映全局性的性能。所以，比较好的做法是每次只修改一个地方，这样就能准确地判断出哪个地方会对性能产生影响。

2.并发测试

并发测试可以理解为很多的用户按照预定的场景并发请求某个业务或功能时是否出现并发问题。例如，内存泄露、线程锁、资源争用等，几乎所有的性能测试都会涉及并发测试。并发测试的主要目的是找出并发引起的问题。

那并发数又如何确定呢？小白通过查找资料得知，一般可以通过以下几种方法推算需要的并发数。

1）并发数=PV / PV Time×页面连接次数×HTTP响应时间×因数/ Web服务器数量。

其中，PV Time是PV的统计时间，换算成秒，一天是86 400s。页面连接次数包括外部的JS、CSS、图片等，一般为10。HTTP响应时间一般可为1s或更少。因数一般为5。

假设，BestTest官网每天有6万PV，其余参数保持默认，那么推算出来的并发数大致为35。

PV（page view）即页面浏览量。一个用户有可能创造十几个甚至更多的 PV。它是目前判断网站访问流量最常用的计算方式，也是反映一个网站受欢迎程度的重要指标之一。

2）著名的经典理论80-20原则。

3）参考段念老师在《软件性能测试过程详解与案例剖析》一书中提到的估算方法。

当然，上面的方法仅供参考，需要根据实际的系统特点、业务特点来衡量。

3.负载测试

负载测试可以理解为确定所要测试的业务或系统的负载范围，然后对其进行测试。它的主要目的是验证业务或系统在给定的负载条件下的处理性能。此外，还要关注响应时间、每秒通过事务数和其他相关指标。

从另一个角度理解，负载测试可以看作是性能测试的一部分，但它们两者的目的是不同的，负载测试是为了发现性能问题，而性能测试是为了获取性能指标。因为在性能测试过程中，也可以不调整负载，而是在同样负载情况下通过改变系统的结构、算法、硬件配置等来得到性能指标。

4.压力测试

压力测试可以理解为没有预期的性能指标，不断地加压，看系统什么时候崩溃，以此来确定系统的瓶颈或者不能接受的性能拐点，以获得系统的最佳并发数、最大并发数。仍然以生活中的例子来说明，压力测试就好比跑马拉松，看你到底能跑多久，什么时候就坚持不住了。

压力测试也可以看作是负载测试的一种，即高负载下的负载测试。通过压力测试，可以更快地发现内存泄漏问题，还可以更快地发现影响系统稳定性的问题。例如，在正常负载情况下，某些功能可以正常使用或者出错的概率比较低，但在压力测试下可能很快就会出现，帮助我们提早发现性能问题。

小白想起，公司之前有个网站，在用户少的时候没有什么问题，但在用户多时就暴露出了一些问题，经常会有异常报错产生。看来公司的网站真的需要进行性能测试来评估了，小白心里暗想。

负载测试与压力测试的概念并非完全独立，读者大可不必纠结于文字概念。在实际应用中一般二者都是相互结合、相互补充的。

5.稳定性测试

稳定性测试顾名思义重点在于“稳定”二字，要想知道系统稳定的情况，就需要长时间运行，在这段时间内观察系统的出错几率、性能变化趋势等。进而大大减少系统上线后的崩溃等现象。一般都会进行所谓的7×24小时的稳定性测试。

但稳定性测试也有和其他分类不一样的地方，这里需要强调以下两点。

1）一般稳定性测试需要在系统成型后进行，并且没有严重的Bug存在。

2）场景的设计以模拟真实用户的实际操作为佳。

6.失效恢复测试

失效恢复测试重在关注系统出现问题后能否根据预先制定的策略恢复，且恢复后能否正常运行。怎么理解呢？很简单，以跑马拉松为例，为了预防出现跑不动的情况，预先准备了一瓶红牛（应该给我广告费），当选手累得躺下后，拿出这瓶红牛一口气喝了，然后你有力量了，恢复了原来的状态，站起来继续跑。这下理解了吧。

不过失效恢复测试一般是对具有负载均衡的系统进行的，主要是为了测试当系统局部发生故障时，是否会对全局产生大的影响，产生的影响是否在可以接受的范围内，以及用户能否继续使用系统。

在实际应用过程中，可以模拟一台或几台负载均衡机器出现故障来进行失效恢复测试，但需要注意的是，不仅要关心失效后，用户是否可以正常访问或者恢复后系统是否可以正常工作，也要关注失效后，系统还能支持多少并发用户，以及采用哪些备选方案来快速响应。

小白学到这里也明白了原来性能测试中需要关注许多点，既要有对某个点的思考，也要有扩展点的思考，否则容易遗漏或得出片面的结论，而不能从根本上来预防解决问题。

7.现网性能测试

所谓现网性能测试，就是在实际网络、实际环境中进行测试，完全和真实用户一样。当然这样的测试有一定的风险，需要注意以下几点。

1）时间段的选择。现网性能测试可能会影响正常用户，所以这样的时间段要尽量避开高峰期，选择半夜或者凌晨来进行。

2）垃圾数据处理。如果现网性能测试涉及了写数据的操作，那么肯定会带来不少的垃圾数据，这些数据后期一定要清理，为了清理方便，前期数据的设计要有规律可循。

3）网络限制。和在内网测试不同，现网的测试如果突然间产生大的数据量，可能会被网络带宽限制，甚至路由会认为是非法数据请求而产生拦截等。所以如果在现网进行性能测试，那么压力机需要和被测服务器部署在同一个网段机房内，这样可以避免网络限制，最后远程收集数据即可。

如果没有特殊情况，尽量不要进行现网的性能测试，风险比较大，如果非要进行，一定要事先充分评估风险以及应对的解决方案，这样出了问题可以快速响应，把影响控制到最小。

内存泄露测试：

定义： 系统在使用一些内存的时候，没有及时的释放，无法释放，造成系统占用的内存越来越大，系统运行越来越慢，影响了它的APP的运行速度

内存泄露原因：

1. 分配完之后忘了回收
2. 程序写法有问题，造成无法回收
3. 某些API使用不正确造成内存泄露
4. 没有及时释放

测试方法：

1. 工具检查如Purify,AQTime等
2. 代码扫描分析工具来检查

转载地址：http://ryfki.baihongyu.com/