软件工程

Software：
（1）指令的集合，通过执行这些指令可以满足预期的特征、功能和性能需求；
（2）数据结构，使得程序可以合理利用信息
（3）软件描述信息，它以硬拷贝和虚拟形式存在，用来描述程序操作和使用

Software Engineering：
软件工程是：
（1）将系统化的、规范化、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。
（2）在（1）中所述方法的研究

What the difference between software and hardware?
1.软件是设计开发的，而不是传统意义上生产制造的。
2.软件不会“磨损”
3.大多数软件根据实际的顾客需求定制的。

Why does software need Change or Evolved?
软件必须适应新的计算环境或技术的需要。
必须增强软件来实现新的业务需求。
软件必须扩展到与其他更现代的系统或数据库进行互操作。
必须重新构建软件，使其在网络环境中可行。

支持软件工程的根基在于质量关注点（quality focus）：
是对软件的组织承诺，是支持软件工程的基石
软件工程的基础是过程（process）层。软件过程将各个技术层次结合在一起，使得合理、及时地开发计算机软件成为可能。
软件工程方法（method）为构建软件提供技术上的解决方法。方法包括：沟通、需求分析、设计模型、编程、测试和技术支持。

Software Process ：
软件过程：软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。

Generic Framework Activity
适用于所有软件项目，无论其规模和复杂程度如何
1.沟通（Communication）：目的是理解利益相关者的项目目标，并收集需求以定义软件特性和功能。
2.策划（Planning）：定义和描述了软件工程工作，包括需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。
3.建模（Modeling）：利用模型哎更好地理解软件需求并完成符合这些需求的软件设计。
4.构建（Construction）：它包括编码和测试以发现编码中的错误。
5.部署（Deployment）：软件交付到用户，用户对其进行评测并给出反馈意见。

Umbrella Activities（普适性活动）：
普适性活动贯穿软件项目始终。
1.软件项目跟踪和控制：项目根据计划评估项目进度，并且采取必要的措施保证项目按进度计划进行。
2.风险管理：对可能影响项目成果或者产品质量的风险进行评估。
3.软件质量保证：确定和执行软件质量保证的活动
4.技术评估：评估软件工程产品、尽量在错误传播到下一个活动之前，发现并清除错误。
5.测量：定义和收集过程、项目和产品的度量，以帮助团队在发布软件的时候满足利益相关者要求。同时，测量还可以与其他框架活动和普适性活动配合使用。
6.软件配置管理：在整个软件工程中，管理变更所带来的影响。
7.可复用管理：定义产品复用的标准，并且建立构建复用机制。
8.工作产品的准备和生产：包括了生产产品所必需的活动。

Process Flow
过程流：描述了在执行顺序和执时间上，如何组织框架中的活动，动作，任务。
线性过程流（Liner process flow）：从沟通到部署顺序执行五个框架活动。

迭代过程流（iterative process flow）：在执行下一个活动前重复执行之前一个或多个活动。

演化过程流（evolution process flow）：采取循环的方式执行各个活动。

并行过程流（parallel process flow）：将一个或是多个活动与其他活动并行执行。

过程模式（process pattern）:描述了软件工程工作中遇到的过程相关的问题、明确了问题环境并给出了针对该问题的一种或几种可证明的解决方式。

Process Model
惯用过程模型是为了改变软件开发的混乱状态，促使软件开发更加有序。
瀑布模型（waterfall model）：又被称为经典生命周期（classic life cycle），它提出了一个系统的、顺序的软件开发方法。
优点：
有利于大型软件开发过程中人员的组织、管理，从而提高了大型软件项目开发的质量和效率。
当需求确定、工作采用线性的方式完成的时候瀑布模型是一个很有用的过程模型。
一个有用的过程模型，其中需求是固定的，工作将以线性方式完成。
缺点:
过于理想，缺乏灵活性，容易产生需求偏差。
实际的项目很少遵守瀑布模型提出的顺序。
客户通常很难清除的描述所有的需求。
客户必须要有耐心，因为只有在项目接近尾声的时候，他们才能的带执行的程序。
适用范围：需求确定，工作能够采用线性的方式完成的软件。

