测试基础概念（全流程）

测 试 相 关

什么是软件测试？

目的

通过一些测试手段发现软件的缺陷从而及时避免这些缺陷所带来的使用障碍，使产品尽可能达到完美程度，保证软件或系统符合相关的法律法规技术标准和应用需求，降低软件的产品风险及应用风险。

概念

在规定的条件下对程序进行操作，以发现程序缺陷，衡量软件质量，并对其是否能满足设计需求进行评估的过程。

测试原理

测试方向

所谓测试方向就是从产品的哪些方面着手来检测，从而使产品达到用户的需求。

常用的方向：依据 软件质量模型8个特性：功能性、性能效率性、兼容性、易用性、可靠性、信息安全性、维护性和可移植性。

功能性：功能完备性、功能正确性、功能适用性

性能效率：时间特性、资源利用率、容量

兼容性：共存性、互操作性

易用性：可辨识性、易学性、易操作性、用户差错、防止性、用户界面、舒适性、易访问性

可靠性：成熟性、可用性、容错性、可恢复性

信息安全性：保密性、完整性、可抵御性、可检查性、可鉴别性

维护性：模块化、可重用性、易分析性、易修改性、易测试性

可移植性：适应性、易安装性、易替换性

测试的依据

一般软件测试的依据是：测试工程师所设计的测试用例。当预期结果和实际结果一致时，证明用例执行成功（该项测试通过）；若预期结果和实际结果不一致时，证明用例执行失败（该项测试未通过），这时就需要向开发提出bug，待开发修复完成后，再次执行该条用例，直至达到成功为止。

什么是bug？

软件没有实现需求规定功能

软件出现了需求规定中指明不应该出现的错误

软件实现了需求中国没有要求要有的功能

软件的隐形功能没有实现

软件不太好使用，难以理解，运行缓慢（测试人员站在用户方面找出的问题）

执行测试用例的时候，发现与用例预期结果不相符的现象

用户、客户认为这是一个Bug，那么无条件修改

测试详细过程

测试流程

需求评审    测试主管进行测试计划、测试方案编写     测试人员依据需求文档、测试计划进行测试用例设计    测试用例评审     搭建测试环境    冒烟测试     正式测试     提交测试报告  

需求评审

产品人员对需求进行统一讲解，然后开发、测试人员提出异议，由产品人员有针对性的进行详细讲解，初步解决开发人员和测试人员对需求的疑惑

测试计划和测试方案

测试计划

测试背景 、测试目标、测试范围、测试策略、测试资源、测试时间、测试进程、人员分配、设备、风险评估、测试进度、测试输出文档、测试规模工作量分析

测试方案

测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案

编写测试用例

编写测试用例时，要保证用例要对需求全覆盖，还要通过显性需求来发掘隐性需求，并在设计用例时尽可能覆盖到。测试用例的编写一般遵循一定的方法，常用的方法是：正交法、等价类、边界值、场景设计法。测试工程师一般根据不同的模块选择不同的用例设计方法，更多时候采用头脑风暴的方式进行用例设计。

测试用例评审

目的

通过多人评审的方式,使测试用例的覆盖面更广，尽可能保证测试的全面性，从而保证产品的质量达标

评审的分类

用例评审阶段，一般有两种方式：测试组内评审、项目组内评审。一般根据需求来决定测试方式。需求不太多且易理解，一般采用测试组内评审的方式；需求比较多，且需求比较模糊，一般项目组内评审的方式。

评审后的准备工作

测试工程师需要根据评审期间提出的建议，对所设计的测试用例进行修改并核对需求，确保用例的可执行性和覆盖性

搭建测试环境

测试环境的概念

简单地说就是软件运行的平台，即软件、硬件、网络设备和历史数据的合集，通俗点说：测试环境=软件+硬件+网络+数据准备+测试工具

硬件：包括PC机、笔记本、服务器、各种终端等。

软件：这里主要指的是软件运行的操作系统。（windows、Linux等）

网络：主要针对的是C/S结构和B/S结构的软件。

（c/s：客户端/服务端；b/s：网页端/服务端）

数据：有时候测试需要有一些虚拟数据支持的（比如说：注册过的账号去验证登录）

测试工具：postman（接口测试工具）、jmeter（性能测试工具）等等

测试环境搭建的原则

1、真实：尽量模拟用户的真实使用环境。项目软件由于只针对某一群体的用户，所以测试的环境比较单一。产品软件针对的是广大群众，所以测试环境比较复杂，要多方面考虑。

2、清洁:尽量不要在测试环境中安装与被测软件无关的软件。这种干净也不是必须的，有时候还要刻意去测试某个软件和其他软件并存时的兼容性问题。

3、无毒：测试工作需要确保在无病毒的环境中进行。

4、独立性：测试环境和开发环境是彼此独立的。开发环境和测试环境最好是分开的。由于测试人员和开发人员使用不同的服务器(数据库、后台服务器等等)，这样做避免了互相干扰，保证了测试结果的准确性。

冒烟测试

什么是冒烟测试？

针对每个版本或每次需求变更之后，在正式测试之前，对产品或系统的一次简单的验证性测试，验证产品或系统的“基本功能”流程是否正常。（主要就是执行优先级最高的测试用例）

冒烟测试的目的

目的是确认软件的基本功能正常，可以进行后续的正式测试工作

（如果冒烟测试不能通过，则不必执行下面的测试，一般要达到95%才算通过）

正式测试

何为正式测试？

正式测试就是按照所设计测试用例的操作步骤对相应的模块进行测试，并记录实际测试结果

提交bug

