软件测试分类

功能测试 —测试人员用鼠标去手动测试 （测试GUI）,点点点测试

自动化测试 —用程序测试程序 （测试API），解放双手

性能测试 —定位系统瓶颈，保证系统良好性能与稳定性

黑盒测试 —测试应用程序的功能，验证结果是否正确

白盒测试 —测试程序内部结构，以编程语言角度设计测试案例

软件测试功能分类

按测试阶段划分：

• 单元测试 Unit Testing


• 集成测试 Integration Testing


• 系统测试 System Testing

单元测试是针对基本单元（软件设计最小单位）进行正确性检测工作。

单元测试目的是检测软件模块是否完成了需求设计书中的要求。

将内存条放进插槽，检查规格是否符合，放入内存是否机器可以工作，此称为集成测试。

集成测试是基于单元测试的基础，将所有模块按照设计组装为一个子系统验证。

结合测试工作人员安排，测试环境配置，计算机硬件环境配置，整合在一起，进行测试工作。

单元、集成、系统测试的区别：

测试方法不同

• 单元测试属于白盒测试范畴


• 集成测试属于灰盒测试范畴


• 系统测试属于黑盒测试范畴

测试范围不同

• 单元测试检查单元内部数据结构、逻辑控制、异常处理等


• 集成测试检查模块之间的数据传输


• 系统测试检查整个软件是否满足了需求

回归测试

测试过程信息流

软件环境配置：需求文档，需求设计书，测试代码等

测试环境配置：测试需求说明书，测试计划书，测试用例等

回归测试定义

软件在测试或者其他活动中发现了缺陷且经过修复之后，应该进行回归测试活动。

目的在于验证缺陷是否正确的被修复，并且是否影响到其他的功能。

回归测试流程

1. 制定测试策略，回归测试策略


2. 确定回归测试版本


3. 根据回归测试策略执行回归测试


4. 回归测试通过，关闭缺陷跟踪单（禅道）


5. 回归不通过，缺陷跟踪单返回给开发人员，重新修复问题，再次回归

回归测试策略设计

完全重复测试

重新执行所有先前定义的测试用例，来确认问题修改的正确性，以及软件修改后可能造成的影响扩散。

选择性重复测试

有选择性的重新执行部分测试用例。

• 覆盖修改法，针对被修改的部分，重新构造测试用例验证已经没有缺陷


• 影响扩散法，再覆盖已修改的部分之上，分析其由于修改后是否间接造成了其他的额外缺陷


• 指标达成法，确定要达成的测试目标，例如测试用例覆盖率的百分比

回归自动化测试

由于回归测试的特性，是重新执行以前的成果，且无法预知需要回归几次后才能够通过测试标准，因此回归测试可能由于枯燥乏味造成测试人员积极性低下，测试质量下降。

因此我们得用机器人或是计算机程序解决此重复且乏味的测试活动，自动化回归测试应运而生。

良好的回归自动化测试活动包括如下：

• 程序自动运行


• 程序参数自我配置


• 测试用例自动管理


• 测试活动自动执行


• 测试信息日志自动收集


• 测试结果自动分析与输出
  实现测试用例自动化且进行结果分析，此类活动适合脚本化用例开发，进行逻辑控制，结果断言等，使用Python进行脚本开发灵活性较高。

对于特定系统或者复杂测试环境下，商业测试工具难以解决问题，自主研发自动化测试工具是灵活的方法。

验收测试

在软件生命周期流程上来看，软件研发阶段，测试活动包括单元测试、集成测试，系统测试等企业内部进行的测试活动。

在软件发布之前还有一个测试活动有真实用户介入，称为验收测试。

软件项目开发分为两种形式：

企业自研产品，如今日头条，王者荣耀，抖音

• 自己公司产品上线前由用户介入进行大范围内测，公测，检验软件正确性


• α测试


• β测试

公司承接业务开发，客户要什么就开发什么

产品研发好后，由客户方验收，检验产品需求正确性

验收测试概要

如何确定验收测试的执行时间、执行人员、执行环境

• 在通过内部系统测试活动以及软件配置审查之后，开始执行验收测试


• 验收测试是以人为测试活动为主，由测试人员和用户群体为代表开展测试活动


• 验收测试原则上是在用户基地进行，在用户同意下，也可以在软件开发公司内部模拟测试环境


• 验收测试以验收测试计划书或软件需求规格书进行标准化测试


• 验收测试结果分两种：


• 软件功能、质量、性能、界面特性与用户需求一致，用户接纳软件结果


• 反之，软件不被用户接受

α、β测试

α测试活动好比游戏的删档内测

• 由企业内部员工在模拟真实环境下进行的测试活动，进行结果反馈
  
  
  
  • 员工在开发人员的接入下，通过指导进行软件使用，且随时记录下使用过程中的错误
  
  
  
  


• 由真实用户在软件内测版本，开发版本环境下进行的产品体验/测试活动，进行结果反馈


• α测试的目的是评价软件产品的FLURPS(即功能、局域化、可用性、可靠性、性能和支持)。


• α测试即为非正式验收测试，尤其注重产品的界面和特色，

β测试好比游戏的不删档公测

• 由多个用户在实际操作环境下进行产品功能测试，如不同的手机型号，平台，网络环境等


• β测试不受开发者控制，自主开展测试活动，然后进行结果反馈。

测试过程分为四大阶段：

测试计划->测试方案->测试用例->测试报告

测试分类

软件测试分类说明

测试计划->测试设计->测试构建->测试执行->测试结果分析->测试评估和报告

