软件测试基础

课程前言

测试是干啥

• 软件测试 : 软件质检工作(查找软件问题,保障软件质量)

从事的岗位

• 1、功能测试工程师
• 2、性能测试工程师
• 3、服务端测试工程师
• 4、自动化测试工程师
• 5、大数据测试工程师
• 6、移动端测试工程师

发展前景

人才缺口

• 软件测试缺口是 JAVA 1.8倍，而 JAVA 现有岗位人才是测试的 5 倍以上

发展路线

• 软件测试工程师

• 自动化测试工程师

• 性能测试工程师

• 测试开发工程师

• 测试架构师

• 首席技术官

• 推荐的发展路线 :

  • 倾向于服务端的测试工程师
    • 网站服务端
    • 大数据
    • 人工智能
    • 云计算

• 不推荐的发展路线 :

  • 倾向于移动端的测试工程师
    • 安卓 , IOS , 小程序 , 鸿蒙

岗位薪资

• 软件测试 1 线均薪 14K+，是金融行业 1.3 倍，其他行业 1.5 倍
• 初级测试工程师 :
  • 刚入行
  • 8k - 9k
• 中级测试工程师 :
  • 1-3年
  • 9k - 15k
• 自动化/性能测试 :
  • 3-5年
  • 15k - 25k
• 资深测试/测试开发 :
  • 5-8年
  • 25k+
• 测试总监 :
  • 8年+
  • 30k+

岗位提升

基础班学习目标

基础班目标

• 能独立完成软件的功能测试工作

• 能复述软件测试的定义

• 能说出7种测试分类的区别

• 能说出质量模型的重点5项

• 能说出测试流程的6个步骤

• 能说出测试模板8个要素

基础班学习路线

基础班具备的能力

• 知道测试主要工作内容
• 能够掌握常用用例设计方法及应用场景
• 能够使用缺陷管理工具对缺陷进行管理
• 能够对web项目功能进行实战

怎么学

学习方式

复习方式

软测测试学习路线

• 阶段一：基础理论篇
• 阶段二：Linux系统和 MySQL 数据库
• 阶段三：功能测试项目实战
• 阶段四：第一次的面试指导
• 阶段五：Python编程
• 阶段六：接口测试及接口自动化测试
• 阶段七：Web自动化测试
• 阶段八：JMeter性能测试
• 阶段九：LoadRunner 性能测试
• 阶段十：综合就业指导

就业方向

• 就业方向该如何选择？
  • 方向（一）：功能测试+接口测试
  • 方向（二）：功能测试+性能测试
  • 方向（三）：功能测试+web自动化

小结

• 测试是做什么

  • 查找软件问题，保障软件质量。

• 行业前景

  • 薪资可观(>1W)
  • 岗位缺口大(比 java 岗位还多)

• 适合人群

  • 专科及以上、年龄19~35.

  • 细心、耐心、逆向思维

• 岗位发展

  • 技术方向、管理方向

• 学完能力

  • 具备对所有软件的功能进行测试能力

软件及软件测试简介

什么是软件

• 软件是计算机程序、程序所用的数据以及有关文档资料的集合。
  • 软件 = 程序 + 数据 + 文档
• 软件是计算机的灵魂。软件又可以分为两大类:系统软件和应用软件。
  • 系统软件 : 系统软件是生成、准备和执行其他程序所需要的一组文件和程序。
    • 如操作系统 Windows ,数据库 SQL-Server , 驱动程序(网卡， 声卡)， java 语言系统编译环境等。
  • **应用软件 **: 计算机用户为了解决某些具体问题而购买、开发或研制的各种程序或软件包。
    • 如 APP, QQ，微信等。
• 提问 : 应用软件测试的对象是什么呢
  • 程序 + 数据 + 文档

软件应用架构

C/S架构

• C/S : (client-server) 这种就是我们一定要安装一个客户端才能够使用的软件,就叫 C/S

  • 优点 : 稳定，速度快
  • 缺点 : 每次更新，都需要更新服务端与客户端，比如说超市收银系统每次更新每台电脑都必须重装客户端，特别是有分店的情况，人力物力财力都很大。

• 提问 : 移动端 APP 是什么架构的呢?

  • C/S 架构

B/S架构

• B/S : (browser-server) 只需要一个浏览器，就可以访问服务的，就是 B/S。
  • 优点 :只需要更新服务器就 OK ,不需要去更新浏览器。用户主动性比较高。比如说天猫、淘宝。
    • 很多软件为了满足不同用户的需求,两种架构应用都存在
• 提问 : 小程序, h5 , 公众号是什么架构的呢?
  • 既不属于 C/S 架构,也不属于 B/S 架构,属于一种新型架构

简版架构

• 用户层 : 我们能够直接看到和操作的部分
• 服务层 : 我们看不到，但负责了软件的核心处理逻辑的部分
• 存储层 : 我们看不到，但负责了存储一切数据的部分

软件的基本组成

软件产生过程

软件的生命周期

• 软件生命周期(SDLC, Systems Development Life Cycle)是软件开始研制到最终被废弃不用所经历的各个阶段。

什么是软件测试

• 软件测试的定义:

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

• 软件测试的本质 :

  • 技术上要以任何方法和手段发现Bug
  • 思维上要以多视角的方式观察项目，预防Bug

• 问题 : 淘宝购买东西的过程，是软件测试么

  • 不是, 因为目的不是为了发现问题,只是单纯的购物

软件测试的目的

• 任何的产品生产出来都是有可能存在瑕症的

• 软件测试是保证软件产品质量最重要的一环

• 软件测试的目的:用最少得人力,物力,财力,找到软件中的问题并修复 , 提高软件测试质量 , 减少软件缺陷(bug)，保障软件质量！从而降低商业风险

• 我们做软件测试的目的什么:

  • 为了发现程序(软件)存在的代码或业务逻辑错误
    • 是最基础的需求,第一优先级发现错误, 属 P1 级
      • 业务逻辑可以从 <<需求规格说明书>> 知道
  • 为了检验产品是否符合用户需求
    • 跟用户要求实现方法一致, 以及满足需求规格说明书的需求 , 属 P1 级
  • 为了提高用户的体验
    • 比如输入用户名密码错误,有友好的提醒
    • 比如提高软件的性能,流畅性等

• 为什么开发不自己测试 :

  • 惯性思维

    • 比如 : 这个就是这么用的,是用户不会用

  • 自我认同感

    • 比如 : 我开发的肯定没有bug

  • 可能存在的需求理解偏差

    • 比如 : 产品 , 开发, 测试对同一需求的不同理解

项目的构成

• 需求阶段 : 产品经理负责需求调研、竞品分析、产品原型设计
• 需求评审 : 项目组所有成员都参加，产品经理为大家讲解产品需求的逻辑
• 设计阶段 :
  • UI/UE : 网页、图片设计
  • 架构师 : 软件架构设计、选择技术栈
• 开发阶段 :
  • 前端开发 : 负责实现网页业务逻辑部分的编码
  • 后端开发 : 负责实现服务端业务逻辑部分的编码
• 测试阶段 :
  • 测试工程师 : 负责软件实现后的质量检查
• 运营维护 :
  • 运维工程师 : 负责线上服务器的服务部署与维护
  • 数据库管理员 : 负责线上数据库的服务部署与维护

小结

• 1、什么是软件
  • 控制计算机硬件工作的工具。
• 2、什么是软件测试
  • 使用技术手段验证软件是否满足使用需求
• 3、软件测试目的
  • 减少软件缺陷(bug)，保障软件质量!

测试主流技能

功能测试

• 功能测试主要验证程序的功能是否满足需求

自动化测试

• 使用代码或工具代替手工，对项目进行测试。

接口测试

• 使用代码或工具对服务端提供的接口进行测试。

• 工具实现

• 代码实现

性能测试

• 模拟多人使用软件，查找服务器缺陷。
• 工具实现

• 代码实现

小结

• 功能测试：
  • 测试主要验证程序的功能是否满足需求
• 自动化测试：
  • 使用代码或工具代替手工，对项目进行测试
• 接口测试：
  • 使用代码或工具验证程序中的接口是否访问正常
• 性能测试：
  • 模拟多人使用软件，查找服务器缺陷

测试分类

按测试阶段划分

