目录
[UML 4+1视图](#UML 4+1视图)
黑盒测试【功能测试】：主要用来集成测试、确认测试盒系统测试阶段
需求工程
概述
软件需求就是指用户对系统在功能、行为、性能、设计约束等方面的期望。
需求工程的主要活动的阶段可以划分为：
- 需求获取:从用户的业务场景来获取到需求是什么
- 需求分析：获取到的需求进行整合、判断、分析、建模
- 形成需求规格【形成SRS】:这个就是形成文档形式的需求
- 需求确认与验证【形成需求基线】（经过评审的SRS）:也就是我们常用的需求评审
- 需求管理【变更控制、版本控制、需求跟踪、需求状态跟踪】
需求工程主要分为这五个，前四个我们可以看做是需求开发，最后一个可以单独看成事对需求的一个管理，也就是对需求基线进行管理
需求获取
这个就是从用户或者其他端口来获取到最原始的需求。
分层
需求获取的时候，不同层级的需求、获取的方式也不一样，目标也不太一样
大致分为三层：
- 业务需求（整体全局的）
- 用户需求（用户视角）
- 系统需求（计算机化）这一层级还可以继续细分：1：功能需求 2：性能需求 3：设计约束
获取方法
- 用户面谈
1-1、有代表性的用户、了解主观想法、交互很好、但是成本很高、要有领域只是支撑
- 需求专题研讨会
高度组织的群体会议、各方参与、了解想法、清楚分歧、交互好、成本高
- 问卷调查
用户多、无法一一访谈、这个成本低
- 现场观察
针对较为复杂的流程和操作
- 原型化方法
通过简易系统方式解决早期需求不确定的问题
- 头脑风暴法
一群人围绕新的业务、发散思维、不断的产生新的观点
项目管理维度
- 基本需求（明确的、常规需求）
- 期望需求(不明确的、隐含的)
- 兴奋需求（多余的）
需求开发---需求分析
如图所示就是结构化开发，在初期会建立三种模型，这里最注重功能模型和数据模型，功能模型最常见的工具就是数据流图。数据流程用于对功能建模。
在数据流里，我们能看到哪些人使用角色，哪些角色传递数据给系统，哪些角色从系统中获取到某些关键的数据。
UML（统一建模语言）：平台无关、语言无关
统一建模语言，其实是之前面向对象的多种建模工具整合形成的，他可以用在多个场景和环境工具集。就好比我们有一个工具箱，我需要用什么工具就拿什么，未必要在所有的项目中，把所有的工具都用上
UML大概有三块
构造块分为三部分
- 事物
结构事物：这是最静态的部分，包括：类、接口、协作、用例、活动类、构件和节点
行为事物：代表时间和空间上的动作。包括：消息、动作次序、连接
分组事物：看成是个盒子，如：包、构件
注释事物：UML模型的解释部分，描述、说明和标注模型的元素。
- 关系（泛化、扩展、依赖等等）
- 图（用例图、类图、对象图等）
规则：这个描述的uml体系运行的基本原则
范围：给一个名字以特定含义的语境
可见性：怎样使用或看见名字
完整性：事物如何正确、一致的相互联系
执行：运行或模拟动态模型的含义是什么
公共机制：所有的元素要达成的共识。
规则说明：事物语义的细节描述、他是模型真正的核心
修饰：通过修饰来表达更多的信息
公共分类：类与对象、接口和实现
扩展机制：允许添加新的规则
UML 4+1视图
需求的定义、验证、跟踪、变更
需求定义
严格定义法：
- 所有需求都能被预先定义
- 开发人员和用户之间能准确的清晰的交流
- 采用图形、文字可以充分体现最终系统
原型法：
- 并不是所有的需求都能在开发前被准确的定义和说明
- 项目参加者之间通常都存在交流上的苦难
- 需要实际的、可供用户参与的系统模型
- 有合适的系统开发环境
- 反复是完全需要和值的提倡的，需求一旦确定，就应遵从严格的方法
需求验证
是我们已经完成了需求规格说明书，已经吧需求落地成了文档，这个文档是有开发方主导完成的，当我们的甲方认不认呢？结果人家一看你的不行，这个时候我们应该提前验证、看看是不是需求和客户当时提的是不是一样的。
需求跟踪
需求变更管理
需求的变更是每一个开发都绕不开的，我们没办法避免。唯一不变的就是变化。无法杜绝的时候，我们就只能在变更的时候做好管理。
软件系统建模
从现有的系统到新的系统往往要经历多步的流程，现有的系统对应的其实就是我们的物理系统，我们把现有的系统模型化、就会得到物理模型，我们再将物理模型抽象化得到逻辑模型，逻辑模型我们进行调整和优化以后实例化他们得到物理模型。我们再将物理模型具体化那就是物理系统了，也就是我们的新系统。
软件界面设计（黄金三法则）
置于用户控制之下
不强迫用户进入不必要的或者不希望的动作方式来定义交互方式
提供灵活的交互方式
允许用户交互可以被中断和撤销
减少用户的记忆负担
减少对短期记忆的要求
建立有意义的缺省
定义直觉性的捷径
界面的视觉布局应该基于真实世界的隐喻
不断进展的方式揭示信息
保持界面的一致性
允许用户将当前任务放入有意义的语境
在应用系列内保持一致性
过去的交互模型已经建立了用户的期望，如果不是迫不得已，不要去改变它
结构化设计
结构化开发方法中的设计阶段就是结构化设计，在这个阶段，首先要明确两个点，一个叫概要设计、一个叫详细设计
概要设计（外部设计）：功能需求分配给软件模块、确定每个模块的功能和调用的关系，形成模块结构图
详细设计（内部设计）：为每个具体任务选择适当的技术手段和处理的方法
结构化设计原则：
模块独立性原则
保持模块的大小适中
多扇入，少扇出
深度和宽度均不要过高
内聚
耦合
模块四要素
- 输入和输出：模块的输入来源和输出去向都是同一个调用者，即同一个模块
- 处理功能：指模块把输入转换成输出所做的工作
- 内部数据：该模块本身引用的数据
- 程序代码：用来实现模块功能的程序
面向对象设计
基本过程
在面向对象的开发过程中，先有分析，再由设计师设计方案、界面、技术支撑、再实现设计模型
分析阶段：一般会构造两大模型：用例模型（用例图）和分析模型（类图、顺序图、等等）
设计师：设计用户界面、细化设计模型
设计模型：架构图、示例图、类图、状态图、活动图等等
类的分类
边界类
机器接口（API）、人机交互（用户界面）这个类主要对外界打交道、比如说显示屏、打印机接口、对话框、菜单、报表
控制类
应用逻辑、业务逻辑、数据访问逻辑；比如说身份验证器
实体类
对接数据库，对标数据源，一个学生表对应一个学生类
设计原则
七大设计设计原则可以看我的分类专栏，该专栏详细的记载了七大原则（编程思想_可有道？的博客-CSDN博客）
软件测试
测试类型
动态测试（计算机运行）：白盒、黑盒、灰盒
静态测试（人工检测盒计算机辅助分析）：桌前检查、代码审查、代码走查
白盒黑盒
白盒测试【结构测试】：主要用于单元测试阶段
- 控制流测试【逻辑覆盖测试（语句覆盖最弱、路径测试覆盖最强）】
- 数据流测试
- 程序变异测试【错误驱动测试】
黑盒测试【功能测试】：主要用来集成测试、确认测试盒系统测试阶段
- 等价类划分：不同的等价类揭示的问题也不一样
- 边界值分析：1<=x<=10,可以取x的值为0,1,10和11作为测试数据
- 错误推测：依靠测试人员的直觉和经验
软件测试阶段
软件系统测试
- 功能测试
- 性能测试
负载测试：各种工作负载下的系统性能
压力测试：测上限，系统的瓶颈或者不能接受的性能点
强度测试：测下限，系统资源很低、很匮乏的情况下运行
容量测试：并发测试：同时在线的最大用户数
可靠性测试：MTTF之类的参数
- 健壮性测试
- 用户界面测试
- 安全性测试
- 安装与反安装测试