软件标准开发测试过程概述
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件开发相关
◼ 软件架构设计的相关知识 ◼ 可视化建模/UML相关知识
软件测试技术相关
◼ 软件集成测试方案的设计 ◼ 软件集成测试用例设计
软件测试管理相关
◼ 软件测试的项目管理 ◼ 沟通能力 ◼ 执行能力
21
概要设计阶段的角色和职责（1）
A. 在项目计划中标识设计活动并确保 有足够的资源
B. 从项目成员中标识出概要设计人员， 负责设计工作
◼ 原始需求 ◼ 产品需求 ◼ 软件需求 ◼ 测试需求
12
需求的属性
每个需求类型都有多个属性：
◼ 优先级 ◼ 工作量 ◼ 风险
1.“必须的”－如果该需求不能实现，软件 产品功能不能成为特定类型的产品； 2.“重要的”－如果该需求不实现，会影响 其市场竞争力；
3.“最好有的”－可以选择实现，针对特定 目标客户群的个性化需求，或为了和同类产 品展开差异化竞争而实现的需求。
件交互 ◼ 性能：速度、响应时间、恢复时间等 ◼ 属性：可移植性、可靠性、可维护性、可用性等 ◼ 实现的设计约束：标准、实现语言、资源限制、操
作环境等
7
软件需求规格说明书的目的
在客户和开发者之间达成一致 为编制计划和成本计价提供基础 为设计提供了基础 为确认和验证提供一个基础 提高开发效率 便于移植
软件标准开发测试过程概述
技术创新，变革未来
1 测试层次传统观点
◈ 测试层次与传统开发V型瀑布模型的对应 ◈ 自顶向下，功能分解
2
概要设计的最终结果是将系统的功能分解为功能组件的 树型结构
ATM系统
终端I/O
管理会话
引导事务
卡输入
PIN输入
选择事务
瀑布模型应用示例：ATM系统的部分功能分解
瀑布模型与通过功能分解进行的自顶向下开发和设计密切 相关；传统集成测试的目标是根据功能分解树集成以前测 过的单元。
3
产品开发测试基本过程
4
常见的软件开发过程
5
需求分析阶段
软件需求的检视、评审 系统测试计划、方案设计 系统测试计划、方案的检视和评审 软件系统测试用例设计 软件系统测试用例的检视和评审
6
SRS的定义
是对在特定环境下要完成一定功能的软件产品、 程序或一组程序的说明。
应该从以下方面去描述需求：
◼ 功能：软件要做什么 ◼ 外部接口：如何与人、系统硬件、外部的硬件和软
C. 确保设计人员按照本流程开发相应 的设计说明书
D. 确保按照评审规程进行设计的评审
A. 完成概要设计和接口文档 B. 参加设计文档评审 C. 根据评审专家意见，修改设计文档
22
概要设计阶段的角色和职责（2）
A. 组织所有的测试活动 B. 制定测试策略 C. 确保测试活动有合适的计划
A. 撰写集成测试用例
软件测试管理相关
◼ 软件测试的项目管理 ◼ 沟通能力 ◼ 执行能力
25
详细设计阶段的角色和职责（1）
A. 在项目计划中标识设计活动并确保有 足够的资源
B. 从项目成员中标识出设计人员，负责 设计工作
C. 确保设计人员按照本流程开发相应的 设计说明书
8
软件需求规格说明书的特点
软件需求的正确性 软件需求的无歧义性 软件需求的完整性 软件需求的一致性 软件需求的可验证性 软件需求的可追踪性
9
实例一
需求1：系统应在不少于每10秒的正常周期内 提供状态信息；
系统应该以误差上下不超过1秒的10秒间隔， 在用户界面的指定位置显示状态信息； 显示的状态信息应包括如下内容：…… 如果显示状态信息有误，应提示如下的错误信 息：……
软件测试管理相关
◼ 软件测试的项目管理 ◼ 沟通能力 ◼ 执行能力
产品业务知识
◼ 通讯的原理 ◼ 财会知识 ◼ 金融产品知识 ◼…
19
概要设计阶段
软件概要设计的检视、评审 软件集成测试计划、方案设计 软件集成测试计划、方案的检视 和评审 软件集成测试用例设计 软件集成测试用例的检视和评审
20
软件集成测试设计的技能要求
可用于界定项目的范围，估计工作量，计划和 平衡资源等
13
需求的表达
表达需求的方法： 通过输入、输出来说明（自然语言） 使用规范化的模型方法（UML） 使用电子表格 使用代表性的例子 …
14
需求表达应避免的问题
需求描述过多涉及到具体的设计和实现 超出规格：对需求描述大大超出用户要求 过度限制：对需求进行不必要的限制 不确定性：
16
软件经理：在SRS评审结束后，批准SRS 文档 QA：监督项目组遵循需求管理流程；参 加相关文档评审；保证相关组参加文档 评审 CCB负责人：控制需求的变更
(Change Control Broad)
17
需求阶段的角色和职责（2）
A. 参与开发人员的软件需求分析，
提出可测试性需求
B. 组织人员参与SRS的评审工作 C. 软件系统测试计划、方案写作 D. 组织软件系统测试计划的评审
23
详细设计阶段
软件详细设计的检视、评审 软件单元测试计划、方案设 计 软件单元测试计划、方案的 检视和评审 软件单元测试用例设计 软件单元测试用例的检视和 评审
24
软件单元测试设计的技能要求
软件开发相关
◼ 具有良好的编码能力 ◼ 软件详细设计的评审能力
软件测试技术相关
◼ 代码逻辑覆盖率的相关知识 ◼ 单元测试用例设计的相关知识
A. 参与软件需求规格的评审工作 B. 协助软件测试项目经理完成软件系统
测试计划、方案写作 C. 参加系统测试计划的评审
18
软件系统测试设计的技能要求
软件开发相关
◼ 软件需求的相关知识 ◼ 可视化建模/UML相关知识
软件测试技术相关
◼ 软件系统测试方案的设计 ◼ 软件系统测试用例设计 ◼ 产品质量属性相关知识
10
实例二
需求2：HTML分析器可以产生HTML标记错误 报告，帮助HTML入门者快速解决错误
HTML分析பைடு நூலகம்可以产生一个错误报告，错误报 告包含有在被分析文件中出错的HTML文本和 行号以及错误的描述。如果没有错误，就不 会产生错误报告
11
需求分类
需求分类是对很多的需求按照可以管理 的方式分组。如：
◼ 以相对的方式描述需求（无具体数据） ◼ 没有结束的需求 ◼ 主观或含糊的描述需求
需求描述基于未经确认的假设
15
需求阶段的角色和职责（1）
A. 带领项目组分析业务需求 B. 带领项目组完成软件需求规格
说明书
A. 撰写软件SRS B. 参加软件SRS的评审 C. 根据评审意见，修改SRS D. 参加系统测试计划的评审
◼ 软件架构设计的相关知识 ◼ 可视化建模/UML相关知识
软件测试技术相关
◼ 软件集成测试方案的设计 ◼ 软件集成测试用例设计
软件测试管理相关
◼ 软件测试的项目管理 ◼ 沟通能力 ◼ 执行能力
21
概要设计阶段的角色和职责（1）
A. 在项目计划中标识设计活动并确保 有足够的资源
B. 从项目成员中标识出概要设计人员， 负责设计工作
◼ 原始需求 ◼ 产品需求 ◼ 软件需求 ◼ 测试需求
12
需求的属性
每个需求类型都有多个属性：
◼ 优先级 ◼ 工作量 ◼ 风险
1.“必须的”－如果该需求不能实现，软件 产品功能不能成为特定类型的产品； 2.“重要的”－如果该需求不实现，会影响 其市场竞争力；
3.“最好有的”－可以选择实现，针对特定 目标客户群的个性化需求，或为了和同类产 品展开差异化竞争而实现的需求。
件交互 ◼ 性能：速度、响应时间、恢复时间等 ◼ 属性：可移植性、可靠性、可维护性、可用性等 ◼ 实现的设计约束：标准、实现语言、资源限制、操
作环境等
7
软件需求规格说明书的目的
在客户和开发者之间达成一致 为编制计划和成本计价提供基础 为设计提供了基础 为确认和验证提供一个基础 提高开发效率 便于移植
软件标准开发测试过程概述
技术创新，变革未来
1 测试层次传统观点
◈ 测试层次与传统开发V型瀑布模型的对应 ◈ 自顶向下，功能分解
2
概要设计的最终结果是将系统的功能分解为功能组件的 树型结构
ATM系统
终端I/O
管理会话
引导事务
卡输入
PIN输入
选择事务
瀑布模型应用示例：ATM系统的部分功能分解
瀑布模型与通过功能分解进行的自顶向下开发和设计密切 相关；传统集成测试的目标是根据功能分解树集成以前测 过的单元。
3
产品开发测试基本过程
4
常见的软件开发过程
5
需求分析阶段
软件需求的检视、评审 系统测试计划、方案设计 系统测试计划、方案的检视和评审 软件系统测试用例设计 软件系统测试用例的检视和评审
6
SRS的定义
是对在特定环境下要完成一定功能的软件产品、 程序或一组程序的说明。
应该从以下方面去描述需求：
◼ 功能：软件要做什么 ◼ 外部接口：如何与人、系统硬件、外部的硬件和软
C. 确保设计人员按照本流程开发相应 的设计说明书
D. 确保按照评审规程进行设计的评审
A. 完成概要设计和接口文档 B. 参加设计文档评审 C. 根据评审专家意见，修改设计文档
22
概要设计阶段的角色和职责（2）
A. 组织所有的测试活动 B. 制定测试策略 C. 确保测试活动有合适的计划
A. 撰写集成测试用例
软件测试管理相关
◼ 软件测试的项目管理 ◼ 沟通能力 ◼ 执行能力
25
详细设计阶段的角色和职责（1）
A. 在项目计划中标识设计活动并确保有 足够的资源
B. 从项目成员中标识出设计人员，负责 设计工作
C. 确保设计人员按照本流程开发相应的 设计说明书
8
软件需求规格说明书的特点
软件需求的正确性 软件需求的无歧义性 软件需求的完整性 软件需求的一致性 软件需求的可验证性 软件需求的可追踪性
9
实例一
需求1：系统应在不少于每10秒的正常周期内 提供状态信息；
系统应该以误差上下不超过1秒的10秒间隔， 在用户界面的指定位置显示状态信息； 显示的状态信息应包括如下内容：…… 如果显示状态信息有误，应提示如下的错误信 息：……
软件测试管理相关
◼ 软件测试的项目管理 ◼ 沟通能力 ◼ 执行能力
产品业务知识
◼ 通讯的原理 ◼ 财会知识 ◼ 金融产品知识 ◼…
19
概要设计阶段
软件概要设计的检视、评审 软件集成测试计划、方案设计 软件集成测试计划、方案的检视 和评审 软件集成测试用例设计 软件集成测试用例的检视和评审
20
软件集成测试设计的技能要求
可用于界定项目的范围，估计工作量，计划和 平衡资源等
13
需求的表达
表达需求的方法： 通过输入、输出来说明（自然语言） 使用规范化的模型方法（UML） 使用电子表格 使用代表性的例子 …
14
需求表达应避免的问题
需求描述过多涉及到具体的设计和实现 超出规格：对需求描述大大超出用户要求 过度限制：对需求进行不必要的限制 不确定性：
16
软件经理：在SRS评审结束后，批准SRS 文档 QA：监督项目组遵循需求管理流程；参 加相关文档评审；保证相关组参加文档 评审 CCB负责人：控制需求的变更
(Change Control Broad)
17
需求阶段的角色和职责（2）
A. 参与开发人员的软件需求分析，
提出可测试性需求
B. 组织人员参与SRS的评审工作 C. 软件系统测试计划、方案写作 D. 组织软件系统测试计划的评审
23
详细设计阶段
软件详细设计的检视、评审 软件单元测试计划、方案设 计 软件单元测试计划、方案的 检视和评审 软件单元测试用例设计 软件单元测试用例的检视和 评审
24
软件单元测试设计的技能要求
软件开发相关
◼ 具有良好的编码能力 ◼ 软件详细设计的评审能力
软件测试技术相关
◼ 代码逻辑覆盖率的相关知识 ◼ 单元测试用例设计的相关知识
A. 参与软件需求规格的评审工作 B. 协助软件测试项目经理完成软件系统
测试计划、方案写作 C. 参加系统测试计划的评审
18
软件系统测试设计的技能要求
软件开发相关
◼ 软件需求的相关知识 ◼ 可视化建模/UML相关知识
软件测试技术相关
◼ 软件系统测试方案的设计 ◼ 软件系统测试用例设计 ◼ 产品质量属性相关知识
10
实例二
需求2：HTML分析器可以产生HTML标记错误 报告，帮助HTML入门者快速解决错误
HTML分析பைடு நூலகம்可以产生一个错误报告，错误报 告包含有在被分析文件中出错的HTML文本和 行号以及错误的描述。如果没有错误，就不 会产生错误报告
11
需求分类
需求分类是对很多的需求按照可以管理 的方式分组。如：
◼ 以相对的方式描述需求（无具体数据） ◼ 没有结束的需求 ◼ 主观或含糊的描述需求
需求描述基于未经确认的假设
15
需求阶段的角色和职责（1）
A. 带领项目组分析业务需求 B. 带领项目组完成软件需求规格
说明书
A. 撰写软件SRS B. 参加软件SRS的评审 C. 根据评审意见，修改SRS D. 参加系统测试计划的评审