四川大学软件工程课程复习总结

1、Chapter 1: TheNatureofSoftware1. SoftwareDefinitionofsoftware计算机软件=程序+数据Z构+文档程序：指令的集合，通过执行这些指令可以满足预期的特征、功能和性能需求；数据结构：使得程序可以合理利用信息；文档：软件描述信息，用来描述程序操作和使用CharacteristicsofSoftware1、软件是设计开发的，而不是传统意义上生产制造的。2、软件不会“磨损”。3、虽然整个工业向着基于构件的构造模式发展，然而大多数软件仍是根据实际的顾客需求定制的。Thedifferenceofsoftwareandhardware一、软件是一种逻辑的

2、产品，与硬件产品有本质的区别二、软件产品质量的体现方式与硬件产品不同三、软件产品的成本构成与硬件产品不同四、软件产品的失败曲线与硬件产品不同五、大多数软件任然是定制产生的2. ThechangingnatureofsoftwareChapter 2: SoftwareEngineering1.Softwareengineering一alayeredtechnology:ThedefinitionofSoftwareengineering运用系统的、规范的、可量化的方法开发、运行和维护软件，即将工程化的方法运用到软件开发中。ThegoalofSoftwareengineering软件工程的目标是

3、：在给定成本、进度的前提下，开发出具有可修改性、有效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操作性并满足用户需求的软件产品。Layer:tools,methods,processandaqualityfocus软件工程是一种层次化的技术。软件工程的根基在于质量关注点；软件过程构成了软件项目管理控制的基础；软件工程方法为构建软件提供技术上的解决方法；软件工程工具为过程和方法提供自动化或半自动化支持。一工具tool方法method_、过程口rocess一一质量关注点auditv-fbcws2. AprocessframeworkThegenericfivepro

4、cessactivities:communication,planning,modeling,constructionanddeployment软件过程框架(processframework)的5个活动：沟通Communication:与客户(及其他利益相关者)的沟通协调。策划Planning:制定软件项目计划书。建卞HModeling:绘制项目体系架构，利用模型理解软件需求。构建Construction:编码和测试。部署Deployment:软件交付，用户测评。3. SoftwaredevelopmentmythsChapter 3: SoftwareProcessStructure1. P

5、rescriptivemodelsThefunctionofprocessmodelsUnderstandthesignificationandcharacteristicsoftheprocessmodelsProcessmodel,Pattern,Framework2. Thewaterfallmodel瀑布模型采用线性工作流方式，适用于可以清楚地了解问题需求的软件项目。:通虏i沟。*嗅*>象期孽fl陆器星反针型自隈在密新柄齿司瀑布棋型Vcyclemodel适合与需求清楚、熟悉的系统V模型是是瀑布模型的一个变体，描述了质量保证动作同沟通、建模相关动作以及早期构建相关的动作之间的关系。

6、型号任务,d付软件r系%需干卜二二二一二证与碘认二二系统代匕系统会求、证/函试后而软件I*“差屿碘功一4.认|软件1求、工攀证干后的软件产侬设计鲤一怪羹舸=概要设计、飞苴证,/搠试后的单元,编逢后的单元F详向设i十一1验证一单元冽赢=市an炭U、藜壮编码一994年在“软件工.rh.Qlli3. Incrementalprocessmodels（阶段式提交）适合于周期比较短的项目增量模型：第一个增量往往是核心产品；侧重与每个增量都提交一个可以运行的产品。OO-basedWhyuseincrementalmodel?4. EvolutionaryprocessPrototyping（原型开发）瀑布

7、模型的改进，适合需求不清楚的系统原型开发更多的运用于定义需求，原型模型描述了一种构建原型系统的方法，使得利益相关者可以反复评估，以便识别和确定软件需求。SpiralModel“螺旋模型”（spiralmodel）将瀑布模型的系统性和可控性和原型模型的迭代性质结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。5. SpecializedprocessmodelsComponentbaseddevelopment（需要面向对象技术支持）Object-orientedprocessmodels6. Unifiedprocessmodel（5个阶段）Inception（起始），Ela

