夜雨聆风第1章 软件
1．软件的概念、构成（程序、文档、数据）和特点，软件与硬件的区别，软件具有的特点（题型：选择、判断、论述题）
软件主要由程序、文档、数据这三部分构成。
软件与硬件的区别：硬件是物理实体，会随着时间磨损和老化；而软件是逻辑实体，没有物理磨损，但会因为不断修改和环境变化而退化或过时。此外，硬件通常是自动化批量生产的，而软件通常是高度定制化、工程化开发出来的。
软件的特点：软件具有复杂性、不可见性、不断演化性以及对硬件和环境的依赖性。
2．软件的分类，系统软件、应用软件的概念与示例（题型：选择、判断题）
系统软件：负责管理、控制和维护计算机底层资源，为其他软件提供运行环境的概念。其示例包括操作系统（如Windows、Linux）、编译器、数据库管理系统等。
应用软件：为解决特定领域问题或满足特定用户需求而开发的软件概念。其示例包括办公软件（如Word）、社交软件（如微信）、企业财务系统等。
3．软件生存周期的概念，软件生存周期包含的3个时期和相应阶段，每个时期和阶段的主要任务（题型：选择、判断、论述题）
基本概念：软件从孕育、诞生、成长、成熟到最终衰亡（退役）的全过程。
软件生存周期包含的3个时期：软件定义时期、软件开发时期、软件运行与维护时期。
软件定义时期的阶段与任务：主要任务是确定软件“做什么”。包含可行性研究（分析项目是否值得做，如技术、经济可行性）和需求分析（明确系统必须具备的具体功能和性能要求）。
软件开发时期的阶段与任务：主要任务是明确“怎么做”并最终实现。包含系统设计（分为概要设计和详细设计，构建软件架构和模块细节）、编码（编写底层源代码）、测试（通过运行程序发现并改正缺陷）。
软件运行与维护时期的阶段与任务：主要任务是保证软件持久满足用户需求。包含软件维护阶段（修复Bug、增加新功能、适应新系统环境等）。
4．软件质量的概念，软件质量模型（McCall、Garvin、ISO/IEC 25010）及其质量因素，软件质量的案例分析（题型：选择、判断题）
软件质量的概念：软件产品满足规定或潜在需求能力的特征和特性的总和。
McCall模型：从用户的角度出发，将软件质量因素分为产品运行、产品修改、产品转移三个重要维度。
Garvin模型：提出了产品质量的8个维度，通常包括性能、特征、可靠性、一致性、耐久性、服务性、美学和感知质量。
ISO/IEC 25010模型：现代常用的软件质量模型，其质量因素包含功能适用性、性能效率、兼容性、易用性、可靠性、安全性、可维护性和可移植性。
软件质量的案例分析：考试中常给出实际场景让你判断质量因素。例如，“某购物APP在双十一期间未发生崩溃”体现了可靠性；“系统响应时间极快”体现了性能效率；“软件能轻松从Windows移植到Mac”体现了可移植性。
5．软件质量保证方法（题型：选择、判断题）
软件质量保证方法：旨在确保软件开发过程和产品符合既定标准的一系列系统性活动。常见方法包括技术评审（同行检查代码或文档以发现早期错误）、软件审计（独立评估是否遵循了标准流程）、全面软件测试，以及引入过程标准化模型（如CMMI）。
第2章 软件工程概述
6．软件工程定义、目标和原则（题型：选择、判断题）
定义：将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程（核心思想：用“修桥盖楼”的工程化思维来开发软件）。
目标：在给定成本、进度的前提下，开发出具有适用性、可靠性、可修改性、可维护性等特性的软件产品。
原则：考试中常考的原则包括抽象、信息隐藏、模块化、局部化等。
7．软件危机的定义（成本高、周期长、质量低等）、具体表现、成因（复杂度高、需求变更、管理低效等）及解决途径（软件工程方法论）（题型：选择、判断题）
定义与具体表现：简单来说，就是软件开发和维护过程中遇到的一系列严重问题。具体表现为你需要死记硬背的几个痛点：成本高（预算总是超支）、周期长（进度永远拖延）、质量低（Bug 频发，做出来的东西不是用户想要的）、维护极其困难。
客观原因：软件本身复杂度高，它是逻辑产品而不是物理产品。
主观原因：用户需求变更频繁（最常见背锅侠），以及开发团队的管理低效（缺乏沟通和规范）。
解决途径：采用软件工程方法论。这也是我们要学习“软件工程”这门课的根本原因——为了消除软件危机。
8．计算机辅助软件工程（CASE）的概念及工具（题型：选择、判断题）
概念：CASE（Computer-Aided Software Engineering），顾名思义，就是用软件来开发软件。它是一组工具和方法的集合，旨在辅助软件生命周期的各个环节，将枯燥的开发过程自动化。
工具：涵盖了整个软件生命周期。例如：需求分析工具、设计建模工具（比如画UML图的软件）、代码自动生成器、自动化测试工具等。
第3章 软件过程
9．基本开发活动、典型的保护性活动（题型:选择、判断、论述题）。
基本开发活动：推动软件从无到有的具体步骤。通常包括：沟通（与客户交流）、策划（制定计划）、建模（分析和设计）、构建（编码和测试）、部署（交付与反馈）。
典型的保护性活动（普适性活动）：贯穿于整个开发过程，为了保证软件质量和项目进度而进行的活动。主要包括：软件项目跟踪与控制、风险管理、软件质量保证（SQA）、正式技术评审、软件配置管理等。
10．经典软件过程模型（瀑布模型，V模型，原型模型，增量模型，迭代模型，螺旋模型，演化模型，统一过程模型），各模型特点，工作步骤，开发与测试阶段的对应关系，区别（题型:选择、判断、论述题）
瀑布模型(Waterfall Model)：
特点：线性的、顺序的。必须做完上一阶段才能进入下一阶段。文档驱动。
缺点：极难适应需求变更，往往到了项目后期才能看到系统全貌。
V模型 (V-Model)：
特点：它是瀑布模型的变种，极其强调测试。
开发与测试的对应关系（高频考点）：V模型的左边是开发，右边是测试。需求分析对应验收测试，概要设计对应系统测试，详细设计对应集成测试，编码对应单元测试。
原型模型(Prototyping)：
特点：快速构建一个可运行的“草稿”（原型），让用户直观地看到并提出反馈。
适用场景：客户需求非常模糊，说不清楚自己到底想要什么的时候。
增量模型(Incremental)：
特点：像搭积木。先开发并交付核心功能（第一个增量），然后再陆续开发并交付后续的附加功能。
优势：用户可以很早用上核心系统，早期就能获得投资回报。
迭代模型(Iterative)：
特点：像画素描。一开始就画出整体轮廓（提供完整但粗糙的系统），然后经过一轮又一轮的迭代，不断细化和完善细节。
区别：增量是“逐块拼装”，迭代是“整体不断精化” 。
螺旋模型(Spiral Model)：
特点：结合了瀑布模型和原型模型，并加入了风险分析。
解题核心词：只要题目里出现“大型复杂项目”、“高风险”、“风险分析”，无脑选螺旋模型。
演化模型(Evolutionary)：
特点：能够适应随着时间推移而演变的产品需求，通常是迭代的，逐步交付更完整的软件版本。
统一过程模型(UP/RUP)：
特点：用例驱动、以体系结构为核心、迭代和增量。这是一个非常重量级、规范化的现代企业级开发模型。
11．软件过程模型的选用、选择建议（题型：选择、判断题）
需求明确、技术成熟、不怎么会变-> 瀑布模型。
对系统的可靠性要求极高，测试极为重要-> V模型。
需求不确定，客户自己都没想清楚-> 原型模型。
需要尽快把核心产品推向市场抢占先机-> 增量模型。
大型、极其复杂、资金投入大、一旦失败后果严重的系统-> 螺旋模型。
第4章 软件开发方法
12．结构化开发方法的建模语言（数据流图DFD、数据字典DD、实体-关系图ERD、HIPO图、结构图SC），各模型的概念、特点与表示方式（题型：选择、判断题）
数据流图（DFD）：描述系统内数据的流动和处理过程，是结构化分析阶段的核心。只关心“数据怎么走”，不关心“怎么控制”。
数据字典（DD）：对DFD中出现的所有数据元素进行详细定义，它是DFD的补充说明。
实体-关系图（ERD）：用于数据建模，描述数据对象及其之间的关系（常用于数据库设计的前置阶段）。
结构图（SC）：描述系统的模块结构以及模块间的调用关系，是结构化设计阶段的核心。
13．结构化分析、设计的总体过程（题型：选择、判断、论述题）
结构化方法遵循“自顶向下，逐步求精”的原则。先用DFD和ERD做分析，搞清楚逻辑模型；再转换为SC结构图，搞清楚物理模型。
14．面向对象开发方法的基本概念（对象、类、封装、继承、多态等），各概念的解释（题型：选择、判断题）
类与对象：类是图纸（抽象），对象是按图纸造出来的实体（具体）。
封装：把数据和操作数据的方法绑在一起，对外隐藏内部细节（提供接口）。
继承：子类自动共享父类的属性和方法（实现代码重用）。
多态：同一个操作作用于不同的对象，可以有不同的解释，产生不同的执行结果（比如“发声”指令，猫是喵，狗是汪）。
15．面向对象开发方法的建模语言UML的类别（用例图、类图、对象图、状态图、时序图、协作图、活动图、组件图、部署图），各类别的概念、特点与表示方式（题型：选择、判断、论述题）
动态/行为图（描述系统怎么动）：用例图（描述用户能做什么）、状态图（对象在其生命周期内的状态变化）、活动图（类似流程图，描述业务逻辑）、时序图（强调按时间顺序的对象交互）、协作图（强调交互对象的空间组织结构）。
静态/结构图（描述系统长什么样）：类图（系统中最核心的静态图，描述类及其关系）、对象图（类图的实例）、组件图（描述软件组件及其依赖）、部署图（描述硬件节点的物理配置）。
16．敏捷开发方法的理念、思想和原则（轻量级流程，强调快速响应变化），典型的敏捷开发方法（XP、Scrum），Scrum方法基本过程（题型：选择、判断、论述题）
核心理念：敏捷开发是传统瀑布模型的“死对头”。它认为计划赶不上变化，因此主张轻量级流程，强调快速响应变化 。它的核心价值观是：个体和交互胜过过程和工具；可以工作的软件胜过面面俱到的文档；客户合作胜过合同谈判；响应变化胜过遵循计划。
两大典型方法：XP（极限编程）：极其强调工程实践，比如结对编程、测试驱动开发（TDD）、持续集成。Scrum：一种侧重于项目管理的敏捷框架。
Scrum基本过程（论述题重点） ：
你需要记住几个关键名词：产品待办事项列表（Product Backlog，所有要做的需求）、Sprint（冲刺，通常是1-4周的迭代周期）、Sprint待办事项列表（本次冲刺要做的任务）、每日站会（Daily Scrum，每天同步进度）。工作流就是从总需求库里挑一拨任务，用一个Sprint周期做完并交付可用软件，然后复盘，接着进入下一个Sprint。
第5章 需求工程
17．需求的定义，需求描述应该具备的特性（题型：选择、判断题）
定义：需求就是用户为了解决某个问题或达到某个目标所需要的条件或能力。简单来说，就是“系统必须做什么”以及“系统必须满足什么约束”。
特性：好的需求描述必须具备完整性、正确性、清晰性（无歧义）、一致性（需求之间不打架）、可测试性（能通过测试验证是否实现）等。
18．需求的分类，功能需求、非功能需求（性能、安全性、兼容性、可移植性等方面）的定义与区别，软件项目中功能需求、非功能需求的分析与列举，非功能需求各方面的具体描述与示例（题型：选择、判断、应用题）
功能需求：系统“必须做什么”。它描述了系统与其环境之间的交互。
示例：“系统必须允许用户通过手机号注册”、“系统能够生成每月的财务报表”。
非功能需求：系统“做得有多好”，即系统的质量属性和约束条件 。主要包括：
性能：响应时间、吞吐量（例：“页面加载时间不能超过2秒”）。
安全性：权限控制、数据加密（例：“用户密码必须加密存储”）。
兼容性：能否在不同环境下运行（例：“必须同时支持 Chrome 和 Safari 浏览器”）。
可移植性：从一个环境迁移到另一个环境的难易程度。
19．用例图的构建，用例识别（识别系统中的不同用例），用例描述（描述用例的参与者），用例图和关系建立（椭圆形绘制用例并正确连接用例-参与者关系）（题型：应用题）
用例图（Use Case Diagram）是站在用户的视角看系统能提供什么服务。你需要掌握三个核心元素：
参与者（Actor）：系统外部与系统交互的人或事物（用小人儿图标表示）。注意，参与者不一定是人，也可以是另一个外部系统或者定时器。
用例（Use Case）：系统为参与者提供的一项具体功能（用椭圆形表示，里面写上动宾短语，如“提交订单”）。
关系连线：
关联（Association）：参与者和用例之间的连线（通常用实线连接）。
进阶关系（通常也会考）：包含（<>）（必须执行的前置动作，如“取款”包含“密码验证”）和扩展（<>）（特定条件下的额外动作，如“结算”扩展出“使用优惠券”）。
避坑指南：画图时，用例的名字一定要是动词+名词的组合；参与者一定要放在系统边界（矩形框）的外面，用例放在里面。
20．需求工程活动（需求获取、需求建模与分析、需求规约、需求确认与验证、需求管理），各活动的概念、任务和方法（题型：选择、判断、应用题）
需求工程是一个流水线，分为五个步骤：
需求获取：去问客户想要什么。常用方法：面谈、问卷调查、观察法、原型法。
需求分析与建模：把客户乱七八糟的想法理清，用图形（如用例图、数据流图）和逻辑把需求模型化。
需求规约（文档化）：将分析结果写成正式的《软件需求规格说明书》（SRS）。这是开发和测试的最重要依据。
需求确认与验证：找客户和专家来开会评审，确认这份SRS是不是真的写对了，有没有遗漏或矛盾。
需求管理：贯穿始终。专门用来应对“客户突然改主意”（需求变更）的情况，进行版本控制和状态跟踪。
第6章 软件设计
21．软件体系结构的概念，软件体系结构模式的概念、基本元素（题型：选择、判断题）
概念：软件体系结构就是系统的高层蓝图。设计一个大型软件，就像设计一辆多层科幻生存重卡或者移动堡垒，你不能上来就直接焊钢板（写代码），而是要先规划好整体架构——指挥中心在哪、动力系统怎么分布、各层之间如何通信。这就是体系结构设计。它的主要目的是为了满足系统的重要非功能需求（如性能、安全性）。
22．典型的软件体系结构模式及其特点（分层模式、代理模式、MVC模式、客户端/服务器模式等），各模式的简述与元素（题型：选择、判断题）
四大经典模式（必须分清）：
分层模式：就像多层重卡的甲板，每一层都有明确的职责，并且通常只与相邻的下一层通信（例如：表示层-> 业务逻辑层 -> 数据访问层）。
MVC模式：即 Model（模型：处理核心数据和逻辑）、View（视图：展示界面）、Controller（控制器：接收输入并调用模型和视图）。这是Web开发中最主流的模式。
客户端/服务器模式（C/S）：服务器集中管理资源并提供服务，客户端负责向用户展示并发送请求。
代理模式（Broker）：在分布式系统中充当“中间人”，隐藏服务器的具体位置，客户端只需要找代理，代理负责把请求路由给真正的服务器。
23．软件体系结构设计的目的，设计时的考虑因素、重要需求（题型：选择、判断题）
设计的目的：体系结构设计是整个系统的最高指导蓝图。这就好比设计一台多层生存重卡或移动堡垒，你不能一开始就去焊钢板或拧螺丝，而是要先规划好动力层、生活区、防御系统的整体布局以及它们如何相互通信与配合。它的目的是为后续的详细开发提供统一的结构框架。
重要需求与考虑因素：体系结构设计主要解决的往往不是具体的功能问题，而是非功能需求（如系统应对高并发的性能、数据传输的安全性、整体的可扩展性）。在考虑因素上，除了纯粹的技术框架选型，还需要综合考量项目成本、团队的开发经验以及未来的维护难度。
24．用户界面的组成，用户界面设计的任务、原则和方法（题型：选择、判断、论述题）
组成与任务：用户界面由展示元素（如屏幕上的菜单、数据看板）和交互元素（如按钮、输入框、拖拽组件）组成。其核心任务是构建一个高效、清晰的人机交互桥梁，让用户能直观地向系统下达指令并获取准确的反馈。
原则与方法（论述题高频考点）：
置于用户控制之下：允许用户灵活取消或撤销操作，不要让系统反客为主，强迫用户进行无法中断的流程。
减少用户的记忆负担：提供合理的默认值，保持视觉层次清晰，避免让用户跨越多个页面去死记硬背长串的数据。
保持界面一致性：整个软件的交互逻辑、色彩规范、排版布局和专业术语必须高度统一。
25．软件概要设计与软件详细设计的任务、区别与联系（题型：选择、判断题）
任务与区别：
概要设计（高层设计）：核心任务是“模块划分”与“全局数据结构/数据库设计” 。它回答的是“系统由哪些大块组成，大块之间怎么传递数据”。
详细设计（底层设计）：深入到已经被划分好的单一模块内部，为其设计具体的“算法流程”和“局部数据结构”。它回答的是“这个具体功能模块到底怎么写代码来实现”。
联系：两者是宏观与微观的递进关系。概要设计是详细设计的基础、骨架和约束，详细设计则是概要设计的血肉填充与具体落实。
26．类设计中通用职责分配模式、设计原则、设计模式（题型：选择、判断题）
通用职责分配模式（GRASP）：用于指导在面向对象设计中，到底该把哪个职责（功能）分配给哪个类。常见的比如“信息专家模式”（谁拥有实现这个职责所需的数据，谁就负责处理这个逻辑）。
设计原则：最经典的如SOLID 原则。考试常考“单一职责原则”（一个类只应该因为一个原因而发生变化，即只干一件事）和“开闭原则”（对扩展开放，对修改封闭，即增加新功能时尽量加新代码，而不是改老代码）。
设计模式：前人总结的针对特定场景的“标准解法”。例如单例模式（确保系统里只有一个实例）、工厂模式（专门用来统一创建对象）、观察者模式（实现一对多的事件联动更新）。
27．类名、属性、方法的设计与精化，类间关系的判别（一对一、一对多、多对多关系）（题型：选择、判断、应用题）
设计与精化：在需求分析阶段，类可能只有一个粗略的类名。到了设计阶段，必须对它进行全面“精化”：明确其属性的具体数据类型（如整数型、字符串型），并明确其方法（函数）的具体输入参数格式和返回值类型。
类间关系判别（重点）：
一对一（1:1）：两个类之间是严密的独占关系 。例如，“移动堡垒”类与“核心能源炉”类。
一对多（1:N）：一个类拥有或包含多个另一个类 。例如，“研发部门”类与多名“软件工程师”类。
多对多（M:N）：双方均包含对方的多个实例 。例如，“学生”类与“选修课程”类（一个学生可以选多门课，一门课也可以有多个学生上）。在实际的系统设计中，多对多关系通常无法直接映射到数据库，必须引入一个中间类（如“选课记录表”）来进行拆解。
第7章 编码实现
28．程序代码的质量要求，程序代码的编码规范，程序代码风格（题型：选择、判断、论述题）
质量要求（论述题语料）：高质量的代码必须具备可读性（首要标准）、可维护性、可靠性和高效率。如果考试问“评价代码质量最重要的标准是什么”，答案永远是可读性。代码被阅读的次数远远多于被编写的次数。
编码规范：团队开发中必须遵守的强制性规则。比如在写自动化脚本时，Python 界公认的 PEP 8 就是一种规范。规范规定了怎么导包、怎么处理异常、文件怎么组织。
程序代码风格：偏向于个人或团队的排版习惯。包括：
命名规则：变量名必须见名知意。比如使用驼峰命名法（camelCase）或蛇形命名法（snake_case）。
注释：注释不是用来翻译代码的（不要写“i++ // i加1”），而是用来解释“为什么这么做”的业务逻辑。
缩进与排版：利用合理的空行和缩进来体现代码的逻辑块。
29．代码重用的概念、方式、方法及优缺点（题型：选择、判断、论述题）
概念：不要重复造轮子。利用已有的软件元素（如代码段、函数、类、组件）来构建新的软件系统。
方式/级别：
代码级：直接复制粘贴一段算法代码（最基础，但不推荐滥用）。
模块/函数级：将通用逻辑封装成函数调用。
类/对象级：通过面向对象的继承机制重用父类属性和方法。
组件/框架级：调用现成的第三方库。比如你做测试时直接引入 pytest 框架或 Selenium WebDriver 工具包，这就是典型的组件级重用。
优缺点（论述题必背）：
优点：大幅降低开发成本和周期；提高软件可靠性（因为重用的模块通常是经过严格测试的，比如成熟的开源库）；提高开发效率。
缺点：存在学习成本（需要花时间读懂别人的文档或源码）；可能引入不必要的依赖和安全风险；有时会为了适配现有组件而妥协系统的部分架构。
30．程序调试方法及工具（题型：选择、判断题）
你需要分清“测试”和“调试”的区别：测试（Testing）是为了发现 Bug，而调试（Debugging）是为了定位并修复 Bug。
常见调试方法：
强行排错法（试探法）：最原始的方法，比如在代码里到处打print() 或查日志，看哪一步输出的数据不对。
回溯法：从发现错误的地方开始，人工沿着控制流往回追踪代码，直到找到出错的源头。适合小型程序。
原因排除法（归纳/演绎法）：提出关于 Bug 为什么会发生的假设，然后用数据去证明或反驳这个假设（比如二分法注释掉一半代码看是否报错）。
调试工具：现代IDE（如 PyCharm, VS Code）自带的 Debugger。核心功能包括设置断点（Breakpoint）、单步步入（Step Into）、单步步过（Step Over）以及实时查看内存变量。
31．低代码编程的发展、概念、工作原理（题型：选择、判断题）
概念：一种软件开发方法，它主要通过图形化用户界面（拖拽组件）和配置来创建应用，而不是像传统方式那样手写大量代码。
工作原理：
模型驱动：底层由平台引擎支撑，开发者在界面上设计的业务流程图和数据模型，平台会自动将其转换为机器可执行的代码或配置脚本。
可视化编排：提供现成的UI 组件库和逻辑动作块，开发者像搭积木一样拼装系统。
发展与意义：旨在解决专业开发人员短缺的问题，降低开发门槛，让不懂编程的业务人员（平民开发者）也能快速搭建简单的管理系统或审批流程，极大地缩短了交付周期。
第8章 软件测试
32．软件错误、缺陷和故障的概念，三者间差异性（题型：选择、判断题）
错误(Error)：是人犯的错。比如程序员在敲代码时，把 < 写成了 <=，或者脑子里理解错了需求。
缺陷(Defect/Bug)：是存在于代码或文档中的瑕疵。程序员犯了“错误”，导致代码中留下了一个“缺陷”（那行写错的代码本身就是缺陷）。
故障(Failure/失效)：是系统运行时表现出来的异常。当含有缺陷的代码被执行时，系统没有按照预期工作（比如程序崩溃、计算结果出错），这就是故障。
一句话总结：开发人员的错误导致了软件中的缺陷，缺陷在运行时引发了系统的故障。
33．软件测试的概念（题型：选择、判断题）
经典定义（Myers）：测试是为了发现错误而执行程序的过程。
避坑指南：在判断题中，如果出现“测试的目的是为了证明程序没有 Bug”、“测试可以证明程序是完全正确的”，一律判错。测试只能证明程序存在缺陷，不能证明程序没有缺陷。
34．软件测试用例的概念、构成（测试用例名称/编号、测试目的、输入数据、预期输出、测试步骤等）及表示，测试用例的编写（题型：选择、判断、应用题）
概念：为特定目的而设计的一组测试输入、执行条件和预期结果。
核心构成（背诵标准表头）：
用例编号/名称：唯一标识（如 TC_Login_001）。
测试目的：为什么要测这个（如“验证密码输入为空时的系统提示”）。
输入数据：具体输入的值。
预期输出：系统应该给出的正确反应。
测试步骤：执行测试的具体动作。
实践映射：联想一下编写pytest 脚本的过程——函数名对应测试目的，传入的参数就是输入数据，函数体内的操作是测试步骤，而最后的 assert 断言就是在对比实际结果与预期输出。考试时，通常要求你画一个表格，把这些要素填进去。
35．软件测试策略（单元、集成、冒烟、系统、验收测试）及对应方法（题型:选择、判断题）。
单元测试(Unit Testing)：测试最小的可独立运行的代码块（通常是函数或类），通常由开发人员自己完成（白盒）。
集成测试(Integration Testing)：把单元模块组装起来，测试它们之间的接口和数据传递是否有问题。
冒烟测试(Smoke Testing)：对软件的核心基本功能进行快速验证。就像硬件通电看冒不冒烟，如果核心功能（如连启动都启动不了）瘫痪，直接打回，拒绝进行后续深度测试。
系统测试(System Testing)：将软件与硬件、外部系统结合，在真实环境下对完整系统进行全面测试（主要验证非功能需求，如性能、安全性）。
验收测试(Acceptance Testing)：由用户/客户主导，确认系统是否满足他们的业务需求（Alpha测试在开发环境下由用户做，Beta测试在实际环境下由多个用户做）。
36．白盒测试的概念和思想，典型的白盒测试技术，各技术的含义与目标，白盒测试中测试用例的输入数据和预期输出（题型：选择、判断、应用题）
思想：把软件看作一个透明的白盒子，完全了解程序内部的逻辑结构和执行路径，针对代码本身进行测试。
典型技术（逻辑覆盖标准，从弱到强）：
语句覆盖：设计用例，让程序里每一行可执行的代码至少执行一次。
判定覆盖（分支覆盖）：设计用例，让程序里每个判断（如if 语句）的 True 和 False 分支至少都执行一次。
条件覆盖：让判断语句中每个逻辑条件的True 和 False 都至少出现一次。
路径覆盖：覆盖程序中所有可能的执行路径（最强，但通常无法实现100%覆盖）。
解题技巧：考试会给一张程序流程图。你需要顺着箭头找路径，挑选合适的输入数据，确保填满题目要求的覆盖标准，并写出对应的预期结果。
37．黑盒测试的概念和思想，典型的黑盒测试技术，各技术的具体方法与任务，黑盒测试的测试用例编写（题型：选择、判断、应用题）
思想：把软件看作一个打不开的黑盒子，不关心内部代码，只关心给什么输入，系统给什么输出。利用Selenium 模拟用户在前端界面点击页面元素、输入表单来验证系统反馈，就是典型的黑盒测试自动化。
典型技术：
等价类划分法：如果输入范围是1~100。那么输入50和60效果是一样的，它们属于“有效等价类”。输入-1和200属于“无效等价类”。每个等价类挑一个数据测就行了，大大减少测试工作量。
边界值分析法（极其重要）：Bug 最容易出现在边界上！如果要求输入1~100。你必须取：刚好等于1、刚好等于100、比1小一点点（0）、比100大一点点（101）。考试大题通常要求结合等价类和边界值一起来设计输入数据。
判定表/因果图：用于处理输入条件之间存在复杂组合关系（比如：条件A和条件B同时满足才执行动作C）的情况。
38．灰盒测试的概念和思想，典型的灰盒测试技术，各技术的具体方法与任务，灰盒测试的测试用例编写（题型:选择、判断、应用题）
思想：介于白盒与黑盒之间。既关注输出对于输入的正确性，也关注内部表现，但不会像白盒那样详细到每一行代码。
示例：通过前端页面提交了一个订单（黑盒表现），然后不仅看页面提示“成功”，还要连接数据库查看订单表里是否真的正确插入了这条数据、状态字段是否正确（白盒层面的数据结构验证）。
39．软件测试前沿技术、工具（题型:选择、判断题）。
常用工具：记住几个业界标杆即可。单元测试工具（JUnit、pytest）、UI自动化工具（Selenium、Appium）、性能测试工具（JMeter、LoadRunner）。
前沿技术：了解测试驱动开发（TDD，先写测试用例再写业务代码）、持续集成测试（CI/CD中的自动化流水线拦截）、以及基于AI的缺陷预测和测试用例自动生成。
第9章 软件部署与维护
40．软件部署的概念和任务（题型：选择、判断题）
概念：软件部署是将开发完毕的软件从开发/测试环境顺利过渡并安装到真实生产环境，使其能够为最终用户提供服务的过程 。 任务：不仅是“复制粘贴代码”。它包括环境准备、软件安装、配置参数调整、数据迁移、系统启动以及运行状态的初始验证。
41．软件部署的方式（单机部署、分布式部署、虚拟化部署、容器化部署），各部署方式的特点、优缺点（题型：选择、判断题）
单机部署：所有程序和服务全跑在一台物理机上。优点是极其简单、成本低；缺点是存在“单点故障”（机器一宕，全盘崩溃），无法应对大流量。
分布式部署：将系统拆分，部署在多台通过网络连接的机器上。优点是高可用、可扩展；缺点是运维极其复杂，排查问题困难。
虚拟化部署：在一台物理机上通过虚拟机软件（如VMware）虚拟出多台相互隔离的操作系统。优点是资源利用率高、隔离性强；缺点是每个虚拟机都要跑完整的操作系统，太重、启动慢。
容器化部署（现代主流）：将程序及其依赖打包成一个轻量级的“容器”（如 Docker）。优点是极其轻量、启动秒级、保证了“开发环境和生产环境完全一致”；缺点是对底层操作系统的依赖较强 。
42．软件部署的方法（CI/CD、DevOps、无服务器部署、微服务化与编排、CDN加速），各部署方法的特点、优缺点和工具（题型；选择、判断、论述题）
CI/CD（持续集成/持续交付）：核心理念是“自动化”。开发者一提交代码，系统自动触发编译、测试和部署流水线 。常用工具：Jenkins、GitLab CI。
DevOps：开发（Dev）和运维（Ops）的结合。它不仅是技术，更是一种打破部门壁垒的文化，旨在缩短系统开发生命周期，确保持续交付高质量软件。
无服务器部署（Serverless）：开发者只管写核心业务逻辑代码，完全不用操心服务器的购买、配置和扩容 。平台（如阿里云函数计算）按代码执行次数收费。
微服务化与编排：把一个庞大的单体应用拆分成几十个独立的小服务，每个服务独立部署。编排工具（如Kubernetes/K8s）负责管理这些海量服务的生老病死。
CDN加速：内容分发网络。把图片、视频等静态资源缓存到离用户最近的边缘节点服务器上，提升访问速度 。
43．提高软件可维护性的方法（模块化设计、规范化编码、持续集成、可测试性设计、日志和监控、文档化）及其内容（题型:选择、判断、论述题）。
模块化设计：做到高内聚、低耦合，改动一个功能不至于牵连全局。
规范化编码：团队统一代码风格，变量命名见名知意。
持续集成：用自动化工具频繁测试，及早发现缺陷。
可测试性设计：代码在设计时就留好测试接口。
日志和监控：系统出Bug时，有详尽的运行日志可以排查（就像飞机的黑匣子）。
文档化：代码和文档必须同步更新，拒绝“祖传代码，全靠口头交接” 。
44．软件维护的形式和类别（纠正性维护、改善型维护、适应性维护、预防性维护），各种维护类别的概念和任务（题型：选择、判断、论述题）
纠正性维护（抓Bug）：软件交付后，用户发现了测试阶段没漏掉的缺陷，你跑去修复。
适应性维护（换环境）：软件没坏，但外部环境变了（比如操作系统升级了，或者数据库换了），为了让软件能在新环境运行而做的修改。
改善型维护/完善性维护（加功能）：用户提出了新需求，要求增加新功能或提升性能。这是维护工作量最大、占比最高的一类。
预防性维护（大重构）：软件目前没出问题，但为了防止未来系统僵化，主动进行代码重构，为将来的升级打基础。
45．软件维护的副作用（编码副作用、数据副作用、文档副作用）（题型:选择、判断、论述题）
副作用就是“按下葫芦浮起瓢”，改了一个地方，搞坏了另一个地方。编码副作用：为了修复Bug A，修改了代码，结果不小心引入了新的 Bug B。
数据副作用：修改了数据库的表结构或数据类型，导致那些依赖旧格式的老程序直接崩溃。
文档副作用：代码逻辑已经大改了，但是《设计说明书》和《用户手册》没跟着更新，导致后来的接手人被文档误导。
46．软件维护的典型问题（文档问题、人员流动、设计问题、代码质量、时间限制、技术债务、兼容性和测试、团队沟通）、实施策略（反应性策略、前摄性策略）（题型:选择、判断题）
典型问题：主要包括文档缺失（最头疼）、人员流动快（懂代码的人离职了）、历史技术债务沉重、代码质量低下如同“屎山”。
策略：
反应性策略：出了问题才去修，典型的“救火队员”模式。
前摄性策略：未雨绸缪，主动进行代码审查和预防性重构，属于“防火”模式 。
47．软件维护技术（DOM、FOM、软件再工程、逆向工程）（题型:选择、判断题）。
逆向工程（Reverse Engineering）：手里只有别人的祖传源代码（没有文档），通过分析代码，反推出它的设计图纸（流程图、类图等）。
软件再工程（Re-engineering）：不仅是反推，推出来之后还要进行大刀阔斧的改造、重构和重新编写，把一个老旧的破系统彻底翻新成一个现代化的新系统 。
第10章 软件项目管理
48．项目的特点（唯一性、一次性、时间性）、重要概念（题型:选择、判断题）。
项目的特点：
唯一性：世界上没有两个完全相同的项目，即使是做同类型的软件，客户、团队或环境也一定不同。
一次性/临时性：项目有明确的开始和结束时间，不是日常流水线那样无休止的重复工作。
时间性：必须在规定的时间窗口内完成。
49．项目管理三要素（质量、成本、时间）（题型:选择、判断题）。
这三要素构成了项目管理的“铁三角”：质量（做得好不好）、成本（花了多少钱/人力）、时间（多久能做完）。
核心逻辑：这三者是相互牵制的。比如你想缩短“时间”，要么增加“成本”（加人加班），要么牺牲“质量”（少做几次测试）。选择题常考这三者之间的制约关系 。
50．软件规模、工作量估算的单位、方法（专家评估法、类比法、参数法）、模型，代码行技术、功能点技术（题型:选择、判断、应用题）。
估算技术（怎么算大小）：代码行技术(LOC)：靠估算代码行数来衡量规模。缺点是受编程语言影响太大（一行 Python 和一行 C 语言的工作量截然不同）。
功能点技术(FP)：从用户角度出发，通过数软件有多少个输入、输出、查询、内部文件等来计算功能点 。这是应用题常考点，通常会给你一张表和权重系数，让你套公式相乘求和。
估算方法（怎么算工作量）：
专家评估法（德尔菲法）：找几个经验丰富的老兵背靠背打分，然后取平均值。
类比法：参考以前做过的类似项目来估算现在的项目。
参数法（模型法）：最著名的是COCOMO 模型，把代码行数代入一个复杂的数学公式里，直接算出需要几个人、几个月。
51．软件项目计划的步骤、软件项目计划书的编写过程（题型:选择、判断、应用题）。
核心步骤：估算规模-> 估算工作量和成本 -> 制定进度表 -> 资源分配。
应用题考点：制定进度表时，常考两种图。一个是WBS（工作分解结构），把大任务像画树状图一样拆分成一个个能执行的小任务；另一个是甘特图（Gantt Chart）或PERT/CPM网络图，用来寻找“关键路径”（决定项目最短工期的那条路径）。
52．软件项目监控对象、方法、工具（题型:选择、判断题）。
计划做好了，执行过程中肯定会跑偏，这就需要监控。主要监控进度、成本和质量。
常用方法：最经典的是“挣值分析法 (Earned Value Analysis)”，通过对比计划预算和实际花销，用量化的数据来评估项目当前到底是超支了还是延期了 。
53．软件项目风险管理方法，主要步骤（风险识别、风险分析、风险优先级排序、风险管理规划、风险处理、风险监控），各步骤的含义（题型:选择、判断题），
风险管理就是应对“可能发生的坏事”。必须牢记其先后步骤：
风险识别：找出可能有哪些危险（如骨干程序员离职）。
风险分析与优先级排序：评估这个危险发生的概率和后果有多严重，挑出最致命的优先处理。
风险管理规划与处理：制定应对策略（如：避免、转移、缓解或接受）。
风险监控：在项目全程盯着，看危险到底有没有发生。
54．软件配置管理、配置项和基线的概念，版本控制系统的分类（本地、集中式、分布式）与工具（题型：选择、判断题）
核心概念：
配置管理(SCM)：专门用来管软件变更的机制，防止代码改乱了找不到历史版本。
配置项(CI)：受控的最小元素，可以是一段代码、一个需求文档或一张设计图。
基线(Baseline)：一个极其重要的里程碑。比如第一版需求评审通过了，就打个“基线”。以后谁想改基线里的东西，必须走极其严格的审批流程。
版本控制系统分类及工具：
本地：文件只能存在自己电脑上。
集中式：所有人连一台中央服务器（如SVN）。服务器挂了，大家都不能提交代码。
分布式：每个人的电脑上都有一个完整的代码库（如Git）。断网了也能在本地提交，是目前绝对的主流。
