软件测试活动常见的这13种类型，作为一名合格的测试工程师，你很有必要了解

根据特定的用户需求关注点、测试目标或测试原因，可以采取针对被测对象特定质量特性的测试活动。一般可分为功能测试、性能测试、负载测试、压力测试、容量测试、安全性测试和兼容性测试等。

【1】功能测试

功能测试验证软件在指定条件下使用时，提供满足明确和隐含功能需求的能力情况。对于一个软件系统而言，用户通常期望该系统完成其特定的业务需求，如完成数据检索、注册登录、商品订购等。

功能测试即验证软件业务需求实现与否的一项测试活动。功能测试主要检查被测对象是否存在以下几种错误：

（1）是否有不正确、遗漏或多余的功能。

（2）是否满足用户需求和系统设计的隐藏需求。

（3）是否对输人做出正确的响应，输出结果能否正确展示。

【案例 OA 系統图书类別管理功能测试】

上述图书类别管理功能从功能测试角度来看，存在以下几个缺陷：

(1）从用户隐性需求来看，图书类别名称添加处未能默认以闪烁光标指引。

(2）从界面设计风格来说，红色*号处的括号应以全角模式显示，与后面“：”对应。

(3）从输入输出的响应来看，类别名称处不应添加 “＜input type=button name=test>”类似的 HTML 代码，避免代码上传攻击。

(4）在第二个“计算机软件测试〞类别处，单击【删除】链接执行删除操作，出现图 5-11所示的脚本错误，未对单引号做转义处理，因此功能实现错误。

【2】性能测试

性能测试通过模拟系统运行业务压力和使用场景组合，验证系统性能是否满足预先定义的性能要求。

性能测试一般有以下3个特点：

1. 主要目的是验证系统是否具有宣称具有的能力

开展性能测试之前，需确定被测系统运行环境以及恰当的测试方法，需有明确的测试计划与目标，根据计划目标，仅验证系统是否具有相应的能力。

2.需了解测试系统典型场景，并具有确定的性能目标

需了解用户业务行为，从用户使用场景着手，确定测试计划，确立测试目标，而不以优化的思路去测试。

3.要求在真实的运行环境下执行

要求测试环境尽可能模拟真实的生产环境，测试结果切忌简单对比类推（可根据数据建模分析），不同测试环境得出的测试结果不同，测试结果仅对当前的测试环境、被测对象负责，无法使用类推方法断言被测系统在其他应用环境中能够表现如何。

性能测试关注被测对象的响应速度、并发数、业务成功率区资源占用情况。常用的性能监控指杯包括并发数、响应时间、吞吐量、TPS 和便件资源耗用等。

性能测试活动可从编码阶段开始实施，如某个函效或类的处理性能、某个循环语向的效率。

在系统测试层面，可模拟用户真实的业务场景，利用性能测试工具完成测试，如 LoadRunner、JMeter 等。下图所示是利用 LoadRunner 实施性能测试活动的示意图：

【3】负载测试

负载测试是指在超过被测对象标准性能负荷指标下，验证系统的负载承受能力，并要求在超负荷时，被测对象依然能够正常实现业务功能。

这种测试类型一般具有以下3个特点：

(1)主要目的是找到系统处理能力极限和性能临界点，便于设定阈值。

(2)在超过被测对象性能负荷情況下实施。

(3)一般用来了解系统性能容量，或者配合性能调优来使用。

负载测试是通过不断对被测对象施加负荷，观察被测对象在不同负载下的性能表现。以举重比费为例，不断增加杠铃的重量，直到超过运动员所能承受的重量，临界点即是运动员可能的最佳举重重量，需要注意的是，负载测试中变化因子是负载（并发用户数、并发请求数等）。

【4】压力测试

压力测试测试被测对象在超过性能指标的饱和状态下，系统处理业务的能力情况，以及系统是否会出现错误。

压力测试一般具有以下几个特点：

(1）主要目的是检查被测对象在峰值情况下应用的表现。

(2）一般使用负载测试的思想实施压力测试，持续关注被测对象持续服务的能力。

(3）一般用于系统的稳定性测试。

压力测试关注被测对象在超过性能负荷的情况下，特续提供服务的能力。例如，500个并发，持续运行24小时等。

与负载测试不同，压力测试更强调被测对象在特定负载下持续运行、持续提供稳定服务的能力，更关注稳定性。例如，在举重比赛中，运动员举起150kg的杠铃维持稳定姿势3s。150kg的杠铃是负载，而3s则是持续的周期，负载测试关注的是不同负载，压力测试关注的是不同周期。

【5】容量测试

容量测试验证被测对象承受超额数据容量时，正确处理业务请求的能力。容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量，如并发用广数、数据库记录、存储文件数等。

对于存储类管理系统，可能需测试数据库记录区文件存储情况，如x雷、y酷等软件系统。对于交易类系统，可能需要测试并发用户数及数据库记录等容量指标。

容量测试也可作为性能测试的一个考察点，实际上容量测试、负载测试、压力测试都可作为性能测试的测试策略，共同发现被测对象响应速度、资源耗用方面的问题。

【6】安全测试

安全测试验证被测对象的安全保护机制能否在实际应用中保护系统不受非法侵入，用来保证系统本身数据的完整性和保密性。例如，受到恶意攻击时，被测对象的自我保护能力、病毒防护能力、自定义通信协议安全性等。

针对电子商务、金融证券类的系统，安全测试尤为重要，通常从系统登录、用户权限管理、系统数据非法读取、访问请求加密解密、通信协议安全等。安全测试可使用人工数据验证的方法，也可使用安全测试工具进行，如 APPSCAN、 X5S、NBSI 等。

下图所示即为NBSI网站漏洞扫描工具：

【7】兼容性测试

不同的转件设计方法、繃程方法和运行环境可能会导致无法兼容的现象，在多用户多平合的应用环境中，可能需要进行兼容测试。

兼容测试验证对测对象与硬件、其他软件之间的兼容情况。对于 web 类系统而言：兼容性主要考虑不同浏览器、不同分辨率的显示及应用情况。对于 C/S结构的系统，一般考虑操作系统、配套软件及分辦率等方面的兼容性问题。

【8】可靠性测试

可靠性测试是验证被测对象在规定时间、规定环境条件下，实现规定功能或性能的能力。测试被测对象的可靠性是指运行应用程序，发现其存在的缺陷或可能引发的失效风险，尽可能在系统部署前发现并修复缺陷，降低失效风险。

可靠性测试主要有组件压力测试、集中压力测试、真实环境测试、随机破坏测试这4种方法，衡量可靠性的指标有平均故障间隔时间 ( Mean Time Between Failare, MTBF） 及平均故障修复时间(Mean Time To Repair, MTTR)。 MTBF 越长越好，MTTR 越短越好。

【9】可用性测试

ISO/TEC 9126-1 软件质量将可用性定义为 〝在特定使用情景下，软件产品能够被用户理解、学习、使用，能够吸引用户的能力”。

可用性提出，用户可以在短时间内使用系统完成相关任务；用户学会使用系统后，能够高效率地使用系统；用户在一段时间没有使用系统后，仍然能修使用系统；用户使用系统时能够少出错，系统必须防止灾难性错误发生；用户使用系统主观上感到满意。这些是执行可用性测试的关注点。

可用性测试一般由两类人实施，一是行业或特定领域内的专家；二是合适的软件系统终端用户。实施时，先定义测试对象及测试目标，然后安装测试环境，由合适的测试工程师进行测试和输出测试报告。

【10】 移植测试

软件移植性是指软件产品能否顺利地移植到新的硬件或软件平合上，移植之后，软件仍能满足用户需求。

在现有业务系统中，软件应用范围非常广泛，软件可移植性已成为衡量软件产品质量的一个非常重要的指标。例如，现在手机平台上的 App 应用，可能会面临不同的使用环境。不同手机厂商深度定制的系统，如联想乐OS、小米MIUI，App在设计开发时需考虑移植性。

实施过程中，从适应性、易安装性、共存性、易替换性等方面进行考虑。

【11】维护测试

维护测试是指软件系统在部署运行交付使用后，在实际使用过程中，因改正错误或需求变更而引发的确认验证测试活动。根据引起软件维护的原因，维护测试可分为 4 种类型：改正性维护测试、移植性维护测试、完善性维护测试、预防性维护测试等。

1．改正性维护测试

软件系统在运行维护过程中，发现了在系统测试过程中未能发现的错误，开发工程师诊断和改正这些隐蔽错误修改软件后，需进行改正性维护测试活动，重点关注缺陷是否已经成功修复并未引发新的问题。

2．移植性维护测试

软件系统因使用环境变化或系统应用护展，需要从一个平台移植到另一个平台，或者系统数据迁移时，需执行移植性维护测试，重点关注移植后的系统能否仍然满足用户需水。

3.完善性维护测试

软件在使用一段时间后，因扩充和完善原有软件的功能或性能，开发工程师需要修改软件，修改后需要进行完善性维护测试，重点关注新增或变更的功能或性能是否成功实现。

4.预防性维护测试

需要重新构建，或可能存在特定风险时，开发工程师对软件系统进行修改，修改后需进行预防性维护测试，重点关注预定义的扩展或风险防范是否实现。

在维护测试实施过程中，对于未做修改或变更的地方，同样需要进行回归，避免因维护活动带来的风险。执行维护测试的测试工程师需了解需求规格或业务知识，否则测试周期变长、测试效果下降。

测试工程师发现缺陷，开发工程师进行修复，生成新的版本时，测试工程师需要确认是否已经成功修复了该缺陷。这个测试过程称为确认测试。

当给定测试周期短或者缺陷严重度较低时，在充分评估测试风险后，可仅执行确认测试。确认测试仅验证修改对象是否已成功修复，不关注该缺陷修改活动衍生问题。

【13】回归测试

回归测试是对已被测试过的程序在修复缺陷后进行的重复测试，目的是验证修复缺陷没有引发新的缺陷或问题。

在修复缺陷过程中，可能因开发修改活动引发新的缺陷，或者导致本可能发生的缺陷被屏蔽掉，增加了风险。回归测试的规模可根据修改缺陷的范围及风险大小来确定。

回归测试策略有完全回归和选择性回归两种。完全回归需执行被测对象的所有用例，不仅执行缺陷对应的用例。选择性回归包括基于风险回归、基于操作剖面回归和缺陷覆盖回归。

(1）基于风险回归，是指可根据项目或产品的风险大小，确定回归用例。除了确认缺陷是否成功修复外，还要执行风险较高的用例。

(2）基于操作剖面回归，是指根据项目或产品功能或业务的使用频率确定回归用例，除了确认缺陷是否成功修复外，还要执行使用频率高的功能或业务。

(3）缺陷覆盖回归，仅回归己修复缺陷对应的用例，此种方法适用于经过风险分析后的被测对象。

在实际的回归测试过程中，确以测试与回归测试往在一起执行。

软件测试面试刷题

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!