软件测试第3章 测试分析与设计-2017

思维导图帮助我们迅速展开测试需求；
代码复杂度静态分析工具，代码越复杂，测试优先级越高； 对过去类似产品或本产品上个版本的缺陷分析； 采用用一些普通工具，如检查表 脑力激荡法，让任何测试需求不会被错过。
产品分析与理解：SFDPO 如何设定测试项的优先级

11
从客户的角度来定义的产品特性优先级，用户用得越多或对业务影 响越关键，对应的测试项，其优先级也越高。

性能 (Performance)
兼容性 (Compatibility)



可安装
……
8
产品分析与理解： 例如：分析 HTSM的产品元素 SFDPO

9
结构 (产品是什么？)：
有哪些文件？构造的信息？接口？模块关系？

功能 (产品做什么？): 有哪些功能？处理哪些错误类型？怎样的UI？… 数据 (产品处理什么？): 处理什么输入？输出是什么？处于哪些模式或状态？…


平台 (它依赖什么？):
什么OS？特殊的环境配置吗?是否依赖第三方组件？

操作 (它是怎样使用的？):
谁会用它？什么场景下使用？用它来做什么？
产品分析与理解：SFDPO 测试分析的方法和技术

10
通过UML或SysML进行需求建模来明确测试需求； 通过状态图、活动图列出的测试场景、状态转换的路径和条件； 对竞争产品进行对比分析，明确测试的重点； 了解产品质量属性，从产品质量需求出发来分析测试需求；
要求测试人员相互审 查、提问；
集体审查测试用例
测试设计框架
建立合适的、可扩展的测试用例框 架，从而借助这个框架能有效地组 织众多的测试用例，包括对测试用 例的分类、清晰的层次结构等
针对不同的测试对象设计 按系统架构、层次来设计 根据业务数据类型或数据 流图来设计 按业务流程或其它建模方 式（如UML建模）来设计； 按质量属性来设计，如功 能模块、非功测试
测试用例的元素
第3章内容
3.1 如何进行测试需求分析
3.2
3.3
测试设计
7
启发式测试策略
Heuristic Test Strategy Model：HTSM
http://www.satisfice.com/rst-appendices.pdf
ຫໍສະໝຸດ Baidu
侧重分析HTSM的三个方面
项目背景

用户（Customers） 开发者关系（Developer Relations） 测试团队（Test Team） 设备与工具 （Equipment & Tools） 进度（Schedule） 测试项（Test Items） 交付品（Deliverables）
3.1 如何进行测试需求分析
3.2 测试设计
3.3 什么是测试用例
3.4
3.5
为什么需要测试用例
测试用例的质量
3.6
测试用例的组织和使用
3.2 软件测试设计
3.2.1 3.2.2 3.2.3
测试设计流程 框架的设计 功能测试设计
问题
可以设计多少个测试用例？
测试设计流程
采用测试用例的模板、 参考已有的范例； 要求先设计工作流程 图、数据流图；
软件测试 第2版
第3章 测试分析与设计
测试分析与设计
解决两个基本问题“测什么”、“如何测”
第3章内容
3.1 如何进行测试需求分析
3.2
3.3
测试设计
什么是测试用例
3.4
3.5
为什么需要测试用例
测试用例的质量
3.6
测试用例的组织和使用
测试需求分析基本内容
明确测试范围，了解哪些功能点要测试、哪些功能点不需要测试； 根据测试目标和测试范围，确定测试项或测试任务； 根据用户需求和质量风险，确定测试项（或测试任务）的优先级
什么是测试用例
测试用例（test case）是可以被独立执行的一个过程，是一个最小的测
试实体，不能再被分解。测试用例也就是为了某个测试点而设计的测试
操作过程序列、条件、期望结果及其相关数据的一个特定的集合
测试用例示
测试用例要描述什么？ 5W1H
Why ——为什么而测？ What ——测什么？ Where ——在哪里测？ When ——什么时候开始测？ Which ——哪些输入数据？ How ——如何操作软件？
功能测试设计
以客户需求导向的设计思 路 尽量避免含糊的、冗长的 或复杂的测试用例 尽量将具有相类似功能的 测试用例抽象并归类
第3章内容
3.1 如何进行测试需求分析
3.2
测试设计
3.3 什么是测试用例
3.4
3.5
为什么需要测试用例
测试用例的质量
3.6
测试用例的组织和使用
测试需求分析的出发点
从客户角度进行分析：通过业务流程、业务数据、业务操作等分析， 明确要验证的功能、数据、场景等内容，从而确定业务方面的测试 需求。
从技术角度分析：通过研究系统架构设计、数据库设计、代码实现
等，分析其技术特点，了解设计和实现要求，包括系统稳定可靠、 分层处理、接口集成、数据结构、性能等方面的测试需求
业务逻辑／代码复杂度越高、容易出错的测试项，即产品质量风险 越大、更有可能发现缺陷的测试项，其优先级也相对高。 从开发修正缺陷难易程度看，逻辑方面的测试对象相对界面方面的 测试对象，出现问题更难解决，影响面也广，改了这问题可能出现 其它问题，这也说明业务逻辑区域的质量风险偏高，其优先级高。


第3章内容
测试需求分析的出发点
从客户角度进行分析：通过业务流程、业务数据、业务操作等分析， 明确要验证的功能、数据、场景等内容，从而确定业务方面的测试 需求。
从技术角度分析：通过研究系统架构设计、数据库设计、代码实现
等，分析其技术特点，了解设计和实现要求，包括系统稳定可靠、 分层处理、接口集成、数据结构、性能等方面的测试需求
产品元素


质量属性

结构（Structure）
功能（Functions） 数据（Data） 平台（Platform） 操作（Operations） 时间（Time）
能力 (Functionality) 可靠性 (Reliability) 可用性 (Availability) 安全 (Security)