目录
需求工程
概述
需求获取
分层
获取方法
项目管理维度
需求开发---需求分析
UML(统一建模语言):平台无关、语言无关
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之类的参数
- 健壮性测试
- 用户界面测试
- 安全性测试
- 安装与反安装测试