零基础快速入门软件测试

一、项目

1. 项目成员

先简要了解一下软件项目组中所涉及的一些重要角色及关键词

• 项目：软件研发项目，包括从前期项目预研、立项、组建项目团队、设计开发软件、测试调试、交付验收，以及软件运营等各项具体的工作
• 项目经理：软件项目的总负责人，既需要有广泛的计算机专业知识，又需要具有项目管理技能，能够对软件项目的成本、人员、进度、质量、风险、安全等进行分析和管理，从而使软件项目能够按照预定的计划顺利完成
• 需求：指用户需求，有了用户需求才能开发相应的产品，它通常包括功能性需求和非功能性需求
• 用户：指提出需求的用户，同时也是软件验收的主要人员
• 开发人员：通过代码来实现软件各项功能的程序员
• 测试人员：负责软件测试
• 产品人员：根据用户提供的原始需求，制定出更为规范的需求文档，并且需要不断与用户交流确认，直至用户满意为止

2. 项目开发的简要流程

• 用户将原始需求提交给产品人员，产品人员根据原始需求制定需求文档
• 产品人员把制定好的需求文档给到开发人员和测试人员，三者进行需求评审（消除歧义，完善需求细节，达成共识）
• 开发人员按照需求文档进行开发
• 测试人员测试产品是否符合需求文档里的要求

3. 如何评审需求文档

• 正确性：对照用户的原始需求，检查产品人员制定的需求文档是否偏离了用户的原始需求
• 明确性：检查需求文档中每个需求项描述是否清晰，是否有歧义
• 完整性：对照用户的原始需求，检查产品人员制定的需求文档是否覆盖了用户提出的所有需求项，每个需求项是否遗漏了用户提出的必要信息
• 限制性：每个需求项是否清晰描述了这个软件能做什么、不能做什么，能输入（输出）什么、不能输入（输出）什么
• 优先级：需求文档中的哪些功能比较重要，哪些功能比较次要，是否做了标识和编号
• 一致性：检查需求文档中的内容前后是否一致，确保不矛盾

4. 测试流程

1. 需求评审：确保各部门需求理解一致

2. 计划编写：测什么、谁来测、怎么测

3. 用例设计：验证项目是否符合需求的操作文档

4. 用例执行：项目模块开发完开始执行用例文档实施测试

5. 缺陷管理：对缺陷进行管理的过程

6. 测试报告：实施测试结果文档

二、初识软件测试

1. 职业规划

• 技术型路线
  • 从功能测试做起，积累一定经验后，可根据兴趣往自动化测试、性能测试、安全测试等方向发展
• 管理型路线
  • 如果对团队管理比较感兴趣，可以往测试主管、测试经理、测试总监的方向发展。注意，作为一名团队的管理者，需要在测试技术的某一方面比较精通，否则只有管理经验没有技术经验是无法管理好团队的
• 产品和市场路线
  • 软件测试人员长期测试产品，对产品的各项功能、用户体验、产品性能等方面比较了解，因此可以考虑转向产品策划类工作、市场培训、技术支持、售后服务等工作
• 开发路线
  • 积累了一定编程能力后再转向软件开发

注：以上路线仅供参考，并不局限于以上四种

2. 初级软件测试人员需要知道的知识

• 软件功能测试技术
  • 即手工测试。主要包含软件需求规格说明书的评审、测试计划、测试用例设计、环境搭建、测试执行（缺陷提交、回归测试）、测试报告等；功能测试主要体现在用例设计和缺陷提交两方面。
• Web 自动化测试的初级应用能力
• 接口测试的初级应用能力
• Linux 操作系统中常用的命令
• 数据库的基本 SQL 语法
• ...

3. 认识软件测试

1. 软件：控制计算机硬件工作的工具

2. 软件测试：使用技术手段验证软件是否满足使用需求

3. 软件测试目的：减少软件缺陷（bug），保障软件质量

4. 测试方向

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

5. 测试分类

   • 按测试阶段分
     • 单元测试：针对程序源代码进行测试
     • 集成测试：又称接口测试，针对模块之间访问地址进行测试
     • 系统测试：对整个系统进行测试包括功能、兼容、文档等测试
     • 验收测试：主要分为内测、公测，使用不同人群来发掘项目缺陷
   • 按代码可见度分
     • 黑盒测试：不关注源代码，针对程序 UI 功能进行测试【系统测试】
     • 灰盒测试：针对部分源代码进行测试【接口测试】
     • 白盒测试：针对程序源代码进行测试【单元测试】