• 按测试阶段划分
  • 单元测试、集成测试、系统测试、验收测试、α 测试，β 测试
    • 单元测试 : 针对单个功能模块的程序源代码进行测试 , 由开发自测
    • 集成测试 : 又称接口测试，主要针对模块与模块或系统与系统之间的接口进行验证 , 即多个功能模块的集合测试
    • 系统测试 : 所有需要测试的需求模块集体测试 ,通常是 2 到 4 轮
    • 验收测试 : 产品验收和客户(甲方)验收
    • α 测试 : 公司内部人员进行测试 , 测试和开发不参与 , 允许有 3 , 4 , 5 级的bug , 不允许有 1 , 2 级的 bug
    • β 测试 : 真实使用环境下的测试 , 测试和开发不参与 , 允许有 3 , 4 , 5 级的bug , 不允许有 1 , 2 级的 bug

按代码可见度划分

• 黑盒测试、白盒测试、灰盒测试(接口测试)
  • 黑盒测试 : 看不见里面的实现，只能看见输入，以及输出的结果(实际结果)
  • 白盒测试 : 也叫单元测试 , 代玛走查，里面过程需要透明可见，一般由开发自查自测 , 对测试要求比较高
  • 灰盒测试 : 接口测试

按测试对象是否运行划分

• 被测试对象是否运行划分
  • 动态测试、静态测试(文档检查、代码走查)
    • 动态测试 : 有数据的走向,需要发起网络请求,需要同后台进行数据交互
    • 静态测试 : 没有数据走向,不需要发起网络请求,不需要同后台进行数据交互

按测试手段划分

• 按不同的测试手段划分
  • 手工测试(点工)、自动化测试(工具+代码)
    • 自动化测试 :
      • 接口自动化测试
      • 界面自动化测试
      • 基于 python 语言
      • 基于 JMeter 工具

按测试内容划分

• 按测试包含的内容划分六个方面 :

  • 测试任何一款软件都需要覆盖的内容 , 一个功能 + 5 个非功能

  • 功能测试(优先)、界面测试、兼容性测试、易用性测试、性能测试、安全测试

    • 易用性测试 : 站在用户角度思考问题

其他测试分类

• 其他测试
  • 回归测试、冒烟测试、探索性测试/自由测试(测试思维)
    • 回归测试 :
      • 提交 bug, 由开发修复后, 再由测试重新进行回归验证
      • 回归测试把之前测试过了的功能，进行第二次测试，属于回归测试
    • 冒烟测试 :
      • 主体功能(核心功能)没有通过测试，后续其他功能就不需要再去进行测试了
    • 探索性测试 :
      • 随意发挥，没有固定方法 , 可以学习别人的测试思维和测试角度
      • 依据文档，凭经验发散思维测试

小结

• 1、按阶段划分
  • 单元测试 : 针对程序源代码进行测试
  • 集成测试 : 针对程序接口进行测试
  • 系统测试 : 针对程序功能、非功能进行测试
  • 验收测试:使用不同用户(内测、公测) 进行测试
• 2、按代码可见度划分
  • 黑盒测试:不关注源代码，针对程序UI功能进行测试。
  • 灰盒测试:针对程序部分代码进行测试(接口)
  • 白盒测试:针对程序源代码进行测试
• 3、其他
  • 性能测试: 归属专项测试
  • 自动化测试: 归属功能测试

常见面试题

• 什么是软件测试?软件测试的目的是什么?

• 软件测试分类都有哪些?

• 什么是黑盒测试?白盒测试?区别是什么?

• 什么是冒烟测试?

  • 大规模执行测试之前，针对程序主功能进行验证，保证程序具备可测性。

• 提测的标准是什么?

  • 冒烟测试通过

• 系统测试和黑盒测试重点核心是功能测试

• 集成测试和灰盒测试又称接口测试

• 单元测试和白盒测试是对代码进行测试

• 自动化测试归属功能测试

• 性能测试、安全测试归属专项测试

测试模型

质量模型

• 质量模型提供测试设计的不同角度视野和验证方向
• 衡量一个优秀软件的维度
  • 功能性 : 功能满足需求
  • 性能效率 : 性能满足实际需求
  • 兼容性 : 软件能与主流硬件和软件兼容
  • 易用性: 便于使用
  • 可靠性 : 性能和功能应用可靠
  • 信息安全 : 信息在传输或者存储过程的安全程度
  • 可维护性 : 便于维护
  • 可移植性 : 具备迁移和便捷性

案例分析1

案例需求

• 1、开发一款网络游戏(要求: 10个主功能)
• 2、游戏支持web (浏览器) 端、App端
• 3、游戏上线后预计每日，20W用户玩家在线

功能性

性能

兼容性

易用性

可靠性

安全性

可移植性

可维护性

瀑布模型

介绍

• 在1970年人类整理了第一个软件生命周期，即瀑布型生命周期模型也叫瀑布模型。规定了它们自.上而下.、相互衔接的固定次序，如同瀑布流水，逐级下落，具有顺序性和依赖性。每个阶段规定文档并需进行评审。
  • 包括以下 6 个阶段 :
    • 软件计划
    • 需求分析
    • 软件设计
    • 程序编码
    • 软件测试
    • 运行维护

优缺点

• 优点 : 严格的规定了每个阶段必须提交的文档，项目的推进必须按照一定的顺序来做
• 缺点 : 严重依赖项目文档，脱离用户真实需求，在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的，很可能导致最终开发出的软件产品不能真正满足用户的需要。也不适合需求模糊的系统。

问题的定义及规划

• 收集用户需求+初步需求文档+确定可行性(产品市场客户)
  • 优秀的项目,取决于产品经理
• 主要确定软件的开发目的及其可行性。制定项目总体开发计划。并得出初步需求文档
• 可行性:
  • 市场营销的可行性
  • 研发是否能实现

需求分析和评审

• 在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析, 明确客户的需求(需求评审–产品，开发，测试)，输出需求规格说明书终版(原型图)。
• 得出最终的需求文档
  • 包含原型图 , 原型图由产品经理制作

设计

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

编码

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

软件测试

• 软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正.
• 测试的方法主要有白盒测试跟**黑盒测试(灰盒测试)**两种。
  • 建立详细的测试计划并严格按照计划进行。
• 单元测试(Unit test) :主要是测试程序代码,为的是确保各单元模块被正确的编译,比如有具体到模块的测试，也有具体到类，函数、方法的测试等。
  • 一般是由开发自测、和测试白盒测试
• 集成测试:单元测试后,将各单元组合成完整的体系,测试软件单位之间的接口是否正确、数据能否正常传递。
  • 接口测试，灰盒测试
• 系统测试:把软件系统搭建起来,按照软件规格说明书中所要求，测试软件其功能、界面、兼容、易用、性能、安全等是否和用户需求相符合，在系统中运行是否存在漏洞等。
• 验收测试:主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到符合效果的。

运行维护

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

V模型

介绍

• RAD (Rap Application Development,快速应用开发)模型是软件开发过程中的一个重要模型,由于其模型构图形似字母V,所以又称软件开发的V模型。
• 它通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。
  • 在拿到需求规格说明书之后,进行需求评审完毕,测试就需要开始编写测试用例

• 系统测试用例根据需求说明编写出的。
• 集成测试用例根据概要设计中模块功能接口等实现方法编写出来
• 单元测试的测试用例是和详细设计实现的，在研发人员做详细设计的对应的测试人员也就把测试用例写了

优缺点

• 优点 : 包含了从底层（单元测试）到顶层的测试（验收测试）更清楚的标识了开发和测试的各个阶段自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。
• 缺点 : 自上而下的顺序导致测试工作在编码后，不能及时的进行修改实际工作中，需求经常变化，导致V模型步骤反复执行，返工量很大，灵活度较低。

W模型

介绍

• 也是一种传统软件开发模型，由两个V字型模型组成，分别代表测试与开发过程，测试的活动与软件开发同步进行测试的对象不仅仅是程序，还包括需求和设计相对与V模型可尽早发现软件缺陷可降低软件开发的成本

• 优点 :

  • 测试伴随整个产品开发周期，测试对象不仅是程序还有需求、设计文档
  • 测试介入较早，及早发现问题，降低修复成本
  • 分阶段工作，方便项目整体管理

• 缺点:

  • 实施起来比较复杂，难度大，对于需求阶段和设计阶段的测试设计要求较高
  • 开发和测试依然是线性的关系，需求的变更和调整，依然不方便
  • 如果没有文档，无法执行W模型
  • 对于项目组成员的技术要求更高

敏捷开发模型

• 市场主流,非常重要

• 从 1990 年代开始逐渐引起广泛关注,是一种以用户需求为核心、切分多个子项目快速迭代、收集用户需求的开发方法。强调以人为本，专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。就是把一个大项目分为多个相互联系,但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

  • 以用户需求为核心 :
    • 强化人与人之间的沟通，弱化文档(需求/测试用例/测试报告),提高沟通效率，降低成本
  • 切分多个子项目快速迭代 :
    • 先做某一指定功能,先发布上线抢占市场
    • 分多个子模块,分开做,快速迭代
  • 收集用户需求 :
    • 根据市场的反馈即时调整后续功能

