测试方法

软件测试阶段划分

单元测试

单元测试（Unit Testing，简称UT）是对软件基本组成单元（函数或类）进行检测的测试工作。其目的是检测与详细设计说明书（Low Level Design，简称LLD）的符合程度。

集成测试

集成测试（Integration Testing，简称IT）是在单元测试的基础上，将所有的模块按照设计的要求进行集成，主要验证组装后的功能以及模块之间的接口是否正确安装的测试工作。主要目的是检测软件与概要设计说明书（High Level Design，简称HLD）的符合程度。集成测试的主要工作是测试模块之间的接口，但是接口测试不等于集成测试，这是个以面盖点的问题。比如，可以说北京是中国的城市，但不能说中国的城市就是北京。

集成测试工具

能够直接用于集成测试的测试工具不是很多，一般来说，一些通用的商用测试工具由于需要满足一定的通用性，因此在实际使用的时候功能是有限的，大部分工具需要进行二次开发。集成测试主要关注接口的测试，常用的接口测试工具：Postman、HTTPRequest、jmeter等。

系统测试

系统测试（System Testing，简称ST）是将已经通过集成测试的软件系统，与计算机硬件、外设、数据库、网络等其他元素结合在一起，在实际运行环境下，进行的一系列的测试工作。
系统测试通常是由独立的测试团队来完成，其测试的主要依据是需求规格说明书。

系统测试的类型主要有：

功能测试

功能测试是系统测试中最基本的测试，它不管软件内部的实现逻辑，主要根据产品的需求规格说明书和测试需求的列表，来验证产品的功能实现是否符合产品的需求规格。特别要注意的是一些隐含功能的需求。功能测试主要检查被测试对象是否存在以下几种错误：

是否有不正确、遗漏的或多余的功能。
功能实现是否满足用户的需求和系统设计的隐藏需求。

对输入是否做了正确的响应，对输出结果是否做了正确的显示。
对系统的流程设计是否正确、合理。

所有的功能是否达到全覆盖。

性能测试

性能测试是指在一定软件、硬件及网络环境下，对系统的各项性能指标来进行测试，主要检测其性能特性否满足特定的性能需求。常用的性能指标包括并发数、响应时间、每秒处理的事务数、吞吐量、点击率、访问量以及硬件资源等。

性能测试需要从以下两个方面考虑：

验证系统实现的性能是否与性能需求完全一致。
检测系统实现的具体性能到底怎么样。

压力测试

压力测试也称强度测试，也是性能测试的一种，是指在极限状态下，长时间或超大负荷地连续运行的测试，主要检测被测系统的性能、可靠性、稳定性等。

压力测试检的目的是检查系统在资源超负荷的情况下的抗压能力。

压力测试的基本步骤如下：

进行简单的多任务测试。
在简单压力缺陷被修正后，增加系统的压力直到系统中断。

容量测试

容量测试是指检查当系统运行在大量数据，甚至最大或更多的数据测试环境下，系统是否会出问题。还可以看作系统性能指标中一个特定环境下的一个特定性能指标，即设定的界限或极限值。容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。

进行容量测试一般可以通过以下几个步骤来完成：

首先分析系统的外部数据源，并对数据进行分类；
对每类数据源分析可能的容量限制，对数据类型分析记录的长度和数量限制；

对每类数据源，构造大容量数据对系统进行测试；
分析测试结果，与期望值进行比较，最后确定系统的容量瓶颈；

对系统进行优化并重复上面的步骤，直到系统达到期望的容量处理能力。

安全性测试

安全测试是用来验证系统内的保护机制是否能够在实际应用中保护系统不受到非法的侵入。该测试用来保护系统本身数据的完整性和保密性。随着互联网的发展，安全测试尤为重要，特别是一些金融类的产品，往往都把安全放到首位。

兼容性测试

兼容性测试是指检查软件在一定的软硬件、数据库、网络、操作系统环境下是否可以正确地进行交互和共享信息。兼容性测试的策略有向下兼容、向上兼容、交叉兼容。