V模型（V-model）：
描述了质量保证动作同沟通、建模相关动作以及早期构建相关的动作之间的关系。
V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。
优点：适合工程量小、人力资源少并且开发过程中改动不大的项目
缺点：错误发现时间迟，产生的风险代价高

增量过程模型（Incremental Model）
增量过程模型侧重于每一个增量都提交一个可以运行的产品。
优点：
1.能在较短的时间内向用户提交可完成部分工作的产品。
2.逐步增加产品功能可以使用户有充裕的时间学习和适应新产品，从而减少一个 全新的软件可能给客户组织带来的冲击。
3. 规避技术风险
4. 可并行开发构件，加快开发的进度
5. 对于在业务截止日期之前完全实施的人员配置非常有用。
缺点：
（1）并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构；
（2）增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
适用范围：
（1）进行已有产品升级或新版本开发，增量模型是非常适合的； （2）对完成期限严格要求的产品，可以使用增量模型；
（3）对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的。
（4） 项目在既定的商业要求期限之前不可能找到足够的开发人员

演化过程模型（Evolutionary Model）
演化模型是迭代的过程模型。
原型开发（prototyping ）：当需求很模糊的时候，原型开发可以帮助软件开发人员和利益相关者更好地理解究竟需要做什么。
优点：
开发者与用户充分交流，可以澄清模糊需求，需求定义比其他 模型好得多
开发过程与用户培训过程同步
为用户需求的改变提供了充分的余地
开发风险低，产品柔性好
开发费用低，时间短
系统易维护，对用户更友好

缺点：
1、 没有考虑软件的整体质量和长期的可维护性。
2、 大部分情况是不合适的操作算法被采用目的为了演示功能，不合适的开发工 具被采用仅仅为了它的方便，还有不合适的操作系统被选择等等。
3、 由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计。
适用范围：
尽管原型可以用作独立的流程模型，但它更常用作一种可以在任何流模型的上下文中实现的技术。

螺旋模型（Spiral Model）
螺旋模型是一种风险驱动型的过程模型生成器，对于软件集中的系统，它可以指导多个利益相关者的协同工作。
优点：
它结合了原型的迭代性质和瀑布模型的系统性和可控性特点。

1. 强调风险
2. 强调阶段质量
3. 提供纠错的机会
4. 使用原型作为风险降低机制，进一步使开发人员能够在产品演变的任何阶段应用原型方法。
   缺点：
5. 每个阶段都要提出被选方案，进行风险分析，研发周期长，效率低
6. 必须要转业的风险分析人员的参与
7. 如果没有发现和管理重大风险，问题无疑将会发生。
   适用范围：大型项目

协同模型（concurrent development model）
有时候又称为协同工程，它允许软件团队表述本章所描述的任何模型中的迭代和并发元素。
协同建模提供了项目当前状态的准确画面。
适用范围：所有类型的软件开发，协同模型通常更适合涉及不同工程团队的产品工程项目。

统一过程（Unified Process）
统一过程模型
统一过程模型是一种“用例驱动、以体系结构为核心、迭代及增量”的软件 过程框架，由 UML 方法和工具支持。它是一种增量模型，定义了五个阶段：
a、起始阶段，包括用户沟通和计划活动，强调定义和细化用例
b、 细化阶段，包括用户沟通和建模活动，重点是创建分析和设计模型。
c、构件阶段，细化模型设计，并将设计模型转化为软件构件实现
d、 转化阶段，将软件从开发人员传递给最终用户，并由用户完成 beta 测试和验 收测试
e、生产阶段，持续地监控软件的运行，并提供技术支持。
优点：

1. 任何功能开发后就进入测试过程，及早进行验证
2. 早期风险识别，采取预防措施

缺点：

1. 需求必须在开始之前完全弄清楚，否怎有可能在架构上出现错误
2. 必须有严格的过程管理，以免使过程退化为原始的试→错→改模式
   3．如果不加控制的让用户过早接触没有测试完全，版本不稳定的产品可能对用 户和开发团队都带来负面的影响。