在执行测试用例的过程中，难免会出现实际结果与预期结果不相符的情况，这时测试人员要及时保留相关佐证（如：实际结果截图、相应的操作步骤），然后按照步骤再次进行操作，若结果还与实际结果不相符，就要使用bug管理工具进行bug的提交（bug管理工具：mantis、禅道等）

若复现操作后，结果又与预期结果一致了，那么就要判定该bug是否为偶发的，当然也要进行bug提交，标明为偶发bug即可

回归测试

（说明：回归测试可以发生在软件生命周期的任何阶段，写在此处是为了帮助读者更清晰的理解回归测试，不要狭义的认为回归测试一定只存在于软件生命周期的最后阶段）

什么是回归测试？

Bug修复完成后，测试其以前的功能仍然正常，同时，也要验证其修改后的缺陷是否正常。

回归测试是指重复以前的全部或部分的相同测试。（全部回归、部分回归）

回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占用很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。）

回归测试的目的

目的是验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能。回归测试可以发生在任何一个阶段（如：上线以后发现了缺陷，修复后也是需要进行回归测试）

回归测试的流程

1、在“测试策略制定”阶段，制定“回归测试策略”

2、确定需要进行回归测试的新的版本。

3、当回归测试版本发布后，按照回归测试策略执行回归测试。

4、若回归测试通过，关闭缺陷跟踪单。

5、若回归测试不通过，则将缺陷跟踪单返回开发人员，开发人员重新修改存在的问题或缺陷，开发人员修改完成后再次提交给测试人员进行回归测试。

提交测试报告

在完成测试后，为了向客户详细说明软件的质量，一般会出具一份测试报告，直观的展现软件的各项数据。

测试报告一般包含以下内容：

1、测试的基本情况：

测试时间、测试人员、测试的环境、测试的范围、还有测试用例执行的基本统计

2、缺陷的统计和分析：

缺陷总数的汇总、不同维度的缺陷分析和统计、遗留问题的汇总和分析

3、测试的结论和建议：

测试存在的风险、本次的测试结论

（比如说测试是否通过，是否达到上线的标准）

测试方法

分为：白盒测试、灰盒测试、黑盒测试

白盒测试

说明：一般由开发人员做，当然代码能力强的测试人员也可以做

白盒测试又称结构测试、逻辑驱动测试或基于代码的测试

盒子指的是被测试的软件，白盒指的是盒子是可视的、透明的，即可以清楚的看到盒子内部的东西以及里面的代码是如何运作的。

灰盒测试

说明：集成测试是测试阶段，灰盒测试是一种集成测试阶段常用的测试方法

灰盒测试，不仅关注输出、输入的正确性，同时也关注程序内部的情况，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。灰盒测试法主要验证软件满足外部指标、软件的所有通道或路径都进行了检验。（主要是接口）

黑盒测试

黑盒测试也称为功能测试和数据驱动测试。

它将被测软件视为一个无法打开的黑盒，主要根据功能需求设计测试用例并进行测试。

把产品软件想象成一个只有出口和入口的黑盒。在测试过程中，你只需要知道向黑盒输入什么，知道黑盒会产生什么结果。

测试的种类

按照测试阶段

需求测试、单元测试、集成测试、系统测试、验收测试

需求测试

测试人员在项目初期对需求文档进行校验确认

基本方法：

是否覆盖了用户提出的全部需求

用词是否清晰，语义是否存在有歧义的地方

是否清楚地描述了软件需要做什么不需要做什么

是否描述了软件的目标环境，包括软硬件环境

是否对需求项进行了合理的编号

需求项是否前后一致无冲突

是否清楚地说明了系统的输入、输出、以及输入输出之间的对应关系

是否清晰地描述了软件系统的性能要求

需求的优先级设置是否合理

是否描述了各种情况下的约束条件

单元测试（UT）

单元测试是开发自己编写的针对代码某个功能模块验证其行为的测试单元模块；单元测试贯穿在开发的整个过程，并伴随着新功能模块的产生而进行；单元测试并不会花费更多的时间，与之相反，在提高代码效率、减少bug数量、有序开展开发工作上，单元测试发挥着很大的作用。

参与人员：开发人员（代码能力强的测试人员）

使用方法：白盒测试方法

参考文档：详细设计文档

所需环境：开发环境

集成测试（IT）

集成测试是软件测试的一个阶段，其中将各个单元组合并进行测试，来验证它们在集成时是否按预期工作。这里的主要目的是测试模块之间的接口。

参与人员：开发/测试（一般涉及到代码就是开发做，涉及到接口就是测试做）

使用方法：灰盒测试方法

参考文档：概要设计文档（接口文档）

所需环境：集成环境

验收测试

在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动

α测试 和 β测试

α测试是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。

α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。

经过α测试调整的软件产品称为β版本。β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出意见，开发进行统一修改，并发布新版本

UAT测试

用户接受度测试（一般上线后进行的）

按照测试方向

功能测试、性能测试、安全测试、兼容性测试、可靠性测试、可用性测试、本地化测试、移植测试

说明：按照测试方向的测试点在前文测试原理中基本都说了，只对本地化测试进行详细说明

本地化测试

本地化测试的对象是软件的本地化版本。

本地化测试的目的是测试特定目标区域设置的软件本地化质量。

（例如：苹果手机的不同版本：日版、港版等等，验证是否能在当地使用的一种测试，包含翻译、网络、本地化是否成熟等等）

按照产品结构不同

web测试、app测试

Web测试

对web应用进行测试，可以采用上述的所有方法，也会经历上述的所有阶段

App测试

对app应用进行测试，可以采用上述的所有方法，也会经历上述的所有阶段

不同的是：app测试还有专项测试

App的专项测试：流量测试、弱网测试、安装测试、终端测试、稳定性测试等