软件工程：系统化方法与质量关注点的基石

菏泽炫佑科技

软件工程：系统化方法与质量关注点的基石

软件工程是：

（1）把系统化、标准化、量化的方法应用于软件开发、运行和维护，即将工程化方法应用于软件。

（2）对（1）中描述的方法进行研究

软件和硬件有什么区别？

1. 软件是设计和开发的，而不是传统意义上的制造。

2. 软件不会“磨损”

3、大部分软件都是根据客户实际需求定制的。

为什么软件需要改变和发展？

软件必须适应新的计算环境或技术的需求。

必须增强软件才能满足新的业务需求。

该软件必须扩展才能与其他更现代的系统或数据库进行互操作。

必须重新设计软件以使其在网络环境中可行。

软件工程的基础是质量关注：组织对软件的承诺是软件工程的基石。软件工程的基础是过程层。软件过程结合了各种技术层面，使得合理及时地开发计算机软件成为可能。软件工程方法为构建软件提供了技术解决方案。方法包括：沟通、需求分析、设计模型、编程、测试和技术支持。软件工程工具为过程和方法提供自动化或半自动化的支持。软件工程

软件流程：软件流程是为了创建工作产品而执行的活动、操作和任务的集合。

流程框架

适用于所有软件项目，无论规模和复杂程度如何

1.沟通（）：目的是了解涉众的项目目标，并收集需求以定义软件特性和功能。

2.规划（）：定义和描述软件工程工作，包括所要执行的技术任务、可能的风险、资源需求、工作产品和工作进度安排。

3.建模（）：使用模型来更好地理解软件需求并完成满足这些要求的软件设计。

4.Build()：包括编码和测试，以查找编码中的错误。

5. 部署（）：软件交付给用户，用户对其进行评估并给予反馈。

普遍活动：

普遍的活动发生于整个软件项目之中。

1、软件项目的跟踪与控制：项目方按计划评估项目进展情况，采取必要的措施，确保项目按计划进行。

2. 风险管理：评估可能影响项目成果或产品质量的风险。

3. 软件质量保证：识别并执行软件质量保证活动

4. 技术评估：评估软件工程产品，并在错误传播到下一个活动之前尝试找到并消除错误。

5. 测量：定义和收集流程、项目和产品指标，以帮助团队在发布软件时满足利益相关者的要求。测量还可以与其他框架活动和普适活动结合使用。

6. 软件配置管理：管理整个软件项目过程中变更的影响。

7.可重用性管理：定义产品重用的标准，并建立构建重用机制。

8.工作产品的准备和生产：包括生产产品所必需的活动。

任务集

任务集定义了实现软件工程活动目标所需完成的工作。

例如，需求引出是沟通活动中的一个重要动作，其对应的任务集可能包括：

对于一个小型、相对简单的项目：

创建项目利益相关者列表。邀请所有利益相关者参加非正式会议。询问每个人他们想要拥有哪些特性和功能。讨论需求并*终确定列表。确定需求的优先顺序。确定不确定的领域。

对于大型、复杂的软件工程项目：制定项目的利益相关者列表。与每个利益相关者单独会面，以了解所有需求。根据利益相关者的意见，构建初步的特性和功能列表。安排一系列会议以促进需求捕获。组织会议。在每次会议上构建非正式的用户场景。根据利益相关者的反馈进一步完善用户场景。构建修订的利益相关者需求列表。使用质量功能部署技术确定需求的优先级。打包需求，以便可以逐步交付软件。注释系统约束和限制。讨论系统验证方法。使用自定义流程模型

习惯的流程模型的目的是为了改变软件开发的混乱状态，使软件开发变得更加有序。

瀑布模型：

它也被称为经典生命周期，它提出了一种系统、连续的软件开发方法。

优势：

有利于大型软件开发过程中人员的组织和管理，从而提高大型软件项目开发的质量和效率。

当定义需求并以线性方式完成工作时，瀑布模型是一种有用的过程模型。

缺点：

过于理想化，缺乏灵活性，容易出现需求偏差。

实际项目很少遵循瀑布模型提出的顺序。

客户通常很难清楚地描述他们的所有需求。

客户必须要有耐心，因为只有在项目结束时他们才能获得可执行程序。

适用范围：需求明确、工作能够以线性方式完成的软件。

V 模型：

描述质量保证活动与沟通、建模相关活动以及早期施工相关活动之间的关系。

