一、测试项目启动与研读需求文档

（一） 组建测试团队

1 测试团队中的角色

2 测试团队的基本责任
  • 尽早地发现软件程序、系统或产品中所有的问题。
  • 督促和协助开发人员尽快地解决程序中的缺陷。
  • 帮助项目管理人员制定合理的开发和测试计划。
  • 对缺陷进行跟踪、分析和分类总结，以便让项目的管理人员和相关的负责人能够及时、 清楚地了解产品当前的质量状态。
  • 帮助改善开发流程、提高产品开发效率。
  • 促进程序编写的规范性、易读性、可维护性等
3 测试团队与开发团队的 3 种模式
  • （1）以开发为核心，测试只是开发队伍的一部分，也就是开发团队中有测试人员，但 没有形成独立的团队
  • （2）以项目经理为核心，开发小组和测试小组并存，隶属于项目经理领导。
  • （3）项目经理、开发组长和测试组长“三足鼎立”，测试团队具有独立的、权威的地 位。

（二）软件质量需求

1 软件质量需求的分类
  • 软件质量需求用于确定测试目标。
  • 测试目标包括：功能、性能、界面、易用性、兼容性、安全性、可用性/可靠性、可维 护性、可扩展性等。
  • 功能以外统称非功能。
2 功能
  • 软件能做什么？
  • -需要做什么？
  • 怎么做是正确的？
  • 哪些功能要测试、哪些功能不需要测试？
  • 哪些功能重要，哪些不重要？
  • 哪些功能先实现或先测试？
3 性能
  • 反映软件运行时的效率和占用资源情况的能力。
     时间特性：时间短、速度快、效率高。
     资源特性：占用资源（CPU、内存、硬盘、网络）少。
4 界面（UI）
  • 布局合理；
  • 控件位置恰当；
  • 文字没有乱码、字体大小合适；
  • 颜色使用恰当；
  • 图片、表格恰当、舒适、美观。
5 易用性
  • 在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。
6 兼容性/可移植性
  • 指软件产品从一种环境迁移到另一个环境的能力，反映一个软件与不同的硬件环境、操 作平台、其他软件的共同使用的能力。
     包括与不同硬件、平台、软件自身不同版本、其他软件、数据的兼容。
7 安全性
  • 指软件产品保护信息和数据的能力。
8 可用性/可靠性
  • 指系统正常运行的能力或程度，可用性=正常运行时间/（正常运行时间+非正常运行时 间）×100%。
     可用性指标一般要求达到 4 个 9 即 99.99%（全年 52 分钟不正常工作）或 5 个 9 即 99.999%（全年 5 分钟），对一些军事系统，可用性高达 7 个 9（99.99999%（全年 失效时间不超过两秒）。
     一般测试时间不足，可以采用空间换时间的办法，如在高负载情况下进 行为期一周 或一个月的测试，以判断其可靠性。
     关注 MTTF（平均无故障时间）、MTTR（平均恢复时间）、MTBF（平均失效间 隔时间）。
9 可维护性
  • 指软件产品可被修改的能力。
     修改可能包括修正、改进或软件对环境需求和功能规格说明变化的适应。
     可维护性的软件应该是易改变的、稳定的、易测试的。
10 可扩展性/可伸缩性测试
  • 通过很少的改动就能实现整个系统处理能力的增长。
     如在部署两台服务器时测试系统性能（容量，即最大负载），再部署四台、八台服 务器时分别进行系统容量的测试，看其容量是否为上次（两台、四台）实验值的两 倍或接近两倍。如果是，系统就具有良好的可伸缩性。

（三）研读需求文档

1 测试需求分析的过程
  • 收集与研读文档，提出并解决问题，整理需求信息
  • 功能拆分、功能描述/需求整理
  • 编写测试点
  • 需求评审
2 研读需求文档
2.1 研读文档主要任务
  • 提取有用的需求信息
  • 提出需求中不清晰、不理解、不明白的问题
     和用户、业务人员、产品经理或产品设计人员、开发人员等沟通
2.2 怎么研读文档
  • 分析思路
     分析软件的用户群，分析用户的实际需要；
     分析软件的开发环境、开发语言、数据类型；
     分析软件架构、软件的运行环境和平台、数据库类型；
     分析软件要实现哪些目标（功能、性能、界面、易用性、兼容性、安全性）以 及具体的要求是什么；
     分析软件有哪些功能，每种功能要完成什么业务，这些业务应该怎么实现，业 务逻辑是什么，业务流程是怎样的，业务规则有何要求；
     分析功能或业务间的联系，哪些业务更关键或重要；
     明确测试周期，测试目标，测试范围。
  • 细节上
     分析每个模块或功能上实现的功能
     设计的开发原理包括数据类型
     从用户使用场景角度分析业务流程
     记录业务规则
  • 实施
     以情景再现的形式写出需求信息。
