【软件测试理论基础（一）】

软件测试的定义及目的

什么是软件

软件是计算机程序，程序所用的数据以及有关文档资料的集合
软件 = 程序 + 数据 + 文档

软件测试的定义

1983年，IEEE将软件测试定义为：使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清“预期结果”和“实际结果”之间的差别

软件测试的目的

• 为了发现程序（软件）存在的代码或业务逻辑错误——找bug
• 为了检验产品是否符合用户需求——提高质量
• 为了提高用户的体验——提高用户体验

软件测试的分类

按测试阶段分类

• 单元测试
  主要是测试程序代码，为确保各单元模块被正确的编译，比如由具体到模块的测试，也有具体到类、函数、方法的测试等…——一般是开发完成；
  只能用白盒测试的方法进行

• 集成测试
  单元测试后，将各单元组合成完整的体系，测试软件单位之间的接口是否正确、数据能否正常传递；
  集成是通过接口实现的，因此集成测试就是对接口进行测试
  接口是后端提供的一个功能，作用是给不同的模块，让模块与模块之间能够通过接口互相发送数据

• 系统测试
  把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞等——根据测试用例，进行完整的系统测试

• 验收测试（UAT测试）
  主要指用户拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应的测试，以确定软件符合效果——用户对软件进行验收

  alpha测试：把用户请到开发方对软件进行测试，测试环境受开发方控制，测试人不多，测试时间比较集中。执行者：测试人员、用户、公司内部人员
  bate测试：测试环境不受开发方控制，测试人比较多，测试时间不集中

  alpha与bate区别：测试场所不一样；一般先做alpha测试，再做bate测试

按测试技术划分（是否查看代码）

• 黑盒测试
  把软件比作一个黑色的盒子，只需要关注外部的输入与输出，不关注内部逻辑
• 白盒测试
  把软件比作一个透明的盒子，需要关注内部逻辑的具体实现，而不需要关注外部的输入与输出
• 灰盒测试
  需要关注外部的输入与输出，也需要关注内部逻辑的具体实现

按被测试对象是否运行划分

• 动态测试
  运行被测系统而进行的测试
• 静态测试
  不用运行被测系统，而进行的测试：
  文档检查、代码走查、界面检查

按不同的测试手段划分

• 手工测试
• 自动化测试：替代手工 工具/写代码

按测试包含的内容划分

• 功能测试
  验证软件的业务功能是否符合需求；
  一般都是用黑盒测试的方法；
  最常见的测试内容

• 性能测试
  某个特定的时间，用户数量剧增，软件是否正常
  1.前端的性能
  打开软件的速度快不快；
  页面加载的速度快不快
  前端对CPU/内存之类的东西的消耗和占用的情况是都合理
  2.后端的性能
  这个软件最多可以容纳多少用户使用；
  某个功能最多可以支持多少用户同时使用；
  后端对数据的吞吐量；
  就是去测试这个软件的各项指标
  一般性能测试默认是对后端的性能进行测试：①在有指标的情况下看软件是否满足指标；②没有指标的情况下，去找出指标。指标就是后端程序对服务器的资源的消耗情况

• 安全测试
  对被测系统的安全进行测试

• UI测试
  被测系统的界面与原型图是否一致

• 易用性测试
  被测系统各个功能是否操作方便、是否容易理解、是否容易上手；
  学习成本越低越好；操作步骤越少越好

• 兼容性测试
  被测系统在不同的测试环境下是否都正常
  WEB：选择主流的浏览器的最近三个大版本进行测试；
  APP分iOS和Android两种：
  Android：系统很复杂，有很多延伸版本，需要综合的选取合适的手机进行测试，例如：市场占有率、安卓系统、品牌、屏幕形状、分辨率等。
  iOS：所有APP的标准都是一样的，只需要测试不同的iOS的版本就可以了（最近三个大版本）
  兼容性测试都是指前端的兼容性，做兼容性测试不需要对全部功能进行测试，只需要简单看看用起来是否正常，显示有无问题即可。

