软件测试方法与技术实践指南-Java篇 ppt课件
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用户通常难以忍受运行或响应速度过慢的系统。 系统的安全性也是一个很重要的指标,尤其是作为企业级的系统,它的安全考量完全继承于
组织对安全的基本诉求 。
ppt课件
28
需求的可实施性评审
是否对每个需求都设置了维一性标志并且可以正确地识别它？是 否每个功能需求都可以跟踪到高层需求
需求必须可以测试,每个需求在特定的输入条件下应当能给出已知 的输出结果。
如果可行性高,则还要考虑它需要哪些资源和预算。我们需要确 定技术是否确实满足业务需求,同时, 也要考虑整个产品成本, 包括开发人员、服务器、许可和升级费用,还需要考虑初始硬件、 软件和支持、基础结构和培训的费用。
ppt课件
27
需求的质量属性评审
我们需要评审需求规格说明是否合理地确定了所有的性能目标， 是否合理地确定了安全性方面要考虑到的问题。
ppt课件
22
需求评审的内容
产品需求的正确性 产品需求的实践性 产品需求的完整性 产品需求的可行性和成本预算 产品需求的质量属性 产品需求的可实验性
ppt课件
23
需求规格说明的正确性评审
需求规格说明的正确性体现在：
✓ 是否有需求与其他需求相互冲突或者重复？ ✓ 是否清晰、简洁、无二义地表达了每个需求? ✓ 是否每个需求都通过了演示、测试、评审，分析是否得到了验证? ✓ 是否每个需求都没有内容和语法上的错误? ✓ 在现有的资源内, 是否能实现所有的需求? ✓ 是否每个需求都在项目的范围内? ✓ 每一条特定的错误信息，是否都是唯一的和具有含义的?
ppt课件
24
需求规格说明的实践性评审
实践性是指需求本身是否来源于目前企业的相关业务规则和文件 制度,而非源于分析师们经验主义的臆测 。
有经验的系统分析师通常会迷信自己的经验,把从前的经验嫁接到 目前的企业需求分析中。也许由于行业性质相同,但如果不经过当 前的实践调研则给出需求，仍然会无法体现出企业自身的特征。 因而不能为企业带来真正的价值,也会造成与用户需求的鸿沟。
件功能。
ppt课件
7
软件需求-需求分析的任务
需求分析的任务：确定用户需求，准确地回答 “系统必须 做什么？” 的问题，获得需求规格说明书。
ppt课件
8
软件需求-需求类型
业务需求（business requirement）
客户对系统的高层次的目标要求。
用户需求（user requirement）
是否对所有预期的错误条件所产生的系统行为都编制了文档?
ppt课件
26
需求方案的可行性和成本预算评审
需求方案的可行性和成本预算评审的目的，是从需求的多项方 案中选择最优化的或者是性价比最高的方案。一般而言,需求说 明书可以给出同一个问题的几种方案，并给出各自的优缺点和 成本差异,经过比较由决策者作出最终选择。
ppt课件
34
第5章 软件测试计划的制定
ppt课件
21
软件需求评审的输入
1、软件需求规格说明书；
2、项目工作任务书；
3、软件需求规格说明书的检查列表（Checklist）；
检查表（checklist）是一种常用的的质量保证手段，也 是正式技术评审的必要工具，评审过程往往由检查表驱动。 一份精心设计的检查表，对于提高评审效率、改进评审质量 具有很大帮助。 可靠性。人们借助检查表以确认被检查对象的所有质量特征 均得到满足，避免遗漏任何项目。 效率。检查表归纳了所有检查要点，比起冗长的文档，使用 检查表具有更高的工作效率。
ppt课件
13
测试在需求阶段的工作
参与需求的分析及评审，从测试角度分析需求的可测试性，具 体为： ✓ 阅读PRD中的详细功能需求，对需求文档进行检查
✓ 跟踪提交的问题解决状态
ppt课件
14
什么是评审
产品需求审查是软件开发重要环节之一，也是测试活动之 一，即静态测试——需求验证。借助需求审查保证用户需 求在市场/产品需求文档及其相关文档中得到准确、完整、 无歧义的反映，并使各类开发人员在需求理解上达成一致。
需求不明确
需求不可测
需求不可实现
导致后续工作难于开展或经常出现变更。
ppt课件
17
需求评审重要性的直观描述
ppt课件
18
主持人
评审会议角色
内审员
作者
技术专业人员 记录员
列席人员
ppt课件
19
测试人员在需求评审中作用
需求评审归为静态测试范畴，包含了文档评审和技术评审 双重内容，通常通过正式的评审会议来进行。而测试人员 主要起着评审员的作用，检查需求定义是否合理和清楚。
用户使用产品必须要完成的任务
功能需求（functional requirement）
开发人员必须实现的软件功能，使得用户能完成他们的任 务，满足业务需求
非功能需求（non-functional requirement ）
对系统提供的服务或者功能提出的约束，包括时间、开发 过程、软件质量、标准等约束
第二篇 基于Java EE产品线的项目实践
第4章：项目初期各阶段的主要工作 第5章：软件测试计划的制定 第6章：软件测试用例的编写 第7章：软件项目各部门相互协作 第8章：执行测试案例并报告缺陷 第9章：产品功能完善与修复缺陷阶段
第10章：测4 试工程师在产品发布前后的工作
ppt课件
1
软件生产的几个主要阶段（第4至10章从测试角度逐步展开）
同时,需求应当层次分明,需要把单个需求下面的相关需求综合在 一起形成一组需求功能。
需求的可实施性除了可跟踪性还包括可测试性。
ppt课件
29
软件需求评审输出
根据评审专家意见修改后的软件需求规格说明书 软件需求规格说明书评审表格（评审记录表单）
ppt课件
30
第5章 软件测试计划的制定
为何要制定测试计划 怎样设计测试计划 测试计划设计实例 测试计划修改与维护
➢产品需求文档的形成及其实例 ✓产品需求文档PRD ✓PRD如何形成 ✓PRD的主要内容与格式 ✓PRD实例介绍
➢产品需求形成阶段测试工程师需要做什么 ✓阅读PRD中的详细功能需求 ✓给PM反馈信息并协助PM去修改 ✓跟踪提交的问题解决状态
ppt课件
6
软件的需求-需求的定义
IEEE软件工程标准词汇表定义需求为：
软件评审是对软件元素或者项目状态的一种评估手段，以 确定其是否与计划的结果保持一致，并使其得到改进。
ppt课件
15
为什么需要需求评审
1.软件缺陷并不只是在编程阶段才产生，需求和 设计阶段同样会产生缺陷
2.软件测试对需求的依赖
在制定测试计划之前，必须清楚测试需求 明确测试需求的优先级 测试需求分解得越细，对测试用例的设计质量越有帮助 详细的测试需求还是衡量测试覆盖率的重要依据 测试需求是规划具体项目资源和时间的基础。
ppt课件
32
测试计划的定义
ANSI/IEEE把测试计划定义为：
一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。 它确认了测试项。被测特征、测试任务、人员安排以及任何偶发 事件的风险
ppt课件
33
测试计划的定义
ANSI/IEEE把测试计划定义为：
一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。 它确认了测试项。被测特征、测试任务、人员安排以及任何偶发 事件的风险
ppt课件
16
需求评审的重要性
需求评审的重要性：
1. 软件需求是软件开发最重要的一个输入 ，好的开始是成功的一半! 所以，需求的质量很大程度上决定了项目质量或产品质量。
2. 需求风险常常是软件开发过程中最大的一个风险 ，要降低需求阶段 带来的风险，就要把需求评审做好。
3. 需求评审做不好的后果：
需求变更
ppt课件
25
需求规格说明的完整性评审
编写的所有需求，其详细程度是否一致和合适?
需求是否能为设计提供足够的基础?
所有对其他需求的内部引用是否正确?
是否包含了每个需求的实现优先级?
是否定义了功能说明的内在算法?
是否包含了所有已知的客户需求或系统需求?
是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题 (TBD) ?
• “不怕太阳晒，也不怕那风雨狂，只怕先生骂我 笨，没有学问无颜见爹娘 ……”
• “太阳当空照，花儿对我笑，小鸟说早早早……”
ቤተ መጻሕፍቲ ባይዱ
第4章 项目初期各阶段的主要工作
项目立项与拟定产品的发展方向阶段 产品规格说明书制定阶段 产品技术文档设计阶段
ppt课件
5
第4章 项目初期各阶段的主要工作
项目立项与拟定产品的发展方向阶段
明确自己的角色和责任 熟悉评审内容，为评审做好准备 针对问题阐述观点，而非针对个人 从客户角度想问题，多问几个为什么 在会前或会后提出自己建设性的意见 对发现的问题跟踪到底 针对需求文档等报告问题
ppt课件
20
评审的形式
✓ 相互评审、交叉评审：甲和乙在一个项目组，处在一个领域，但工作内容不同，甲的工作成果交给 乙审查，乙的工作成果交给甲审查。相互评审是最不正式的一种评审形式，但应用方便、有效。 ✓ 轮查：又称分配审查方法，是一种异步评审方式。作者将需要评审的内容发送给各位评审员，并收 集他们的反馈意见 ✓ 走查：作者将测试需求在现场向一组同事介绍，以收集大家的意见。希望参与评审的其他同事可以 发现其中的错误，并能进行现场讨论。这种形式介于正式和非正式之间。 ✓ 小组评审：通过正式的小组会议完成评审工作，是有计划的和结构化的评审方式。评审定义了评审 会议中的各种角色和相应的责任，所有参与者在评审会议的前几天就拿到了评审材料，并对该材料进 行了独立研究。 ✓ 审查：审查和小组评审很相似，但更为严格，是最系统化、最严密的评审形式，包含了制定计划、 准备和组织会议、跟踪和分析审查结果等。
◦ 用户解决问题或达到目标所需的条件或能力。 ◦ 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 ◦ 一种反映上面(1)或(2)所描述的条件或能力的文档说明。
Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更 为精练的定义：
◦ 用户解决某一问题或达到某一目标所需的软件功能。 ◦ 系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软
ppt课件
9
需求获取的内容
系统分析人员通过与用户的交流、对现有系统的 观察及对任务进行分析，确定：
系统或产品范围的限制性描述 与系统或产品有关的人员及特征列表 系统的技术环境的描述 系统功能的列表及应用于每个需求的领域限制 一组描述不同运行条件下系统或产品使用状况的应用场景 为更好地定义需求而开发的任意原型。
ppt课件
31
第5章 软件测试计划的制定
为何要制定测试计划
➢可以让项目有条理有计划地进行 ➢可以提前预知项目过程中可能出现的问题 ➢明确测试目标、测试范围和测试重点 ➢明确测试任务和测试方法，保证测试实施过程的顺畅沟通
说明： 测试计划是每一个测试项目组长一定要会写的，并且能准确执行的。 好的测试计划能让测试有条不紊的进行，做到事半功倍。
ppt课件
12
第4章 项目初期各阶段的主要工作
产品技术文档设计阶段
➢编写技术设计文档 ✓什么是产品的技术文档 ✓技术文档中包括哪些内容 ✓技术文档实例介绍
➢技术设计文档阶段测试工程师需要做什么 ✓为测试环境做准备 ✓了解产品的逻辑流程，数据库结构，以及各个模块的具体功能 ✓了解产品设计中的一些技术问题 ✓了解产品的性能，为性能测试作准备
软件生产流程：(本篇重点) 该图能清晰看出软件生产各环节开发与测试的主要工作 学生需要清晰的知道每个英文代表的环节与意义 本书所有章节,以及软件工程师的工作都是围绕本图展开
ppt课件
2
精品资料
• 你怎么称呼老师？
• 如果老师最后没有总结一节课的重点的难点，你 是否会认为老师的教学方法需要改进？
• 你所经历的课堂，是讲座式还是讨论式？ • 教师的教鞭
ppt课件
10
需求获取方法与策略
建立顺畅的通信途径 访谈与调查 观察用户操作流程 组成联合小组
ppt课件
11
第4章 项目初期各阶段的主要工作
产品规格说明书制定阶段
➢产品规格说明书的形成及其实例 ✓产品规格说明书SPEC ✓SPEC如何形成 ✓SPEC的主要内容与格式 ✓SPEC实例介绍
➢产品规格说明书阶段测试工程师需要做什么 ✓阅读并查看SPEC中的功能是否符合PRD要求 ✓和EM保持良好的沟通，并且一起阅读SPEC的详细内容 ✓根据SPEC设计Test Case ✓跟踪SPEC中提出的问题解决状态
组织对安全的基本诉求 。
ppt课件
28
需求的可实施性评审
是否对每个需求都设置了维一性标志并且可以正确地识别它？是 否每个功能需求都可以跟踪到高层需求
需求必须可以测试,每个需求在特定的输入条件下应当能给出已知 的输出结果。
如果可行性高,则还要考虑它需要哪些资源和预算。我们需要确 定技术是否确实满足业务需求,同时, 也要考虑整个产品成本, 包括开发人员、服务器、许可和升级费用,还需要考虑初始硬件、 软件和支持、基础结构和培训的费用。
ppt课件
27
需求的质量属性评审
我们需要评审需求规格说明是否合理地确定了所有的性能目标， 是否合理地确定了安全性方面要考虑到的问题。
ppt课件
22
需求评审的内容
产品需求的正确性 产品需求的实践性 产品需求的完整性 产品需求的可行性和成本预算 产品需求的质量属性 产品需求的可实验性
ppt课件
23
需求规格说明的正确性评审
需求规格说明的正确性体现在：
✓ 是否有需求与其他需求相互冲突或者重复？ ✓ 是否清晰、简洁、无二义地表达了每个需求? ✓ 是否每个需求都通过了演示、测试、评审，分析是否得到了验证? ✓ 是否每个需求都没有内容和语法上的错误? ✓ 在现有的资源内, 是否能实现所有的需求? ✓ 是否每个需求都在项目的范围内? ✓ 每一条特定的错误信息，是否都是唯一的和具有含义的?
ppt课件
24
需求规格说明的实践性评审
实践性是指需求本身是否来源于目前企业的相关业务规则和文件 制度,而非源于分析师们经验主义的臆测 。
有经验的系统分析师通常会迷信自己的经验,把从前的经验嫁接到 目前的企业需求分析中。也许由于行业性质相同,但如果不经过当 前的实践调研则给出需求，仍然会无法体现出企业自身的特征。 因而不能为企业带来真正的价值,也会造成与用户需求的鸿沟。
件功能。
ppt课件
7
软件需求-需求分析的任务
需求分析的任务：确定用户需求，准确地回答 “系统必须 做什么？” 的问题，获得需求规格说明书。
ppt课件
8
软件需求-需求类型
业务需求（business requirement）
客户对系统的高层次的目标要求。
用户需求（user requirement）
是否对所有预期的错误条件所产生的系统行为都编制了文档?
ppt课件
26
需求方案的可行性和成本预算评审
需求方案的可行性和成本预算评审的目的，是从需求的多项方 案中选择最优化的或者是性价比最高的方案。一般而言,需求说 明书可以给出同一个问题的几种方案，并给出各自的优缺点和 成本差异,经过比较由决策者作出最终选择。
ppt课件
34
第5章 软件测试计划的制定
ppt课件
21
软件需求评审的输入
1、软件需求规格说明书；
2、项目工作任务书；
3、软件需求规格说明书的检查列表（Checklist）；
检查表（checklist）是一种常用的的质量保证手段，也 是正式技术评审的必要工具，评审过程往往由检查表驱动。 一份精心设计的检查表，对于提高评审效率、改进评审质量 具有很大帮助。 可靠性。人们借助检查表以确认被检查对象的所有质量特征 均得到满足，避免遗漏任何项目。 效率。检查表归纳了所有检查要点，比起冗长的文档，使用 检查表具有更高的工作效率。
ppt课件
13
测试在需求阶段的工作
参与需求的分析及评审，从测试角度分析需求的可测试性，具 体为： ✓ 阅读PRD中的详细功能需求，对需求文档进行检查
✓ 跟踪提交的问题解决状态
ppt课件
14
什么是评审
产品需求审查是软件开发重要环节之一，也是测试活动之 一，即静态测试——需求验证。借助需求审查保证用户需 求在市场/产品需求文档及其相关文档中得到准确、完整、 无歧义的反映，并使各类开发人员在需求理解上达成一致。
需求不明确
需求不可测
需求不可实现
导致后续工作难于开展或经常出现变更。
ppt课件
17
需求评审重要性的直观描述
ppt课件
18
主持人
评审会议角色
内审员
作者
技术专业人员 记录员
列席人员
ppt课件
19
测试人员在需求评审中作用
需求评审归为静态测试范畴，包含了文档评审和技术评审 双重内容，通常通过正式的评审会议来进行。而测试人员 主要起着评审员的作用，检查需求定义是否合理和清楚。
用户使用产品必须要完成的任务
功能需求（functional requirement）
开发人员必须实现的软件功能，使得用户能完成他们的任 务，满足业务需求
非功能需求（non-functional requirement ）
对系统提供的服务或者功能提出的约束，包括时间、开发 过程、软件质量、标准等约束
第二篇 基于Java EE产品线的项目实践
第4章：项目初期各阶段的主要工作 第5章：软件测试计划的制定 第6章：软件测试用例的编写 第7章：软件项目各部门相互协作 第8章：执行测试案例并报告缺陷 第9章：产品功能完善与修复缺陷阶段
第10章：测4 试工程师在产品发布前后的工作
ppt课件
1
软件生产的几个主要阶段（第4至10章从测试角度逐步展开）
同时,需求应当层次分明,需要把单个需求下面的相关需求综合在 一起形成一组需求功能。
需求的可实施性除了可跟踪性还包括可测试性。
ppt课件
29
软件需求评审输出
根据评审专家意见修改后的软件需求规格说明书 软件需求规格说明书评审表格（评审记录表单）
ppt课件
30
第5章 软件测试计划的制定
为何要制定测试计划 怎样设计测试计划 测试计划设计实例 测试计划修改与维护
➢产品需求文档的形成及其实例 ✓产品需求文档PRD ✓PRD如何形成 ✓PRD的主要内容与格式 ✓PRD实例介绍
➢产品需求形成阶段测试工程师需要做什么 ✓阅读PRD中的详细功能需求 ✓给PM反馈信息并协助PM去修改 ✓跟踪提交的问题解决状态
ppt课件
6
软件的需求-需求的定义
IEEE软件工程标准词汇表定义需求为：
软件评审是对软件元素或者项目状态的一种评估手段，以 确定其是否与计划的结果保持一致，并使其得到改进。
ppt课件
15
为什么需要需求评审
1.软件缺陷并不只是在编程阶段才产生，需求和 设计阶段同样会产生缺陷
2.软件测试对需求的依赖
在制定测试计划之前，必须清楚测试需求 明确测试需求的优先级 测试需求分解得越细，对测试用例的设计质量越有帮助 详细的测试需求还是衡量测试覆盖率的重要依据 测试需求是规划具体项目资源和时间的基础。
ppt课件
32
测试计划的定义
ANSI/IEEE把测试计划定义为：
一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。 它确认了测试项。被测特征、测试任务、人员安排以及任何偶发 事件的风险
ppt课件
33
测试计划的定义
ANSI/IEEE把测试计划定义为：
一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。 它确认了测试项。被测特征、测试任务、人员安排以及任何偶发 事件的风险
ppt课件
16
需求评审的重要性
需求评审的重要性：
1. 软件需求是软件开发最重要的一个输入 ，好的开始是成功的一半! 所以，需求的质量很大程度上决定了项目质量或产品质量。
2. 需求风险常常是软件开发过程中最大的一个风险 ，要降低需求阶段 带来的风险，就要把需求评审做好。
3. 需求评审做不好的后果：
需求变更
ppt课件
25
需求规格说明的完整性评审
编写的所有需求，其详细程度是否一致和合适?
需求是否能为设计提供足够的基础?
所有对其他需求的内部引用是否正确?
是否包含了每个需求的实现优先级?
是否定义了功能说明的内在算法?
是否包含了所有已知的客户需求或系统需求?
是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题 (TBD) ?
• “不怕太阳晒，也不怕那风雨狂，只怕先生骂我 笨，没有学问无颜见爹娘 ……”
• “太阳当空照，花儿对我笑，小鸟说早早早……”
ቤተ መጻሕፍቲ ባይዱ
第4章 项目初期各阶段的主要工作
项目立项与拟定产品的发展方向阶段 产品规格说明书制定阶段 产品技术文档设计阶段
ppt课件
5
第4章 项目初期各阶段的主要工作
项目立项与拟定产品的发展方向阶段
明确自己的角色和责任 熟悉评审内容，为评审做好准备 针对问题阐述观点，而非针对个人 从客户角度想问题，多问几个为什么 在会前或会后提出自己建设性的意见 对发现的问题跟踪到底 针对需求文档等报告问题
ppt课件
20
评审的形式
✓ 相互评审、交叉评审：甲和乙在一个项目组，处在一个领域，但工作内容不同，甲的工作成果交给 乙审查，乙的工作成果交给甲审查。相互评审是最不正式的一种评审形式，但应用方便、有效。 ✓ 轮查：又称分配审查方法，是一种异步评审方式。作者将需要评审的内容发送给各位评审员，并收 集他们的反馈意见 ✓ 走查：作者将测试需求在现场向一组同事介绍，以收集大家的意见。希望参与评审的其他同事可以 发现其中的错误，并能进行现场讨论。这种形式介于正式和非正式之间。 ✓ 小组评审：通过正式的小组会议完成评审工作，是有计划的和结构化的评审方式。评审定义了评审 会议中的各种角色和相应的责任，所有参与者在评审会议的前几天就拿到了评审材料，并对该材料进 行了独立研究。 ✓ 审查：审查和小组评审很相似，但更为严格，是最系统化、最严密的评审形式，包含了制定计划、 准备和组织会议、跟踪和分析审查结果等。
◦ 用户解决问题或达到目标所需的条件或能力。 ◦ 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 ◦ 一种反映上面(1)或(2)所描述的条件或能力的文档说明。
Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更 为精练的定义：
◦ 用户解决某一问题或达到某一目标所需的软件功能。 ◦ 系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软
ppt课件
9
需求获取的内容
系统分析人员通过与用户的交流、对现有系统的 观察及对任务进行分析，确定：
系统或产品范围的限制性描述 与系统或产品有关的人员及特征列表 系统的技术环境的描述 系统功能的列表及应用于每个需求的领域限制 一组描述不同运行条件下系统或产品使用状况的应用场景 为更好地定义需求而开发的任意原型。
ppt课件
31
第5章 软件测试计划的制定
为何要制定测试计划
➢可以让项目有条理有计划地进行 ➢可以提前预知项目过程中可能出现的问题 ➢明确测试目标、测试范围和测试重点 ➢明确测试任务和测试方法，保证测试实施过程的顺畅沟通
说明： 测试计划是每一个测试项目组长一定要会写的，并且能准确执行的。 好的测试计划能让测试有条不紊的进行，做到事半功倍。
ppt课件
12
第4章 项目初期各阶段的主要工作
产品技术文档设计阶段
➢编写技术设计文档 ✓什么是产品的技术文档 ✓技术文档中包括哪些内容 ✓技术文档实例介绍
➢技术设计文档阶段测试工程师需要做什么 ✓为测试环境做准备 ✓了解产品的逻辑流程，数据库结构，以及各个模块的具体功能 ✓了解产品设计中的一些技术问题 ✓了解产品的性能，为性能测试作准备
软件生产流程：(本篇重点) 该图能清晰看出软件生产各环节开发与测试的主要工作 学生需要清晰的知道每个英文代表的环节与意义 本书所有章节,以及软件工程师的工作都是围绕本图展开
ppt课件
2
精品资料
• 你怎么称呼老师？
• 如果老师最后没有总结一节课的重点的难点，你 是否会认为老师的教学方法需要改进？
• 你所经历的课堂，是讲座式还是讨论式？ • 教师的教鞭
ppt课件
10
需求获取方法与策略
建立顺畅的通信途径 访谈与调查 观察用户操作流程 组成联合小组
ppt课件
11
第4章 项目初期各阶段的主要工作
产品规格说明书制定阶段
➢产品规格说明书的形成及其实例 ✓产品规格说明书SPEC ✓SPEC如何形成 ✓SPEC的主要内容与格式 ✓SPEC实例介绍
➢产品规格说明书阶段测试工程师需要做什么 ✓阅读并查看SPEC中的功能是否符合PRD要求 ✓和EM保持良好的沟通，并且一起阅读SPEC的详细内容 ✓根据SPEC设计Test Case ✓跟踪SPEC中提出的问题解决状态