# 1.软件测试发展历程
测试这个词，在生活中经常被提及，比如你换个灯泡，换好之后，你会开关几下看看亮不亮。其实换好之后的动作就是测试行为，只是这个测试比较简单。随着业务、技术、环境的变化，软件测试发展历程大致分为四个阶段： 以调试化为特征的测试：没有测试岗，也没有成熟的测试组织形式和测试理论体系，是测试发展的初始阶段。更多是开发人员对软件进行“调试”。 以职能化为特征的测试：对项目研发各个阶段有了明确划分，将测试阶段和开发阶段明确区分，制定测试的目标，有专职的测试角色定义，要求测试人员具备业务能力、测试设计能力。系统定义了测试阶段各项文档产出，以及质量指标。可持续地度量、反馈、优化项目质量。 以中心化为特征的测试：发布了测试专有的体系规范与成熟度，测试作为独立组织存在，对测试人员的要求不再只是业务能力，以自动化、性能等专项为代表的能力逐渐成为必备能力。测试领域更加细分，出现了分层测试，以及测试开发人员角色，专职从事专项测试、测试环境维护以及测试工具开发。 以聚焦价值为特征的测试：项目交付节奏越来越快，从需求到交付过程充满了各种变化。竖井式管理模式，制约团队间的测试协作，自组织项目型团队需要各角色高效地运转以有效响应快速的业务交付。要求测试人员具备更好的研发及工程能力，向团队提供智能高效的执行、管理、度量质量工具，有效支撑内建质量、保障高效价值交付。 从软件测试发展历程看，软件测试对能力要求越来越高。除基础的业务理解能力和用例设计能力之外，还需要具备测试开发能力。
# 2.常见的软件测试类型
按照不同的分类方法，会有不同的测试概念。
# 2.1 从是否关心软件内部结构和具体实现划分
# 2.1.1 黑盒测试
黑盒测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
# 2.1.2 白盒测试
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，即清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。
# 2.1.3 灰盒测试
灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。
# 2.2 从是否执行代码划分
# 2.2.1 静态测试
静态测试是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。
# 2.2.2 动态测试
动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能。这种方法由三部分组成：构造测试用例、执行程序、分析程序的输出结果。
# 2.3 从软件开发的过程阶段划分
# 2.3.1 单元测试
单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
# 2.3.2 集成测试
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。
# 2.3.3 确认测试
确认测试是对通过集成测试的软件进行的，这些软件已经存于系统目标设备的介质上。确认测试的目的是要表明软件是可以工作的，并且符合”软件需求说明书”中规定的全部功能和性能要求。确认测试是按照这些要求定出的“确认测试计划”进行的。测试工作由一个独立的组织进行。而且测试要从用户观点出发。
# 2.3.4 系统测试
系统测试，英文是System Testing。是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方。这种测试可以发现系统分析和设计中的错误。如安全测试是测试安全措施是否完善，能不能保证系统不受非法侵入。再例如，压力测试是测试系统在正常数据量以及超负荷量(如多个用户同时存取) 等情况下是否还能正常地工作。
# 2.3.5 验收测试
验收测试是部署软件之前的最后一个测试操作。在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
# 2.3.6 回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
# 2.4 从业务系统划分
# 2.4.1 Web测试
Web测试是软件测试的一部分，是针对Web应用的一类测试。由于Web应用与用户直接相关，又通常需要承受长时间的大量操作，因此Web项目的功能和性能都必须经过可靠的验证。通过测试可以尽可能地多发现浏览器端和服务器端程序中的错误并及时加以修正，以保证应用的质量。由于Web具有分布、异构、并发和平台无关的特性，因而它的测试要比普通程序复杂的多。
# 2.4.2 App测试
App测试基于手机设备，还有一些手机设备的专项测试。如交叉事件测试，操作类型测试，网络测试（弱网测试，网络切换）。交叉事件测试：就是在操作某个软件的时候，来电话、来短信，电量不足提示等外部事件。操作类型测试：如横屏测试，手势测试。网络测试：包含弱网和网络切换测试。
# 2.4.3 客户端测试
用户可以看到的，使用界面的，web端，pc端，app，一般是在用户的机器上去做。
# 2.4.4 服务端测试
服务端测试有两种：一种是直接对Web或者App的服务端进行测试；另一种是对更后端的数据库、缓存系统、中间件、文件系统等进行测试。
# 2.4.5 大数据测试
大数据测试是对大数据应用程序的数据质量进行检测的过程。由于我们难以使用传统计算技术来处理大型数据集合，因此传统的数据测试方法不适合被实施到大数据上。为此，我们需要考虑的大数据测试策略应包括：大数据测试的基本技术(例如Apache的Hadoop)、方法、以及自动化工具。
# 2.5 从专项技能划分
# 2.5.1 功能测试
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
# 2.5.2 接口测试
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
# 2.5.3 自动化测试
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
# 2.5.4 性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
# 2.5.5 安全性测试
安全性测试是指有关验证应用程序的安全等级和识别潜在安全性缺陷的过程。应用程序级安全测试的主要目的是查找软件自身程序设计中存在的安全隐患，并检查应用程序对非法侵入的防范能力，根据安全指标不同测试策略也不同。
# 2.5.6 易用性测试
易用性测试是指用户使用软件时是否感觉方便，比如是否最多点击鼠标三次就可以达到用户的目的。易用性和可用性存在一定的区别，可用性是指是否可以使用，而易用性是指是否方便使用。
上面都是测试的基础概念，对于有一定测试经验的都比较好理解。为保障好产品质量，测试人员需要具备和学习更多的技能，在项目中灵活运用专业知识，方能在业务中使测试价值最大化。
# 3.总结
本节课我们介绍了软件测试的发展历程、常见的软件测试类型。