V模型强调软件开发的协作与速度，将软件实现与验证有机结合起来，在保证软件高质量的情况下缩短了开发周期。

优点：适合工程量小、人力少、开发过程中变更不大的项目

缺点：错误发现得晚，风险成本高

增量过程模型

增量过程模型侧重于每次增量交付可用的产品。

优势：

能够完成部分工作的产品可以在更短的时间内交付给用户。逐步增加产品功能可以让用户有充足的时间学习和适应新产品，从而减少全新软件可能对客户组织造成的影响。避免技术风险可以并行开发组件，加快开发进度对于在业务截止日期前全面实施的人员配备非常有用。

缺点：

（1）组件并行开发可能产生不可集成的风险，软件必须具有开放的架构；

(2)增量模型的灵活性使得它比瀑布模型和快速原型模型能更好地适应这种变化，但是它也容易退化为即用即做的模型，从而使对软件过程的控制失去完整性。

适用范围：

（1）增量模型非常适合升级现有产品或者开发新版本；

（2）对于有严格截止期限的产品，可以采用增量模型；

（3）如果熟悉开发领域，并且已经有原型系统，增量模型也非常适合。

（4）项目在既定的业务需求之前无法找到足够的开发人员。

进化过程模型

进化模型是一种迭代过程模型。

原型设计（）：当需求不明确时，原型设计可以帮助软件开发人员和利益相关者更好地理解到底需要做什么。

优势：

开发人员和用户可以充分沟通，明确模糊的需求，需求定义比其他模型好很多

将开发过程与用户培训过程同步

为用户需求变化提供充足的空间

开发风险低、产品灵活性好

开发成本低、开发时间短

系统维护更方便，使用更方便

缺点：

1.没有考虑软件的整体质量和长期可维护性。

2、很多情况下为了展示功能而采用了不合适的操作算法、为了方便而采用了不合适的开发工具、选择了不合适的操作系统等等。

3.产品可能因不符合质量要求而被丢弃，并使用新模型重新设计。

适用范围：

虽然原型可以用作独立的过程模型，但它们更常用作可以在任何流模型环境中实现的技术。

统**程 ( )

统一过程模型

统一过程模型是一个由 UML 方法和工具支持的“用例驱动、以架构为中心、迭代和增量”的软件过程框架。它是一个增量模型，定义了五个阶段：

a. 初始阶段，包括用户沟通和规划活动，强调用例的定义和细化

b. 细化阶段包括用户沟通和建模活动，重点创建分析和设计模型。

c.组件阶段：细化模型设计，将设计模型转化为软件组件实现

d. 转换阶段，软件从开发人员交付给*终用户，然后由*终用户完成 beta 测试和验收测试

e.在生产阶段，持续监控软件的运行并提供技术支持。

优势：

1. 任何功能开发完成后都应进入测试流程，尽早进行验证

2. 早期风险识别和预防措施

缺点：

在开始之前必须充分理解需求，否则架构就有出错的可能。必须有严格的流程管理，防止流程退化为原来的试错修正模型。

3.如果不受控制地让用户过早接触未经完全测试、不稳定的产品版本，可能会对用户和开发团队都产生负面影响。

敏捷开发

敏捷宣言：

个人及其互动胜过发展过程和工具

可用的软件胜过大量的文档

客户合作胜过合同谈判

正确应对变化胜过遵循计划

极限编程（XP）

极限编程是敏捷软件开发*广泛使用的方法。

极限编程过程：

1.规划：

开始创建“用户故事”

敏捷团队评估每个故事并分配成本（开发周数）

故事被分组为可交付的增量

按时交付的承诺

在**个增量之后，项目速度用于帮助估计后续版本的发布日期和时间表，并确定整个开发项目中的所有故事是否都被过度承诺。

2. 设计

遵循KIS（保持简单）原则

鼓励使用 CRC（类-责任-合作者）卡（参见第 8 章）

对于困难的设计问题，建议创建一个“尖峰解决方案”——设计原型

鼓励“重构”：重构是在不改变代码外部行为的情况下修改软件系统以改善其内部结构的过程。

3. 编码

在开始编码之前，建议对故事进行单元测试

鼓励“团队编程”

持续集成

帮助避免兼容性和接口问题，并建立可尽早发现错误的“烟雾测试”

4. 测试

所有单元测试每天执行

