软件工程期末复习

软件测试

1. 软件测试，是为了发现错误而执行程序的过程
2. 测试阶段的根本目标是尽可能多的发现软件中潜藏的错误，用尽可能少的测试用例，发现尽可能多的软件错误
3. 测试不能直接提高软件质量，软件质量的提高要依赖软件开发
4. 软件测试贯穿软件开发的整个生命周期，单元测试，集成测试，系统测试，验收测试
5. 测试是为了证明程序有错，而不是证明程序无错，一个成功的测试应该是发现了至今未发现的错误
6. 测试包含了分析或运行软件，分析软件产品的过程称为静态测试，运行软件的测试过程称为动态测试
7. 软件测试两个基本功能：验证和确认，验证产品的正确性，确认保证生产了正确的产品
8. 软件测试是贯穿整个软件开发生命周期、对软件产品 （包括阶段性产品）进行验证和确认的活动过程，其目的 是尽快尽早地发现在软件产品中所存在的各种问题
9. 软件测试核心在于对测试用例的设计
10. 测试人员的工作：֍规划测试任务 ֍设计测试 ֍建立一个合适的测试执行环境 ֍评估、获取、安装和配置自动测试工具 ֍执行测试 ֍撰写适当的测试文档及报告
11. 制定测试计划：提取测试需求 →制定测试策略 →确定所需资源及日程安排 →制定计划与测试文档
12. 测试用例三个要素：前提条件和操作步骤、预期结果、实际结果
13. 测试用例设计的基本原则： →数量越少越好 →典型性越高越好 →对缺陷的定位性越强越好
14. 缺陷报告：缺陷的严重性是指缺陷对与软件产品使用的影响程度，缺陷的优先级是缺陷应被修复的紧急程度，这两个的级数都随数字的增大而减小
15. 软件测试类型：
16. 静态测试方法
    1. 不运行被测试的软件，通过人工分析或程序正确性证明的方式来对需求规格说明书，软件设计说明书，源程序做检查和审阅
    2. 很大部分取决于测试人员的经验
17. 动态测试：输入数据，运行软件，观察结果
    1. 白盒测试（玻璃盒测试，结构测试，逻辑驱动测试）：知道产品的内部工作流程，检验产品内部动作是否按照规格说明书正常进行
       1. 测试人员对内部的逻辑路径进行测试，
       2. 每条路径都测试耗时较长，不太现实
          1. 语句覆盖：每条语句都至少执行一次
          2. 判定覆盖：每个分支都至少执行一次
          3. 条件覆盖每一个判定，分别按照真，假，至少各执行一次
          4. 判定/条件覆盖：同时满足判定覆盖和条件覆盖的要求
          5. 条件组合覆盖：可能的条件组合至少都执行一次
       3. 不知道有多少个测试用例，不知道测试路径
          1. 基本路径覆盖法
    2. 黑盒测试（行为测试，功能测试，接口测试）：知道产品应该具有的功能，检验产品的每个功能是否能正常使用
       1. 等价类划分法（等价分配）：将测试里面作用相同的划分成一类：有效等价类(合理等价类) ֍无效等价类(不合理等价类) ֍划分等价类的标准
       2. 边界值分析法：以选取正好等于、刚刚大于或小于边界值作为测试数据。
       3. 场景法：对 应不同的业务 场景生成相应的测试用例
       4. 错误推测法：根据经验、直觉和预感来进行测试
       5. 因果图法
