说明：该篇博客是博主一字一码编写的，实属不易，请尊重原创，谢谢大家！

一、界面中的控件知识

1.文本框和密码框

• 文本框
  √ 长度要求；
  √ 输入内容限制。

• 密码框
  √ 长度要求；
  √ 不允许明文显示；
  √ 禁止复制粘贴；
  √ 输入内容限制；
  √ 两次密码要一致。

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

• 单选按钮
  √ 框架标题/提示文本不缺失且正确；
  √ 各个选项正确；
  √ 执行同一功能的多个单选按钮只能选中一个；
  √ 要有默认选中项；
  √ 一般不能取消选中；
  √ 存入后台的数据正确。

• 组合列表框/下拉列表
  √ 通常单选，条目内容要正确（没有多余/错放项、缺少项）；
  √ 横向显示要完整；
  √ 条目功能要正确实现；
  √ 组合列表框中可能允许输入数据。

• 数码框（up-down 控件）
  
  √ 能使用上下箭头控制数字变动；
  √ 数字有范围限制；
  √ 数字自动循环或者到达边界时停止；
  √ 可以直接输入数字。

3.复选框

• 复选框
  √ 选项正确；
  √ 可以不选、任意选一个、任意选多个、全选；
  √ 可以取消选中；
  √ 每一个复选框功能都正确实现。

4.列表框

• 通常多选；
• 条目内容要正确（多余/错放项、缺少项）；
• 横向显示完整，纵向显示完整；
• 条目功能要正确实现。

5.命令按钮

• 实现所需的功能；
• 出现错误时，给出切当明确的提示信息。

6.其他界面元素

• 窗口标题
  √ 不缺失；
  √ 显示正确。

• 选项卡
  √ ctrl+tab 切换

• 默认焦点

• Tab 顺序

• 快捷键/热键
  √ 使用 ctrl 或 alt+其它字母
  √ 同一窗口、界面或菜单中不能重复

二、大纲法分解功能

1.大纲法

大纲法主要用于对软件进行功能拆分。

• 模块
  √ 包含多个功能操作的对象或功能集合，如文件（菜单）等。

• 功能点/功能
  √ 能独立完成一件事或一个业务。如新建、打开等。

• 业务流程
  √ 软件为了完成业务或完成核心功能所经历的步骤。

• 业务逻辑
  √ 是对业务的不同处理方式。

• 业务规则
  √ 如要求用户名只能用英文，5-11 个字符等。

• 案例
  √ 即时贴程序部分需求说明
  ✰ 便签的数量最多为 50 个
  ✰ 便签标题字数最多为 40 个字节
  ✰ 便签的正文文字数量最多为 200 个
  ✰ 年份只能设置在 1900－2100 之间

2.开始编写测试需求分析

• 将功能拆分与整理的需求信息写入测试需求分析
  

3.项目实战

3.1 将之前的写的学生信息管理系统中的连接数据库服务器进行功能拆分

• 在excel表格中进行连接数据库服务器功能拆分，其中的二级功能其实是看不到的，所以可以不写二级功能
  

3.2 填写原始需求

• 将之前分析后的需求结合文档填写即可
  

3.3 需求整理

• 根据之前我们分析文档做出的需求分析进行整理
  

3.4 登录模块需求填写

• 首先查看需求规格说明书
  
• 然后查看系统设计说明书
  
  
• 填写原始需求
  
• 登录模块需求整理
  

3.5 修改密码模块需求整理

• 查看需求规格说明书
  
  
• 修改密码需求整理
  

3.6 添加用户模块需求整理

• 查看需求规格说明书
  
• 添加用户需求整理
  

3.7 修改用户信息模块需求整理

• 查看需求规格说明书
  
• 修改用户信息需求整理
  

3.8 删除用户模块需求整理

• 查看需求规格说明书
  
• 删除用户需求整理
  

3.9 学生注册模块需求整理

• 查看需求规格说明书
  
• 学生注册需求整理
  

3.10 查询学生信息模块需求整理

• 查看需求规格说明书
  
• 查询学生信息需求整理
  

3.11 修改学生信息模块需求整理

• 查看需求规格说明书
  
• 修改学生信息需求整理
  

3.12 删除学生信息模块需求整理

• 查看需求规格说明书
  
• • 删除学生信息需求整理
    

3.13 关于以及退出模块需求整理

• 查看需求规格说明书
  
• 关于及退出需求整理
  

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

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 机余额不足：提示错误并退卡

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

1.6 场景法练习