“验收测试”根据客户指定的技术要求，重点关注客户可见且可审查的系统级特性和功能。

Scrum

待办事项 () - 为用户提供商业价值的项目需求或功能的优先级列表。随时可以向待办事项中添加新项目（这是引入变更）。产品经理评估待办事项并根据需要更改优先级。

冲刺（）——为实现待办事项中定义的需求而必须完成的工作单元，必须在预定的时间段（时间框9）（通常为 30 天）内完成。冲刺期间不允许进行任何更改（例如待办事项）。因此，冲刺为开发团队成员提供了一个短暂但稳定的工作环境。

Scrum 会议——Serum 团队每天召开的简短会议（通常为 15 分钟），所有成员必须回答三个问题 [Noy02]：

上次会议结束后你做了什么？遇到了什么困难？下次会议前你计划做什么？

燃尽图：衡量一段时间内剩余的待办事项数量。

需求工程 ( )

七项任务：启动、获取、细化、协商、规范、确认、管理

1. 起始：在项目开始时，建立基本的了解，包括问题、谁需要解决方案、所需解决方案的性质，以及与项目利益相关者和开发人员的初步沟通和协作的有效性。

2、获取（-）：询问客户、用户等其他人系统或产品的目标是什么，想要实现什么，系统和产品如何满足业务的要求，以及*终系统或产品如何在日常工作中使用。

3. 细化（-）：在初始阶段和演化阶段获得的信息将在细化阶段进行扩展和细化。该任务侧重于开发准确的需求模型。

4、协商（-双赢）：用迭代的方式确定需求的优先次序，评估每个需求对项目的成本和风险，表达内部冲突，删除、组合和修改需求，使得参与的各方都达到一定的满意度，实现双赢。

5. 规范（-，模型，）：规范可以是一份书面文档、一组图形模型、一个正式的数学模型、一组使用场景、一个原型或以上任何的组合。

6.确认（-）：在确认步骤中软件工程：系统化方法与质量关注点的基石，评估需求工程工作产品的质量。

7. 需求管理（-）：基于计算机的系统的需求是会变化的，变化的需求贯穿于系统的整个生命周期。需求管理是一组活动，用于帮助项目团队在项目进展过程中识别、控制和跟踪需求以及需求的变化。

打下基础：

 识别利益相关者

“你认为我还需要和谁谈谈？

 识别多种观点

 协作：识别共同领域和冲突领域，通过优先点法解决需求

 **个问题

这项工作的原始请求者是谁？

谁将会使用这个解决方案？

成功的解决方案将带来哪些经济效益？

您是否需要任何额外的资源来解决这个问题？

获取要求

协作需求收集：

 会议由软件工程师和其他利益相关者共同组织和参加

 制定会议准备和参加规则

 准备会议议程

 “主持人”（可以是客户、开发人员或其他人）控制会议

 使用“解决方案演示工具”（可以是工作表、挂图、贴纸或电子公告板、聊天室或虚拟论坛）

 目标是识别问题、提出解决方案的要素、协商不同的方法并确定一组问题的初步解决方案。

开发用例

用例模板：用例、主要参与者、目标、前提条件、触发器、场景、异常、优先级、何时可用、使用频率、使用方式、次要参与者、次要参与者使用方式、未解决的问题

基于场景的建模（功能）

使用基于场景的方法，可以从用户的角度描述系统。

在开发用例图时，您应该列出特定参与者执行的功能或活动。

例子：

UML 活动图通过提供特定场景中迭代流程的图形表示来补充用例。

例子：

UML 泳道图是活动图的一个有用变体，它允许建模者表示用例所描述的活动流程，同时指示哪个参与者或分析类负责活动矩形所描述的活动。

基于类的建模

基于类的建模表示系统操作的对象、对象能够有效控制的操作、这些对象之间的关系以及定义的类之间的协作。

基于类的分析模型包括类和对象、属性、操作、类职责和合作者（CRC）模型、协作图和包。

鉴定与分析

基于计算机系统生成或试验信息的外部实体（其他系统、设备、人员）。

事物（报告、显示、信件、信号），问题的信息域的一部分。

系统操作环境中发生的事件或发生（所有权的转移或一组机器人动作的完成）。

与系统交互的人员扮演的角色（经理、工程师、销售员）

与应用系统相关的组织单元（部门、群组、团队）

现场（制造车间或码头），确定问题的背景和系统的整体功能

