软件测试分类

笔者经常在工作中听到“冒烟测试，α 测试，β 测试”等等。笔者并非专业的软件测试人员，有些测试类型见名知意，有些类型还是需要请教专业测试人员进行讲解。为了工作方便，在这里对相关软件测试的分类进行了整理，仅供参考。如有错误或不清晰的地方，还请指摘。

一、按照测试阶段分类

按照测试阶段可以将软件测试分为单元测试、集成测试、冒烟测试、系统测试与验收测试。这种分类方式与软件开发过程相契合，是为了检验软件开发各个阶段是否符合要求。

单元测试（unit testing）

单元测试，是指对软件中的最小可测试单元进行检查和验证（比如一个方法、一个函数，或一小组方法或函数之间的交互）。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

单元测试是软件开发的第一步测试，目的是为了验证软件单元是否符合软件需求与设计。单元测试大多是开发人员进行的自测。

集成测试（integration testing）

集成测试也叫组装测试、联合测试、子系统测试或部件测试，是在单元测试的基础上，将所有函数按照概要设计要求组装成为子系统或系统所进行的测试；它和单元测试所关注的范围是不同的，因此，它们在发现问题的集合上包含有不相交的区域，不能使用集成测试来替代单元测试，反之亦然。

实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题，在全局上很可能暴露出来。

以下两种测试技术是用于集成测试：

• 功能性测试。使用黑盒测试技术针对被测模块的接口规格说明进行测试。
• 非功能性测试。对模块的性能或可靠性进行测试。

冒烟测试（smoke testing）

冒烟测试，最初是从电路板测试得来的，当电路板做好以后，首先会加电测试，如果电路板没有冒烟再进行其他测试，否则就必须重新设计后再次测试。

后来这种测试理念被引入到软件测试中。在软件测试中，冒烟测试是指软件版本构建后，对系统的基本功能进行简单的测试，这种测试重点验证的是程序的主要功能，而不会对具体功能进行深入测试。如果测试未通过，需要返回给开发人员进行修正;如果测试通过则再进行其他测试。因此，冒烟测试是对新构建版本软件进行的最基本测试。

系统测试（System Testing）

系统测试，是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方。这种测试可以发现系统分析和设计中的错误。

系统测试是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效地测试，以发现软件潜在的问题，保证系统的正常运行。

主要内容包括：

• 功能测试。即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规格说明书》。由于正确性是软件最重要的质量因素，所以功能测试必不可少。
• 健壮性测试。即测试软件系统在异常情况下能否正常运行的能力。健壮性有两层含义：
  • 一是容错能力
  • 二是恢复能力

验收测试（Acceptance testing）

验收测试，是部署软件之前的最后一个测试操作。在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

实施验收测试的常用策略有三种，它们分别是：

• 正式验收
• 非正式验收或 Alpha 测试
• Beta 测试

您选择的策略通常建立在合同需求、组织和公司标准以及应用领域的基础上。

正式测试

正式验收测试，是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。

非正式测试（Alpha 测试 ，α 测试）

在非正式验收测试中，执行测试过程的限定不象正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不象正式验收测试那样组织有序，而且更为主观。

Beta 测试（β 测试）

在以上两种验收测试策略中，Beta 测试需要的控制是最少的。在 Beta 测试中，采用的细节多少、数据和方法完全由各测试员决定。各测试员负责创建自己的环境、选择数据，并决定要研究的功能、特性或任务。各测试员负责确定自己对于系统当前状态的接受标准。

Beta 测试由最终用户实施，通常开发（或其他非最终用户）组织对其的管理很少或不进行管理。Beta 测试是所有验收测试策略中最主观的。

二、按照测试技术分类

按照使用的测试技术可以将软件测试分为黑盒测试、白盒测试及灰盒测试。

黑盒测试（Black Box Testing）

黑盒测试就是把软件(程序)当作一个有输入与输出的黑匣子，它把程序当作一个输入域到输出域的映射，只要输入的数据能输出预期的结果即可，不必关心程序内部是怎么样实现的。

