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