结构（传感器、车辆、计算机），定义对象的类别或与对象相关的类别。

例子：

类-职责-协作者建模 (CRC)

CRC 模型实际上是代表类别的标准索引卡的集合。

在顶部写上类名，在左侧列出类的职责，在右侧列出类的合作者。

种类：

实体类：通常表示存储在数据库中并在整个应用程序中使用的内容。

边界类：创建用户在使用软件时看到并交互的界面

控制类：管理“控制单元”

职责：

责任基本原则：

1.智能系统应该分布在各个类别中，以*好地满足问题的需要。

2. 每个职责的描述应该尽可能的概括。

3.信息及相关信息应该局限于一个类中，而不要分布在多个类中。

4.信息和与其相关的动作应该放在同一类别中。

5. 在适当的时候，相关类别之间应分担责任。

属性：描述已选择纳入需求模型的类。

操作：定义对象的行为。

生成行为模型

生成行为模型的步骤：

1. 评估所有用例，确保完全理解系统内的交互顺序

2. 识别驱动交互序列的事件，并了解这些事件与特定对象之间的相互关系

3. 为每个用例生成一个序列

4.创建系统状态图

5. 审查行为模型以验证准确性和一致性。

状态图：

UML 状态图是一个行为模型，它呈现每个类的活动状态以及导致这些活动状态改变的事件。

例子：

流程图：

表示某事物导致从一个对象到另一个对象的转移。

设计概念

1. 摘要（）：

程序抽象是指明确定义且有限的指令序列（描述动作）

数据抽象是一个命名的数据集，用于描述数据对象（描述如何执行操作）

2. 架构：软件的整体结构以及该结构为系统提供概念完整性的方式。组件表示主要系统元素及其交互。

3、模式：模式承载着经过验证的解决方案的精髓。设计模式描述的是在特定场景下解决特定设计问题的设计结构，以及可能对模式的应用和使用产生“影响”。

4.关注点分离：它指出，如果将任何复杂问题分解为几个可以独立解决和优化的部分，就可以更容易地处理。

5、模块化：模块化是关注点分离*常见的表现形式。软件被划分为独立命名、可处理的组件，有时称为模块，这些组件可以集成在一起以满足问题的需求。模块化设计使开发工作更容易规划。

6、信息隐藏：隐藏是指通过定义一系列独立的模块来实现有效的模块化，独立模块之间只传递实现软件功能所必需的信息。隐藏定义并强制执行对模块内部流程细节的访问约束，以及对模块使用的任何本地数据结构的访问约束。

7、功能独立性（）：通过开发具有“单一用途”功能、低耦合的模块可以实现功能独立性。

8、细化：通过不断细化过程的详细程度来开发程序，通过逐步分解功能的宏语句来分层开发，直到形成编程语言的语句。

抽象和细化是互补的概念。

9. 方面：方面是作为独立模块实现的，而不是作为与许多组件“分裂”或“纠缠”在一起的软件。设计架构应该支持方面的定义，方面是一个模块，它使关注点能够通过它所交叉的所有其他关注点来实现。

10. 重构：重构是改变软件系统的过程软件开发，使得代码的外部行为不变，但内部结构得到改善。

11.面向对象设计概念（OO）：

面向对象的概念（类、对象、继承、消息和多态性）

12. 设计类：提供设计细节，以使程序能够实现。

设计理念强调：

(1) 抽象的必要性，它提供了一种创建可重用软件组件的方法

（2）架构的重要性，它能够让我们更好地理解系统的整体结构

（3）基于模式的工程（一种具有成熟功能的软件设计技术）的优势

（4）关注点分离和有效模块化的价值，这使得软件更易于理解、更易于测试和更易于维护。

（5）信息隐藏的直接作用是，当错误发生时，可以减少负面影响的蔓延。

（6）功能独立性的影响，这是构建有效模块的标准

（7）细化作为设计方法的作用

（8）考虑跨系统要求

（9）重构的应用，优化导出的设计

（10）面向对象的类和类相关特性的重要性

设计模型

数据设计元素：数据设计创建以高抽象层次表示的数据模型和信息模型。

架构设计元素：架构设计元素通常被描述为一组相互关联的系统的子系统，通常源自需求模型中的分析包。

界面设计元素：软件界面设计元素描述信息如何流入和流出系统，以及作为架构一部分定义的组件如何相互通信。

