测试复习

通识/基础/概念

什么是软件测试

• 验证软件特性是否满足用户的需求

专业名词

• 需求

  • 满足用户期望或正式文档（合同、标准、规范）所具备的条件和权能，包含用户需求和软件需求

    • 用户需求
    • 软件需求

  • 是测试人员开展软件测试工作的依据

  • 如何让测试人员更好了解需求呢

    • 从需求分析阶段测试人员就介入（测试应当贯穿软件的生命周期）

• bug

  • 什么是bug

    • 规格说明存在且正确的时候，程序和规格说明之间的不匹配才是错误
    • 当需求规格说明书没有提到的功能，以用户为标准判断：程序没有实现最终用户合理预期的功能要求时，就是软件错误

  • 如何描述一个bug(简单了解，笔试)

    • 标题

    • 发现bug的版本

    • 发现bug的环境

    • 发现bug的步骤

    • 期望的结果

    • 实际的结果

    • 其他

      • bug类型
      • bug等级

  • bug的级别(具体要看企业的bug定级标准文档)

    • 崩溃
    • 严重
    • 一般
    • 次要

  • bug的生命周期

    • New

      • 新发现bug，未经评审决定是否指派给开发人员修改

    • Open

      • 确认是bug，并且认为需要进行修改，指派给相应的开发人员

    • Fixed

      • 开发人员修改后标识为修改状态，有待测试人员的回归测试验证

    • Rejected

      • 认为不是bug，拒绝修改

    • Delay

      • 认为暂时不需要修改或暂时不能修改，则延后修改

    • Closed

      • 修改状态的bug，经测试人员的回归测试验证通过，则关闭bug

    • Reopen

      • 经验证bug仍然存在，则重新打开bug，开发人员重新修改

    • 具体流程

软件开发的生命周期

• 需求分析

  • 分析用户需求是否合理（技术可行性、市场可行性）
  • 产出软件需求文档

• 计划

  • 指定需求执行计划
  • 产出计划文档

• 设计

  • 将需求细化成任务，进行技术设计（设计哪些接口，采用哪些技术）
  • 产出设计文档

• 编码

  • 开发人员按照需求文档以及设计文档来进行编码

• 测试

  • 测试人员参考测试用例，执行测试

• 运行维护

  • 项目上线后对产品进行线上维护

• 测试是如何贯穿软件的整个生命周期的

  • 需求分析

    • 分析需求逻辑是否合理，是否符合用户行为习惯。还要站在开发人员角度思考技术实现难度，针对技术难度来合理调整需求

  • 计划

    • 根据需求文档编写测试计划/方案

  • 设计

    • 适当了解设计，合理的进行测试用例的设计和调整

  • 编码

    • 专业的白盒测试人员可以执行单元测试，完善、细化测试用例以及调整测试计划和方案

  • 测试

    • 测试人员参考测试用例执行测试

  • 运行和维护

    • 测试往往是最了解需求的人，进行产品的演示和功能的介绍，期间记录大家的反馈建议，反馈给产品经理，成为一个新的用户需求

软件测试的生命周期

• 需求分析

  • 站在用户的角度：需求逻辑是否正确，是否符合用户的需求和行为习惯
  • 站在开发人员的角度：需求是否可以实现，或实现起来的难度大小

• 测试计划

  • 指定测试计划：测试工时、人力安排等

• 测试设计、测试开发

  • 设计测试用例（经验丰富的白盒测试人员可以开始单元测试）

• 测试执行

  • 参考测试用例来执行测试

• 测试评估

  • 测试人员需要记录测试，做好缺陷管理，进行测试的评估

跟开发产生争执了怎么办

• 具有批判性思维，反思是不是自己bug描述的不够清楚

• bug等级一定要有理有据

• 合理友好的进行沟通，站在用户的角度反问，假如你是用户，你能接受吗？

• 不仅能够提问题，最好也能够给出解决方案

• 组织bug评审，邀请代表参加bug评审：产品代表、开发代表、测试代表

  • 如何解决bug
  • 如何预防类似的bug

常用模型

开发模型