Agile Development
敏捷宣言（Agile development manifesto）：
个人和这些个人之间的交流胜过了开发过程和工具
可运行的软件胜过了宽泛的文档
客户合作胜过了合同谈判
对变更的良好响应胜过了按部就班地遵循计划

极限编程（Extreme Programming (XP)）
极限编程是敏捷软件开发使用最广泛的一个方法。

极限编程过程:
1.策划：
开始创造“用户故事”
敏捷团队评估每个故事并分配一个成本（开发周数）
故事被分组到一个可交付增量
承诺在交付日期进行
在第一次递增之后，“项目速度”用于帮助估计后续发行版本的发布日期和进度安排，确定是否对整个开发项目中的所有故事有过分承诺。
2.设计
遵循KIS（保持简洁）原则
鼓励使用CRC（类-责任-协作者）卡（见第8章）
对于困难的设计问题，建议创建“尖峰解决方案” - 一个设计原型
鼓励“重构”： 重构是以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。
3.编码
在编码开始之前，建议对故事进行单元测试
鼓励“结队编程”
4.测试
所有的单元测试每天都执行
“验收测试”，由客户规定技术条件，并且着眼于客户可见的、可评审的系统级的特征和功能。

工业极限编程（Industrial XP （IPX））
IXP是XP的一种有机进化。它由XP的最低限要求、以客户为中心、测试驱动精神组成。IXP和XP的主要差别在于其管理具有更大的包容性，它扩大了用户角色，升级了技术实践。
IXP合并了六个新实践：
Readiness assessment(项目准备)
Project community(项目社区)
Project chartering（项目承租）
Test-driven management （测试驱动管理）
Retrospectives.（回顾）
Continuous learning （持续学习）

需求工程（Requirement engineering）
七个任务
1.起始（Inception）：在项目起始阶段，要建立基本的理解，包括对问题、谁需要解决方案、所期望解决方案的性质、与项目利益相关者和开发人员之间达成初步交流合作的效果。
2.导出（Elicitation –gathering requirements）：询问客户、用户和其他人，系统或产品的目标是什么，想要实现什么，系统和产品如何满足业务的要求，最终系统或产品如何利用于日常工作。
3.精化（Elaboration-requirement modeling）：在起始和导出阶段获得的信息将在精化阶段进行扩展和提炼该任务集中于开发一个精确的需求模型。
4.协商（Negotiation-win-win）：使用迭代的方法给需求排序，评估每项需求对项目产生的成本和风险，表述内部冲突，删除、组合和修改需求，以便参与各方均能达到一定的满意度，实现双赢。
5.规格说明（Specification-document，Model，prototype）：一个规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、一组使用场景、一个原型或上述各项的任意组合。
6.确认（Validation-Quality assess）：在确认这一步对需求工程的工作产品进行质量评估。
7.需求管理（Management-Change）：基于计算机的系统其需求会变更，并且变更的要求贯穿于系统的整个生存期。需求管理是用于帮助项目组在项目进展中标识、控制和跟踪需求以及需求变更的一组活动。

需求建模的元素

基于场景建模（功能）
使用基于场景的方法可以从用户的视角描述系统。
开发用例图时，应列出特定参与者执行的功能或活动。
例：

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

UML泳道图是活动图的一种有用变化，可以让建模人员表示用例所描述的活动流，同时指示哪个参与者或分析类是由活动矩形所描述的活动来负责。

基于类的建模
基于类建模表示了系统操作的对象、应用于对象间能有效控制的操作、这些对象间的关系以及已定义类之间的协作。
基于类的分析模型包括类和对象、属性、操作、类的职责协作者（CRC）模型、协作图和包。