18. 
19. 单元测试又称模块测试——程序模块进行正确性检验的测试 工作，试主要采用白盒测试方法设计测试用例，辅之以黑盒测试的 测试用例   需要在5个方面对被测模块进行检查： 1、模块接口测试 2、局部数据结构测试 3、重要路径测试 4、错误处理测试 5、边界测试
20. 集成测试（Integration Testing）是在单 元测试的基础上，将所有模块按照总体设计 的要求组装成为子系统或系统进行的测试。 也叫组装测试或联合测试。
    1. 一次性集成方式：每个模块分别进行模块测试，然后再把所有模块组装在一起进行 测试，最终得到要求的软件系统。
    2. 渐增式集成测试即把一个要测试的模块同已经测试好的模块结合起来进 行测试，测完后，再把下一个应该测试的模块结合进来测试
       1. 自顶向下集成方式（Top-Down Integration）：是一个递增的组装 软件 结构的方法。从主控模块（主程序）开始沿控制层向下移，把模块一一组合 起来。分两种方法： →深度优先：按照结构，用一条主控制路径将所有模块组合起来。 →宽度优先：逐层组合所有下属模块，先在每一层完成水平集成
       2. 自底向上集成方式：从程序模块结构中最底层的模块开始组装和测试。因 为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包 括子模块的所有下属模块）事前已经完成组装并经过测试，所以不再需要编 制桩模块，但需要设计驱动模块。最常用的一种集成方法。
    3. 核心系统先行集成测试，先对核心软件部件进行集成测试，对可快速开发软件很有效果，能够保证一 些重要的功能和服务的实现
    4. 高频集成测试：同步于软件开发过程，每隔一段时间对开发团队的现有代码进行一次集成测试
21. 系统测试：将已经确认的软件、计算机硬件、外设、网络等其他元 素结合在一起，进行信息系统的各种组装测试和确认测试
    1. 功能测试（Functional Testing）：从用户角度进行测试，又称 “确认测试”。包括用户界面测试、各种操作测试、不同的操作数据、 数据输出与存储等。采用黑盒测试法。
    2. 性能测试（Performance Testing）是在实际或模拟实际的运行环 境下，针对非功 能特性所进行的测试。
22. 验收测试：用户将其用 于执行软件的既定功能和任务。
    1. Alpha测试：由开发者模拟用户
    2. Beta测试：由软件的最终用户
23. 回归测试是指重新执行已经做过的测试的某个子 集，以保证修改变化没有带来非预期的副作用。
24. 冒烟测试（Smoke Testing）是一种软件测试方法，用 于验证软件的基本功能是否按预期工作。通常在软件开发过 程中的代码提交、集成或发布新版本之前进行，目的是快速 发现明显的错误或问题，确保软件的核心功能没有被破坏。风险
25. 
26. 面向对象测试：类是测试的基本单元

软件维护

1. 调试（也称为纠错）作为成功测试的后果出现，也就是说， 调试是在测试发现错误之后排除错误的过程。是把症状和原因联系起来
2. 项目验收交付时，还有三项工作在等着：实施、培训、 验收。
3. 项目实施是将软件系统部署到客户方的计算机系统上， 协助客户准备基础数据， 使软件系统顺利上线运行。
4. 培训：在系统部署完成、基础数据准备齐全之后，应该组织 客户培训，使其掌握对软件系统的使用和操作。
5. 验收：客户对系统进行验收测试，包括范围核实（用户需求 是否全部实现）和质量核实 （质量属性是否满足要求）
6. 软件的变化是不可避免的（更觉得是更新）
7. 软件维护是软件生命周期中时间最长、费 用最高、越来越难的活动。消耗的工作量就比 较多，其工作量占整个生存周期的70%以上
   1. 改正性维护：在软件交付使用后，因开发时测试的不彻底、不完全， 必然会有部分隐藏的错误遗留到运行阶段
   2. 适应性维护：使用过程环境发生变化
   3. 扩充与完善性维护：用户往往会对软件提出新的功能 与性能要求
   4. 预防性维护（软件再工程）：是重新构造或编写 现有系统的一部分或全部，但不改变其功能
      1. 逆向工程是以复原软件的规格说明和设计为目标的软件分析过程。 ֍大多数情况下，逆向工程弥补缺乏良好文档的问题。 ֍开发阶段的文档与维护阶段的文档可能是不一致的
8. 影响维护成本的因素：
   1. 团队稳定性：：系统移交后开发团队会解散，人员分配到其他 项目中，负责维护的人员通常不是原开发人员，需要花时间 理解系统
   2. 程序年龄与结构：程序结构随年龄增加而受到破坏，不易理 解和变更。
   3. 人员技术水平：维护人员有可能缺乏经验，而且不熟悉 应 用领域
   4. 合同责任：维护合同一般独立于开发合同，这样开发人员有 可能缺少为方便维护而写软件的动力。
