软件测试需求分析
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
– 易用性需求：功能的细节，产品中必须提供了， 便于功能操作使用的一些细节，比如快捷键就 是典型的易用性需求。
– 编辑约束：功能的细节，在功能执行时，对输 入数据项目的一些约束性条件，比如只能输入 数字。
– 参数需求：功能的细节，在功能中，需要根据 参数设置不同，进行不同处理的细节。
– 权限需求：功能的细节，这里的权限是指在功 能的执行过程，根据根据不同的权限进行不同 处理的，不包括直接限制某个功能的权限
• 仅从需求分析的角度来讲，需求规格描述 得较细的话确实会增大很多工作量，但从 整个开发过程来看，需求描述完整的话， 后续阶段的开发产生歧义和遗漏的可能性 就很小，实际上后续阶段节约的时间会大 大超过需求所多花的时间。
举例WEB应用测试需求分析
• 界面要素分析
– 页面链接：是否遗漏加链接，链接是否正确； – 页面表单：例如用户填写的出生日期与职业是
• 4、软件需求获取的来源信息作为信息来源。
• 5、提取的原始测试需求中，可能存在重复 和冗余，在提取原始测试需求过程中，可 以通过以下方法整理原始测试需求：
– 删除：删除原始测试需求表中重复的、冗余的 含有包含关系的原始测试需求描述；
– 细化：对太简略的原始测试需求描述进行细化；
– 合并：如果有类似的原测试始需求，在整理时 需要对其进行合并。
测试需求及需求分析
伊薇亦 2013年12月28号
工作中的场景？
问题漏测；测 试设计不充分 >60%！
需要做测试 需求分析！
很多公司现状
没有测试
需求分析 过程
测试输入
测试经理口头分配 测试方案任务不明 确
测试过程与结果缺 乏质量评估与控制
测试对象分析侧
重测试方案内部 实现
测试对象分析 测试用例设计（方案内的）
– 功能性需求:系统功能、业务流程、界面、系统 安装等
需求分析通常步骤
• 1、通过列表的形式对软件开发需求进行梳 理，形成原始测试需求列表，列表的内容 包括需求标识、原始测试需求描述、信息 来源。
• 2、将每一条软件需求对应的开发文档及章 节号作为软件需求标识。
• 3、使用软件需求的简述作为原始测试需求 描述。
方法参考
1、强调测试需求分析 分析过程和结果分开，产生测试需求需要问 自己，“这些功能假设要做什么？如果做了 这些，我如何才能知道”，和开发进行交流 的思路来源于以下事实：有些规格并没有写 在SRS中，而是停留在开发人员的脑中，特别 是用户使用的方式等等。 2、电子表格是支撑测试分析设计的主要工具 测试设计的工具选择并非一定要有专门的工 具支撑，只要能将测试设计活动通过工具串
• 文件命名：从文件名属性来看，如何命名 日志文件，需求中也没有提及。
• 文件位置：从存放位置属性来看，日志文 件存放在什么地方也没有说明。是不是所 有的日志文件都存放在应用程序同一子目
举例说明如何进行测试需求分析 （续5）
• 需求描述中有很多的问题没有描述清楚。 也许有人会有疑问，如果将所有上面说到 的问题都描述出来的话会不会工作量太大 了？
软件需求分析
• 可行性和紧迫程度，近期需求和远期需求， 分析的主要工作包括：
– 通过启发、诱导、深层次的沟通与交流，获取 用户潜在需求
– 分析行业的规则、规范，分析用户需求的合理 性
– 编写分析报告并获得用户认可 – 将用户需求做阶段性的截止，否则系统设计将
无所适从，并增加系统设计的风险和隐患。 – 如果需求变更，则需要进行变更控制
– 考虑本项目与外部系统的交互，划分系统边界 （除了本项目的需求中要求做的事情，其他的 都可以是外部系统，本系统和外部系统之间的 交互就是系统的边界），可以参考系统分析说 明书。
• 3、业务场景法：
– 考虑用例的调用者；考虑每一个用例提供的服 务是供哪些外部用例或者系统调用，找出所有 的调用者。调用的前提、约束都要考虑。每一 个调用都可以考虑成一个大的业务流程。（一 般和外部有交互的用例出错的概率比较大，需 要重点关注）
如何分析测试需求
测试需求分析考虑的因素
• 测试阶段 • 待测软件的特性 • 测试焦点 • 测试需求优先级 • 测试需求的覆盖率与覆盖程度
一、测试阶段
• 系统测试阶段 侧重于技术层面，软件是否实现了功能。 同一流程或角色执行功能正确，具有相同 特征的业务或角色都能执行正确。
• 验收测试阶段 侧重于业务层面，更注重于不同角色在同 一功能上执行是否正确
• 好像可以根据这个需求描述进行开发，但 仔细来分析一下这段需求的话，就会发现 并不是想象的那样乐观。先找出需求中涉 及的三个显性元素：
• 1、访问者 2、访问记录 3、日志文件
举例说明如何进行测试需求分析 （续2）
• 首先对访问者和访问记录这两个元素进行 分析，先看访问者有那些属性，除了描述 中提及的访问时间和IP地址外，访问者还有 那些属性呢？
测试需求提供一个测试应用程序所必须的详 细的描述。
•软件测试需求是开发测试用例的依据 •确定测试完整性的一个基础 •确定测试工作的范围 •识别可做自动化测试的策略 •作为测试的方向标 •有助于保证测试的质量与进度
测试需求的特征
一条有用的测试需求总是： • 唯一的 • 精确的 • 有边界的 • 可测试的
常用的或规定的业务流程 各业务流程分支的遍历 明确规定不可使用的业务流程 没有明确规定但是应该不可以执行的业务流程
• 其它异常或不符合规定的操作
四、测试需求的优先级
• 把握重点、有的放矢 • 缓和测试风险 • 用户需求\软件需求 • 有优先级：则决定测试需求优先级 • 无优先级：则通过沟通，确定测试需求优
先级
五、测试需求的覆盖率与覆盖程 度
• 测试需求与软件需求的对应关系 • 覆盖率=测试需求覆盖点数/软件需求功能点
数*100%
测试需求分析的步骤
• 1 、 熟悉需求背景及商业目标：
– 了解清楚项目发起的原因，是为了解决用户的 什么问题。
– 当前的解决方案是不是最优的，为什么会这样 做？
• 2 、业务模型法：
需求的定义
• 需求是用户为解决一个或达到一个目标所 需要的一种能力条件。
• 或需求是一个系统或系统组成部分为满足 一个合同、标准、规则说明或其它正式规 定的文件必须达到或具备的能力条件。
什么是测试需求
1. 测试需求主要解决“测什么”的问题，即 指明被测对象中什么需要测试
2. 测试需求通常是以软件开发需求为基础进 行分析，通过对开发需求的细化和分解， 形成可测试的内容
3. 测试需求应全部覆盖已定义的业务流程， 以及功能和非功能方面的需求
业务需求与测试需求的关系
• 业务需求通常是指系统需要做什么 • 测试需求除了需要覆盖系统应该做什么外，
还要覆盖系统不应该做什么。 • 测试需求是用来发现需求中存在的问题
为什么做测试需求分析？
清晰把握 测试需求！
时刻关注 产品质量！
– 基于数据流的处理：商品库存数量，不同客户 端订购并支付成功减少，退货成功后增加，在 相关子系统的数据一致性
举例WEB应用测试需求分析方法 （续）
• 功能交互分析
– 交互的入口要鲜明； – 交互的步骤要简洁； – 交互的结果要正确；
– 如答疑系统，当某问题再次被学员追问，追问 的问题必须有列表显示，助教可清晰区分追问 的问题和非追问的问题，助教回答问题后，用 户可收到消息提醒；
测试需求分析方法（1）
业务流程分析：业务流逐渐细化为子业务流 •常用的或规定的业务流程 ：
提交 答案
异常判 断
否
确认是 是 提交成
否提交
功
•各业务流程分支的遍历
•明确规定不可使用的业务流程
•没有明确规定但是应该不可以执行的业务流 程
测试需求分析方法（2）
用户场景分析 •通常指事件触发的场景。 •如微信的测试，当前账号已经登录微信了， 再用该账号在其他地方登录微信； •如答疑系统中，助教A正要领取某问题的时 候，助教B抢先领取了该问题；
– 考虑系统内部各个用例之间的交互，形成内部 业务流程图。需要分析每个用例之间的约束关 系、执行条件，组织出各种业务流程图。
• 4、业务功能：与用户实际业务直接相关的 功能或细节。
– 辅助功能：辅助完成业务功能的一些功能或者 是细节，比如，设置过滤条件。
– 数据约束：功能的细节，主要是用于控制在执 行功能时，数据的显示范围、数据之间的关系 等。
• 有经验的开发者就知道日志记录格式是一 个很重要的问题，因为日志记录的分析一 般是需要使用专门的分析软件或者写专门 的分析程序来分析的。如何设计合理的记 录格式来利用已有的日志分析软件来进行 分析是首要考虑的问题。
• 一般要对日志文件属性进行分析，应该具
举例说明如何进行测试需求分析 （续4）
• 时间点：需求描述中提到了每天要生成一 个日志文件，从文件创建时间属性来看， 每天有24小时，到底从什么时候开始创建 文件，从0点开始还是从几点开始，没有描 述出来。
测试需求分析方法（3）
• 不同角色的权限分析 • 技术实现原理上分析 • 系统边界分析 • 非功能性的特征分析
兼容性 系统响应 性能特性 …
测试需求分析步骤
• 对测试依据进行分析，列出的每一条开发 需求对应的测试需求；
• 对上面步骤形成的每一条测试需求点，软 件内部/外部质量模型来确定软件产品的质 量需求；
举例：说明如何进行测试需求分 析
先看一段关于日志文件的需求描述如下：
•“软件要将所有的访问者都要记录下来，对 每次访问要记录访问开始时间、访问结束时 间、访问者的IP地址这三个信息作为一条日志 记录。要求以天为单位每天生成一个访问记 录日志文件。”
举例说明如何进行测试需求分析 （续1）
• 在这段需求描述中，我们首先要想象自己 是日志模块的开发者，根据这段需求描述， 是否能够开发出日志模块来呢？日志文件 要记录的信息内容上面都提到，包括：访 问开始时间、结束时间、IP地址。
过多关注功能 实现、产品质 量维度关注不 全面
测试用例
没有统一成 熟的分析设 计工程方法 支撑
测试过程中遇到的问题汇总
• 测试需求不wenku.baidu.com分，没有明确的测试需求分 析过程
• 产品质量维度关注不全面，测试类型不完 整
• 没有测试规格，测试分解分配比较随意 • 责任主体不明确 • 没有系统的工程方法或指导 • 没有相应的质量评估原则
二、待测软件的特性
• 不同业务背景和应用
– 安全性软件—安全（人身、重大财产） – 电子商务网站—压力 – ERP—流程 – 驱动程序—兼容性 – 政府门户—法律、法规
三、测试焦点
• 根据所测的功能点划分的层次 例如：界面、业务流、模块化、数据、输 入域等
• 基于业务流的测试需求分析方法
测试需求分析时需要列出以下类别：
其它可能： • 必要的前置条件
测试需求分析内容
• 测试需求的内容：测试范围、测试目标
– 测试范围：就是测试项目中，我们需要进行开 发生命周期的各个阶段的测试，还是部分测试 – 测试目标：系统的那些特性需要测试
• 测试需求的要点：
– 解决系统要测什么而不是描述如何测
• 测试需求包含：功能性需求和非功能性需 求
• 显然访问者的访问内容是最重要的属性， 仅记录访问时间和访问者的IP地址是否足够 呢，从日志能分析出什么有用的信息呢？ 从时间信息上最多只能看出那段时间访问 的人数较多，得到用户的时间分布规律， 但很难对用户的行为有深入的分析，只有
举例说明如何进行测试需求分析 （续3）
• 从访问记录这个元素来分析，访问记录主 要属性是记录格式，每条记录是以什么格 式来记录呢？没有描述出来。
• 测试需求分析目的是：明确应 该测试什么。即明确测试需求， 其核心是产品质量。
• 产品质量就是符合用户的明确 的或隐含的需求的程度。
– 需求文档中的产品需求、系统设 计需求是明确的需求
– 未在需求文档中明确的隐含的用 户需求也是我们需要分析的，如 用户使用产品方式、感受等。
测试需求分析的作用和重要性
否恰当，填写的所属省份与所在城市是否匹配 等。如果使用了默认值，还要检验默认值的正 确性；
– 页面控件：如下拉值，下拉选中后，再次点击， 选中焦点是否还在原来的下拉选项；如多选， 单选是否正确；
举例WEB应用测试需求分析方法 （续）
• 页面功能点分析
– 单个功能点的处理：正常操作、异常操作；
– 关联功能处理：A删除QQ中的好友B，在好友列 表中就会去掉B的显示；在B的好友列表中，也 会去掉A的显示；这点也通常称为关联测试点；
– 编辑约束：功能的细节，在功能执行时，对输 入数据项目的一些约束性条件，比如只能输入 数字。
– 参数需求：功能的细节，在功能中，需要根据 参数设置不同，进行不同处理的细节。
– 权限需求：功能的细节，这里的权限是指在功 能的执行过程，根据根据不同的权限进行不同 处理的，不包括直接限制某个功能的权限
• 仅从需求分析的角度来讲，需求规格描述 得较细的话确实会增大很多工作量，但从 整个开发过程来看，需求描述完整的话， 后续阶段的开发产生歧义和遗漏的可能性 就很小，实际上后续阶段节约的时间会大 大超过需求所多花的时间。
举例WEB应用测试需求分析
• 界面要素分析
– 页面链接：是否遗漏加链接，链接是否正确； – 页面表单：例如用户填写的出生日期与职业是
• 4、软件需求获取的来源信息作为信息来源。
• 5、提取的原始测试需求中，可能存在重复 和冗余，在提取原始测试需求过程中，可 以通过以下方法整理原始测试需求：
– 删除：删除原始测试需求表中重复的、冗余的 含有包含关系的原始测试需求描述；
– 细化：对太简略的原始测试需求描述进行细化；
– 合并：如果有类似的原测试始需求，在整理时 需要对其进行合并。
测试需求及需求分析
伊薇亦 2013年12月28号
工作中的场景？
问题漏测；测 试设计不充分 >60%！
需要做测试 需求分析！
很多公司现状
没有测试
需求分析 过程
测试输入
测试经理口头分配 测试方案任务不明 确
测试过程与结果缺 乏质量评估与控制
测试对象分析侧
重测试方案内部 实现
测试对象分析 测试用例设计（方案内的）
– 功能性需求:系统功能、业务流程、界面、系统 安装等
需求分析通常步骤
• 1、通过列表的形式对软件开发需求进行梳 理，形成原始测试需求列表，列表的内容 包括需求标识、原始测试需求描述、信息 来源。
• 2、将每一条软件需求对应的开发文档及章 节号作为软件需求标识。
• 3、使用软件需求的简述作为原始测试需求 描述。
方法参考
1、强调测试需求分析 分析过程和结果分开，产生测试需求需要问 自己，“这些功能假设要做什么？如果做了 这些，我如何才能知道”，和开发进行交流 的思路来源于以下事实：有些规格并没有写 在SRS中，而是停留在开发人员的脑中，特别 是用户使用的方式等等。 2、电子表格是支撑测试分析设计的主要工具 测试设计的工具选择并非一定要有专门的工 具支撑，只要能将测试设计活动通过工具串
• 文件命名：从文件名属性来看，如何命名 日志文件，需求中也没有提及。
• 文件位置：从存放位置属性来看，日志文 件存放在什么地方也没有说明。是不是所 有的日志文件都存放在应用程序同一子目
举例说明如何进行测试需求分析 （续5）
• 需求描述中有很多的问题没有描述清楚。 也许有人会有疑问，如果将所有上面说到 的问题都描述出来的话会不会工作量太大 了？
软件需求分析
• 可行性和紧迫程度，近期需求和远期需求， 分析的主要工作包括：
– 通过启发、诱导、深层次的沟通与交流，获取 用户潜在需求
– 分析行业的规则、规范，分析用户需求的合理 性
– 编写分析报告并获得用户认可 – 将用户需求做阶段性的截止，否则系统设计将
无所适从，并增加系统设计的风险和隐患。 – 如果需求变更，则需要进行变更控制
– 考虑本项目与外部系统的交互，划分系统边界 （除了本项目的需求中要求做的事情，其他的 都可以是外部系统，本系统和外部系统之间的 交互就是系统的边界），可以参考系统分析说 明书。
• 3、业务场景法：
– 考虑用例的调用者；考虑每一个用例提供的服 务是供哪些外部用例或者系统调用，找出所有 的调用者。调用的前提、约束都要考虑。每一 个调用都可以考虑成一个大的业务流程。（一 般和外部有交互的用例出错的概率比较大，需 要重点关注）
如何分析测试需求
测试需求分析考虑的因素
• 测试阶段 • 待测软件的特性 • 测试焦点 • 测试需求优先级 • 测试需求的覆盖率与覆盖程度
一、测试阶段
• 系统测试阶段 侧重于技术层面，软件是否实现了功能。 同一流程或角色执行功能正确，具有相同 特征的业务或角色都能执行正确。
• 验收测试阶段 侧重于业务层面，更注重于不同角色在同 一功能上执行是否正确
• 好像可以根据这个需求描述进行开发，但 仔细来分析一下这段需求的话，就会发现 并不是想象的那样乐观。先找出需求中涉 及的三个显性元素：
• 1、访问者 2、访问记录 3、日志文件
举例说明如何进行测试需求分析 （续2）
• 首先对访问者和访问记录这两个元素进行 分析，先看访问者有那些属性，除了描述 中提及的访问时间和IP地址外，访问者还有 那些属性呢？
测试需求提供一个测试应用程序所必须的详 细的描述。
•软件测试需求是开发测试用例的依据 •确定测试完整性的一个基础 •确定测试工作的范围 •识别可做自动化测试的策略 •作为测试的方向标 •有助于保证测试的质量与进度
测试需求的特征
一条有用的测试需求总是： • 唯一的 • 精确的 • 有边界的 • 可测试的
常用的或规定的业务流程 各业务流程分支的遍历 明确规定不可使用的业务流程 没有明确规定但是应该不可以执行的业务流程
• 其它异常或不符合规定的操作
四、测试需求的优先级
• 把握重点、有的放矢 • 缓和测试风险 • 用户需求\软件需求 • 有优先级：则决定测试需求优先级 • 无优先级：则通过沟通，确定测试需求优
先级
五、测试需求的覆盖率与覆盖程 度
• 测试需求与软件需求的对应关系 • 覆盖率=测试需求覆盖点数/软件需求功能点
数*100%
测试需求分析的步骤
• 1 、 熟悉需求背景及商业目标：
– 了解清楚项目发起的原因，是为了解决用户的 什么问题。
– 当前的解决方案是不是最优的，为什么会这样 做？
• 2 、业务模型法：
需求的定义
• 需求是用户为解决一个或达到一个目标所 需要的一种能力条件。
• 或需求是一个系统或系统组成部分为满足 一个合同、标准、规则说明或其它正式规 定的文件必须达到或具备的能力条件。
什么是测试需求
1. 测试需求主要解决“测什么”的问题，即 指明被测对象中什么需要测试
2. 测试需求通常是以软件开发需求为基础进 行分析，通过对开发需求的细化和分解， 形成可测试的内容
3. 测试需求应全部覆盖已定义的业务流程， 以及功能和非功能方面的需求
业务需求与测试需求的关系
• 业务需求通常是指系统需要做什么 • 测试需求除了需要覆盖系统应该做什么外，
还要覆盖系统不应该做什么。 • 测试需求是用来发现需求中存在的问题
为什么做测试需求分析？
清晰把握 测试需求！
时刻关注 产品质量！
– 基于数据流的处理：商品库存数量，不同客户 端订购并支付成功减少，退货成功后增加，在 相关子系统的数据一致性
举例WEB应用测试需求分析方法 （续）
• 功能交互分析
– 交互的入口要鲜明； – 交互的步骤要简洁； – 交互的结果要正确；
– 如答疑系统，当某问题再次被学员追问，追问 的问题必须有列表显示，助教可清晰区分追问 的问题和非追问的问题，助教回答问题后，用 户可收到消息提醒；
测试需求分析方法（1）
业务流程分析：业务流逐渐细化为子业务流 •常用的或规定的业务流程 ：
提交 答案
异常判 断
否
确认是 是 提交成
否提交
功
•各业务流程分支的遍历
•明确规定不可使用的业务流程
•没有明确规定但是应该不可以执行的业务流 程
测试需求分析方法（2）
用户场景分析 •通常指事件触发的场景。 •如微信的测试，当前账号已经登录微信了， 再用该账号在其他地方登录微信； •如答疑系统中，助教A正要领取某问题的时 候，助教B抢先领取了该问题；
– 考虑系统内部各个用例之间的交互，形成内部 业务流程图。需要分析每个用例之间的约束关 系、执行条件，组织出各种业务流程图。
• 4、业务功能：与用户实际业务直接相关的 功能或细节。
– 辅助功能：辅助完成业务功能的一些功能或者 是细节，比如，设置过滤条件。
– 数据约束：功能的细节，主要是用于控制在执 行功能时，数据的显示范围、数据之间的关系 等。
• 有经验的开发者就知道日志记录格式是一 个很重要的问题，因为日志记录的分析一 般是需要使用专门的分析软件或者写专门 的分析程序来分析的。如何设计合理的记 录格式来利用已有的日志分析软件来进行 分析是首要考虑的问题。
• 一般要对日志文件属性进行分析，应该具
举例说明如何进行测试需求分析 （续4）
• 时间点：需求描述中提到了每天要生成一 个日志文件，从文件创建时间属性来看， 每天有24小时，到底从什么时候开始创建 文件，从0点开始还是从几点开始，没有描 述出来。
测试需求分析方法（3）
• 不同角色的权限分析 • 技术实现原理上分析 • 系统边界分析 • 非功能性的特征分析
兼容性 系统响应 性能特性 …
测试需求分析步骤
• 对测试依据进行分析，列出的每一条开发 需求对应的测试需求；
• 对上面步骤形成的每一条测试需求点，软 件内部/外部质量模型来确定软件产品的质 量需求；
举例：说明如何进行测试需求分 析
先看一段关于日志文件的需求描述如下：
•“软件要将所有的访问者都要记录下来，对 每次访问要记录访问开始时间、访问结束时 间、访问者的IP地址这三个信息作为一条日志 记录。要求以天为单位每天生成一个访问记 录日志文件。”
举例说明如何进行测试需求分析 （续1）
• 在这段需求描述中，我们首先要想象自己 是日志模块的开发者，根据这段需求描述， 是否能够开发出日志模块来呢？日志文件 要记录的信息内容上面都提到，包括：访 问开始时间、结束时间、IP地址。
过多关注功能 实现、产品质 量维度关注不 全面
测试用例
没有统一成 熟的分析设 计工程方法 支撑
测试过程中遇到的问题汇总
• 测试需求不wenku.baidu.com分，没有明确的测试需求分 析过程
• 产品质量维度关注不全面，测试类型不完 整
• 没有测试规格，测试分解分配比较随意 • 责任主体不明确 • 没有系统的工程方法或指导 • 没有相应的质量评估原则
二、待测软件的特性
• 不同业务背景和应用
– 安全性软件—安全（人身、重大财产） – 电子商务网站—压力 – ERP—流程 – 驱动程序—兼容性 – 政府门户—法律、法规
三、测试焦点
• 根据所测的功能点划分的层次 例如：界面、业务流、模块化、数据、输 入域等
• 基于业务流的测试需求分析方法
测试需求分析时需要列出以下类别：
其它可能： • 必要的前置条件
测试需求分析内容
• 测试需求的内容：测试范围、测试目标
– 测试范围：就是测试项目中，我们需要进行开 发生命周期的各个阶段的测试，还是部分测试 – 测试目标：系统的那些特性需要测试
• 测试需求的要点：
– 解决系统要测什么而不是描述如何测
• 测试需求包含：功能性需求和非功能性需 求
• 显然访问者的访问内容是最重要的属性， 仅记录访问时间和访问者的IP地址是否足够 呢，从日志能分析出什么有用的信息呢？ 从时间信息上最多只能看出那段时间访问 的人数较多，得到用户的时间分布规律， 但很难对用户的行为有深入的分析，只有
举例说明如何进行测试需求分析 （续3）
• 从访问记录这个元素来分析，访问记录主 要属性是记录格式，每条记录是以什么格 式来记录呢？没有描述出来。
• 测试需求分析目的是：明确应 该测试什么。即明确测试需求， 其核心是产品质量。
• 产品质量就是符合用户的明确 的或隐含的需求的程度。
– 需求文档中的产品需求、系统设 计需求是明确的需求
– 未在需求文档中明确的隐含的用 户需求也是我们需要分析的，如 用户使用产品方式、感受等。
测试需求分析的作用和重要性
否恰当，填写的所属省份与所在城市是否匹配 等。如果使用了默认值，还要检验默认值的正 确性；
– 页面控件：如下拉值，下拉选中后，再次点击， 选中焦点是否还在原来的下拉选项；如多选， 单选是否正确；
举例WEB应用测试需求分析方法 （续）
• 页面功能点分析
– 单个功能点的处理：正常操作、异常操作；
– 关联功能处理：A删除QQ中的好友B，在好友列 表中就会去掉B的显示；在B的好友列表中，也 会去掉A的显示；这点也通常称为关联测试点；