您现在的位置是：首页 >学无止境 >软件测试之测试分类网站首页学无止境

目录

1.按界面测试划分

1.1 界面测试

1.2 可靠性测试（简单了解，但是作为测试员要知道这个概念）

1.3 容错性测试

1.4 文档测试 

1.5 兼容性测试（非常重要）

1.6 易用性测试

1.6 安装卸载测试

1.7 安全测试

1.8 性能测试

1.9 内存泄漏测试

2.按是否查看代码划分

2.1 黑盒测试(Black-box Testing)——不关注代码内部实现，关注测试执行结果是否和预期结果一致

2.2 白盒测试(White-box Testing)——关注代码内部实现

2.3 灰盒测试(Gray-Box Testing)——代码关注，业务上的预期结果和实际结果是否匹配也关注

3.按开发阶段划分

3.1 测试金字塔

3.2 单元测试(Unit Testing)

3.3 集成测试(Integration Testing)

3.4 系统测试(System Testing)

3.5 回归测试(Regression Testing)

3.6 冒烟测试（smoke testing）

3.7 验收测试(Acceptance Testing)

4.按测试实施组织

4.1 α测试(Alpha Testing)

4.2 β测试(Beta Testing)

4.3 α测试与β测试区别

4.4 第三方测试

5.按是否运行划分

6.按是否手工划分

7.按测试地域划分

8.设计测试用例-登陆页面

9.测试用例设计-淘宝购物车

---

🌈本章内容主要介绍软件测试的各种技术。我们作为一个测试人员，需要不断的扩充自己的测试知识。并且用于这些知识在测试项目中。

接下来我会用一个思维导图来介绍今天所学的知识！!

1.按界面测试划分

1.1 界面测试

界面：用户直接通过肉眼看到的页面（例如：web站、APP、PC端、小程序、公众号......）

界面的重要性：用户通过软件界面来完成使用软件的这个目的

界面测试（简称UI测试)：指按照界面的需求（一般是UI设计稿）和界面的设计规则，对我们软件界面所展示的全部内容进行测试和检查，一般包括如下内容：

1️⃣验证界面内容显示的完整性，一致性，准确性，友好性。比如界面内容对屏幕大小的自适应，换行，内容是否全部清晰展示；

2️⃣验证整个界面布局和排版是否合理，不同板块字体的设计，图片的展示是否符合需求；

3️⃣对界面不同控件（控件：页面上的最小化“图形”）的测试，比如，对话框，文本框，滚动条，选项按钮等是否可以正常使用，有效和无效的状态是否设计合理；

4️⃣界面的布局和色调符合当下时事的发展。

1.2 可靠性测试（简单了解，但是作为测试员要知道这个概念）

可靠性（Availability）即可用性，是指系统正常运行的能力或者程度，一般用正常向用户提供软件服务的时间占总时间的百分比表示。

可用性指标一般要求达到4个或5个“9”，即99.99%或者99.999%

如果可用性达到 99.99% ，对于一个全年不间断（ 7*24 的方式）运行的系统，意味着全年（ 252600min) 不能正常工作的时间只有52min ，不到一个小时。

如果可用性达到99.999%，意味着全年不能正常工作的时间只有5min。

不同的应用系统，可用性的要求是不一样的，非实时性的信息系统或一般网站要求都很低，99%和99.5%就可以了，但是军事系统，要求则很高；

🙈思考题：如何进行可靠性的测试？

---

🙉通过一些工具编写一些脚本，让脚本自动运行，自动运行完之后就会有一个报告，作为测试员只需要针对报告做一个总结的结果

     让系统不断的运行，例如先运行24h是否存在问题，如果不存在问题；进而运行7*24h 、一个月......

     涉及到性能测试，必须借助工具，不能依靠人工测试！！！

1.3 容错性测试

容错性测试是指系统能够处理异常，用户的错误操作而不至于系统崩溃，从而能够提高系统的可用性。