小结

• 质量模型：
  • 功能、性能、兼容、易用、安全、可靠性、移植性、维护性

常见面试题

• 问题 : 项目发布上线后,测试是否还需要测试 ?
  • 在线上环境/生产环境,要经过冒烟测试(核心功能的测试)
    • 若不通过,出问题立马修复,实在不行就版本打回
• 问题 : 项目已经在客户使用阶段，运行维护阶段出现问题，测试需不需要跟踪 ?
  • 已经交付甲方, 看合同需要维护多久 , (由运维负责 , bug 由运维提交给产品经理)
    • 纠错性维护 : 如果有 bug ,经由产品经理确认后才可以改
    • 改进型维护 : 产生新的需求, 得加钱

软件测试流程

软件测试工作流程

软件测试工作流程

• 1、了解需求
• 2、测试用例设计
• 3、测试环境准备
• 4、根据用例执行测试
• 5、Bug记录与上报
• 6、Bug修复
• 7、Bug修复后的验证
• 8、形成测试报告
• 9、项目上线
• 10、生产环境验证

测试各阶段分析

• 测试需求分析 :

  • 阅读需求,理解需求,主要就是对业务的学习,分析需求点。
  • 参与需求评审会议,确定各部门对需求的理解一致, 站在不同角度对需求进行查漏补缺

• 测试计划 :

  • 编写测试计划，参考软件需求规格说明书、项目总体计划，内容包括测试范围(来自需求文档)、进度的安排，人力物力的分配，整体测试策略的制定，和风险的评估与规避措施有一个制定，一般由测试负责人编写，当然我们可能也会参与相关的评审工作。
  • 测试计划通常由测试负责人编写测试计划

• 测试用例编写 :

  • 主要任务是编写测试用例，会参考需求文档(原型图)、概要设计、详细设计等文档,有不明确的也会及时和开发、产品经理沟通。用例编写完成后会进行评审。

• 执行测试用例 :

  • 首先搭建测试环境，执行预测(冒烟)， 以判定当前版本可测与否,如果预测通过，正式进入系统测试(2-4轮) , 遇到问题提交Bug到缺陷管理平台，并

• bug缺陷管理

  • 对 bug 进行跟踪，直到被测软件达到测试需求要求，没有重大bug,测试结束。
    • 提出 bug , 验证 bug , 关闭 bug
    • 优化、完善测试用例

• 测试评估 :

  • 生成测试报告，对整个测试的过程和版本质量做一个详细的评估(剩余bug数量/严重程度,测试用例的覆盖率)。确认是否可以上线。
  • 测试报告 : 一个项目由测试负责人出一份测试报告，不用每个测试人员都写。

• UAT 验收测试 :

  • 部署到 UAT 测试环境，由产品或者领导来验证功能。
  • UAT : 验收测试(预发布环境)
  • 一般由负责人或者甲方进行测试

系统测试

• 第一轮 : 最初测试并提出 bug , 该轮问题最多 , 通常用时 1 天
• 第二轮 : 对开发修改 bug 后提交的新版本,进行回归验证第一轮的 bug , 并继续测试没有测试完的功能 , 以及各功能的细测 , 通常用时 1 - 2 天
• 第三轮 : 第二轮存在的问题以及更细致的测试,更多场景的验证,确保需求不遗漏,不漏测试 . 最后评估项目质量,提交测试报告,发布上线
• 注意点:
  • 测试轮数的多少,根据测试人员数量和需求的多少决定
  • 测试报告通常包含以下各项 :
    • 测试用例覆盖率
    • bug 验证程度
    • bug 人员分配
    • bug 总数
    • bug 清单
    • 开发周期
    • 测试周期
    • 预估风险(提前预警)
    • 最终结论(决定此次版本是否可以上线)
    • …
  • 发布上线 :
    • 冒烟测试
      • 不通过
        • 紧急修复
        • 版本回滚 , 例如: 1.0 (线上) — 1.1 (更新,但出错了) – 1.0 (回滚回 1.0)
        • 再次上线
    • 不要留下测试数据,不能动生产环境的数据,找开发删除,不能自己自行删除

冒烟测试

• 冒烟先检测开发提交的版本有没有达到可以测试的标准
• 验收阶段客户进行的冒烟测试
• 线上环境/生产环境进行冒烟测试(重点)

小结

• 如何开展软件的测试工作？
  • ① 需求评审
  • ② 编写测试计划
  • ③ 用例设计
  • ④ 用例执行
  • ⑤ 缺陷管理
  • ⑥ 测试报告

测试需求分析

测试需求是什么

• 测试需求主要解决“测什么”的问题

  • 一般来自需求规格说明书中原始需求
  • 需求文档由产品收集整理,需求来自市场调研或者甲方客户

• 测试需求应全部覆盖已定义的业务流程（逻辑)，以及功能和非功能方面的需求

  • 测试分析需求文档
    • 怎么测试?测试什么东西?测试点?
  • 开发分析需求文档
    • 分析需求文档决定怎么去开发?怎么代码编译实现功能?怎么达到需求要求的效果?

• 示例:淘宝

  • 注册—登录–浏览商品—加入购物车/立即购买—提交订单—支付–物流跟踪―(主流程/核心业务)

    • 主流程/核心业务—冒烟测试—正向流程
    • 其他分支/异常场景—反向流程
      • 注册失败(已注册/不规范)—登录失败(用户名/密码错误)—商品库存不足/已下架—购物车(空/有)–立即购买(页面跳转)–支付(超时/余额不足)
      • 依据提示信息
      • 异常场景—站在用户的角度，提高用户体验
      • 业务流程尽可能多的去覆盖各个路径，多花时间去了解/通透需求文档，梳理业务逻辑/流程

  • 功能与非功能

    • 功能:第—优先级保证正确性

      • 业务流程(功能+业务)—正常/异常

    • 非功能:界面、兼容、易用、安全、性能

    • 注意:作为测试，不要为了提 bug 而提 bug，一定先从功能业务发现问题，提高产品质量

为什么需要测试需求

• 简而言之︰只有明确了测试需求，才能知道测试什么内容，怎么去测试?什么时候开始测试?多少人?什么环境测试?测试范围?
  • 怎么去测试? —测试方法(用例设计–四大金刚)和工具(接口/性能/数据库)
  • 什么时候开始测试?–测试时间评估
  • 多少人测试?—-人力分配
  • 什么环境下测试?
    • PC 客户端( windows8/10 32/64bit )、web端( chrome/firefox/lE )、app ( 安卓/IOS )、小程序/H5
  • 统一的统筹安排工作—测试负责人(测试计划)—通过需求分析文档得到
  • 测试计划—会在组内评审—信息同步

如何开展测试工作

• 拿到一个新项目后，如何开展测试工作?步骤?
  • 第一步:先了解这是一个什么项目?什么架构?PC? App?web?涉及哪些端?
    • 大概业务逻辑是怎么样的, 业务流程要做一个整体的把握
      • 腾讯课堂:分不同角色来区分业务流
        • 学生端:注册—登录–报名课程–点击进入课堂—上课体验—文字发言–举手发言
        • 教师端:注册—登录–我的排课–点击进行上课—分享屏幕(摄像头)—发声说话
  • 第二步:细化分析（分模块/约束条件/要点），具体测试点―—-正向+异常场景
    • 注册:手机?邮箱?密码要求?验证码要求?
    • 登录:第三方?自己注册登录?授权?错误次数?记住密码?密码是否明文显示?
      • 测试点需明确
  • 第三步:功能之间的模块交互测试(模块的关联测试)
    • 注册＋登录
      • 前端(用户视角)＋后端(后台视角)的交互测试
      • 新增–修改–详情–查询–删除
  • 第四步:非功能的测试(界面(设计图)、兼容(产品/客户)、安全(产品)、性能(产品)、易用(用户角度))

常见面试题

• 遇到隐性需求怎么办?

  • 充分理解需求文档，参考成熟产品(同类产品/竞品分析)，与产品沟通(先自己尝试解决)，知识储备经验