兼容性测试一般考虑以下几点：

软件本身能否向前或向后兼容，即不同版本之间的兼容。
软件能否与其他相关软件的兼容。

软件在不同的操作系统上兼容。
数据的兼容性，主要是指数据能否共享等。

硬件上的兼容性，如手机APP软件需要考虑不同品牌的手机。

配置测试

配置测试主要是指测试系统在各种软硬件配置、不同的参数配置下系统具有的功能和性能。配置测试并不是一个完全独立的测试类型，需要和其他测试类型相结合，如功能测试、性能测试、兼容性测试等。

通常配置测试的可以分为服务器端和客户端的配置测试。

服务器端的配置需要考虑服务器的硬件、Web服务器、数据库服务器等。
客户端的配置需要考虑操作系统、浏览器、分辨率、颜色质量等。

异常测试

异常测试是指通过人工干预手段使系统产生软、硬件异常，通过验证系统异常前后的功能和运行状态，达到检测系统的容错、排错和恢复的能力。它是系统可靠性评价的重要手段。

通常异常测试关注的要点如下:

强行关闭软件的数据库服务器或者用其他方式导致数据库死机。
非法删除或修改数据库中的表数据或者表。

断开网络或者人为增加网络流量。
强行重启软件的web服务器或者中间件服务器，测试系统的恢复能力。

通过人为手段，增加cpu、内存、硬盘等负载进行测试。
对部分相关软件测试机器进行断电测试。

安装测试

安装测试就是确保该软件在正常情况和异常情况的不同条件下，都能进行安装。安装系统是开发人员的最后一个活动，通常在开发期间不太受关注。

在进行安装测试时需要关注以下3点：

安装前测试：首先要检查安装包文件以及安装手册是否齐全，其次关注是否有权限以及空间进行安装，还需要考虑杀毒软件和防火墙的影响。
安装中测试：主要是安装流程的测试以及检查安装时文件、注册表、数据库的变动。

安装后测试：主要检查安装好的软件是否能正常运行，基本功能是否可以使用。

网络测试

网络测试是在网络环境下和其他设备对接，进行系统功能、性能与指标方面的测试，保证设备对接正常。网络测试考察系统的处理能力、兼容性、稳定性、可靠性以及用户使用等方面。网络测试的关注点如下：

功能方面需要考虑的是协议测试和软件内的网络传输与架构。
性能方面需要考虑网络吞吐率和网络I/O占有率等。

安全性则考虑网络传输加密，常用的加密方式有MD5和RSA加密。
网络技术上对网络数据收集、分析，常用网络监控工具有Wireshark，Fiddler，Charles等。

可用性测试

可用性测试和可操作性测试有很大的相似性，它们都是为了检测用户在理解和使用系统方面是否满意。这包括系统功能、系统发布、帮助文档和过程，以保证用户舒适的和系统交互。在实际测试的时候，通过观察有代表性的用户，完成产品的典型任务，而界定出可用性问题并解决这些问题。它的目的就是让产品用起来更容易。

可用性测试的难点在于可用性有时候比较难以量化，因此可用性测试通常而言由行业专家或用户来进行。行业专家结合自己对行业和用户的了解来进行测试。在系统测试中，需要结合一些经验进行分析，要针对一些容易量化的特性进行检查，如：菜单级数、快捷键的使用和网站导航等。

健壮性测试

健壮性测试有时也叫容错性测试（Fault ToleranceTesting），主要用于测试系统在出现故障时，是否能够自动恢复或者忽略故障继续运行。为了使系统具有良好的健壮性，要求设计人员在做系统设计时必须周密细致，尤其是在系统的异常处理方面。即一个健壮的系统是设计出来的而不是测试出来的。

健壮性有两层含义：一是容错能力，二是恢复能力。

容错性测试：通过构造不合理的输入来引诱软件出错，如输入错误的数据类型、输入定义域之外的数值等。
恢复性测试：重点考察系统能否重新运行、有无重要的数据丢失、是否毁坏了其他相关的软、硬件。

文档测试