界面设计有三个重要元素：

（1）用户界面

（2）与其他系统、设备、网络或其他信息生成者或用户的外部接口

（3）各设计部件之间的内部接口

组件级设计元素：软件的组件级设计完整地描述了每个软件组件的内部细节。组件级设计定义了所有本地数据对象的数据结构，定义了组件内发生的所有处理的算法细节，并定义了允许访问所有组件操作的接口。

部署级设计元素：部署级设计元素指定软件功能和子系统在支持该软件的物理计算环境中如何分布。

架构设计

程序或计算机系统的软件架构是指系统的一个或多个结构，包括软件组件、它们的外部可见属性以及它们的相互关系。

架构不是可执行程序。

更准确地说，它是一种能够：

（1）分析设计是否满足既定要求的有效性

（2）当设计变更相对容易时，考虑可能的架构选项

（3）降低软件建设风险

建筑为何如此重要？3 个关键原因

1.软件架构的表示有利于对计算机系统开发感兴趣的各方之间的沟通。

2. 架构强调了早期的设计决策，这些决策对所有后续的软件工程工作都有深远的影响，并在系统作为一个工作实体的*终成功中发挥重要作用。

3. 架构“构建一个相对较小、易于理解的模型，以说明系统的结构及其组件如何协同工作”

建筑风格：

以数据为中心的架构。

数据流架构。

调用和返回架构

面向对象的架构：

系统的组件封装了数据以及控制数据所必须的操作，组件之间通过信息传递进行通信、协作。

分层架构

组件级设计组件的概念：

1. 组件是计算机软件中的模块化构建块。

2.OMG将组件定义为系统中模块化、可部署、可替换的部分，它封装了实现并公开一组接口。

面向对象视图：

组件由一组协作的类组成。

传统观点：

组件是程序的功能元素，程序由处理逻辑、实现处理逻辑所需的各个数据结构以及能保证组件被调用和实现数据传递的结构组成。

基本设计原则

 开放封闭原则：模块应该对扩展开放，对修改关闭。

 依赖倒置原则：依赖于抽象，而不是具体的实现。

 替换原则：子类可以替换它的基类。

 接口分离原则：多个客户特定接口优于一个通用接口

 发布与复用等价原则：复用的粒度就是发布的粒度

 通用封装原则：一起变化的类应该归为一组

 共同重用原则：不能一起重用的类不能组合在一起

凝聚

内聚性是指组件或类只封装那些彼此之间联系紧密、并且与组件或类本身联系密切的属性和操作。

功能内聚性：主要通过操作来体现，当一个模块只完成某组特定的操作并返回结果时，这个模块就称为功能内聚。

分层内聚：较高层的服务可以访问较低层的服务，但较低层的服务不能访问较高层的服务。

通信内聚：所有访问相同数据的操作都定义在同一个类中。（数据的查询、访问、存储）

耦合（）：

耦合是衡量类与类之间连接紧密程度的一个定性指标。

随着类（组件）之间的相互依赖性越来越强，类之间的耦合度也会增加。

内容耦合：偷偷修改其他组件内部数据，违反信息隐藏原则

常见耦合：当大量组件使用同一个全局变量时就会发生这种耦合。

控制耦合：当操作 A 调用操作 B 并将控制令牌传递给 B 时，就会发生这种耦合。

标签耦合：当类 B 被声明为类 A 的操作中的参数类型时，就会发生这种耦合。

数据耦合：当操作需要传递长串数据参数时，就会发生这种耦合。

例程调用耦合：当一个操作调用另一个操作时就会发生这种耦合。

类型使用耦合：当组件 A 使用组件 B 中定义的数据类型时，就会发生这种类型的耦合。

包括或导入耦合：当组件A导入或包含组件B的软件包或内容时，此耦合发生。

外部耦合：当组件与基础架构组件进行交流并协作时，就会发生这种耦合。

为什么要高凝聚力？

模块之间的关系更加紧密，错误越少！

为什么要低耦合？

子例程之间的关系越复杂，就会发生更多意外的错误！

高凝聚力和低耦合是软件工程中的概念。

用户界面设计

黄金法则

1.用户控制的操作

（1）以不迫使用户施加不必要或不良动作的方式定义交互模式

（2）允许用户交互被中断和撤销

（3）随着技能水平的增长而简化和自定义互动

（4）将用户与内部技术细节隔离