2.3 研读需求文档案例
  • 拿到一个项目，怎么入手？
    – 即时贴程序部分需求说明
     便签的数量最多为 50 个
     便签标题字数最多为 40 个字节
     便签的正文文字数量最多为 200 个
     年份只能设置在 1900－2100 之间

(四)需求评审

1 意义
  • 对软件需求进行正确性的检查。
  • 保证软件需求的可测试性。
  • 通过产品需求文档的评审，与市场、产品、开发等各部门相关人员沟通，使得大家 认识一致，避免在后期产生不同的理解，引起争吵。
  • 通过产品需求文档的评审，更好地理解产品的功能性和非功能性需求
  • 在需求文档评审通过后，测试的目标和范围就确定了。虽然此后会有需求的变更， 但可以得到有效的控制，这样可降低测试的风险。
  • 评审是否完成是以需求文档获得多方“邮件确认”或“签字”通过为标志的。这不 应该只体现在“签字”形式上，更重要的是达到下面的结果。
     所有参与方达成一致。
     已发现的问题被阐述清楚、被修正。
2 需求评审的质量要求
  • 正确性
  • 完备性
  • 易理解性
  • 一致性
  • 可行性
  • 易修改性
  • 可测试性
  • 可追溯性
3 需求评审的参加人员
  • 用户代表
  • 需求人员
  • 产品经理
  • 项目经理
  • 开发人员
  • 开发经理
  • 测试人员
  • 测试经理
  • 市场经理
  • 质量保证人员
4 测试人员参与评审时的注意事项
  • 明确自己的角色和责任。
  • 熟悉评审内容，为评审做好准备，做细做到位。
  • 在评审会上，针对问题阐述观点，而不是针对个人。
  • 可以分别讨论主要的问题和次要的问题。
  • 在会议前或会议后可以就存在的问题提出自己建设性的意见。
  • 提高自己的沟通能力，采取适当的、灵活的表述方式。
  • 对发现的问题跟踪下去。
  • 应该在需求形成的过程中进行分阶段的多次评审，而不是一次评审。
  • 测试人员要善于提问，多思考
     这些需求都是用户提出来的吗？
     有没有画蛇添足的需求？没有漏掉什么需求吗？
     和竞争对手的产品做过比较吗？我们的产品优势体现在哪里？
     是否正确地描述了每个需求？这条描述是否存在二义性的问题？
     我的理解和文档作者的理解一致吗？

二、测试需求分析与测试用例设计

（一） 界面中的控件知识

1 文本框和密码框

2 单选按钮、组合列表框、数码框

3 复选框

4 列表框

5 命令按钮

6 其他界面元素

三、 测试需求分析与测试用例设计方法

1 场景法

1.1 测试点/检查点

  • 测试时应该考虑可以测试的诸多方面。

1.2 场景法概述

  • 场景法模拟用户操作软件时的情景，主要用于测试系统的业务流程。
  • 当拿到一个测试任务时，我们先要关注它的主要功能和业务流程是否正确实现，这 就需要使用场景法来完成测试。

1.3 场景的定义

  • 场景用来描述软件操作的路径。
  • 基本流
  • 按照正确的业务流程来实现的一条操作路径（模拟正确的操作流程）。
  • 备选流
  • 导致程序出现错误的操作流程（模拟错误的操作流程）。

1.4 场景法的分析步骤

  • 分析软件需求
  • 从用户使用情景角度，写出业务流程和业务规则
  • 写出基本流场景和备选流场景

1.5 场景法案例：ATM 机取款

  • 步骤一：分析业务流程（可以绘制流程图）


    步骤二：描述程序的基本流及备选流

    • 1、基本流（正确的流程）
      （1）插入银行卡：客户将银行卡插入 ATM 机的读卡器
      （2）验证银行卡：ATM 机从银行卡的磁条中读取账户代码，并检查它是 否属于可以接受的银行卡
      （3）输入密码：ATM 机要求客户输入密码
      （4）验证密码：确定该密码是否正确 
      （5）进入 ATM 主界面：ATM 显示在本机中可用的各种选项
      （6）选择取款并输入金额：客户选择“取款”，并选择取款金额
      （7）ATM 机验证：ATM 机进行验证账户余额是否满足以及总取款金额 是否满足要求，验证 ATM 机内现金是否够用
      （8）更新账户余额、出钞：验证成功，更新账户余额，输出现金，提示 用户收取现金
      （9）返回主界面

  • 2、备选流（各种错误情况）
    （1）银行卡无效：提示错误并退卡
    （2）密码错误：提示错误，并判断是否 3 次错误
    （3）密码 3 次错误：吞卡
    （4）账户余额不足：提示错误并退卡
    （5）总取款金额超出当日可取限额：提示错误并退卡
    （6）ATM 机余额不足：提示错误并退卡