• APP专项测试
  此部分内容仅适用于APP
  1、安装、卸载更新测试
  检查APP能否正常安装；
  检查APP能否正常卸载；
  更新是指直接覆盖安装：低版本–>高版本、高版本–>低版本（禁止）、版本一致的情况下更新（不允许）
  2、权限测试
  APP在手机上，如果要正常使用，需要各种权限；
  权限测试需要关闭APP对应的权限，使用对应的功能，查看APP的结果是否合理；
  正常的结果：提示没有对应的权限，并引导用户去开启权限。
  3、场景交互测试
  测试APP在不同场景下能否正常使用；
  如：有电话、有短信、边听歌边使用、分屏、小窗模式、折叠屏；还有不同的APP相互切换；前后台相互切换。
  4、弱网测试
  在不同的网络下使用；
  2G、3G、4G、5G、WIFI (2G、3G一般不进行测试)
  测试方法：①直接让手机保持在不同的网络环境下使用即可；②模拟对应的信号即可（模拟网速方式方法很多，但本质都是通过限速实现）
  5、离线测试
  APP有的功能不联网可以正常使用；
  APP对于没有网络的提示是否友好；
  在没联网的情况下，会不会出现异常。
  6、资源争用测试
  APP对硬盘大小的使用情况；
  APP对内存的使用率是否合理；
  APP对CPU的使用率是否合理；
  APP对流量使用的情况；
  APP对电量使用的情况；
  在其他的APP正在使用扬声器、麦克风之类的情况下，被测APP也要使用，APP的表现。
  使用adb检查

其他测试

• 冒烟测试
  在进行正式测试前对主要核心功能进行的测试，一般是开发或者测试主管负责

• 回归测试
  开发对存在的问题的功能进行修改后，再一次进行的测试

• 探索性测试/自由测试（测试思维）
  根据自己的“项目经验”而进行的随意测试

• 打桩测试（MOCK）
  为了辅助开发或者测试去验证自己的代码是否完成的一种手段；
  对测试来说，打桩测试主要用于接口自动化测试，在编写代码的阶段使用。当开发的接口还未做好，但是测试有时间想要提前实现接口自动化的代码，此时就可以利用MOCK的技术，来模拟一些假的接口，作为测试对象使用。

• 埋点测试
  埋点测试是辅助测试的一种手段；
  1.让软件实际结果的表现变得更加直观
  2.收集用户的操作习惯

• 全链路测试
  按照软件操作的业务流程，把所有的业务串联起来，运行一遍

• 灰度测试
  在预生产环境上做测试的过程

软件的生命周期

定义

软件生命周期（SDLC）是软件开始研制到最终被废弃不用所经历的各个阶段

软件生命周期的各阶段

1. 问题的定义及规划
   主要确定软件的开发目的及可行性；
   指定项目总体开发计划。

2. 需求分析
   在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析，明确客户的需求，输出需求规格说明书最终版（原型图），提交评审

3. 设计
   把需求分析得到的结果转化为软件结构和数据结构，形成系统架构
   概要设计：主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等事物。
   详细设计：对概要设计钟表述的各模块进行深入分析等，其中需要包含数据库设计说明。

4. 编码
   按照详细设计好的模块功能表，变成人员编写出计算机可运行的程序代码

5. 软件测试
   在软件设计完成后要经过严密的测试，以发现软件在整个设计过程钟存在的问题并加以纠正
   测试方法主要有白盒测试和黑盒测试梁总建立详细的测试计划并严格按照计划进行

6. 运行维护
   软件维护是软件生命周期钟持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的需求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护主要包含纠错性维护和改进性维护两个方面。

软件生命周期模型