例如： 写一个除法计算器 2/0，这个时候代码会报异常了，如果把异常直接抛给用户，就相当于摆烂，用户人员根本看不懂发生了什么（程序员可以看懂，但是有多少是程序员呢，我们应该面向大众化）；此时就需要系统捕获异常，针对这些异常进行处理（被除数不能是0）

容错性测试包含1️⃣输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。 （比如数据级测试，校验测试，环境容错性测试，界面容错性测试）2️⃣灾难恢复性测试：通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。

1.4 文档测试 

文档可以划分为：1️⃣开发文件2️⃣用户文件3️⃣管理文件

开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。开发文档相当于一个技术文档，用来记录每一个模块代码如何实现

用户文件（测试人员进行编写）：用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。

管理文件（分析软件质量）：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

文档测试的关注点：

文档的术语

文档的正确性

文档的完整性

文档的一致性

文档的易用性

1.5 兼容性测试（非常重要）

兼容性测试需求是指明确要求测试的兼容环境；兼容测试非常耗费时间

1️⃣设备：电脑、手机、ipad

 如果是浏览器打开的网页，那么此时就需要考虑浏览器版本

2️⃣操作系统：windows、mac、linux

3️⃣APP之间的兼容：有的软件两者之间不可以兼容

1.6 易用性测试

许多产品都应用人体工程学的研究成果，是产品在使用起来更加灵活和，舒适。软件产品也始终关注用户体验，让用户获得舒适，易用的体验，针对软件这方面的测试称之为易用性测试。

1️⃣软件设计符合大众的审美

2️⃣软件使用灵活

3️⃣软件设计见明知意

1.6 安装卸载测试

应用的安装和卸载在任何一款APP中都属于最基本功能。一旦出错，就属于优先级为紧要Critical的缺陷。主要需要考虑以下方面：

软件不同的安装和卸载方式；

应用是否可以在不同的环系统，版本下安装（安装兼容性）

安装或者卸载过程中是否可以手动暂停，或者取消

安装空间不足的时候系统是否有提示

是否可以正常的卸载，以及应用软件的各种卸载方式

卸载和安装过程中出现环境问题，软件是否可以正常并且合理的应对，比如死机，断电，断网等

1.7 安全测试

安全性是指信息安全，是指计算机系统或网络保护用户数据隐私，完整，保护数据正常传输和抵御黑客，病毒攻击的能力。安全性测试属于非功能性测试很重要的一个方面，系统常见的安全漏洞和威胁如下：

输入域，如输入恶性或者带有病毒的脚本或长字符串；

代码中的安全性问题，如 SQL/XML 注入

不安全的数据存储或者传递

数据文件，邮件文件，系统配置文件等里面有危害系统的信息或者数据；

有问题的访问控制，权限分配等

假冒 ID ：身份欺骗

篡改，对数据的恶意修改，破坏数据的完整性

安全性测试的方法有代码评审，渗透测试，安全运维等，常用的静态安全测试工具有，Coverity，IBMAppscan Source，HPFortify，常用的动态安全测试有OWASP的ZAP，HP WebInspect等。其中静态安全测试是常用的安全性测试的方法

1.8 性能测试

我们在使用软件的时候有时会碰到软件网页打开时越来越慢，查询数据时很长时间才显示列表，软件运行越来越慢等问题，这些问题都是系统的性能问题引起的。

资源泄露

资源瓶颈

线程死锁，线程阻塞

查询速度慢或效率低

受外部系统影响越来越大

衡量一个系统性能好坏的关键性指标有，用户响时间，事务平均响应时间（TPS），吞吐率，每秒点击次数，内存和CPU使用率等。

1.9 内存泄漏测试

内存泄露是会累积的，只要执行的次数足够多，最终会耗尽所有可用内存，使软件的执行越来越慢，最后停止响应。可以把这种软件的问题比喻成软件的“慢性病”。

分配完内存之后忘了回收。

程序写法有问题，造成没办法回收（如死循环造成无法执行到回收步骤）。

某些 API 函数的使用不正确，造成内存泄露。

人工静态法：代码走读，人工查找未被回收的内存。

自动工具法：借助相应测试内存泄漏的工具，如 Visual Leak Detector ，记录每次内存分配，清楚告诉用户内存是如何泄漏的。

