一、前言

  万字长文，只为精品，这是一篇你阅读后能够对测试术语和解释有明显提升认知的文章，同时也能在大致的介绍中指引你方向的文章，还可能是你看完以后会随手点个收藏、反复阅读的文章。

  本文章主要讲解软件、游戏测试行业的测试术语，并对测试专业术语进行概要补充，笔者进行一次整理，这里并不会提及到整个软件行业或游戏行业的所有术语，但所介绍的内容都是大家常用的术语或未来很可能会碰到的一些术语或目前已经在使用的术语，也包括跨领域的知识学习，没学习的萌新可以快速了解，学习过的大佬也可以通过目录快速进入到想了解的内容~

二、按照测试阶段划分：

2.1 单元测试（Unit Test）：

  单元测试，目的是为了验证软件中最小单元（类、函数）的正确性，测试的对象即是最小单元。

• 测试阶段：最小单元开发完成后
• 测试对象：类、函数等最小单元
• 测试人员：开发工程师、白盒测试工程师、自动化测试工程师
• 测试依据：代码与注释、需求文档、脚本调试
• 测试技术：白盒测试
• 测试优点：稳固底层代码逻辑
• 测试内容：接口测试、局部数据测试、路径测试、容错处理测试、边界值测试

补充说明：

1、单元测试是白盒测试，白盒测试并非单元测试

2、测试依据可以根据自身需要来进行制定

3、测试驱动开发在编写某个功能的代码之前先编写测试代码，只编写测试通过的功能代码，通过测试推动整个开发的进行

2.2 集成测试（Integration Test）：

  集成测试，是单元测试的逻辑扩展，将已经测试过的软件单元组合在一起测试它们之间的交互和依赖，对系统的接口及集成后的功能进行测试，以验证正确性。集成测试主要目的是检查软件单位之间的接口是否正确。

• 测试阶段：单元测试阶段后、功能集合前的单项功能正常
• 测试对象：类合集的多个函数对象、软件接口、业务系统与模块的交互
• 测试人员：开发工程师、白盒测试工程师、自动化测试工程师、功能测试工程师
• 测试依据：服务端设计文档的单元设计、概要文档、业务需求文档
• 测试技术：黑盒测试、白盒测试、灰盒测试
• 测试优点：保障模块间交互与独立功能的稳定性
• 测试内容：接口测试、模块间数据传输、模块间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

补充说明：

1、单元测试是单个函数或类方法的测试，只针对代码层面的测试

2、集成测试是多个函数、类方法的集合测试，集成测试至少包括两个以上的关联函数或类方法的测试

3、集成测试与单元测试不同的是，集成测试不仅用于代码测试，也用于功能层面测试两个或以上系统模块之间的联系

2.3 系统测试（System Test）：

  系统测试，将整个软件看作一个系统，在实际运行环境下对软件系统进行一系列严格有效地测试（包括功能、性能、自动化、安全等领域的测试），以发现软件潜在的问题，保证系统的正常运行。

• 测试阶段：集成测试阶段后
• 测试对象：整个软件系统以及关联的硬件系统
• 测试人员：系统测试工程师、黑盒测试工程师、自动化测试工程师、性能测试工程师等
• 测试依据：需求文档说明书
• 测试技术：黑盒测试、白盒测试、灰盒测试
• 测试优点：全范围、全方位保证系统的稳定性、健壮性、功能正确性等
• 测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

补充说明：

1、系统测试是针对整个软件系统进行的全局测试，不针对单一的模块、单元

2、冒烟测试以及回归测试包含在系统测试中且为重要组成部分，顺序：冒烟 ＞系统 ＞回归

3、只会单一的测试技术也可以完成系统测试的部分，并非需要技术精湛的系统测试工程师或同类工种测试人员完成

  冒烟测试（Smoke Test）：

  
  回归测试（Regression Test）：指代码进行修改后的复查，重新对修改内容以及相关联的内容进行测试确保没有出现新增Bug且该问题修复成功。

  
  

2.4 验收测试（Acceptance Test）：

  验收测试主要是对软件产品说明进行验证，逐行逐字地按照说明书的描述对软件产品进行测试，确保其符合各项要求。

• 测试阶段：系统测试通过后
• 测试对象：整个软件系统以及关联的硬件系统
• 测试人员：需求方或用户方
• 测试依据：用户需求、验收标准
• 测试技术：黑盒测试
• 测试优点：避免冗余、重复性开发
• 测试内容：软件系统的功能是否符合标准（用户需求、验收标准、各类需求文档）

补充说明：

1、验收测试不同于系统测试，系统测试是系统化的流程测试，而验收测试是验证各项需求文档中所提及的需求内容

2、验收测试主要是对于需求中所提及的需求点进行验证测试，无需在验收测试时考虑各类异常点或非需求提及内容

3、完全独立的系统模块可以考虑提前介入验收测试的环节，但测试的结果不可当成最终的验收结果，只是提前检查是否符合需求规划，如不符合尽快改进的一个推动手段

  

三、按照测试技术划分：

3.1 黑盒测试（Black-box Testing）：

  黑盒测试，即数据驱动测试、功能测试，测试中把被测的软件（程序）当成一个黑盒子，它把程序当作一个输入域到输出域的映射，不关心盒子的内部结构是什么，只关心软件的输入数据和输出数据正确即可。