9. 非结构化维护： → 软件的配置中只有源代码。 → 由于没有分析和设计文档，无法对程序的功能进行反向追踪，理解别人的代码是 很痛苦的事情。 →由于配置中没有测试文档，所以维护后的代码无法进行回归测试。因而导致程序 的结构化被不断的破坏，维护的质量无法得到保证。
10. 结构化维护： →待维护的软件的配置是完整的。 →用户提出的维护申请用正向追踪很容易从分析设计文档追踪直至代码中， 从而使维护人员很容易定位代码的维护点。所以这种维护不会破坏软件 的结构。 →结构化维护不仅能减少维护的工作量，还能提高维护的质量。
11. 软件文档应该满足下述要求： (1) 必须描述如何使用这个系统，没有这种描述时即使是最 简单的系统也无法使用； (2) 必须描述怎样安装和管理这个系统； (3) 必须描述系统需求和设计； (4) 必须描述系统的实现和测试，以便使系统成为可维护的。
12. 用户文档主要描述系统功能和使用方法，并不关心这些 功能是怎样实现的。
13. 系统文档描述系统设计、实现和测试等各方面的内容。
14. 文档是影响软件可维护性的决定因素

软件开发

1. 软件开发就是通过对模型的逐步细化，模型从分析模型到设计模型再到编码模型
2. 对目标系统进行需求建模后，进入到系统分析和概要设 计阶段。 ֍ 在该阶段中，将在需求模型的基础上，对系统进行静态 建模和动态建模，构建出系统的软件架构。
3. 软件设计采用自顶向下、逐次功能展开的设计方法，先完成 总体设计，再完成各有机组成部分的设计。
4. 软件设计包括：系统结构设计（总体设计，概要设计，根据需求确立软件的框架）和系统过程设计（详细设计，软件的算法表示，数据结构）
5. 概要设计（总体设计）：包括系统的总体设计文档、各模块的概要 设计文档。在需求规格说明书的基础上描述系统的架构、功能模块 的划分、模块接口的定义、用户界面设计、数据库设计，概要设计不涉及系统内部的实现细节
6. 概要设计不涉及系统内部的实现细节，但它产生的实施方案与 策略将会影响最终软件实现的成功与否，并影响今后软件系统维护 的难易程度。
7. 详细设计（具体设计）：根据概要设计进行的模块划分，实现各模 块的算法设计，实现用户界面设计，表单，需要的数据，数据结构 设计的细化等。
8. OOD面向对象设计，OOA面向对象分析，分析要搞清楚系统“做什么”，设计要搞清楚“怎么做”
9. 软件的体系结构就像建筑师在设计一个建筑时所做的蓝图一样，首先设计建筑的框架结构
10. 框架和体系结构的关系：
    1. 体系结构的呈现形式是一个设计规约，而框架则是“半成品”的软件；
    2. 体系结构的目的是指导软件系统的开发，而框架的目的是设计复用。
    3. 框架给出的是整个应用的体系结构；而设计模式则给出了单一设计问 题的解决方案，且可以在不同的应用程序或者框架中进行应用。