（5）设计应允许用户直接与屏幕上出现的对象进行交互

2.减轻用户的内存负担

（1）减少对短期记忆的需求

（2）建立有意义的默认值

（3）定义直观的快捷方式

（4）以持续的方式揭示信息

3.保持接口一致

（1）允许用户将当前的任务纳入有意义的上下文

（2）保持应用系统家庭中的一致性

（3）如果过去的交互模型已经建立了用户期望，则除非有令人信服的原因，否则打ze不应更改它们。

可用性

可用性是指用户对高科技产品提供的功能和功能的使用的量化测量。

用户界面分析和设计

工程师构建了软件工程师。

用户模型：标识系统*终用户的配置文件。

设计模型：用户界面的设计

心理模型：*终用户在他或她的脑海中拥有的形象。

实施模型：它结合了计算机系统的外部表示以及用于描述系统语法和语言的所有支持信息。

用户界面分析和设计过程是从螺旋模型的内部开始的，包括四个阶段：（1）接口分析和建模。

接口设计的目标是定义一组接口对象和操作，使用户能够以满足系统定义的每个用法目标的方式完成所有定义的任务。

界面分析

在用户界面设计中，了解问题意味着知道：

（1）通过界面与系统互动的人

（2）*终用户需要执行的任务以完成工作

（3）作为接口的一部分显示的内容

（4）任务处理环境

接口分析：

（1）用户分析：

设计人员可以将用户心理模型与设计模型相连的唯一方法是努力了解用户以及如何使用系统。

可以从各种来源获得信息

用户访谈：软件团队（代表）与用户之间的讨论。

销售输入：销售人员定期与用户见面。

市场输入：使用软件分析/分析/了解市场细分市场的细微差别。

支持输入：技术支持人员和用户访谈。

（2）任务分析和建模

任务分析的目的是将这些技术应用于用户界面：

a用例：一个用例描述参与者如何与系统相互作用。

b。

1.了解实现活动目标必须完成的任务

2.研究现有的基于计算机的解决方案的规格，并得出一组适合用户模型，设计模型和系统感觉的用户任务。

逐渐完善。

c。对象改进：对象细化

d。工作流程分析：工作流分析定义了涉及多个人（和角色）时如何完成工作流程。

e。

用户任务：请求处方补充

提供识别信息。

指定名称。

指定用户ID。

指定PIN和密码。

指定处方号码。

需要指定日期重新填充。

质量概念：实现软件质量：

软件工程方法：

需求和设计部分提供了一系列概念和方法，可帮助我们获得对问题的合理理解和全面的设计，从而为建筑活动建立坚实的基础，并采用适当的分析和设计方法，可以得到极大的改进。

项目管理技术：

（1）项目经理使用估计来确认（2）时间表的依赖性是明确的，并且团队能够抵制降低拐角处的诱惑；

此外，本书的第四部分将讨论项目计划的明确质量管理和变更管理技术。

质量控制：

质量控制包括一组软件工程活动，以确保对其质量目标进行审查，以确保它们是完整的，并在测试开始时要查找和正确的错误。

质量保证：

质量保证建立基础架构，支持固体软件工程方法，合理的项目管理和质量控制活动 - 如果您打算建立高质量的软件，那么所有这些都是关键活动。

软件质量保证：

软件可靠性：
	可靠性的简单测量是平均失效间隔时间（MTBF）

mtbf = mttf + mttr

（即平均故障时间+平均维护时间）

软件可用性：

可用= mttf/（mttf+mttr）* 100％

MTBF可靠性测量团队MTTF和MTTR同样敏感。

测试

测试：测试是执行具有特定意图的程序的过程，以在交付给*终用户之前查找错误。

验证和确认（和V＆V）：

验证是指确保正确实施某个功能功能的一系列活动。

确认是指确保软件开发的另一系列活动可以追溯到客户的需求。

测试策略：从小到大

传统软件的测试策略：单元测试：

目的：充分利用测试技术来运行操作组件中每个控制结构的特定路径，以确保路径的完整覆盖范围并找到*大可能性的错误。

在单元测试期间，选择测试的执行路径是*基本的任务。

边界测试是*重要的单元测试任务之一。

单位测试过程：

驱动器模块：接收测试用例数据，将这些数据传递给组件，然后输出结果。

桩模块：更换属于测量组件的模块

