软件测试的分类（补充）

最新推荐文章于 2023-05-30 13:15:00 发布

原创最新推荐文章于 2023-05-30 13:15:00 发布 · 1.1k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#软件测试

软件测试的分类

按测试策略分类
常见测试方法

按测试策略分类

静态测试与动态测试

静态测试的特点

• 静态测试不必动态运行程序，也不必进行测试用例设计和结果判断等工作。
• 静态测试可以由人工进行，充分发挥人的逻辑思维优势。
• 静态测试实施不需要特别的条件，容易开展。

动态测试的特点

通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能

黑盒测试与白盒测试

黑盒测试

• 又称为功能测试、数据驱动测试或基于规格说明书的测试
• 黑盒测试就当整个程序是个黑盒子，我们看不到它里面做了些什么事情，只能通过输入输出看是否能得到我们所需的来测试。

黑盒测试的主要测试方法有

等价类划分法、边界值分析法、因果图法、场景法、正交实验设计法、判定表驱动分析法、错误推测法、功能图分析法等

白盒测试

• 白盒测试称为结构测试或逻辑驱动测试
• 白盒测试是针对被测单元内部是如何进行工作的测试
• 白盒测试可以当盒子是透明的，里面的一切我们都看的清楚，从而我们可以通过去测内部结构来测试

白盒测试的主要测试方法有

静态测试&动态测试、单元测试、代码检查、同行评审、逻辑覆盖、基本路径测试等等

黑盒测试和白盒测试

白盒测试的重点是进行代码覆盖，而黑盒测试着重进行功能、性能的测试。

白盒测试中可能不考虑软件的外在表现特性，往往根据运行的代码来判断测试的结果。而黑盒测试则不关心程序的内部逻辑结构，只提供输入和操作过程，通过软件运行给出的运行结果来判断测试是否通过。

在实践中，单元测试主要是采用白盒测试方法，而除单元测试之外其他阶段的测试则大都采用黑盒测试方法。有时并不能完全区分进行的是哪种测试，往往把两者结合起来会得到更好的测试效果。

灰盒测试

• 是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。
• 灰盒测试关注的是一个模块或模块之间的接口问题

手工测试与自动化测试

手工测试：就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较初级但是必须的一个步骤。
自动化测试：通过将测试执行部分或者全部交由机器执行的一种测试，叫做自动化测试。这种测试不需要人的实时参与。同时这种测试在小规模应用时会比手动测试昂贵许多。
测试自动化：这是一种让测试过程脱离人工的一次变革。对于控制成本，控制质量，回溯质量和减少测试周期都有积极影响的一种研发过程。

自动测试优点

• 对程序新版本运行前一版本执行的测试，提高回归测试效率
• 可以运行更多更频繁的测试，比如冒烟测试
• 可以执行手工测试困难或不可能做的测试，比如大量的重复操作或者性能测试，如处理精确的事务、大数据量事务、并发事务

自动测试局限

• 不能取代手工测试，自动化测试只能提高测试效率，不能提高测试有效性，即不可能发现更多缺陷，手工测试比自动测试发现的缺陷更多
• 对测试设计依赖性极大，测试设计的不好会遗漏问题
• 自动化测试对软件开发具有很大的依赖性，开发上出现变更可能导致前面的自动化测试完全失效
• 工具本身并不具备想象力，工具不具有智能
• 开发、维护脚本工作量大、费用高

适合使用自动化测试的情况

版本稳定、项目周期长、脚本可复用

不适合使用自动化测试的情况

• 定制型项目（一次性的）
• 项目周期很短的项目
• 涉及业务规则复杂的对象
• 关于美观、声音、易用性的测试
• 很少运行的测试
• 测试的软件不稳定
• 涉及物理交互的测试

冒烟测试

冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。冒烟测试也是针对软件版本包进行详细测试之前的预测试，执行冒烟测试的主要目的是快速验证软件基本功能是否有缺陷。如果冒烟测试的测试用例不能通过，则不必做进一步的测试。
• 冒烟测试执行，与正式测试的区别在于二者侧重点不同，冒烟测试关注的是阻塞型缺陷，包括但不限于流程不通、主要功能未实现等，而正式测试则属于全面、细致的测试，需要尽可能的发现全部缺陷并按其严重性进行区分。

冒烟测试过程中，需要注意的是

• 开发协同
• 注重效率
• 评估用例

回归测试

• 过一段时间以后再回过头来对以前修复过的缺陷重新进行测试，看该缺陷是否会重新出现
• 修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误
• 回归测试贯穿整个测试活动，且占据很大的工作量
• 选择回归测试策略应该兼顾效率和有效性两个方面。

常用的选择回归测试的方式包括

• 再测试全部用例
• 基于风险选择测试：选择最重要、最常用、存在风险的功能进行测试
• 基于操作剖面选择测试：操作剖面是操作的集合以及各种使用方式的出现概率
• 再测试修改的部分

回归测试可遵循下述基本过程进行

• 识别出软件中被修改的部分；
• 从原基线测试用例库T中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0。
• 依据一定的策略从T0中选择测试用例测试被修改的软件。
• 如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分。
• 用T1执行修改后的软件。
• 第(2)和第(3)步测试验证修改是否破坏了现有的功能，第(4)和第(5)步测试验证修改工作本身

常见测试方法

功能测试

对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户的要求

性能测试

观察系统在一个给定的环境和场景中的性能表现是否与预期目标一致，评判系统是否存在性能缺陷，并根据测试结果识别性能瓶颈，改善系统性能的完整的过程

负载测试

在一定的软件、硬件及网络环境下，通过改变系统负载方式、增加负载等来发现系统中所存在的性能问题。用于确定系统所能承载的最大用户数、最佳用户数。关注不同用户数下的系统响应时间及服务器的资源利用率

压力测试

在一定的软件、硬件及网络环境下，通过模拟大量的虚拟用户向服务器产生负载，使服务器的资源处于极限状态下长时间连续运行。目的测试服务器在高负载情况下是否能够稳定工作，挖掘系统最脆弱的位置

稳定性测试（可靠性测试）

在一定的软件、硬件及网络环境下，模拟一定数量虚拟用户运行一种或多种业务，长时间的运行（7*24小时)系统。目的是检测系统在长时间运行下的稳定性和性能相关指标是否符合预期

易用性测试

指用户使用软件时是否感觉方便，也称为用户体验测试
• 安装易用性
• 功能易用性
• 界面易用性 https://baike.baidu.com/item/易用性测试
• 辅助系统易用性

界面测试

测试用户界面的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等

测试目标

通过用户界面 (UI) 测试来核实用户与软件的交互。UI测试的目标在于确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。除此之外，UI 测试还要确保 UI 功能内部的对象符合预期要求，并遵循公司或行业的标准。

优秀界面的7要素

符合标准和规范

• 最重要的用户界面要素是软件符合现行的标准和规范
• 苹果的标准在Addison-Wesley出版的《Macintosh Human Interface Guidelines》
• 微软的标准在Microsoft Press出版的《Microsoft Windows User Experience》
• 平台也可能没有标准，也许测试的软件就是平台本身。在这种情况下，设计小组可能成为软件易用性标准的创立者。