• 记事本上对以上三角形程序进行需求分析
  
• 根据需求分析，写出基本流和备选流
  

2.等价类划分

2.1 案例引入

• 测试两位数加法器（学生思考、讨论、陈述）
  

2.2 等价类划分核心思想

• 通过需求分析，找出程序的输入域。

• 将输入域划分成若干类。

• 每一类中选取代表性数据等价于这一类中的其他值。

2.3 等价类划分的步骤

• 需求分析

• 划分等价类（根据需求，有效等价类、无效等价类）并细化（根据计算机知识）

2.4 等价类划分案例

• 步骤 1：需求分析
  √ 阅读文档
  √ 借助开发知识（每个开发语言的数据类型字符长度不一致）
  √ 与开发或用户沟通（针对用户群）
  √ 了解用户群及行业知识
  √ 写出需求：
  ✰ -99~99 之间的整数

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

2.5 等价类划分练习

ATM 机的取款测试：取款最少 50，最多 5000，每笔 50 的倍数，测试取一笔。

需求：50~5000 ，50的倍数
有效类：50~5000 50的倍数
无效类：小于50 大于5000 非50的倍数；不输入取款金额丶输入字符（前提ATM机键盘有字符）

2.6 等价类划分注意事项

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

2.7 思考题

• 密码框的输入范围 4-10 位
• 程序要求输入 BOOLEAN 型数据
• Microsoft Office 中，选择字体的组合框
  
• 要求用户名由字母或数字组成，必须由字母开头，不包含特殊字符，最大长度为12
• 日期文本框

解决：

• 密码框测试点
  √ 有效等价类：4-10位
  √ 无效等价类：小于4和大于10

• 程序输入类型测试点（根据开发语言来分辨是否区分大小写）
  √ 有效等价类：true和false
  √ 无效等价类：true和false以外的

• Office 中选择字体测试点
  √ 有效等价类：选择组合框中存在的字体，输入组合框中存在的字体
  √ 无效等价类：输入不存在的字体

• 用户名组成测试点
  √ 有效等价类：纯字母丶字母加数字 长度不超过12
  √ 无效等价类：数字开头，包含特殊字符，长度大于12，长度为0（也就是不输入）

• 日期文本框测试点
  √ 在分析之前需要了解产品用户，因为每个国家的日期排序规则不一样，如英国为日丶月丶年，美国为月丶日丶年，中国为年丶月丶日；并且还需要了解日期间隔符使用哪种符号
  √ 有效等价类：日期范围正确，使用 / 作为间隔符；日期范围正确，不使用间隔符
  √ 无效等价类：范围不正确，间隔符不合法（如空格或字母等），日期顺序与设定日期规则不匹配，年月日输入不合法数据（字符，标点等）

3.边界值分析

3.1 一个缺陷

• 缺陷原因，编程时多加了 = 导致错误提示
  

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

• 分析需求，找出边界。

• 写出边界值
  √ 最小值
  √ 小于最小值
  √ 最大值
  √ 大于最大值

3.3 边界值分析案例

• 两位数加法计算器的边界值
  √ -99
  √ -100
  √ 99
  √ 100

3.4 为什么分析边界值‘’

看看下面的代码有错误吗？

• 输入或输出的边界最容易产生错误。
  √ 以上代码中data这个数组的长度为10，但是在for循环遍历时i从0开始，i<=10而数组的下标为数组长度-1，导致数组溢出异常data[i]=i;

3.5 边界值分析练习

使用边界值分析方法写测试点

• 练习题讲解
  √ 测试知识的储备
  ✰ 了解开发原理
  ▲ 可能的编码方式
  ■ if （bl >= ‘A’ && bl <= ‘Z’）
  ■ if （bl >=65 && bl <=90）
  ■ if （bl > 64 && bl < 91）
  ■ if（bl>=‘0’ && bl<=‘9’）
  ■ if（bl>=0 && bl<=9）
  ■ if （bl>= -32768 && bl <= 32767）
  ■ if （bl >= -99 && bl<= 99）

• 部分 ASCII
  
  如在输入框输入数据一定要了解系统的编程语言，如java中char类型或者int类型byte类型都是可以存储0~9的

3.6 边界值分析思考题

• 即时贴程序，考虑标题的测试
  √ 标题字数：1-40 字节
  √ 标题字数：0-40 字节

• 文本输入域允许输入 1-255 个字符

• 下拉列表

• 分页

思考题讲解：

