软件测试基础

学习目标

  • 认识软件测试
  • 了解软件测试定义、目的、原则
  • 熟练掌握软件测试流程
  • 掌握软件测试分类
  • 了解测试工程师的任职要求

1. 软件测试发展史

  • 1960年代是调试时期(测试即调试)
  • 1960年 - 1978年 论证时期(软件测试是验证软件是正确的)
  • 1979年 - 1982年 破坏性测试时期(为了发现错误而执行程序的过程)
  • 1983年起,软件测试已有了行业标准(IEEE829),它需要运用专门的方法和手段,需要专门人才和专家来承担。
  • 1990年起软件迅速发展,测试行业也更着发生了巨大变化,开始引入专业测试工具
  • 直到2005年软件测试在国内才慢慢出现对应岗位

2. 什么是软件测试

在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程

3. 为什么要进行软件测试

  • 软件总存在缺陷,有缺陷的软件也许仅仅给用户带来了不便,也可能是灾难性的(bug存在危害性)
  • 软件的应用越来越广泛(软件受众群体庞大)
  • 软件的工程化程度越来越高,复杂度越来越高(需要专业人士采用专业手段进行测试)
  • 竞争越来越激烈的企业生存环境(高质量软件得以生存)

4. 软件测试的两面性

  • 正向思维(验证软件正常工作):
    • 目的:评估被测系统的特性或能力,并确定是否能达到预期的效果
    • 做法:在设计规定的环境下运行被测系统的所有功能,直至全部通过
  • 逆向思维(假定软件有错误):
    • 目的:为发现错误而针对某个程序或系统的执行过程
    • 做法:寻找易出错的地方和系统的薄弱环节,试图破坏系统,想尽办法折磨系统,直至找不出问题。

5. 软件测试的目的

是想以最少的人力,物力和时间找出软件中潜在的各种错误与缺陷,通过修正各种错误和缺陷提高软件质量, 回避软件发布后由于潜在的软件缺陷和错误造成的隐患以及带来的商业风险。

  • 软件测试是为了发现错误而执行程序的过程。(发现错误不是唯一目的)
  • 测试是为了证明程序有错,而不是证明程序无错。
  • 一个好的测试用例在于它发现至今未发现的错误。
  • 一个成功的测试是发现了至今未发现的错误的测试。

注意:

  • 测试并不仅仅是为了要找出错误。需分析错误产生的原因和错误的分布特征,提出针对性的解决方案。
  • 没有发现错误的测试也是有价值的,更重要的是执行测试的过程

6. 软件测试的定义

使用人工或自动的手段来运行或测定某个软件系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

7. 软件测试的原则

  • 所有的软件测试都应追溯到用户需求。
  • 尽早地和不断地进行软件测试。
  • 完全测试是不可能的,测试需要终止。
  • 测试无法显示软件潜在的缺陷。
  • 充分注意测试中的群集现象(二八法则)。
  • 程序员应避免检查自己的程序。
  • 尽量避免测试的随意性。
  • 测试用例应包括合理的输入条件和不合理的输入条件。
  • 应当彻底检查每个测试的执行结果。
  • 妥善保存测试相关的文档及数据,为管理提供依据,为维护提供方便。

8. 软件测试流程

  • 需求分析:即测试启动阶段,参与软件需求评审、技术评审、UI评审等。从而全面了解需求,整理出测试需求。
  • 制定测试计划:根据产品需求分析,制定测试计划、测试风险分析,规划测试资源,对测试人员进行分工。测试人员根据项目大小及项目紧急度商讨测试交付件颗粒度。
  • 制定测试方案:描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。
  • 需求分解:详细分解每一个测试点,精确到每一个操作流程、每一个界面功能、每一个异常情况等。
  • 编写测试用例:根据不同的测试策略(黑盒、白盒、性能、自动化等等),采用不同的方法编写测试用例。
  • 测试用例评审:组织会议,对编写的测试用例进行评估,校验用例的合理性、有效性、可实施性、覆盖度、颗粒度等。
  • 搭建测试环境:搭建被测系统所依赖的环境,如:数据库服务、初始化的数据、前端服务、后端服务、硬件环境(手机、电脑)
  • 执行冒烟测试:对主流程进行测试,检查主功能是否已基本实现。若被测系统的基本流程不通畅,可驳回被测系统。
  • 执行测试用例:根据测试用例一条条进行操作执行,实际操作结果与预期结果进行比对,若不满足预期结果,则进行缺陷管理。直到所有测试用例被执行完毕。
  • 缺陷跟踪管理:测试人员提交bug后,需等待开发解决bug后,进行bug复测,直到bug被解决。
  • 回归测试:对老功能进行回归测试,确保新功能不会影响老功能的正常使用。
  • 验收测试(UAT测试):由需求提出方(产品经理、甲方)进行验收;或以内测(α测试)、公测(β测试)方式进行用户验收
  • 出具测试报告:针对项目的测试结果进行反馈,判定是否满足上限标准。对潜在风险、遗留bug等进行报告。