黑盒测试

• 黑盒称为功能测试，一是按顺序检测程序每个功能，二是按功能模块优先级测试。


• 对软件的界面和功能进行测试，只考虑其整体特性，不考虑其内部实现


• 需要根据说明书、用户手册进行功能测试


• 如电视遥控器，就是一个标准的黑盒测试，我们不管是液晶的还是其他方式，只需要查看遥控器是否能控制空调


• 要求多组数据，多次测试才能得到准确的报告

黑盒测试类型

• 功能性测试，网站顺序使用的功能，手机使用功能，显示器是否正常显示…


• 容量测试，海量数据的处理，如1亿人用微信，1亿人用支付宝，这个数值容量


• 负载测试，系统在短时间内处理海量数据时，系统的健康状况指标


• 恢复性测试，小米手机秒杀活动太过热火，网站挂了，不该影响用户数据

白盒测试

白盒测试就打开了盒子，可以看到软件的内部代码

对比黑盒测试，白盒测试更严谨，对软件的源码和架构进行测试。

需要软件源代码，流程图等设计文档。

依据被测软件分析程序内部构造，并且根据内部结构设计测试用例，针对内部控制流程进行测试。

白盒测试是基于程序结构的逻辑驱动测试。

黑盒，白盒测试，相辅相成，白盒测试通过了，还得运行软件，查看软件的性能好坏，界面美丑，是否易用等等方面。

软件测试方法选择：

已知产品需求规格，但不知道其系统内部实现，进行黑盒测试证明需求是否实现。

已知产品内部实现，通过测试每种内部操作是否符合需求，属于白盒测试。

为什么要白盒测试

只验证产品基本需求得到实现，为什么要费力去测试产品内部实现呢？所谓知其然不知其所以然，仅黑盒测试，只能够满足一定的覆盖率，不能够消除更多隐藏的缺陷。

而白盒测试能够从内部逻辑检测，测试覆盖率更高，给予软件质量更高的保证。

白盒测试特点

• 理解软件需求


• 了解软件代码实现


• 检测代码逻辑


• 检测代码中文件路径


• 白盒测试成本较高

白盒测试的方法

• 静态分析：控制流分析，数据流分析，信息流分析


• 动态分析：逻辑覆盖测试（分支测试、路径测试）、程序插装

逻辑覆盖测试

• 语句覆盖


• 判定覆盖


• 条件覆盖


• 路径覆盖

逻辑覆盖率的统计通过程序插装可以体现

程序插装

• 调试代码时，往往会在程序中添加print()语句，能够很方便的打印出我们想要的信息，进一步了解程序执行的一些动态信息，比如程序执行顺序，计算后的变量的具体值等。


• 程序插装技术能够按照用户的要求，获取程序部分信息，是测试工作的有效手段。

黑盒测试和白盒测试的优缺点

黑盒测试的优点有:

1. 比较简单，不需要了解程序内部的代码及实现;


2. 与软件的内部实现无关;


3. 从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题;


4. 基于软件开发文档，所以也能知道软件实现了文档中的哪些功能;


5. 在做软件自动化测试时较为方便。

黑盒测试的缺点有:

1. 没有清晰的测试规格说明，测试用例难以设计


2. 自动化测试的复用性较低。


3. 无法控制程序内部路径，可能缺少较多测试点

白盒测试的优点有:

1. 帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。

白盒测试的缺点有:

1. 程序运行会有很多不同的路径，不可能测试所有的运行路径;测试基于代码，只能测试开发人员做的对不
   对，而不能知道设计的正确与否，可能会漏掉一些功能需求;系统庞大时，测试开销会非常大。

灰盒测试

介于白盒与黑盒之间，针对被测对象信息的不同，采用不同的测试方法。

• 检验被测对象整体特性信息，采用黑盒测试


• 检验被测对象内部实现，采用白盒测试


• 既要观察被测对象整体信息，又要观察内部具体信息，信息占比不同，这就是所谓灰盒测试。

软件测试文档

软件研发如同工厂生产，整个过程会有产品输出，输出的产品有两类

• 编译好的代码程序，如QQ.exe

  
  



• 用户使用手册，QQ使用手册

  
  



• 源代码,QQ源代码

  
  



• 需求分析：软件测试依据

  
  



• 概要设计：根据需求分析的内容，进行方案设计，明确是否覆盖到软件的需求

  
  



• 详细设计：包含方案、策略、架构、体系、接口名、接口文档、数据结构算法，保证开发过程细致

  
  



• 测试设计：测试需要进行哪些内容，包含哪些功能点，是否会影响其他功能，例如第三方支付页面跳转

  
  



• 测试用例：用例是进行测试的依据，测试的规范条文

  
  



• 测试报告：测试成功数量、失败数量、测试是否通过，允许产品上线等

  
  

动态测试与静态测试

静态测试：不运行被测试的软件系统，采用例如代码阅读、文档评审、代码分析等方式进行软件测试。

动态测试：按照预先规划好的测试数据与流程执行被测软件系统。

静态分析技术

定义：静态分析是不执行程序而分析程序的技术

功能：检查软件功能与需求是否一致，没有明显缺陷与歧义

测试点：

• 程序代码语法上是否一致性与完整性


• 文档描述是否规范、精准、便于查阅


• 程序与文档之间描述的一致性

动态分析技术

对软件系统进行数据驱动运行，与期望结果进行对比检查的过程。

• 脚本录制工具，进行反复测试，回归测试，如Robot、QTP、Selenium工具


• 性能测试工具，LoadRunner、Robot等