• 给你一个带有 logo(A4纸，盆栽，行李箱，电梯，N95I罩）的水杯，你会如何去测试?—经典面试题(选择1个/多个)

  • 测试水杯

    • 遇到这种面试题，回答思路：

    • 因为没有明确需求，所以根据我自己的理解，我认为主要可以从以下几个方面考虑：

      • 功能测试：装水、喝水、是否可以保温、容量多少？漏水

      • 界面测试：外观、logo是否正确，大小、形状、颜色

      • 易用性测试：方便拿？方便携带，喝水友好，盖子好不好拧

      • 兼容性测试：冷水、冰水、开水、饮料、桌子稳定

      • 性能测试：支持高温/低温，耐摔、挤压

      • 安全测试：材质是否安全，漏水

• 你会如何去测试朋友圈，购物车等熟知的软件产品? (支付，优惠券，购物车、微信聊天，朋等）

测试用例

什么是用例

• 用例：用户使用的案例

什么是测试用例

• 测试用例(TestCase) 是为项目需求而编制的一组测试输入、执行步骤以及预期结果，以便测试某个程序是否满足客户需求。
  • 即为测试项目而设计的执行文档
• 可以总结为:每一个测试点的数据设计和步骤设计。
  • 对测试点的细化

测试用例的作用

• 0 , 软件测试的核心是测试用例的设计和编写,是每个测试人员必须掌握的技能! ! !
• 1、测试用例是软件测试的核心。
  • 软件测试的重要性是毋庸置疑的,测试用例是测试工作的指导，防止漏测,也是实施测试的标准, 质量评价依据 , 是软件测试质量稳定的根本保障。
  • 测试执行(点点点)依据是测试用例文档
• 2、评估测试结果的基准
  • 测试用例的通过率以及错误率， 是测试结束的一个重要依据，用来判断该软件测试结果是否通过，能否达到上线的标准; –; 评估测试质量的标准
  • 测试用例数量/质量作为测试绩效考核标准;
• 3、保证测试的时候不遗漏测试功能点,避免漏测和错误测试
  • 可以在测试人员疲累的时候起到一个牵引的作用。
    • 大厂公司的用例，给一个实习生可以直接去执行
• 4、在编写测试用例的过程，可以熟悉需求，对系统架构或者业务流程有一个整体的，深入地了解
• 5、在执行完测试用例之后，补充完善用例
  • 测试用例的编写不是一次性能编写完的，不是一蹴而就的, 会经历很多的过程

测试用例的八大要素

• 1、用例编号:产品名测试阶段(st 或 uat)

  • st 系统测试，uat 验收测试

• 2、测试项目:对应一-个功能模块(细分功能)

• 3、测试标题:直接对测试点进行细化得出，输入内容+结果，同一功能模块标题不能重复(来自测试点)

• 4、重要级别:

  • 高(high) (核心功能) - P1
  • 中(medium) (次要–异常) - P2
  • 低(low) (界面， 不常用场景) - P3

• 5、预置条件:需要满足一些前提条件,否则用例无法执行, 不是必填项

• 6、测试输入(数据) :需要加工的输入信息，根据具体情况来设计(跟步骤结合起来-定要具有指导性意义)-数据构造

• 7、操作步骤:明确给出每个步骤的描述,执行人员可以根据该步骤完成执行工作-小白/实习生

• 8、预期结果:根据预期输出比对实际结果，来判断被测对象是否符合需求。(预期结果唯一， 不能出现“是否或者”)

• 9、实际结果:执行后的最终结果

• 例如:

编写测试用例的步骤

• 分析需求—提取测试点–细化测试用例

测试用例编写的原则

• 测试用例编写的原则:
  • 1、正常冒烟: 详细到每一个步骤，进行预期结果的检查
    • 第一 条用例比较多
  • 2、后面用例:但凡跟第一条测试用例的点有重复的话 , 要去重 , 用到用例设计方法—细化(正常/异常)
• 哪些内容可以放到预期结果里检查,不要单独写一条测试用例进行验证?
  • 1、操作跟之前的用例操作步骤重复的，第一条写用例—后面缩写了
  • 2、查看想—查看同意协议，注册成功，弹框显示”欢迎加入蜂群”–查看性的功能–顺带做了

测试用例的编写格式

测试用例评审

• 测试用例评审流程：
  • 1、组内评审(测试内部)：
    • 编写用例的人发起评审–协商时间–组织一个会议—邮件(用例附件+时间+会议室===人员)
    • 开会：用例讲解(测试点+思路+展示)–意见+建议–会议记录–修改用例—二次用例评审(没有太大的问题–评审通过)
  • 2、组外评审(开发+产品+测试)
    • 编写用例的人发起评审–协商时间–组织一个会议—邮件(用例附件+时间+会议室===人员)
    • 开会：用例讲解(测试点+思路+展示)–意见+建议–会议记录–修改用例—二次用例评审(没有太大的问题–评审通过)
• 真实公司场景：没有时间参与会议形式评审，发邮件(用例文档)===开发+产品+测试===回复(有问题)===责任规避
• 面试题：你们公司就算没有时间，也会做用例评审吗？
  • 做,发邮件, 对方爱看就看 , 扯皮的时候有的说, 避免背锅

测试用例的变更

• 由于需求变更、对于业务的不断深入了解和测试用例评审，测试用例是无法一次全部写好的， 所以，测试用例在完成之后是需要不断修正的。
• 测试用例变更通常包括:
  • 1、需求变动
  • 2、执行完成后的用例完善
  • 3、评审后的用例修改
    • 一定要记得备份，避免重复的工作! ! !
    • 1、写完测试用例-需求变更-修改用例–快修改完了–需求又改回去-不要在原文档进行修改–通过 git 管理文档/代码
    • 2、执行完后的测试用例，要进行不断的修正，为后期工作做总结

案例分析1

案例需求

• 需求: QQ登录（4 条）
  • 1、账号为空
  • 2、账号未注册
  • 3、密码为空
  • 4、密码错误

测试用例编写

常见面试题

• 1:用例需要评审么?紧急情况用例也需要评审么?
  • 需要,紧急可以不开会,但需要通过邮件发给相关人员
• 2:如果被测项目很紧急,来不及写用例，怎么办?
  • 直接写测试点，项目结束后，完善测试用例，归档
• 3:用例有没有优先级?如果一定要有优先级，依据什么来确定呢?有什么作用呢?
  • 指定执行策略依据
• 4:如何编写测试用例? (以项目为基础来讲一 个小模块 用例设计，手机号)结合项目
  • 分析需求—提取测试点—细化测试用例(四大金刚)，实操测试用例(8大要素)

测试用例设计方法

本节学习目标

• 能对穷举场景设计测试点
• 能对限定边界规则设计测试点
• 能对多条件依赖关系进行设计测试点
• 能对于项目业务进行设计测试点

等价类划分法

说明｜分类｜步骤

等价类划分法的概念

• 等价类划分法是把所有程序的输入域划分成若干个子集合（等价类)，然后从每一个子集合（等价类)中选取少数具有代表性的数据作为测试的输入数据。

• 1)划分等价类(集合)

• 2)怎么选择代表数据

  • 在该子集合中，所有的输入数据对于揭露软件中的错误都是等效的。
  • 依据需求文档 , **将等价类划分有效等价类(正面-不会报错)和无效等价类(负面-抛出异常)**。
    • 有效等价类 : 是指将程序的输入值的集合当中符合输入要求的数据就是有效等价类
    • 无效等价类 : 是指将程序的输入值的集合当中不符合输入要求的数据就是无效等价类

• 例如:

  • 发微信红包[0.01-200] : (每个数据都测试叫穷举法)

    • 有效等价类:

      • (1) [0.01-200] (4)数字 (6) 非空(必填) (8)不能超过两位小数

    • 无效等价类:

      • (2) 小于0.01 (3)大于200 (5)非数字（7)为空 (9)超过两位小数（10)负数

用例设计步骤和原则

• 1, 分析需求，先确定其有效等价类，和无效等价类
• 2, 在确立了等价类之后，建立等价类表，列出所有划分出的等价类;
• 3, 再从划分出的等价类中选择测试用例。
  • 设计一个新的测试用例数据,使其尽可能多地覆盖尚未被覆盖的有效等价类,重复这一步，直到所有的有效
  • 价类都被覆盖为止;–都会正常运行，提高效率
  • 将多个等价类涵盖在一条测试用例里面(能正常运行/省时省力/提高效率)
    • 为了去重测试
  • 设计一个新的测试用例数据,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价都被覆盖为止
    • 唯一变量，一次只能覆盖;目的确保所有的异常都会软件处理
    • 1个无效的数据仅覆盖一条测试用例(容易定位问题)

使用场景

• 针对：需要有大量数据测试输入，但是没法穷举测试的地方。
  • 输入框
  • 下拉列表
  • 单选复选框
• 典型代表：页面的输入框类测试。
• 重点:
  • 1、正向用例 : 一条尽可能覆盖多条
  • 2、逆向用例 : 每一条数据，都是一条单独用例。

案例需求1

