Loading

零基础快速入门软件测试

一、项目

1. 项目成员

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

  • 项目：软件研发项目，包括从前期项目预研、立项、组建项目团队、设计开发软件、测试调试、交付验收，以及软件运营等各项具体的工作

  • 项目经理：软件项目的总负责人，既需要有广泛的计算机专业知识，又需要具有项目管理技能，能够对软件项目的成本、人员、进度、质量、风险、安全等进行分析和管理，从而使软件项目能够按照预定的计划顺利完成

  • 需求：指用户需求，有了用户需求才能开发相应的产品，它通常包括功能性需求和非功能性需求

  • 用户：指提出需求的用户，同时也是软件验收的主要人员

  • 开发人员：通过代码来实现软件各项功能的程序员

  • 测试人员：负责软件测试

  • 产品人员：根据用户提供的原始需求，制定出更为规范的需求文档，并且需要不断与用户交流确认，直至用户满意为止

2. 项目开发的简要流程

  • 用户将原始需求提交给产品人员，产品人员根据原始需求制定需求文档

  • 产品人员把制定好的需求文档给到开发人员和测试人员，三者进行需求评审（消除歧义，完善需求细节，达成共识）

  • 开发人员按照需求文档进行开发

  • 测试人员测试产品是否符合需求文档里的要求

3. 如何评审需求文档

  • 正确性：对照用户的原始需求，检查产品人员制定的需求文档是否偏离了用户的原始需求

  • 明确性：检查需求文档中每个需求项描述是否清晰，是否有歧义

  • 完整性：对照用户的原始需求，检查产品人员制定的需求文档是否覆盖了用户提出的所有需求项，每个需求项是否遗漏了用户提出的必要信息

  • 限制性：每个需求项是否清晰描述了这个软件能做什么、不能做什么，能输入（输出）什么、不能输入（输出）什么

  • 优先级：需求文档中的哪些功能比较重要，哪些功能比较次要，是否做了标识和编号

  • 一致性：检查需求文档中的内容前后是否一致，确保不矛盾

4. 测试流程

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

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

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

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

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

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

二、初识软件测试

1. 职业规划

  • 技术型路线

    • 从功能测试做起，积累一定经验后，可根据兴趣往自动化测试、性能测试、安全测试等方向发展

  • 管理型路线

    • 如果对团队管理比较感兴趣，可以往测试主管、测试经理、测试总监的方向发展。注意，作为一名团队的管理者，需要在测试技术的某一方面比较精通，否则只有管理经验没有技术经验是无法管理好团队的

  • 产品和市场路线

    • 软件测试人员长期测试产品，对产品的各项功能、用户体验、产品性能等方面比较了解，因此可以考虑转向产品策划类工作、市场培训、技术支持、售后服务等工作

  • 开发路线

    • 积累了一定编程能力后再转向软件开发

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

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

  • 软件功能测试技术

    • 即手工测试。主要包含软件需求规格说明书的评审、测试计划、测试用例设计、环境搭建、测试执行（缺陷提交、回归测试）、测试报告等；功能测试主要体现在用例设计和缺陷提交两方面

  • Web 自动化测试的初级应用能力

  • 接口测试的初级应用能力

  • Linux 操作系统中常用的命令

  • 数据库的基本 SQL 语法

  • ...

3. 认识软件测试

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

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

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

  4. 测试方向

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

    • 自动化测试：使用代码或工具代替手工，对项目进行测试

    • 接口测试：使用代码/工具验证程序中的接口是否访问正常

    • 性能测试：模拟多人使用软件，查找服务器缺陷

  5. 测试分类

    • 按测试阶段分

      • 单元测试：针对程序源代码进行测试

      • 集成测试：又称接口测试，针对模块之间访问地址进行测试

      • 系统测试：对整个系统进行测试包括功能、兼容、文档等测试

      • 验收测试：主要分为内测、公测，使用不同人群来发掘项目缺陷

    • 按代码可见度分

      • 黑盒测试：不关注源代码，针对程序 UI 功能进行测试【系统测试】

      • 灰盒测试：针对部分源代码进行测试【接口测试】

      • 白盒测试：针对程序源代码进行测试【单元测试】

  6. 冒烟测试

    • 针对每个版本或每次需求变更之后，在正式测试之前，对产品或系统的一次简单的验证性测试，验证产品或系统的“基本功能”流程是否正常

    • 简单理解：在执行正式测试之前的“预测试”

    • 目的：确认软件的基本功能正常，可以进行后续的正式测试工作

  7. 回归测试

    • 在发布新版本后，测试其以前的功能仍然正常，同时，也要验证缺陷是否被修复

    • 目的：验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能