识别分析类
外部实体（其他系统、设备、人员），产生或实验基于计算机系统的信息。
事物（报告、显示、字母、信号），问题信息域的一部分。
偶发事件或事件（所有权转移或完成机器人的一组移动动作），在系统操作环境内发生。
角色（经理，工程师，销售人员），由和系统交互的人员扮演
组织单元（部门，组，团队），和某个应用系统相关
场地（制作车间或码头），建立问题的环境和系统的整体功能
结构（传感器、交通工具、计算机），定义了对象的类或与对象相关的类。
例：

类-职责-协作者建模（CRC）
CRC模型实际上是表示类的标准索引卡片的集合。
顶部写类名，左侧列出类的职责，右侧部分列出了类的协作者。

类：
Entity classes 实体类：一般代表保存在数据库中和贯穿应用程序的事物。
Boundary classes 边界类：创建用户可见的和在使用软件时交互的接口
Controller classes 控制类：管理“控制单元”

职责：
职责的基本原则：
属性：描述了已经选择包含在需求模型中的类
操作：定义了某个对象的行为。
5个指导原则：
1.智能系统应分布哎所有类中以求最佳地满足问题的需求。
2.每个职责的说明应尽可能具有普遍性。
3.信息和与之相关的信息应局限于一个类中而不要分布在多个类中。
4.信息和与之相关的行为应该放在同一类中。
5.适合时，职责应由相关类共享。

生成行为模型
生成行为模型的步骤：
1.评估所有的用例，以保证完全理解系统内的交互顺序
2.识别驱动交互顺序的事件，并理解这些事件如何与特定的对象相互关联
3.为每个用例生成序列
4.创建系统状态图
5.评审行为模型以验证准确性和一致性。

状态图：
UML状态图就是一种行为模型，该图为每个类呈现了主动状态和导致这些主动状态变化的事件。
例:

顺序图：
表明事物引发从一个对象到另一个对象的转移。

软件设计（Software Design）

设计概念
1.抽象（Abstraction）：
过程抽象是指具有明确和有限的指令序列（描述动作）
数据抽象是描述数据对象的冠名数据集合（描述动作怎么做）

2.体系结构（Architecture）：软件的整体结构和这种结构为系统提供概念完整方式。构件表示主要的系统元素及其交互。

3.模式（Patterns）：模式承载了已证实的解决方案的精髓。设计模式描述了在某个特定场景与可能影响模式应用和使用方法的“影响力”中解决某个特定的设计问题的设计结构。

4.关注点分离（Separation of concerns）：它表明任何复杂问题如果被分解为可以独立解决和优化的若干块，该复杂问题能够更容易的被处理。

5.模块化（Modularity）：模块化是关注点分离最常见的表现。模块化设计使得开发工作更易规划。

6.信息隐蔽（Hiding）：隐蔽意味着通过定义一系列独立的模块可以得到有效的模块化，独立模块互相之间只交流实现软件功能所必须的那些信息。隐蔽定义并加强了对模块内过程细节的访问约束和对模块所使用的任何局部数据结构的访问约束。

7.功能独立（Functional independence）：开发具有“专一”功能和低耦合性的模块即可实现功能独立。

8.求精（Refinement）：通过连续精化过程细节层次来实现程序的开发，通过逐步分解功能的宏观陈述直到形成程序设计语言的语句来进行层次开发。
抽象和精化是互补的概念。

9.方面（Aspects）：一个方面作为一个独立的模块进行实施，而不是作为“分割的”或者和许多构件“纠缠的”软件片段进行实施。设计体系结构应当支持定义一个方面，该方面即一个模块，该模块能够使该关注点经过它横切的所有其他关注点而得到实施。

10.重构（Refactoring）：重构是使用这样一种方式改变软件系统的过程：不改变代码的外部行为而是改进其内部结构。

11.面向对象的设计概念（OO design concepts）:
面向对象概念（类、对象、继承、消息和多态）

12.设计类（Design Class）：提供设计细节，使程序得以实施。

