标签：bre 情况下 子类 种类型 bsp 输入数据 第一章 取值 条件测试
软件是计算机程序、规程以及运行计算机系统可能需要的相关文档和数据，从软件的内容来看，软件更像是一种嵌入式的数字化知识，其形成是一个通过交互对话和抽象理解而不断演化的过程，根据软件服务对象的范围，一般分为通用和定制两种。
复杂性、不可见性、可变性、一致性
软件是复杂的，软件是人类思维和智能的一种延伸和在异体上的再现，远比任何以往人类的创造物都要复杂的多，软件的复杂性是软件的固有属性、本质特性。
软件是不可见的，软件是客观世界空间和计算机空间之间的一种逻辑实体，不具有物理的形体特征。
软件是不断变化的，它需要随着应用、硬件、用户和社会等各种因素的变化而不断的被修改和扩展。
软件必须遵从人为的惯例并适应已有的技术和系统，软件需要随接口的不同而改变，随时间的推移而变化，而这些变化是不同的人设计的结果，许多复杂性来自保持与其他接口的一致，对软件的任何再设计，都无法简化这些复杂特性。
软件工程以关注软件质量为目标，包括过程、方法和工具三要素
功能性、可靠性、可使用性、有效性、可维护性、可移植性
软件过程是软件工程人员为了获得软件产品而在软件工具的支持下实施的一系列软件工程活动。
问题提出、软件需求规格说明、软件设计、软件实现、软件确认、软件演化
软件过程模型描述软件过程的整体框架，是软件过程的一种抽象表示。
软件过程模型包括：瀑布模型、快速原型模型、增量模型、螺旋模型、形式化方法模型、基于组件的开发模型
瀑布模型 将软件过程划分为需求定义与分析、软件设计、软件实现、软件测试、软件运行与维护等一系列基本活动。以上活动自上而下、相互衔接的固定顺序，如瀑布流水，逐级下落。
快速原型模型 快速原型模型的第一步是迅速构建一个可以运行的软件原型，实现用户与系统的交互，由用户对该原型进行评价，进一步细化待开发软件需求。结果逐步调整使其满足用户的要求之后，开发人员可以将用户的真正需求确定下来。第二步则在第一步的基础上开发用户满意的软件。（特点：有效适应用户需求的变化不知循环多少次，进度难以控制）
增量模型 增量模型在各个阶段并不一定交付一个可运行的完整产品，而是交付满足用户需求的一个子集。第一个增量往往是实现基本需求的核心产品，交付用户使用后，经过评价形成下一个增量的开发计划，其中包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。
螺旋模型 将瀑布模型和快速原型模型结合起来，强调了风险分析，特别适合大型复杂软件系统（优点：风险驱动（关注软件的重用、关注早期错误的消除、将质量目标放在首位、将开发阶段与维护阶段结合在一起）（缺点：需要风险评估的经验适应内部大规模软件开发）
形式化方法模型 首先将软件需求描述提炼成采用数学符号表达的形式化描述；然后经过一系列的形式化转换将形式化描述转换成可执行程序；最后将整个系统集成起来测试。 (优点：由于数学方法具有严密性和准确性，形式化方法开发过程所交付的软件系统具有较少的缺陷和较高的安全性) (缺点：开发人员需要具备一定技能并经过特殊训练;形式化描述和转换是一项费时费力的工作,成本高，质量不一定高;现实应用的系统大多数是交互性强的软件，但是这些系统难以用形式化方法进行描述)
就是在项目活动中运用相关知识, 技能, 工具和技术满足项目的要求。
启动、计划、监督、控制、收尾
一个不确定的事件或者情况，若其一旦发生，会对项目的目标，例如，范围、进度、成本和质量，产生积极或消极的影响。
特点:事先难以确定；一旦发生将带来损失，影响项目实施，甚至会导致项目失败
类别:软件规模、商业影响、客户特性、软件过程、开发技术、开发环境、开发人员
风险识别→风险评估→风险管理计划→风险监控
风险识别是试图采用系统化的方法，识别特定项目已知和可预测的风险 风险识别的常用方法是建立风险条目检查表，即利用一组提问来帮助项目管理者了解在项目和技术方面的一些风险。
描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节
是从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求，包括过程需求、产品需求和外部需求等类型。
需求工程是应用已证实有效的原理和方法，并通过合适的工具和符号，系统地描述出待开发系统及其行为特征和相关约束。
用户面谈、需求专题讨论会、现场考察、原型化方法、基于用例的方法 基于用例的方法 通过用例模型，明确系统功能
特点：以任务和用户为中心、有助于客户了解系统功能、有助于开发人员理解用户需求、可以采用面向对象分析和设计方法将用例转化为设计模型
关联是对象属性之间的静态联系，它通过对象的属性来表现对象之间的依赖关系
关联关系是类与类之间最常用的一种关系，它是一种结构化关系，表示has-a关系，往往表现为B作为A的属性存在（A关联B）
依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。表示要做一件事情，离不开某个对象，往往表现为B作为A的方法参数存在（A依赖B）
聚合关系表示一个整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构，从而找出一些成员类，该整体类和成员类之间就形成了聚合关系。
在分析模型中，分析类是概念层次上的内容，用于描述系统中较高层次的对象，分析类直接与应用逻辑相关，而不关注技术实现的问题，分析类从软件的功能需求来看分为实体类、边界类和控制类
理解用例模型→识别分析类→定义交互行为→建立分析类→评审分析模型
模块化、高内聚、低耦合、复用性
涉及软件系统的总体组织、全局控制、数据存取以及子系统之间的通信协议等。
典型软件体系结构：仓库体系结构、分层体系结构、MVC体系结构、客户机/服务器体系结构、管道和过滤体系结构
仓库体系结构：在仓库体系结构中，有两种不同的软件部件：一个表示当前的中心数据结构和一组相互独立的处理中心数据的子系统。仓库体系结构无需在子系统之间进行数据转换，因而是一种共享大量数据的高效方法，而且只要与共享模型一致，新的子系统就可以很容易的增加到系统中
分层体系结构：层次化是一种概念，它将软件设计组织成为类或组件的层次或集合，在同一个层次上的类或组建完成一个特定的目的，良好的层次结构可以易与系统的扩建与维护，不同的层次之间通过接口进行通信
MVC子系统：在MVC体系结构中，子系统划分成不同的三种类型：模型子系统负责存储系统的中心数据；视图子系统负责将模型中的数据展示给用户；控制器子系统负责管理与用户的交互控制
客户机/服务器子系统：在客户机/服务器体系结构中，作为服务器的子系统为其他客户的子系统提供服务，作为客户机的子系统负责与用户的交互。
管道和过滤体系结构：在管道和过滤体系结构中，数据在不同的子系统之间流动，每一个子系统处理输入的一组数据，并将处理结构输出给其他子系统。
方法建模、属性建模、状态建模、关系建模
也就是继承关系，也称为“is-a-kind-of”关系，泛化关系用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。在UML中，泛化关系用带空心三角形的直线来表示。
广义讲，软件设计模式是可解决一类软件问题并能重复使用的软件设计方案；狭义讲，设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。是在类和对象的层次描述的可重复使用的软件设计问题的解决方案。 分类
对象模式 - Factory模式（工厂模式） 对象型创建模式
父类负责定义创建对象的公共接口，而子类则负责生成具体对象，将类的实例化操作延迟到子类中完成。
- Adapter模式（适配器模式）
将一个类的接口适配成用户所期待的接口。一个适配器允许因为接口不兼容而不能在一起工作的类在一起工作。做法是将类自己的接口包装在一个已经存在的类中。
- Bridge模式（桥梁模式）
将问题的抽象和实现分离开来实现，通过用聚合代替类继承来解决子类爆炸性增长的问题。
- Façade模式（外观模式）
为子系统提供一个更高层次、更简单的接口，从而降低了子系统的复杂度，使子系统更易于使用和管理。
将所有模块按照设计要求组装成一个完整的系统而进行的测试，也称组装测试或联合测试，目的是发现与接口有关的各种错误方法 非增量式测试（把所有的模块按设计要求组装在一起进行的整体测试）、增量式测试（逐个把模块组装到已经测试过的模块上去，进行集成测试。每加入一个新模块进行一次集成的测试，重复此过程直至程序组装完毕）、
通过集成测试后，软件已经完全组装了起来，接口方面的错误也已排除，这时就可以对软件进行最后的确认测试。
把软件、硬件和环境连接在一起，在实际运行环境下进行全面测试，验证系统各部件是否都能够正确工作并完成任务。
该方法把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试，依据需求说明书，检查程序是否满足功能要求。
方法：等价类划分、边界值分析、错误推测等
该方法把测试对象看作一个打开的盒子，测试人员须了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错、实际的运行状态与预期的状态是否一致。
方法：逻辑覆盖、基本路径测试
1) 如果某个输入条件规定了取值范围或值的个数，则可确定一个合理的等价类(输入值或数在此范围内)和两个不合理的等价类（输入值或数不在此范围） 2) 如果规定了输入数据的一组值，而且程序对不同的输入值做不同的处理，则每个允许的输入值是一个合理等价类，此外还有一个不合理等价类（任何一个不允许的输入值） 3) 如果规定了输入数据必须遵循的规则，可确定一个合理等价类（符合规则）和若干个不合理等价类（从各种不同角度违反规则） 4) 如果已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分为更小的等价类
软件被投入运行使用后人们对软件产品所进行的修改 目的：为了修改软件缺陷或增加新的功能而对软件进行的变更。 软件变更通常发生在局部，不会改变整个结构
特点：受开发过程影响大、维护困难多、维护成本高
过程：维护申请→维护分类→影响分析→版本规划→变更实施→软件发布
软件再工程以系统理解为基础，结合反向工程、重构和正向工程等方法，将现有系统重新构造成为新的形式。形象地说，就是“把今天的方法学用于昨天的系统以满足明天的需要”。
标签：bre 情况下 子类 种类型 bsp 输入数据 第一章 取值 条件测试
原文地址：https://www.cnblogs.com/qinnian/p/11676904.html
