题目：需求分析产生的主要文档是（ ）。
选项：
A. 可行性分析报告
B. 需求规格说明书
C. 项目开发计划
D. 设计说明书
知识点总结（0基础必看）
1. 软件工程生命周期阶段与核心文档
| 阶段 | 核心任务 | 主要文档 |
|---|
| 可行性研究 | 评估项目可行性 | 可行性分析报告 |
| 需求分析 | 明确用户需求 | 需求规格说明书（SRS） |
| 项目规划 | 制定开发计划 | 项目开发计划 |
| 系统设计 | 定义技术实现方案 | 设计说明书 |
| 编码与测试 | 实现与验证系统功能 | 测试用例、代码文档 |
| 部署与维护 | 上线及后续优化 | 维护日志、用户手册 |
2. 需求规格说明书（SRS）的内容结构
- 引言：
- 功能需求：
- 系统需实现的具体功能（如用户登录、订单支付）。
- 用例图：描述用户与系统的交互场景。
- 非功能需求：
- 性能（如响应时间≤2秒）、安全性（如数据加密）、兼容性（支持Chrome/Firefox）。
- 约束条件：
- 技术限制（如必须使用Java开发）、法律法规（如符合GDPR）。
- 附录：
3. 需求分析的核心方法
- 用户访谈与问卷调查：
- 原型设计：
- 通过低保真/高保真原型（如Axure、Figma）验证需求可行性。
- 用例建模：
- 使用UML用例图描述系统与外部实体的交互（如管理员管理用户）。
- 需求优先级排序：
- 采用MoSCoW法则（Must have, Should have, Could have, Won’t have）划分需求优先级。
4. 常见误区与避坑指南
- 误区1：混淆“用户需求”与“系统需求”。
- 正解：用户需求是业务角度的描述（如“快速生成报表”），系统需求需转化为技术指标（如“报表生成时间≤5秒”）。
- 误区2：忽视非功能需求。
- 正解：性能、安全性等非功能需求直接影响用户体验和系统稳定性。
- 误区3：需求文档过于模糊。
- 正解：需求需满足SMART原则（具体、可衡量、可实现、相关、有时限）。
扩展知识：需求变更管理
- 变更流程：
- 提交变更申请 → 评估影响（成本、进度） → 审批 → 更新需求文档 → 通知相关方。
- 工具支持：
- 使用Jira、Trello等工具跟踪需求状态，Confluence管理文档版本。
- 应对策略：
- 预留缓冲时间（如迭代开发中的弹性时间），采用敏捷开发快速响应变更。
7. 下面属于黑盒测试方法的是（ ）
A、条件覆盖
B、基本路径测试
C、判定覆盖
D、错误推测法
知识点总结（适合0基础初学者）
1. 黑盒测试与白盒测试的核心区别
| 测试类型 | 关注点 | 是否需要看代码 | 典型方法 |
|---|
| 黑盒测试 | 软件外部功能是否满足需求 | 不需要 | 等价类划分、边界值分析、错误推测法 |
| 白盒测试 | 代码逻辑是否正确 | 需要 | 条件覆盖、路径覆盖、判定覆盖 |
2. 选项分析
| 选项 | 正误 | 解析 |
|---|
| A | 错误 | 条件覆盖：属于白盒测试，要求代码中每个逻辑条件的可能结果都被覆盖。 |
| B | 错误 | 基本路径测试：属于白盒测试，通过分析程序控制流覆盖所有执行路径。 |
| C | 错误 | 判定覆盖：属于白盒测试，确保每个判定的“真”和“假”结果都被执行。 |
| D | 正确 | 错误推测法：基于经验和直觉推测程序中可能存在的错误，无需了解代码逻辑。 |
3. 黑盒测试的常用方法
- 等价类划分：
- 将输入数据划分为有效和无效的等价类，每个类选一个代表值测试。
- 示例：测试“年龄”输入框，有效类（1-150岁）、无效类（负数或>150）。
- 边界值分析：
- 针对输入范围的边界值设计测试用例（如最小值、最大值、略小于/大于边界）。
- 示例：测试允许输入1-100的字段，测试0、1、2、99、100、101。
- 错误推测法：
- 基于经验猜测易错点（如输入非法字符、超长字符串、空值）。
- 示例：在密码框中输入特殊符号（如
!@#$%^）测试兼容性。
- 场景法：
- 模拟用户实际使用场景（如电商下单流程：登录→选商品→支付→订单确认）。
4. 白盒测试方法举例
- 逻辑覆盖：条件覆盖、判定覆盖、路径覆盖等。
- 循环测试：测试循环边界（如0次、1次、最大次循环）。
- 数据流测试：跟踪变量从定义到使用的过程。
5. 实际应用场景
- 黑盒测试适用场景：
- 验收测试（用户验证功能是否符合需求）。
- 安全性测试（如输入SQL注入语句检测漏洞）。
- 白盒测试适用场景：
- 单元测试（开发阶段验证代码逻辑）。
- 性能优化（分析代码瓶颈）。
题目
E-R图中用来表示实体的图形是（ ）。
O A、菱形
O B、三角形
O C、矩形
O D、椭圆形
知识点总结（适合0基础初学者）
1. E-R图的基本元素与符号
- 实体（Entity）：
- 定义：现实世界中可区分的事物或概念（如学生、课程、订单）。
- 图形表示：矩形（选项C）。
- 属性（Attribute）：
- 定义：实体或联系的特征（如学生的姓名、课程编号）。
- 图形表示：椭圆形（选项D），通过直线连接到对应的实体或联系。
- 联系（Relationship）：
- 定义：实体之间的关联（如学生“选修”课程）。
- 图形表示：菱形（选项A），位于相连的实体之间。
2. 错误选项排除
- A. 菱形：表示实体间的联系（如“选课”），而非实体本身。
- B. 三角形：非E-R图标准符号，属干扰项。
- D. 椭圆形：表示属性（如学生年龄），而非实体。
3. E-R图的实际应用示例
- 场景：设计学生选课系统的数据库。
- 实体：
学生（矩形）、课程（矩形）。 - 联系：
选修（菱形），连接学生与课程。 - 属性：学生有
学号（椭圆形），课程有课程名（椭圆形）。
4. 扩展：E-R图的规范化与转换
- 逻辑模型到物理模型：E-R图最终会转换为数据库表结构。
- 实体 → 表（如
学生表）。 - 属性 → 表字段（如
学号、姓名）。 - 联系 → 外键或关联表（如
选课表存储学生与课程的对应关系）。
总结图示
E-R图符号速记：
[学生] ---- <选修> ---- [课程] | |
(学号) (课程名)
题目
下列叙述中正确的是（ ）。
OA、关系模式的候选关键字可以有1个或多个
OB、关系模式的候选关键字只能有1个
OC、关系模式可以没有候选关键字
OD、关系模式必须有2个以上的候选关键字
零基础知识点总结
1. 候选关键字的定义与作用
- 候选关键字（候选键）：能唯一标识关系中元组（行）的最小属性集合，且满足以下条件：
- 唯一性：任意两个元组的候选键值不同。
- 最小性：去掉候选键中的任意一个属性，剩余属性不再满足唯一性。
- 主键：从候选键中选择一个作为主要标识符，其他候选键称为“替代键”。
2. 选项逐项解析
| 选项 | 正确性 | 解释 |
|---|
| OA | ✅ | 关系模式可以有多个候选键（如学生表的学号、身份证号均可唯一标识学生）。 |
| OB | ❌ | 候选键数量不唯一，例如订单表中“订单号”和“用户ID+时间”均可作为候选键。 |
| OC | ❌ | 候选键是关系模式的必要约束，无候选键则无法保证数据唯一性，违反关系模型基本要求。 |
| OD | ❌ | 候选键数量可以是1个或多个，但无需强制要求2个以上。 |
3. 候选键的典型场景
- 单候选键：
- 示例：学生表
Student(Sno, Sname, Age) 中，Sno（学号）是唯一候选键。
- 多候选键：
- 示例：用户表
User(IDCard, Phone, Email) 中，IDCard（身份证号）、Phone（手机号）、Email（邮箱）均可作为候选键。
- 复合候选键：
- 示例：选课表
SC(Sno, Cno, Grade) 中，(Sno, Cno)（学号+课程号）是唯一候选键。
4. 候选键与范式设计
- 第一范式（1NF）：候选键的存在是基础要求，确保元组可唯一标识。
- 第二范式（2NF）：消除非主属性对候选键的部分依赖（仅针对复合候选键）。
- 第三范式（3NF）：消除非主属性对候选键的传递依赖。
5. 实际应用建议
- 主键选择原则：
- 选择值稳定（如学号而非手机号）。
- 选择单属性（优先于复合键）。
- 避免选择业务含义可能变化的字段（如部门编号可能因重组失效）。
- 替代键管理：
- 为替代键创建唯一索引以提高查询效率（如对身份证号字段建唯一索引）。
题目
设有课程关系模式如下：
R(C#, Cn, T, Ta)
（其中C#为课程号，Cn为课程名，T为教师名，Ta为教师地址）
假设不同课程号可以有相同的课程名，每门课程只有一位任课教师，但每位教师可以有多门课程。
关系R的范式最高达到（ ）。
A、1NF
B、2NF
C、3NF
D、BCNF
知识点总结（适合0基础初学者）
1. 范式定义与核心要求
| 范式 | 核心要求 | 关键判断条件 |
|---|
| 1NF | 所有属性都是原子的（不可再分）。 | 无重复列或嵌套结构。 |
| 2NF | 满足1NF，且所有非主属性完全依赖候选键（消除部分依赖）。 | 主键为单属性时自动满足。 |
| 3NF | 满足2NF，且所有非主属性直接依赖候选键（消除传递依赖）。 | 不存在非主属性间的依赖。 |
| BCNF | 满足3NF，且所有主属性与非主属性均完全依赖候选键（消除主属性对候选键的部分依赖）。 | 所有决定因素均为候选键。 |
2. 关系模式分析
- 候选键：
- 题目明确“不同课程号可以有相同课程名”，因此课程号**C#**是唯一候选键。
- 函数依赖：
- C# → Cn, T：课程号确定课程名和教师。
- T → Ta：教师名确定教师地址（每位教师有唯一地址）。
- 传递依赖：C# → T → Ta，即教师地址（Ta）通过教师名（T）间接依赖课程号（C#）。
3. 范式验证
| 范式 | 验证过程 | 结论 |
|---|
| 1NF | 所有属性（C#, Cn, T, Ta）均为原子值，无重复组或复合属性。 | ✔️ 满足 |
| 2NF | 主键为单属性C#，非主属性（Cn, T, Ta）完全依赖C#，无部分依赖问题。 | ✔️ 满足 |
| 3NF | 存在传递依赖（C# → T → Ta），非主属性Ta通过T间接依赖候选键C#，违反3NF规则。 | ❌ 不满足 |
| BCNF | 因不满足3NF，无需进一步验证。 | ❌ 不满足 |
4. 选项排除与验证
- 选项A（1NF）：虽然满足，但2NF更高，排除。
- 选项B（2NF）：正确，关系满足2NF但不满足3NF。
- 选项C（3NF）：错误，存在传递依赖。
- 选项D（BCNF）：错误，需先满足3NF。
5. 改进方案（达到3NF）
- 分解关系模式：
- R1(C#, Cn, T)：存储课程信息。
- R2(T, Ta)：存储教师信息。
- 分解后：
总结
- 核心结论：原关系模式因存在传递依赖（C# → T → Ta），最高仅满足2NF。
- 实践意义：
- 未规范化的关系可能导致数据冗余（如同一教师地址重复存储）。
- 通过分解消除传递依赖，可优化存储效率并减少更新异常。
- 举一反三：
- 若题目中教师地址（Ta）直接依赖课程号（C#），则关系可满足3NF。
- 若候选键包含多个属性（如C#+T），需重新分析部分依赖问题。
题目：下列选项中不属于实体的是（ ）。
选项：
A. 学生
B. 课程
C. 图书
D. 姓名
知识点总结（0基础必看）
1. 实体-联系模型（E-R模型）的核心概念
| 概念 | 定义 | 示例 |
|---|
| 实体 | 现实世界中独立存在的对象，可通过属性描述 | 学生、课程、图书 |
| 属性 | 实体的特征或性质，分为简单属性（不可分）和复合属性（可分解） | 姓名（简单）、地址（复合） |
| 联系 | 实体之间的关联关系（如1:1、1:N、M:N） | 学生选课（M:N联系） |
2. 实体的类型
- 强实体：
- 不依赖其他实体存在，拥有主键（唯一标识符）。
- 示例：
学生（学号为主键）。
- 弱实体：
- 依赖强实体存在，无独立主键，需结合强实体的主键标识。
- 示例：
订单项（依赖订单存在，主键为订单号+商品号）。
3. 属性的分类
| 属性类型 | 描述 | 示例 |
|---|
| 简单属性 | 不可再分的原子属性 | 学号、年龄 |
| 复合属性 | 可分解为多个子属性 | 地址（省、市、街道） |
