软件测试流程

最新推荐文章于 2021-05-30 20:30:15 发布

liyi_999

最新推荐文章于 2021-05-30 20:30:15 发布

阅读量808

点赞数

本文链接：https://blog.csdn.net/liyi_999/article/details/111563337

版权

本文详细介绍了软件测试的各个阶段，包括单元测试、集成测试和系统测试，强调了它们的目的、好处与不足。此外，还探讨了软件测试的分类，如静态测试、动态测试、黑盒测试和白盒测试，以及常见的测试方法，如功能测试、性能测试和兼容性测试。文章最后讨论了优秀界面的7要素，包括符合标准、直观性、一致性等，以提升用户体验。

摘要由CSDN通过智能技术生成

软件测试阶段

单元测试

定义：单元测试又称为模块测试，是最小单位测试

单元测试具有独立性，可以与系统其他部分分隔离出来，从而完成测试，其依据是详细设计
测试对象

其测试对象是软件设计的最小单位模块与组件，类、文件、窗口、函数、菜单、报表或一个存储过程都可以作为一个单元进行测试

单元测试可以发现的缺陷类型：

计算错误
需求或功能遗漏
程序路径选择错误

执行方法：

代码扫描工具：SonarQube + PMD

测试原则

尽可能保证测试用例相互独立（测试用例中不能直接调用其他类的方法，而应在测试用例中重写模拟方法）
此阶段一般由软件的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求

单元测试的好处

尽早的发现缺陷
利于重构
简化集成

单元测试的不足

不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误
每行代码需要3~5行代码进行单元测试，存在投入与产出的平衡

集成测试

定义

是将已分别通过测试的单元按设计要求组合成系统或子系统，再进行的测试。目的在于检查这些单元之间的接口是否存在问题。

测试目标：API

对集成的组件之间的接口和组件与组件的协同工作进行测试。

测试依据

软件和系统设计文档
系统架构
定义和描述接口的文档、工作流和用例等

执行方法

工具：Postman
自动化测试框架：python + requests + ddt + nose2

测试原则

尽早集成测试关键模块
尽早测试包含I/O的模块

集成测试的好处

可以检查一系列的环境配置正确与否
可以迅速定位BUG
可以为功能测试和性能测试提供支持

集成测试的不足

难以完成业务场景测试
无法测试前端页面

系统测试

定义：是充分运行软件系统，以验证系统是否满足产品的质量需求

系统测试分为：功能测试、非功能测试
非功能测试

性能测试、容量测试
安全性测试
兼容性测试
可靠性测试

集成测试和系统测试之间的比较

测试内容：集成测试是测试各个单元模块之间的接口，系统测试是测试整个系统的功能和性能；
测试角度：集成测试偏重于技术的角度进行测试，系统测试是偏重于业务的角度进行测试。

验收测试

定义

也称交付测试，是针对用户需求、业务流程进行的正式的测试，以确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。

验收测试一般会根据产品产品需求（用户故事），严格的逐项的检查产品，确保所开发的软件产品符合用户预期的各项要求。

软件测试的分类

按测试策略分类

静态测试与动态测试特点

静态测试特点

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

动态测试特点

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

黑盒测试

定义：又称为功能测试、数据驱动测试或基于规格说明书的测试

黑盒测试就当整个程序是个黑盒子，我们看不到它里面做了些什么事情，只能通过输入输出看是否能得到我们所需的来测试。

主要测试方法

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

白盒测试

定义：白盒测试称为结构测试或逻辑驱动测试

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

主要测试方法

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

黑盒测试和白盒测试区别

白盒测试的重点是进行代码覆盖，而黑盒测试着重进行功能、性能的测试。
白盒测试中可能不考虑软件的外在表现特性，往往根据运行的代码来判断测试的结果。而黑盒测试则不关心程序的内部逻辑结构，只提供输入和操作过程，通过软件运行给出的运行结果来判断测试是否通过。
在实践中，单元测试主要是采用白盒测试方法，而除单元测试之外其他阶段的测试则大都采用黑盒测试方法。有时并不能完全区分进行的是哪种测试，往往把两者结合起来会得到更好的测试效果。

灰盒测试

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

手工测试与自动化测试

手工测试：就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较初级但是必须的一个步骤。
自动化测试：通过将测试执行部分或者全部交由机器执行的一种测试，叫做自动化测试。这种测试不需要人的实时参与。同时这种测试在小规模应用时会比手动测试昂贵许多。
自动测试优点：

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

自动测试局限：

*> 不能取代手工测试，自动化测试只能提高测试效率，不能提高测试有效性，即不可能发现更多缺陷，手工测试比自动测试发现的缺陷更多

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

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

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

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

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

测试自动化

这是一种让测试过程脱离人工的一次变革。对于控制成本，控制质量，回溯质量和减少测试周期都有积极影响的一种研发过程。

冒烟测试

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

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

回归测试

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

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

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

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

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

常见测试方法

功能测试

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

性能测试

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

负载测试：在一定的软件、硬件及网络环境下，通过改变系统负载方式、增加负载等来发现系统中所存在的性能问题。用于确定系统所能承载的最大用户数、最佳用户数。关注不同用户数下的系统响应时间及服务器的资源利用率。
压力测试：在一定的软件、硬件及网络环境下，通过模拟大量的虚拟用户向服务器产生负载，使服务器的资源处于极限状态下长时间连续运行。目的测试服务器在高负载情况下是否能够稳定工作，挖掘系统最脆弱的位置。
稳定性测试（可靠性测试）：在一定的软件、硬件及网络环境下，模拟一定数量虚拟用户运行一种或多种业务，长时间的运行（7*24小时)系统。目的是检测系统在长时间运行下的稳定性和性能相关指标是否符合预期。