三、质量模型

1. 衡量一个优秀软件的维度

外观界面、功能、性能、兼容性、易用性、安全性、可靠性、移植性、维护性

2. 案例

需求：

① 开发一款网络游戏（要求：10个主功能）

② 游戏支持web（浏览器）端、App端

③ 游戏上线后预计每日20w玩家在线

3. 分析

• 功能性

需求	测试
1. 10个功能 2. 功能详情（...）	1. 功能数量为10个 2. 功能正确实现 3. 错误处理情况

• 性能

需求	测试
1. 预估每日在线人数20w	1. 服务器每秒处理请求数 2. 服务器硬件配置是否满足

• 兼容性

浏览器	操作系统	手机
谷歌、IE、火狐、欧朋、苹果	win系统：win7、win8、win10 其他	分辨率、品牌、系统、网络、其他

• 易用性：简洁（对比一下竞品）、友好（体积大不大）、流畅、美观

• 可靠性：死机（系统崩溃）、无响应、卡顿（响应时间慢）

• 安全

• 可移植性：可以将数据转移到更优秀的服务器中

• 可维护性：有文档说明、该独立的模块独立出来等等，这样才好维护

四、用例

1. 用例：用户使用的案例（以下都属于用例）

   • 是否能开机：打开手机按下电源键3秒钟，看是否能开机
   • 验证内存：打开手机设置查看内存是否为64G

2. 测试用例：为测试项目而设计的执行文档

3. 测试用例的作用

   • 防止漏测
   • 实施测试的标准

4. 测试用例的编写格式

   • 用例编号：项目_模块_编号

   • 用例标题：预期结果（测试点）

   • 模块/项目：所属项目或模块

   • 优先级：表示用例的重要程度或者影响力p0~p4（p0最高）

   • 前置条件：要执行此条用例，有哪些前置操作

   • 测试步骤：描述测试步骤

   • 测试数据：操作的数据，没有的话可以为空

   • 预期结果：期望达到的结果

5. 案例实践

需求：QQ登录

① 账号为空

② 账号未注册

③ 密码为空

④ 密码错误

• 用例编写

五、测试用例设计方法

1. 等价类划分法——对穷举场景设计测试点

1.1 介绍

• 说明：在所有测试数据中，具有某种共同特征的数据集合进行划分

• 划分为两种情况

  • 有效等价类：满足需求的数据集合
  • 无效等价类：不满足需求的数据集合

• 步骤

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

• 适用场景

  • 针对：需要有大量数据测试输入，但没法穷举测试的地方

    • 输入框
    • 下拉列表
    • 单选复选框

  • 典型代表：页面的输入框类测试

  • 重点

    • 正向用例：一条尽可能覆盖多条
    • 逆向用例：每一条数据都是一条单独用例

1.2 案例1

需求：验证QQ账号的合法性

要求：6~10位自然数

• 步骤

• 用例编写

1.3 案例2

需求：验证某城市电话号码正确性

要求：

① 区号：空或者是三位数字

② 前缀码：非“0”非“1”开头的三位数字

③ 后缀码：四位数字

• 划分有效等价和无效等价

2. 边界值分析法——对限定边界规则设计测试点

2.1 边界范围节点

• 选取正好等于、刚好大于（小于）边界的值作为测试数据
  • 上点：边界上的点（正好等于）【绿色点】
  • 离点：距离上点最近的点（刚好大于、刚好小于）【黄色点】
  • 内点：范围内的点【蓝色点】

• 注意：
  • 在测试中可以将7个点优化为5个点
    • 上点：必选
    • 内点：必选（建议选择中间范围）
    • 离点：开内闭外（开区间选择内部离点，闭区间选择外部离点）
  • 边界值能解决位数限制问题，但不能解决类型问题（要结合等价类）

2.2 步骤

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

2.3 练习

需求：验证qq号码的合法性

要求：6-10位自然数

• 步骤

• 用例编写（蓝色部分可删除）

2.4 使用场景

• 在等价类的基础上针对有边界范围的测试数据输入的地方（重点关注边界）
• 常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语
• 典型代表：有边界范围的输入框类测试
• 常用方式：边界 + 等价类

3. 判定表法——对多条件依赖关系进行设计测试点

• 案例：验证“若用户欠费或者关机，则不允许主被叫”功能的测试

• 说明：