• 测试阶段：开发功能基本稳定到发布阶段前
• 测试对象：软件系统的功能
• 测试人员：功能测试工程师
• 测试依据：业务需求文档
• 测试技术：黑盒测试
• 测试优点：保障基础功能的正确性与稳定性
• 测试内容：软件各项功能

补充说明：

1、黑盒测试主要验证功能的正确性，业务功能的集成内容也属于黑盒测试

2、黑盒测试过程中不可用作穷举测试，需要考虑合法的输入场景和特定的异常场景

3、黑盒测试的基础前提上是以用户的角度出发结合异常点与发散思维进行的测试

3.2 灰盒测试（Gray-Box Testing）：

  灰盒测试是介于白盒测试和黑盒测试之间的一种，灰盒测试多用于集成测试阶段，不仅关注输入、输出的正确性，同时也关注程序内部的情况。

• 测试阶段：单元测试阶段后集成阶段前
• 测试对象：程序接口、集成项
• 测试人员：黑盒测试工程师、接口测试工程师、自动化测试工程师
• 测试依据：业务需求文档、接口需求文档
• 测试技术：黑盒测试、灰盒测试
• 测试优点：保障集成阶段的正确性与稳定性
• 测试内容：接口测试、模块间数据传输、模块间功能冲突

补充说明：

1、灰盒测试主要是功能测试与接口测试

2、灰盒测试在内部过程中把程序看作一个必须从外面进行分析的黑盒

3、灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。

3.3 白盒测试（White-Box Testing）：

  白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试不同于黑盒测试，不会关注或过多关注盒子的表面，而是关注盒子的内部，去研究里面的“容貌”与“结构”等（等价于源代码和程序结果）

• 测试阶段：单元测试阶段
• 测试对象：程序源代码、程序结构体
• 测试人员：白盒测试工程师、开发人员、高级自动化测试工程师
• 测试依据：服务端代码设计文档、客户端代码设计文档、程序设计概要、业务需求文档
• 测试技术：白盒测试
• 测试优点：保证底层代码逻辑功能实现正常，为后续其他测试的便捷与稳定做铺垫
• 测试内容：程序判断逻辑、语句覆盖、条件覆盖等

补充说明：

1、白盒测试也是接口测试的一种

2、白盒测试是直接对源代码进行测试

3、白盒测试其中一部分需要语言对标，在挑选工具时要选择工具语言支持的

  

四、按照程序运行划分：

4.1 静态测试（Static Testing）：

  静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错

• 测试阶段：可测试情况下的任意阶段
• 测试对象：程序代码、需求说明书、接口等非程序运行环境的检查
• 测试人员：任意测试工程师、开发人员
• 测试依据：需求文档、程序概要设计、程序结构图等
• 测试技术：黑盒测试、灰盒测试、白盒测试
• 测试优点：稳固底层代码逻辑与集成交互功能、优化流程等
• 测试内容：程序代码的正确性、需求文档的正确性与合理性等

补充说明：

1、我们所说的发现需求文档中的设计缺陷就属于静态测试的一种方式

2、静态测试主要的测试层面为代码测试、界面测试以及需求文档测试

3、静态测试不同于大多数的测试，在测试完成后需要有专人进行多次的复核

4.2 动态测试（Execution-Based Testing）：

   动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性、健壮性、性能等。

• 测试阶段：项目框架比较完善且程序可运行
• 测试对象：整个软件系统及其硬件设备
• 测试人员：任意测试工程师、开发人员
• 测试依据：用户手册、需求文档、对标产品数据
• 测试技术：黑盒测试、灰盒测试、白盒测试
• 测试优点：系统的二次质量保证
• 测试内容：运行效率、正确性、健壮性、性能等

补充说明：

1、动态测试主要有三部分组成：构造测试用例、执行程序、分析程序的输出结果。

2、大多数的软件和少部分的游戏都在进行动态测试

3、动态测试与静态测试最明显的区别就在于静态测试不运行程序，而动态测试是在程序运行下进行的

  

五、按照测试对象划分：

5.1 性能测试（Performance Testing）：

   性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

• 测试阶段：开发功能基本稳定到发布阶段前
• 测试对象：整个软件系统及其硬件设备
• 测试人员：性能专项测试工程师
• 测试依据：用户手册、概要方案、对标产品数据
• 测试技术：专项测试
• 测试优点：系统的二次质量保证
• 测试内容：资源利用、执行间隔、响应时间、吞吐量等

补充说明：

1、App主要测试CPU消耗、内存消耗、电量消耗、流量消耗等，这是与Web测试与PC端的明显区别，游戏App亦是如此

2、如果系统的性能相对于较好的时候，可以考虑上线后介入，如果不理想需要在上线前进行测试，亦可在单一的某块稳定后针对测试

3、性能测试中有负载测试、压力测试、容量测试等等，测试的主流程工具是Loadrunner、Jmeter等等

5.2 安全测试（Security Testing）：

   安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。

• 测试阶段：开发功能基本稳定到发布阶段前
• 测试对象：软件系统及其硬件设备
• 测试人员：安全测试工程师
• 测试依据：违反权限与能力的约束
• 测试技术：专项测试
• 测试优点：建立在安全需求定义基础上的质量保证
• 测试内容：日志数据、用户数据隐私、用户权限等

