软件测试基础【笔记】

1. 软件测试理论

1.1 软件的概述

1.1.1 做好测试需要具备的思维

1. 用户思维【产品/项目经理】
2. 架构思维【开发人员】
3. 测试思维【具备清晰的逻辑思维能力、怀疑求证、量化统计】

1.1.2 软硬件是什么

1. 硬件就是计算机硬件的简称，是由机械、光电元件等组成的各种的物理装置的总称，它们按系统结构要求构成一个有机整体为计算机软件运行提供物质基础【就类似于打地基】

​ 特点： 看得见摸得着

2. 软件就是一系列按照特定顺序组织的计算机数据和指令的集合

​ 特点： 看得见摸不着

1.2 软件分类

1.2.1 按维度分类

1. 按开发规模分类
   

2. 按用户对象分类
   

3. 按功能分类
   

4. 按技术结构分类
   

B/S架构图

C/S架构图

1.3 软件测试是什么

1.3.1 概念

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

1.3.2 测试对象

对源程序和各阶段的文档

1.3.3 测试目的

找出缺陷/BUG

2. 软件开发流程

2.1 软件开发模型

概念： 规范化的软件开发流程

测试人员为什么要了解开发模型？

1. 了解何时介入测试，何时结束测试
2. 了解各阶段的重心

2.1 软件开发模型分类

1. 边做边改模型
2. 瀑布模型
3. 快速原型模型
4. 增量模型
5. 螺旋模型
6. 智能模型
7. 混合模型
8. RUP模型
9. IPD模型

常见软件开发模型 https://www.jianshu.com/p/6f2c10d9f8a9

2.2 瀑布模型

2.2.1 概念与生命周期

1. 制定计划
2. 需求分析
3. 软件设计
4. 软件编码
5. 软件测试
6. 运行维护

规定自上而下，相互衔接，固定的次序

2.2.2 流程图

2.2.3 详细流程图

2.2.4 特点以及优缺点

特点： 线性模型，其他模型都是基于瀑布模型的基础

优点：

1. 阶段清楚
2. 一个阶段只执行一次，当前阶段结束后，只需要关注一下一个阶段的工作
3. 文档驱动

缺点：

1. 反工量大
2. 不适用于需求变化的项目

应用场景： 需求清晰的大型项目【建筑、银行、保险】

2.3 快速原型模型

2.3.1 概念

在开发系统之前，先做一个原型demo，然后让用户参与进来，从而达到手机相关的系统反馈信息，最终使得完成整个项目的开发

2.3.2 优缺点

优点：

1. 用户参与
2. 降低了需求变化带来的项目失败的风险

缺点：

1. 不适用于大型项目

应用场景： 需求变化的中小型项目

2.4 敏捷开发模型

2.4.1 基本原则

1. 个体和交互 胜过过程和工具
2. 快要工作的软件 胜过 面面俱到的文档
3. 客户合作胜过合同谈判
4. 响应变化 胜过遵循计划

2.4.1 特点

1. 以人为本（效率快）
2. 一切从简（时间短）
3. 尽早交付
4. 持续迭代，持续交付，周期越短越好

3. 软件测试流程

概念： 规范化的软件测试流程

3.1 软件测试模型分类

3.1.1 V模型（*）

概念： 将整个测试分为开发和测试，并且开发和测试之间是串行的关系

优缺点

优点： 开发和测试之间是串行

缺点： 测试介入过晚，返工量大

3.1.2 W模型（*）

概念： W模型是由两个V模型组成，一个开发阶段，另一个测试阶段

优缺点

优点： 开发和测试之间是并行、测试可以提早介入

缺点： 虽然开发和测试并行，但总体流程还是串行的，不支持敏捷开发流程

3.1.3 X模型

3.1.4 H模型

3.2 最佳实践流程-1（在企业真正的实际流程）

3.2.1 角色

1. 产品

2. UI设计

3. 开发

   • 前端开发

   • 后端开发

4. 测试

5. 运维

3.2.2 周期

最佳实践流程的周期 1-2周

3.2.3 各阶段需要做的事