8、boration（细化）,Construction（构建）,Transition（转换）,Production（生产）Chapter 4: AgileDevelopment1. WhatisAgility?2. AgileProcess敏捷过程适用的3个假设1 .提前预测哪些需求是稳定的而那些需求会变更非常困难。同样，预测项目进行中客户优先级的变更也很困难。2 .对很多软件来说，设计和构建是交错进行的。也就是，两种活动应当顺序开展以保证通设计策划过构建来实时验证设计模型，而在通过构建验证之前很难估计应该设计到什么程度。3.从制定计划的角度来看，分析、设计、构建和测试并不像我们所设想的那么容易预

9、测。XP（pairprogramming结对编程）XP使用面向对象方法作为推荐的开发范型。它包含了策划、设计、编码和测试动的规则和实践。，4个框架活用户故萼权值电收遍址推则迭代计划ScrumScrum模型：待定项backlog冲刺sprint结对胡捏Scrum例会1k眸升1s1/冲。等皆有群尸q本=附器利,皖朋如配型冲刺分岷整的客户里需七品特征三仃13!1（1-1方介神H邯台国的成员卦瑞幅I）上次后骨了什也?口遇到卜幺日近，j，卜次立哙前传些价商单设计匚反匚卡5Plice解决方察腺型第九削试遮续集成盥收测试软的增量项目型度估算Chapter8:UnderstandingRequirements

10、1. AbridgetodesignandconstructionThedefinitionofrequirementsengineering需求工程（RequirementEengineering,RE）是指致力于不断理解需求的大量任务和技术。它是一个软件工程动作，开始于沟通活动并持续到建模活动。2. sevenRequirementsengineeringtasks（简答题）Inception（起始）Elicitation（导出）日aboration（精化）Negotiation（协商）Specification（规格说明）Validation（确认）Requirementsmanagem

11、ent（需求管理）1 .起始。HOW问题：如何开始一个软件项目？技术（方法）：向业务领域去发现计算机系统的潜在应用。2 .导出。HOW问题：如何收集需求？技术（方法）：询问客户、用户和其他人，系统或产品的目标是什么、想要实现什么，系统和产品如何满足业务要求，最终系统或产品如何用于日常工作。3 .精化。HOW问题：如何开发分析模型，以便为计算机系统提供必要的信息、功能和行为说明？技术（方法）：需求的精化是由一系列的用户场景建模和求精任务驱动的。这些用户场景描述了如何让最终用户和其它参与者与系统交互；解析每个用户场景以提取分析类（即最终用户可见的业务域实体）；并初步定义每个分析类的属性、确定每个类

12、的操作，确定类之间的关联和协作关系，并完成各种补充图。4 .协商。HOW问题：如何解决需求相关的冲突问题？技术（方法）：通过协商过程来调节这些冲突。一一具体来说，就是让用户、客户和其它利益相关者对各自的需求排序、然后按优先级讨论冲突。使用迭代的方法给需求排序，评估每项需求对项目产生的成本和风险，表述内部冲突，删除、组合和（或）修改需求，以便参与各方均能达到一致的满意度。5 .规格说明。HOW问题：如何编写规格说明？技术（方法）：应当恰当的编写规格说明。6 .确认。HOW问题：如何检查一致性、是否有遗漏以及歧义性？技术（方法）：质量评估、技术评审。7 .需求管理。HOW问题：如何管理需求和需求变

13、更？技术（方法）：大部分同SCM技术，用于在项目进展中标识、控制和跟踪需求以及需求变更。3. Initialingtherequirementsengineeringprocess1、确定共利益者；2、识别多种观点；3、协同合作；4、首次提问；4. Elicitingrequirements通过开发系统原型获取用户需求1、协同需求收集；2、质量功能部署；质量功能部署（QFD）是一种将客户要求转化成软件技术需求的质量管理技术。目的是最大限度的让客户从软件工程过程中感到满意3、用户场景；场景Scenarios?可以识别对将要构建的系统的使用线索?提供了如何使用系统的描述?场景通常称为用例（usec