• 等价类边界值分析法主要关注单个输入类条件的测试

• 未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试

3.1 定义及组成部分

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

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

3.2 步骤

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

3.3 案例1：订购单检查

规则：

• 如果金额大于500元，又未过期，则发出批准单和提货单
• 如果金额大于500元，但过期了，则不发批准单和提货单
• 如果金额小于等于500元， 则不论是否过期都发出批准单和提货单
• 在过期的情况下不论金额大小还需要发出通知单

• 步骤

是否大于500	是	是	否	否
是否过期	是	否	是	否
批准单	×	√	√	√
提货单	×	√	√	√
通知单	√	×	√	×

• 用例编写

3.4 案例2：文件修改规则

规则：

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

• 步骤

第一列是A或B	是	是	否	否
第二列是数字	是	否	是	否
输出L	×	×	√	√
输出M	×	√	×	√
文件修改成功	√	×	×	×

• 用例编写

3.5 使用场景

• 有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系
• 判定表一般适用于条件组合数量较少的情况（4个条件以下）
• 若条件超过4个，就不适合覆盖所有条件，应采用正交法来解决

4. 场景法——对于项目业务进行设计测试点

4.1 流程图

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

• 流程图对测试人员有什么用？
  • 能够看懂流程图，设计业务用例
  • 当需求文档信息不全时，能够根据需求梳理出流程

4.1.1 练习

登录、搜索商品、添加购物车、去结算、支付，如果支付成功，则提示下单成功，否则提示支付失败

4.1.2 总结

• 覆盖业务测试，需要使用流程图法【业务用例根据流程图来梳理】
• 先测试业务，再测试单功能、单模块、单页面

4.2 场景法

4.2.1 介绍

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

4.2.2 案例：ATM取款

• 取款流程

• 流程图

• 步骤

1、开始->验证银行卡不成功->结束

2、开始->验证银行卡不成功->密码错误3次->结束

3、开始->验证银行卡不成功->密码验证成功->账户余额不足->结束

4、开始->验证银行卡不成功->密码验证成功->账户余额验证成功->取款金额不正确->结束

5、开始->验证银行卡不成功->密码验证成功->账户余额验证成功->取款金额正确->ATM余额不足->结束

6、开始->验证银行卡不成功->密码验证成功->账户余额验证成功->取款金额正确->ATM余额充足->取款成功->结束

• 用例编写

5.错误推荐法

当项目用例都执行完毕，且BUG修复完成，离上线还有一段时间，在这段时间中可使用错误推荐法复测主要业务或测试未覆盖的功能

• 定义：经过经验推测系统可能出现的问题
• 思想：根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷
• 适用场景
  • 时间紧任务量大时，根据之前项目类似经验找出易出错的模块重点测试
  • 时间宽裕通过该方法列出之前出现问题较多的模块再次测试

6. 练习：单模块用例设计

• 流程图

• 用例数量

六、缺陷管理

1. 缺陷介绍

1.1 定义

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

• 存在缺陷的用例
  • 执行结果与用例预期结果不一致，为缺陷
• 工作流程：设计用例->执行用例（执行测试）->缺陷（提交、验证、关闭）

1.2 判定标准

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

1.3 产生的原因

• 需求阶段：需求描述不易理解，有歧义、错误等
• 设计阶段：设计文档存在错误或者缺陷
• 编码阶段：代码出现错误
• 运行系统：软硬件系统本身故障导致软件缺陷

1.4 软件缺陷的生命周期

• 回归测试：
  • 常规项目回归：项目本次发布新增2个模块，最基本要测新增模块功能及新增模块关联的旧模块
  • 非常规项目（银行、部队、航天）：新增功能，必须全部复测
• 回归bug：上一个版本发现的缺陷，开发修复完毕，在下个版本进行重新验证

1.5 软件缺陷的核心内容

• 缺陷的标题：描述缺陷的核心问题
• 缺陷的前置条件：缺陷产生的前提
• 缺陷的复现步骤：复现缺陷的过程
• 缺陷的预期结果：希望得到的结果
• 缺陷的实际结果：实际得到的结果
• 缺陷的必要附件：图片、日志等信息（证据）

1. 缺陷描述：发现缺陷以后如何描述，让别人看得懂

2. 缺陷提交：指派人、优先级、类型等......

3. 一般可以使用excel、专业的缺陷管理工具

1.6 缺陷提交要素