文档测试的目标是验证用户文档是否正确的并且保证操作手册的过程能够正确工作。主要针对系统提交给用户的文档的验证。文档测试有助于发现系统中的不足并且使得系统更可用。因此文档的编制必须保证一定的质量，通常考虑有以下几点：

针对性：分清读者对象，按不同类型、层次的读者，决定怎样适应他们的需要。
精确性：文档的行文应当十分确切，不能出现多义性的描述。

清晰性：文档编写应力求简明，适当可以配图表以增强其清晰性。
完整性：任何一个文档都应当是完整的、独立的、自成体系的。

灵活性：各个不同软件项目，其规模和复杂程度有着许多实际差别，文档测试应灵活应对。

验收测试

验收测试是部署软件应用之前的最后一个测试操作。是以用户为主的测试，软件开发人员和软件质量保证人员也应参加。由用户参与测试用例的设计，通过用户界面输入测试数据，并分析测试的输出结果，一般使用生产实践中的实际数据进行测试。在测试过程中除了考虑功能和性能外，还应对软件的兼容性、可移植性、可维护性、可恢复性以及法律法规、行业标准进行测试。

验收测试可分为正式验收和非正式验收2种。

正式验收就是用户验收测试（UAT）
非正式验收包括α测试和β测试

UAT测试

UAT（User Acceptance Test），也就是用户验收测试或用户可接受测试。它是系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试，由系统管理性和防御性控制。

因为测试人员并不了解用户用什么样的手段和思维模式进行测试。所以UAT主要是要求用户参与测试流程，并得到用户对软件的认可，鼓励用户自己进行测试设计和进行破坏性测试，充分暴露系统的设计和功能问题，显然，用户的认可和破坏性测试是难点。

α测试

α（Alpha）测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试是在受控制的环境下进行的测试，即软件在一个自然设置状态下使用，开发者坐在用户旁边，随时记下错误情况和使用中的问题，主要目的是评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能等），尤其注重产品的界面和特色。α测试人员是除产品研发人员之外最早见到产品的人，他们提出的功能和修改建议是很有价值的。

β测试

β（Bate）测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。与α测试不同的是，β测试时开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试过程中，由用户记录下遇到的所有问题，包括客观的和主观认定的，定期向开发者报告，开发者在综合用户的报告后做出修改，再将软件产品交付给全体用户使用。

回归测试

回归测试主要指软件在测试或其他活动中发现的缺陷经过修改后，重新进行测试，目的是验证修改后缺陷是否得到了正确的修复，同时还要关注有没有引入新的缺陷或导致其他代码产生缺陷或错误。

冒烟测试

在大部分软件测试工作中，单元测试与集成测试是由开发工程师完成的，而系统测试是由软件测试工程师完成的。为了提高软件测试工程师测试的有效性，当软件测试工程师拿到开发工程师提交的版本后，就需要进行一次冒烟测试。冒烟测试主要指测试软件版本中的主要功能是否实现，速度很快，一般一到两个小时即可完成。夸张地说，抽一根香烟的时间就可以完成测试。还有一个说法来源于硬件测试，一般硬件组装完毕，上电后，如果电路出现冒烟故障，则不必进行更深入的测试。在软件测试中，如果冒烟测试没有通过，就需要返回给开发工程师重新修改后再测试。

A/B测试

A/B测试本质上是使用数据来驱动决策。关于一个决策（例如，登录页面的设计，注册引导方式或者后端算法服务），传统方式更倾向于根据主观经验进行决策，但是经验并不一定是完全正确的，且一旦决策失误会影响到用户体验，导致损失大量用户。而A/B测试就是用于辅助决策的，我们通过分析A/B测试的结果，设计处两个甚至多个版本，按照线上或者其它方式对多个版本进行划分，最终通过客户反馈效果或者收益大小来决定使用哪个版本。

A/B测试有着广泛的应用，那么为什么要在上线新产品或者新服务的时候进行A/B测试呢？

降低经验注意决策的风险。
降低开发维护成本。

缩短项目周期。

软件测试流程

1、测试流程