9. 软件测试对象

软件 = 程序 + 文档 + 数据,因此软件测试的对象包括[程序]、[文档]、[数据]

  • 针对程序测试:可采用不同的测试方法,根据测试流程进行常规测试工作。
  • 针对文档测试:积极参加各项文档评审,认真审核文档的合理性、准确性、可执行性。
  • 针对数据测试:当用户执行各项操作时,数据库会产生对应的变化,对该数据变化的准确性、实时性进行校验。

10. 按照阶段分类

  • ① 单元测试:也叫模块测试。对软件基本组成单元(软件设计的最小单位)进行正确性检验的测试工作,如模块、过程、函数或一个类的方法。
    • 是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。
    • 由程序员自己来完成,最终受益的也是程序员自己。
    • 单元测试属于白盒测试,也可以由白盒测试人员来完成。
    • 用代码验证代码。

  • ② 集成测试:也叫组装测试、联合测试、子系统测试或部件测试,是在单元测试的基础上,将所有模块按照概要设计要求组装成为子系统或系统,验证组装后功能以及模块间接口是否正确的测试工作。
    • 集成测试属于灰盒测试
    • 主要测试各单元与其它程序部分之间的接口、或模块之间的接口和接口数据传递的关系,以及模块组合后的整体功能
    • 可采用非增量式集成:先单独测试每一个模块,再一口气全部集成合并,进行一次整体测试。
    • 可采用增量式集成:采用逐步集成方式实现测试
      • 自顶向下增量式测试:从顶部模块开始组装,逐步向下延伸结合
      • 自底向上增量式测试:从底部模块开始组装,逐步向上延伸结合

  • ③ 系统测试:将已经集成好的软件系统与计算机硬件、外设、网络等其他元素结合在一起,在模拟实际使用的环境下,对软件系统进行一系列的组装测试和确认测试的工作。
    • 将被测系统与需求定义做比较,排查不符合需求、功能矛盾、功能缺陷。
    • 采用一定的测试策略:黑盒测试、性能测试、UI界面测试、安全性测试、文档测试、数据测试、兼容性测试、接口测试、配置测试、可靠性测试等

  • ④ 验收测试:也称交付测试,是在软件产品完成了单元测试、集成测试和系统测试之后,产品发布之前所进行的最后测试,是一项确定产品是否能够满足合同或用户所规定需求的测试
    • 属于黑盒测试,其主要目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务
    • 非正式验收测试:Alpha 测试(α测试)、Beta 测试(β测试)
      • Alpha 测试(α测试):由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。俗称内测。
      • Beta 测试(β测试):开发给一部分用户进行真实使用场景测试,并要求用户报告异常情况、提出批评意见,然后软件开发公司再对β版本进行改错和完善。俗称公测。
    • 正式验收测试:有正规的测试过程,需要制定测试计划、定义测试方案、选择测试用例,进行测试,结果提交。着重考虑软件是否满足合同规定的所有功能和性能,文档资料是否完整、准确,人机界面和其他方面