• 需求：验证QQ账号的合法性
• 要求: 6~10位自然数
  • 分类:

    • 有效等价：所有有效数据集合，取一个即可。

      • (从6,7,8,9,10位中取一个即可)

    • 无效等价：所有无效数据集合，取一个即可。

      • (从小于6位,大于10位的集合中取一个即可)

案例需求2

• 需求：验证某城市电话号码正确性
• 要求：
  • 区号:空或者是三位数字
  • 前缀码:非“0”且非“1”开头的三位数字
  • 后缀码:四位数字

边界值分析法

边界值分析法

• 1, 定义:边界值分析法是对等价类划分法的一个补充，边界值一般都是从等价类的边缘值去寻找。有效等价类边界无效等价类边界
• 2, 原则和步骤:确定边界:应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据–-范围相关
  • [0.01-200]
    • 两点法(正好等于) : 0.01、200
    • 四点法(正好等于+刚刚大于+刚刚小于) : 0.01、0.02、199.99、200
    • 三点法(正好等于+中间取值):0.01、100、200
    • 7点法 : 0、0.01、0.02、100、199.99、200、200.01
      • 看项目、时间分配、模块的重要程度来测试
  • 特殊边界值:—年(1-12)、月(1-30/31/28/29)、星期(1-7)、小时(O-23)
    • 0是一个特殊值、负数、空值、空格、特殊字符等
• 3, 边界值的作用 :
  • 人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围内部。因此针对各种边界情况设计测试用例，可以查出更多的错误!

案例分析1

• 如何验证两个两位数整数边界数据的求和？
• 需求：判断输入的数据是否小于-99或者大于99，如果小于 -99 或大于 99 给出错误提示

边界范围节点

• 选取正好等于、刚好大于、刚好小于边界的值作为测试数据
  • 上点：边界上的点(正好等于)
  • 离点：距离上点最近的点(刚好大于、刚好小于)
  • 内点：范围内的点(区间范围内的数据)

设计用例步骤

1. 明确需求
2. 确定有效和无效等价类
3. 确定边界范围值
4. 提取数据编写测试用例

使用场景

• 边界值的应用场景 :

  • 如果需求规定了取值范围，取值的个数时，可以利用边界值进行测试 , 通常与等价类分析法一起使用

  • 在等价类的基础上针对有边界范围的测试数据输入的地方(重点关注边界)

  • 常见词语描述:大小、尺寸、重量、最大、最小、至多、至少等修饰词语

  • 典型代表:有边界范围的输入框类测试

• 常见的应用场景 :

  • 常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语

  • 典型代表：有边界范围的输入框类测试

  • 1, 输入条件规定的取值范围或值的个数的情况(类似最小<x<最大、最小<x、最大>x);

    • 比如用户名长度、红包金额数值输入范围

  • 2, 在下拉列表包含多个选项的情况;比如城市下拉选项(第一个、最后一个、中间一个)

  • 3, 报表数据的第一行、最后一行、中间一行

  • 4, 屏幕上光标在最左上、最右下位置–界面边界

案例分析2

• 需求：通过边界值法验证标题长度的合法性
• 要求：标题长度大于0，小于等于30个字符

案例分析3

• 需求：通过边界值法验证QQ号码的合法性
• 要求：6~10位自然数

案例优化

• 结论:7个优化为5个点
• 上点:必选(不考虑区间开闭)
• 内点:必选(建议选择中间范围)
• 离点:开内闭外(考虑开闭区间，开区间选择内部离点，闭区间选择外部离点)
  • 10 < a <= 20
  • 使用开闭区间表达: (10,20]
  • 开区间:不包含
  • 闭区间:包含
• 开区间指的是区间边界的两个值不包括在内;(a,b)
• 闭区间指的是区间边界的两个值包括在内。[a,b]
• 半开半闭区间:开区间一边的边界值不包括在内，而闭区间一边的边界值包括在内。[a,b)、(a,b]

判定表法

判定表法的引用

• 案例: 验证“若用户欠费或者关机，则不允许主被叫”功能的测试
• 说明：
  • 等价类边界值分析法主要关注单个输入类条件的测试, 并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试。

判定表定义及组成

• 定义：是一种以表格形式表达多条件逻辑判断的工具
  • 组成：
  • 条件桩：列出问题中的所有条件，列出条件的次序无关紧要。
  • 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束。
  • 条件项：列出条件对应的取值，所有可能情况下的真假值。
  • 动作项：列出条件项的、各种取值情况下应该采取的动作结果。

• 规则:
  • 判定表中贯穿条件项和动作项的一列就是一条规则
  • 假设有n个条件，每个条件的取值有两个(0,1)，全组合有2的n次方种规则

判定表法设计用例步骤

• 1、明确需求
• 2、画出判定表
  • 1, 列出条件桩和动作桩
  • 2, 填写条件项，对条件进行全组合
  • 3, 根据条件项的组合确定动作项
  • 4, 简化、合并相似规则(有相同的动作)
• 3、根据规则编写测试用例

使用场景

• 有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖(制约)关系
• 判定表一般适用于条件组合数量较少的情况(比如4个条件以下)
• 提示：如果碰到项目中多条件组合大于4个相互依赖，可以使用（正交表和因果图来实现）

案例分析1

• 订购单检查
  • 规则
    • 1）如果金额大于500元，又未过期，则发出批准单和提货单;
    • 2）如果金额大于500元，但过期了，则不发批准单与提货单;
    • 3）如果金额小于等于500元，则不论是否过期都发出批准单和提货单;
    • 4）在过期的情况下不论金额大小还需要发出通知单。

案例分析2

• 文件修改规则
  • 规则
    • 1）输入的第一列字符必须是A或B
    • 2）第二列字符必须是一个数字
    • 3）如果第一列字符不正确，则给出信息L
    • 4）如果第二列字符不正确，则给出信息M
    • 5）如果两列字符输入正确，则修改文件成功

场景法

流程图

• 使用标准图形和箭头来表达程序或业务的走向

• 流程图对测试人员有什么作用？

  • 1、能够看懂流程图，设计业务用例
  • 2、当需求文档信息不全是，能够根据需求，梳理出流程

• 网页版工具：https://processon.com/

• Windows 工具: visio

场景法

• 1、什么是场景法?
  • 通过场景描述的业务流程(业务逻辑)，也包括代码实现逻辑， 设计用例来遍历场景(路径)，验证软件系统功能的正确性。
• 2、如何使用场景法
  • 2.1画出流程图–产品需求文档，画好了;或者需要测试自己画，工具: wps, office -visio, processon
    • 矩形:示步骤(操作、输入、输出结果)
    • 菱形:判断条件–是、否
    • 箭头:流向–输入文字
  • 2.2遍历场景,提取测试用例。正常+异常
    • 1)覆盖正常的路径-顺利取到钱
    • 2)走每一个分支–正常场景下没有覆的路径
    • 3)出错步骤重新回到主流程，建议多走一步 正确的步骤
• 注意:场景法的重点是测试流程，因此每个流程一个用例验证即可，流程测试没有问题并不能说明系统功能没有问题了，还需要针对单步的功能进行细化测试,只有单个功能点和流程测试，才算是充分的测试+等价类、边界值—细化测试

应用场景举例

• 场景一:插入一张合法的银行卡，输入正确密码不取消，输入正确的金额，账户和ATM余额充足，取款成功;
• 场景二:插入一张不合法的银行卡，提示错误退卡;
• 场景三:插入一张合法的银行卡，取消了，退卡;
• 场景四:插入一张合法的银行卡，输入不正确的密码，错误超过3次,吞卡;
• 场景五:插入- -张合法的银行卡，输入不正确密码，错误次数不超过3次，提示重新输入，返回输入密码界面—建议多走一步,输入正确密码是否可以正常进行
• 场景六:插入-张合法的银行卡，输入正确密码，输入不合法的金额, 提示重新输入–建议多走一步，输入合法的金额是否正常
• 场景七:插入-张合法的银行卡，输入正确密码，输入合法的金额,账户余额不足，提示重新输入
• 场景八:插入- -张合法的银行卡，输入正确密码，输入合法的金额,账户余额充足，ATM机里余额不足，提示重新输入–建议多走一步,输入法的ATM余额充足，金额是否正常
• 场景法覆盖完之后，功能测试是否充分? ==密码输入，金额输入–细化–边界值等价类

案例分析1

• 流程图练习
  • 1、用户名为 admin , 密码为：123456，输出：登录成功
  • 2、登录、搜索商品、添加购物车、去结算、支付，如果支付成功，则提示下单成功，否则提示支付失败

场景法介绍

• 说明：
  • 场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。
• 意义：
  • 用户使用角度:用户平时使用的不是单个功能，而是多个功能组合起来进行使用
  • 测试人员角度:平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试