14、ase）4、导出工作产品要求和可行性陈述系统或产品范围的界限说明参与需求导出的客户、用户和其他利益相关者名单系统技术环境的说明需求列表以及每个需求适用的领域限制一系列用户使用场景定义需求的原型5. Developinguser-caseChapter9,10.11:RequirementsModeling1. RequirementsanalysisThethreegoalsofanalysismodeling(Information/Data,Function,Behavioral)三个目标：?描述客户需要什么；?为软件设计奠定基础；?定义在软件完成后可以被确认的一组需求。Theconcep

15、tsofanalysismodeling分析建模使用文字和图表的综合形式，以相对容易理解的方描绘需求的数据、功能和行为，更重要的是，可以更直接地评审它们的正确性、完整性和一致性。Specification模型应该关注在问题域或业务域内可见的需求，抽象的级别应该相对高一些。分析模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解。关于基础结构和其他非功能的模型应该推迟到设计阶段再考虑。最小化整个系统内的关联。确认分析模型为所有共利益者都带来价值。尽可能保持模型简洁。Requirementsvalidationreview,CheckList2. Analysis

16、modelingapproachesTheprinciplesofmodeling3. DatamodelingconceptsE-Rdiagram,一般，用E-R图来描述数据对象及其关系：E-R图是数据模型的基础，它描述数据对象、属性及其关系。E-R图是描述系统所有数据对象的组成和属性，描述数据对象之间关系的图形语言。矩形框：表示实体，在框中记入实体名。菱形框：表示联系，在框中记入联系名。椭圆形框：表示实体或联系的属性，将属性名记入框中。对于主属性名，则在其名称下划一下划线。连线：实体与属性之间；实体与联系之间；联系与属性之间用直线相连，并在直线上标注联系的类型。（对于一对一联系，要在两个实

17、体连线方向各写1;对于一对多联系，要在一的多对多美系relationshipofobjects数据对象可以以多种不同的方式与另一个数据对象连接?一对一关系01白cojTTEObfam。小叫小咋h肛m（i.n?一对多关系?多对多关系OrderDteIiveryCustomerOrder一对多关系数据对象和面向对象类的区别NameAddressOrderLineproductquantityobject£?数据对象定义了一个复合的数据项一方写1,多的一方写N;对于多对多关系，则要在两个实体连线方向各写N,Mo）?一个面向对象类封装了数据属性，但对这些属性所定义的数据的操作进行了合并。4.

18、 Scenario-basedmodelingUMLUse-CasesinUML：use-casediagram/activitydiagram/sequencediagram/statediagram/classdiagram（见书和PPT）OOanalysis:Behavioral,Class,Use-Case5. Creatingabehavioralmodel（生成行为模型）行为模型显示了软件如何对外部时间或激励作出响应行为，状态图、顺序图6. Class-basedmodelingIdentifyinganalysisclassesCRC（classresponsibility-co

19、llaborator）Modeling（类-职责-协作方）：实际上是表示类的标准索引卡片的集合。这些卡片被分为三部分：顶部写类名、下面左侧部分列出类的职责、右侧部分列出类的协作关系。（见书）Chapter12:DesignConcepts1. DesignwithinthecontextofsoftwareengineeringMaptheanalysismodelintodesignmodel建针*里2. Designconceptsabstraction,architecture,patterns,modularity,informationhiding,functionalindepen

20、dence,refactoring（重构），designclass抽象(Abstraction)(1)“当力图陈述一种解决方案时，面向问题的术语和面向实现的术语会同时使用”，以“提供更为详细的解决方案”。(2)并且，软件设计师应“力图得到解决现有问题的过程抽象和数据抽象”。求精(Refinement)求精实际上是一个细化的过程。该过程从高抽象级上定义的功能陈述或信息描述开始，随着在每个细化(精化)的持续进行，将提供越来越多的细节。低问题时满求>需求理愎用题任、分析等.CRC模型、行为版型、过程抽象+敷据抽氟：用例图、分斫英、CE匚围鳖，行为谑工、就模型过程抽象十数据抽象；体系结构、设计类

