手工测试总结

测试基础

软件测试分类

按阶段分类

• 单元测试
• 集成测试
• 系统测试
• 验收测试

是否覆盖源代码

• 黑盒测试
• 白盒测试
• 灰盒测试

是否运行

• 动态测试
• 静态测试

是否自动化

• 手工测试
• 自动化测试

其他

• 冒烟测试
• 回归测试
• 随机测试
• 探索测试

软件开发模型

• 瀑布模型
  • 需求分析=》概要设计=》详细设计=》编码=》软件测试=》软件维护

  软件工程的重要环节：瀑布模型

• 敏捷开发模型

软件测试模型

• V模型
  • 需求分析=》概要设计=》详细设计=》编码=》单元测试=》集成测试=》系统测试=》验收测试
• W模型
  • 开发V
    • 需求分析=》概要设计=》详细设计=》编码=》集成测试=》实施=》交付
  • 测试V
    • 验收系统测试设计=》集成测试设计=》单元测试设计=》单元测试=》集成测试=》系统测试=》验收测试
    • 测试参与了软件开发全生命周期

软件质量模型

• 功能性：检查业务功能是否满足要求
• 可靠性
• 易用性
• 效率性
• 可维护性
• 可移植性

测试用例

• 概念：测试用例，也叫Test Case，为了特定的目的而设计的一组测试输入，执行条件和预期结果的文档。
• 组成要素：
  • ID
  • 模块
  • 优先级
  • 用例标题
  • 预置条件
  • 测试步骤
  • 测试数据
  • 预期结果
• 测试用例的作用
  • 便于理清测试思路，确保覆盖测试的功能点无遗漏
  • 便于测试工作量的评估
  • 便于提前准备测试数据
  • 便于把控测试工作进度
  • 便于回归测试
  • 便于测试工作的组织，提高测试效率，降低测试交接成本

测试用例设计

等价类

• 概念：通过科学的方法找到具有共同特性的测试输入的子集，能够从穷举测试中解放(大大减少了测试用例的数量，从而提升测试效率)
• 分类
  • 有效等价类
  • 无效等价类
    • 输入内容
    • 长度
    • 类型
    • 是否为空
    • 是否重复
• 使用场景：输入框
• 测试用例步骤：
  • 需求分析
  • 划分等价类
  • 设计测试用例

边界值

• 基于边界值【有效等价类和无效等价类的分界点】设计测试用例的一种【黑盒】方法
• 作用：对等价类的补充，统计表明程序最容易出错的地方就是在边界附近。
• 设计步骤：
  • 需求分析
  • 划分等价类
  • 确定边界值
  • 设计测试用例

判定表

• 概念：是一种以表格形式表达多条件逻辑判断的工具
• 组成
  • 条件桩：所有输入条件，如欠费状态、关机状态
  • 动作桩：所有可能的输出结果，如允许主被叫、不允许主被叫
  • 条件项：单个条件的取值范围，一般都是有等价类和无效等价类
  • 动作项：基于每一种条件的组合，得到确认的结果，如打不通等
• 测试测试用例的步骤
  • 明确需求
  • 画出判定表
    • 列出条件桩和动作桩
    • 填写条件项，对条件进行全组合
    • 根据条件项的组合确定动作项
    • 简化、合并相似规则（有相同的动作）
  • 根据规则编写测试用例

因果图

• 用图解的方法表示输入的各组合关系，写出判定表，进而设计测试用例的一种【黑盒测试】方法。
• 适用场景：适用于分析程序输入条件的各种组合情况，以及输入和输出之间的依赖关系。
• 因果关系：
  • 恒等 - ：条件成立，结果成立。
  • 非 ~ ：条件成立，结果不成立；条件不成立，结果成立。
  • 与 ^ ：只要有一个条件成立，结果就成立；所有条件都不成立时，结果才不成立。
  • 或 v ：多个条件必须同时成立，结果成立；只要有一个不成立，结果就不成立。
  • 设计测试用例步骤;
    • 需求分析
    • 画出因果图
    • 将因果图转换为判定表
    • 生成测试用例
• 输入条件比较少（2,3,4），推荐直接使用判定表;输入条件比较多（>4）,推荐使用因果图。

正交法