补充说明：

1、测试理论通常而言很难适用于安全测试领域，其主要原因是因为实操性过强且理论知识范围宽泛

2、功能测试主要是以运用各类方法发现Bug为主，安全测试则以发现安全隐患为主，两者的关联性很低

3、web安全、软件安全与游戏安全的测试方向差距很大，想学习安全测试的朋友需要明确方向进行学习

5.3 兼容性测试（Compatibility Testing）：

   兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能够很友好的运行测试。

• 测试阶段：开发功能基本稳定到发布阶段前
• 测试对象：软件系统及其硬件设备
• 测试人员：兼容专项测试工程师、功能测试工程师
• 测试依据：软硬件兼容性测试指标
• 测试技术：专项测试
• 测试优点：与平台软硬件独立、完好运行
• 测试内容：操作系统兼容性、异构数据库兼容性、应用软件兼容性、数据兼容性等

补充说明：

1、最常见的兼容性测试是Web兼容，一个网页中在不同的浏览器不同的Windows系统分辨率的情况下兼容的展示

2、App类型的兼容性测试以数据库兼容、数据兼容测试最为常见，硬件也是如此，例如手机系统升级更新，就需要测试数据兼容

3、游戏的App存在最多的是软件兼容以及数据兼容，软件兼容即在运行其他软件时游戏的独立性，无冲突，数据兼容主要是游戏合服

5.4 文档测试（Documentation Testing）：

   文档测试是检验样品用户文档的完整性、正确性、一致性、易理解性、易浏览性，测试文档是提供测试信息的一组文档，而并非单纯地指文档测试。

• 测试阶段：测试方案编写完成
• 测试对象：项目各类流程文档、需求文档、测试用例、测试总结报告等
• 测试人员：功能测试工程师、专项领域工程师等
• 测试依据：项目各类流程文档、需求文档、测试用例、测试总结报告等
• 测试技术：黑盒测试
• 测试优点：提高测试效率、阅读理解性、间接提高产品质量等
• 测试内容：文档的完整性、正确性、一致性、易理解性、易浏览性等

补充说明：

1、黑盒测试中的需求评审、用例评审等都属于文档测试，根据测试内容对需求文档进行测试

2、文档测试的介入通常是在正式执行某一项事务或事件前进行的测试

3、通常在测试方案阶段进行测试介入，在项目发布前的最终测试报告属于阶段性文档测试，上线后仍需对各类文档测试及维护

5.5 易用性测试（Usability Testing）：

   易用性测试又称为用户体验测试，是检查软件系统中各项内容是否方便用户使用，用户使用软件时是否具有一定的便捷性。

• 测试阶段：开发功能基本稳定持续到软件生命周期结束
• 测试对象：软件系统中的各功能、图形化界面、文档等
• 测试人员：功能测试工程师、软件体验师
• 测试依据：用户自主认知、用户基础认知及基础行为操作
• 测试技术：黑盒测试
• 测试优点：提高软件使用的便捷性
• 测试内容：易理解性、易学习性、易操作性、吸引性、易用依从性

补充说明：

1、依从性是软件在遵循与某一特性相关的标准、约定或法规以及类似规定的能力，这些标准要考虑国际标准、国家标准、行业标准等

2、易用性测试大多数情况下是以用户的角度去思考、进而验证软件是否符合易用性的标准，部分标准会参照行业标准或依从性

3、易用性测试主要是由功能测试人员在日常测试中以及专业的体验师进行的体验工作，但大多数国内行业的公司，其他部门也会介入寻找、挖掘用户的体验问题，以更好的保障软件易用性

5.6 适配测试（Adaptation Test）：

   适配测试是为了让软件系统能够在不同的硬件设备上均能够有良好的运行，达到最佳用户体验而进行的一种测试。

• 测试阶段：系统测试完成后
• 测试对象：软件系统中的各功能、图形化界面等
• 测试人员：适配专项工程师、功能测试工程师
• 测试依据：主流手机型号、平板等硬件设备，主流分辨率
• 测试技术：专项测试
• 测试优点：提高用户体验、使用舒适度
• 测试内容：设备系统、分辨率等

补充说明：

1、适配与兼容性的主要区别在于兼容性是检查设备兼容，数据兼容，更多关注的是功能的正常使用以及数据继承，而适配更多的关注的是在不同系统与分辨率下的界面适应能力与系统适应能力

2、测试主要选择市场主流的手机型号、品牌、系统以及分辨率，具体可以参考：百度统计流量研究院

3、适配的测试时机并非一定是在系统测试完成后，时间及设备条件允许的情况下可以考虑提前介入测试，但不应在系统模块频繁调整期间介入，至少需要模块比较稳定后在考虑介入测试

5.7 接口测试（Interface Testing）：

   接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

• 测试阶段：单元测试完成后
• 测试对象：软件系统
• 测试人员：接口测试工程师、开发人员
• 测试依据：接口需求文档
• 测试技术：专项测试
• 测试优点：缩短项目测试时间、提高系统健壮性等
• 测试内容：业务功能覆盖、业务规则覆盖、参数验证、接口及代码覆盖率等

补充说明：

1、接口测试的关注点是服务器代码的逻辑验证为核心点出发的