• 瀑布模型

  • 

  • 是其他所有模型的基础框架

  • 特点：线性的开发流程，不能应对需求的变化

  • 缺点

    • 测试被后置

      • 风险往往在后期的测试阶段才能被发现，因而失去了及早纠正的机会
      • 必须在代码完成后有足够的时间预留给测试活动，否则导致测试不充分，从而缺陷直接遗留给用户

    • 最大的缺陷是，产品要很迟才能被看到

  • 适用于固定的小项目

• 螺旋模型

  • 

  • 引入全流程的风险评估，每次分析完后后，都会生成一个新的原型

  • 适用于规模庞大、复杂度高、风险大的项目

  • 缺点：时间拉长，人力、资金耗费大

• 敏捷模型

  • 敏捷宣言（了解）

  • scrum

    • 三个角色

      • 产品经理

        • 收集用户需求，编写需求文档，对产品负责

      • 项目经理

        • 召开各种会议，协调项目，为团队研发服务

      • 研发团队

        • 开发人员、测试人员、UI人员等

    • 五个会议

      • 发布计划会议

        • 制定出这一期要完成的stroy列表，sprint backlog

      • 迭代计划会议

        • 任务分解，划分负责人，初步工时

      • 每日例会

        • 了解项目进度，预知风险并规避
        • 产出物：可交付的软件

      • 演示会议

        • 迭代结束后，展示成果。期间记录反馈，由po整理成新的story
        • 产出物：新的user story

      • 回顾会议

        • 项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，以达到持续改进的效果

    • 

  • 特点：轻流程、轻文档、重目标、重产出

• 增量模型和迭代模型

  • 增量模型

    • 逐块构造
    • 先画头，再画身体，再画四肢

  • 迭代模型

    • 反复求精
    • 先画轮廓，再完善其他细节

测试模型

• V模型

  • 特点

    • 明确标注了测试的类型
    • 明确标注了测试阶段和开发阶段的关系

  • 缺点

    • 风险别推迟到测试的时候才发现，失去及早纠正的机会
    • 必须给测试留足够的时间，不然风险会遗留给用户

  • 

• W模型

  • 特点：测试从需求阶段就开始介入了

  • 缺点

    • 上一个阶段完成，下一个阶段才能开始
    • 开发模型和测试模型也保持着一种前后的线性关系
    • 重文档、重过程 => 不支持敏捷模型

  • 

测试用例

测试用例

• 解决了测什么，怎么测

• 是为了实施测试而面向被测试的系统提供的一组集合

  • 测试环境

    • 操作系统版本
    • 浏览器版本

  • 测试步骤

  • 测试数据

  • 预期结果

• 为什么要设计测试用例

  • 围绕软件需求来设计测试用例

    • 解决了重复测试的问题
    • 原则：避免用后即弃

设计测试用例的万能公式

• 界面测试

  • 看得到的都要测试

• 功能测试

• 性能测试

  • eg登录注册的响应时间，千万人同时访问接口

• 兼容性测试

  • 系统版本
  • 软件版本
  • 终端
  • 不同浏览器

• 易用性测试

  • 产品是否简单易上手、方便使用

• 安全测试

  • 针对物品来说

    • 本身是否有毒
    • 其他干扰环境下是否有毒有害

  • 针对一个软件功能来说

    • sql注入
    • xxs漏洞
    • 越权（垂直越权、水平越权）

• 其他测试（根据测试对象的特性）

设计测试用例的方法

• 基于需求设计测试用例

  • 需求分析
  • 需求有哪些功能呢个
  • 设计测试点
  • 设计测试用例

• 等价类

  • 针对需求输入范围划分成若干个等价类，从其中一个等价类取出一个用例，若该测试用例通过，则认为该测试用例所在的等价类是通过的

  • 步骤

    • 确定有效等价类和无效等价类
    • 编写测试用例

  • 

• 边界值

  • 通常是对等价类的补充
  • 设计边界值测试用例的时候，需要加上边界值＋次边界值
  • 

• 判定表法

  • 一种表达逻辑判断的工具

  • 为什么别人写的因果图，而你使用判定表？

    • 根据因果图画判定表，我认为画因果图很多余，而且因果图在设计测试用例的时候并没有多大意义

  • 步骤

    • 确认输入和输出条件
    • 找出输入条件和输出条件的关系
    • 画判定表
    • 根据判定表编写测试用例

  • 

  • 适用于需要考虑输入之间的组合关系，不同的组合关系对应的输出结果不同