• 核心思想：用最小的测试用例获得最大的测试覆盖率
• 正交表：一种特制的表，一般的正交表标记为:Ln(m^k)
  • K代表因素（输入参数）
  • m叫水平（输入参数的取值）
  • n代表测试用例数
  • 读法：k因素m水平

场景法

• 概念：场景法就是模拟用户操作软件的场景，主要用于多个测试功能之间的组合使用情况
• 流程图

状态迁移图

• 概念：是一种基于产品规格分析，对系统的每个状态及状态相关的功能进行测试，通过不同的状态验证程序逻辑的逻辑流程
• 使用步骤：
  • 明确状态节点
  • 绘制状态迁移图
  • 绘制状态迁移树
  • 抽取测试路径设计用例

错误推测法

• 概念：利用经验或智慧发现程序中可能犯错的地方
• 使用场景：
  • 重要功能
  • 使用同类型产品
  • 任务急、时间紧、资源少

测试用例设计方法总结

• 具有输入功能，但输入之间没有组合关系==》【等价类】
• 输入有边界，如长度、类型==》【边界值】
• 多输入、多输出、输入与输出之间存在组合关系、输入与输出之间存在依赖或制约关系==》【判定表、因果图】
• 用最少的测试用例获得最大的测试覆盖率时==》【正交法】
• 多个功能的组合测试==》【场景法、流程图】
• 最后推荐使用【错误推测法】来进一步补充测试用例

缺陷管理

• 定义：软件在使用过程中存在的任何问题（如：错误、异常等），都叫软件的缺陷，简称bug
• 标准：
  • 软件未实现需求（规格）说明书中明确要求的功能
  • 软件出现了需求（规格）说明书中指明不应该出现的错误
  • 软件实现的功能超出需求（规格）说明书指明的范围
  • 软件未实现需求（规格）说明书中虽未明确指明但应该实现的要求,一般指国际/国家/行业/企业标准规范或者法规的要求
  • 软件难以理解，不易使用，运行缓慢，用户体验不好
• 组成要素
  • 编号
  • 状态
  • 所属模块
  • 严重程度
  • 优先级
  • 预期结果
  • 实现结果
  • 复现步骤
  • 缺陷类型
    • 打开
    • 新建
    • 重新打开
    • 关闭
    • 修复
    • 拒绝
    • 延期处理
• 缺陷报告：
  • 组成要素
  • 重要性：它是一个与开发的沟通渠道，体现测试的专业度
  • 注意事项：
    • 确保bug能够稳定复现
    • 推荐一个bug记录在一个缺陷报告里面
    • 在什么情况下发生了什么事，结果是什么
    • 站在开发的角度多思考
  • 书写规范：
    • 标题：应保持简短、准确，提供缺陷的本质信息
    • 复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤
    • 实际结果：是执行复现步骤后软件的现象和产生的行为
    • 预期结果：通常需要列出期望的结果是什么
    • 附件：对缺陷描述的补充说明
• 管理工具：禅道
• 缺陷状态：
  • 激活
  • 处理中
  • 已解决
  • 已关闭
• 缺陷跟踪管理
  • 场景1：确认BUG解决
    • 测试【新建】=》开发【打开】=》开发【解决】=》测试【关闭】
  • 场景2：验证未通过，缺陷仍存在
    • 测试【新建】=》开发【打开】=》开发【解决】=》测试【重新打开】
  • 场景3：开发延期处理
    • 测试【新建】=》开发【打开】=》开发【延期】
  • 场景4：拒绝处理
    • 测试【新建】=》开发【打开】=》开发【拒绝】

测试准备及项目测试流程

搭建测试环境

• 基本要素
  • 操作系统
    • windows
    • Linux
  • web服务器
    • apache：80
    • nginx：80
    • tomcat：8080
    • iis
  • 数据库
    • mysql
    • …
  • 项目
    • php
    • …
• 组合
  • WAMP
    • 准备
    • 安装集成环境=》phpstudy=》apache，mysql
    • 部署项目
  • LNMP
    • 准备
    • 安装集成环境=》lnmp=》nginx，mysql
    • 部署项目

测试流程

• 需求分析与评审
• 编写测试计划与测试方案
• 设计测试用例与评审
• 执行用例与缺陷跟踪
• 编写测试报告