步骤三：根据基本流和备选流生成不同的场景

2 等价类划分

2.1 案例引入
测试两位数加法器（学生思考、讨论、陈述）

2.2 等价类划分核心思想

  • 通过需求分析，找出程序的输入域。
  • 将输入域划分成若干类。
  • 每一类中选取代表性数据等价于这一类中的其他值。
    2.3 等价类划分的步骤
  • 需求分析
  • 划分等价类（根据需求，有效等价类、无效等价类）并细化（根据计算机知识）
    2.4 等价类划分案例
  • 步骤 1：需求分析

    • 阅读文档 ：
       借助开发知识
       与开发或用户沟通
       了解用户群及行业知识

    • 写出需求：
       -99~99 之间的整数

  • 步骤 2：划分等价类并细化
  • 有效类
     -99 到 99 之中的整数
     细化 ：负数、0 、正数
  • 无效类
     超范围 ：<-99 或 >99
     非法类型 ： 浮点数 、 字符（串）

2.5等价类划分注意事项

  • 不但要考虑有效等价类，也要考虑无效等价类
  • 两块划成一块（等价类划分过粗），结果？
     遗漏一种测试情况
  • 一块划成两块（等价类划分过细），结果？
     冗余测试
  • 仔细划分，审查划分
     过于粗略可能会漏掉软件缺陷
     积累经验

3边界值分析

3.1 边界值分析的思想与步骤

  • 分析需求，找出边界。
  • 写出边界值
     最小值
     小于最小值
     最大值
     大于最大值
    3.2边界值分析案例
  • 两位数加法计算器的边界值 ： -99 、-100、99 、100
    3.3 为什么分析边界值
    看看下面的代码有错误吗？

     输入或输出的边界最容易产生错误。

4 决策表

前面测试两位数加法计算器的测试没有考虑输入组合。

4.1 决策表的分析步骤
  • 需求分析

    • 分析输入和输出
       用等价类划分分析输入的各种情况、输出的各种情况
  • 画判定表
  • 分析与简化判定表
4.2 决策表案例

  • 分析输入条件和输出条件

    • 输入

    • 输出
       正确计算
       错误提示

  • 原始决策表/判定表

  • 优化决策表

    • 优化策略
       测试基本功能的保留；
       一个输入错误，另外输入无所谓，可以整合；
       所有输入都要错误过。

  • 最终的决策表

4.3 决策表的局限性与优化策略

导致测试量爆炸。

5 错误推测

5.1 测试若干原则回顾
  • 测试不是验证软件正确，而是攻击软件，发现错误。
  • 测试要时刻保持怀疑的态度，具有缺陷预防意识。
  • 测试要寻求系统设计、功能设计的弱点。
  • 设计负面的、异常的测试，如考虑错误的或者异常的输入，往往可以发现更多的软件缺陷。
5.2 什么是错误推测

在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对 性地编写检查这些错误的测试方法。

  • 错误推测分类
     输入数据测试方面
     输出数据测试方面
     数据结构测试方面
     文件系统方面
5.3 输入数据方面的错误推测

输入非法数据

  • 一般用于键盘输入数据时。

    • 测试方法
       输入非法类型
       输入非法范围/长度
       输入非法格式
  • 注意
  • 错误信息的检查：需要额外考虑错误提示信息的内容
  • 错误信息和错误要对应一致
  • 错误信息不能为空
  • 错误信息的内容不能只是错误代码，不能包含开发信息
  • 错误信息不能中英文混合
5.4 错误推测
  • 输入非法类型
  • 输入非法范围（数值）
  • 输入非法长度（个数）
  • 输入非法格式
  • 输入默认值
  • 输入特殊字符
  • 输入合法数据的非法组合
  • 粘贴强制输入
  • 一个输入多个输出不要遗漏
  • 输出结果（含数据库）要正确
  • 上溢、下溢（含结果）
  • 操作数与操作符不符
  • 文件超载
  • 文件权限不足
  • 介质忙或不可用
  • 介质损坏

输入默认值

  • 适用于有默认值的地方。
  • 测试方法
     接受软件的默认值
     键入空值
     将默认值改为另外一个值
     将默认值改为另外一个值，再变为空值

输入特殊字符（集）