使用场景

• 根据实际的应用场景，来测试业务用例，可以使用场景法

案例分析2

• ATM 取款流程

案例分析3

• 场景一:员工请假超过3天，部门]经理，部门总监，HR都审批通过，请假成功
• 场景二:员工请假超过3天，部门]经理不通过，重新提交申请
• 场景三:员工请假超过3天，部门]经理通过,总监不通过，重新提交申请
• 场景四:员工请假超过3天，部门]经理通过,总监通过，HR不通过重新提交申请
• 场景五:员工请假不超过3天，部门]经理和HR通过，请假成功
• 场景六:员工请假不超过3天,部门]经理不通过，重新提交申请
• 场景七:员工请假不超过3天,工部门经理通过，HR不通过，重新提交申请

错误推荐法

介绍

• 基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。
• 它的要素共有三点，分别为:经验、知识、直觉。—探索性测试
• 考虑程序可能触发错误场景，也就是导致程序不能正常运行的因素。— 不能单独使用，补充
• 等价类-边界值-场景法-错误推测(由果及因)

案例分析1

• 单模块用例设计 :

  • 密码规则 :

    • a) 不能纯数字

    • b) 不能纯字母

    • c) 字母+数字

    • d) 长度6-16位

案例分析2

• 业务用例设计

错误推测法案例

• 案例:某平台登录页面
  • 既然是用错误猜测法，那么我们首先列出可能导致结果出错的情况(登录失败)(功能+非功能)
    • 1、网络问题—中断(断电/断网)
    • 2、用户名/密码错误—数据不对
    • 3、未注册用户登录
    • 4、单点登录(账号在一个设备登录,在其他设备下线)/多点登录(同一个账号可以多端同时在线)–踢下线
    • 5、验证码错误
    • 6、外部因素:网站升级、系统崩溃、宕机
    • 7、页面超时
    • 8、账号为空/密码为空
    • 9、账号冻结–黑名单–安全
    • 10、点击登录按钮无响应
    • 11、账号已注销
    • 12、密码多次输入错误，已超上线次数
    • 13、登录限制—IP受限—异地限制
    • 14、兼容性测试—不兼容当前浏览器
    • 15、访问人数过多-性能测试
    • 16、 未成年超过玩游戏时间限制登录

常见面试题

• 1, 编写测试用例会用到什么方法? -四大金刚

  • 你觉得你在写用例的时候用到了吗?怎么用的? ?

• 2, 判断能否构成三角形:

• 测试用例方法有哪些 :
  • 等价类划分法
  • 边界值分析法
  • 错误推测法
  • 因果图法
  • 判定表驱动法
  • 正交试验法
  • 功能图法
  • 场景法

bug缺陷管理

学习目标

1. 能够说出软件缺陷判定标准
2. 能够说出项目中缺陷的管理流程
3. 能够使用Excel对于缺陷进行管理
4. 能使用工具管理缺陷

缺陷定义

• 软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug。

• 狭义概念是指软件程序的漏洞或缺陷

• 广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节（增强性，建议性).或与需求文档存在差异的功能实现等。

• 测试职责:发现这些bug，并提交给开发，让开发去修改

  • 发现bug—定位bug—提交bug(开发)—回归验证Bug—关闭Bug

缺陷的判定标准

• 软件未实现需求(规格)说明书中明确要求的功能 –少功能
• 软件出现了需求(规格)说明书中指明不应该出现的错误 -功能错误
• 软件实现的功能超出需求(规格)说明书指明的范围 -多功能
• 软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求 –隐性功能错误
• 软件难以理解，不易使用，运行缓慢，用户体验不好 - 不易使用

bug的分类

功能型 Bug

• 功能型 Bug : 指产品实现过程中，具体逻辑的实现错误
  • 比如 : 登录时，用户名要求使用邮箱登陆，但并未验证邮箱格式
    • 类型 : 实现错误
      • 前端未验证 : 频繁且大量的错误请求发到后端给服务器带来无意义的压力
      • 后端未验证 : 如果前端验证时有Bug则错误数据会直接进入到数据库中
  • 比如 : 用户浏览商品时，商品添加到购物车中失败
    • 类型 : 未成功实现
      • 前端未实现 : 点击添加购物车按钮无反应，或并没有发送添加请求到后端
      • 后端未实现 : 后端代码逻辑有问题，比如数据数据传输解析失败或数据存储失败

需求型 bug

• 需求型 bug : 指在软件项目管理的过程中，需求阶段就埋下了隐患，如未按照需求实现需求理解错误或需求未描述清楚等情况
  • 比如 : 系统中用户可使用微信手机号、邮箱注册并登陆
    • 类型 : 需求未描述清楚
      • 出现的问题 : 当一个用户分别使用了微信、手机号、由邮箱进行了系统的注册登陆
      • 带来的影响 : 在软件系统中会认为微信、手机号、邮箱分别是一个独立的用户 , 这明显是错误的
    • 如何解决 : 在需求阶段就定义一个明确的唯一值，比如手机号，无论用什么方式注册，登陆成功后都必须绑定手机号

性能型Bug

• 性能型Bug : 指在软件在多人同时使用或长时间运行时出现了响应慢，甚至是崩溃的问题
  • 比如 : 某明星官宣恋爱、结婚等或被曝出违法犯罪的行为，导致微博崩溃
    • 类型 : 多人同时使用系统崩溃
    • 结论 : 微博这个问题，很难解决，是金钱与用户之前的一种平衡
    • 原因 :
      • 多年运行的成熟软件，架构已然成熟，靠的就是增加服务器来提升性能
      • 大多数时间没有那么多用户，增加太多服务器就是增加成本
      • 明星新闻爆出速度太快，并没有给服务器动态扩充多少准备的时间

常识型Bug

• 常识型Bug : 在过去用户一直是这样认为的，已经形成一种默认的约定，但软件设计或开发人员就不按照约定俗成的规则来

bug的等级

• 要bug等级，这个划分有分三级或四级，也有分五级的。如果是等级越高（严重)，那么可能被修复的等级也会高一些，然后有些公司还会根据你提的bug数量和bug等级来考察你的绩效。很多情况下，我们提交bug大致的等级差不多即可，没有严格区分。
• 影响到开发绩效==等级设置谨慎
• 如何来判断bug的等级（严重程度)，一般可以参照下面的判断条件。

致命错误P1级

• (1) 致命错误:—- P1
  • 1、常规操作引起的系统崩溃、死机、死循环、闪退—阻塞，冒烟测试都不通过
  • 2、造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露—安全漏洞
  • 3、涉及巨额的金钱计算和金钱损失—-巨额损失，银行/信贷/P2P/电商—看用户的基数
  • 4、阻断性测试，所有测试工作进行不下去
  • 5、权限问题–用户越权，vip/普通

严重错误P2级

• (2) 严重错误:—–P2
  • 1、重要功能不能实现;
  • 2、次要功能错误的波及面广，影响到其它重要功能正常实现;
  • 3、非常规操作导致的程序崩溃、死机、死循环、闪退
    • 网络异常情况导致/连续点击4-5次才能出现的问题
  • 4、外观(界面)难以接受的缺陷;
  • 5、密码明文显示;
    • 前端密码标*处理，后端传输数据的时候密码是加密处理
    • 抓包工具去看数据
  • 6、偶现的致命性bug

一般错误P3级

• (3) 一般错误:—P3
  • 不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷
    • 1、次要功能不能正常实现;
    • 2、操作界面错误（包括数据窗口内列名定义、含义不一致);
    • 3、查询错误，数据错误显示
    • 4、简单的输入限制未放在前端进行控制;
      • 减轻后端(开发+服务器)的压力，比如在前端校验手机号/邮箱/空/长度/类型 , 如果前端未校验,则可以提建议性 bug
    • 5、删除操作未给出提示;—防止误操作，友好型
    • 6、偶现的严重性bug

细微错误P4级

• (4) 细微错误:—P4
  • 程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误
    • 1、界面不规范;
    • 2、辅助说明描述不清楚;
    • 3、提示窗口文字未采用行业术语;—约定俗成4、界面存在文字错误;

改进建议P5级

• (5) 改进建议—-P5

  • 可以提高产品质量的建议，包括新需求和对需求的改进。可以参考借鉴同类产品/竞品产品

• 问:提交 Bug，提交给谁?一定开发吗?(开发+产品)

  • 建议性的问题:我不确定要不要做,就提交给产品，我确定要做,就提交给开发