• 即时贴程序标题字数（1-40字节）：0丶1丶40丶41
  即时贴程序标题字数（0-40字节）：0丶40丶41

• 文本输入域：0丶1丶255丶256（说明一点只允许输入1~255个字符，当输入到255个字符无法输入时，即表明256个字符已经测了，没有缺陷）

• 下拉列表：下拉列表选择第一个和最后一个

• 分页（显示1~20页）：第1页和20页
  分页（显示首页丶上一页丶下一页丶末页）：首页丶末页丶点了首页点上一页丶点了末页点下一页

4.决策表

4.1 前面方法忽略的问题

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

4.2 决策表的分析步骤

• 需求分析
  √ 分析输入和输出
  ✰ 用等价类划分分析输入的各种情况、输出的各种情况

• 画判定表

• 分析与简化判定表

4.3 决策表案例

• 分析输入条件和输出条件
  √ 输入
  ✰ 输入 1：
  ▲ 条件 1： 0<=X<=99
  ▲ 条件 2： -99<=X<0
  ▲ 条件 3： X<-99
  ▲ 条件 4： X>99
  ✰ 输入 2：
  ▲ 条件 1： 0<=X<=99
  ▲ 条件 2： -99<=X<0
  ▲ 条件 3： X<-99
  ▲ 条件 4： X>99
  √ 输出
  ✰ 正确计算
  ✰ 错误提示

• 原始决策表/判定表
  

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

• 最终的决策表
  

4.4 决策表练习

案例： 某厂工资发放需求

√ 工资分为年薪制，月薪制，两者互斥

√ 错误程度分为普通和严重，两者可同时具备

√ 年薪制员工犯普通错误扣工资 2％，犯严重错误扣工资 6％

√ 月薪制员工犯普通错误扣工资 4％，犯严重错误扣工资 8％

• 根据案列画出决策表，首先分析输出和输入，输入为工资制和错误类型，然而工资制中两种结果年薪和月薪，错误类型包括不犯错误丶普通丶验证丶两种错误四种结果；输出为扣款比例包括0丶2%丶4%丶6%丶8%以及12%
  

4.5 决策表的适用范围

适用于多种输入的存在组合情况时。

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

导致测试量爆炸。

• 决策表优化策略

5.错误推测

5.1 测试若干原则回顾

• 测试不是验证软件正确，而是攻击软件，发现错误。

• 测试要时刻保持怀疑的态度，具有缺陷预防意识。

• 测试要寻求系统设计、功能设计的弱点。

• 设计负面的、异常的测试，如考虑错误的或者异常的输入，往往可以发现更多的软件缺陷。

5.2 什么是错误推测

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

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

5.3 输入数据方面的错误推测

5.3.1 输入非法数据

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

• 测试方法
  √ 输入非法类型
  √ 输入非法范围/长度
  √ 输入非法格式

• 注意
  √ 错误信息的检查：需要额外考虑错误提示信息的内容
  √ 错误信息和错误要对应一致
  √ 错误信息不能为空
  √ 错误信息的内容不能只是错误代码，不能包含开发信息
  √ 错误信息不能中英文混合

• 案例
  

• 讲解
  √ 咨询开发语言以及数据类型，如java byte类型-128~127，实际生活中肯定有超过127岁的，那么byte类型就不能用了
  √ 如果年龄的范围设定在18-40岁之间，那么非法数据包括无效等价类 <18 >40，非法字符，小数，以及18.0这种格式
  √ 两位以内的整数-99~99，同理也需要咨询开发语言以及数据类型
  √ 文件名长度要求1~255字符，然而在windows系统中有些文件命名是拒绝使用的，如一些windows命令字符等
  √ 日期格式，日期范围以及必须是数字其外都是非法输入

5.3.2 输入默认值

• 适用于有默认值的地方。

• 测试方法
  √ 接受软件的默认值
  √ 键入空值
  √ 将默认值改为另外一个值
  √ 将默认值改为另外一个值，再变为空值

5.3.3 输入特殊字符（集）

• 适用于不能输入有特殊含义的字符时。

• 测试方法
  √ 根据被测软件所处的操作系统、程序设计语言、后台数据库以及具体业务等信息列出表格，进行讨论，标明哪些需要测试，哪些需要剔除。
  √ 了解具体行业知识，具体问题具体分析。

• 案例
  √ 文件命名下列特殊字符（33 个）
  ✰ 不能使用：\ / < > | “ : * ?，com0-com9，lpt0-lpt9，prn、aux、nul、con。