11. “4+1”模型，从5个不同的视角，每一个视图只关心系统的一个侧面，逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构
12. 管道和过滤器风格的优点，支持软件重用，系统性能下降，并增加了编写过滤器的复杂性。
13. 分层系统，客户层，数据层，业务层，支持重用，并不是每个系统都可以很容易地划分为分层的模式
14. 仓库系统及知识库，黑板知识中心既作为独立结构成分，也作为各个知识源的连接器
15. H/T结构，一台主机+多个用户终端，一层体系结构，即所有负担都由主机承担，当主机负担过重时，终端用户的数量就要受到限制。
16. C/S结构，属于两层结构 ，也可以有多层。将复杂的网络应用的GUI和业务应用处理与访问处理分离，服务器和客户端之间通过消息传递机制进行对话，由客户端向服务器发出请求，服务器进行相应的处理后经传递机制送回客户端。存在问题：应用程序升级困难，客户端程序维护困难，当业务处理复杂时，客户端程序会显得“臃肿”（胖客户机 ）。
17. B/S结构，客户端升级和维护容易，可以跨平台操作，浏览器有兼容性问题
18. 三种评估方式的比较
19. 模块是相对独立的程序体，是数据说明、可执行语句等程序对象，面向对象软件开发模式，很自然地支持模块的设计原理：对象就是模块
20. 内聚度：一个模块内部各个元素间(语句和程序段)彼此的紧密程度的度量。
21. 耦合度：指软件结构中各模块之间相互联系紧密程度的度量。
22. 软件独立性的衡量标准：高内聚：内部结构紧密。低耦合：模块间关联和依赖程度尽可能小，与其他模块的接口简单。
23. ① 非直接耦合 （独立性最强）② 数据耦合 ③ 特征耦合④ 控制耦合⑤ 外部耦合⑥ 公共耦合⑦ 内容耦合
24. 模块内聚度越高，独立性越强，系统越容易理解和维护，功能性内句最好
25. 工厂模式把简单工厂的内部逻辑判断移到了客户端来进行。如果要加功能，本来是修改工厂类，现在是修改客户端类。
26. MVC是Model-View-Controller的缩写，将界面、处理、数据源分开，可以使修改影响的部分最小
27. ASP.NET MVC 3，与ASP.NET WebForm一起成为微软目前最强大的两种Web开发框架，二者各有所长
28. DAO设计模式让数据库访问变的可重用，可维护，可扩展呢

用例图，类图，活动图，数据库，表结构，状态图

软件工程概述

1. 软件发展历程：由最初的程序设计阶段，到程序系统阶段，再到软件工程阶段，然后到达当今的阶段
2. 软件危机：计算机软件的开发和维护过程中所遇到的一系列严重问题
3. 软件危机的典型表现：开发成本预估不准，超出预算；开发进度不能保证；开发产品不符合用户需求；软件不可维护
4. 原因（与上方对应）：忽视软件开发前期的调研和分析；
5. 随着软件开发进度的加深，进行修改所需要付出的代价也越来越大
6. 软件工程的三要素：过程，方法，工具
7. 软件质量唯独：功能性，可靠性，易用性，效率/性能，可维护性，可移植性
8. 软件工程过程是指在生命周期内，为了实现特定目标而进行的一系列相关活动
9. 软件开发的策略：软件复用（利用已有的进行组装），分而治之（将复杂问题分解为一个个能够处理的小问题），逐步演进（不断进行迭代式开发），优化折中（不能让所有目标得到优化，折中实现总体最优）
10. 好的软件：1.满足用户的需求，为用户增加利润，或减少成本2.没有缺陷，具有很强的扩展性，良好的性能
11. 商业环境下的软件质量：商业目标决定质量目标，不能把质量目标凌驾在商业目标之上，理想的质量目标不是零缺陷，而是让广大用户满意
12. 软件生命周期：软件从功能确定、设计到开发成功投入使用，并在使用中不断地修改、增补和完善，直到被新的需要所代替而停止使用该软件的全过程。
13. 
14. 问题定义：要解决的问题是什么；可行性分析；做还是不做；需求分析：要做什么；总体设计：怎么做；详细设计：具体的做法；实现：编码；测试：单元测试（对模块进行测试）和综合测试；软件维护
15. 软件开发中，开发人员是最大的资源。一个开发小组5-10人最合适，可以采用层级式结构