一：需求分析了解熟悉业务，分析需求测试点

确认功能(业务功能，辅助功能，数据约束，易用性需求，编辑约束，参数需求，权限需求，性能约束）

场景分析（考虑场景调用者和系统内部各个场景之间联系）

挖掘隐性需求（常用业务流程以及各分支）

2、测试计划

编写目的

此文档根据项目需求文档，制定测试策略、评估测试风险，确定所需的资源，并对测试的工作量进行估计，进行人员和进度安排，并且列出测试项目的可交付元素。

参考文档：详细设计文档，设计原型

测试概要

（1）测试目标

通过测试，达到以下目标：

测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确。

产品规定的操作和系统运行稳定。

Bug数和缺陷率控制在可接收的范围之内，遗留BUG一般不超过所有BUG的10%

（2）测试范围

列出测试最终需要交付的功能模块列表

（3）测试人力资源

（4）测试环境：服务器环境，终端环境，网络环境

（5）bug管理工具

测试规范

开始测试标准：代码编译通过，软件可以争取安装运行，实现功能与产品设计出人，冒烟测试通过

中断测试标准：安装无法正确完成，程序代码编译不通过，系统服务异常，发现阻塞功能的bug

bug规范

一级致命，二级严重，三级一般，四级建议

3、测试策略

冒烟测试：依据开发提测时间变动

第一轮功能测试：执行测试用例，包括边界值测试，兼容性测试，易用性测试，用户界面测试，安全性测试

第二轮功能测试：bug复测及功能验证

回归测试：全面回归测试

性能测试：需确认具体性能测试方案和工具

发布测试

测试报告总结

测试风险

测试本身（测试时间/测试技术/开发进度延误/难以修复缺陷/其它原因）

测试输出文档

测试计划

测试用例

测试bug单

测试报告

4：测试用例

测试需求分析和业务流程分析

设计方法：

等价类划分法（将测试的范围划分成几个互不相交的子集）

边界值分析法（选出的测试用例，应选取正好等于、刚刚大于、刚刚小于边界的值）

错误推测法（在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误）

判定表法（适合于逻辑判断复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判断清晰的策略）

正交实验法（在各因素互相独立的情况下，设计出一种特殊的表格，找出能以少数替代全面的测试用例）

还有其它场景法和状态迁移法等

测试用例八要素：用例编号，测试项目，测试标题，重要级别，预置条件，测试输入，操作步骤，预期输出

（1）用例编号（规则：由字符和数字组成的字符串，具有唯一性，易识别性）

（2）测试项目（对应测试用例编号中的测试子项名系统测试

（3）测试标题（体现测试出发点关注点以及测试用例期盼的测试结果）

（4）重要级别、优先级别（重要级别一般分为高中低）

（5）预置条件：测试用例在执行时需要满足一些前提条件，环境的设置

（6）测试输入（测试执行中需要加工的外部信息，避免用描述性语言，要具体，根据测试用例具体情况，有手工输入，文件，数据库记录）

（7）操作步骤：执行当前用例需要经过的操作步骤，需要明确的给出每一个步骤的描述

（8）预期输出：需要判断测试对象是否正常工作

5、测试执行

测试环境搭建

测试环境：硬件环境，软件环境

硬件环境：测试必须的服务器，客户端，网络连接设备，以及打印机/扫描仪等辅助硬件设备构成的环境

软件环境：被测软件运行的操作系统，数据库以及其它应用软件构成的环境

搭建测试环境的准备工作：

安装工具：虚拟机

虚拟机优点：运行在主机上

执行测试用例

根据测试用例优先级来执行测试用例

测试执行流程：冒烟测试-迭代测试（先功能后性能，回归测试）-发布测试

注：对应测试产出对应测试报告和bug清单，并将bug提到缺陷管理库里

6、测试文档

测试报告

测试结论（是否达到发布标准，是否可发布）

已知风险、未知风险

测试时间，测试人员（测试起止时间）

测试环境，测试设备（用到哪些测试收集，客户端环境，浏览器）

需求大纲（当前这个版本，包含哪些需求点）

Bug数据分析（从多个维度分析：bug等级分布，遗留bug分析，bug类型分布。模块bug分布，bug激活次数分析）

测试总结（从测试角度，对版本存在的问题，提出建议）

bug清单报告

分析统计bug迭代生命周期

bug迭代修复情况（折线图）

未关闭bug按严重等级或状态统计（扇形图）

另附：

bug描述：

（1）bug标题（问题描述）

（2）bug测试环境（所属版本，所属模块）

（3）bug优先级

（4）bug类型

（5）可重复性（是否好复现）

（6）操作步骤（通过对什么样的操作，进行了什么样的步骤）

（7）预期结果

（8）实际结果

最好配带截屏图片

7、回归测试的策略

假如XYC邮箱的测试工作已完成，Bug已全部修复，并已达到上线标准。接下来就以XYC邮箱为例来回顾一下XYC邮箱回归测试的基本流程

下面对以上流程图进行一个简要说明。

（1）开发人员把最初开发出来的XYC邮箱命名为XYC邮箱V1.0版本。测试人员就会针对XYC邮箱V1.0版本进行第一轮测试。第一轮测试执行完成后，测试人员一共发现了100个Bug，其中存在多个严重问题，XYC邮箱无法达到上线标准。

（2）开发人员随后对XYC邮箱V1.0版本的这100个Bug进行修复。Bug修复完成后，就把修复后的软件命名为XYC邮箱V1.1版本，以区别V1.0版本。接着测试人员就会在V1.1版本上进行第二轮的回归测试以验证开发人员是否修复了这100个Bug，结果发现100个Bug中有15个Bug并没有修复好，另外还新引入了25个Bug，相当于XYC邮箱V1.1版本还存在40个Bug，且存在多个严重问题，故达不到上线标准。

（3）开发人员随后对XYC邮箱V1.1版本上的这40个Bug进行修复，Bug修复完成后，就把修复后的软件命名为XYC邮箱V1.2版本，以区别V1.1版本。接着测试人员就会在V1.2的版本上进行第三轮的回归测试以验证开发人员是否修复了这40个Bug，结果发现40个Bug中有2个Bug并没有修复好，另外还新引入了10个Bug，相当于XYC邮箱V1.2版本存在12个Bug，且存在1个严重问题，故达不到上线标准。

（4）开发人员随后对XYC邮箱V1.2版本的这12个Bug进行修复，Bug修复完成后，就把修复后的软件重新命名为XYC邮箱V1.3版本，以区别V1.2版本。接着测试人员就会在V1.3的版本上进行第四轮的回归测试以验证开发人员是否修复了这12个Bug，结果发现仅有2个Bug存在，且这2个Bug都是建议性的问题，并不影响用户对功能的使用和体验，达到上线标准，此时XYC邮箱V1.3版本就可以上线让用户使用了。

以上展示的就是一个回归测试的基本流程，从中可以看到：

（1）即使上一轮的Bug被修复了，在下一轮的测试中还可能发现新的Bug，并不是说上一轮的Bug修复好了就不会再出现其他问题了；

（2）软件测试并不是测试一轮就完成了，一般情况下，一个软件产品可能需要经过多轮反复测试和验证才能达到上线标准。

回归测试的基本策略

回归测试的策略一般由测试经理或测试组长制定，初级软件测试人员只要按相应的策略执行测试即可。现以XYC邮箱的测试为例，简要介绍一下回归测试的基本策略。

（1）回归测试时执行全部的测试用例。
XYC邮箱V1.0版本的第一轮测试中发现100个Bug，那么在第二轮的回归测试中，除了测试这100个Bug之外，其他所有功能点的测试用例需要重新再执行一遍，这样做的原因在于，回归测试的V1.1版本是在修改了V1.0版本存在的100个Bug的基础上建立起来的。由于修复了大量的Bug，这就意味着要改动大量的代码，当多处代码被改动后谁也不能保证其他功能点不受影响，所以对所有的功能点进行测试是比较保险的，也是比较周密的，不会遗漏任何的测试点。使用此策略的时间周期和人力成本也是比较高的，一般情况下，当第一轮测试发现的Bug数量过多的情况下，第二轮回归测试应该执行全部的测试用例。

（2）选择重要的功能点、常用的功能点、与Bug相关联的功能点进行回归测试。

XYC邮箱的第二轮回归测试中又发现了40个Bug，那么在第三轮的回归测试过程中，除了要测试这40个Bug之外，还应当把重要的功能点、常用的功能点、与Bug相关联的功能点的测试用例再执行一遍，其他次要的测试用例可在时间充足的情况下选择性执行。

（3）选择性执行关键功能点的测试用例。

XYC邮箱的第三轮回归测试中又发现了12个Bug，那么在第四轮的回归测试过程中，除了测试这12个Bug之外，还可以选择性地执行一些关键功能点的测试用例，其他测试用例可在时间充足的情况下选择性执行。

（4）仅测试出现Bug的功能点。

如果测试组认为软件的功能点已经十分稳定了，回归测试的时候可选择仅测试出现Bug的功能点。每个策略都有其适应的场

测试基础--测试方法相关推荐

测试基础-测试方法及测试过程
一.测试方法自动化脚本编写以及后期维护需要花大量的时间投入,什么一般来说,项目周期长.需求稳定的项目比较适合做自动化测试二.测试过程(包括测试阶段和回归测试) 1.测试阶段 2.回归测试(不属于软 ...
【转载】探索式测试基础系列—生活进阶曲
在探索式测试落地实践中奏出了协奏曲后进入到高级阶段,如何在问题定位和经验积累中发挥作用,也可以理解为在生活达到非常和谐后,如何孕育一个后代并为其提供良好的环境,因此本章的名字叫做生活进阶曲,表明在本章 ...
《软件测试技术大全：测试基础流行工具项目实战(第3版)》—第1章1.2节软件测试的发展...
本节书摘来自异步社区<软件测试技术大全:测试基础流行工具项目实战(第3版)>一书中的第1章,第1.2节软件测试的发展,作者陈能技 , 黄志国,更多章节内容可以访问云栖社区"异 ...
软件测试 - 测试基础知识
软件测试知识整理软件测试使用人工或自动手段,来运行或测试某个系统的过程.其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别. 贾祥玉软件测试常用术语 1. ...
视频测试基础知识--视频算法DMOS和PPSNR--视频参考与无参考测试介绍
视频测试基础知识--视频算法DMOS--视频参考与无参考测试介绍测试则从传统的静态.单帧像分析,转换为动态测试.图像质量分析. 虽然单帧像分析可提供信号定时.色深.线条同步化,以及更多有用信息,但压 ...
软件测试体系学习及构建（13）-测试基础之测试工程师的基本要求
(13)-测试基础之测试工程师的基本要求 1 软性能力 1.1 沟通表达能力 1.2 逻辑思维能力 1.3 原则和立场 1.4 情绪管理 1.5 抗压性 1.6 学习成长 1.7 时间管理 1.8 问 ...
软件测试整理一：测试基础知识以及开发、测试模型、按照开发阶段进行测试
文章目录一.基础概念 1.什么是软件测试 2.软件测试的目的 3.软件测试的原则 4.软件测试的分类 4.1 按照开发阶段分类 4.2 按照软件特性分类 4.3 按照测试技术分类 4.4 按照测试运 ...
最近面了12个人，发现这个测试基础题都答不上来...
一般面试我都会问一两道很基础的题目,来考察候选人的"地基"是否扎实,有些是操作系统层面的,有些是 python语言方面的,还有些- 深耕IT行业多年,我们发现,对于一个程序员而言, ...
【入门】App测试基础
点赞关注是对我最大的支持,可留言一起学习交流哦. App测试基础 1.安全测试 1.1 软件权限 1.扣费风险:包括发送短信.拨打电话.连接网络等 2.隐私泄露风险:包括访问手机信息.访问联系人信息等 ...

测试基础--测试方法