• 思考
  √ 用户名有哪些特殊字符？
  
  √ QQ 昵称、聊天内容有哪些特殊字符？

解答：
①如在windows操作系统中那么admin以及administrator就是特殊字符；linux中可能root则是特殊字符，在数据库里面sa丶root丶system丶master等都可能是特殊字符，包括数据库中–注释丶单引号等都要进行测试，防止sql注入

②在QQ昵称中比如领导人历史人物的名字，以及小数点等特殊字符；聊天内容比如涉及到金钱相关的银行卡，转账，金额等，以及骂人的话包括中英文

5.3.4 输入合法数据的非法组合

• 适用于输入值之间存在依赖关系时。

• 测试方法
  √ 输入可能是出现问题的组合值。

• 案例
  
  单独看都是合法数据，但组合起来就有问题；当选择天津市时，区县可以选择海淀区说明是个bug，也就是非法组合，因为海淀区属于北京市的

5.3.5 通过复制粘贴强制输入程序不允许输入的数据

5.4 输出数据方面的错误推测

5.4.1 同一个输入产生多种输出

• 案例
  √ 输入：一个电话打来
  √ 输出：
  ✰ 状态一：等待接听。
  ✰ 状态二：占线。
  ✰ 状态三：停机。
  ✰ 状态四：无法接通。
  ✰ 状态五：关机。
  ✰ 状态六：空号。

• 测试方法
  √ 详细测试每一种输出，不要有遗漏。
  √ 熟悉被测软件业务知识，阅读各种程序文档，明确输入可能产生的输出，列出关于程序输入于输出的一个列表，然后进行测试。

• 思考
  √ QQ 中有没有类似的测试？
  ✰ QQ视频
  ▲ 接听
  ▲ 拒绝
  ■ 点击拒绝
  ■ 退出QQ
  ■ 关闭计算机/手机
  ▲ 等待超时（无应答）

5.4.2 验证输出结果的正确性

• 测试方法
  √ 不仅测试输入的正确性，还要检查结果的正确性。
  √ 测试人员要尽可能多地学习所涉及问题的领域。

5.5 数据结构方面的错误推测

5.5.1 数据结构溢出

• 适用于程序中存在变量、数组等数据结构时。

• 测试方法
  √ 变量
  ✰ 上溢：值太大
  ✰ 下溢：值太小
  √ 数组
  ✰ 上溢：数据量太多
  ✰ 下溢：数据量太少

• 思考
  ✰ QQ 中有相关案例吗？
  ▲ 添加好友，例如只能添加1000个好友，当添加1000个好友后再进行添加，则是测上溢；删除好友则是测下溢，如果此时删除好友选项不存在或者按钮置灰，不代表我们没有测，而是说明该功能无缺陷

5.5.2 计算结果溢出

• 案例
  
• 测试方法
  √ 输入非法值或很大与很小数据，强制结果产生上溢或下溢。

5.5.3 操作数和操作符不符

• 案例
  ✰ 是否是缺陷？
  
  ✰ 如果是缺陷，开发人员修改成什么样的结果，你作为测试人员会确认这个缺陷已经被修复？

• 适用于需要进行数值计算程序和图形操作程序的测试时，如加、减、乘、除等。

• 测试方法
  ✰ 找到程序中容易引起操作数和操作符不符的计算、表达式等。

计算√2^2-2，实际会想的是√2的平方就是2，然后2-2的0，其实并不是因为√2算出来的值为1.14…，然而1.414…的平方并不是2了，这个是不是缺陷取决于精确到或者咨询经理，根据用户需求来定

5.6 文件系统方面的错误推测

5.6.1 使文件系统超载

• 适用于数据存储到硬盘中时。

• 案例
  √ 假设“软件测试工程师管理系统”要保存 10000 个工程师信息，则保存时 engineer.txt 文件可能会有 20M 大小，如果此时磁盘只有 10M 可用空间了，“软件测试工程师管理系统”会如何动作呢？

• 测试方法
  √ 创建满容量或近乎满容量的文件系统，然后强制执行各种通过输入或输出访问文件系统的操作。
  √ 打开足够多的文件，文件打开时会强制创建备份副本，从而占用双倍的存储空间。
  √ 使用工具 Canned Heat，模拟文件系统超载。

5.6.2 更改文件访问权限