2、接口测试分为内部接口和外部接口，例如部分软件的登录有微信登录和QQ登录，即是调用了外部接口，而内部接口是自研接口

3、外部接口通常被当成系统测试来对待且外部接口通常在接口测试有着很高的优先级，严格的意义上讲，在进行功能测试前需要对外部接口测试通过，而内部的接口而言先后顺序的影响并不是很重要，任意顺序均可

5.8 界面测试（UI Testing）：

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

• 测试阶段：集成测试阶段
• 测试对象：软件系统中的各个UI界面
• 测试人员：功能测试工程师
• 测试依据：UI需求文档
• 测试技术：黑盒测试
• 测试优点：提升便捷性与用户视觉体验等
• 测试内容：规范性、合理性、美观性、独特性等

补充说明：

1、游戏行业也会存在大量的界面测试，通常会参考美术的UI文档，而部分UI美术图是由策划（产品）所提供的

2、UI测试的目标在于确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。除此之外，UI 测试还要确保 UI 功能内部的对象符合预期要求，并遵循公司或行业的标准。

3、界面测试在日常的工作中大多数都会被称为UI测试，但我们所说的UI自动化测试可不是界面自动化测试哦，萌新们要注意这一点哦，具体可以查找一些资料详细了解。

5.9 安装测试（Installation Testing）：

   安装测试是确保该软件在正常情况和异常情况的不同条件下，能够正常的进行安装、升级、卸载。

• 测试阶段：可打包较为稳定的Apk或Ipa后
• 测试对象：软件系统的安装流程
• 测试人员：功能测试工程师
• 测试依据：各类需求文档的综合集成
• 测试技术：黑盒测试
• 测试优点：提升用户体验
• 测试内容：安装、升级、卸载

补充说明：

1、测试的阶段并非绝对的，在上线前进行测试也并非不可，具体依据项目需要决定，即使安装测试的流程在最后进行测试，也不会过多的影响项目的流程或其他质量性问题，更多的是应用外部的独立

2、对于安装测试而言不仅仅只是“安装”，“升级”，“卸载”，也需要考虑到一定的异常点，例如安装时锁屏、卸载时手机断电关机、升级时接到了移动电话等

3、无论什么样的App软件，什么形式的生命周期，都会经历安装测试，在App领域中安装测试又被称为经典测试

六、按测试实施的组织：

6.1 α测试（Alpha Testing）：

   α测试又称alpha测试，是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可用性、可靠性、性能和支持)。

• 测试阶段：单元测试、集成测试、系统测试
• 测试对象：功能、局域化、可使用性、可靠性、性能和支持
• 测试人员：开发人员、功能测试工程师、性能专项工程师、软件体验师
• 测试依据：各类需求文档的综合集成
• 测试技术：黑盒测试、专项技术
• 测试优点：提升用户体验、正式验收前的风险降低
• 测试内容：软件的功能、稳定性、软件性能等

补充说明：

1、α测试也称之为内测，通常来说是内部的用户进行的测试，并非会涉及到外部人员

2、α测试工作不可以由开发人员或测试人员相关的专业人员进行测试，通常而言是其他部门进行的测试，将发现的问题反馈至开发人员，并有开发人员进行分析、跟进、处理

3、α测试可以在单元、集成、系统测试的阶段进行，但绝大多数的情况下，α测试只会在单元测试完成后进行测试，即项目的初期，通常为软件的第一个大版本，可用、可测、核心功能已实现的版本。

6.2 β测试（Alpha Testing）：

   β测试又称beta测试，β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，即发放一部分给用户进行测试，并要求用户报告异常情况、提出批评意见，然后软件开发公司再对β版本进行改错和完善。

• 测试阶段：集成测试、系统测试
• 测试对象：系统功能、系统体验
• 测试人员：用户群体
• 测试依据：用户自主行为以及软件认知
• 测试技术：黑盒测试
• 测试优点：提升用户体验、发现潜在问题
• 测试内容：系统全功能及体验

补充说明：

1、β测试也称之为公测，通常是由不同的用户在不同的场所进行的测试，β测试的用户会在各式各样的环境下进行测试

2、β测试的进行的前提条件是已经解决了软件中大部分的不完善之处，但仍有可能还存在缺陷和体验问题，通常会提供给测试的用户群体进行测试，得到用户反馈后加以修正改善

3、β测试的环境不受开发方控制，测试用户群体是对软件具有一定认知性、对测试职业以及软件有一定的掌握性和了解性的特定人群

6.3 λ测试（Final Testing）：

  λ测试又称最终测试、终测，λ测试是指软件发布前使用相当成熟稳定的软件所面向广大用户群体或特定用户群体的最终版本测试，λ测试的实际版本与正式发布版本没有很大的差异，会根据用户最终报告的一些建议和潜在的风险做最后的调整及修正

• 测试阶段：验收测试
• 测试对象：系统功能、系统体验
• 测试人员：用户群体
• 测试依据：用户自主行为以及软件认知
• 测试技术：黑盒测试
• 测试优点：提升用户体验、发现潜在问题
• 测试内容：系统全功能及体验

补充说明：

1、在游戏领域中λ测试其实就是所谓的游戏终测，及游戏上线前所发布的版本，游戏与软件在终测上无明显的差别，大多数情况下，软件以及游戏都需要经历的相同的λ测试