21、、构件困、活动图、嘤序图、部署图,体备造岗.设计类、棺件匡活动困、有-过程抽象卜数据拽象：源偿顺序图，部君寸再千鸡图.一二精化/细化_-予体系Z构(architecture)的定义：软件的整体结构和这种结构为系统提供概念完整性的方式。程序构件(模块)的结构或组织、这些构件交互的形式以及这些构件所用数据的结构。“体系结构”作为一个设计概念提出来，从以下3方面指定了体系结构设计表示应达成的内容：结构特征(Structuralproperties)o应定义系统的构件、构件被封装的方式以及构件之间相互作用的方式。外部功能特征(Extra-functionalproperties)o应指出设计体系结构如

22、何满足需求，应包括：性能需求、能力需求、可靠性需求、安全性需求、可适应性需求以及其他系统特征需求相关系统族(familiesofrelatedsystems)o体系结构应当能抽取出在一类相似系统开发中经常遇到的重复性模式。本质上，设计应当能够重用体系结构构件。体系结构描述语言ADLArchitecturaldescriptionlanguagesADL是这样一种形式化语言，它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法与概念框架，为体系结构的表示、分析、进化、细化、设计过程等提供支持。储蓄臬统偷入版盘信息饰Alf/I软卧即校叠宓码计算利总打印利总倩单&入I;也也褴

23、阿I雷码模块化(Modularity)(过犹不及)是关注点分离最常见的表现模块化和软件成本优点：1)使开发工作更易于规划；2)可以定义和交付软件增量；3)更容易实施变更；4)能够更有效的开展测试和调试；5)可以进行长期维护而没有严重的副作用。信息隐蔽(InformationHiding)原则：?建议模块应该“具备的特征是每个模块对其它所有模块都隐藏自己的设计策略”。?换句话说，模块应该规定并设计成为在模块中包含的信息(算法和数据)不被不需要这些信息的其它模块访问。?隐蔽定义并加强了对模块内过程细节的访问约束和对模块所使用的任何局部数据结构的访问约束。功能独立(FunctionalIndepen

24、dence):功能独立的概念是关注点分离、模块化、抽象和信息隐藏的直接产物。?软件设计时应使每个模块仅涉及需求的某个特定子集，并且当从程序结构的其它部分观察时，每个模块只有一个简单的接口。?独立性可以通过两条定性标准进行评估：-内聚性(Cohesion)：显示某个模块相关功能的强度；-耦合性(Coupling)：显示模块间的相互依赖性。?目标：高内聚、低耦合，减少“涟漪效应”。高内聚，低耦合的系统有什么好处呢？高内聚，低耦合的系统具有更好的重用性，维护_世，扩展性,可以更高效的完成系统的维护开发，持续的支持业务的发展，而不会成为一业务发展的障碍。重构（refactoring）是一种重新组织的的

25、技术，可以简化构件的设计（或代码）而无需改变其功能或行为。重构是使用这样一种方式改变软件系统的过程：不改变代码的外部行为而是改进其内部结构。设计活动：分析检查设计的冗余性、没有使用的设计元素、低效或不必要的算法、不恰当的数据结构。修改设计类（designclass）：需要将需求分析模型定义的一组分析类映射为设计类通过提供使类得以实现的设计细节对分析类进行细化。创建一组新的设计类实现支持业务解决方案的软件基础结构。将分析模型映射为5种不同类型的设计类i用户界面类（HCI,HMI人机交互接口）。ii业务域类。iii过程类。iv持久类，如数据库。v系统类。随着体系结构设计的进展，需要为每个设计类开发

26、出完整的一组属性和操作。评审改进。组织良好的设计类定义了4个特征：i完整性和充分性。ii原始性。iii高内聚。iv低耦合。3. Thedesignmodeltheconceptsofthedesignprocess:DataDesign,ArchitecturalDesign,Interface（接口）Design,Component-Level（组件级）Design4. characteristicsofawell-formeddesignclass:Completeandsufficient,Primitiveness（原始性）,Highcohesion,Lowcoupling（高类聚低耦