设计高付费组件时，可以简化单位测试。

集成测试：

集成测试是一种构建软件体系结构的系统技术，它也是发现与接口相关的错误的测试。

目的是建立一个由单元测试的组件设计中描述的程序结构。

综合策略：

执返回测试：重新执行某些已测试的子集，以确保更改尚未处于不利地位。

回归测试有助于确保不引入更改或非同寻常。

可以手动进行回归测试。

捕获/播放工具使软件工程师能够捕获测试用例和测试结果，以进行随后的播放和比较捕获。

可以测试软件所有功能的代表性测试样本。

其他测试的重点是可能受更改影响的软件功能。

专注于已更改的软件组件测试。

吸烟测试：（滚动集成测试方法，您需要每天重建或添加新组件）

活动：

1.已转化为代码的软件组件已集成到结构中（“构建”）。

结构包括所有数据文件，库，可重复使用的模块和工程组件。

2.设计一系列测试以显示错误，以使该结构无法正确执行其功能。

目的是揭示“显示阻塞”错误。

3.将这种结构与其他结构集成，每天（当前形式）吸烟。

优点：1。降低集成风险；

2.提高*终产品的质量；

3.简化错误的诊断和纠正；

4.易于评估的进度状态

下**从顶部到顶部的集成：从顶部到底部的集成测试是结构软件体系结构的增量方法。

从顶部进行集成过程：

1.主控制模块用作测试驱动器模块，桩模块被直接关联的下部模块代替；

2.基于所选的集成策略（首先是深度优先/广度），每次实际模块替换桩模块时；

3.测试每个模块的集成；

4.完成每个测试集后，将另一个桩模块替换为实际模块；

5.回归测试（即重复已重复进行的测试），以避免引入新的错误。

返回到第二个步骤，以继续此过程，直到整个程序结构的结构完成为止。

上：从原子模块（程序结构的底部组件）开始，以进行结构和测试。

从底部进行集成的测试过程：

1.连接基础组件以形成完成特定子功能的群集。

2.编写驾驶模块的输入和输出（用于测试的控制程序）以协调测试用例的输入和输出

3.测试集群

4.卸下驾驶员并逐渐将群集连接到程序结构

**针对对象的软件的测试策略

面向对象的软件的测试等效于传统软件的单元测试。

区别是：

传统软件单元测试的重点是模块的算法详细信息和模块接口数据；

面向对象的类的测试集中在此类封装的操作和类行为上。

封装类是单元测试的重点，但不再孤立地测试单个操作，而是将其用作类的一部分。

在面向对象的软件集成测试中进行一步的集群测试。

确认测试：

确认测试指南：软件证实它是通过一系列测试获得的，这些测试表明满足了软件要求。

α测试：α测试是由代表性的*终用户在自然环境中使用的开发人员的位置。

系统测试实际上是整个基于计算机的系统的一系列不同测试。

各恢复测试：被迫使软件以各种方式失败，并验证是否正确执行恢复。

**测试安全测试：**安全测试验证是否基于系统的保护机制实际上可以保护系统免于被非法入侵。

**力压力测试：**压力测试的目的是软件正面临正常情况。

**能绩效测试：**性能测试用于在集成环境中测试软件的性能。

**部署测试：**有时部署测试也称为配置测试，这是在每个环境中都在该软件中运行的软件。

调试

在成功测试之后，调试（）是探索错误的外部绩效及其内部原因之间关系的智力过程。

测试是发现错误，调试是找到错误的原因

测试传统应用系统

白盒测试：白盒子测试有时称为玻璃盒子测试。

白盒测试是在理解模块内部结构的条件下进行的测试。

使用白盒测试方法导出的测试用例可以是：

（1）确保至少执行一次模块中的所有独立路径。

（2）所有逻辑判断都需要进行测试和离开。

（3）在上边界和操作范围内执行所有周期。

（4）测试内部数据结构以确保其有效性。

基基本路径测试：基本路径测试是汤姆首先提出的白盒测试技术。

流图（程序图）是控制流表示表示的简单方法。

流程图用于描述程序的控制结构。

将流程图映射到相应的流图。

独立程序路径：

独立路径是指引入至少一组新句子或新条件的路径。

如果设计测试被迫执行这些路径（基本集合：不是唯一的），则可以至少执行程序中的每个语句，并且执行每个条件的实现和休假。