2、λ测试只能够存在于验收测试之后，各项功能完善、齐全、几乎无明显问题或体验问题的最终版本，否则进行公开测试的版本都只能算做β测试，因为实际软件条件不符合λ测试，只是名义字眼上的终测

3、对于α测试、β测试以及λ测试，越后置的测试，人力消耗越大、经办费用越高、维护成本越高，通常而言在国内只有少数技术实力强劲的公司会进行λ测试

6.4 三方测试（Third party testing）：

  三方测试又称合作方测试，是软件系统产品与用户需求方或合作发行、开发的公司的第三方合作伙伴，目前很多软件系统都会有一些相关联的开发或发行的合作伙伴。

• 测试阶段：软件大版本之后
• 测试对象：整个软件系统
• 测试人员：合作方内部人员
• 测试依据：研发需求文档、用户软件认知及理解
• 测试技术：黑盒测试
• 测试优点：提升用户体验、发现潜在问题
• 测试内容：功能、易用、吸引性、美观性等

补充说明：

1、三方测试通常而言在某个大版本之后会有合作方协助进行测试，但并非绝对，具体依据各个公司及项目的实际情况来综合考虑测试介入的时机

2、三方测试通常而言只会存在功能测试，如果发现表层的问题也会及时反馈给研发合作方，予以修复，例如软件使用时的卡顿问题等，更多出现在游戏领域

3、三方测试也包括用户测试，即β测试阶段以及λ测试阶段

七、按执行方式划分：

7.1 手工测试（Manual Testing）：

  手工测试又称功能测试，是软件系统测试执行方式的常见手段，俗称“点点点”，手工测试也是最原始的测试手段，用于验证功能是否正确。

• 测试阶段：单元测试阶段后
• 测试对象：整个软件系统
• 测试人员：功能测试工程师
• 测试依据：研发需求文档、UI需求文档、美术需求文档等
• 测试技术：黑盒测试
• 测试优点：保证系统的功能稳定性
• 测试内容：功能、UI界面、集成逻辑等

补充说明：

1、手工测试不需要任何的三方工具，只需要具备测试理论即可进行最基础的软件测试

2、有很多人认为当今的软件/游戏市场，任何人都可以进行手工测试，这种想法是完全错误的，手工测试的要求很高并且需要专业的理论知识具备，只是在特定的行情、门槛又低的情况下，大批量的人力涌入导致所显示的手工测试低廉罢了

3、手工测试大多数情况下依据测试用例来进行执行，少部分专业性较强的测试工程师会使用错误推测法以及探索性测试的方法来进行进阶的功能保障，手工测试不能100%的找出所有问题，它只可以将软件产品的质量无限推进于完美

7.2 自动化测试（Automation Testing）：

  自动化测试就是将手工测试的行为以及流程使用自动化的方式进行代替，从而减少人力成本与时间成本，达到高效、稳定，便捷的最佳效果。

• 测试阶段：系统测试阶段
• 测试对象：整个软件系统
• 测试人员：自动化测试工程师
• 测试依据：研发需求文档、开发设计概要与设计文档
• 测试技术：白盒测试、专项技术测试
• 测试优点：减少繁琐的步骤、人力资源，提升测试效率等
• 测试内容：业务功能、集成逻辑等

补充说明：

1、自动化测试不可代替手工测试，无论软件处于生命周期的任何阶段，自动化也不可能完全取代，自动化测试的建立是在手工测试的基础上进行的

2、自动化测试分多个测试方向领域、接口自动化、性能自动化、安全自动化等且学习成本较高，时间成本较大，各位萌新们仔细思考对应的路线并进行学习哦~

3、自动化测试更多的情况下是进行回归测试，而非第一次测试，一次测试往往是由手工代替，自动化测试更多做的是重复性的工作，其主要的代表性工作就是回归测试

八、按测试地域划分：

8.1 本地化测试（Localization Testing）：

  本地化测试就是软件的本地化测试，例如一个西方版本的微信，那么换成国内版本的微信就是本地化测试，一个特定的人文区域的测试也是本地化测试，我们所从事的大多数测试工作都是本地化测试

• 测试阶段：项目全阶段
• 测试对象：整个软件系统
• 测试人员：功能测试工程师、自动化测试工程师、性能测试工程师等
• 测试依据：研发需求文档、UI需求文档等
• 测试技术：黑盒测试、灰盒测试、白盒测试、专项技术测试
• 测试优点：保障在本地环境运行的兼容性、正确性等
• 测试内容：软件本地运行的文化、喜好、UI、文本内容等

补充说明：

1、评判一个软件是否是本地化测试的直接标准就是这个软件的服务器运行时间是否是东八区的时间即国内的北京时间，其次的标准是是否为简体中文的国内语言，符合上述两个条件才能够称之为本地化测试，这是所有本地化测试最核心的前提

2、本地化测试中还存在地域测试，日常的测试中并非所有的测试工程师都在进行本地化测试，本地化测试具有一定的领域划分，你可以理解成我们所认知的麻将有四川麻将、东北麻将，以四川麻将举例，如果要进行四川麻将的测试，那么这套麻将的玩法就必须符合四川本地人的喜好、文化，也就是所谓的本地化测试