27、合）AnalysisModelandDesignModel（二者关系：过程维度、抽象维度）七慢工求相；设计娄宝现工系疏t¥同甘毛身听回号，出军胡卡阿用后比ttMSB北押出程描建设计是并册于黑电例传国用例一发本用例困话动画泳点用曲作网求可用明息胭荚函分而皿理里协择甚的当n庭控与道囹处理m程式送状青回即序图率未管半文立探作目而稀消",JE1.r.j1fr.F近1俄计芟子技作推口追计喝动凰协、围身匕也计1-恂*图则影用口方由设力询十支西胡画求精工芮件回设计类土耳”型mmK鸟茨口元烹峋件班元幸辽程港度Chapter 13: ArchitecturalDesign1. Softwar

28、eArchitectureThedefinitionofarchitectural:一个程序和计算系统软件体系结构是指系统的一个或者多个结构，。结构中包括软件的构建，构建的外部可见属性以及它们之间的相互关系2. DatadesignThegoalofDataDesignintheArchitecturalDesign:3. Architecturalstylesandpatternscomponents,connectors,constraints,semantic（语义）models;Data-centered,Data-flow,Callandreturn,Object-oriented,

29、LayeredarchitecturesArchitecturalcomplexity:dependencies（三种依赖关系）Chapter 14: Component-levelDesign1. WhatisacomponentOOview在面向对象软件工程环境中，构件包括一个协作类集合。(包括所有的属性和与实现相关的操作)Conventionalview在传统软件工程环境中，一个构件就是程序的一个功能要素，程序由处理逻辑及实现处理逻辑所需的内部数据结构以及能够保证够构件被调用和实现数据传递的接口组成。传统构件也被称为模块，作为软件体系结构的一部分，它承担如下三个重要角色之：1.控制构件(

30、acontrolcomponent);2.问题域构件(aproblemdomaincomponent);3.基础设施构件(aninfrastructurecomponent)。2. DesignClass-basedcomponentBasicdesignprinciples4个基本设计原则开闭原则(OCP)。模块对外延具有开放性，对修改具有封闭性Liskov替换原则。子类可以替换它们的基类 依赖倒置原则。依赖于抽象，而非具体实现 接口分离原则。多个客户专用接口比一个通用接口要好OCP(开闭原则)：是面向对象设计中“可复用设计”的基石，是面向对象设计中最重要的原则之一。对于扩展是开放的，对于修

31、改是关闭的，这意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。也就是说，我们可以改变模块的功能。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。开闭原则中“开”，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；开闭原则中“闭”，是指对于原有代码的修改是封闭的，即修改原有的代码对外部的使用是透明的。LSP（里氏替换原则）：任何基类可以出现的地方，子类一定可以出现。LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。只有满足以下2个条

32、件的OO设计才可被认为是满足了LSP原则（否则，他们的继承关系就应该废除）：不应该在代码（客户代码/客户程序）中出现if/else之类对子类类型进行判断的条件。子类应当可以替换父类并出现在父类能够出现的任何地方，或者说如果我们把代码中使用基类的地方用它的子类所代替，代码还能正常工作。'DIP（依赖倒置原则）：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。ISP:指在设计时采用多个与特定客户类有关的接口比采用一个通用的接口要好。即，一个类要给多个客户使用，那么可以为每个客户创建一个接口，然后这个类实现所有的接口；而不要只创建一个接口，其中包含所有

33、客户类需要的方法，然后这个类实现这个接口。Cohesion&Coupling（定义和区别，模块内和模块间）内聚：内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作。耦合：耦合是类之间彼此联系程度的一种定性度量。AnalysisClassandDesignClass3. Conductingcomponent-leveldesignThestepsofOOComponent-levelDesign1 .标识出所有与问题域相对应的设计类；2 .确定所有与基础设施域相对应的设计类；3 .细化所有不能作为复用构件的设计类；a.在类或构件的协作时说明消息的细节