• 瀑布流模型
  第一个软件生命周期模型。规定了它自上而下、相互连接的固定次序，如同瀑布流水，逐级下落，具有顺序性和依赖性。每个阶段规定文档并需进行评审；
  问题定义及规划—需求分析—设计—编码—测试—运行维护；
  特点：自上而下、有顺序性
  缺点：测试介入时间比较晚，回溯成本高，测试周期比较长
  适用：需求不清、开发周期短的中小型系统
  

• 增量模型
  结合瀑布模型和演化模型的优点，在需求不清时，对最核心或最清晰的需求，利用瀑布模型实现。对后续需求进行重复开发（可能按照需求的优先级逐个进行），从而逐步建成一个完整的软件系统
  优点：保障核心功能实现、开发风险较低、保障最高优先级的功能的可靠实现、提高系统稳定性和可维护性
  缺点：增量力度难以合理选择、确定所有的需求服务较困难
  

• 喷泉模型
  每个阶段是相互重叠、多次反复的。每个开发阶段没有次序要求，可以并发进行，某个阶段随时补充其他阶段中遗漏的需求
  优点：提高效率、所短周期
  缺点：管理结构性较差
  

• 螺旋模型
  将开发过程分为四个类型：风险分析、制定计划、实施工程、客户评估。每次评估之后确定是否进行螺旋线的下一个回路
  优点缺点：降低风险，单身狗开发周期长
  适用：风险较高、开发周期较长的大型项目
  

• 敏捷开发模型
  是一种以人为核心、迭代、循序渐进的开发方式。强调以人为本，专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。就是把一个大项目分为多个相互连接，但也可以独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态
  特点：快、弱化文档，通过沟通实现需求分析

软件测试过程模型

• V模型
  瀑布流变种，将测试模块细化分解，把测试看作与开发同等重要的过程，每一测试阶段的前提和要求是对应开发阶段的文档；
  特点：测试在需求阶段介入–传统、周期长的项目
  

• W模型/双V模型
  相对于V模型增加了软件开发阶段中应同步进行的验证和确认活动。测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等开发输出的文档同样要测试。有利于今早地发现问题
  优点：测试的活动与开发同步进行，今早发现软件缺陷可降低软件开发的成本
  缺点：上一阶段完全结束，方可开始下一阶段的工作，无法支持迭代的开发模型。
  

• H模型
  将测试活动从开发流程中完全独立出来，使测试流程形成一个完全独立的流程，只要测试条件成熟来，测试准备活动完成了，测试执行活动就可以进行了
  

软件测试流程

测试需求分析阶段

阅读需求，理解需求，主要就是对业务的学习，分析需求点，参与需求评审会议

测试计划阶段

主要任务是编写测试计划，参考软件需求规格说明书、项目总规划，内容包括测试范围（来自需求文档）、进度的安排，人力物力的分配，整体测试策略的制定，和风险的评估与规避措施有一个制定，一般有测试负责人编写，当然我们可能也会参与相关的评审工作。
测试工作统筹安排：测试内容、哪些人、任务分配、测试环境、工作、时间安排

测试设计阶段

主要任务是编写测试用例，会参考需求文档（原型图）、概要设计、详细设计等文档，又不确定的也会及时和开发、产品经理沟通。用例编写完成后会进行评审。
测试用例：具体怎么来进行测试的文档

测试执行阶段

首先搭建测试环境，执行预测（冒烟），以判定当前版本可测与否，如果预测通过，正式进入系统测试，遇到问题提交BUG到缺陷管理平台，并对BUG进行跟踪，直到被测软件达到测试需求要求，没有重大bug，测试结束。

测试评估阶段

出测试报告，对整个测试的过程和版本质量做一个详细的评估。确认是否可以上线。

发布条件：剩余BUG数量很少+用例执行覆盖率
发布流程：开发打包–>运维/运营/开发–>部署到生产环境实现发不上线
环境：
1. 开发环境：开发人员写代码的环境
2. 测试环境：测试人员进行测试的环境（一个或一个以上）
3. 预发布环境（UAT环境）：验收测试（UAT测速）进行的环境
4. 生产环境：真是用户使用的环境