测试计划
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
11
什么是好的需求文档？
具有清晰的格式和文档结构 需求的内容正确 需求的内容完整 需求具有可行性 必要性 对不同的需求的优先等级进行定义 描述明确，无歧义、二义，上下文一致 可证实和可测试性 可修改性 可追踪 需求文档被及时更新
12
如何进行需求测试？
从以下几个方面来评价需求文档：
需求文档是否符合公司的格式要求？ 需求是否正确？ 要保证需求文档中所描述的内容是真实可靠的 这是“真正的”需求吗？描述的产品是否就是要开 发的产品？ 需求是否完备？列出的需求是否能减去 一部分？ 需求是否兼容？需求有可能是矛盾的。 需求是否可实现？ 需求是否合理？ 需求是否可测？
14
定义测试需求
用 户 需 求
定义
根据用户需求定义并完善测试 需求，以作为整个测试的标准
15
2.3 测试策略
测试策略考虑的问题：
测试范围 测试方法 测试标准 测试工具
16
2.3.1 确定测试范围
测试过度，则在测试覆盖中存在大量冗余； 测试范围过小，则存在遗漏错误的风险。 定义测试范围是一个在测试时间、费用和质 量风险之间寻找平衡的过程。 通过分析产品的需求文档识别哪些需要被测 试。 测试范围不能仅仅由测试人员来确定。
24
选择自动化测试工具需要注意以下几方面：
13
需求测试的方法：
复查 (Review) 复查一般是让工作中合作者检查产品并提出意 见。同级互查可以面对面进行，也可以通过E-Mail 实现，并没有统一标准。发现文档缺陷同级互查的 能力是三种方法中最弱的。 走查 (Walkthrough) 相比较审查走查较为宽松，其事先需要收集数 据，也没有输出报告的要求。 审查 (Inspection) 审查是为发现缺陷而进行的。关键组件的审查 通过会议进行，会前每个与会者需要进行准备，会 议必须按规定的程序进行，缺陷被记录并形成会议 报告。审查被证明是非常有效的发现缺陷的方法。
6
测试计划：考虑测试内容
系统功能 用户界面 系统性能 负载测试 强化测试 容量测试 配置测试 安装测试
7
2.2 测试软件需求
需求分析过程
收集用户需求 编写需求定义文档 编写软件功能说明 编写软件需求跟踪矩阵 审核软件需求文档
8
需求分析中测试人员工作
理解需求，参与审核需求文档 理解项目的目标、限制，了解用户应用背景 编写测试计划 准备资源
17
定义测试范围需要考虑下列一些因素：
首先测试最高优先级的需求。 测试新的功能和代码或者改进的旧功能。 使用等价类划分来减小测试范围 重点测试经常出问题的地方
18
确定测试范围方法
可采用提问单的方式来确定测试范围
哪些功能是软件的特色？ 哪些功能是用户最常用的？ 如果系统可以分块卖的话，哪些功能块在销售时最 昂贵？ 哪些功能出错将导致用户不满或索赔？ 哪些程序是最复杂、最容易出错的？ 哪些程序是相对独立，应当提前测试的？ 哪些程序最容易扩散错误？ 哪些程序是全系统的性能瓶颈所在？ 哪些程序是开发者最没有信心的？
第二章 测试计划
2.1 2.2 2.3 2.4 2.5 2.6 测试计划要点和制订过程 测试软件需求 测试策略 测试环境 测试管理 测试计划编写
1
2.1 测试计划要点和制订过程
软件测试生命周期
开发生命周期 需求分析 设计定义 程序编制
建立 建立 建立
维护
修改
测试生命周期
测试计划 测试设计
定制个案 缺陷跟踪
20
2.3.3 定义测试标准
定义测试标准的目的是设置测试中遵循的 规则。 需要制订以下几种标准：
测试入口标准 测试出口标准 测试暂停与继续标准
21
制订测试标准常用规则（一）
基于测试用例的规则 当测试用例的不通过率达到某一百分比时，则 拒绝继续测试。 优点是适用于所有的测试阶段 缺点是太依赖于测试用例。 基于“测试期缺陷密度”的规则 “测试期缺陷密度”：测试一个CPU小时发现 的缺陷数。 如果在相邻n个CPU小时内“测试期缺陷密度” 全部低于某个值m时，则允许正常结束测试。
测试执行 评估
2
软件测试阶段组成
测试计划
测试设计
测试开发
测试评估
测试执行
3
测试计划的目标
收集并组织测试计划信息 将软件细化为可检验的测试需求 建立测试计划
4
测试计划制订过程
分析和测试软件需求
定义测试策略
定义测试环境
定义测试管理
编写和审核测试计划
5
测试计划要点
测试活动进度综述，可供项目经理产生项目进度时参考； 测试方法，包括测试工具的使用； 测试工具，包括如何和何时获取工具； 实施测试和报告结果的过程； 系统测试进入和结束准则； 设计、开发和执行测试所需的人员； 设备资源：需要什么样的机器和测试基准； 恰当的测试覆盖率目标； 测试所需的特殊软件和硬件配置； 测试应用程序策略； 测试哪些特性，不测试哪些特性； 风险和意外情况计划。
19
2.3.2 选择测试方法
在不同的开发阶段，需要选择不同的测试方法。 在瀑布生命期模型中不同的阶段可以选择的不同的 测试方法：
需求分析阶段：静态测试 概要设计与详细设计阶段：静态测试 编码和单元测试阶段：静态测试和动态测试、白盒测试 集成测试阶段：动态测试、白盒测试、黑盒测试 系统测试阶段：动态测试、黑盒测试 验收测试阶段：动态测试、黑盒测试
9
软件需求文档
需求文档是进行设计、编码、测试的基础 文件，软件需求文档中，需要描述下列内容： 说明 一般描述 各种限制条件、假定和以来 功能需求 非功能需求 参考
10
需求跟踪矩阵
对于需求文档中的每项需求，要确保以下 问题： 是否完成了相应的设计？ 是否编写完成了相应的代码？在哪里可以找 到这些代码？ 是否编写完成了相应的单元测试用例？是否 进行了单元测试？ 是否完成了相应的集成测试用例？是否进行 了集成测试？ 需求跟踪矩阵即描述上述问题。
22
制订测试标准常用规则（二）
基于“运行期缺陷密度”的规则 “运行期缺陷密度”：软件运行一个CPU小时 wenku.baidu.com现的缺陷数 如果在相邻n个CPU小时内“运行期缺陷密度” 全部低于某个值m时，则允许正常结束测试。
23
2.3.4 选择自动化测试工具
使用测试工具可以带来下面一些主要的好 处：
能够很好地进行性能测试和压力测试 能够缩短测试周期 能够提高测试工作的可重复性
什么是好的需求文档？
具有清晰的格式和文档结构 需求的内容正确 需求的内容完整 需求具有可行性 必要性 对不同的需求的优先等级进行定义 描述明确，无歧义、二义，上下文一致 可证实和可测试性 可修改性 可追踪 需求文档被及时更新
12
如何进行需求测试？
从以下几个方面来评价需求文档：
需求文档是否符合公司的格式要求？ 需求是否正确？ 要保证需求文档中所描述的内容是真实可靠的 这是“真正的”需求吗？描述的产品是否就是要开 发的产品？ 需求是否完备？列出的需求是否能减去 一部分？ 需求是否兼容？需求有可能是矛盾的。 需求是否可实现？ 需求是否合理？ 需求是否可测？
14
定义测试需求
用 户 需 求
定义
根据用户需求定义并完善测试 需求，以作为整个测试的标准
15
2.3 测试策略
测试策略考虑的问题：
测试范围 测试方法 测试标准 测试工具
16
2.3.1 确定测试范围
测试过度，则在测试覆盖中存在大量冗余； 测试范围过小，则存在遗漏错误的风险。 定义测试范围是一个在测试时间、费用和质 量风险之间寻找平衡的过程。 通过分析产品的需求文档识别哪些需要被测 试。 测试范围不能仅仅由测试人员来确定。
24
选择自动化测试工具需要注意以下几方面：
13
需求测试的方法：
复查 (Review) 复查一般是让工作中合作者检查产品并提出意 见。同级互查可以面对面进行，也可以通过E-Mail 实现，并没有统一标准。发现文档缺陷同级互查的 能力是三种方法中最弱的。 走查 (Walkthrough) 相比较审查走查较为宽松，其事先需要收集数 据，也没有输出报告的要求。 审查 (Inspection) 审查是为发现缺陷而进行的。关键组件的审查 通过会议进行，会前每个与会者需要进行准备，会 议必须按规定的程序进行，缺陷被记录并形成会议 报告。审查被证明是非常有效的发现缺陷的方法。
6
测试计划：考虑测试内容
系统功能 用户界面 系统性能 负载测试 强化测试 容量测试 配置测试 安装测试
7
2.2 测试软件需求
需求分析过程
收集用户需求 编写需求定义文档 编写软件功能说明 编写软件需求跟踪矩阵 审核软件需求文档
8
需求分析中测试人员工作
理解需求，参与审核需求文档 理解项目的目标、限制，了解用户应用背景 编写测试计划 准备资源
17
定义测试范围需要考虑下列一些因素：
首先测试最高优先级的需求。 测试新的功能和代码或者改进的旧功能。 使用等价类划分来减小测试范围 重点测试经常出问题的地方
18
确定测试范围方法
可采用提问单的方式来确定测试范围
哪些功能是软件的特色？ 哪些功能是用户最常用的？ 如果系统可以分块卖的话，哪些功能块在销售时最 昂贵？ 哪些功能出错将导致用户不满或索赔？ 哪些程序是最复杂、最容易出错的？ 哪些程序是相对独立，应当提前测试的？ 哪些程序最容易扩散错误？ 哪些程序是全系统的性能瓶颈所在？ 哪些程序是开发者最没有信心的？
第二章 测试计划
2.1 2.2 2.3 2.4 2.5 2.6 测试计划要点和制订过程 测试软件需求 测试策略 测试环境 测试管理 测试计划编写
1
2.1 测试计划要点和制订过程
软件测试生命周期
开发生命周期 需求分析 设计定义 程序编制
建立 建立 建立
维护
修改
测试生命周期
测试计划 测试设计
定制个案 缺陷跟踪
20
2.3.3 定义测试标准
定义测试标准的目的是设置测试中遵循的 规则。 需要制订以下几种标准：
测试入口标准 测试出口标准 测试暂停与继续标准
21
制订测试标准常用规则（一）
基于测试用例的规则 当测试用例的不通过率达到某一百分比时，则 拒绝继续测试。 优点是适用于所有的测试阶段 缺点是太依赖于测试用例。 基于“测试期缺陷密度”的规则 “测试期缺陷密度”：测试一个CPU小时发现 的缺陷数。 如果在相邻n个CPU小时内“测试期缺陷密度” 全部低于某个值m时，则允许正常结束测试。
测试执行 评估
2
软件测试阶段组成
测试计划
测试设计
测试开发
测试评估
测试执行
3
测试计划的目标
收集并组织测试计划信息 将软件细化为可检验的测试需求 建立测试计划
4
测试计划制订过程
分析和测试软件需求
定义测试策略
定义测试环境
定义测试管理
编写和审核测试计划
5
测试计划要点
测试活动进度综述，可供项目经理产生项目进度时参考； 测试方法，包括测试工具的使用； 测试工具，包括如何和何时获取工具； 实施测试和报告结果的过程； 系统测试进入和结束准则； 设计、开发和执行测试所需的人员； 设备资源：需要什么样的机器和测试基准； 恰当的测试覆盖率目标； 测试所需的特殊软件和硬件配置； 测试应用程序策略； 测试哪些特性，不测试哪些特性； 风险和意外情况计划。
19
2.3.2 选择测试方法
在不同的开发阶段，需要选择不同的测试方法。 在瀑布生命期模型中不同的阶段可以选择的不同的 测试方法：
需求分析阶段：静态测试 概要设计与详细设计阶段：静态测试 编码和单元测试阶段：静态测试和动态测试、白盒测试 集成测试阶段：动态测试、白盒测试、黑盒测试 系统测试阶段：动态测试、黑盒测试 验收测试阶段：动态测试、黑盒测试
9
软件需求文档
需求文档是进行设计、编码、测试的基础 文件，软件需求文档中，需要描述下列内容： 说明 一般描述 各种限制条件、假定和以来 功能需求 非功能需求 参考
10
需求跟踪矩阵
对于需求文档中的每项需求，要确保以下 问题： 是否完成了相应的设计？ 是否编写完成了相应的代码？在哪里可以找 到这些代码？ 是否编写完成了相应的单元测试用例？是否 进行了单元测试？ 是否完成了相应的集成测试用例？是否进行 了集成测试？ 需求跟踪矩阵即描述上述问题。
22
制订测试标准常用规则（二）
基于“运行期缺陷密度”的规则 “运行期缺陷密度”：软件运行一个CPU小时 wenku.baidu.com现的缺陷数 如果在相邻n个CPU小时内“运行期缺陷密度” 全部低于某个值m时，则允许正常结束测试。
23
2.3.4 选择自动化测试工具
使用测试工具可以带来下面一些主要的好 处：
能够很好地进行性能测试和压力测试 能够缩短测试周期 能够提高测试工作的可重复性