设计概念强调了：
（1）抽象的必要性，它提供了一种创造可重用软件构件的方法
（2）体系结构的重要性，它使得能够更好地理解系统整体结构
（3）基于模式的工程的有益性，它是一项用于已证明能力的软件的设计技术
（4）关注点分离和有效的模块化的价值，他们使得软件更容易理解、更容易测试以及更容易维护。
（5）信息隐藏的直接作用，当错误发生时，它能够减少负面影响的传播
（6）功能独立的影响，他是构造有效模块的标准
（7）求精作为一种设计方法的作用
（8）横切系统需求方面的考虑
（9）重构的应用，他是为了优化已导出的设计
（10）面向对象的类和与类相关特征的重要性

设计模型（design model）
数据设计元素：数据设计创建在高级抽象级上表示的数据模型和信息模型。
体系结构设计元素：体系结构设计元素通常描述为一组相互关联系统的子系统，且常常从需求模型中的分析包中派生出来。
接口设计元素：软件接口设计元素描述了信息如何流入和流出系统以及被定义为体系结构一部分的构件之间是如何通信的。
接口设计有3个重要的元素：
（1）用户界面
（2）和其他系统、设备、网络或其他信息生成者或使用者的外部接口
（3）各种设计构件之间的内部接口
构件级设计元素：软件的构件级设计完整地描述了每个软件构件的内部细节。构件级设计为所以局部数据对象定义数据结构，为所有在构件内发生的处理定义算法细节，并定义允许访问所有构件操作的接口。
部署级设计元素：部署级设计元素指明软件功能和子系统将如何在支持软件的物理计算环境内分布。

体系结构设计
程序或计算机系统的软件体系结构是指系统的一个或者多个结构，它包括软件构件、构件的外部可见属性以及它们之间的相互联系。
体系结构并非可运行的程序。
确切的说，它是一种表达,是能够：
（1）对设计在满足既定需求方面的有效性进行分析
（2）在设计变更相对容易的阶段，考虑体系结构可能的选择方案
（3）降低与软件构造相关的风险

体系结构重要的3个关键原因
1.软件体系结构的表示有助于对计算机系统开发感兴趣的各方展开交流。
2.体系结构突出了早期的设计决策，这些决策对随后所有的软件工程工作有深远影响，同时对系统作为一个可运行实体的最后成功有重要作用。
3.体系结构“构建了一个相对小的、易于理解的模型，该模型描述了系统如何构成以及其构件如何一起工作”

体系结构风格
1.以数据为中心的体系结构。
2.数据流体系结构。
3.调用和返回体系结构
4.面向对象体系结构
5.层次体系结构

体系结构环境图（ACD）
上级系统：这些系统把目标系统作为某些高层处理方案的一部分
下级系统：这些系统被目标系统使用，并为完成目标系统的功能提供必要的数据和处理
同级系统：这些系统在对等的基础上相互作用
参与者：通过产生和消耗必要处理所需的信息，实现与目标系统交互的实体（人，设备）

构件级设计
构件的概念：
1.构件是计算机软件中的一个模块化的构造块。
2.OMG定义构件：系统中模块化的、可部署的和可替换的部件，该部件封装了实现并暴露一组接口。
面向对象的观点（Object-Oriented view）：构件包括一组协作的类。
传统观点（Traditional View）：一个构件就是程序的一个功能要素，程序由处理逻辑及实现处理逻辑所需的每部数据结构以及能够保证构件被调用和实现数据传递的结构构成。

基本设计原则
开闭原则（Open-Closed Principle ，OCP）：模块应该对外延具有开放性，对修改具有封闭性。
依赖倒置原则（Dependency Inversion Principle ，DIP）：依赖于抽象，而非具体实现。