3、本地化测试具有一定显著的鲜明、特征，例如国内的软件测试，那么软件需要符合一定的行业标准、执行标准等，类似于依从性

8.2 国际化测试（International Testing）：

  国际化测试的目的是测试软件的国际化支持能力，发现软件的国际化的潜在问题，保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型，针对任何区域性或区域设置检查产品的功能是否正常。

• 测试阶段：集成测试阶段、系统测试阶段、验收测试阶段
• 测试对象：整个软件系统
• 测试人员：功能测试工程师、自动化测试工程师
• 测试依据：研发需求文档、UI需求文档等、国际标准依从性
• 测试技术：黑盒测试
• 测试优点：保障在国际化环境运行的兼容性、正确性等
• 测试内容：软件国际化运行的正确性、兼容性、文化习惯、政治要求等

补充说明：

1、本地化测试的重点更多在于本地的文化习俗内容，而国际化测试重点在于国际的政治要求，虽然其他内容也需要测试，这是两种测试对比的明显差距

2、国际化测试更多的测试的是输入域、输出域，语言的输入、输出，不同的时间时区、货币格式、文化习惯、政治要求，特定图片检测等（例如某宗教不吃猪，这个产品又要发布在这个国家地区，理论上不应存在与猪负面的相关图片等一系列的负面言论，甚至部分国家有明确的写进法律法规中，这也是对政治要求、文化习惯的测试）

3、国际化测试前的准备环境通常是软件为对应地区的版本软件（对应地区是指对应地区本地的测试版本，并非国内版本修改语言的形式）且硬件设备服务器的时间也同为对应国际化地区的时间

  

九、其他类合集：

9.1 全量测试（Omnidirectional Test）：

  全量测试属于黑盒测试技术的一种也属于手工测试，全量测试是指对整个软件系统的二次全覆盖测试，主要为执行业务层面的测试用例达到系统全覆盖，进而避免问题二次修复或遗漏的内容的进阶保障手段。

• 测试阶段：系统测试阶段
• 测试对象：整个软件系统
• 测试人员：功能测试工程师
• 测试依据：研发需求文档、UI需求文档等
• 测试技术：黑盒测试
• 测试优点：排查软件系统中的疑难杂症以及遗漏问题等，进阶保证产品质量
• 测试内容：软件功能、集成内容等

补充说明：

1、全量测试只针对于软件系统的业务功能测试，其他部门所谓的“全量测试”称之为回归测试

2、全量测试并非只能由业务功能的测试工程师完成测试，其他的测试人员通常而言可以给予一些建议性或指导

3、全量测试的次数不定，时间不定，依据各个项目需要决定，部分公司为了快速上线可能只会进行一次全量测试甚至没有全量测试，而一些实力强劲的公司会在上线前组织2到5次不等的全量测试，项目越大，意味着全量测试的次数越多，暴露风险的可能性才会越大，不少国外的3A游戏巨作就会存在多次的全量测试。

9.2 随机测试（Ad hoc testing）：

  随机测试又称即兴测试，主要是对被测软件系统的重要核心功能以及关键集成逻辑进行的复测，通常而言如果项目时间不完全无法进行全量测试，那么可以由特定且专业的测试工程师进行即兴测试，从全量测试的所有覆盖点中挑取最核心、最重要的内容进行测试。

• 测试阶段：系统测试阶段
• 测试对象：整个软件系统
• 测试人员：功能测试工程师、性能测试工程师
• 测试依据：研发需求文档、性能测试需求
• 测试技术：黑盒测试、专项技术测试
• 测试优点：排查软件系统中的疑难杂症以及遗漏问题等，进阶保证产品质量
• 测试内容：软件功能、集成内容、软件性能等

补充说明：

1、随机测试不仅仅用作于全量测试的备用手段，也用作于日常支援性工作以及日常需求冒烟的测试手段

2、随机测试不仅仅要对软件系统的功能进行测试也需要对软件系统的性能进行测试，所测试的场景可以为核心主干场景，也可是其他场景，依据项目时间、人力等多因素安排

3、随机测试可以是组员内的交互进行，并非必须由一个人来完成，随机测试没有明确的起点和终点，可随时停止，亦可由其他人反复的检验和交替测试

9.3 烟雾测试（Smoke Testing）：

  烟雾测试是指开发人员在个人版本的软件上执行目前的烟雾测试项目，确定新的程序代码不出故障。

• 测试阶段：任意阶段
• 测试对象：私有的公用软件版本
• 测试人员：开发人员、自动化测试工程师、测试开发工程师
• 测试依据：软件测试理论基础
• 测试技术：黑盒测试
• 测试优点：阶段性的复查
• 测试内容：软件版本功能

补充说明：

1、烟雾测试又称为自测，所谓的开发自测其实就是烟雾测试的一种说法，烟雾测试不仅仅用于开发，自动化工程师对于自己的自动化脚本也需要进行烟雾测试， 测试开发的工程师亦是如此

2、烟雾测试最重要的就是版本的功能验证，其他的内容也会验证，但会比较少，大多数情况下的烟雾测试都是进行功能测试，以检验新的程序代码的正确性