1. 需求阶段
   • 拿到需求文档后，对比同类产品，确认需求合理性
   • 参与需求评审
   • 根据用户体验，给出建议
2. 开发阶段
   • 评审
     • UI设计评审
     • 前后端设计评审：代码逻辑和数据库设计
   • 本职工作
     • 测试计划和测试用例
     • 发起测试用例评审
3. 测试阶段
   • 部署项目
   • 执行测试
   • 发现bug，定位bug，bug管理
   • 输出测试报告
4. 验收阶段
   • 在预生产环境，点点点
   • 完善文档
5. 线上运行
   • 点点点
   • 收集线上bug，进行验证

3.3 软件测试维度分类

3.3.1 按阶段划分

1. 单元测试：指对软件中的最小单元进行测试和验证（最小单元指的是函数）

   • 应用场景：测试某个函数的功能是否实现正确

2. 集成测试：在单元测试的基础上，将所有模块按照设计要求组装成子系统，进行测试

   • 原因：有些模块虽然可以单独工作，但是并不能保证集成起来也可以正常工作

3. 系统测试：经过集成测试的软件和操作系统/硬件看做一个整体，在实际运行环境下进行测试

4. 验收测试：

   • 按对象分类：

     • 产品验收：产品经理组织的基于需求文档验证
     • 项目验收：客户组织的基于最开始的需求进行验证性测试，主要检测乙方（软件实施方）完成的系统是否满足甲方（付款方）的业务需求

   • 按阶段分类：

     • α测试：（内测版本）
     • β测试：（公测版本）
     • γ测试：（待发布版本）

   • 负责人：

     • 对于产品：产品经理和客户
     • 对于项目：客户（甲方dad）、测评机构和乙方（软件实施方）

3.3.2 按是否考虑代码逻辑划分

1. 黑盒测试

   • 概念：把测试对象看作一个不能打开的黑盒子，不需要考虑内部结构和逻辑，根据需求文档检查功能是否符合需求
   • 测试依据：需求文档
   • 重点：以用户的角度，从输入数据到输出数据的对应关系出发进行测试
   • 分类：
     • 功能相关：
       • 功能测试：检查产品功能是否满足需求
       • UI测试：检查页面元素是否符合UI的设计，页面是否美观
       • 易用性测试：用户体验
       • 专项测试：如安装卸载升级、网络等专项测试
     • 性能相关：
       • 性能测试：模拟用户场景，测试系统的各项性能指标，查看是否满足需求
       • 压力测试：在高压（高负载/资源少）的情况下运行测试，找出性能隐患
       • 负载测试：不断增加负载，测试软件吞吐量上限，以验证系统的负载能力

2. 白盒测试

   • 概念：把测试对象看作一个透明的盒子，测试时需要考虑程序内部结构和逻辑，通过在不同的市场检查程序的状态，检验程序中的每条路径是否能够按照预定要求正确工作

   • 测试依据：源代码

   • 重点：必须检查程序内部结构，从程序的逻辑入手，得出测试数据（输入和输出）

   • 对应关系：

     • 单元测试：白盒
     • 集成测试：白盒
     • 系统测试：黑盒
     • 验收测试：黑盒

3. 灰盒测试

   • 概念：介于黑盒测试和白盒测试之间，只关注一部分代码逻辑

3.3.3 按是否运行代码划分

1. 静态测试

   • 概念：静态测试指的是不允许被测试程序本身，仅通过分析或者检查源程序的语法/结构/过程等检查程序的正确性
   • 测试对象：
     • 文档：需求文档和设计文档
     • 源程序：找出代码可能重复的地方、找出不安全因素

2. 动态测试

   • 概念：动态测试指的是通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率，正确性，健壮性等
   • 测试对象：系统
   • 步骤：
     • 用例设计
     • 执行用例
     • 检查预期结果与实际结果是否一致

3.3.4 按是否自动化划分

1. 手工测试：手工的方式去执行测试

2. 自动化测试：需要借助根据或者代码去完成手工测试的工作

3.3.5 其他划分