Liskov替换原则（Liskov Substitution Principle (LSP)）：子类可以替换他们的基类。
接口分离原则（The Interface Segregation Principle (ISP)）：多个客户专用接口比一个通用接口好
发布复用等价性原则（The Release Reuse Equivalency Principle，REP）：复用的粒度就是发布的粒度
共同封装原则（The Common Closure Principle (CCP)）：一同变更的类应该合在一起
共同复用原则（The Common Reuse Principle (CRP））：不能一起复用的类不能被分到一组

内聚性（Cohesion）：内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有亲密关系的属性和操作。
功能内聚：主要通过操作来体现，当一个模块只完成某一组特定操作并返回结果时，就称此模块是功能内聚的。
分层内聚：高层能够访问低层的服务，但低层不能访问高层的服务。
通信内聚：访问相同数据的所有操作被定义在同一个类中。（数据的查询，访问，存储）

耦合性（Coupling）：
耦合是类之间彼此联系程度的一种定性度量。
随着类（构件）相互依赖越来越多，类之间的耦合程度亦会增加。
内容耦合：暗中修改其他构件的内部数据，这违反了信息隐蔽原则
公用耦合：当大量的构件都要使用同一个全局变量时发生这种耦合
控制耦合：当操作A调用操作B，并向B传递控制标记时，就会发生这种耦合。
标记耦合：当类B被声明为类A某一操作中的一个参数类型时，就会发生这种耦合。
数据耦合：当操作需要传递长串的数据参数时，就会发生这种耦合。
例程调用耦合：当一个操作调用另一个操作时，就会发生这种耦合。
类型使用耦合：当构件A使用了在构件B中定义的一个数据类型时，就会发生这种耦合。
包含或者导入耦合：当构件A引入或者包含一个构件B的包或者内容时，就会发生这种耦合。
外部耦合：当一个构件和基础设施构件进行通信和协作时，就会发生这种耦合。

为什么要高内聚?　　
　模块之间的关系越紧密,出错就越少!
　为什么要低耦合?　　
　子程序间的关系越复杂,就会产生更多的意想不到的错误!会给以后的维护工作带来很多麻烦!
　 高内聚低耦合，是软件工程中的概念，是判断设计好坏的标准，主要是面向对象的设计，主要是看类的内聚性是否高，耦合度是否低。

用户界面设计
黄金准则
1.用户操纵控制
（1）以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式
（2）允许用户交互被中断和撤销
（3）当技能级别增长时可以使交互流线化并允许定制交互
（4）使用用户与内部技术细节隔离开来
（5）设计应允许用户与出现在屏幕上的对象直接交互
2.减少用户的记忆负担
（1）减少对短期记忆的要求
（2）建立有意义的缺省
（3）定义直观的快捷方式
（4）以不断进展的方式揭晓信息
3.保持界面一致
（1）允许用户当前任务放入有意义的环境中
（2）在应用系统家族内保持一致性
（3）如果过去的交互模型已经建立起了用户期望，除非有迫不得已的理由，doze不要改变它。

可用性
可用性是指用户在使用高科技产品所提供的功能和特性时，对使用的容易程度和有效程度的定量测量。

用户界面的分析与设计
工程师建立用户模型。软件工程师创建设计模型。最终用户在脑海中对界面产生映像，称为用户的心理模型或系统感觉。系统的实现者创建实现模型。
用户模型：确定了系统最终用户的轮廓。
设计模型：用户界面的设计
心理模型：最终用户在脑海里对系统产生的印象。
实现模型：组合了计算机系统的外在表现，结合了所有用来描述系统语法和语言的支撑信息。

用户界面的分析和设计过程是迭代的，用户界面分析和设计过程开始于螺旋模型的内部，并且包括4个阶段：（1）界面分析及建模。（2）界面设计。（3）界面构造。（4）界面确认。

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

界面分析
在用户界面的设计中，理解问题就意味着了解：
（1）通过界面和系统交互的人
（2）最终用户为完成工作要执行的任务
（3）作为界面的一部分而现实的内容
（4）任务处理的环境

界面分析：
（1）用户分析：
设计师能够将用户心理模型与设计模型聚合在一起的唯一办法就是努力了解用户，以及了解用户是如何使用系统的。
可以从各种途径获得信息
用户访谈：软件团队（代表）与用户讨论。
销售输入：销售人员与用户定期见面。
市场输入：市场分析，分析/理解市场每个部分使用软件的细微差别。
支持输入：技术支持人员与用户访谈。

（2）任务分析与建模
任务分析的目标就是将这些技术应用到用户界面：
a.用例：用例描述了参与者和系统的交互方式。从用例描述中，软件工程师可以提炼出任务、对象和整个的交互过程。
b.任务细化：改进了交互流程。任务细化有两种方法：
1.理解实现活动目标而必须完成的任务
2.研究已有的基于计算机的解决方案的规格说明，并且得到一个适应于用户模型、设计模型和系统感觉的用户任务集合。
逐步细化。
c.对象细化：对象细化标识了接口对象
d.工作流分析：工作流分析定义了涉及多个人（和角色）时工作流程是如何完成的。
e.层次分析：
用户任务：请求重新填写处方
提供识别信息。
指定名称。
指定用户ID。
指定PIN和密码。
指定处方号码。
指定日期重填是必需的。

测试
测试：测试是在交付给最终用户之前以特定意图找出错误为目的来执行程序的过程。
验证与确认（Verification and Validation，V&V）：
验证是指确保软件正确地实现某一特定功能的一系列活动。
确认是指确保开发的软件可追溯到客户需求的另外一系列活动。

测试策略
从小到大

传统的测试策略
单元测试
单元测试侧重于软件设计的最小单元（软件构件或模块）的验证工作。
单元测试侧重于构件的内部处理逻辑和数据结构。
可以对多个构件并行执行。
测试模块的接口是为了保证被测试程序单元的信息能够正常地流入和流出；
检查局部数据结构以确保临时存储的数据在算法的整个执行过程中能维持其完善性。
执行控制结构中的所有独立路径（基本路径）以确保模块中的所有语句至少执行一次。
测试边界条件确保模块在到达边界值得极限或受限处理的情形下仍能正确执行。
最后要对所有的错误处理路径进行测试。

在单元测试期间，选择测试的执行路径是最基本的任务。
边界测试时最重要的单元测试任务之一。

单元测试过程

驱动模块：接收测试用例数据，将这些数据传递给被测模块，并输出结果。
桩：替换那些从属于被测模块的模块
当设计高内聚的构件时，就可以简化单元测试。当构件只强调一个功能时，测试用例数就会降低，且比较容易预见错误和发现错误。

集成测试
集成测试时构造软件体系结构的系统化技术，同时也是进行一些旨在发现与接口相关的错误的测试。
集成测试的目标是利用单元测试的构件建立设计中描述的程序结构。

自顶向下集成：自顶向下集成测试是一种构造软件体系结构的增量方法。
深度优先：深度优先集成是首先集成位于程序结构中主控路径上的所有控件。
广度优先：广度优先集成首先沿水平方向，将属于同一层的构件集成起来。
自顶向下集成过程：
1.主控模块作为测试驱动模块，用桩模块代替直接附属的下层模块；
2.根据所选的集成策略（深度优先/广度优先），每次用一个实际模块替换一个桩模块；
3.每集成一个模块都进行测试；
4.完成每个测试集之后，用实际模块替换另一个桩模块；
5.可以进行回归测试（即全部或部分地重复已做过的测试），以避免引入新错误。
回到第2步继续执行此过程，直到完成整个程序结构的构造。

自底向上集成测试：就是从原子模块（程序结构的最底层构件）开始进行构造和测试。
自底向上集成测试过程：
1.连接底层构件以构成完成特定子功能的簇。
2.编写驱动模块（测试的控制程序）以协调测试用例的输入和输出
3.测试簇
4.去掉驱动程序，沿着程序结构向上逐步连接簇

回归测试
回归测试重新执行已测试过的某些子集，以确保变更没有传播不期望的副作用。
回归测试有助于保证变更不引入无意思行为或额外的错误。
回归测试可以手工进行，方法是重新执行所以测试用例的子集，或者利用捕捉/回放工具自动进行。

面向对象软件的测试策略
面向对象软件的类测试等同于传统软件的单元测试。
不同的是：
传统软件单元测试侧重于模块的算法细节和模块接口数据；
面向对象类的测试侧重于封装在该类中的操作和类的状态行为。
封装的类是单元测试的重点，但不再孤立地对单个操作进行测试，而是将其作为类的一部分。
簇测试时面向对象软件集成测试中的一个步骤。

确认测试（Validation Testing）
确认测试准则：软件确认是通过一系列表明与软件需求相符合的测试而获得的。

α测试（Alpha testing）：α测试测试是由代表性的最终用户在开发者的场所进行。软件在自然的环境下使用，开发者站在用户的后面观看，并记录错误和使用问题。α测试在受控的环境下测试。

β测试（Beta testing）（又称客户验收测试，Acceptance testing）：β测试在一个或多个最终用户场所进行。与α测试不通过，开发者通常不在场，因此，β测试是在不为开发者控制的环境下软件的“现场”应用。是在不可控的环境下测试。

系统测试
系统测试实际上是对整个基于计算机的系统进行一系列不同考验的测试。所有测试都是为了验证系统成分已经正确地集成在一起，并且完成了指派的功能。

恢复测试（Recovery testing）:通过各种方式强制让软件以各种方式失败并验证恢复是否正确执行。
安全测试（Security testing）：安全测试验证建立在系统内的保护机制是否能够实际保护系统不受非法入侵。
压力测试（Stress testing）：压力测试的目的是是软件面对非正常的情形。是一种要求以非正常数量、频率或容量的方式进行彻底评估。
性能测试（Performance testing）：性能测试用来测试软件在集成环境中的运行性能。
部署测试（Deployment testing）：部有时也将署测试称为配置测试，是在软件将要在其中运行的每一种环境中测试软件。

测试传统的应用系统
白盒测试：白盒测试有时也称为玻璃盒测试，是一种测试用例设计方法，它利用作为构件层设计的一部分描述的控制结构来生成测试用例。
白盒测试是在了解模块内部结构的情况下进行的测试。
利用白盒测试方法导出的测试用例可以：
（1）保证一个模块中的所有独立路径至少被执行一次。
（2）对所有的逻辑判定均需要测试取真和取假两个方面。
（3）在上下边界及可操作的范围内执行所有的循环。
（4）检验内部数据结构以确保其有效性。

基本路径测试（Basic path testing）
基本路径测试时由TOM首先提出的一种白盒测试技术。
流图（程序图）是一种简单的控制流表示方法。
流程图用于描述程序的控制结构，流程图映射为相应的流图。
圆称为流图结点（flow graph node），表示一个或多个过程语句。处理框序列和一个菱形判定框可以映射为单个节点。
流图中的箭头称为边或者连接，标识控制刘，类似于流程图中的箭头。
由边和结点限定的区域称为域。当计算域时，将图的外部作为一个域。
包含条件的结点称为判定结点，其特征是由它发射出两条或多条边。

独立路径是指任何贯穿程序的、至少引入一组新语句或一个新条件的路径。
如果设计测试用例强迫执行这些路径（基本集合），就可以保证程序中的每条语句至少执行一次，同时，每个条件判断的真和假都被执行。

环复杂度（Cyclomatic Complexity ）计算方法：

V（G）的值提供了组成基本集合的独立路径的上街，并由此得出覆盖所有程序语句所需设计和运行的测试数量的上界。

黑盒测试
黑盒测试也称为行为测试，侧重软件的功能需求。
黑盒测试使软件工程师能设计出将测试程序所有功能需求的输入条件集。
黑盒测试不是白盒测试的替代品，而是作为发现其他类型错误的辅助方法。
黑盒测试试图发现以下类型的错误：
（1）不正确或遗漏的功能
（2）接口错误
（3）数据用在测试的后期阶段
（4）行为或性能错误
（5）初始化和终止错误
黑盒测试的方法：
Graph-based testing methods 基于图的测试方法
Equivalence partitioning 等价类划分
Boundary value analysis 边界值分析
Orthogonal array testing 正交数组测试

黑盒测试的例子：

---

作者：qq_36146165
来源：CSDN
原文：https://blog.csdn.net/qq_36146165/article/details/78988521
版权声明：本文为博主原创文章，转载请附上博文链接！