• 正交表法

  • 步骤

    • 找到因素数和水平数
    • 用allpairs工具生成正交表
    • 根据正交表来编写测试用例
    • 补充测试用例

  • 正交表达式

  • 

• 场景设置法

  • 步骤

    • 基本事件流
    • 备用事件流

  • 

• 错误猜测法

  • 依赖测试人员的个人工作经验
  • 用到万能公式、弱网测试、异常测试

测试分类

按照测试对象分类

• 文档内存兼容性，界面易用可双安

• 界面测试（UI测试）

  • 非软件

    • 颜色
    • 大小
    • 材质
    • 形状
    • 整体是否美观

  • 软件

    • 尺寸、颜色、形状、整体适配清晰度

      • 输入框
      • 文本框
      • 滚动条
      • 按钮
      • 文字
      • 图片

• 可靠性测试（*）

  • 可靠性 = 正常运行时间 / (正常运行时间＋非正常运行时间) * 100%，一般要求达到4个9或者5个9

• 容错性测试

  • 指系统能够处理异常，用户的操作不至于系统崩溃，从而能够提高系统的可用性

• 文档测试

  • 通常来说是需求评审阶段，测试人员需要进行需求分析（文档测试）

• 兼容性测试

  • 浏览器兼容性

    • Chrome
    • Firefox
    • Edge
    • Safari

  • 平台兼容性

    • PC端（Windows、Mac、Linux）
    • 移动端（安卓、苹果）

  • 自身兼容性

    • eg.Chrome软件的1~103版本

  • 其他软件兼容性

    • 其他软件的引流入口都不同

  • 数据兼容性

• 易用性测试

  • 软件需要具备简单易上手的特性

• 安装卸载测试

  • 移动端很容易遗漏卸载测试

• 安全测试

  • SQL注入

  • XSS漏洞

  • 越权

    • 垂直越权
    • 水平越权

• 性能测试

  • 资源泄露
  • 资源瓶颈（CPU、内存、网络、进程对比），采长补短

• 内存泄露测试

  • 工具检查

    • 静态代码扫描工具

  • 人工检查

按照是否查看代码划分

• 黑盒测试

  • 把代码看做一个黑匣子，不关心内部结构和内部特性，只关心功能是否符合产品规格说明书

  • 别称

    • 数据驱动测试
    • 功能测试

  • 常见的黑盒测试设计测试用例的方法

    • 等价类
    • 边界值
    • 判定表
    • 正交法
    • 场景法
    • 错误猜测法

• 白盒测试

  • 检查程序内部实现、检查程序的运行状态是否符合预期

  • 别称

    • 逻辑驱动测试
    • 结果测试

• 灰盒测试

  • 介于两者之间，既要关心内部构造和内部特性
  • 通常用在集成测试

• 常见的测试方法有哪些？哪种用得更多？

  • 黑盒测试和白盒测试，在工作中需要根据实际情况来结合黑盒测试和白盒测试。通常来说，测试人员使用黑盒测试要多一点

• 为什么不直接用灰盒测试？

  • 灰盒测试没有白盒测试详细、完整，没有黑盒测试覆盖产品范围广，所以灰盒测试不能取代黑盒测试和白盒测试。
  • 黑盒测试可以取代灰盒测试，但是不建议，需要消耗很大的代价

按照开发阶段划分

• 单元测试

  • 针对系统最小单元进行测试
  • 最小单元是人为规定的

• 集成测试

  • 完成单元测试后，将模块和模块之间集成，按照功能来进行测试

• 冒烟测试

  • 由测试人员来执行，检查系统主要功能/流程是否正常，评估软件/系统是否具备可测性的条件/标准

• 系统测试

  • 集成测试完成后，测试人员准备项目环境，将程序看成一个整体，对程序/系统进行系统测试，保证系统功能符合产品规格说明书的要求

• 回归测试

  • 对历史版本/功能进行测试，保证功能是符合要求的
  • 随着功能迭代越来越多，版本越来越多，回归测试的难度相对于来说要大一些，需要借助自动化测试来进行回归测试

• 验证测试

  • 通常是用户来进行验收测试，目的就是为了验证产品/程序是否符合用户的需求。实际上主要是由产品/运营来进行验收

思维导图总结

需要pdf可以评论区d