34、；b.为每一个构件确定适当的接口；c.细化属性并且定义相应的数据类型和数据结构；d.详细描述每个操作中的处理流；4 .说明持久数据源（数据库和文件）并确定管理数据源所需要的类；5 .开发并且细化类或构件的行为表示；6 .细化部署图以提供额外的实现细节；7 .考虑每一个构件级设计表示，并且时刻考虑其他选择；4. Designconventionalcomponentsflowdiagram流程图（教材有图形化设计：顺序型、if-then-else结构、选择型、重复型）PDL程序设计语言Chapter 15: UserInterfaceDesign1. TheGoldenRules、i用户操纵控制

35、。是界面控制用户，还是用户控制界面？(置用户于控制之下)(1)以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式。(2)提供灵活的交互。(3)允许用户交互被中断或撤销。(4)当技能级别增长时可以使交互流线化并允许定制交互。(5)使用户与内部技术细节隔离开来。(6)设计应允许用户与出现在屏幕上的对象直接交互。2减少用户的记忆负担；3保持界面一致性。2. UserInterfaceanalysisanddesign(确认)3.Interfaceanalysisuseranalysis,taskandworkenvironmentanalysis,Interfacedesign,Interf

36、acevalidation(确认)useranalysis：利用各种途径获得用户是怎样的以及用户是如何使用系统的”，这些途径包括:(1)用户访谈。软件团队(代表)与用户讨论。(2)销售输入。销售人员与用户定期见面。(3)市场输入。市场分析，分析/理解市场每个部分使用软件的细微差别。(4)支持输入。技术支持人员与用户访谈。Taskanalysis任务分析目标- 在指定环境下用户将完成什么工作？- 当用户工作时将完成什么任务和子任务？- 在工作中用户将处理什么特殊的问题域对象?- 工作任务的顺序(工作流)如何？- 任务的层次关系如何？建模撰写用例任务细化对象细化工作流分析。层次表示Interfac

37、edesign:界面设计：通用的用户界面设计步骤(1)使用界面分析获得的信息，定义界面对象和动作(操作)。(2)定义那些导致用户界面状态发生变化的事件(用户动作)，并对行为建模。(3)描述每个界面状态，就像最终用户实际看到的那样。(4)简要说明用户如何从界面提供的界面信息来解释系统状态。Stepsofinterfaceanalysis用户分析、任务分析和建模、显示内容分析、工作环境分析4.InterfacedesignStepsDesignGUIaccordingtoUse-CaseDiagramChapter22,23,24:Testingstrategiesandtechniques1.

38、AstrategicapproachtosoftwaretestingVerificationandvalidation(验证与确认)验证是检测每一阶段形成的工作产品是否与前一阶段定义的规格相一致,确认是检测每一阶段的工作产品是否与最初定义的软件需求规格相一致。确认是保证软件符合产品说明书的过程验证是保证软件满足用户要求的过程2. Teststrategiesforconventionalsoftware（过程与文档）Unittest单元测试一一测试的单位是开发者创建的最小软件片段。典型地，它是指一个程序员的工作并且存贮在单独的文件中。integrationtesting集成测试（也叫组装测试

39、或联合测试）是单元测试的逻辑扩展，它在单元测试的基础上，将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。Top-Downintegration&Botton-UpintegrationTop-Downintegration:按照控制层次结构向下进行集成。分两种方法：深度优先：按照模块结构用一条主控制路径将所有模块组合起来；宽度优先：逐层组合所有下属模块，在每一层水平地沿着移动。Botton-Upintegration:?自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。?自底向上的集成测试方案是工程实

40、践中最常用的测试方法，相关技术也较为成熟。?它的优点很明显：管理方便、测试人员能较好地锁定软件故障所在位置，主要缺点就是“直到最后一个模块被加进去之后才能开到整个程序框架”。regression（回归）testing&smoke（冒烟）testingAcceptancetesting（Validationtesting）Systemtesting3. Validationtestinga测试的特点是：它是在开发环境下进行的（环境是可控的）；它不需要测试用例评价软件使用质量；用户往往没有相关经验，可以由开发人员或测试人员协助用户进行测试。a测试的关键在于尽可能逼真地模拟实际运行环境和用户