3、烟雾测试的英文与冒烟测试的英文一致，不用惊慌，设计如此，但烟雾测试并非同冒烟测试，冒烟测试更多的是针对公用版本的即产品版本的核心功能检查，而烟雾测试则是开发私有的特殊化公用版本或自行的脚本检查，两者有本质上的区别

9.4 敏捷测试（Agile Testing）：

  敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求能得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。

• 测试阶段：任意阶段
• 测试对象：整个软件系统
• 测试人员：功能测试工程师
• 测试依据：软件测试理论基础
• 测试技术：黑盒测试、白盒测试
• 测试优点：提升测试效率，推动项目流程建设等
• 测试内容：全方位内容，主要为自动化测试

补充说明：

1、强调从客户的角度，即从使用系统的用户角度，来测试系统。重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段

2、敏捷测试通常具有敏捷性且拥有敏捷开发的相关特性，例如测试驱动开发（TDD）、验收测试驱动开发（ATDD）等，建议尽早开始测试，对于高度迭代的内容、有周期性的高效率反馈以及测试驱动开发的思想就是敏捷测试思想的核心

3、敏捷测试在国内的软件及游戏行业盛行，其主要原因是能够加快项目的进度流程效率，但不巧的是，往往很多公司的测试人员不能够很好的掌握敏捷测试的技术要点和思想，在发布的时候往往会因为敏捷测试的方式，遗漏很多问题在正式服上，造成测试遗漏，笔者建议大家学习敏捷测试，但应在熟练掌握各类软件测试理论的基础上加以使用，才能更好的保证测试质量哦~

9.5 配置测试（Configuration Testing）：

  配置测试是指使用各种硬件来测试软件运行的过程。配置测试方法是指通过对被测系统软硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。

• 测试阶段：系统测试阶段
• 测试对象：整个软件系统的硬件运行
• 测试人员：硬件测试工程师、硬件性能测试工程师
• 测试依据：性能测试需求
• 测试技术：专项测试
• 测试优点：找到系统资源的最佳分配
• 测试内容：各个接口、外设、设备驱动、主板以及内部设备等

补充说明：

1、配置测试多数是硬件，在游戏行业中配置测试大多数指明的是配置表的测试，配置表测试则是对一系列Excel格式的csv表的各个字段进行测试，以便于服务端及客户端对于数据的读取，实时呈现最终的游戏效果展示，或是实现特定的功能等

2、硬件的配置测试实行难度较大，它与手工测试相同，也有一套完整的测试体系以及测试流程，硬件的配置学习更新较快，主要源于现阶段的硬件更新迭代速度，测试人员需要不断的学习、探索，才能掌握最新的硬件信息和行情

3、硬件配置测试在人们的认知中大多数情况下出现在游戏领域，例如登录王者荣耀后，系统会默认识别你的手机型号、品牌以及各项参数，来默认调整你的画质、辨识度等内容，在一些PC游戏上，大多数游戏都会有最低配置以及推荐配置的硬件配置表，主要就是根据配置测试的最终结果来得出的结论

9.6 通过性测试（Passability Test）：

  通过性测试实际上是确认软件至少能做什么，而不会考验其能力。软件测试人员并不需要要想尽办法让软件崩溃，仅仅运用最简单、最直观的测试用例。

• 测试阶段：单元测试阶段后
• 测试对象：整个软件系统
• 测试人员：功能测试工程师
• 测试依据：业务测试用例
• 测试技术：黑盒测试
• 测试优点：确保各个模块的基本保证
• 测试内容：系统模块间的各项基础功能

补充说明：

1、通过性测试不等同于冒烟测试，冒烟测试是测试每一个模块中最核心的主流程，而通过性测试是不仅仅测试主流程，还需要测试其他的简单的、直观的功能，测试量要大于冒烟测试

2、笔者更建议大家在日常的需求测试或版本测试之前先进行通过性测试，这样有助于快速发现一些明显问题，避免执行测试用例到尾声以后才进行问题暴露，会拖慢测试进度

3、通过性测试可以由功能测试人员进行，也可以由其他人员进行测试，例如性能测试也存在有性能测试用例、安全领域也是相同的，不仅仅只运用于功能测试，但大多数情况下我们所说的通过性测试都是功能测试，性能、安全等专项领域的测试工程师，也可根据组内所设计的测试用例进行通过性测试

9.7 失效性测试（Failure Test）：

  失效性测试与通过性测试是对立面，失效性测试会考验被测软件系统的能力，软件测试人员需要想尽一切办法攻破软件系统，尽可能使其崩溃。

• 测试阶段：单元测试阶段后
• 测试对象：整个软件系统
• 测试人员：功能测试工程师
• 测试依据：业务测试用例
• 测试技术：黑盒测试
• 测试优点：确保各个模块的基本保证
• 测试内容：系统模块间的功能、性能、安全等方面

补充说明：

1、失效性测试没有明确要求具体需要哪一方面的测试用例，与通过性测试比较接近，可以是功能、性能、安全领域的测试用例，但目的不会发生改变，就是想尽办法使其软件系统崩溃

2、失效性测试的测试顺序严格意义上必须在通过性测试之后进行，在未进行过通过性测试后所进行的失效性测试是不符合软件测试规范的，很可能会引起一些不必要的质量麻烦

3、失效性测试的测试方面更广泛，时间不定，在大多数情况下都可以进行失效性的测试且不受具体的人员限制

