该笔记涵盖软件过程、设计、测试和项目管理等知识。介绍通用和惯用过程模型，如瀑布、V、增量等模型；阐述需求建模的各类图；强调模块化设计、高内聚低耦合原则；讲解软件测试方法，包括单元、集成、系统和验收测试；还提及项目规模估算和关键路径等内容。
写在前头：
此笔记内容较为简略，存在部分知识点未详细描述的情况，课件链接置于文末可以下载可以参看课件以了解更为详细的内容;
如果内容有误可私信笔者以进行修正;
文章中小标题前的数字对应着课件序列。
知识点概览
- 软件过程
- 需求文档画图/需求建模,UML建模
- 高内聚低耦合
- 软件设计
- 软件测试
- 项目管理
文章目录
3 通用过程模型（PROCESS FlOW）
线性过程流：
迭代过程流：
演化过程流：
并行过程流：
4过程模型
惯用过程模型（※）：
prescriptive process models
也称软件生存周期模型 software life cycle model.
I. 瀑布模型:
waterfall model
特点：
- 阶段间具有顺序性和依赖性；
- 推迟实现的观点：前面步骤完成后才考虑实现；
- 质量保证的观点：每一阶段都需要有文档以及经过评审；
问题：
- 瀑布模型需要客户明确需求，但客户难以准确表达所有需求。
- 得到可执行程序的时间太迟(项目接近尾声)，对于系统中存在的重大缺陷，如果在可执行程序评审之前没有被发现，将可能造成惨重损失。
- 可能导致一些阻塞(开发团队的一些成员要等待另一些成员工作完成，尤其在开始和结束阶段，花在等待的时间可能超过生产性工作时间)
- 过于理想化，难以应对开发过程中的各种不确定因素。
II. V模型
V模型的本质：增加了一系列测试以保证工作质量；
III. 增量过程模型(Incremental process model)
应用背景：
- 需求不明确或迫切需要为用户迅速提供一套功能有限的软件产品，然后再后续版本中再进行细化和扩展功能。
特点：
它允许团队集中精力在优先级较高的功能上，逐步完善产品。
增量模型综合了线性过程流和并行过程流的特征：
- 随着时间的推移，增量模型在每个阶段运用线性序列；
- 每个线性序列以一种演化过程流的方式生产出软件的可交付增量。
以迭代方式运用瀑布模式。
缺点：
- 难以确定所有版本共需的公用模块。
IV. 螺旋模型
A typical spiral model
开发大型系统和软件的理想方法，更好地应对风险。
开发周期比较长，无法确保规定时间交付产品。
V. 原型开发
客户提出了一些基本功能，但未详细定义输入、处理和输出需求；
开发人员可能对开发运行环境、算法效率、操作系统的兼容性和人机交互等情况不确定。
统一过程模型（UP）:
专用过程模型：
（略）
7 需求(理解)
各种服务对象为需求的图：用例图，类图，实体关系图（Entity relation shape）.
用例图:
展示参与者，系统边界，用例，参与者之间的关系
实体关系图：
类图（基于类的建模：主要包含）：
8基于场景的需求建模
状态图（State Diagram）:
活动图(activity diagram)：
泳道图（Swimlane Diagrams）：
泳道图是更为清晰的活动图表示形式。
提供迭代流的图形化表示来补充用例
两端为半圆形的矩形表示一个特定的系统功能
箭头表示通过系统的流
判定菱形表示判定分支
实心水平线意味着并行发生的活动。(见后面的案例)
实体关系图（Entity Relationship ）:
10 数据流图/协作图
I.数据流图(data flow diagram)
数据流图的优化流程
II. 协作图(collaboration diagram)
III. 时序图(Sequence Diagram)
11 设计概念
I. 模块化设计
模块数增加时，模块间的关系也随之增加，接口和集成的工作量也随之增加；
结论：寻找最佳模块化程度平衡点。
II. 内聚与耦合（高内聚低耦合-好的组件级设计）
内聚(cohesion)：描述为构件的专一性；
模块内部各个元素彼此结合的紧密程度：
- 一个内聚的模块执行一个独立的任务，与程序的其他部分构件只需要很少的交互。
- 一个内聚的模块应该 (理想情况下)只完成一件事情。为了实现良好的设计，应该避免“分裂型”构件 (某个构件执行多个无关功能)。
- 尽量高！
耦合(coupling)：构件之间彼此联系紧密程度的一种定性度量。
- 模块之间相互关联的程度：
- 耦合性依赖于模块之间的接口复杂性、引用或进入模块所在的点以及什么数据通过接口进行传递。
- 模块间简单的连接性使得软件易于理解并减少“涟漪效果”(ripple effect)的倾向。
- 当在某个地方发生错误并传播到整个系统时，就会引起“涟漪效果”。
- 尽量低！
内聚度的七个层次：
<
- 巧合内聚(偶然内聚)：将几个模块中的相同程序代码段独立出来建立的模块 (无明显独立性)。
- 逻辑内聚：完成一组逻辑相关任务的模块，由控制型参数来确定执行哪一种功能 (选择其中一个功能，内聚性不强)。
- 时间内聚：模块中的多个任务必须在一段时间内先后执行 (有时间约束，无明确的过程约束)。
- 过程内聚：模块内的多个任务必须按指定的过程执行。
- 通信内聚：模块内所有处理元素都集中在某个数据结构的一块区域中 (例如对课程进行选、退课和查询)。
- 顺序内聚：指一个模块完成多个功能，这些功能又必须顺序执行 (更加单一的过程内聚)。
- 功能内聚 ：指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割的 (单个功能)。
耦合度的七个层次：
-
内容耦合：一个模块可以直接访问另一个模块的内部数据或内部功能。
-
公共耦合：多个模块共同访问某些公共数据元素。
-
外部耦合：多个模块间需要遵循同样的外部约束，例如通信协议、数据格式等。(遵循全局的约束)
-
控制耦合：模块间的交互参数包含控制信息，可影响另一个模块的执行逻辑。
-
标记耦合：模块间传递特定的数据结构。
一个数据结构被作为参数传递,并且被调用模块只使用了部分而非全部数据;
问题：传送了不必要的数据：
不受限制的数据访问可能成就计算机犯罪。 -
数据耦合：模块间仅传递简单数据。
如果一个模块访问另一个模块时，彼此之间是通过简单数据参数 (不是控制参数、 公共数据结构或外部变量)来交换信息的，则称这种耦合为数据耦合。(推荐使用的方式)
-
非直接耦合：两个模块可以相对独立工作。
模块关联的评价指标
扇出：一个模块直接控制的模块数目：
扇出过大意味着模块过分复杂，需要控制和协调过多的下级模块。
理想的平均扇出为3-4（上限为5-9）。
扇入：有多少个上级模块直接调用它。
扇入越大意味着共享该模块的数目越多。
设计得好的软件结构通常顶层扇出高，中层扇出少，底层高扇入。
设计模型维度
12 架构级设计
I. 以数据为中心
优点：
- 开放：数据对所有使用者开放，客户软件可以直接决定存取方式；
- 可集成性：现有构件可以被修改，新的客户构件可以加入到体系结构中，而无需考虑其他客户。
问题：
- 客户软件难以协作；
- 中心数据的格式必须为所有客户软件所接受。
II. 管道过滤器模式(数据流体系结构)
优点：
- 易理解；
- 容易并行运行。
问题：
- 适用于批处理，不易交互；
- 流的协作需要考虑。
III. 调用和返回体系结构（call-return）
该体系结构风格能够设计出一个相对易于修改和扩展的程序结构，存在以下子风格：
- 主程序/子程序体系结构：将功能分解为一个控制层次结构，其中的“主”程序调用一组程序构件，这些程序构件又去调用别的程序构件 (此时，对于被调者来说，这些主调者就是主程序)。
- 远程过程调用体系结构：构件分布在网络的多个计算机上。
IV. 面向对象体系结构(Object-oriented architecture)
- 系统的构件封装了数据和应用到该数据上的操作。
- 构件间通过消息传递进行通信与合作。
V. 层次体系结构(Hierarchical architecture)
- 定义了不同的层次，各个层次完成各自操作；
- 每一层为上层提供服务，又接受下层的服务；
- 优点：明确的抽象层次、易于增减或修改层次；
- 问题：系统并不是总能分层。
举出你所知道的两个设计模式，简要描述
13 组件级设计
I. 基本设计原则
- 开闭原则（The Open-Closed Principle, OCP）；模块应该对外延具有开放性，对修改具有封闭性；
无需对构件自身内部做修改就可以进行扩展
- Liskov替换原则：子类可以替换它们的基类；
保证系统或子系统有良好的扩展性。
实现运行期内绑定。
有利于实现契约式编程。
-
依赖倒置原则：依赖于抽象，而非具体实现 ；
-
接口分离原则：多个用户专用接口比一个通用接口要好。
II. 组件级设计guideline
构件：对那些已经被确定为体系结构模型一部分的构件应该建立命名约定：
- 使用全名，例如：Job management system, Read print job data；
- 采用与日常描述一致的词，例如：Detector, Phone；
- 混合大小写，例如：checkPriority, totalJobCost；
- 采用动/名或名/动形式来描述方法,例如：computePageCost()；方法名不要与类名重复；
- 意义明确，例如不要出现：a, a()；
接口：
- 记号中的接口用棒棒糖式记号；
- 接口都放在构件框的左边 ；
- 即使其他接口也适用，只表现出那些与构件相关的接口；
- 结果：系统易于查看。
依赖与继承：
- 依赖关系自左向右，继承关系自底(导出类)向上(基类)；
- 依赖通过接口来表示，而不是采用“构件到构件”的方法；
- 结果：系统更易于维护。
控制耦合通用耦合七七八八的图会出现在考试里
P32-P45
14 用户界面设计流程
17 通用的软件测试方法
I. 软件测试策略（software testing strategy）:
①Test Plan;②Test case design;③Test execution; ④Collection and evaluation of test result.
II.软件错误的来源
①错误需求；②缺少需求；③无法实现的需求；④设计错误；⑤编码错误
软件测试流程：
单元测试：
- 测试模块的接口是为了保证被测程序单元的信息能够正常地流入和流出。
- 检查局部数据结构以确保临时存储的数据在算法的整个执行过程中能维持其完整性。
- 执行控制结构中的所有独立路径 (基本路径)以确保模块中的所有语句至少执行一次。
- 测试边界条件确保模块在到达边界值的极限或受限处理的情形下仍能正确执行。
- 最后，要对所有的错误处理路径进行测试。(try…catch)
driver程序
stub程序
单元测试的一般步骤：
- 编译运行程序，进行语法正确性验证；
- 静态测试，检查代码是否符合规范，参看“编码规范”；
- 动态测试，深入检查代码的正确性、容错性和边界值等。主要用白盒测试。
集成测试：
指将通过测试的单元模块组装成系统或子系统，再进行测试。
集成测试的内容：
- 单元组装后的功能正确性：是否实现预期功能；
- 单元之间的接口：调用关系、数据传递是否正确；
- 集成后的系统性能：集成后系统资源使用情况.
-
一步到位的集成：所有的构件都连接在一起，全部程序作为一个整体进行测试。
-
增量集成：程序以小增量方式进行构造和测试，具体包括：
- 自顶向下测试：从主控模块开始，沿着控制层次结构逐步向下，利用深度优先或广度优先的方式将从属于主控模块的模块集成到结构中去；
- 自底向上测试：从原子模块开始进行构造和测试；
- 组合方法（三明治）：用自顶向下方法测试程序结构较高层，用自底向上方法测试其从属层。
Testing和Debugging的区别
Testing（测试）和debugging（调试）是软件开发生命周期中两个不同但密切相关的活动。它们都旨在提高软件质量，但它们关注的方面和执行的任务有所不同。
- Testing（测试）:
- 定义： Testing是验证软件系统是否满足其规格要求的过程。它涉及执行软件系统的各种测试，以确保其功能正常、性能良好，并且符合规格。
- 目的： 主要目的是发现系统中可能存在的错误、缺陷或问题，以确保软件在交付给用户之前达到预期的质量水平。
- 活动： 包括单元测试、集成测试、系统测试、验收测试等不同层次和类型的测试。测试是从系统的外部观察和评估系统的行为。
- Debugging（调试）:
- 定义： Debugging是在软件开发过程中发现、定位和修复程序中的错误或缺陷的过程。它是一种追踪和纠正代码问题的活动。
- 目的： 主要目的是找出在软件中可能存在的bug或错误，并对其进行诊断和修复，以便软件能够正常工作。
- 活动： 包括使用调试器、日志记录、打印语句等方法来定位和修复代码中的错误。调试是从程序的内部检查和修改代码。
简而言之，testing是一种验证软件是否按照规格要求工作的活动，而debugging是在发现软件中的错误后对其进行定位和修复的活动。Testing关注整个系统的行为，而debugging关注个别代码段的行为。这两个活动通常在软件开发过程中交替进行，以确保最终的软件产品质量。
18 Testing
黑盒测试与白盒测试:
黑盒测试：在软件接口处进行测试，检查系统的功能方面，不需了解软件的内部结构。
白盒测试：检查软件的过程细节，测试贯穿软件的逻辑路径和构件间的协作。
基本路径测试
它是在程序控制流图的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合。设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。
路径复杂度计算公式：
数据流图below:
流程图-》流图-》测试路径-》测试用例；
控制结构测试
控制结构测试包括：
条件测试：基于模块中包含的逻辑条件，设计测试用例使得程序中每个判断的每个条件的可能取值至少执行一次
数据流测试：根据变量的定义和使用位置来选择测试路径
循环测试：侧重于循环的有效性
黑盒测试black box testing
Also known as functional testing
Testers do not consider the logical structure and internal characteristics of the program at all, and only check whether the function of the program conforms to its function description according to the program’s requirements specification.
测试人员根本不考虑程序的逻辑结构和内部特征，而只是根据程序的需求规范检查程序的功能是否符合其功能描述
Model-Based Testing
停止测试的方法：
错误播种(Error Seeding）:通过播种来估计错误的数量。
单独测试法(Separate test method):有两个独立的测试组，将两组的测试结果合并估算剩余误差数。
软件测试的总体流程：
单元测试
单元测试又称为模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作，单元测试需要从程序内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。
测试阶段：编码后
测试对象：最小模块
测试人员：白盒测试工程师或开发工程师
测试依据：代码和注释+详细设计文档
测试方法：白盒测试
测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
比如说在商店买东西时，需要扫码付款，如果使用支付宝付款，那么正常情况下就应该用支付宝去扫描商家的支付宝收钱码进行付款而不是微信收钱码。那么要是出现异常情况的话，比如用支付宝扫了微信收钱码还会弹出支付界面吗，又或者是在无网情况下扫码会出现什么界面呢？ -> 进行错误处理测试
总的来说，单元测试是为了验证相关人员所编写的功能模块代码实现了正常情况下该实现的功能，也对其它任何可能出现的缺陷做了相应正确的处理。单元测试完成之后，通常会发现大量bug，然后开发人员对其作出处理，这样可以为后期维护代码降低代价。
集成测试
集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。
测试阶段：一般单元测试之后进行
测试对象：模块间的接口
测试人员：白盒测试工程师或开发工程师
测试依据：单元测试的模块+概要设计文档
测试方法：黑盒测试与白盒测试相结合
测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
系统测试
将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段，包括回归测试和冒烟测试。
测试阶段：集成测试通过之后
测试对象：整个系统（软、硬件）
测试人员：黑盒测试工程师
测试依据：需求规格说明文档
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
还是在淘宝上买东西的例子，如果刚开始是在华为手机上测试通过了，那么换成小米手机或是苹果手机呢？又或者是换成电脑呢？提交订单后还会出现确认付款界面吗，能正常调用支付宝付款接口进行付款吗？在电脑上付款的话是不是会比手机慢呢或者不安全呢？ 如果发现不能调用支付宝付款接口进行付款，那么在修复了这个bug之后会不会引进新的bug呢？【比如提交订单后连确认付款的界面都不见了】这些都是系统测试需要做的事情。
验收测试
验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买者展示该软件系统满足原始需求。
测试阶段：系统测试通过之后
测试对象：整个系统（包括软硬件）。
测试人员：主要是最终用户或者需求方。
测试依据：用户需求、验收标准
测试方法：黑盒测试
测试内容：同系统测试(功能…各类文档等)
这个阶段主要是依据用户的需求和验收标准来测的，由用户进行测试，测试所有的功能是否符合他们的预期等等
22 Project Manager
规模指标（Metrics for Scale）
Line of Code估算
Determine the optimistic (Sopt), likely (Sm) and pessimistic (Spess)values of the scale and combine them (weighted average)Expected value S=(Sopt+4Sm +Spess) /6
确定乐观(opt)，可能(Sm)和悲观(Spess)并将其合并(加权平均值)
期望值S=(Sopt+4Sm +Spess) /6
FP估算
①计算复杂度调整因子
②计算工作量
关键路径
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
