软件测试方法与技术实践指南 Java篇
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
? 项目立项与拟定产品的发展方向阶段
?产品需求文档的形成及其实例 ?产品需求文档PRD ?PRD如何形成 ?PRD的主要内容与格式 ?PRD实例介绍
?产品需求形成阶段测试工程师需要做什么 ?阅读PRD中的详细功能需求 ?给PM反馈信息并协助PM去修改 ?跟踪提交的问题解决状态
软件的需求 -需求的定义
?
需求不可测
?
需求不可实现
? 导致后续工作难于开展或经常出现变更。
需求评审重要性的直观描述
主持人
内审员
作者
技术专业人员 记录员
评审会议角色
列席人员
测试人员在需求评审中作用
需求评审归为静态测试范畴，包含了文档评审和技术评审 双重内容，通常通过正式的评审会议来进行。而测试人员 主要起着评审员的作用，检查需求定义是否合理和清楚。
? 跟踪提交的问题解决状态
什么是评审
产品需求审查是软件开发重要环节之一，也是测试活动之 一，即静态测试——需求验证。借助需求审查保证用户需 求在市场/产品需求文档及其相关文档中得到准确、完整、 无歧义的反映，并使各类开发人员在需求理解上达成一致。 软件评审是对软件元素或者项目状态的一种评估手段，以 确定其是否与计划的结果保持一致，并使其得到改进。
? IEEE软件工程标准词汇表定义需求为：
? 用户解决ቤተ መጻሕፍቲ ባይዱ题或达到目标所需的条件或能力。 ? 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需
具有的条件或能力。 ? 一种反映上面(1)或(2)所描述的条件或能力的文档说明。
?Merlin Dorfman 和 Richard H. Thayer 提出了一个包容 且更为精练的定义：
需求评审的重要性
需求评审的重要性：
1. 软件需求是软件开发最重要的一个输入 ，好的开始是成功的一半!
所以，需求的质量很大程度上决定了项目质量或产品质量。
2. 需求风险常常是软件开发过程中最大的一个风险 ，要降低需求阶段 带来的风险，就要把需求评审做好。
3. 需求评审做不好的后果：
?
需求变更
?
需求不明确
?技术设计文档阶段测试工程师需要做什么 ?为测试环境做准备 ?了解产品的逻辑流程，数据库结构，以及各个模块的具体功能 ?了解产品设计中的一些技术问题 ?了解产品的性能，为性能测试作准备
测试在需求阶段的工作
参与需求的分析及评审，从测试角度分析需求的可测 试性，具体为：
? 阅读PRD中的详细功能需求，对需求文档进行检查
第二篇 基于Java EE 产品线的项目实践
第4章：项目初期各阶段的主要工作 第5章：软件测试计划的制定 第6章：软件测试用例的编写 第7章：软件项目各部门相互协作 第8章：执行测试案例并报告缺陷 第9章：产品功能完善与修复缺陷阶段
第10章：测4 试工程师在产品发布前后的工作
软件生产的几个主要阶段（第4至10章从测试角度逐步展开）
为什么需要需求评审
? 1.软件缺陷并不只是在编程阶段才产生，需求和 设计阶段同样会产生缺陷
? 2.软件测试对需求的依赖
? 在制定测试计划之前，必须清楚测试需求 ? 明确测试需求的优先级 ? 测试需求分解得越细，对测试用例的设计质量越有帮助 ? 详细的测试需求还是衡量测试覆盖率的重要依据 ? 测试需求是规划具体项目资源和时间的基础。
– 客户对系统的高层次的目标要求。
? 用户需求（user requirement ）
– 用户使用产品必须要完成的任务
? 功能需求（functional requirement ）
– 开发人员必须实现的软件功能，使得用户能完成他们 的任务，满足业务需求
? 非功能需求 （non-functional requirement ）
场景 – 为更好地定义需求而开发的任意原型。
? 建立顺畅的通信途径 ? 访谈与调查 ? 观察用户操作流程 ? 组成联合小组
需求获取方法与策略
第4章 项目初期各阶段的主要工作
?产品规格说明书制定阶段
?产品规格说明书的形成及其实例 ?产品规格说明书SPEC ?SPEC如何形成 ?SPEC的主要内容与格式 ?SPEC实例介绍
软件生产流程： (本篇重点) 该图能清晰看出软件生产各环节开发与测试的主要工作 学生需要清晰的知道每个英文代表的环节与意义 本书所有章节,以及软件工程师的工作都是围绕本图展开
第4章 项目初期各阶段的主要工作
? 项目立项与拟定产品的发展方向阶段 ?产品规格说明书制定阶段 ?产品技术文档设计阶段
第4章 项目初期各阶段的主要工作
? 用户解决某一问题或达到某一目标所需的软件功能。 ? 系统或系统构件为了满足合同、规约、标准或其他正式实行的文档
而必须满足或具备的软件功能。
软件需求 -需求分析的任务
? 需求分析的任务：确定用户需求，准确地回答 “系统必须 做什么？” 的问题，获得需求规格说明书。
软件需求 -需求类型
? 业务需求（business requirement ）
– 对系统提供的服务或者功能提出的约束，包括时间、 开发过程、软件质量、标准等约束
需求获取的内容
? 系统分析人员通过与用户的交流、对现有系统的 观察及对任务进行分析，确定：
– 系统或产品范围的限制性描述 – 与系统或产品有关的人员及特征列表 – 系统的技术环境的描述 – 系统功能的列表及应用于每个需求的领域限制 – 一组描述不同运行条件下系统或产品使用状况的应用
? 明确自己的角色和责任 ? 熟悉评审内容，为评审做好准备 ? 针对问题阐述观点，而非针对个人 ? 从客户角度想问题，多问几个为什么 ? 在会前或会后提出自己建设性的意见 ? 对发现的问题跟踪到底 ? 针对需求文档等报告问题
评审的形式
?相互评审、交叉评审 ：甲和乙在一个项目组，处在一个领域，但工作内容不同，甲的工作成果交给 乙审查，乙的工作成果交给甲审查。相互评审是最不正式的一种评审形式，但应用方便、有效。 ?轮查：又称分配审查方法，是一种异步评审方式。作者将需要评审的内容发送给各位评审员，并收 集他们的反馈意见 ?走查：作者将测试需求在现场向一组同事介绍，以收集大家的意见。希望参与评审的其他同事可以 发现其中的错误，并能进行现场讨论。这种形式介于正式和非正式之间。 ?小组评审： 通过正式的小组会议完成评审工作，是有计划的和结构化的评审方式。评审定义了评审 会议中的各种角色和相应的责任，所有参与者在评审会议的前几天就拿到了评审材料，并对该材料进 行了独立研究。 ?审查：审查和小组评审很相似，但更为严格，是最系统化、最严密的评审形式，包含了制定计划、 准备和组织会议、跟踪和分析审查结果等。
?产品规格说明书阶段测试工程师需要做什么 ?阅读并查看SPEC中的功能是否符合PRD要求 ?和EM保持良好的沟通，并且一起阅读SPEC的详细内容 ?根据SPEC设计Test Case ?跟踪SPEC中提出的问题解决状态
第4章 项目初期各阶段的主要工作
?产品技术文档设计阶段
?编写技术设计文档 ?什么是产品的技术文档 ?技术文档中包括哪些内容 ?技术文档实例介绍
?产品需求文档的形成及其实例 ?产品需求文档PRD ?PRD如何形成 ?PRD的主要内容与格式 ?PRD实例介绍
?产品需求形成阶段测试工程师需要做什么 ?阅读PRD中的详细功能需求 ?给PM反馈信息并协助PM去修改 ?跟踪提交的问题解决状态
软件的需求 -需求的定义
?
需求不可测
?
需求不可实现
? 导致后续工作难于开展或经常出现变更。
需求评审重要性的直观描述
主持人
内审员
作者
技术专业人员 记录员
评审会议角色
列席人员
测试人员在需求评审中作用
需求评审归为静态测试范畴，包含了文档评审和技术评审 双重内容，通常通过正式的评审会议来进行。而测试人员 主要起着评审员的作用，检查需求定义是否合理和清楚。
? 跟踪提交的问题解决状态
什么是评审
产品需求审查是软件开发重要环节之一，也是测试活动之 一，即静态测试——需求验证。借助需求审查保证用户需 求在市场/产品需求文档及其相关文档中得到准确、完整、 无歧义的反映，并使各类开发人员在需求理解上达成一致。 软件评审是对软件元素或者项目状态的一种评估手段，以 确定其是否与计划的结果保持一致，并使其得到改进。
? IEEE软件工程标准词汇表定义需求为：
? 用户解决ቤተ መጻሕፍቲ ባይዱ题或达到目标所需的条件或能力。 ? 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需
具有的条件或能力。 ? 一种反映上面(1)或(2)所描述的条件或能力的文档说明。
?Merlin Dorfman 和 Richard H. Thayer 提出了一个包容 且更为精练的定义：
需求评审的重要性
需求评审的重要性：
1. 软件需求是软件开发最重要的一个输入 ，好的开始是成功的一半!
所以，需求的质量很大程度上决定了项目质量或产品质量。
2. 需求风险常常是软件开发过程中最大的一个风险 ，要降低需求阶段 带来的风险，就要把需求评审做好。
3. 需求评审做不好的后果：
?
需求变更
?
需求不明确
?技术设计文档阶段测试工程师需要做什么 ?为测试环境做准备 ?了解产品的逻辑流程，数据库结构，以及各个模块的具体功能 ?了解产品设计中的一些技术问题 ?了解产品的性能，为性能测试作准备
测试在需求阶段的工作
参与需求的分析及评审，从测试角度分析需求的可测 试性，具体为：
? 阅读PRD中的详细功能需求，对需求文档进行检查
第二篇 基于Java EE 产品线的项目实践
第4章：项目初期各阶段的主要工作 第5章：软件测试计划的制定 第6章：软件测试用例的编写 第7章：软件项目各部门相互协作 第8章：执行测试案例并报告缺陷 第9章：产品功能完善与修复缺陷阶段
第10章：测4 试工程师在产品发布前后的工作
软件生产的几个主要阶段（第4至10章从测试角度逐步展开）
为什么需要需求评审
? 1.软件缺陷并不只是在编程阶段才产生，需求和 设计阶段同样会产生缺陷
? 2.软件测试对需求的依赖
? 在制定测试计划之前，必须清楚测试需求 ? 明确测试需求的优先级 ? 测试需求分解得越细，对测试用例的设计质量越有帮助 ? 详细的测试需求还是衡量测试覆盖率的重要依据 ? 测试需求是规划具体项目资源和时间的基础。
– 客户对系统的高层次的目标要求。
? 用户需求（user requirement ）
– 用户使用产品必须要完成的任务
? 功能需求（functional requirement ）
– 开发人员必须实现的软件功能，使得用户能完成他们 的任务，满足业务需求
? 非功能需求 （non-functional requirement ）
场景 – 为更好地定义需求而开发的任意原型。
? 建立顺畅的通信途径 ? 访谈与调查 ? 观察用户操作流程 ? 组成联合小组
需求获取方法与策略
第4章 项目初期各阶段的主要工作
?产品规格说明书制定阶段
?产品规格说明书的形成及其实例 ?产品规格说明书SPEC ?SPEC如何形成 ?SPEC的主要内容与格式 ?SPEC实例介绍
软件生产流程： (本篇重点) 该图能清晰看出软件生产各环节开发与测试的主要工作 学生需要清晰的知道每个英文代表的环节与意义 本书所有章节,以及软件工程师的工作都是围绕本图展开
第4章 项目初期各阶段的主要工作
? 项目立项与拟定产品的发展方向阶段 ?产品规格说明书制定阶段 ?产品技术文档设计阶段
第4章 项目初期各阶段的主要工作
? 用户解决某一问题或达到某一目标所需的软件功能。 ? 系统或系统构件为了满足合同、规约、标准或其他正式实行的文档
而必须满足或具备的软件功能。
软件需求 -需求分析的任务
? 需求分析的任务：确定用户需求，准确地回答 “系统必须 做什么？” 的问题，获得需求规格说明书。
软件需求 -需求类型
? 业务需求（business requirement ）
– 对系统提供的服务或者功能提出的约束，包括时间、 开发过程、软件质量、标准等约束
需求获取的内容
? 系统分析人员通过与用户的交流、对现有系统的 观察及对任务进行分析，确定：
– 系统或产品范围的限制性描述 – 与系统或产品有关的人员及特征列表 – 系统的技术环境的描述 – 系统功能的列表及应用于每个需求的领域限制 – 一组描述不同运行条件下系统或产品使用状况的应用
? 明确自己的角色和责任 ? 熟悉评审内容，为评审做好准备 ? 针对问题阐述观点，而非针对个人 ? 从客户角度想问题，多问几个为什么 ? 在会前或会后提出自己建设性的意见 ? 对发现的问题跟踪到底 ? 针对需求文档等报告问题
评审的形式
?相互评审、交叉评审 ：甲和乙在一个项目组，处在一个领域，但工作内容不同，甲的工作成果交给 乙审查，乙的工作成果交给甲审查。相互评审是最不正式的一种评审形式，但应用方便、有效。 ?轮查：又称分配审查方法，是一种异步评审方式。作者将需要评审的内容发送给各位评审员，并收 集他们的反馈意见 ?走查：作者将测试需求在现场向一组同事介绍，以收集大家的意见。希望参与评审的其他同事可以 发现其中的错误，并能进行现场讨论。这种形式介于正式和非正式之间。 ?小组评审： 通过正式的小组会议完成评审工作，是有计划的和结构化的评审方式。评审定义了评审 会议中的各种角色和相应的责任，所有参与者在评审会议的前几天就拿到了评审材料，并对该材料进 行了独立研究。 ?审查：审查和小组评审很相似，但更为严格，是最系统化、最严密的评审形式，包含了制定计划、 准备和组织会议、跟踪和分析审查结果等。
?产品规格说明书阶段测试工程师需要做什么 ?阅读并查看SPEC中的功能是否符合PRD要求 ?和EM保持良好的沟通，并且一起阅读SPEC的详细内容 ?根据SPEC设计Test Case ?跟踪SPEC中提出的问题解决状态
第4章 项目初期各阶段的主要工作
?产品技术文档设计阶段
?编写技术设计文档 ?什么是产品的技术文档 ?技术文档中包括哪些内容 ?技术文档实例介绍