当前位置：首页 > news >正文

软考复习——知识点软件开发

news 来源：原创 2025/8/3 22:54:50

开发模型

瀑布模型

各个活动规定为线性顺序连接的若干阶段的模型。是一种理想的现象开发模型，缺乏灵活性，无法理解软件需求不明确或不准确的问题。适用于需求明确的项目。

演化模型

从初始的原型逐步演化成最终软件产品，特别适用于对软件需求缺乏准确认识的情况

增量模型

把软件作品作为一系列增量构件来设计、编码、集成和测试，先提供给用户核心模块，在增量开发中逐步理解需求，进行改进，可以较早的发现问题

螺旋模型

一种演化软件开发过程模型，将瀑布模型与快速原型模型结合，兼顾快速原型的迭代以及瀑布模型的系统化与严格监控，并加入两种模型均忽略风险分析，适用于复杂的大型软件

快速原型模型

在开发初期阶段构造一个简易的系统，最终演化为最终产品，适用于需求不明确的情况，往往只应用在初期和需求分析阶段

喷泉模型

适合面向对象开发，采用迭代和无间隙

V模型

强调早测试，强调测试要贯穿与开发的始终

RAD快速开发模型

sdlc+cbsd，包含业务建模，数据建模，过程建模，应用生成，测试与交付

构件组装模型（CBSD）
把软件开发中的各个模块作成标准构件，然后将构件进行组装就得到了我们需要的软件。极大的提高了软件开发的复用性，可以使软件开发的总时长极大减小，软件成本降低，可靠性提高

统一过程模型UP

一种以用例和风险驱动、以架构为中心、迭代并且增量的开发过程，由UML方法和工具支持。UP过程定义了五个阶段，起始阶段、精化阶段、构建阶段、移交阶段和产生阶段。开发过程中包含多次迭代，每次迭代都包括：计划、分析、设计、构造、集成测试，以及内部和外部发布。每个迭代有五个核心工作流。

起始阶段：项目的初始化活动
精化阶段：理解最初的领域范围之后，进行需求分析和框架演进
构建阶段：关注系统的构建，产生实现模型
移交阶段：关注软件提交方面的工作，产生软件增量
产生阶段：运行软件并检测软件的持续使用，提供运行环境的支持，提交并评估缺陷报告和变更需求。

测试

原则：尽早、不断的进行测试

程序员避免测试自己设计的程序

既要选择有效、合理的数据，也要选择无效、不合理的数据

修改后应进行回归测试
尚未发现的错误数量与该程序已发现错误数成正比

动态测试

白盒测试

基于结构进行测试，主要关注被测系统的内部结构和逻辑，并验证代码的逻辑准确性和性能，包含基本路径测试，循环路径测试，逻辑覆盖测试

灰盒测试

基于上述两者之间，多用于集成测试阶段，不仅关注输出和输入的关系还关注程序内部结构

黑盒测试

主要关注被测系统的功能和行为，确保系统按照系统需求规格说明书进行工作等价类划分，包括边界值分析，错误推测，因果图

静态测试

桌前检查

代码审查

代码走查

单元测试

最小设计单元（模块）的验证，确保模块被正确编码，对重要控制路径进行测试以发现模块内错误，通常情况下是白盒测试，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早发现解决不易显现的错误。

集成测试

通过测试发现与模块接口有关的问题，将通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构，避免一次性的继承，采用增量继承。测试接口是否一致、模块间数据流控制流是否按照设计实现其功能、以及结果的正确性验证。可以是整个产品的集成测试，也可以是大模块的集成测试。（黑盒白盒相结合）

自顶向下集成：首先集成主模块，按控制层次结构向下集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。

自底向上集成：从原子模块开始构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。

冒烟测试

　　针对每个版本或每次需求变更后，在正式测试前，对产品或系统的一次简单的验证性测试。

　　用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。

系统测试

基于系统整体性需求说明书的黑盒类测试，覆盖系统所有联合部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足需求规格的定义，找出不符或与之矛盾的地方。系统测试的对象：需要测试的的系统产品的软件、软件依赖的硬件、外设甚至某些数据、某些支持软件和接口等。因此，将以上所有结合起来，在系统实际运行环境中测试。

回归测试

修改后测试
回归测试是指修改了旧代码后，重复以前的全部或部分的相同测试以确认修改没有引入新的错误或导致其他代码产生错误

验收测试

面向用户
系统开发生命周期方法论的一个阶段，这时相关用户和独立测试人员根据测试计划和结果对系统进行测试和验收，它让系统用户决定是否接收系统，它是一项是否能够满足合同或用户所规定需求的测试，包括（Alpha测试、Beta测试）

Alpha测试

内测版本，开发者内部交流；是由用户在开发者的场所来进行的，在一个受控的环境中进行。测试完后一般不会有大问题

Beta测试

公测版本，面向所有用户；由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件。

Gamma测试

指软件正式发行的候选版，相当成熟，与正式版本相差无几，成为正式发布的候选版。

基准测试

Benchmark或者Baseline测试。一般为单用户测试，或者是零数据量环境下的测试；

稳定性测试

验证系统是否可长期稳定的运行，是否存在一些短时间内可能无法发现的缺陷；

压力测试

对系统逐渐增加压力的测试，来获得系统能提供的最大的服务级别的测试或者不能接收用户请求的性能点。通俗地讲，压力测试是为了发现在什么条件下应用程序的性能会变得不可接受。

根据压力测试结果，通常分析随着压力的增加，系统的平均吞吐量、响应时间的变化趋势，确定系统的性能瓶颈，进而为优化系统提供参考依据

风险

风险是损失或者伤害的可能性

风险的优先级与风险曝光度有关，风险暴露=风险影响*风险概率

特性：不确定性，损失

项目的主要风险
项目风险：涉及各种的预算、进度、人员、资源以及和客户相关的问题；
技术风险：潜在的设计、实现、对阶、测试等维护问题
业务风险：建立一个无人想要的项目的风险、失去预算的风险等
商业风险：市场风险、策略风险、管理风险预算风险等

数据标准化通常包括业务建模阶段，数据规范阶段，文档规范阶段