• 适用于对文件进行读写的应用程序。
• 测试方法
  √ 不同的用户对相同文件具有不同的访问权限，需要考虑登录同一台机器的多个用户操作相同文件的权限问题。
  ✰ 打开一个文件，在操作系统中修改该文件的访问权限。有些操作系统允许权限高的用户控制一般用户已经打开的文件。
  √ 两个应用程序打开，关闭同一个文件。
  ✰ 如把同一应用程序的不同版本安装在同一机器上，在不同版本的应用程序中打开和关闭同一文件；
  ✰ 试着在某个应用程序中打开在另一个程序中已打开的文件，这可能会导致文件访问权限上出现冲突。

5.6.3 使介质忙或不可用

• 适用于应用程序的运行需要消耗大量内存或运行时需求其他相关软件同时运行的情况。
  √ 大多数操作系统能同时运行多个应用程序，但相互切换时会有延迟，但是没有对错误响应。

• 测试方法
  √ 通过启动大量应用程序，强制它们都打开并保存文件来使文件系统处于忙的状态；或者同时下载大量文件也可以使后台拥挤。
  √ 使用一些测试工具来模拟磁盘的状况。

5.6.4 介质损坏

• 使用场合
  √ 损坏的介质可能使操作系统传回错误代码，这些错误代码可能没有在应用程序中编程处理。

• 测试方法
  √ 损坏介质的方法使用不很多，只有少数公司采用，大多是开发操作系统、设备驱动程序以及以安全为主的应用程序的公司会采用这种测试方法。确定是否使用该方法，主要要考虑数据对用户的重要性。
  √ 该方法可以使用实际损坏了的介质。检查应用程序对错误的处理能力，应用程序可以对错误进行处理或者将问题告诉用户，并且要确保用户数据文件不丢失、不损坏。
  √ 也可以通过软件模拟。

5.7 错误推测总结

• 输入非法类型

• 输入非法范围（数值）

• 输入非法长度（个数）

• 输入非法格式

• 输入默认值

• 输入特殊字符

• 输入合法数据的非法组合

• 粘贴强制输入

• 一个输入多个输出不要遗漏

• 输出结果（含数据库）要正确

• 上溢、下溢（含结果）

• 操作数与操作符不符

• 文件超载

• 文件权限不足

• 介质忙或不可用

• 介质损坏

6.编写测试点

• 将测试点写入测试需求分析说明书，或者 XMind 等，留存下以供将来编写测试用例使用。
  
• 结合之前学生管理系统项目实战，使用xmind软件对学生管理系统进行功能拆分
  
• 根据连接数据库服务器需求以及功能，整理测试点
  

四、需求评审

1.意义

• 对软件需求进行正确性的检查。

• 保证软件需求的可测试性。

• 通过产品需求文档的评审，与市场、产品、开发等各部门相关人员沟通，使得大家认识一致，避免在后期产生不同的理解，引起争吵。

• 通过产品需求文档的评审，更好地理解产品的功能性和非功能性需求

• 在需求文档评审通过后，测试的目标和范围就确定了。虽然此后会有需求的变更，但可以得到有效的控制，这样可降低测试的风险。

• 评审是否完成是以需求文档获得多方“邮件确认”或“签字”通过为标志的。这不应该只体现在“签字”形式上，更重要的是达到下面的结果。
  √ 所有参与方达成一致。
  √ 已发现的问题被阐述清楚、被修正。

2.需求评审的质量要求

• 正确性
• 完备性
• 易理解性
• 一致性
• 可行性
• 易修改性
• 可测试性
• 可追溯性

3.需求评审的参加人员

• 用户代表
• 需求人员
• 产品经理
• 项目经理
• 开发人员
• 开发经理
• 测试人员
• 测试经理
• 市场经理
• 质量保证人员

4.测试人员参与评审时的注意事项

• 明确自己的角色和责任。

• 熟悉评审内容，为评审做好准备，做细做到位。

• 在评审会上，针对问题阐述观点，而不是针对个人。

• 可以分别讨论主要的问题和次要的问题。

• 在会议前或会议后可以就存在的问题提出自己建设性的意见。

• 提高自己的沟通能力，采取适当的、灵活的表述方式。

• 对发现的问题跟踪下去。

• 应该在需求形成的过程中进行分阶段的多次评审，而不是一次评审。

• 测试人员要善于提问，多思考
  √ 这些需求都是用户提出来的吗？
  √ 有没有画蛇添足的需求？没有漏掉什么需求吗？
  √ 和竞争对手的产品做过比较吗？我们的产品优势体现在哪里？
  √ 是否正确地描述了每个需求？这条描述是否存在二义性的问题？