1. 回归测试：
   • 概念：回归测试是指修改代码之后，重新测试程序，已确认修改没有引入新的错误
   • 应用场景：bug回归和旧功能回归
   • 回归原则：每个版本都需要进行回归测试
   • 缺点：工作量大
   • 解决方案：
     • 自动化测试：自动化测试可以大幅度降低系统测试，维护升级等阶段的成本
2. 冒烟测试：针对最基本的测试的功能或流程进行的测试
   • 比如：商城系统，一套最基本的流程包含注册 --> 登录 --> 浏览商品 --> 添加购物车 --> 下订单 --> 支付和收货，如果期间有任何一个流程出错【这里就冒烟了】，返回去重新修改后在再次冒烟测试
3. 随机测试：
   • 需要一定的相关经验
   • 测试一些重要的功能
   • 测试其他人没有测试到的模块
4. 探索性测试：测试用例设计和测试用例执行同时进行，为了能够完善测试用例，进行完整的系统测试

4. 测试用例

4.1 概述

4.1.1 概念

一个为了特定目的而设计的，包含测试输入、执行条件和预期结果的文档

4.1.2 作用

1. 理清测试思路，确保需要覆盖的测试的功能点无遗漏
2. 评估测试工作量：量化
3. 把控测试工作进度
4. 提前准备测试数据
5. 回归测试
6. 组织测试工作，提高测试效率，降低测试交接成本

4.2 测试用例的八大要素

4.2.1 八大要素

1. 编号：唯一性
2. 模块
3. 标题：见名知意
4. 预置条件：外在网络和系统服务等、本模块的前置条件
5. 测试数据
6. 测试步骤
7. 预期结果：需求文档
8. 优先级：在资源、时间、人员受限时，测试用例执行的先后顺序

4.2.2 登录案例

编号ID	模块	标题	预置条件	测试数据	测试步骤	预期结果	优先级	实际结果
login_001	登录	输入正确的用户名和密码，登录成功	网络正常	1.打开浏览器，输入网址 2.输入用户名和密码 3.点击登录按钮	用户名： xiaoan 密码：123456	登录成功	高	pass
login_001	登录	输入正确的用户名和错误的密码，登录失败	网络正常	1.打开浏览器，输入网址 2.输入用户名和密码 3.点击登录按钮	用户名： xiaoan 密码：123	登录失败，请输入输入正确的用户名和密码	中	fail

5. 用例设计方法

5.1 总体介绍

5.1.1 应用场景

黑盒测试的测试用例时无法穷尽的，需要科学的方法帮我们把无限变为有限

5.1.2 常见八大用例设计方法

1. 等价类(***)
2. 边界值(***)
3. 判定表(***)
4. 因果图(**)
5. 正交法(*)
6. 场景法(***)
7. 流程图法(***)
8. 错误推测法(**)

5.1.3 重点用例设计

5.1.3.1 等价类划分法

• 应用场景：与等价类混合使用【边界值是等价类划分法的重要补充，大量程序错误往往是容易发生在边界上】
• 步骤：
  1. 需求分析
  2. 划分等价类：有效/无效等价类 ==> 满足需求的输入范围为有效等价类，反之为无效等价类
  3. 确定边界值：找出上点、内点和离点
  4. 设计测试用例
• 举例
  • 需求： qq用户名的输入 需求：6-10位自然数
  • 步骤：
    1. 需求分析
       • A：6-10位
       • B：自然数
    2. 划分等价类
       • 有效等价类：同时满足A和B的条件
       • 无效等价类：
         • 不满足A，满足B【不足6位数，10位以上自然数】
         • 满足A，不满足B【6-10位的非自然数】
         • A，B都不满足【不足6位非自然数，10位以上非自然数】
    3. 确定边界值
       • 上点：6，10
       • 内点：8
       • 离点：5，11
    4. 设计测试用例
       • 有效等价类：同时满足A和B的条件 ==> 6，7，8，9，10位自然数
       • 无效等价类：
         • 不满足A，满足B【不足6位数，10位以上自然数】 ==5位自然数，11位自然数
         • 满足A，不满足B【6-10位的非自然数】 ==> 6，7，8，9，10位非自然数
         • A，B都不满足【不足6位非自然数，10位以上非自然数】 ==>5位非自然数，11位非自然数