2.按是否查看代码划分

2.1 黑盒测试(Black-box Testing)——不关注代码内部实现，关注测试执行结果是否和预期结果一致

黑盒测试就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当的接收输入数据而输出正确的结果，满足规范需求

黑盒测试的优点：

1️⃣不需要了解程序内部的代码以及实现，不关注软件内部的实现。

2️⃣从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维

3️⃣测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能

黑盒测试的缺点：不可能覆盖所有代码

2.2 白盒测试(White-box Testing)——关注代码内部实现

白盒测试又称为结构测试或逻辑测试，它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试。

白盒测试的测试目的是，通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。

主要包含六种测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

白盒测试的优点：代码覆盖率高

白盒测试的缺点：只关注了代码，但是将模块组合到一起，此时有可能会出现问题

白盒测试和黑盒测试没有哪个好哪个坏，只要适合当前的业务，能够保障软件质量，就是一个好的的是方法

2.3 灰盒测试(Gray-Box Testing)——代码关注，业务上的预期结果和实际结果是否匹配也关注

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。

3.按开发阶段划分

3.1 测试金字塔

3.2 单元测试(Unit Testing)

单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。又称为模块测试

测试阶段：编码后或者编码前（ TDD ）

测试对象：最小模块

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

测试依据：代码和注释 + 详细设计文档

测试方法：白盒测试

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

3.3 集成测试(Integration Testing)

集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。

测试阶段：一般单元测试之后进行

测试对象：模块间的接口

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

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

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

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

3.4 系统测试(System Testing)

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。

测试阶段：集成测试通过之后

测试对象：整个系统（软、硬件）

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

测试依据：需求规格说明文档

测试方法：黑盒测试

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

3.5 回归测试(Regression Testing)

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误

回归测试目的：为了保障修复的模块没有问题，修复了之后没有引入新的问题

在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

3.6 冒烟测试（smoke testing）

冒烟测试：验证软件是否达到了一个测试标准

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件主要功能和核心流程正常，在正式进行系统测试之前执行。冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试时，先进行冒烟测试，保证基本功能正常，不阻碍后续的测试

如果冒烟测试通过，则测试人员开始进行正式的系统测试，如果不通过，则测试人员可以让开发人员重新修复代码直到冒烟测试通过，再开始进行系统测试。

回归测试和冒烟测试都属于系统测试。

3.7 验收测试(Acceptance Testing)

验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求

测试阶段：系统测试通过之后

测试对象：整个系统（包括软硬件）。

测试人员：主要是最终用户或者需求方。

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

测试方法：黑盒测试

测试内容：同系统测试 ( 功能 ... 各类文档等 )

4.按测试实施组织

4.1 α测试(Alpha Testing)

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

4.2 β测试(Beta Testing)

β测试是一种验收测试。β测试由软件的最终用户们在一个或多个场所进行。

4.3 α测试与β测试区别

测试的场景不同：Alpha测试是指把用户请到开发方的场所来测试,β测试是指在一个或多个用户的场所进行的测试。

测试的环境不同：Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中；beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。

4.4 第三方测试

介于开发方和用户方间的组织的测试

5.按是否运行划分

1.静态测试(Static testing) ：所谓静态测试（static testing）就是不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。不以测试数据的执行而是对测试对象的分析过程，仅通过分析或检查源程序的设计、内部结构、逻辑、代码风格和规格等来检查程序的正确性。

2.动态测试(Dynamic testing) ：动态测试（dynamic testing），指的是实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以判断一个测试属于动态测试还是静态的，唯一的标准就是看是否运行程序。

6.按是否手工划分

1.手工测试(Manual testing)：手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。总结优缺点：

优点：自动化无法替代探索性测试、发散思维结果的测试。

缺点：执行效率慢，量大易错。

2.自动化测试(Automation Testing) ：就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。

7.按测试地域划分

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

2.本地化测试：之前我们所讲的全是本地化测试

8.设计测试用例-登陆页面

9.测试用例设计-淘宝购物车