• 问:测试提交的 Bug，开发不认为是 bug，测试怎么办?

  • 测试要先确定下bug是不是存在的，排除外界因素导致(网络问题/环境问题/误操作…)找开发协商沟通，说服开发，测试是从哪些角度去考虑（用户的角度)

  • 找产品/项目负责人，进行确认，得到最终的答复(不认为是Bug—关闭–说明原因–自己记录下来)

案例练习分析

• 1, 用户输入正确的用户名和密码不能登录网站
  • 结合产品去考虑
    • 如果是类似QQ/微信,则属于 P1级
    • 如果是类似爱奇艺/优酷, 则属于 P2 级
• 2, 客户需求要有充值功能，但是网站没有做
  • 区分功能的重要性 , 核心?次要?可有可无?
• 3, 网站充值后，出现金额错误:
  • 看金额的大小?用户基群?巨额?小钱?是哪个区域的业务(银行/电商) , 用户群体越大,金额越大,则优先级越高
• 4, 在某购物APP上进行商品搜索时，闪退回到手机桌面
  • 业务?重要功能?偶发性?
• 5, 在某购物APP上进行商品搜索时，手机卡死
  • 业务?重要功能?偶发性?跟硬件有关?
• 6, 关闭按钮在弹窗左侧
  • 操作定义违反用户习惯P3/P4(也要根据公司业务场景来)
• 7, APP某个图标显示太小或者像素失真
  • 结合业务去定义P2/P3/P4/P5
• 8, 某个提示语需要改进一下，用户对专业术语不太懂
  • 提示语描述不清楚P3/P4
• 9.忘记密码，功能没有实现
  • 依据业务来定义，看是重要?次要的?功能?

缺陷产生原因

• 程序在开发时考虑不周全导致
• 程序在使用时不符合用户习惯

软件缺陷的生命周期

• 这个是面试/笔试过程中经常会被问的问题。
  • bug的生命周期，就是一个bug被发现到这个bug被关闭的过程。
• 你们觉得这个过程有哪些步骤?
  • 生命周期中一般缺陷状态:发现–新建(提bug)-→>指派->已解决-→>待验->关闭。—正常
  • 如果待验的bug在验证时没有解决好，我们需要重新打开（重激活)->指派->已解决->待验，循环这个过程。
  • 中间其他状态:拒绝、延期等
• 我们来看一个bug的处理流程图（生命周期图)，让大家更深刻地理解周期中bug的状态及相应处理。

软件缺陷的核心内容

缺陷提交要素

软件缺陷类型

• 要确定一个bug的类型，需要对项目（纯产品）有比较深的理解。这个划分对于开发定位问题影响很小，但对于问题类型的统计就比较重要了。—测试报告bug分析
• 常见的bug类型划分（禅道系统为例，可自定义)∶
  • 1、代码(功能)错误—最重要，比重最多的
  • 2、界面优化— Ul
  • 3、设计缺陷–需求不合理，改进，建议性的bug
• 按照公司具体的规定来分类! !!
• 如何区分前端bug还是后端bug？
  • 1、如果是界面或兼容性的错误为前端bug
  • 2、如果是功能错误区分前端和后端bug，需要抓包查看请求和响应。

缺陷报告示例

bug状态跟踪流程

bug的状态管理

• 1、发现bug：不要着急提bug—-记录(截图)
• 2、确认bug：确认bug(排除外界因素)—确定步骤是否必现？====目的：Bug的有效性
• 3、提交bug：必现/偶现–提交到哪里？—提交给谁？—怎么提交？
• 4、指派bug：开发计划(人员分配) , 可以直接提交给开发本人,或者提交开发负责人,由负责人分配
  • 注意：一定要跟进bug，开发理了？催开发处理bug—- P1(半天)
• 5、研发确认bug： 从测试提交的bug描述中判断，是不是bug？
• 6、重复bug：其他人提交过的bug，重复提了重复 bug
  • 确认是重复了,则关闭bug，并说明原因 , 如果确认不是重复, 则重激活 bug 并指派给开发
  • 注意：开发一定要把重复 bugID标注(备注)
• 7、不是缺陷：无效bug , 先确认外部因素(误操作/网络/环境)， 不是bug—设计如此–先去确认需求–找产品确认
  • 第一种：自己排查 , 如果是无效 bug ，备注并关闭，不是无效的, 备注并重激活指派对应开发
  • 第二种：开发坚持认为不是bug，说明原因—站在用户的角度–沟通不一致–找产品/项目负责人–最后确认
  • 要改(重激活指派对应开发)
  • 不改(关闭bug+原因备注+记录)
• 8、无法重现：
  • 第一种：偶现bug，要记录，在标题上标记偶现，后续版本持续的复现，尝试找到稳定复现的步骤+提供截图+日志(linux)；
  • 第二种：测试提出一个bug，开发人员在开发环境没有复现，尝试在自己的测试环境查看是否复现，让开发来测试环境看问题，修改测试的Bug（开发修改的代码同步到开发环境）
  • 第三种：测试环境无法复现—持续跟踪(5个版本)—一直持续关注，如果临近发布版本，依旧无法复现 , 则关闭加备注
• 9、不予解决：不修复bug , 可以要求开发给出不修复的理由
• 10、延期bug：本次发布项目不修复，留到下个版本解决
  • 建议性bug , 比如新功能以及动作大的需求,可以在下一个版本处理
  • 修复风险太大，可能会引入新的bug，会导致项目延期发布
  • 衡量 bug 对用户的影响 , 如不修复，对用户影响不大 , 则可以下次再修
    • 如不修复，对用户影响面很广, 就需要重激活 bug (说明) , 并指派给产品
• 11、回归验证Bug：bug 步骤重新测试一遍 , 这个bug所涉及的功能点，均要测试
  • 开发改动的代码所涉及到的点均要回归验证
  • 临近发布版本的时候，要把P1、P2的bug 要进行回归验证
• 12、解决Bug：回到了测试手上–开发把修复bug代码的版本提交测试==注意版本/环境
• 13、关闭bug：确认此bug通过验证，即关闭bug

提交缺陷注意事项

bug提交规范

• 发现bug后，接下来你提交到bug管理平台，提交一个bug包含哪些内容?
• bug标题——标题要清晰简洁，写明bug描述;如果没有选择功能模块，最好在标题中标注功能模块。让查看bug的人员清楚知道你所表达的意思。bug的功能模块+bug的操作+bug的结果
  • 例如 :

• 重现步骤——详细写下发现bug的测试过程。能指导开发重现这个bug。附上测试数据
• 实际结果——出现bug的结果，粘贴bug截图、日志截图===文字＋截图–Ul-web APP==有图有真相，证据直观
• 预期结果——记得写清楚预期==测试用例预期结果–指引开发修复bug的依据bug类型和严重程度——便于后续测试结果分析，bug的统计
• bug测试环境——例如:什么系统，哪个版本等。兼容性问题、难以重现问题附件——日志文件，文件测试数据。图片、崩溃日志文件等
• 所有以上，参考公司前辈写的bug，依葫芦画瓢，拓展测试思维

• 柠檬班禅道地址: http://zbox.lemonban.com/zentao/my/

bug的管理工具

• 常见的缺陷管理平台:
  • 禅道(zentao) —-国内中小型企业，免费开源bugzilla、 jira —外企==安装比较麻烦
  • bugfree:
  • Readmine
  • easybug:免费开源，在线网站类型的
  • Mantis:这个还可以用
  • QC(QualityCenter)TAPD–微信–TD
• 不管是开源还是商业的缺陷管理工具，它们本质都是一样的，用来管理bug的生命周期。掌握其中一款工具，自然就会用其他的，稍微有一点点区别的，别人加以指点，就可以明白了。

禅道的介绍

• 本地部署下载地址 : https://www.zentao.net/page/download-new.html
• 特点：
  • 国产、免费、开源、简单、轻量级
  • 三管融合(产品管理、项目管理、质量管理)

禅道使用流程

• 测试 :
  • 提交bug
  • 分派bug
• 开发 :
  • 处理bug
• 测试 :
  • 回归bug
  • 关闭bug

缺陷描述

常见面试题

• 1:有没有你印象深刻的bug? bug的原因/bug当时怎么解决?— 90%以上都会问，实战之后，自己再去梳理
• 2: bug 的生命周期?(笔试)
• 3:当你发现了一个bug，但是开发不认为是bug，如何处理?–90%以上会问
  • 测试要先确定bug是不是存在，排除外界因素导致(网络问题/环境问题/误操作….)
  • 找开发协商沟通，说服开发，测试是从用户角度去考虑问题
  • 找产品/项目负责人，进行确认，得到最终的答复(不认为是bug—关闭(说明原因)—自己记录下来)
• 4:你在发现bug并确认bug的过程中,对于复现率不高（偶现）的bug怎么处理?

