一、测试概述

本文完全参考 https://www.cnblogs.com/lihou...

• 软件测试是为了发现错误而执行程序的过程
• 软件测试的基本原则是尽早地和不断地进行软件测试
  

二、测试分类

1、根据测试方法划分

1.1 黑盒测试

把被测的软件看作是一个黑盒子，我们不去关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出结果。

它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

采用黑盒技术设计测试用例的方法有

• 等价类划分
• 边界值分析
• 错误推测
• 因果图
• 综合策略

1.2 白盒测试

把盒子盖子打开，去研究里面的源代码和程序结果。

它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能够按预定要求正确工作。

1.3 灰盒测试

介于黑盒与白盒测试之间

可以这样理解，灰盒测试关注输入对于输出的正确性，同时也关注内部表现，但这种关注不像白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒方法。

2、根据测试流程/开发阶段划分

• 单元测试

  • 对软件中的基本组成单位进行的测试
  • 目的是检验软件基本组成单位的正确性

• 集成测试

  • 在系统集成过程中所进行的测试
  • 目的是检查软件单位之间的接口是否正确

• 系统测试

  • 对已经集成好的软件系统进行彻底的测试
  • 目的是验证软件系统的正确性和性能等是否满足规约指定的要求

• 验收测试

  • 部署软件之前的最后一个测试操作
  • 目的是确保软件准备就绪，向软件购买者展示该软件系统满足其用户的要求

2.1 单元测试阶段

模块接口测试
通过所测模块的数据流进行测试。调用所测模块时的输入参数与模块的形式参数的个数、属性和顺序是否匹配。

局部数据结构测试
是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，模块的局部数据结构往往是错误的根源。

路径测试
是指对模块中重要的执行路径进行测试。

错误处理测试
比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理，以便一旦程序出错时能对出错程序重新安排，保证其逻辑上的正确性。

边界条件测试
大量的错误是发生在输入或输出的边界上。因此针对各种边界情况设计测试用例，可以查出更多的错误。

2.2 集成测试阶段

在集成测试中，我们主要关注以下内容：

• 把各个模块连接起来，穿越模块接口的数据是否会丢失。
• 各个子模块组合起来，能否达到预期要求的功能。
• 一个模块的功能是否会对另一个模块的功能产生不利影响。
• 全局数据结构是否有问题。
• 单个模块的误差积累起来是否会被放大，从而达到不可接受的程度。

2.3 系统测试阶段

一般系统的主要测试工作都集中在系统测试阶段。根据不同的系统所进行的测试种类也很多，例如：

• 功能测试，是对产品的各功能进行验证，以检查是否满足需求的要求。
• 性能测试，是通过自动化测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能进行测试。
• 安全测试，检查系统对非法入侵的防范能力。
• 兼容测试，主要是测试系统在不同软硬件环境下能否正常的运行。

2.4 验收测试阶段

• 功能确认测试
• 安全可靠性测试
• 兼容性测试
• 易用性测试
• 可扩充性测试
• 资源占用率测试
• 用户文档资料验收

3. 根据测试的侧重划分

3.1 功能测试

功能测试检查实际的功能是否符合用户的需求。

功能测试又可以细分为很多种：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试等。

功能测试
在规定的一段时间内运行软件系统的所有功能，以验证这个软件系统有无严重错误。

易用性测试
从使用的合理性和方便性等角度对软件系统进行检查，发现人为因素或使用上的问题。

安装测试
安装测试的目的不是找软件错误，而是找安装错误。

兼容性测试
这类测试主要想验证软件产品在不同版本之间的兼容性。有两类基本的兼容性测试：

• 向下兼容，测试软件新版本保留它早期版本的功能
• 交错兼容，验证共同存在的两个相关但不同的产品之间的兼容性

恢复测试
证实在克服硬件故障（包括掉电、硬件或网络出错等）后，系统能否正常地进行工作，并不对系统造成任何损害。为此，可采用各种人工干预的手段，模拟硬件故障，并由此检查：

• 错误探测功能（系统能否发现硬件失效或故障）
• 能否切换或启动备用的硬件
• 在故障发生时能否保护正在运行的作业和系统状态
• 在系统恢复后能否从最后记录下来的无错误状态开始继续执行作业等

如果系统的恢复时自动的（由系统自身执行），则应对重新初始化、数据恢复、重新启动等逐个进行正确性评价。如果恢复需要人工干预，就需要对恢复的平均时间进行评估以及判断它是否在允许的范围之内。

文档测试
检查用户文档（如用户手册）的清晰性和精确性。确保叙述正确无误。

可支持性测试
验证系统的支持策略对于公司与用户方面是否切实可行。它所采用的方法是试运行支持过程（如对有错部分打补丁的过程等），对其结果进行质量分析，评审诊断工具、维护或称、内部维护文档；衡量修复一个明显错误所需的平均最少时间。还有一种常用的方法是，在发行前把产品交给用户，向用户提供支持服务的计划，从用户处得到对支持服务的反馈。

互连测试
验证两个或多个不同的系统之间的互连性。这类测试对支持标准规格说明或承诺支持其他系统互连的软件系统有效。

3.2 性能测试

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

软件的性能包括很多方面，主要有时间性能和空间性能两种。

• 时间性能，主要是指软件的一个具体的响应时间。比如一个登陆所需的时间，一个交易所需要的时间等。
• 空间性能，主要指软件运行时所消耗的系统资源。比如硬件资源、CPU、内存、网络带宽消耗等。

性能测试方法是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。通俗地说，这种方法就是要在特定的运行条件下验证系统的能力状态。性能测试特点如下：