三、质量模型

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 位自然数

  • 步骤
image-20240310005827894
  • 用例编写

1.3 案例 2

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

要求：

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

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

③ 后缀码：四位数字

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

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

2.1 边界范围节点

  • 选取正好等于、刚好大于（小于）边界的值作为测试数据

    • 上点：边界上的点（正好等于）【绿色点】

    • 离点：距离上点最近的点（刚好大于、刚好小于）【黄色点】

    • 内点：范围内的点【蓝色点】

image-20240310164001231

  • 注意：

    • 在测试中可以将 7 个点优化为 5 个点

      • 上点：必选

      • 内点：必选（建议选择中间范围）

      • 离点：开内闭外（开区间选择内部离点，闭区间选择外部离点）

    • 边界值能解决位数限制问题，但不能解决类型问题（要结合等价类）

2.2 步骤

  1. 明确需求

  2. 确定有效和无效等价

  3. 确定边界范围

  4. 提取数据编写用例

2.3 练习

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

要求：6-10 位自然数

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

2.4 使用场景

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

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

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

  • 常用方式：边界 + 等价类

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

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

  • 说明：

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

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

3.1 定义及组成部分

  • 定义：是一种以表格形式表达多条件逻辑判断的工具

  • 组成

    • 条件桩：列出问题中的所有条件，条件之间无顺序之分

    • 动作桩：列出问题中可能采取的操作，操作之间无顺序之分

    • 条件项：列出条件对应的取值，所有可能情况下的真假值

    • 动作项：列出条件项的、各种取值情况下应该采取的动作结果

  • 规则

    • 判定表中贯穿条件项和动作项的一列就是一条规则

    • 假设有 n 个条件，每个条件的取值有两个（0, 1），全组合有2n种规则

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）
  1. Excel 管理缺陷

3.1 禅道的介绍

3.2 禅道使用流程

3.3 使用禅道管理缺陷

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

  • 创建缺陷

  • 提交缺陷

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

5. 缺陷标题分析

6. 总结

七、项目实战

1. 产品功能架构

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

    • 用户端：App，用户可以查看资讯、文章内容，进行问答讨论交流

    • 自媒体运营平台：PC 网站，自媒体用户可以管理文章、评论，查看分析粉丝数据

    • 系统后台：PC 网站，内部运营管理系统

2. 项目功能测试

2.1 测试对象

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

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

2.2 需求 - 登录

  • 输入正确的中国手机号（11 位）

    • 当文本框失去焦点时验证，红色为失败，绿色为成功

  • 点击发送验证码

    • 若手机号文本框状态为绿色，弹出“点击按钮进行验证”

    • 若手机号文本框为红色，提示手机号不正确

  • 点击按钮进行验证

    • 拖拽图形到指定位置，按钮消失

    • 拖拽图形未到指定位置，晃动提醒，滑块回到初始位置

    • 超过 5 次，提示尝试过多，请点击重试

  • 输入验证码

    • 正确的验证码，并“勾选我已阅读并同意”，点击登录，进入系统

    • 错误的验证码，并“勾选我已阅读并同意”，点击登录，提示验证码错误

    • 正确的验证码，未“勾选我已阅读并同意”，点击登录，提示请勾选

  • 点击登录

    • 手机号、验证码都为绿色，勾选“我已阅读并同意”，登录成功

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

  • 分析需求

  • 提取测试点

  • 设计用例

  • 用例评审

  • 执行用例

  • 缺陷管理

  • 测试报告

2.4 用例设计 - 登录

2.6 需求 - 发布文章

  • 文章标题不少于 5 个字符

  • 文章内容不能为空

  • 频道不能为空

  • 封面选择

    • 单图

    • 三图

    • 无图

    • 自动

  • 点击选择图片

    • 素材库、上传图片切换

    • 素材库

      • 全部和收藏切换

      • 图片可以选择

    • 上传图片

      • 点击选择图片 - 选择本地文件

      • 点击开始上传 - 如果已经选择本地文件，点击上传，上传成功

      • 点击开始上传 - 如果未选择本地文件，提示“请选择一张图片”

  • 点击发表，提示新增文章成功，跳转到内容列表，文章状态显示待审核

  • 点击存入草稿，提示新增文章成功，跳转到内容列表，文章状态显示草稿

2.7 用例设计 - 发布文章

posted @ 2024-12-04 22:41  iRuriCatt  阅读(9)  评论(0)  编辑  收藏  举报