• 缺陷报告编号：缺陷的唯一性标志
• 严重程度
  • 严重（S1）：主功能
  • 一般（S2）：次要功能
  • 微小（S3）：易用性、界面
  • 建议（S4）：建议性问题
• 缺陷优先级
  • Priority 0：24小时之内解决
  • Priority 1：发布前必须修复
  • Priority 2：可以在下一个版本中修复
• Bug类型：代码错误、兼容性问题、设计缺陷、性能问题
• 缺陷状态
  • New：新建
  • Open：打开
  • Closed：关闭
  • Postponed：延期

1.7 缺陷类型

• 功能错误
• 界面（UI）错误
• 兼容性
• 数据
• 易用性
• 改进、建议
• 架构

2. 缺陷编写

当你无意或按照用例发现一个缺陷时，要把这个中间的步骤记录下来，用于其他人看到了可以依据这个步骤将这个缺陷再演示出来。这个就是重现。

2.1 示例

2.2 缺陷的跟踪流程

提交 -> 验证 -> 关闭

2.3 提交缺陷注意事项

• 可重现：缺陷可以复现
• 规范性：符合公司或项目要求
• 唯一性：一个缺陷上报一个问题（提交时要检查缺陷是否已存在）

2.4 缺陷编写规范

• 准确：描述的信息是正确的
• 具体：有细节且是真是特定的
• 简洁易懂：描述简单容易理解
• 次序清晰：描述缺陷过程有条件，有先后顺序

3. 缺陷管理工具

1. 项目管理工具 - 管理缺陷（禅道、JIRA、TFS）
2. Excel管理缺陷

3.1 禅道的介绍

• 地址：https://demo.zentao.net/user-login.html

• 特点

  • 国产、免费、开源、简单、轻量级
  • 三管融合（产品管理、项目管理、质量管理）

• 各个角色的工作

3.2 禅道使用流程

3.3 使用禅道管理缺陷

• 要求：将以下缺陷通过禅道进行管理

• 创建缺陷

• 提交缺陷

• 关闭缺陷（开发解决缺陷之后）

5. 缺陷标题分析

6. 总结

七、项目实战

1. 产品功能架构

• 产品主要分为三个前端子产品
  • 用户端：App，用户可以查看资讯、文章内容，进行问答讨论交流
  • 自媒体运营平台：PC网站，自媒体用户可以管理文章、评论，查看分析粉丝数据
  • 系统后台：PC网站，内部运营管理系统

2. 项目功能测试

• 网址：https://pc-toutiao-python.itheima.net/#/login

2.1 测试对象

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

2.2 需求 - 登录

• 输入正确的中国手机号（11位）
  • 当文本框失去焦点时验证，红色为失败，绿色为成功
• 点击发送验证码
  • 若手机号文本框状态为绿色，弹出“点击按钮进行验证”
  • 若手机号文本框为红色，提示手机号不正确
• 点击按钮进行验证
  • 拖拽图形到指定位置，按钮消失
  • 拖拽图形未到指定位置，晃动提醒，滑块回到初始位置
  • 超过5次，提示尝试过多，请点击重试
• 输入验证码
  • 正确的验证码，并“勾选我已阅读并同意”，点击登录，进入系统
  • 错误的验证码，并“勾选我已阅读并同意”，点击登录，提示验证码错误
  • 正确的验证码，未“勾选我已阅读并同意”，点击登录，提示请勾选
• 点击登录
  • 手机号、验证码都为绿色，勾选“我已阅读并同意”，登录成功

2.3 明确需求后如何开始测试

• 分析需求
• 提取测试点
• 设计用例
• 用例评审
• 执行用例
• 缺陷管理
• 测试报告

2.4 用例设计 - 登录

2.6 需求 - 发布文章

• 文章标题不少于5个字符
• 文章内容不能为空
• 频道不能为空
• 封面选择
  • 单图
  • 三图
  • 无图
  • 自动
• 点击选择图片
  • 素材库、上传图片切换
  • 素材库
    • 全部和收藏切换
    • 图片可以选择
  • 上传图片
    • 点击选择图片 - 选择本地文件
    • 点击开始上传 - 如果已经选择本地文件，点击上传，上传成功
    • 点击开始上传 - 如果未选择本地文件，提示“请选择一张图片”
• 点击发表，提示新增文章成功，跳转到内容列表，文章状态显示待审核
• 点击存入草稿，提示新增文章成功，跳转到内容列表，文章状态显示草稿

2.7 用例设计 - 发布文章