编号ID	模块	标题	预置条件	测试数据	测试步骤	预期结果	优先级	实际结果
qq_login_001	登录	输入账号6-10位自然数	/	xiaoan123	账号： xiaoan123	输入成功	高	pass
qq_login_001	登录	输入账号不足6位自然数	/	xiao	账号： xiao	输入失败	高	fail

5.1.3.2 边界值法

• 应用场景：有需要输入数据的地方，如输入框【从大量数据中划分范围，然后从每个范围中挑选代表数据】

• 步骤：

  1. 需求分析
  2. 划分等价类：有效/无效等价类 ==> 满足需求的输入范围为有效等价类，反之为无效等价类
  3. 设计测试用例

• 举例

  • 需求： qq用户名的输入 需求：6-10位自然数
  • 步骤：
    1. 需求分析
       • A：6-10位
       • B：自然数
    2. 划分等价类
       • 有效等价类：同时满足A和B的条件
       • 无效等价类：
         • 不满足A，满足B
           • 不足6位数
           • 10位以上自然数
         • 满足A，不满足B
           • 6-10位的非自然数
         • A，B都不满足
           • 不足6位非自然数
           • 10位以上非自然数

• 练习：输入文章标题，要求标题长度10-20个字符

  • 需求： 文章标题的输入需求：10-20个字符

  • 步骤：

5.1.3.3 判定表法

• 应用场景：用于处理复杂的业务逻辑，可以避免遗漏测试点

• 组成：

  1. 条件桩：列出所有可能的条件
  2. 动作桩：列出所有可能的操作
  3. 条件项：列出所有可能的条件取值组合
  4. 动作项：列出在每一种取值组合的情况下，执行动作桩中的哪些动作

• 步骤：

  1. 需求分析

  2. 通过判定表法，列表分析
     

  3. 设计测试用例，每列数据对应一条测试用例

• 举例

  • 需求： 若用户欠费或关机，则不允许主被叫

  • 步骤：

    1. 需求分析
    2. 通过判定表法，列表分析

    

    3. 设计测试用例，每列数据对应一条测试用例

5.1.3.4 因果图法

应用场景：

1. 输入条件或者输出条件的组合比较多，组合是由判定表和因果图
2. 为什么是由因果图？ ==> 借助图像手段分析判定表

5.1.3.5 正交法

概念：是一种古希腊的实验设计方法，基于数学概率学知识，设计最经济的实验路径

应用场景：输入条件较多，每个条件的取值可能性也比较多时，可以使用正交法

5.1.3.6 场景法

应用场景：主要应用于系统测试、验收测试阶段，模拟用户操作场景（测试多个功能组合）

步骤：

1. 需求分析
2. 确定基本流和备选流设计测试场景
   • 基本流：模拟用户正常流程的操作环境
   • 备选流：模拟用户错误流程的操作环境
3. 一个场景就是一条用例

举例：

• 需求：测试微信发红包功能，用场景法设计测试用例
• 步骤：
  1. 分析用户操作微信发红包可能遇到的情况
  2. 分析场景：
     • 场景一：成功发送红包 ==> 基本流
     • 场景二：余额不足 ==> 备选流1
     • 场景三：被删除好友/被拉黑==> 备选流2
     • 场景四：网络异常 ==> 备选流3
  3. 编写测试用例：一个场景就是一条用例
• 注意：以结果为导向去推演

5.1.3.7 流程图法

应用场景：

1. 用流程图的方式去展现基于用户使用的场景
2. 先用流程图来表示，然后用场景法来组织测试用例

步骤：

1. 需求分析
2. 绘制流程图

3. 设计测试用例

举例：

• 需求：根据ATM取款机的功能，画出业务流程图

5.1.3.8 错误推测法

应用场景：测试人员使用经验或直觉去发现程序错误

有经验的测试人员如何使用该方法？

• 举例：
  1. 新开发的功能，与其相关的业务，或者数据，容易出现问题
  2. 分页功能，页码搜索
  3. 新功能，异常场景
  4. 列表展示功能，数据为空，是否报错
  5. 文本框，杜宇特殊字符的处理