11. 按是否查看代码划分

  • 黑盒测试:也称为功能测试、手工测试和数据驱动测试。它将被测软件视为一个无法打开的黑盒,主要根据功能需求 设计测试用例和执行测试。不关心内部代码架构,只关心需要输入什么、操作什么,对应会产生什么样的结果。
    • 侧重于程序的外部结构,不考虑内部逻辑结构,针对测试软件界面和软件功能。
    • 使用的测试方法:等价类划分、边界值法、因果图、判定表、正交排列、场景法等。

  • 白盒测试:又称为结构测试、透明盒测试、逻辑驱动测试或基于程序本身的测试。它将被测软件视为一个透明的盒子,即清楚盒子内部的东西以及里面是如何运作的。着重于程序的内部结构及算法,通常不关心功能与性能指标。
    • 白盒测试主要应用在单元测试阶段
    • 主要使用两类测试方法:
      • 基本路径法:代码基本路径覆盖
      • 逻辑覆盖法:以程序内部的逻辑结构为基础设计测试用例。又可细分到以下6种方法:
        • 语句覆盖:被测程序的每一个语句至少执行一次,其覆盖标准无法发现运算中的逻辑关系错误。
        • 判定覆盖:使得程序中的每一个判断至少获得一次“真”和一次“假”,即使得程序流程图中的每一个真假分支至少被执行一次
        • 条件覆盖:使得运行这些测试用例时,使得判定中的每个条件至少有一次取真值,有一次取假值
        • 判定条件覆盖:使得被测试程序中的每个判断本身的判定结果(真假)至少满足一次,同时,每个逻辑条件的可能值(真假)也至少被满足一次
        • 条件组合覆盖:使得被测试程序中的每个判定中条件结果的所有可能组合至少执行一次
        • 路径覆盖:覆盖被测试程序中的所有可能路径,是最强的覆盖准则。

        案例:假设有一定如下的python代码:

        使用语句覆盖法设计用例:


        使用判定覆盖法设计用例:


        使用条件覆盖法设计用例:


        使用判定条件覆盖法设计用例:


        使用条件组合覆盖法设计用例:


        使用路径覆盖法设计用例:



  • 灰盒测试:介于白盒测试与黑盒测试之间的一种测试,灰盒测试多用于集成测试阶段,不仅关注输出、输入的正确性,同时也关注程序内部的情况。
    • 灰盒测试主要应用在集成测试阶段
    • 关注于系统内部模块之间的接口和交互
    • 不像白盒那样详细、完整,但又比黑盒测试更关注程序的内部逻辑。
    • 通过一些表征性的现象、事件、标志来判断内部的运行状态

12. 按功能作用划分

  • 兼容性测:试在特定的或不同的硬件、网络环境和操作系统平台上、不同的应用软件之间,验证软件系统能否正常地运行,以及能否正确存取原先版本的用户数据所进行的测试
    • 兼容性测试分三大类:
      • 硬件兼容性测试:与整机兼容、与板卡和外设兼容
      • 软件兼容性测试:操作系统/平台的兼容、应用软件之间的兼容、不同浏览器的兼容、数据库的兼容、软硬件配合兼容、网络环境兼容性测试、分辨率兼容性测试
      • 数据兼容性测试:不同版本间的数据兼容、不同软件间的数据兼容
    • WEB兼容性测试的侧重点:
      • 操作系统兼容性测试
      • 浏览器兼容性测试
      • 分辨率兼容性测试
    • C/S兼容性测试的侧重点:
      • 操作系统兼容性测试
      • 客户端版本与服务器版本兼容性测试

  • 安全性测试:对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。就是通过不同的测试方法,发现安全性的问题,包括各类问题:信息泄露、破坏信息的完整性、拒绝服务、非法使用(非授权访问)、窃听、业务数据流分析、假冒、旁路控制、授权侵犯(内部攻击)、抵赖(来自用户的攻击)、计算机病毒、恶意软件
    • 静态的代码安全测试:通过对源代码进行安全扫描,根据程序中数据流、控制流、语义等信息与其特有软件安全规则库进行匹对,从中找出代码中潜在的安全漏洞。
    • 动态的渗透测试:是常用的安全测试方法。是使用自动化工具或者人工的方法模拟黑客的输入,对应用系统进行攻击性测试,从中找出运行时刻所存在的安全漏洞。
    • 程序数据扫描:通常是进行内存测试,内存测试可以发现许多诸如缓冲区溢出之类的漏洞,而这类漏洞使用除此之外的测试手段都难以发现。

  • 性能测试:是通过自动化测试工具模拟多种正常,峰值,以及异常的负载情况下对系统各项性能指标进行的测试
    • 硬件性能:通过施压对手机、服务器、客户机的各项性能指标进行的测试
    • 软件性能:通过施压对程序内部的接口、模块各项性能指标进行的测试

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

  • 自动化测试:通过工具或者脚本的方式代替部分手工测试,来达到测试的目的
    • 自动化测试分类:web自动化、app自动化、接口自动化
    • 自动化测试常用于回归测试、日常功能巡检,有效节约人力成本
  • app测试:针对的是android和ios两大主流操作系统,主要考虑的就是功能性、兼容性、稳定性、易用性(也就是人机交互)、性能、应用交叉、弱网使用。
    • 功能性:常规的黑盒测试,根据需求编写测试用例,执行测试,bug追踪管理
    • 兼容性:对市场上主流的设备安装应用执行测试,确保都能正常运行;兼容性方面考虑手机的版本、型号、分辨率
    • 稳定性:执行大量monkey测试,寻找闪退、系统崩溃、无响应等问题
    • 易用性:考虑界面是否吸引人、容易理解、界面整洁、简单、无错别字、点击范围、操作便捷等
    • 性能:靠工具来实现的CPU占用、内存占用、电池温度等监测,获取各项性能指标
    • 应用交叉:被测系统在运行时,被其他应用所干扰时能否正常运行,如:电话、短信、推送消息、系统提示、充电等
    • 弱网:当手机处于信号低、无信号场景下,能否正常使用app、app是否有对应的预案
  • 大数据测试:对采用大数据技术的系统或者应用的测试活动

