测试需求分析第一部分
一、 界面中的控件知识
1 文本框和密码框
文本框
长度要求；
输入内容限制。
密码框
长度要求；
不允许明文显示；
禁止复制粘贴；
输入内容限制；
两次密码要一致。
2 单选按钮、 组合列表框 、 数码框
单选按钮
框架标题/提示文本不缺失且正确；
各个选项正确；
执行同一功能的多个单选按钮只能选中一个；
要有默认选中项；
一般不能取消选中；
存入后台的数据正确。
组合列表框/下拉列表
通常单选，条目内容要正确（没有多余/错放项、缺少项）；
横向显示要完整；
条目功能要正确实现；
组合列表框中可能允许输入数据。
数码框（up-down 控件）
能使用上下箭头控制数字变动；
数字有范围限制；
数字自动循环或者到达边界时停止；
可以直接输入数字。
3. 复选框
选项正确；
可以不选、任意选一个、任意选多个、全选；
可以取消选中；
每一个复选框功能都正确实现。
4.列表框
通常多选；
条目内容要正确（多余/错放项、缺少项）；
横向显示完整，纵向显示完整；
条目功能要正确实现。
二、 大纲法分解功能
1 大纲法
大纲法主要用于对软件进行功能拆分。
模块
包含多个功能操作的对象或功能集合，如文件（菜单）等。
功能点/功能
能独立完成一件事或一个业务。如新建、打开等。
业务流程
软件为了完成业务或完成核心功能所经历的步骤。
业务逻辑
是对业务的不同处理方式。
业务规则
如要求用户名只能用英文，5-11 个字符等。
案例
即时贴程序部分需求说明
便签的数量最多为 50 个
便签标题字数最多为 40 个字节
便签的正文文字数量最多为 200 个
年份只能设置在 1900－2100 之间
2 开始编写测试需求分析
将功能拆分与整理的需求信息写入测试需求分析
三、 测试需求分析与测试用例设计方法
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 机余额不足：提示错误并退卡
步骤三：根据基本流和备选流生成不同的场景
3 错误推测
3.1 测试若干原则回顾
测试不是验证软件正确，而是攻击软件，发现错误。
测试要时刻保持怀疑的态度，具有缺陷预防意识。
测试要寻求系统设计、功能设计的弱点。
设计负面的、异常的测试，如考虑错误的或者异常的输入，往往可以发现更多的软件缺陷。
3.2 什么是错误推测
在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试方法。
错误推测分类
输入数据测试方面
输出数据测试方面
数据结构测试方面
文件系统方面
3.3 输入数据方面的错误推测
3.3.1 输入非法数据
一般用于键盘输入数据时。
测试方法
输入非法类型
输入非法范围/长度
输入非法格式
注意
错误信息的检查：需要额外考虑错误提示信息的内容
错误信息和错误要对应一致
错误信息不能为空
错误信息的内容不能只是错误代码，不能包含开发信息
错误信息不能中英文混合