41、对软件产品的操作，并尽最大努力涵盖所有可能的用户操作方式。3测试的特点是：它是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试；开发人员通常不在测试现场；它是免费的；用户是任意的，环境是无法控制的。4. SystemtestingSystemtesting系统测试一一系统测试是将分别经过集成测试后的软、硬件作为计算机系统的一个部分，与系统支持软件、数据和人员等系统元素结合起来，在实际运行环境下对计算机系统进行一系列的严格有效的测试来发现软件的潜在问题，保证系统的运行。Use-CaseDiagramFunctiontesting,specification5. Theartofdebu

42、ggingTherelationshipoftestinganddebugging1）目的不同软件测试的目的是发现错误，至于找出错误的原因和错误发生的地方不是软件测试的任务，而是调试的任务.调试的目的是为了证明程序的正确，因此它必须不断地排除错误.它们的出发点不一样。前者是挑错，是一种挑剔过程，属于质量保证活动。后者是排错，是一种排除过程，是编码活动的一部分.2）任务不同既然软件测试属于质量保证活动，因此它贯穿于整个开发过程.从需求分析开始，就要制订软件测试计划，软件设计时要设计系统软件测试、集成侧试用例，编码阶段要设计单元软件测试用例并进行单元软件测试，软件测试阶段要进行集成软件测试、系统软

43、件测试等，直到产品交付。只要有修改就有软件测试，产品交付后同样如此。它是比较有规律的活动，有系统的方法、原则作指导。而调试是编码活动的一部分，因此有编码就有调试.它的任务主要就是排错。调试的方法经常与使用的开发工具有关。3）指导原则和方法不同软件测试是一种有规律的活动，有一系列软件测试的原则.其中主要是制订测试计划，然后严格执行.其次是一种挑剔性行为，因此它不但要测试软件应该做的，还需要测试软件不应该做的事情。调试所遵循的规律主要是一些启发式规则，是一个推理过程。软件测试的输出是预知的，其软件测试用例必须包括预期的结果，而调试的输出大多是不可预见的，需要调试者去解释、去发现产生的原因。4）操作

44、者不同因为心理状态是软件测试程序的障碍，所以执行软件测试的人一般不是开发人员，以使软件测试更客观、更有效，而调试人员一般都是开发人员6. White-Boxtesting白盒测试：又叫透明盒测试，结构测试。知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规定正常进行。是针对源程序实现的测试。把测试对象看做一个打开的盒子，利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。缺点：如果代码中本身就没有包含某个功能，则无法发现此类错误。FlowGraphNotationCyclomaticComplexity(环复杂性与独立路径)7. Basispathtes

45、ting基本路径测试(BasicPathTesting)是Thomas.McCabe提出的一种白盒测试技术，McCabe建立了一个度量指标叫做圈复杂度(CyclomaticComplexity),用于度量基于控制流程序的单元复杂度可以通过绘制一个描述当前被测试单元的有向图(控制流图)来度量圈复杂度圈复杂度的意义在于：1 .高复杂度的模块本质上就容易出错；2 .圈复杂度的数值同时也告诉测试人员在图中存在的基本路径，也就是等同于你想要覆盖整个图形所需要进行测试的次数基本路径中的每条路径对应一个测试用例，基本路径不唯一独立路径(IndependentPath)是指程序中至少引入一条新的处理语句序列或

46、一个新条件的任一路径，在控制流图中，独立路径至少包含一条在定义该路径之前未曾用到过的边在基本路径测试时，独立路径的数目就是控制流图的封闭区域数+1基本路径就是一组可以覆盖整个控制流图的独立路径在顺序结构下，整个程序没有分支，程序沿一条路径执行，覆盖整个控制流图只需要执行一,一、条路径即可。整个图形没有封闭区域，没有形I】)成一个圈，仅有一个外部区域，参见右图'I，用V(G)来表示圈复杂度，用R表示程序控制流X图中的封闭区域，在顺序结构中，V(G)=1,(2)R=0,我们得到以下公式：一1> V(C)=R+1；(1)I，在1个分支结构下3程序会沿着分支的两条路径来执行，只有覆盖了分