13. 其他划分

  • 冒烟测试:对系统的基本功能进行简单的测试。强调程序的主要功能进行的验证,不会对具体功能进行更深入的测试。常常属于提测指标之一。
  • 回归测试:也叫衰退测试。验证新研发的功能、新修改的bug是否会影响老功能的正常运行。往往会在当前版本测试完成后,收尾进行回归测试。
  • 随机测试:也叫猴子测试。是根据测试者的经验对软件进行功能和性能抽查,测试数据是随机产生的,在测试用例之外。非主流测试手段。
  • 静态测试:不运行被测软件,一般是以人工对代码进行走查、文档进行评审、页面进行对比等
  • 动态测试:通过实际执行代码、执行被测系统,去发现潜在代码错误、业务缺陷的测试方法

14. 软件测试工程师的职责

  • 参与各项评审,如需求评审、技术评审、UI评审、用例评审等
  • 管理、配置、维护测试环境
  • 执行软件测试
  • bug缺陷管理,协助开发人员分析定位问题
  • 出具各项测试文档:测试计划、测试方案、测试用例、bug缺陷报告、测试结果等
  • 参与/组织各项技能培训,引入、学习、分享新技术

15. 软件测试工程师的分类

  • 按职能划分:
    • 功能测试工程师
    • 自动化测试工程师
    • 性能测试工程师
    • 安全测试工程师

  • 按测试对象划分:
    • web测试工程师
    • 数据库测试工程师
    • C/S测试工程师
    • APP测试工程师

  • 按职位划分:
    • 测试部门经理
    • 测试技术总监
    • 测试主管
    • 测试项目经理
    • 高级测试工程师
    • 中级测试工程师
    • 初级测试工程师
    • 测试设计人员
    • 测试执行人员
    • 测试协助员
    • 测试技术支持

  • 总分类:
    • 软件测试开发工程师
    • 软件测试工程师

16. 软件测试工程师的技能要求

  • 测试理论基础、计算机基础
  • 熟练掌握项目流程、测试流程、用例设计方法、测试规范、缺陷管理流程
  • 掌握功能测试、接口测试、自动化测试、性能测试(至少精通一项)
  • 掌握主流数据库MySQL、oracle的操作,熟练编写sql
  • 熟练使用postman、jmeter、禅道、xshell、fiddler、Charles、Navicat等测试相关工具
  • 熟悉web、Android、IOS、windows、Linux等平台特性
  • 熟悉java/python等主流编程语言中的一种

17. 软件测试工程师的职业素养

  • 责任心、细心、耐心、专心、自信心
  • 良好的沟通能力、语言文字表达能力、问题描述能力
  • 积极主动,较强团队协作能力
  • 较强的学习能力
  • 逻辑思维能力、发散思维能力
  • 幽默感、记忆力、怀疑精神、自我督促、洞察力、发现问题的敏锐度
  • 处理日常事务的能力和处理紧急突发事件的能力
  • 各行各业广泛的业务知识