圆圈复杂性：它是一个软件学位，它为程序的逻辑复杂性提供了定量标准。

环复杂度的值定义了程序的基本集合中的独立路径的数量，并提供了所需测试数量的数量的上限至少至少需要一个必需的测试。

环复杂度的计算：

生成基本测试用例的步骤：

源基于设计或源代码，绘制相应的流程图。

流确定流程图的环复杂性。

v（g）=侧点+2 =确定节点的数量+1 =封闭区域的数量+1

独确定线性独立路径的基本集。

例例准备测试案例并强制基本集合中的每个路径。

黑匣子测试：

行黑匣子测试也称为行为测试，重点是软件的功能要求。

工黑匣子测试使软件工程师能够为测试程序的所有功能要求设计输入条件。

盒黑匣子测试不是白盒测试的替代方法，而是一种查找其他类型错误的辅助方法。

黑匣子测试尝试发现以下类型的错误：

（1）不正确或省略的功能

（2）接口错误

（3）数据用于测试的阶段阶段

（4）行为或绩效错误

（5）错误的初始化和终止

：等效分类：这是一种黑匣子测试方法，将程序的输入分为几个数据类，并从中生成测试用例。

等效类代表输入条件的一组有效或无效状态。

设计等效的指导原则：

1.如果输入条件指定了一个范围，则可以定义有效的等效类和两个无效的等效类。

2.如果输入条件需要特定值，则可以定义有效的等效类和两个无效的等效类。

3.如果输入条件指定集合中的一组元素，则可以定义有效的等效类和无效等效的类别。

4.如果输入条件是布尔值，则可以定义有效的等效和无效等效。

通过使用设计等效类的指导原理，您可以为每个输入域数据对象设计测试用例。

B边界值分析（BVA）：

原因：在输入域的边界，而不是在输入域的“中间”中发生了大量错误。

边界价值分析是“等效划分”的补充。

软件配置管理（SCM）（也称为更改管理）

基线：

基线是软件配置管理概念，可以帮助我们控制不严重妨碍合理更改的条件下的变化。

基线的定义：已对其进行正式评估和批准的规格或产品。

软件配置项目：

软件配置项目是在软件工程过程中创建的信息。

将SCI组织到配置对象中。

SCM中心存储：

功能和内容：中央存储的中央存储空间是什么，中央存储提供了哪些特定服务。

SCM功能：

版本控制：

保存所有这些版本，以有效地管理产品发布，并允许开发人员在测试和调试过程中返回到早期版本。

变依赖性跟踪和变化管理：

中央存储必须管理存储的配置对象之间的各种关系。

需求跟踪：

它可以跟踪特定需求规格生成的所有设计组件，架构组件和产品；

配置管理：

它可以跟踪一系列代表特定项目的里程碑或产品发布的配置。

审查跟踪：

评论跟踪使我们能够了解更改何时，原因是什么以及谁完成信息。

SCM流程：

版本控制：

版本控件结合了法规和工具，可用于管理软件过程中创建的配置对象的不同版本。

版本控制系统实现或直接集成了4个主要功能：

对存储所有相关配置对象的项目数据库（中心存储）；

所有存储配置对象所有版本（或可以在上一个版本之间构造任何版本以构建任何版本）管理功能；

能使软件工程师可以收集所有相关的配置对象和软件的特定版本的生产功能。

更版本控制和更改控制系统通常具有问题跟踪（也称为错误跟踪）功能，因此团队可以记录和跟踪与每个配置对象相关的重要问题。

变更控制：（项目 - 级别的变更控制和以前的基线SCI可以链接））

软件项目估计

估基于过程的估计：

根据该过程，每个过程中需要多少人。

估估计用例：

ucp =（UUCW + UAW） * TCF * ECF

UCP：用法点

UUCW：加权后用例的重量获得了整体未解决的用例的重量。

复杂用例描述* 15

一般用例描述* 10

简单用例描述* 5

UAW：寻求加权参与者的重量，并获得整体未安置的参与者的重量。

复杂参与者* 3

普通参与者* 2

简单参与者* 1

TCF：技术复杂性因素

ECF：环境复杂性因子

计算案例点，以确定根据经验获得代码总数的要求，并使用系统的平均生产率使用系统的平均生产率来获得每行代码的成本，您可以获得总计算值。

管理软件项目

及进度计划评估和审查技术（PRT）

C密钥路径方法（CPM）

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等