软件测试阶段划分
单元测试
单元测试（Unit Testing，简称UT）是对软件基本组成单元（函数或类）进行检测的测试工作。其目的是检测与详细设计说明书（Low Level Design，简称LLD）的符合程度。
集成测试
集成测试（Integration Testing，简称IT）是在单元测试的基础上，将所有的模块按照设计的要求进行集成，主要验证组装后的功能以及模块之间的接口是否正确安装的测试工作。主要目的是检测软件与概要设计说明书（High Level Design，简称HLD）的符合程度。集成测试的主要工作是测试模块之间的接口，但是接口测试不等于集成测试，这是个以面盖点的问题。比如，可以说北京是中国的城市，但不能说中国的城市就是北京。
集成测试工具
能够直接用于集成测试的测试工具不是很多，一般来说，一些通用的商用测试工具由于需要满足一定的通用性，因此在实际使用的时候功能是有限的，大部分工具需要进行二次开发。集成测试主要关注接口的测试，常用的接口测试工具：POSTMan、HTTPRequest、jmeter等。
系统测试
系统测试（System Testing，简称ST）是将已经通过集成测试的软件系统，与计算机硬件、外设、数据库、网络等其他元素结合在一起，在实际运行环境下，进行的一系列的测试工作。
系统测试通常是由独立的测试团队来完成，其测试的主要依据是需求规格说明书。
系统测试的类型主要有：
功能测试
功能测试是系统测试中最基本的测试，它不管软件内部的实现逻辑，主要根据产品的需求规格说明书和测试需求的列表，来验证产品的功能实现是否符合产品的需求规格。特别要注意的是一些隐含功能的需求。功能测试主要检查被测试对象是否存在以下几种错误：
- 是否有不正确、遗漏的或多余的功能。
- 功能实现是否满足用户的需求和系统设计的隐藏需求。
- 对输入是否做了正确的响应，对输出结果是否做了正确的显示。
- 对系统的流程设计是否正确、合理。
-
性能测试
性能测试是指在一定软件、硬件及网络环境下，对系统的各项性能指标来进行测试，主要检测其性能特性否满足特定的性能需求。常用的性能指标包括并发数、响应时间、每秒处理的事务数、吞吐量、点击率、访问量以及硬件资源等。
性能测试需要从以下两个方面考虑： 验证系统实现的性能是否与性能需求完全一致。
-
压力测试
压力测试也称强度测试，也是性能测试的一种，是指在极限状态下，长时间或超大负荷地连续运行的测试，主要检测被测系统的性能、可靠性、稳定性等。
压力测试检的目的是检查系统在资源超负荷的情况下的抗压能力。
压力测试的基本步骤如下： 进行简单的多任务测试。
-
容量测试
容量测试是指检查当系统运行在大量数据，甚至最大或更多的数据测试环境下，系统是否会出问题。还可以看作系统性能指标中一个特定环境下的一个特定性能指标，即设定的界限或极限值。容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。
进行容量测试一般可以通过以下几个步骤来完成： 首先分析系统的外部数据源，并对数据进行分类；
- 对每类数据源分析可能的容量限制，对数据类型分析记录的长度和数量限制；
- 对每类数据源，构造大容量数据对系统进行测试；
- 分析测试结果，与期望值进行比较，最后确定系统的容量瓶颈；
对系统进行优化并重复上面的步骤，直到系统达到期望的容量处理能力。
安全性测试
安全测试是用来验证系统内的保护机制是否能够在实际应用中保护系统不受到非法的侵入。该测试用来保护系统本身数据的完整性和保密性。随着互联网的发展，安全测试尤为重要，特别是一些金融类的产品，往往都把安全放到首位。
兼容性测试
兼容性测试是指检查软件在一定的软硬件、数据库、网络、操作系统环境下是否可以正确地进行交互和共享信息。兼容性测试的策略有向下兼容、向上兼容、交叉兼容。
兼容性测试一般考虑以下几点：软件本身能否向前或向后兼容，即不同版本之间的兼容。
- 软件能否与其他相关软件的兼容。
- 软件在不同的操作系统上兼容。
- 数据的兼容性，主要是指数据能否共享等。
-
配置测试
配置测试主要是指测试系统在各种软硬件配置、不同的参数配置下系统具有的功能和性能。配置测试并不是一个完全独立的测试类型，需要和其他测试类型相结合，如功能测试、性能测试、兼容性测试等。
通常配置测试的可以分为服务器端和客户端的配置测试。 服务器端的配置需要考虑服务器的硬件、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测试呢？ 降低经验注意决策的风险。
- 降低开发维护程本。
- 缩短项目周期。
若有收获，就点个赞吧
0 人点赞