1. 主要目的是验证系统是否有系统宣称具有的能力
2. 要事先了解被测试系统经典场景，并具有确定的性能目标
3. 要求在已经确定的环境下运行。

也就是说，这种方法是对系统性能已经有了了解的前提并对需求有明确的目标，并在已经确定的环境下进行的。

负载测试
通过在被测系统上不断加压，直到性能指标达到极限。

这种方法是对一个系统持续不断地加压，看你在什么时候已经超出“我的要求”或系统给崩溃。

1. 主要目的是找到系统处理能力的极限。
2. 需要在特定的测试环境下进行，通常也需要考虑北侧是系统的业务压力量和典型场景、使得测试结果具有业务上的意义。
3. 一般用来了解系统的性能容量或是配合性能调优来使用。

压力测试
测试系统在一定饱和状态下（例如cpu、内存在饱和情况下）能够处理的会话能力，以及系统是否会出现错误。

也就是说，这种测试是让系统处在很大强度的压力之下，看系统是否稳定，哪里会出问题。

1. 主要目的是检查系统处于压力性能下时，应有的表现。
2. 一般通过模拟负载等方法，使得系统的资源使用达到较高水平。
3. 一般用于测试系统的稳定性。

配置测试
配置测试方法通过对被测系统的软硬件环境的调整，了解各种不同配置对系统性能影响的程度，从而找到系统各项资源的最优分配原则。

这种测试关注点是“微调”，通过对软硬件的不断调整，找出它们的最佳状态，使系统达到一个最强的状态。

1. 主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。
2. 一般在对系统性能状况有初步了解后进行。
3. 一般用于性能调优和规划能力。

可靠性测试
在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测是否稳定。

这种测试的关注点是“稳定”，不需要给系统太大压力，只要系统能够长期处于一个稳定的状态。

1. 主要目的是验证是否支持长期稳定的运行。
2. 需要在压力下持续运行一段时间（2~3天）。
3. 测试过程中需要关注系统的运行状况。

测试容量
通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。

并发测试
通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其它性能问题。

这种测试关注点是多个用户同时（并发）对一个模块或操作进行加压。

1. 主要目的是发现系统中可能隐藏的并发访问时的问题。
2. 主要关注可能存在的并发问题，例如系统中的内存泄漏、线程死锁和资源争用方面的问题。
3. 可以在开发的各个阶段使用需要相关的测试工具的配合和支持。

4、根据测试是否使用自动化工具划分

4.1 手工测试

手工测试就是由人去一个一个地去执行测试用例，通过键盘鼠标等输入一些参数，查看返回结果是否符合预期结果。

4.2 自动化测试

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。

自动化测试：又可分为功能自动化测试与性能自动化测试。

我们一般所说的自动化测试就是指功能自动化测试，通过相关的测试技术，通过编码的方式用一段程序来测试一个软件的功能，这样就可以重复执行程序来进行重复的测试。如果一个软件一小部分发生改变，我们只要修改一部分代码，就可以重复的对整个软件进行功能测试。这样就大大的提高了测试效率。

性能自动化测试，除了早期阶段，现在的性能测试工作都是通过性能测试工具辅助完成的。能过工具可以模拟成千上万的用户向系统发送请求，用来验证系统的处理能力。

5、其它测试方法

5.1 冒烟测试

是指在对一个新版本进行系统大规模地测试前，先验证一下软件的基本功能是否实现，是否具备可测试性。

引入到软件测试中，就是指测试小组在正规测试一个新版本之前，先投入较少的人力和时间验证一个软件的主要功能，如果主要功能都没有实现，则打回开发组重新开发。这样做的好处是可以节省大量的时间成本和人力成本。

5.2 回归测试

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

回归测试一般是在进行软件的第二轮测试开始的，验证第一轮中发现的问题是否得到修复。当然，回归也是一个循环的过程，如果回归的问题通不过，则需要开发人员修改后再次进行回归，直到通过为止。

5.3 随机测试

是指测试中的所有输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。

随机测试可以发现一些隐蔽的错误，但是也有很多缺点。比如测试不系统，无法统计代码覆盖率和需求覆盖率，发现的问题难以重现。一般是放在测试的最后执行。其实随机测试更专业的升级版叫探索性测试。

探索性测试是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。

5.4 安全性测试

安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。

安全测试也在越来越受到企业的关注和重视，因为由于安全性问题造成的后果是不可估量的。尤其对于互联网产品最容易遭受各种安全攻击。

5.5 场景测试

针对用户需求内容的测试，称之为场景测试。场景测试首先在系统测试阶段测试通过，然后在用户确认阶段，由用户执行场景测试来进行产品验收。

要做到场景测试，实际上需要从需求开始做起。需求与用户沟通，确认用户的实际场景，然后分析这些场景，并据此设计出产品的解决方案，得到用户使用产品的应用场景，并排列出优先级；然后开发根据场景优先级开发出产品；最后测试根据场景优先级进行测试，并结合软件实际情况，给出拓展场景，给出使用说明，推荐给用户使用。

5.6 辅助功能测试

软件辅助功能测试是指软件测试是否向残疾用户提供足够的辅助功能。

5.7 本地化/全球化测试

确保应用程序的世界通用性需要三个测试阶段：全球化测试、可本地化测试和本地化测试。

• 全球化测试

  • 确保应用程序在任何区域性或区域设置中都能正常运行

• 可本地化测试

  • 验证可以轻松地将程序的用户界面翻译成任何目标语言

• 本地化测试

  • 检查特定目标区域性或区域设置的产品本地化的质量

三、中英文对照表

四、参考链接

• 软件测试常用术语总结