47、支处的两条路径才算覆盖了整个控制流图二> 1个分支结构的图形只有一个封闭区域R.参见右图，根据公式（1）具有一个分支结构的控制流图的圈复杂度为> （G）=R+1=1+1=2>在2个分支结构的条件下，有两个封闭区域R1和R2,参见右图，根据公式（1）,则圈复杂度为2+1=3卜对于右图，按照判定覆盖，只需要2条路径就可以覆盖整图；而按照路径覆盖而言，则需要4条路径才能覆盖（©图。在前图中，对于包含起始点和结束点的完整控制流图，其边数E和结点数N与圈复杂度也是密切相关的，V（G）=E-N+2;33.6圈复杂度与分支的关系卜而每当程序引入一个ifelse型的分支结构，圈复杂

48、度也增加1（因为增加了一个封闭区域），因此圈复杂度与ifelse型的分支节点数P之间的变化关系也是一致的，如果不考虑case型分支（可以转换为ifelse结构），则引入公式（3）V（G）=P+1；8. Controlstructuretesting（条件/循环）9. Black-Boxtesting黑盒测试：又叫功能性测试或行为测试。根据产品的功能设计说明，通过测试来检测每个功能是否都能正常使用。所有的测试和结果完全基于软件的外部行为，仅依赖于软件的输入和输出。把测试对象看做一个黑盒子，不考虑软件的内部逻辑和具体实现。缺陷：不能发现需求说明书本身存在的问题。EquivalencePartiti

49、oning（等价类划分）、等价类划分，指的是一种典型的、重要的黑盒测试方法。就是解决如何选择适当的数据子集来代表整个数据集的问题，通过降低测试的数目去实现“合理的”覆盖，以此来发现更多的软件缺陷，并由此对软件进行改进升级。等价分配是指将测试用例减少到可以控制的级别但仍然可以维护软件测试合理覆盖范围的技术。等价分配的基本技术是寻找等价区间BoundaryValueAnalysis（边界值分析）卜我们根据边界条件划分等价区间：L第一个区间包含有效数据，选择的测试用例为边界内部最后的一两个数据点2第二个区间包含无效数据.选择测试边界之外的一两个数据点10. OOTestingMethodsChapt

50、er21,29,31,32,33,34,35:ProjectManagement1.4P'sPeopleProductProcessProject人员People；建立交流机制.优调人员之间的美系：确立利益相关者及其职责；规划软件工程团队结构，培养有创造力、高技术水平的软件人员；培养具备技术领导能力的团队负责人。）产品Product:确定软件的范围口过程Process：基于软件框架活动，选择适合于待开发软件的过程模型&项目Pomct：管理.项目策划与跟踪监控口项目策划活动,进行成本、工作量的估计，并安排进度;制定风险管理计划、度量计划，质量管理计划以及配詈管理计划。跟踪：计划实

51、施和监控2. SCM定义：协调软件开发以最大限度的减少混乱的技术称为配置管理。配置管理是对软件开发团队正在构建的软件的修改进行标识、组织和控制的技术，目标是使错误量减少到最小，并使生产率最高。SCM活动用于：标识变更(identify)控制变更(control)保证恰当的实施变更(implement)向其它可能的相关人员报告变更(report)SCM软件配置管理的内容：软件配置项(SCI:SoftwareConfigurationItems)凡是纳入配置管理范畴的工作产品统称为配置项。软件配置项是在软件工程过程中创建的信息。项目生命周期中各技术或管理活动所产生的有价值的成果，例如计划、方案、设计文档、源代码、数据等。?计算机程序源代码和可执行程序、辅助开发的自动化工具?描述计算机程序的文档针对不同的软件开发人员和客户?数据或内容包含在程序内部和外部软件配置项管理是一组用于在计算机软件的整个生命周期内管理变更的活动，是对工作产品进行标志、存储和控制，以维护其完整性、可追溯性以及正确性，它为项目生命周期中的各工作产品提供了一套管理办法和活动原则。SCM的4个目标：?统一标识软件配置项；?管理一个或多个软