5.2 测试用例设计方法总结

原则：

1. 具有输入功能，但输入之间没有组合关系 ==> 推荐等价类
2. 输入有边界如长度、类型 ==> 用边界值补充测试用例
3. 多输入、多输出，输入和输出存在组合关系 ==> 推荐使用判定表
4. 多个功能的组合测试 ==> 流程图和场景法
5. 最后推荐使用错误推测法来进一步补充测试用例

6. 软件缺陷与管理

6.1 软件缺陷概述

6.1.1 概念

软件缺陷就是找软件的毛病。它可能存在于功能/性能/易用性等各方面，包括已发现和未发现的

缺陷 = BUG

6.1.2 通俗理解

• 行内标准
  1. 软件未实现需求文档要求的功能
  2. 软件实现了需求文档未提到的功能
  3. 软件未实现需求文档未明确提及但应该实现的目标
  4. 软件难以理解/不易使用/运行缓慢或从测试人员的角度，最终用户会认为不好
• 概括总结：实际结果与预期结果不一致

6.1.3 思考

只有在测试阶段才去发现和解决bug？

1. 需求阶段
2. 开发/设计阶段
3. 测试阶段
4. 线上阶段

6.2 缺陷产生的原因

1. 需求原因：需求文档错误/有疏漏等
2. 编码原因：设计有误/编码有误等
3. 其他原因：时间紧，沟通理解有问题，甚至于立项就是个错误等
4. 思考：缺陷的产生，与测试人员有关系吗？没有

6.3 缺陷的描述

1. 应用场景：测试人员发现bug后，应准确无误的描述bug，描述的内容应该具有规范性

2. 要素：

   1. 编号ID ==> 唯一性
   2. 模块
   3. 缺陷标题 ==> 见名知意
   4. 严重程度
      • 严重：主要功能不可用，crash问题【系统崩溃、黑屏、闪退等】
      • 一般：次要功能【异常未处理、边界】
      • 微小：易用性问题、界面展示和小的性能问题等
      • 建议：
   5. 优先级
      • 高：阻塞性问题【不能注册就不能登录下单，影响继续测试，必须立即修复】
      • 中：正常流程，本次迭代上线前修复即可【支付问题】
      • 低：可以延期到下一个版本解决
   6. 复现步骤
   7. 预期结果
   8. 实际结果
   9. 缺陷类型：代码错误/界面错误/兼容性错误/性能错误/安全问题/易用性问题
   10. 缺陷状态
       • 新建
       • 已指派
       • 打开
       • 修复（已解决）/拒绝/延期
       • 关闭/再次打开

   6.4 缺陷报告

   1. 概念：一个记录缺陷的文档
   2. 组成：包括缺陷描述的全部内容，测试人员的相关信息，开发人员的相关信息，环境相关信息等

   

   3. 注意事项：
      • 一个缺陷对应一个报告
      • 尽量确保缺陷可以重现
        • 一定能重现
        • 概率出现，把概率写清楚
        • 只出现1次，需要测试人员认真记录，并思考重现的过程
      • 简洁、准确和完整

6.4 BugList[缺陷清单]

6.5 缺陷统计

1. 应用场景：统计数据需要整理到测试报告中，方便项目相关负责人熟悉当前测试版本的整体质量

2. 作用：

   • 直观了解版本质量，了解隐患
   • 绩效考核

3. 统计维度

   • 按照缺陷的活动分布统计 ==> 第几轮测试？验收测试？线上？
   • 按照缺陷的严重程度 ==> 严重的多？建议的多？
   • 按照缺陷引入源分布 ==> 需求引入？编码引入？
   • 按照模块统计 ==> 哪个模块
   • 按照负责人统计 ==> 哪个开发人员产生的bug
   • 按照解决方案统计 ==> 已解决？不是bug？无法重现？设计如此？不予解决？外部原因？

   

6.6 缺陷管理-禅道

6.6.1 测试人员使用流程

• 测试用例管理

  1. 编写用例

  2. 用例评审

     

  3. 用例执行

• bug管理

  1. 提交bug
  2. 回归测试
  3. 导出报表

  

6.7 SVN