软件工程复习

致性的方式来描述数据（信息）、功能和行为的需求。图形化的表示
分析模型可以增强对软件需求的理解，也为软件设计奠定了基础。 （4）生成需求规格说明。
需求分析阶段活动、建模的原因、方法、模型的种类、作用。2/2
建模方法：
1.结构化分析 2.面向对象的分析
目标：
分析建模目标是创建各种表现形式以描述软件信息、功能和行为的需求。 具体建模方法：
测试用例设计方法：3/3
其它需要考虑的问题：
以上测试用例的设计主要考虑选取合适的操作序列，还要考虑操作的 参数（接口），在选择参数时可对参数划分等价类，每个输入参数属于一 个等价类，同时还需考虑参数的边界情况。
（3） 增量模型
1. 2. 反复的应用瀑布模型的基本成分和原型模型的迭代特征，每一个线型过程产 生一个“增量”的发布或提交，该增量均是一个可运行的产品。 第一个增量往往是核心产品，即满足用户的基本需求，提供给用户评估的平 台, 以便制定下一个增量计划。
（4） 螺旋模型：
1.适合于大型系统的软件开发，随着过程的进展演化，开发者和用户能够更好的识 别和对待每一个演化级别上的风险。 2.演进的方法不一定可控，依赖于相当丰富的风险评估经验来保证成功。
计测试用例技术。
4.错误推测。根据经验或直觉推测程序中可能存在的各种错误，有针对性的设计检 查这些错误的测试用例。 5.使用判定表。如果功能说明中含有多个输入条件的逻辑组合，可以建立判定表， 判定表的每一列对应一个测试用例。
测试用例设计方法：1/3
传统的测试用例设计是由软件的输入、加工、输出视图或个体模块的算法细节驱动 的，面向对象测试关注于设计合适的操作序列以测试类的状态和用例的实现。 一、类级的测试用例设计（单元测试） 着重于单个类及封装的操作。可按照以下方法设计用例： ① 随机测试：类的操作隐含了一些限制（例如，银行客户账号必须在其它操作可 应用前被打开，在所有操作完成后被关闭）。同时，一项操作可能导致一系列操作 序列随机产生，因此可随机选取其它的测试序列以测试该类对象不同的生命历史。 ② 划分测试：可以减少测试类所需的测试用例的数量，采用与传统测试的等价划 分相同的方式，即输入、输出被分类，为处理每个类别设计测试用例。划分类别的 具体方法是： • 基于状态的划分：基于类操作改变类状态的能力来对类操作分类，分别独立测 试改变状态的操作和不改变状态的操作。 • 基于属性的划分：根据操作使用的属性来划分类操作，即使用相同属性的操作 划分在一个等价类中， 然后对每个划分设计测试序列。 • 基于操作类别的划分：如在银行客户账户类中的操作可被分类为：初始化操作、 计算操作、查询操作、和终止操作。 ③ 从行为模型导出的测试 类的STD可用于帮助导出测试类的动态行为的测试序列。所涉及的测试应覆盖所有 的状态，即操作序列应该导致account类的转换穿越所有允许的状态。
沟通 项目启动 需求获取
策划
项目估算 进度计划 项目跟踪
建模
分析 设计
构建 编码 测试 部署 交付 支持 反馈
（2） 原型模型
分为抛弃型、实验型、演化行三种。建造原型仅是为了定义需求，之后就被抛弃， 实际的软件在充分考虑了质量和可维护性之后才被开发。 缺点：a.为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。b. 为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不 理想的选择成了系统的组成部分。c.开发过程不便于管理。
仓库风格（容器模型），管道－过滤器风格（数据流模型），调用－返回风格(主 程序-子程序结构)，面向对象风格，层次式风格（虚拟机模型），基于事件的隐式 调用风格，客户机/服务器模型，对等体系结构，正交软件体系结构。
设计模式的概念、面向对象软件系统分类、原则、要素。
概念：是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结， 是软件工程的基石 。使用设计模式是为了可重用代码、让代码更容易被他人理解、 保证代码可靠性。 分类：应用程序、工具箱和框架； 原则： 1、“开－闭”原则：模块应对扩展开放，而对修改关闭。 2、里氏代换原则：如果调用的是父类的话，那么换成子类也完全可以运行。 3、合成复用原则：少用继承，多用合成关系来实现。 4 依赖倒转原则：抽象不应该依赖与细节，细节应当依赖与抽象。要针对接口编程， 而不是针对实现编程。 5 接口隔离原则：定制服务的例子，每一个接口应该是一种角色。 6 抽象类：抽象类不会有实例，一般作为父类为子类继承，一般包含这个系的共同 属性和方法。 7 迪米特法则：最少知识原则。 四个基本要素：模式名称，问题 ，解决方案 ，效果。
它包含了写、需求有效性验证、需求管理。
需求分析活动具有以下任务：
（1）分析需求的可行性：允许的成本、性能；与其他需求的冲突；外界因 素的依赖和技术障碍等。
（2）对于渐增式开发要确定需求的优先级别，以便确立产品版本。
（3）建模：模型能突出或强调某些关键的系统特征。使用文本和图表形式 的组合，以相对容易理解和能直接评审正确性、完整性和一致性的方
体系结构设计为什么重要？
• 体系结构是系统的高层表示，有利于项目人员之间沟通。
• 体系结构的设计对系统能否满足关键性需求如系统的性能、可靠性、可 维护性等属性的评估有极深的影响。
• 体系结构能在具有相似需求的系统之间复用。
软件体系结构不仅指出了系统的组织结构和拓扑结构，并显示了系统需求 和构成系统元素之间的对应关系，提供了软件如何设计的重要决策。 体系结构的风格：
黑盒测试2/2
几种方法： 1.基于图的测试方法:事务流建模、有限状态建模、数据转换流建模、时间建模. 2.等价类划分：主要思想：根据被测对象的功能说明和输入域，按合理的或不合理 划分为若干等价类，为每个等价类设计一个测试用例，这样大大减少测试次数，提 高测试效率。 步骤：①划分等价类②设计测试用例 3.边界值分析。输入域的边界比中间更容易发现错误，是一种补充等价类划分的设
方法、实践和变换。通俗的说，是为建造高质量软件所需完成的任
务的框架，即形成软件产品的一系列步骤，包括中间产品、资源、 角色及过程中采取的方法、工具等范畴。 【软件过程模型：软件过程中定义了如下框架活动：沟通、策划、 建模、构建、部署。这些活动如何衔接，开发过程中采用什么样的 策略，应遵守什么样的规定和制约，将这些活动及其关联用一种模 型表示出来，称为软件过程模型（或软件开发模型）】
⑴ 瀑布模型（线性顺序模型）
• • • • • 提供了软件过程模型的基本框架（模板）。 强调了每一阶段活动的严格顺序。 质量保证观点：以经过评审确认了的阶段工作产品（文档）驱动下一阶段的 工作，便于管理。 是一种整体开发模型，程序的物理实现集中在开发阶段的后期，用户在最后 才能看到自己的产品。 适合于用户需求明确、完整、无重大变化的软件项目开发。
数据设计： 构件级：数据结构和操作它们的相关算法；
应用级：数据模型到数据库的转换；
业务级：存储在不同数据库并重新组织为“数据仓库”的信息的集合产生 了数据挖掘技术。
体系结构的概念，设计体系结构的重要性。体系结构的风格或模式。
软件体系结构(Architecture)是构造系统的基本框架，为软件系统提供了一个结构、 行为和属性的高级抽象。由构成系统的元素（构件）的描述、这些元素的相互作用、 指导元素集成的模式以及模式的约束组成。
式来描述数据（信息）、功能和行为的需求。图形化的表示分析模型
可以增强对软件需求的理解，也为软件设计奠定了基础。 （4）生成需求规格说明。
需求分析阶段活动、建模的原因、方法、模型的种类、作用。1/2
需求工程是一个包括创建和维持系统需求文档所必需的一切活动的过程。
它包含了如下活动：系统可行性研究、需求获取和分析、需求描述和文 档编写、需求有效性验证、需求管理。
（5） 形式化方法模型 1. 对系统需求的分析在软件开发的早期阶段完成。 2. 是对非形式化描述技术的补充，可以用来精化非形式化的详细的系统需求描述。 描述是精确的和无二义的，避免了由于语言误解而产生的一些问题。形式化 描述可用来描述标准。 3.最适合用于安全性、可靠性和保密性等性能要求极高的系统。 形式化开发记录 与需求比 较后修正 变换n …… 形式化 规格说明 变换2 变换1 系统需求 设计逻辑或 目标系统 验证
（6）构件组装模型： 该模型是软件体系结构被建立后用构件去充实。这些构件可从复用 库（或商品库）中获得，或者根据专门需要而开发。整个过程 可以演化地进行，面向对象方法给予技术上的支持。
需求分析阶段的活动、建模的方法、模型的种类、作用。
需求工程是一个包括创建和维持系统需求文档所必需的一切活动的过程。
软件测试的策略、方法1/2 软件测试策略包括测试计划、测试用例设计、测试结果评估等。
测试方法分为两类： （1）黑盒 (Black-box)或闭盒（Closed-box）法 不考虑被测程序的内部结构和处理过程，只关心它的输入和输出是否能达到 预期结果，因此也称为功能性测试。【他必须依靠能够反映这一关系和程序功能的 需求规格说明书考虑确定测试用例，和推断测试结果的正确性。即所依据的只能是 程序的外部特性。因此，黑盒测试是从用户观点出发的测试。 】 （2）白盒(White-box)或开盒（Open-box）法 使用更细致的测试策略，检查被测程序的内部逻辑与结构。 软件测试步骤： 1、单元测试:完成对最小的软件设计单元－软件组件或模块的测试。任务:模块接 口,局部数据结构,重要的执行路径,错误处理路径,边界条件。【白盒】 2、集成测试：也称为组装测试。对单个组件或模块的测试达到目标之后，将它们 组合成一个能工作的系统以发现组件交互中的问题。【黑盒】 3、系统测试：含功能测试、性能测试、强度测试、 容量测试、 恢复测试、安全 测试。 4、用户确认的测试：验收测试、安装测试。
• 对每个客户类，使用类操作列表生成随机测试序列，这些操作将向其他服务 类发送消息。 • 对生成的每个消息，确定协作类和服务对象中的相应操作。 • 对服务对象中的每个操作，确定它所发送的消息。 • 对每个消息，确定下一层被调用的操作并将其引入到测试序列中。 ② 划分测试 类似于单个类划分测试方法，但需扩展测试序列以包括那些通过发送给协作 类的消息而激活的操作。 ③ 基于交互场景的测试 先测试那些最常用到的交互场景，不寻常的或异常的场景放在稍后测试。交 互场景可以从设计的用例中来，为了补充测试信息，需要用时序图来更详细说明对 象是如何完成一个场景的。