9.8 健壮性测试（Robustness Testing）：

  健壮性测试又称为容错性测试，用于测试系统在出现故障时，是否能够自动恢复或者忽略故障继续运行。

• 测试阶段：系统测试阶段
• 测试对象：整个软件系统
• 测试人员：系统测试工程师
• 测试依据：部分研发需求文档、预期系统健壮性目标等
• 测试技术：无技术划分
• 测试优点：提高系统的稳定性以及容错能力
• 测试内容：软件系统遇到报错异常的解决能力

补充说明：

1、健壮性测试关注整个软件系统出现异常解决的能力，如果出现了异常是否能够做到忽略异常或常识性的自主解决异常，保证系统的正常运行

2、健壮性测试通常在系统测试阶段或系统测试阶段后，过早的提前介入健壮性测试的意义不大，并且可能有其他风险

3、健壮性测试不等同于恢复性测试，容错测试一般是输入异常数据或进行异常操作，以检验系统的保护性，而恢复性测试是通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失、系统和数据是否能很快恢复

9.9 恢复性测试（Recovery Testing）：

  恢复性测试是测试一个系统从灾难或出错中能否很好地恢复的过程，如遇到系统崩溃、硬件损坏或其他灾难性出错。可恢复测试一般是通过人为的各种强制性手段让软件或硬件出现故障，然后检测系统是否能正确的恢复（自动恢复和人工恢复）。

• 测试阶段：系统测试阶段
• 测试对象：整个软件系统
• 测试人员：系统测试工程师
• 测试依据：部分研发需求文档、预期系统健壮性目标等
• 测试技术：无技术划分
• 测试优点：提高系统的稳定性以及容错能力
• 测试内容：软件系统遇到报错异常的解决能力

补充说明：

1、可恢复测试通常需要关注恢复所需的时间以及恢复的程度，主要包括硬件、软件、数据、通信四大方面

2、实际的硬件设备是有很多恢复性测试的手段，例如多生成树的网络技术、服务器负载均衡等，这些都可以有效的保证硬件服务器设备出现致命级错误时能够快速响应恢复，软件系统也有很多恢复性测试的手段，最重要需要防止的就是数据丢失

3、恢复性测试在我们身边是非常常见的测试手段，需要引起高度重视，一旦出现问题，对于软件产品来说是致命级的打击，以笔者的建议，大家都应该学习或至少了解并应用到实际项目当中

十、游戏行业术语：

10.1 封闭测试（Closed Test）：

  封闭测试又称为封测，是指游戏在很初期且有一些成型的时候，开放少部分名额对外的测试手段，封闭测试在内测之前，相当于在软件测试中的α测试前，主要用于收集玩家对于游戏第一印象以及对玩法的部分规划喜好等收集，同时也收集部分玩家所反馈的Bug以及建议性内容用以完善。

• 测试阶段：单元测试阶段之前或单元测试阶段
• 测试对象：整个游戏系统
• 测试人员：外部玩家
• 测试依据：玩家对游戏的自主认知
• 测试技术：黑盒测试
• 测试优点：快速反馈出游戏当前所存在的问题，提升游戏优化
• 测试内容：游戏玩法、系统的易用性、美观性、可玩性等

补充说明：

1、在游戏行业中大多数公司已经不实行封闭测试了，其主要原因有两种，第一种是大型的游戏不想过早的暴露给竞争市场，告诉市场我要出一款这一类的游戏，这样可能会增大其他竞争对手的打击力度，第二种是因为整个游戏有过多可以优化的内容和方向，内部策划可以完全不需要用户提供反馈以及建议性内容仍然可以继续进行游戏的开发制作，通常而言部分参与到游戏体验的体验人员有一定的奖励且有在签署保密协议，具有保密义务

2、封闭测试虽然很少公司在实行甚至是寥寥无几，但封闭测试更核心的点在于能够提前暴露出玩家的喜好和游玩意愿，如果做出一款自认为的精品游戏但玩家却不愿意买单，那么终究也是功亏一篑

3、封闭测试只能在单元测试阶段或之前介入，在单元测试阶段之后所对外的测试无法称之为封闭测试

10.2 删档测试（Delete file test）：

  删档测试多数属于对封测、内测的一种附加条件，很多游戏会有一定的存储数据，会明确告知玩家游戏会进行删档测试，其主要的删档原因是因为需要保证游戏上线后玩家的起点水平线一致

• 测试阶段：封测、删档测
• 测试对象：整个游戏系统
• 测试人员：外部玩家、内部玩家
• 测试依据：玩家对游戏的自主认知
• 测试技术：黑盒测试
• 测试优点：保证游戏上线后的数据公平性
• 测试内容：游戏玩法、系统的易用性、美观性、可玩性等

补充说明：

1、删档测试通常只存在于游戏行业，软件行业几乎没有类似的说法

2、删档测试可用于封测或本身删档测试，我们所说的公测是面向广大玩家的测试，并非删档测试，换而言之，如果存在删档行为，那么就不是公测

3、这里的“档”指的是玩家在测试期间在游戏内产生了游戏数据，而删档则是在停止测试后对玩家数据的清除

  

  
  
  好啦~以上就是本次文章分享的全部内容啦，你学会了吗？希望能给大家带来帮助哦！