《软件过程模型 (2)精品文稿.ppt》由会员分享，可在线阅读，更多相关《软件过程模型 (2)精品文稿.ppt（70页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、软件过程模型第1页，本讲稿共70页上次课的基本知识点回顾上次课的基本知识点回顾传统软件过程模型传统软件过程模型原型模型原型模型螺旋模型螺旋模型喷泉模型喷泉模型现代软件过程模型现代软件过程模型基于构件的开发模型基于构件的开发模型形式化方法模型形式化方法模型第2页，本讲稿共70页如何选择软件过程模型如何选择软件过程模型软件过程模型是不断发展的软件过程模型是不断发展的各种软件过程模型各有优缺点和各种软件过程模型各有优缺点和适用场合适用场合选用时不必拘泥于某种模型选用时不必拘泥于某种模型可组合多种模型可组合多种模型也可根据实际创造新的模型也可根据实际创造新的模型第3页，本讲稿共70页应用举例应用举例v
2、开发一个类似于开发一个类似于Word的字处理软件。的字处理软件。迭代迭代1：提供基本的文件管理、编辑和文档生成功能。：提供基本的文件管理、编辑和文档生成功能。迭代迭代2：提供高级的文档编辑功能。：提供高级的文档编辑功能。迭代迭代3：实现拼写和语法检查功能。：实现拼写和语法检查功能。迭代迭代4：完成高级的页面排版功能：完成高级的页面排版功能。第4页，本讲稿共70页应用举例应用举例v应用举例：开发一个教务管理系统。应用举例：开发一个教务管理系统。第一次迭代：完成基本的学籍管理、选课和成绩管理功能。第一次迭代：完成基本的学籍管理、选课和成绩管理功能。（6周）周）客户反馈：基本满意，但是对大数据量运行
3、速度慢效率，不客户反馈：基本满意，但是对大数据量运行速度慢效率，不需要学生自己维护学籍的功能等。需要学生自己维护学籍的功能等。第二次迭代：修改细节，提高成绩统计和报表执行效率（第二次迭代：修改细节，提高成绩统计和报表执行效率（2周）。周）。客户反馈：需要严格的权限控制，报表打印格式不符合要求。客户反馈：需要严格的权限控制，报表打印格式不符合要求。第三次迭代：完善打印和权限控制功能。（第三次迭代：完善打印和权限控制功能。（2周）周）客户反馈：可以进行正式应用验证。客户反馈：可以进行正式应用验证。第5页，本讲稿共70页面向方面的软件开发面向方面的软件开发随着现代计算机系统变得更加复杂，随着现代计算
4、机系统变得更加复杂，某些关注点某些关注点客客户需要的属性或技术兴趣点户需要的属性或技术兴趣点已经体现在整个架构设计已经体现在整个架构设计中。某些关注点是系统的高层属性（例如安全性、容错能力），中。某些关注点是系统的高层属性（例如安全性、容错能力），某些关注点影响了系统的功能等。某些关注点影响了系统的功能等。如果某个关注点涉及系统多个方面的功能、特性和信如果某个关注点涉及系统多个方面的功能、特性和信息，这些关注点通常称为息，这些关注点通常称为横切关注点横切关注点。第6页，本讲稿共70页面向方面的软件开发面向方面的软件开发方面需求定义那些对整个软件体系结构产生影响的横切关注点。方面需求定义那些对整
5、个软件体系结构产生影响的横切关注点。面向方面的软件开发（面向方面的软件开发（AOSDAOSD）通常称为面向方面编程）通常称为面向方面编程（AOPAOP），为定义、说明、设计和构建方面提供过程和方），为定义、说明、设计和构建方面提供过程和方法，是对横切关注点局部表示的一种机制，超越了子程序法，是对横切关注点局部表示的一种机制，超越了子程序和继承的方法。和继承的方法。第7页，本讲稿共70页面向方面的构件工程(AOCE)AOCEAOCE对纵向分解的软件构件进行横向切片，称为对纵向分解的软件构件进行横向切片，称为“方面方面”，以表示构件功能及非功能的横切属性。以表示构件功能及非功能的横切属性。系统的方
6、面包括用户接口、协同工作、发布、持续性、存系统的方面包括用户接口、协同工作、发布、持续性、存储器管理、事务处理、安全、完整性等。储器管理、事务处理、安全、完整性等。构件也许提供或需要某一方面的构件也许提供或需要某一方面的“方面细节信息方面细节信息”，如视，如视图机制、可扩展性和接口类型（用户接口方面）；事件生图机制、可扩展性和接口类型（用户接口方面）；事件生成、传输和接收（分布式方面）；数据存取成、传输和接收（分布式方面）；数据存取/查询和索引查询和索引（持久性方面）；认证、编码和访问权限（安全方面）；（持久性方面）；认证、编码和访问权限（安全方面）；原子事务、协同控制和登录策略（事务方面）等
7、。原子事务、协同控制和登录策略（事务方面）等。第8页，本讲稿共70页RationalRational统一过程统一过程Unified Process(UP)以用例驱动、以架构为核心，迭代增量模型的软件过以用例驱动、以架构为核心，迭代增量模型的软件过程程描述了如何为软件开发团队有效的部署经过商业化验证的软件描述了如何为软件开发团队有效的部署经过商业化验证的软件开发方法。它们被称为开发方法。它们被称为“最佳实践最佳实践”，UP为每个团队成员提为每个团队成员提供了必要准则、模板和工具指导。供了必要准则、模板和工具指导。获得广泛使用获得广泛使用基于面向对象方法学基于面向对象方法学使用统一建模语言使用统一
8、建模语言UMLUML第9页，本讲稿共70页统一过程的三个特点统一过程的三个特点用例驱动用例驱动所有的软件开发都是用户需求驱动的。所有的软件开发都是用户需求驱动的。UP采用用例来描述采用用例来描述用户需求，同时提供一套方法把用例转化为设计的类用户需求，同时提供一套方法把用例转化为设计的类图，进一步变成最终的程序代码。在整个软件开发过图，进一步变成最终的程序代码。在整个软件开发过程中，要求用例是可跟踪的，即在设计和实现阶段，程中，要求用例是可跟踪的，即在设计和实现阶段，都可以找到相应的需求。都可以找到相应的需求。以架构为核心以架构为核心架构刻画了系统的整体设计，舍弃细节，突出重要特征。架构刻画了系
9、统的整体设计，舍弃细节，突出重要特征。UP提供了创建架构的方法和过程。提供了创建架构的方法和过程。第10页，本讲稿共70页统一过程的三个特点统一过程的三个特点UP采用迭代和增量的开发模式，把一个软件产品划分成多采用迭代和增量的开发模式，把一个软件产品划分成多个较小的部分，每次完成一个部分，每次迭代都是产品的个较小的部分，每次完成一个部分，每次迭代都是产品的一个增量。一个增量。优点：把一个复杂系统分解成多个简单系统，提供软优点：把一个复杂系统分解成多个简单系统，提供软件项目的可控性，降低软件开发的风险，有效的应对件项目的可控性，降低软件开发的风险，有效的应对需求变更。需求变更。第11页，本讲稿共
10、70页UPUP起源起源v面向对象面向对象 60年代年代 Alan Kay发明发明OO语言语言 Smalltalk和面向对象编程和面向对象编程（Object-Orientedprogramming,OOP）1982年年Grady Booch提出面向对象设计（提出面向对象设计（Object-Oriented Design,OOD）80年代末，年代末，Peter Coad创建完整的创建完整的OOA/D方法方法v 三剑客及其建模方法三剑客及其建模方法 James Rumbaugh提出了提出了OMT方法方法 Grady Booch提出了提出了Booch方法方法 Ivar Jacobson提出了提出了Ob
11、jectory（Object Factory）方法）方法第12页，本讲稿共70页UP起源起源UML 1994年年James Rumbaugh和和Grady Booch创建了统一方法创建了统一方法（Unified Method），即），即UML第一个草案第一个草案 三人加入三人加入Rational公司（后被公司（后被IBM收购），领导了收购），领导了OMG的建的建模标准制定模标准制定 1997年年UML1.0发布，发布，2004年年UML2.0发布，成为发布，成为OO建模标建模标准准第13页，本讲稿共70页UP起源起源UP历史第14页，本讲稿共70页RationalRational统一过程统一过
12、程从从3 3个视角描述软件开发过程个视角描述软件开发过程动态视角动态视角：随时间变化的各个阶段：随时间变化的各个阶段静态视角静态视角：所进行的活动：所进行的活动实践视角实践视角：可采用的良好实践建议：可采用的良好实践建议第15页，本讲稿共70页RationalRational统一过程统一过程初始初始：项目计划、：项目计划、评估风险；评估风险；精化精化：设计系统：设计系统的体系结构、制的体系结构、制定项目计划、确定项目计划、确定资源需求；定资源需求；构建构建：开发出所：开发出所有组件和应用有组件和应用程序，集成并程序，集成并进行详尽测试；进行详尽测试；产品化产品化：将产品：将产品移交给用户。移交
13、给用户。动态视角动态视角静静态态视视角角第16页，本讲稿共70页统一过程的最佳实践准则统一过程的最佳实践准则实践视角：实践视角：6 6条最佳实践条最佳实践1.1.迭代式开发迭代式开发需求变更不可避免需求变更不可避免每次迭代产生一个可交付版本，用户反馈，减少风险每次迭代产生一个可交付版本，用户反馈，减少风险根据客户的轻重缓急来规划增量，先开发和交付优先级最高的根据客户的轻重缓急来规划增量，先开发和交付优先级最高的增量增量2.2.管理需求管理需求采用采用用例用例分析来捕获需求，由用例驱动设计和实现分析来捕获需求，由用例驱动设计和实现对需求及其变更进行管理对需求及其变更进行管理第17页，本讲稿共70
14、页3.3.使用基于构件的体系结构使用基于构件的体系结构将体系结构组建成基于构件的将体系结构组建成基于构件的提高软件复用率提高软件复用率4.4.可视化建模可视化建模使用统一建模语言（使用统一建模语言（UMLUML）对系统进行可视化建模）对系统进行可视化建模5.5.验证软件质量验证软件质量软件质量评估贯穿于整个开发过程的所有活动中软件质量评估贯穿于整个开发过程的所有活动中全体成员参与全体成员参与6.6.控制软件变更控制软件变更描述了如何控制和跟踪软件的变更描述了如何控制和跟踪软件的变更统一过程的最佳实践准则统一过程的最佳实践准则第18页，本讲稿共70页RationalRational统一过程统一过
15、程初始初始：项目计划、：项目计划、评估风险；评估风险；精化精化：设计系统：设计系统的体系结构、制定的体系结构、制定项目计划、确定资项目计划、确定资源需求；源需求；构建构建：开发出所：开发出所有组件和应用有组件和应用程序，集成并程序，集成并进行详尽测试；进行详尽测试；产品化产品化：将产品：将产品移交给用户。移交给用户。动态视角动态视角静静态态视视角角第19页，本讲稿共70页v起始阶段起始阶段(inception)：沟通、策划沟通、策划包括客户包括客户沟通和策划沟通和策划活动。该阶段识别基本的业务需求，并初活动。该阶段识别基本的业务需求，并初步用步用“用例用例”描述每一类描述每一类用户所需要的主要
16、特征和功能用户所需要的主要特征和功能。此时。此时的架构仅是主要子系统及其功能、特性的试探性概括。策的架构仅是主要子系统及其功能、特性的试探性概括。策划活动识别各种资源，评估主要风险，定义进度计划，并划活动识别各种资源，评估主要风险，定义进度计划，并为用于软件增量开发的各个阶段建立基础。为用于软件增量开发的各个阶段建立基础。统一过程的阶段统一过程的阶段第20页，本讲稿共70页统一过程的阶段统一过程的阶段v细化阶段细化阶段(elaboration)策划、建模策划、建模包括用户沟通和通过过程模型的建模活动。该阶段扩展了包括用户沟通和通过过程模型的建模活动。该阶段扩展了起始阶段定义的用例，并扩展体系结
17、构以包括软件的五种视起始阶段定义的用例，并扩展体系结构以包括软件的五种视图图用例模型、分析模型、设计模型、实现模型和部署模用例模型、分析模型、设计模型、实现模型和部署模型型。体系结构基线证明了体系结构的可实现性，但没有提供体系结构基线证明了体系结构的可实现性，但没有提供系统使用所需的所有功能和特性。另外，在细化的最终阶段系统使用所需的所有功能和特性。另外，在细化的最终阶段将评审项目计划以确保项目的范围、风险和交付日期合理。将评审项目计划以确保项目的范围、风险和交付日期合理。同时对项目计划进行修订。同时对项目计划进行修订。第21页，本讲稿共70页统一过程的阶段统一过程的阶段v构建阶段构建阶段(c
18、onstruction)：部署部署与通用软件过程中的构建活动相同。该阶段采用体系结构与通用软件过程中的构建活动相同。该阶段采用体系结构模型作为输入，开发或获取软件构件，使得最终用户能够操模型作为输入，开发或获取软件构件，使得最终用户能够操作用例。作用例。v转换阶段转换阶段(transition):构建、部署构建、部署包括通用构建活动的后期阶段以及第一部分通用部署活动。包括通用构建活动的后期阶段以及第一部分通用部署活动。软件被提交给最终用户进行软件被提交给最终用户进行Beta测试，用户反馈缺陷及必要测试，用户反馈缺陷及必要的变更。另外，软件开发团队创建系统发布所必要的支持信的变更。另外，软件开发
19、团队创建系统发布所必要的支持信息。息。第22页，本讲稿共70页统一过程的阶段统一过程的阶段v生产阶段生产阶段(production)：发布发布与通用过程的部署活动一致。在该阶段，监控软件的持续与通用过程的部署活动一致。在该阶段，监控软件的持续使用，提供运行环境的支持，提交并评估缺陷报告和变更请使用，提供运行环境的支持，提交并评估缺陷报告和变更请求。求。一个软件工程的工作流分布在所有一个软件工程的工作流分布在所有UP阶段。阶段。第23页，本讲稿共70页统一过程工作产品统一过程工作产品UP每一个阶段产生的主要工作产品第24页，本讲稿共70页产品与过程产品与过程如果过程很薄弱，最终产品必将受到影响。
20、但是对过程如果过程很薄弱，最终产品必将受到影响。但是对过程的过于依赖也是很危险的。的过于依赖也是很危险的。第25页，本讲稿共70页RationalRational统一过程统一过程适用场合适用场合适合大团队大项目。适合大团队大项目。第26页，本讲稿共70页敏捷软件开发敏捷软件开发Agile software developmentAgile software development高效工作、快速响应变化高效工作、快速响应变化20012001年年2 2月，月，1717位编程大师发表位编程大师发表敏捷软件开发宣言敏捷软件开发宣言个体和交互个体和交互胜过过程和工具胜过过程和工具可以工作的软件可以工作的
21、软件胜过面面俱到的文档胜过面面俱到的文档客户合作客户合作胜过合同谈判胜过合同谈判响应变化响应变化胜过遵循计划胜过遵循计划虽然右边的项有价值，但我们更重视左边的项虽然右边的项有价值，但我们更重视左边的项敏捷敏捷Agility第27页，本讲稿共70页敏捷软件开发的基本原则敏捷软件开发的基本原则客户参与到开发团队中客户参与到开发团队中确定系统需求、对需求排确定系统需求、对需求排序、评估系统等序、评估系统等软件以增量的方式进行开软件以增量的方式进行开发和交付发和交付开发团队的技术和开发团开发团队的技术和开发团队的风格应得到认可队的风格应得到认可接受变更，设计软件适应接受变更，设计软件适应变更变更保持所
22、开发软件和开发过保持所开发软件和开发过程的简单性程的简单性实践中的困难实践中的困难客户不一定愿意参与到开客户不一定愿意参与到开发团队中发团队中团队成员的性格团队成员的性格需求和变更的优先级不容需求和变更的优先级不容易确定易确定维护简单性需要额外的时间维护简单性需要额外的时间企业文化很难改变企业文化很难改变第28页，本讲稿共70页敏捷开发方法敏捷开发方法极限编程：极限编程：eXtreme Programming/XPeXtreme Programming/XP自适应软件开发自适应软件开发Adaptive Software Development/ASDAdaptive Software Deve
23、lopment/ASD并列争球法：并列争球法：ScrumScrum动态系统开发方法动态系统开发方法Dynamic System Development Method/DSDMDynamic System Development Method/DSDM水晶法：水晶法：CrystalCrystal特征驱动开发：特征驱动开发：Feature-Driven Development/FDDFeature-Driven Development/FDD精益软件开发：精益软件开发：Lean Software Development/LSDLean Software Development/LSD扩展扩展内容内
24、容第29页，本讲稿共70页极限编程极限编程eXtreme Programming XPeXtreme Programming XP把好的开发实践运用到极致把好的开发实践运用到极致为当前版本选择故事情节/需求（Scenario）将故事情节分解成任务规划版本开发/集成/测试软件发布软件评估系统结对编程先写测试用例再编程第30页，本讲稿共70页极限编程极限编程XPvXPXP使用面向对象方法作为推荐的开发范型。使用面向对象方法作为推荐的开发范型。XPXP包包含了含了策划、设计、编码和测试策划、设计、编码和测试4 4个框架活动个框架活动的规则和实践。的规则和实践。如图如图3-23-2所示。所示。第31页
25、，本讲稿共70页极限编程极限编程课本图3-2 极限编程过程第32页，本讲稿共70页极限编程的过程极限编程的过程v策划策划：策划活动开始于建立一系列描述待开发软件必要特：策划活动开始于建立一系列描述待开发软件必要特征与功能的征与功能的“故事故事”。v每个故事由客户书写并置于一张索引卡上，客户根据对应特征或功能每个故事由客户书写并置于一张索引卡上，客户根据对应特征或功能的全局业务价值度标明权值（故事优先级）；的全局业务价值度标明权值（故事优先级）；v评估每个故事给出开发周数为单位的成本；评估每个故事给出开发周数为单位的成本；v客户和团队共同决定故事分组；客户和团队共同决定故事分组；v团队对待开发故
26、事进行排序团队对待开发故事进行排序v团队计算项目的速度团队计算项目的速度v在开发过程中，用户可增加、减少故事数，以及改变故事的优先级。在开发过程中，用户可增加、减少故事数，以及改变故事的优先级。第33页，本讲稿共70页极限编程的过程极限编程的过程v设计设计：XPXP设计严格遵循设计严格遵循KISKIS原则，即使用简单而不是复原则，即使用简单而不是复杂的表述。另外，设计为故事提供不多也不少的实现杂的表述。另外，设计为故事提供不多也不少的实现原则，不鼓励额外功能性设计。原则，不鼓励额外功能性设计。v鼓励使用鼓励使用CRCCRC卡（类卡（类-责任责任-协作者）确定和组织与当前软协作者）确定和组织与当
27、前软件增量相关的类；件增量相关的类；v如果某个故事的设计中遇到困难，采用如果某个故事的设计中遇到困难，采用SpikeSpike方案；方案；v鼓励重构鼓励重构vXPXP的中心观念是设计与编码可以同时进行。的中心观念是设计与编码可以同时进行。第34页，本讲稿共70页极限编程的过程v编码编码：XP推荐的故事开发和基本设计完成之后，团队不应直接开始编码，而是开发一系列用于检测本次（软件增量）发布的包括所有故事的单元测试。XP编码活动中的关键概念之一是结对编程结对编程。vXP建议两个人共同为一个故事开发代码，提供实时解决问题和实时保证质量。第35页，本讲稿共70页极限编程的过程v测试测试：在编码开始之前
28、建立单元测试是XP方法的关键因素。所建立的单元测试应当使用一个可以自动实施的框架，这种方式支持代码修改之后即时的回归测试策略。v一旦将个人的单元测试组织到一个“通用测试集”，每天都可以进行系统的集成和确认测试。vXP验收测试，也称为客户测试，则客户规定技术条件，并且着眼于客户可见的、可评审的系统级的特征和功能。第36页，本讲稿共70页极限编程的有效实践极限编程的有效实践增量式开发增量式开发小版本短周期交付小版本短周期交付结对编程结对编程代码集体所有代码集体所有开放的工作空间开放的工作空间可持续的开发速度：可持续的开发速度：4040小小时时/周，连续加班不超过两周，连续加班不超过两周周简单的设计
29、简单的设计测试驱动开发测试驱动开发持续集成持续集成重构重构及时调整计划及时调整计划客户作为开发团队成员客户作为开发团队成员第37页，本讲稿共70页敏捷开发的优点和缺点敏捷开发的优点和缺点优点：优点：对变化和不确定性有更快速更敏捷的反应对变化和不确定性有更快速更敏捷的反应在快速的同时保持可持续的开发速度在快速的同时保持可持续的开发速度能较好的地适应商业竞争环境下对小项目提出的有限资源和能较好的地适应商业竞争环境下对小项目提出的有限资源和有限开发时间的约束有限开发时间的约束缺点：缺点：极限编程中的测试驱动开发可能会导致系统通过了测试但不极限编程中的测试驱动开发可能会导致系统通过了测试但不是用户期望
30、的是用户期望的重构而不降低系统体系结构的质量是困难的重构而不降低系统体系结构的质量是困难的用于大型项目有很多问题用于大型项目有很多问题第38页，本讲稿共70页敏捷开发实例敏捷开发实例在敏捷软件开发中，测试人员的职责有三个主要方面：在敏捷软件开发中，测试人员的职责有三个主要方面：定义质量定义质量(Define Quality)交流缺陷（交流缺陷（Communication）及时反馈及时反馈(Feedback)我们的测试框架提供自助测试我们的测试框架提供自助测试(Self-assistant Test)：通：通过点击测试用例列表中的某个具体用例，开发人员不需要中过点击测试用例列表中的某个具体用例，
31、开发人员不需要中断测试人员的工作就可以重现缺陷。断测试人员的工作就可以重现缺陷。第39页，本讲稿共70页敏捷开发中的测试流程敏捷开发中的测试流程结合一个软件项目，详细介绍项目流程中的主要测试活动，每个活动的前提条件和目标任务等。项目介绍：根据一家在线项目介绍：根据一家在线 B2B 公司的要求，我们将公司的要求，我们将为其开发一款类似于谷歌的搜索服务。作为为其开发一款类似于谷歌的搜索服务。作为 Web Service，该服务可以内嵌于网页中。当用户输入关，该服务可以内嵌于网页中。当用户输入关键词并选择商户的类型和位置后，系统会返回具体键词并选择商户的类型和位置后，系统会返回具体商户的列表商户的列
32、表第40页，本讲稿共70页典型的敏捷开发和测试活动典型的敏捷开发和测试活动主主要要由由三三部部分分构构成成，从从最最初初的的用用户户故故事事设设计计和和发发布布计计划划，到到几几次次 Sprint 周周期期的的迭迭代代开开发发和和测测试试，以以及及最最后后的的产产品品发发布布阶阶段段。每每个个时时间间段段都都有有相相应应的的测测试试活活动动。通通常常 Sprint 周周期期被被分分成成两两类类：特特征征周周期期（Feature Sprint）和和发发布布周周期期（Release Sprint）。特特征征周周期期主主要要涉涉及及新新功功能能的的开开发发和和各各类类测测试试。发发布布周周期期则则会
33、会结结合合计计划划，确确定定新新版版本本功功能能，然后对最新的功能进行测试。，然后对最新的功能进行测试。第41页，本讲稿共70页典型的敏捷开发和测试活动典型的敏捷开发和测试活动敏捷开发的主要活动敏捷开发的主要活动 测试活动测试活动用户故事设计用户故事设计寻找隐藏的假设寻找隐藏的假设发布计划发布计划设计概要的验收测试设计概要的验收测试用例用例迭代迭代 Sprint估算验收测试时间估算验收测试时间编码和单元测试编码和单元测试估算测试框架的搭建估算测试框架的搭建重构重构详细设计验收测试用详细设计验收测试用例例集成集成编写验收测试用例编写验收测试用例执行验收测试执行验收测试重构验收测试重构验收测试Sp
34、rint 结束结束执行验收测试执行验收测试下一个下一个 Sprint 开始开始执行回归测试执行回归测试发布发布发布发布第42页，本讲稿共70页典型的敏捷开发和测试活动典型的敏捷开发和测试活动在在迭迭代代的的 Sprint 周周期期中中，开开发发部部分分可可以以根根据据传传统统步步骤骤分分成成编编码码和和单单元元测测试试、重重构构和和集集成成。需需要要指指出出的的是是，重重构构和和集集成成是是敏敏捷捷开开发发的的 Sprint 迭迭代代中中不不可可忽忽视视的的任任务务。如如果果在在新新的的 Sprint 周周期期中中要要对对上上次次的的功功能能加加以以优优化化和和改改进进，必必然然离离不开重构和
35、集成。不开重构和集成。在在每每个个 Sprint 周周期期结结束束前前，测测试试团团队队将将提提交交针针对对该该 Sprint 周周期期或或者者上上个个 Sprint 周周期期中中已已完完成成的的功功能能的的验验收收测测试试（在在实实际际项项目目中中，测测试试团团队队的的进进度度通通常常会会晚晚于于开开发发团团队队）。这这样样一一来来，开开发发团团队队可可以以运运行行验验收收测测试试来来验验证证所所开开发发的的功功能能目目前前是是否否符符合合预预期期。当当然然，这这个个预预期期也也是是在在迭迭代代中中不不断断变变化和完善的。化和完善的。当当产产品品的的所所有有功功能能得得以以实实现现，测测试试
36、工工作作基基本本结结束束后后，就就进进入了发布周期。此时，测试团队的任务相对较多。入了发布周期。此时，测试团队的任务相对较多。第43页，本讲稿共70页用户故事设计和发布计划阶段用户故事设计和发布计划阶段在用户故事和发布计划阶段，项目经理和产品经理会根在用户故事和发布计划阶段，项目经理和产品经理会根据客户的需求，制定概要的产品发布日程计划。此时，据客户的需求，制定概要的产品发布日程计划。此时，测试人员可以和开发人员一起学习新的功能，了解客户测试人员可以和开发人员一起学习新的功能，了解客户的需求。其中，有两个主要活动：寻找隐藏的假设和设的需求。其中，有两个主要活动：寻找隐藏的假设和设计概要的验收测
37、试用例。计概要的验收测试用例。下面我们将对各阶段相应的测试活动作详细的介绍和分下面我们将对各阶段相应的测试活动作详细的介绍和分析析第44页，本讲稿共70页用户故事设计和发布计划阶段用户故事设计和发布计划阶段1、寻找隐藏的假设、寻找隐藏的假设 开开发发人人员员通通常常关关注注一一些些重重要要的的系系统统功功能能而而忽忽视视细细节节。此此外外，敏敏捷捷开开发发倡倡导导简简单单的的实实现现方方案案，每每个个开开发发 Sprint 周周期期不不可可能能将将功功能能完完美美得得实实现现；相相反反，每每个个 Sprint 都都会会增增量量得得开开发发一一些些功功能能。所所以以，测测试试人人员员在在最最初初
38、就就需需要要从从各各种种角度来寻找系统需求，探索隐藏的假设。角度来寻找系统需求，探索隐藏的假设。第45页，本讲稿共70页用户故事设计和发布计划阶段用户故事设计和发布计划阶段项目实例：项目实例：从在线从在线 B2B 公司角度思考公司角度思考Q：这个搜索框对公司的业务有什么价值？：这个搜索框对公司的业务有什么价值？A：搜索框可以为用户方便得提供商户的目录信息。如果越来：搜索框可以为用户方便得提供商户的目录信息。如果越来越多用户使用这个搜索框，可以增加我们网站的访问量。越多用户使用这个搜索框，可以增加我们网站的访问量。从用户角度思考从用户角度思考Q：作为查询信息、寻找商业合作伙伴的网站用户，搜索框对
39、：作为查询信息、寻找商业合作伙伴的网站用户，搜索框对我有什么好处？我有什么好处？A：坏处：找到一家商户的地址，过去才发现已经关门歇业好：坏处：找到一家商户的地址，过去才发现已经关门歇业好处：查找商户很简单，只要轻点鼠标处：查找商户很简单，只要轻点鼠标不快：有时候在寻找一类商户，却记不清楚具体名字不快：有时候在寻找一类商户，却记不清楚具体名字第46页，本讲稿共70页用户故事设计和发布计划阶段用户故事设计和发布计划阶段项目实例：项目实例：从程序员角度思考从程序员角度思考Q：一个搜索框的最简单实现方法是什么？：一个搜索框的最简单实现方法是什么？A：一个有：一个有 text input 和和 sear
40、ch button 组成的组成的 form；后台通；后台通过过 server 程序将符合类型和地址的商户名从数据库中取出，程序将符合类型和地址的商户名从数据库中取出，返回给用户；每个返回项包括商户的名称、地址和评价意见。返回给用户；每个返回项包括商户的名称、地址和评价意见。寻找这些观点中的问题寻找这些观点中的问题Q：搜索框如何在用户忘记具体名字的时候提醒用户？：搜索框如何在用户忘记具体名字的时候提醒用户？A：在第一版本中实现比较困难。可以让用户输入至少一个类：在第一版本中实现比较困难。可以让用户输入至少一个类型来提高模糊查找的效果。最后寻找到隐藏的假设型来提高模糊查找的效果。最后寻找到隐藏的假
41、设第47页，本讲稿共70页用户故事设计和发布计划阶段用户故事设计和发布计划阶段让测试人员对系统的隐含假设更加清晰让测试人员对系统的隐含假设更加清晰首先，系统应该能够在高峰时候处理首先，系统应该能够在高峰时候处理 200 条搜索请求和条搜索请求和 1000 个鼠标点击事件。个鼠标点击事件。其次，用户可以在已经查找到的内容中继续查找其次，用户可以在已经查找到的内容中继续查找最后，系统提供一个商户类别清单；如果用户选择商户类最后，系统提供一个商户类别清单；如果用户选择商户类别而忘记具体名字，系统提供模糊查询。别而忘记具体名字，系统提供模糊查询。第48页，本讲稿共70页用户故事设计和发布计划阶段用户故
42、事设计和发布计划阶段3.2.2 设计概要的验收测试用例设计概要的验收测试用例定义完一系列用户故事后，测试人员就可以定义完一系列用户故事后，测试人员就可以着手设计概要的着手设计概要的验收测试用例验收测试用例。不同于单元测试，验收测试检查系统是否满。不同于单元测试，验收测试检查系统是否满足客户的预期，也就是用户故事是否能够实现。于是，测试足客户的预期，也就是用户故事是否能够实现。于是，测试人员可以根据每条用户故事来扩展，寻找其中的人员可以根据每条用户故事来扩展，寻找其中的“动作动作”，然后为每条然后为每条“动作动作”制定正例和反例。制定正例和反例。动作动作数据数据期待的结果期待的结果搜索搜索一组能
43、成功搜索到的（类一组能成功搜索到的（类别，位置）数据别，位置）数据在该类别和位置条件在该类别和位置条件下的一组商户信息下的一组商户信息搜索搜索一组不能成功搜索到的一组不能成功搜索到的（类别，位置）数据（类别，位置）数据空列表空列表项目实例：项目实例：第49页，本讲稿共70页用户故事设计和发布计划阶段用户故事设计和发布计划阶段3.3 迭代迭代 Sprint 阶段阶段当一个 Sprint 周期正式开始时，项目经理将制定该周期的具体开发和测试任务开发和测试任务。在定期的 Sprint 计划会议（Planning Meeting）上，每位团队成员都要提供自己在未来一个 Sprint 周期中的休假和培训
44、计划。另外，每个团队可以根据各自团队成员的能力和工作经验，适当设定一个工作负载值（Load Factor）。比如，我们团队的工作负载值为 75%，也就是说每个人平均每天工作 6 小时（以 8 小时计算）。接着，大家就可以开始分配任务。第50页，本讲稿共70页用户故事设计和发布计划阶段用户故事设计和发布计划阶段3.3 迭代迭代 Sprint 阶段阶段当开发团队开始编码和单元测试时，测试人员的工作重点包括：估算验收测试的时间、估算测试框架的搭建、详细估算验收测试的时间、估算测试框架的搭建、详细设计验收测试和编写验收测试代码设计验收测试和编写验收测试代码。第两个主要活动一般在项目初期的 Sprint
45、 周期中完成。其他的三个主要活动将在接下来的多个 Sprint 周期中视情况迭代进行。下面我们将具体介绍每个主要活动。第51页，本讲稿共70页用户故事设计和发布计划阶段用户故事设计和发布计划阶段3.3.1 估算验收测试时间估算验收测试时间在软件开发初期，需要估算时间以制定计划。这一点在敏捷开发中应用更加广泛。如果以前的开发模式需要测试人员估算一个软件版本发行的计划（这样的计划通常会延续几个月），那么现在则要在每个 Sprint 机会会议上估算两周到一个月的任务。此外，在每天的站立会议上，测试人员需要不断得更新自己的估算时间，以应对变化的需求。所以，每个测试人员都应该具备一定的估算任务能力。下面
46、我们将介绍一个通用的估算测试计划的方法：第52页，本讲稿共70页用户故事设计和发布计划阶段用户故事设计和发布计划阶段快速而粗糙的方法从经验而言，测试通常占项目开发的三分之一时间。如果一个项目开发估计要 30 天 1 人，那么测试时间为 10 天 1 人。项目实例：项目实例：搜索框的开发估计需要 78 天 1 人完成。但是，考虑到系统有模糊搜索的功能，所以测试任务可能会占 40左右，大概 31 天 1 人。下面列出了具体的任务：第53页，本讲稿共70页用户故事设计和发布计划阶段用户故事设计和发布计划阶段任务任务估计时间估计时间设计测试用例，准备测试数据（搜索数据集）设计测试用例，准备测试数据（搜
47、索数据集）8加载数据集加载数据集2编写自动测试代码编写自动测试代码18执行测试和汇报结果执行测试和汇报结果3总结总结31第54页，本讲稿共70页用户故事设计和发布计划阶段用户故事设计和发布计划阶段3.3.2 估算测试框架的搭建估算测试框架的搭建测试框架是自动测试必不可少的一部分工作。由于敏捷开发流程倡导快速而高效得完成任务，这就要求一定的自动测试率。一个完善的测试框架可以大大提高测试效率，及时反馈产品的质量。在敏捷开发流程中，在第一个 Sprint 周期里，需要增加一项建立测试框架的任务。在随后的迭代过程中，只有当测试框架需要大幅度调整时，测试团队才需要考虑将其单独作为任务，否则可以不用作为主
48、要任务罗列出来。第55页，本讲稿共70页用户故事设计和发布计划阶段用户故事设计和发布计划阶段项目实例：项目实例：考虑该项目刚刚进入测试，需要为此建立一个测试框架。于是，在原先的估算中多增加一些任务。任务估算选择测试工具3建立测试系统3编写下载、存放和恢复测试数据的脚本2寻找或建立测试结果汇报工具8设计具体的搜索测试用例4准备搜索测试数据4编写和测试“搜索”模块3编写和测试“验证返回列表”的模块1学习“在结果中搜索”的模块设计4编写和测试“在结果中搜索”模块4第一次执行测试4分析第一轮测试结果4第二次执行测试4分析第二轮测试结果4总共52第56页，本讲稿共70页用户故事设计和发布计划阶段用户故事
49、设计和发布计划阶段3.3.3 详细设计验收测试用例详细设计验收测试用例完成对测试任务的估算，接着就可以着手详细设计验收测试用例。我们可以对概要设计中的测试用例进行细化，根据不同的测试环境、测试数据以及测试结果，编写更详细的测试用例。另外，可以结合几个用例，完成一个复杂的测试操作。第57页，本讲稿共70页用户故事设计和发布计划阶段用户故事设计和发布计划阶段由于敏捷开发的流程是不断迭代的过程，所以很多复杂的功能可能会在未来的 Sprint 周期中被优化。对测试人员而言，一个有效的方法是尽量将一些验证基本功 能 的 测 试 用 例 作 为 基 本 验 证 测 试 用 例（Basic Verifica
50、tion Test Case）在第一时间实现自动化；而对一些复杂的功能测试用例，可以先采用手工的方法测试，直到在未来 Sprint 周期中该功能达到稳定时候再考虑自动化。此外，对测试中出现的缺陷可以设计回归测试用例（Regression Test Case），为其编写自动测试代码，使得此类问题在发布周期（Release Sprint）时可以顺利而高效得进行验证。第58页，本讲稿共70页用户故事设计和发布计划阶段用户故事设计和发布计划阶段动作数据期待的结果登录用户名：（空）密码：（空）“用户名和密码无效”动作数据期待的结果登录正确的用户名和密码进入系统：请输入搜索条件并点击“搜索”按钮搜索错误的