测试计划与测试报告

测试计划简介

• 为什么要写软件测试计划?一般是主管来写，测试计划是在做完需求分析后，整个测试工作开始之前做的一些准备计划工作，“5W+1H”去记忆。一般包括以下内容:
  • 目的(why)、测试范围(what)、测试进度安排(when)、测试人员(who)、测试环境（where)，测试方法+测试工具(how)，风险评估。
    • 项目充分熟悉＋项目经验==测试老大
      • 1)以后你会做老大
      • 2）计划需要所有参与者的评审的—信息同步
• 可能会有的同学问，为什么要提到测试工具?因为像一些访问量比较大的公司，可能要进行性能测试，那么就需要用到测试工具。
  • JMeter/postman/Fildder/mysql….
• 公司一般会有自己的软件测试计划模板，下面我们来看下软件测试计划的模板，课后老师会分享给大家，大家请一定自己保存好，以后会用得到的。

软件测试报告简介

• 软件测试的五个阶段中:评估阶段(测试人员必须会的)
• 公司一般都有自己的软件测试报告模板，看下我们的软件测试报告模板
• 在进行完整个测试工作后，你就要对测试产品做一个总结/评估，提交给你老大或者是研发部门负责人，项目经理目的:产品质量==用例是否执行完了? bug修复完===结论:是否可以上线?
• 包括的内容:测试范围、测试环境、遗留的bug有哪些，测试用例覆盖率有多少，bug的统计与分析，风险有哪测试评估，发布的建议
• 一般公司有自己的报告模板，照写就好。没有，可以用老师提供的模板。
  • 注意:一个项目出几份测试报告?谁写?
    • 一份,由测试负责人编写

常见面试题

• 1:写过测试报告/计划么?内容包括什么?(笔记详细-面试:挑选重要的说明）测试报告的编写目的是什么?
  • 1）评估软件质量（用例/bug)，是否达到上线标准
  • 2）分析bug分布，总结经验，优化下次项目执行
• 2:报告中的结果是怎么分析的?分析的目的是什么?
• 3:你认为测试报告的侧重点?— Bug的分析，测试用例覆盖率

项目发布流程

项目测试流程

项目发布流程

• 第一步:测试完成，测试报告下结论:
  • 测试结束了!发邮件通知相关人员。
• 第二步:
  • 验收测试—产品验收
• 第三步:开发打包做新版本
• 第四步:产品，开发,运维(每个公司不一样) , 部署线上环境
  • 部署生产环境发布上线时 : 产品，开发, 运维、测试均要在场
• 第五步:线上环境测试做冒烟测试。
• 发布成功

常见面试题

• 面试题:
  • 生命周期模型包含哪些阶段?你们开发的模型是什么?
  • 你们公司的开发流程是怎样的?
  • 你们公司的测试流程是怎样的?各个阶段的输出是什么?
  • 开发环境，测试环境，预发布环境(验收环境) , 生产环境是什么?你在测试环境后台添加的数据和信息，能够在生产环境看到么?

浏览器兼容性测试

浏览器兼容性简介

• 产生浏览器兼容性问题的原因:
  • 因为不同浏览器使用内核及所支持的HTML（标准通用标记语言下的一个应用）等网页语言标准不同;以及用户客户端的环境不同(如分辨率不同）造成的罐示效果不能达到理想效果。最常见的问题就是网页元素位置混乱，错位，重叠。–U界面测试
• 为什么做兼容性测试﹖预见所有客户可能遇到浏览器。–显示/使用–贴近用户使用场景!
  • 内核:决定了浏览器如何显示网页的内容以及页面的格式信息
• 如何选择浏览器做兼容性? ? —主流＋内核（类型)

浏览器兼容性测试原则

• 选择浏览器做兼容性测试的原则
  • 1.用户有要求，指定浏览器 - 优先
  • 2.网站一般都需要做兼容，用户使用量+内核来看，选取主流浏览器 ，最新版本 chrome UC /QQ firefox
    • 测试选择之后，找产品确认; 编写在测试计划文档里= where (软件测试环境)
• 一般兼容性测试是测试什么? 什么时候测试的? 以及怎么来做的?
  • 1,兼容性测试内容:–U界面进行测试 随着功能测试同步去做 ! 功能同时会去检查页面!
    • 主要是页面的格式，字体，输入框，下拉框，复选框，按钮等的检查;页面显示正常
  • 2.什么时候测呢?—系统测试同时进行，分配? chrome firefox 360
    • 方案一: 按照轮次2-4轮===轮次可能无法覆盖所有的浏览器
      • 第一轮: chrome 第二轮: firefox 第三轮: 360
    • 方案二:按照任务分配===没人分配不同的功能模块
      • 购物车: A测试 chrome—同时检查下其他模块的UI—浏览商品，订单
      • 浏览商品: B测试 firefox —同时检查下其他模块的UI—购物车，订单
      • 订单: C测试 360—同时检查下其他模块的UI—购物车，浏览商品

常见面试题

• 1, 小众浏览器出现问题，需不需要做兼容性测试?
  • 1, 用户特别要求的，要进行覆盖测试—–用户的需求优先
  • 2, 不是特别客户的要求，我们不用去覆盖兼容性测试(主流+内核)
    • 提交测试报告===测试覆盖的浏览器+产品支持的浏览器—给到市场、售前、售后===给用户发这个测试报告，户使用我们推荐的浏览器
• 2, 如果一个网站分为前台访问系统、后台管理系统;是否都需要做浏览器兼容性测试?
  • 前台—用户操作的页面—以用户为中心–要进行兼容性测试—-甲方要求优先/(主流+内核)
  • 后台—管理员使用+内部操作人员使用–看情况，看项目来，看时间–可以不覆盖，可以做兼容性测试
• 3, 浏览器的兼容性测试是怎么做的?–真实面试高频
  • 1, 怎么选择浏览器
    • 如果说是用户特别要求，按用户需求优先。
    • 市场调研的项目(主流+内核) , 可以参考百度流量统计
  • 2, 兼容性测试是伴随着功能测试一起做的，不同的模块任务划分进行的，覆盖不同的浏览器

阶段综合案例分析

项目背景介绍

• 传智作为一个T教育机构，拥有自己开发且实际运营的产品，将开发和运营的技术作为授课的内容，对于学员而言学到的都是一手的真实案例和实际经验，知识内容也可以细化深入。而且一个产品就可以涵盖公司多个学科的技术，衍生的课程价值辐射多个学科，这可以作为公司的一个核心竞争力。

产品定位

• 一款汇集科技资讯、技术文章和问答交流的用户移动终端产品。
• 用户通过该产品，可以获取最新的科技资讯，发表或学习技术文章，讨论交流技术问题。

项目目标

• 1）研发并上线运营头条产品
• 2）从实际的产品技术中孵化 Python 人工智能、Python 数据分析、Python Web、测试、运维等课程案例
• 3）构建公司自己的数据仓库、和算法模型

产品功能架构

• 产品主要分为三个前端子产品：

• 1）用户端：APP，用户可以查看资讯、文章内容，进行问答讨论交流
• 2）自媒体运营平台：PC网站，自媒体用户可以管理文章、评论，查看分析粉丝数据
• 3）系统后台：PC网站，内部运营管理系统

登录功能测试

测试对象

• 完成黑马头条web登录功能测试

登录需求1

• 输入正确的中国手机号（11位）
  • 当文本框失去焦点的时候验证，红色为失败，绿色为成功
• 点击发送验证码
  • 如果手机号文本框状态为绿色，弹出“点击按钮进行验证”；
  • 如果手机号文本框为红色，提示手机号不正确
• 点击按钮进行验证
  • 拖拽图形到指定位置，按钮消失；
  • 拖拽图形未到指定位置，晃动提醒，滑块回到初始位置；
  • 超过5次，提示尝试过多，请点击重试；

登录需求2

• 输入验证码
  • 正确的验证码，并“勾选我已阅读并同意 ”，点击登录，进入系统；
  • 错误的验证码，并“勾选我已阅读并同意 ”，点击登录，提示验证码错误；
  • 正确的验证码，未“勾选我已阅读并同意 ”，点击登录，提示请勾选；
• 点击登录
  • 手机号、验证码都为绿色，勾选“我已阅读并同意”，登录成功

登录测试用例

文章发布功能测试

学习目标

• 能够对于发布文章模块进行需求分析（提取测试点）
• 能够对于发布文章测试点进行设计用例和执行
• 能够对于使用禅道记录缺陷
• 能够对于黑马头条项目测试进行编写测试报告

测试对象

• 完成黑马头条web发布文章功能测试

案例需求

测试用例