1. 软件过程模型：
   1. 瀑布模型：用户需求明确、完整、无重大变化的软件项目，也称线性顺序模型、生命周期模型，由文档驱动，面向过程的管理模式，但缺乏灵活性
   2. 快速原型模型：用户不能给出完整、准确的需求说明，或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式  ，根据用户的一组基本需求，快速建造一个原型（可视化的软件样机，展示系统的主要功能和接口）
      1. 抛弃型（废弃型）：构造一个功能简单质量要求不高的模型系统，对其进行反复分析修改，形成比较好的设计思想，系统构造完成后就被废弃。针对系统的某些功能进行实际验证，本质仍是瀑布模型。
      2. 演化型（追加型）：由一个功能简单的模型系统作为最终系统的核心，再不断扩充修改逐步追加新要求，最后发展成最终系统
      3. 可视化，强化沟通，降低风险，节省后期变更成本，提 高项目成功率。
   3. 增量模型：把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。
      1. 反复的应用瀑布模型 的基本成分和原型模 型的迭代特征，每一 个线型过程产生一个 “增量”的发布或提 交，该增量均是一个 可运行的产品。
      2. 在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地 提交。从第一个构件交付之日起，用户就能做一些有用的工作。
      3. 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的 错误不会影响到整个软件系统。
      4. .在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏 原来已经开发出的产品
   4. 螺旋模型：降低风险
      1. 1. 对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型 将瀑布模型和增量模型结合起来，加入了风险分析
         2. 风险控制的一系列专门技 术，因此投入较大，适用于规模较大的复杂系统。
         3. 螺旋模型较早地提出了迭代的概念，为后来出现的迭代 式开发提供了思路，引出RUP
         4. 随着迭代次数的增加，工作量加大，软件开发成本增加。
         5. 费用昂贵，所以只适合大型软件的开发
   5. 喷泉模型：支持面向对象开发过程
   6. 迭代式开发：开始提交一个完整系统，在后续发布中补充完善各子系统功能。
      1. 1. 
   7. RUP统一过程模型：基于迭代思想的软件开发模型，可以多次执行各个工作流程 每个周期划分为初始、细化、构造和移交四个阶段，每个阶段围绕着九个核心工作流分别迭代。
      1. 1. 重复一系列周期，每个周期由一个交付给用户的 产品结束。
2. 
3. 由于现实中项目的复杂性，通常会在一个项目中选择几种过程模型综合起来使用。
4. 问题定义主要包括：工作目标（要解决什么问题？）主要内容（问题的背景、总体要求与目标、类型范围、功能规模、实现目标的方案、开发的条件、环境要求等）问题定义报告
5. 可行性研究的目的不是解决问题， 而是确定问题是否值得去解决。 ֍可行性研究是为了确定项目能否 用最小的代价在尽可能短的时间 里进行开发
6. 可行性研究：技术可行性 社会可行性 经济可行性
7. 软件开发方法：传统的开发方法（面向过程，结构化开发方法）、面向对象的开发方法、面向组件的开发方法。 正迎来的面向服务和面向云计算的演变过程。
8. 传统计划驱动的开发方法强调过分过程控制
9. 敏捷开发：以人为核心、循环迭代、响应变化，抛弃了机械、严格的过程控制，是靠人自我的管理，团队自我的管理
   1. 敏捷开发过程是容易适应变化并迅速做出调整，在保 证质量的前提下做到文档适量适度。
   2. 程序员在软件开发中不再是单纯被管理的 对象，而是开发的主体。所有的主要设计策略的制定，开 发方法的选择，需求的确定都由程序员决定，
   3. 发是通过小改来避免大改。用前期的的失败 （试错）来保证最终结果，而不是顺风顺水地冲到一个大 坑里。
10. 
11. 敏捷开发方法：
    1. SCRUM开发方法
       1. Backlog是Scrum中经过优先级排序的动态刷新的产品需求清单，
       2. 用户故事STORY
          1. 。用户故事 是从用户的角度来描述用户渴望得到的功能。
          2. 
    2. 极限编程(XP)
       1. 在最短的时间内将较为模糊、变化较大的用户需求转化为符合用户要求的软件产品。
       2. RUP面向管理层面，XP面向实施层面。两者是相辅相成、互相补充的。在RUP管理框架之下，才能在迭代实施过程中采用XP，发挥XP的“快速”作用。
12. CI/CD 是一套使软件开发的构建、测试和部署阶段自动化的方法。
13.