白盒测试（White Box Testing）

白盒测试又叫透明盒测试，它是指测试人员了解软件程序的逻辑结构、路径与运行过程，在测试时，按照程序的执行路径得出结果。白盒测试就是把软件(程序)当作一个透明的盒子，测试人员清楚地知道从输入到输出的每一步过程。

相对于黑盒测试来说，白盒测试对测试人员的要求会更高一点，他要求测试人员具有一定的编程能力，而且要熟悉各种脚本语言。但是在软件公司里，黑盒测试与白盒测试并不是界限分明的，在测试一款软件时往往是黑盒测试与白盒测试相结合对软件进行完整全面的测试。

灰盒测试（Grey Box Testing）

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。

从测试目标和依据来说：黑盒面对的是产品设计，白盒针对的是程序功能的实现，灰盒针对兼而有之，既要考虑产品设计要求，又考虑到功能实现的效果

三、按照软件质量特性分类

按照软件质量特性可以将软件测试分为功能测试与性能测试。

功能测试（Functional testing）

功能测试也称为行为测试（behavioral testing），根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。功能测试是为了确保程序以期望的方式运行而按功能要求对软件进行的测试，通过对一个系统的所有的特性和功能都进行测试确保符合需求和规范。

性能测试（performance testing ）

性能测试，就是测试软件的性能是否满足客户的需求，性能测试包括负载测试、压力测试、兼容性测试、可移植性测试和健壮性测试等等。

性能测试，是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

性能测试中包含以下测试类型：

• 压力测试（Stress Testing）- 强度测试也就是压力测试，压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标，譬如在一定时期内，系统的cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等，压力测试和负载测试最大的差别在于测试目的不同。
• 基准测试 - 比较新的或未知测试对象与已知参照标准（如现有软件或评测标准）的性能。
• 争用测试 - 核实测试对象对于多个主角对相同资源（数据记录、内存等）的请求的处理是否可以接受。
• 性能配置 - 核实在操作条件保持不变的情况下，测试对象在使用不同配置时其性能行为的可接受性。
• 负载测试（Load Testing）- 负载测试是一种主要为了测试软件系统是否达到需求文档设计的目标，譬如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等，测试的主要是软件系统的性能。核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。
• 强度测试- 核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。
• 容量测试（Volume Testing）- 确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等。核实测试用户同时使用软件程序的最大数量。

四、按照自动化程度分类

按照自动化程度可以将软件测试分为手工测试与自动化测试。

手工测试（Manual testing）

手工测试，又称人工测试，是测试人员一条一条地执行代码完成测试工作。手工测试比较耗时费力，而且测试人员如果是在疲惫状态下，则很难保证测试的效果。

自动化测试

自动化测试是借助脚本、自动化测试工具等完成相应的测试工作，它也需要人工的参与，但是它可以将要执行的测试代码或流程写成脚本，执行脚本完成整个测试工作。

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。

五、按照测试类型分类

软件测试类型有多种，包括界面类测试、功能测试、性能测试、安全性测试、文档测试等，其中功能测试与性能测试前面已经介绍，下面主要介绍其他几种测试。

界面类测试

界面类测试，简称UI测试，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。

安全性测试

安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程 。测试软件在没有授权的内部或外部用户的攻击或恶意破坏时如何进行处理，是否能保证软件与数据的安全。

文档测试（Documentation Testing ）

文档测试以需求分析、软件设计、用户手册、安装手册为主，主要验证文档说明与实际软件之间是否存在差异。

测试文档通常情况下指软件测试文档，测试文档是提供测试信息的一组文档，而并非单纯地指文档测试。

六、按程序是否运行分类

静态测试

静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。

它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。 （Fxcop是代码分析工具）

动态测试

动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能。这种方法由三部分组成：

• 构造测试用例
• 执行程序
• 分析程序的输出结果

七、其他测试类型

其他测试类型，并非不重要的类型，而是以目前笔者的认知，无法对其划分到正确的分类，故此先放在“其他”中。

回归测试（Regression Testing ）

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。