| @@ -0,0 +1,98 @@ | |||
| 基础学习任务要求 | |||
| - 理解代码管理的含义且熟练使用SourceTree进行代码管理 | |||
| - 熟练掌握Markdown的常用语法 | |||
| - 熟练使用IAR进行嵌入式工程的开发 | |||
| - 熟练使用SourceInSight进行代码查看及编辑 | |||
| - 熟练掌握VS2019的基本操作 | |||
| - 在VS2019平台下熟练掌握库的生成与使用 | |||
| - 了解单元测试的基本概念 | |||
| - 在VS2019平台下熟练掌握单元测试 | |||
| 验收说明: | |||
| - 在任务开始的第4个工作日早上8:40,统一进行理论知识的笔试 | |||
| - 任务开始的第6个工作日早上8:40,统一进行实操考试 | |||
| - 对每个软件的操作进行验收 | |||
| - 每个任务都需要使用Markdown书写相关学习文档 | |||
| - 基础学习(一共7道小题)可验收3次,若3次验收不通过则淘汰,文档验收也计入验收次数 | |||
| 注: | |||
| - 不是指每个小题各有3次,是指基础学习这一整个大题只有3次实操验收机会 | |||
| - 学习文档的目录结构如下图所示: | |||
| TrainCamp_姓名全拼_BasicLearn | |||
| |---Markdown | |||
| | |---pictures | |||
| | | |---图片1.png | |||
| | | |---图片2.png | |||
| | | |---图片3.png | |||
| | | | . | |||
| | | | . | |||
| | | | . | |||
| | | +---图片n.png | |||
| | +---Markdown.md | |||
| |---SourceTree | |||
| | |---pictures | |||
| | | |---图片1.png | |||
| | | |---图片2.png | |||
| | | |---图片3.png | |||
| | | | . | |||
| | | | . | |||
| | | | . | |||
| | | +---图片n.png | |||
| | +---SourceTree.md | |||
| |---IAR | |||
| | |---pictures | |||
| | | |---图片1.png | |||
| | | |---图片2.png | |||
| | | |---图片3.png | |||
| | | | . | |||
| | | | . | |||
| | | | . | |||
| | | +---图片n.png | |||
| | +---IAR.md | |||
| |---SourceInsight | |||
| | |---pictures | |||
| | | |---图片1.png | |||
| | | |---图片2.png | |||
| | | |---图片3.png | |||
| | | | . | |||
| | | | . | |||
| | | | . | |||
| | | +---图片n.png | |||
| | +---SourceInsight.md | |||
| |---Library | |||
| | |---pictures | |||
| | | |---图片1.png | |||
| | | |---图片2.png | |||
| | | |---图片3.png | |||
| | | | . | |||
| | | | . | |||
| | | | . | |||
| | | +---图片n.png | |||
| | +---Library.md | |||
| |---UnitTest | |||
| | |---pictures | |||
| | | |---图片1.png | |||
| | | |---图片2.png | |||
| | | |---图片3.png | |||
| | | | . | |||
| | | | . | |||
| | | | . | |||
| | | +---图片n.png | |||
| | +---UnitTestVisualStudio.md | |||
| |---VisualStudio | |||
| | |---pictures | |||
| | | |---图片1.png | |||
| | | |---图片2.png | |||
| | | |---图片3.png | |||
| | | | . | |||
| | | | . | |||
| | | | . | |||
| | | +---图片n.png | |||
| | +---VisualStudio.md | |||
| @@ -0,0 +1,46 @@ | |||
| # 代码管理相关知识点 | |||
| ## Git | |||
| - Git的概念 | |||
| - 三个区域的概念 | |||
| - 仓库的概念 | |||
| - 节点的概念 | |||
| - 分支的概念 | |||
| ## SourceTree | |||
| - SourceTree的概念 | |||
| - 仓库相关操作 | |||
| · 创建本地仓库 | |||
| · 打开本地仓库 | |||
| · 克隆远程仓库 | |||
| · 获取 | |||
| · 关联远程仓库 | |||
| - 节点相关操作 | |||
| · 提交 | |||
| · 重置 | |||
| · 回滚提交 | |||
| - 分支相关操作 | |||
| · 新建分支 | |||
| · 合并分支 | |||
| · 删除分支 | |||
| · 切换分支 | |||
| · 制造冲突 | |||
| · 解决冲突 | |||
| · 拉取 | |||
| · 推送 | |||
| - 其他 | |||
| · 书写忽略文件 | |||
| · 停止跟踪 | |||
| · 创建补丁1种 | |||
| · 应用补丁1种 | |||
| · 贮藏 | |||
| · 丢弃 | |||
| · 移除 | |||
| · 创建标签 | |||
| · 删除标签 | |||
| - 综合 | |||
| · 一系列操作后最终状态 | |||
| 附加: | |||
| - 变基 | |||
| - 创建补丁2种及以上 | |||
| - 应用补丁2种及以上 | |||
| @@ -0,0 +1,34 @@ | |||
| # Markdown相关知识点 | |||
| ## 常用语法 | |||
| - 标题相关 | |||
| · 一级标题 | |||
| · 二级标题 | |||
| · 三级标题 | |||
| - 标号相关 | |||
| · 无序标号 | |||
| · 有序标号 | |||
| · 标号嵌套 | |||
| - 文字相关 | |||
| · 加粗 | |||
| · 倾斜 | |||
| · 加粗倾斜 | |||
| · 删除线 | |||
| - 代码块 | |||
| · 单行代码块 | |||
| · 多行代码块 | |||
| - 超链接 | |||
| · 文字超链接 | |||
| · 图片超链接 | |||
| · 页面内跳转 | |||
| · 跳转到目录 | |||
| · 跳转到标题 | |||
| · 跳转到任意指定位置 | |||
| - 其他 | |||
| · 分割线 | |||
| · 图片 | |||
| · 表格 | |||
| · 引用 | |||
| 附加: | |||
| - 生成目录 | |||
| - 页面内跳转到指定位置2种 | |||
| @@ -0,0 +1,43 @@ | |||
| # IAR相关知识点 | |||
| ## 工程操作 | |||
| - 各类型文件含义 | |||
| - 新建/打开工作区 | |||
| - 新建/打开工程 | |||
| - 工作区中导入/添加工程 | |||
| - 新建分组 | |||
| - 新建/打开文件 | |||
| - 工程目录与文件目录的关系 | |||
| ## 工程配置 | |||
| - 设备配置 | |||
| - 编译配置 | |||
| · 优化等级 | |||
| · 硬件浮点 | |||
| · 预处理 | |||
| · 链接文件 | |||
| · 文件路径配置 | |||
| · 输出文件路径 | |||
| · 输出文件配置 | |||
| - 调试器配置 | |||
| - 库相关配置 | |||
| - 静态库的封装 | |||
| - 静态库的调用 | |||
| ## 工程调试 | |||
| - 断点 | |||
| · 设置断点 | |||
| · 禁用断点 | |||
| · 启用断点 | |||
| · 删除断点 | |||
| · 条件断点 | |||
| - 监控信息 | |||
| - 寄存器信息 | |||
| - 内存信息 | |||
| - 栈信息 | |||
| - 汇编信息 | |||
| - 调用堆栈信息 | |||
| - 单步调试 | |||
| · 逐过程 | |||
| · 逐语句 | |||
| · 复位 | |||
| · 跳出 | |||
| @@ -0,0 +1,8 @@ | |||
| # SourceInSight相关知识点 | |||
| ## 常规操作 | |||
| - 工程新建/添加 | |||
| - 文件新建/添加 | |||
| - 符号表同步 | |||
| - 视图切换 | |||
| - 常用窗口打开/关闭 | |||
| - 搜索引用 | |||
| @@ -0,0 +1,43 @@ | |||
| # VisualStudio相关知识点 | |||
| ## 工程创建 | |||
| - 工程相关 | |||
| · 创建/打开项目 | |||
| · 加载/卸载项目 | |||
| · 设置启动项 | |||
| - 解决方案相关 | |||
| · 添加项目 | |||
| - 文件相关 | |||
| · 创建/打开文件 | |||
| · 包括/排除文件 | |||
| ## 工程配置 | |||
| - 解决方案配置 | |||
| - 平台配置 | |||
| - 项目类型配置 | |||
| - 路径配置 | |||
| · 输出路径配置 | |||
| · 头文件路径配置 | |||
| · 源文件路径配置 | |||
| · 库文件路径配置 | |||
| - 宏定义 | |||
| - 运行库配置 | |||
| - 调用库配置 | |||
| - 安全检查 | |||
| ## 工程调试 | |||
| - 断点 | |||
| · 断点创建 | |||
| · 断点删除 | |||
| · 断点禁用 | |||
| · 断点启用 | |||
| · 条件断点 | |||
| - 窗口 | |||
| · 监视窗口 | |||
| · 内存窗口 | |||
| · 线程窗口 | |||
| · 调用堆栈窗口 | |||
| - 单步调试 | |||
| · 全速运行 | |||
| · 重新运行 | |||
| · 逐过程 | |||
| · 逐语句 | |||
| @@ -0,0 +1,7 @@ | |||
| # 单元测试相关知识点 | |||
| ## 单元测试 | |||
| - 单元测试创建 | |||
| - 代码覆盖度 | |||
| - 运行性能 | |||
| - 测试样例书写 | |||
| - 单元测试的调试 | |||
| @@ -0,0 +1,17 @@ | |||
| # 库相关知识点 | |||
| ## 静态库 | |||
| - 静态库的基本概念 | |||
| - 静态库的生成 | |||
| - 静态库的调用 | |||
| · 在工程配置中调用 | |||
| · 在代码中语句加载lib调用 | |||
| ## 动态库 | |||
| - 动态库的基本概念 | |||
| - 动态库的生成 | |||
| · 通过导出语句生成 | |||
| · 通过模块文件生成 | |||
| - 动态库的调用 | |||
| · 在工程配置中调用 | |||
| · 在代码中语句加载lib调用 | |||
| · 在代码中语句加载dll调用 | |||
| @@ -1,5 +1,7 @@ | |||
| # IAR 学习文档 | |||
| [TOC] | |||
| ## 1. IAR 简介 | |||
| IAR Embedded Workbench 是常用的嵌入式集成开发环境,主要用于单片机工程的创建、代码编写、编译、链接、下载和调试。 | |||
| @@ -47,6 +49,34 @@ IAR 工程中常见文件类型如下: | |||
| | `.hex` | 可下载或烧录的十六进制文件 | | |||
| | `.bin` | 二进制烧录文件 | | |||
| | 文件类型 | 文件含义 | 主要作用 | 备注 | | |||
| | ----------------- | ------------------------------------------ | ---------------------------------------------------- | ----------------------------------- | | |||
| | **`.eww`** | **Workspace 工作空间文件** | **记录当前工作空间中包含哪些工程** | **通常双击它打开整个 IAR 工作空间** | | |||
| | **`.ewp`** | **Project 工程文件** | **记录工程文件列表、编译选项、链接选项等** | **工程核心配置文件** | | |||
| | **`.ewd`** | **Debugger 调试配置文件** | **记录调试器、下载器、调试参数等配置** | **和下载、仿真、调试相关** | | |||
| | `.ewt` | Project Template 工程模板文件 | 用于保存工程模板 | 平时较少手动修改 | | |||
| | **`.c`** | **C 源文件** | **编写 C 语言程序代码** | **主要代码文件** | | |||
| | **`.h`** | **头文件** | **存放函数声明、宏定义、结构体、变量声明等** | **通常被 `.c` 文件包含** | | |||
| | **`.s` / `.asm`** | **汇编文件** | **编写汇编代码** | **常见于启动文件** | | |||
| | `.cpp` | C++ 源文件 | 编写 C++ 程序代码 | 嵌入式中相对少见 | | |||
| | **`.icf`** | **Linker Configuration File 链接配置文件** | **配置 Flash、RAM 地址、代码段、数据段、栈和堆大小** | **非常重要,和内存分配有关** | | |||
| | `.xcl` | Linker Command File 链接命令文件 | 老版本 IAR 使用的链接配置文件 | 新工程中多用 `.icf` | | |||
| | `.ddf` | Device Description File 设备描述文件 | 描述芯片寄存器、外设等信息 | 和芯片支持包有关 | | |||
| | `.mac` | Macro File 宏文件 | 用于调试初始化、自动执行调试命令等 | 调试时可能用到 | | |||
| | `.o` | Object File 目标文件 | `.c` / `.s` 编译后的中间文件 | 还不是最终可执行文件 | | |||
| | `.pbi` | Browse Information 浏览信息文件 | 用于代码跳转、符号查找等浏览功能 | IAR 自动生成 | | |||
| | `.pbd` | Project Browse Database 工程浏览数据库 | 保存工程浏览信息 | IAR 自动生成 | | |||
| | `.dep` | Dependency File 依赖文件 | 记录源文件和头文件之间的依赖关系 | 用于增量编译 | | |||
| | `.lst` | List File 列表文件 | 显示 C 代码与汇编代码的对应关系 | 可用于分析编译结果 | | |||
| | **`.out`** | **IAR 输出文件** | **IAR 默认生成的可执行调试文件** | **常用于下载和调试** | | |||
| | `.elf` | ELF 可执行文件 | 一种通用可执行文件格式 | 部分配置下生成 | | |||
| | **`.hex`** | **Intel HEX 文件** | **常用于单片机烧录** | **烧录工具常用** | | |||
| | **`.bin`** | **Binary 二进制文件** | **纯二进制程序文件** | **也可用于烧录** | | |||
| | **`.map`** | **Map 映射文件** | **查看函数地址、变量地址、Flash/RAM 占用情况** | **分析内存占用很常用** | | |||
| | **`.a`** | **Static Library 静态库文件** | **多个目标文件打包成的库文件** | **IAR 中常见静态库格式** | | |||
| | **`.lib`** | **Library 库文件** | **库文件,供工程链接使用** | **不同平台或厂商库可能使用** | | |||
| | `.log` | Log 日志文件 | 记录编译、链接、调试等日志信息 | 用于查看错误和过程信息 | | |||
| 简单理解: | |||
| ```text | |||
| @@ -264,7 +294,7 @@ CMSIS:存放内核相关文件 | |||
| IAR 中可以新建源码文件,也可以打开已有文件。 | |||
| ## 8.1 新建文件 | |||
| ### 8.1 新建文件 | |||
| 操作步骤: | |||
| @@ -685,7 +715,7 @@ Project → Options → C/C++ Compiler → Preprocessor | |||
| 6. 点击 **OK** 保存配置。 | |||
|  | |||
|  | |||
| 注意:这里添加的是头文件所在的**文件夹路径**,不是具体的 `.h` 文件。 | |||
| @@ -748,20 +778,6 @@ $PROJ_DIR$\Lib\Include\lib_demo.h | |||
| .map | |||
| ``` | |||
| ## 18. 输出文件路径配置 | |||
| 输出文件路径配置用于设置 IAR 编译后生成文件的保存位置。 | |||
| 常见输出文件包括: | |||
| ```text | |||
| .out | |||
| .hex | |||
| .bin | |||
| .map | |||
| .obj | |||
| ``` | |||
| 其中,`.out`、`.obj`、`.map` 等文件一般会生成到工程的输出目录中。 | |||
| ### 18.1 操作步骤 | |||
| @@ -1574,7 +1590,7 @@ Project → Download and Debug | |||
| 断点用于让程序运行到指定代码行时暂停,方便查看当前变量、寄存器和程序状态。 | |||
| ## 26.1 设置断点 | |||
| ### 26.1 设置断点 | |||
| 操作步骤: | |||
| @@ -1585,7 +1601,7 @@ Project → Download and Debug | |||
|  | |||
| ## 26.2 禁用断点 | |||
| ### 26.2 禁用断点 | |||
| 禁用断点是指暂时不使用该断点,但不删除断点。 | |||
| @@ -1597,13 +1613,13 @@ Project → Download and Debug | |||
| 3. 选择 Disable Breakpoint; | |||
|  | |||
|  | |||
| 4. 断点变为禁用状态。 | |||
|  | |||
| ## 26.3 启用断点 | |||
| ### 26.3 启用断点 | |||
| 如果需要重新使用被禁用的断点,可以启用断点。 | |||
| @@ -1621,7 +1637,7 @@ Project → Download and Debug | |||
| ## 26.4 删除断点 | |||
| ### 26.4 删除断点 | |||
| 删除断点是指将断点完全移除。 | |||
| @@ -1632,7 +1648,7 @@ Project → Download and Debug | |||
| 或者右键断点,选择删除断点。 | |||
| ## 26.5 条件断点 | |||
| ### 26.5 条件断点 | |||
| 条件断点是指只有满足指定条件时,程序才会在该断点处暂停。 | |||
| @@ -1839,7 +1855,7 @@ Error_Handler | |||
| 跳出 | |||
| ``` | |||
| ## 33.1 逐过程 | |||
| ### 33.1 逐过程 | |||
| 逐过程一般对应 Step Over。 | |||
| @@ -1859,7 +1875,7 @@ Debug → Step Over | |||
| 只关心当前函数执行结果,不需要进入函数内部。 | |||
| ``` | |||
| ## 33.2 逐语句 | |||
| ### 33.2 逐语句 | |||
| 逐语句一般对应 Step Into。 | |||
| @@ -1879,7 +1895,7 @@ Debug → Step Into | |||
| 需要查看函数内部具体执行过程。 | |||
| ``` | |||
| ## 33.3 复位 | |||
| ### 33.3 复位 | |||
| 复位用于将程序重新复位到初始状态。 | |||
| @@ -1899,7 +1915,7 @@ Debug → Reset | |||
| 需要重新观察初始化流程 | |||
| ``` | |||
| ## 33.4 跳出 | |||
| ### 33.4 跳出 | |||
| 跳出一般对应 Step Out。 | |||
| @@ -2067,4 +2083,56 @@ IAR 学习主要包括工程操作、工程配置和工程调试三部分。 | |||
| 单步调试 | |||
| ``` | |||
| 通过以上学习,可以掌握 IAR 在嵌入式工程中的基本使用流程,为后续进行单片机程序开发、编译下载和调试分析打下基础。 | |||
| ## 37. 考试知识点补充(按章节归类) | |||
| ### 37.1 工程、工作区和文件类型 | |||
| 1. `.eww` 是工作区文件,用于保存工作区中的工程组织关系;`.ewp` 是工程文件,用于保存工程配置。 | |||
| 2. 如果只需要保留基本工程信息,通常需要保留 `.eww` 和 `.ewp`;如果还要保留调试器、下载器、连接器等调试相关信息,还需要保留 `.dep`、`.ewt` 等相关文件。 | |||
| 3. `.eww` 和 `.ewp` 是重要工程文件,不能当作普通临时文件删除。 | |||
| 4. `.hex` 是编译链接后生成的输出文件,可根据需要重新生成,因此相对工程配置文件来说可以删除。 | |||
| 5. `.a` 是 IAR 中常见的静态库文件后缀;`.icf` 是 IAR ILINK 链接器配置文件;`.map` 是链接后生成的内存映射信息文件。 | |||
| 6. 工程目录用于存放工程相关文件,文件目录是操作系统中实际保存文件的目录。工程目录可以包含文件目录,文件目录也可能位于工程目录外。 | |||
| 7. IAR 中不是只有新建分组后才能新建文件;分组主要用于组织工程文件结构。 | |||
| ### 37.2 新建工程和工程模板 | |||
| 1. 新建工程时如果代码和文件需要自己编写,通常选择 `Empty Project`。 | |||
| 2. 工程模板中的 `C`、`C++`、`Asm` 等模板会带有对应类型的基础结构;空工程更适合从头组织嵌入式工程。 | |||
| ### 37.3 编译、优化和路径配置 | |||
| 1. IAR 优化等级包括无优化、低等级优化、中等优化、高等级优化。需要更快执行速度时,一般选择较高优化等级。 | |||
| 2. 优化等级不一定要求大于默认初始优化等级,应根据调试、代码体积、实时性和执行速度综合选择。 | |||
| 3. 高等级优化可能改变代码结构,可能增加编译时间,也可能使单步调试和变量查看不够直观;它通常可以提升执行速度,但不代表一定会让文件体积和代码量增加。 | |||
| 4. 头文件路径、库文件路径等文件路径配置建议使用相对路径,避免工程目录移动后找不到文件。 | |||
| 5. 预处理器配置位置通常是:`Project -> Options -> C/C++ Compiler -> Preprocessor`。预处理不只配置相对路径,还包括宏定义、头文件包含路径等内容。 | |||
| ### 37.4 链接文件、map 文件和静态库 | |||
| 1. `.icf` 链接文件用于配置 ROM、RAM 等存储区域的起始地址、结束地址、大小,以及 section 放置规则。 | |||
| 2. 链接文件不是用来分析代码内存占用的结果文件;分析占用情况主要看 `.map` 文件。 | |||
| 3. `.map` 文件记录程序链接后的内存映射信息,可查看堆栈、各段、符号、地址范围和内存占用情况,是分析代码内存占用的重要文件。 | |||
| 4. 链接文件由不同地址块、可编址存储空间、不同存储地址区域和 section 放置规则组成。 | |||
| 5. IAR 库相关配置中,`Custom` 表示可以指定用户自定义库配置文件;`Normal` 表示普通运行库。`Full` 通常不是“不支持文件描述符和多字节操作”的选项,`None` 表示不链接运行库,通常也不支持运行库能力。 | |||
| 6. 静态库通常不能独立运行。使用静态库编译出的可执行文件才可以独立运行;当程序使用到库中的函数时,库代码会在链接阶段参与生成最终程序。 | |||
| 7. 使用静态函数库编译出的最终可执行文件可能较大;如果库更新,通常需要重新编译或重新链接主程序。 | |||
| ### 37.5 调试接口和硬件浮点 | |||
| 1. 标准 JTAG 常见调试信号包括 4 条主要信号线:`TCK`、`TMS`、`TDI`、`TDO`,实际接口还会配合电源、地、复位等信号使用。 | |||
| 2. SWD 调试接口主要使用 `SWDIO` 和 `SWCLK`,`SWO` 是可选跟踪输出信号,`GND` 是参考地。 | |||
| 3. 硬件 FPU 使用实际浮点运算单元,可提高浮点计算能力。FPU 通常配有额外寄存器用于浮点参数传递和运算。 | |||
| 4. F3 系列芯片通常不作为可配置硬件浮点的典型系列;是否支持硬件浮点要以具体芯片内核和手册为准。 | |||
| ### 37.6 调试窗口和断点 | |||
| 1. Watch、Live Watch、Quick Watch 都属于常见监控信息窗口;Watch 可用于观察静态变量,Live Watch 适合实时观察变量,Quick Watch 适合临时查看表达式或变量。 | |||
| 2. 监控信息不只限于变量值,还可能结合寄存器窗口、内存窗口查看寄存器值和内存值。 | |||
| 3. 寄存器是有限存储容量的高速存储部件,可暂存指令、数据和地址。 | |||
| 4. 设置断点时,可以点击需要设置断点语句的前侧,也可以右键选择 `Toggle Breakpoint(Code)`;`Enable/disable Breakpoint` 用于启用或禁用已有断点,不是创建断点。 | |||
| 5. 条件断点是代码断点与标志、变量或表达式条件的组合,只有满足条件时才中断。 | |||
| 6. 硬件断点数量受芯片硬件资源限制;软件断点或在 RAM 中运行程序时,断点数量不完全等同于硬件断点数量限制。 | |||
| 7. `Step Over` / `Next Statement` 表示逐过程,不进入函数内部;`Step Into` 表示进入函数内部;`Step Out` 表示跳出当前函数。 | |||
| 通过以上学习,可以掌握 IAR 在嵌入式工程中的基本使用流程,为后续进行单片机程序开发、编译下载和调试分析打下基础。 | |||
| @@ -1,5 +1,7 @@ | |||
| # Visual Studio 2019 库学习文档 | |||
| [TOC] | |||
| ## 1. 学习目标 | |||
| 本文档用于记录 Visual Studio 2019 平台下库文件的生成与使用方法,主要包括静态库和动态库两部分内容。 | |||
| @@ -598,7 +600,7 @@ extern "C" int Sub(int a, int b); | |||
| 这里不使用 `__declspec(dllexport)`,而是通过 `.def` 文件指定导出函数。 | |||
|  | |||
|  | |||
| #### 5.4.2 编写 DLL 源文件 | |||
| @@ -618,7 +620,7 @@ int Sub(int a, int b) | |||
| } | |||
| ``` | |||
|  | |||
|  | |||
| #### 5.4.3 添加模块定义文件 | |||
| @@ -651,7 +653,7 @@ EXPORTS | |||
| MathDllDef.def | |||
| ``` | |||
|  | |||
|  | |||
| #### 5.4.4 DEF 文件方式注意事项 | |||
| @@ -662,7 +664,7 @@ MathDllDef.def | |||
| 3. `.def` 文件适合集中管理导出函数; | |||
| 4. 如果导出函数较多,`.def` 文件比在每个函数前写导出语句更清晰。 | |||
|  | |||
|  | |||
| ### 5.5 动态库的调用 | |||
| @@ -821,7 +823,31 @@ int main(void) | |||
| 7. DLL 可以放在 exe 同级目录,也可以放在系统 PATH 能找到的目录; | |||
| 8. 显式加载 DLL 时,要检查 `LoadLibrary` 和 `GetProcAddress` 的返回值。 | |||
|  | |||
|  | |||
| ### 5.10 运行库配置与库调用兼容性 | |||
| 库文件能否正常调用,不只和 `.h`、`.lib`、`.dll` 路径有关,也和主程序、静态库、动态库项目的运行库配置有关。尤其是静态库项目,建议和主程序保持相同的运行库配置,避免链接冲突或运行异常。 | |||
| VS2019 中常见运行库标识如下: | |||
| | 标识 | 名称 | 含义 | | |||
| |---|---|---| | |||
| | `/MD` | 多线程 DLL | Release 常用,使用动态运行库 | | |||
| | `/MDd` | 多线程调试 DLL | Debug 常用,使用动态调试运行库 | | |||
| | `/MT` | 多线程 | Release 可用,静态链接运行库 | | |||
| | `/MTd` | 多线程调试 | Debug 可用,静态链接调试运行库 | | |||
| 记忆方法: | |||
| ```text | |||
| M:Multi-threaded,多线程 | |||
| D:DLL,动态运行库 | |||
| d:Debug,调试版本 | |||
| T:Static runtime,静态运行库选项中常见为 MT | |||
| ``` | |||
| 因此,“多线程调试 DLL”对应 `/MDd`,不是 `/MTd`。`/MTd` 虽然也带 `d`,但它是静态调试运行库。 | |||
| ## 6. 静态库和动态库对比总结 | |||
| @@ -1027,6 +1053,43 @@ Library 部分验收时,应重点掌握以下内容: | |||
| ## 10. 学习结论 | |||
| ### 10.1 考试知识点补充(按章节归类) | |||
| ### 静态库补充 | |||
| 1. 静态库常见后缀为 `.lib`(IAR 中常见静态库后缀为 `.a`)。 | |||
| 2. 调用静态库时,库文件中的代码会在链接阶段被链接到最终可执行文件中。 | |||
| 3. 使用静态库后,如果静态库内容更新,通常需要重新链接或重新编译主程序,主程序才会使用新的库实现。 | |||
| 4. 静态库本身不能独立运行,编译成功后生成的可执行文件才可以运行。 | |||
| 5. 静态库的优点是发布简单,运行时不需要额外 DLL;缺点是最终程序体积可能变大,库更新不如动态库方便。 | |||
| ### 动态库补充 | |||
| 1. 动态库是在程序运行时被加载使用的库,Windows 下常见文件为 `.dll`,配套导入库通常为 `.lib`。 | |||
| 2. 动态库不是只在程序里做标记然后自动找到库,运行时必须能找到对应 DLL。 | |||
| 3. 工程配置方式调用 DLL 时,一般需要头文件 `.h`、导入库 `.lib` 和运行时 DLL。 | |||
| 4. 显式加载 DLL 常用函数包括 `LoadLibrary`、`GetProcAddress`、`FreeLibrary`。 | |||
| 5. `DestroyLibrary`、`SetLibraryAddress` 不是 Windows 显式加载 DLL 的常用函数。 | |||
| ### 调用库配置方式补充 | |||
| 调用库的常见方式包括: | |||
| 1. 将库文件复制到项目输出目录或程序运行目录; | |||
| 2. 配置附加库目录; | |||
| 3. 配置附加依赖项; | |||
| 4. 在代码中使用 `#pragma comment(lib, "库名.lib")` 指定链接库。 | |||
| 不应把“在注册表中注册库路径”作为 VS 工程调用普通静态库或动态库的常规方式。 | |||
| ### 运行库配置补充 | |||
| 1. `/MD`:多线程 DLL,Release 常用,动态运行库。 | |||
| 2. `/MDd`:多线程调试 DLL,Debug 常用,动态调试运行库。 | |||
| 3. `/MT`:多线程,Release 可用,静态运行库。 | |||
| 4. `/MTd`:多线程调试,Debug 可用,静态调试运行库。 | |||
| 5. 主程序和库项目的运行库配置建议保持一致,避免链接冲突或运行异常。 | |||
| 通过本次学习,掌握了 VS2019 平台下静态库和动态库的基本概念、生成方法和调用方法。 | |||
| 静态库适合将稳定代码直接链接进主程序,发布简单,运行时不需要额外 DLL。动态库适合需要运行时加载、模块独立更新或隐藏实现的场景,但发布时需要保证 DLL 能被程序找到。 | |||
| @@ -1051,3 +1114,26 @@ Library 部分验收时,应重点掌握以下内容: | |||
| ``` | |||
| 掌握库的生成与使用后,可以更好地理解公司项目中模块封装、源码隐藏、库文件发布和多人协作的基本方式。 | |||
| ## 11. 错题整理 | |||
| ### 11.1 运行库配置标识 | |||
| 错题: | |||
| ```text | |||
| 运行库配置中,“多线程调试DLL”对应的标识是? | |||
| ``` | |||
| 正确答案:`/MDd`。 | |||
| 错因分析:这道题容易把 `/MDd` 和 `/MTd` 混在一起。两者都带小写 `d`,都表示 Debug 调试版本,但是否使用 DLL 运行库不同。 | |||
| 对比记忆: | |||
| | 标识 | 名称 | 关键点 | | |||
| |---|---|---| | |||
| | `/MDd` | 多线程调试 DLL | Debug + 动态运行库 | | |||
| | `/MTd` | 多线程调试 | Debug + 静态运行库 | | |||
| 库调用时主程序和库项目的运行库配置建议保持一致。例如主程序使用 `/MDd`,静态库也尽量使用 `/MDd`;主程序使用 `/MTd`,静态库也尽量使用 `/MTd`。运行库配置不一致时,可能出现链接冲突、重复运行库符号或运行异常。 | |||
| @@ -1,226 +1,369 @@ | |||
| <span id="mulu"></span> | |||
| # Markdown 学习文档 | |||
| [TOC] | |||
| # 一级标题 | |||
| ## 1. Markdown 简介 | |||
| ## 二级标题 | |||
| Markdown 是一种轻量级标记语言,主要通过简单符号控制文档结构和显示效果。它适合编写学习笔记、项目说明、接口文档、操作手册等内容。 | |||
| Markdown 文档的优点: | |||
| - 语法简单,容易阅读和维护。 | |||
| - 可以同时保留纯文本可读性和排版效果。 | |||
| - 适合配合 Git 进行版本管理。 | |||
| - 常用于 README、学习文档、开发文档和测试记录。 | |||
| ## 2. 标题语法 | |||
| Markdown 使用 `#` 表示标题,`#` 数量越多,标题级别越低。 | |||
| ```markdown | |||
| # 一级标题 | |||
| ## 二级标题 | |||
| ### 三级标题 | |||
| ``` | |||
| - 第一项 | |||
| - 第二项 | |||
| 1. 嵌套 | |||
| 2. 嵌套 | |||
| 显示效果: | |||
| # 一级标题示例 | |||
| - 第四项 | |||
| ## 二级标题示例 | |||
| 1. 第一步 <span id="target"></span> | |||
| 2. 第二步 | |||
| 3. 第三步 | |||
| 4. 第四步 | |||
| 5. 第五步 | |||
| - 嵌套 | |||
| - 嵌套 | |||
| - 嵌套 | |||
| ### 三级标题示例 | |||
| **加粗文字** | |||
| 注意事项: | |||
| *倾斜文字* | |||
| - `#` 后面建议加一个空格。 | |||
| - 一个文档中通常只保留一个一级标题。 | |||
| - 标题层级应按顺序使用,避免结构混乱。 | |||
| ***加粗倾斜文字*** | |||
| ## 3. 列表语法 | |||
| ~~删除线文字~~ | |||
| ### 3.1 无序列表 | |||
| 无序列表通常使用 `-`、`*` 或 `+` 表示,推荐统一使用 `-`。 | |||
| ```markdown | |||
| - SourceTree | |||
| - IAR | |||
| - Visual Studio | |||
| ``` | |||
| 显示效果: | |||
| `printf` | |||
| - SourceTree | |||
| - IAR | |||
| - Visual Studio | |||
| `hello` | |||
| ### 3.2 有序列表 | |||
| 有序列表使用数字加英文句点表示。 | |||
| ```markdown | |||
| 1. 创建工程 | |||
| 2. 添加文件 | |||
| 3. 编译运行 | |||
| ``` | |||
| int main(void) | |||
| { | |||
| printf("Hello World\n"); | |||
| return 0; | |||
| } | |||
| 显示效果: | |||
| 1. 创建工程 | |||
| 2. 添加文件 | |||
| 3. 编译运行 | |||
| ### 3.3 列表嵌套 | |||
| 子列表需要缩进,通常使用两个或四个空格。 | |||
| ```markdown | |||
| - 软件学习 | |||
| - SourceTree | |||
| - IAR | |||
| - Visual Studio | |||
| - 文档学习 | |||
| 1. Markdown 语法 | |||
| 2. 图片引用 | |||
| 3. 页面跳转 | |||
| ``` | |||
| [百度](www.baidu.com) | |||
| 显示效果: | |||
| [必应](www.bing.com) | |||
| - 软件学习 | |||
| - SourceTree | |||
| - IAR | |||
| - Visual Studio | |||
| - 文档学习 | |||
| 1. Markdown 语法 | |||
| 2. 图片引用 | |||
| 3. 页面跳转 | |||
| [](www.baidu.com) | |||
| ## 4. 文字样式 | |||
| [](www.baidu.com) | |||
| ### 4.1 加粗 | |||
| [跳转到一级标题](#一级标题) | |||
| ```markdown | |||
| **加粗文字** | |||
| ``` | |||
| [跳转到二级标题](#二级标题) | |||
| 显示效果:**加粗文字** | |||
| [跳转到指定位置1](#target) | |||
| ### 4.2 倾斜 | |||
| [跳转到指定位置2](#target2) | |||
| ```markdown | |||
| *倾斜文字* | |||
| ``` | |||
| ------ | |||
| 显示效果:*倾斜文字* | |||
| ![kk]() | |||
| ### 4.3 加粗倾斜 | |||
| ------ | |||
| ```markdown | |||
| ***加粗倾斜文字*** | |||
| ``` | |||
| | xixi | 11 | | |||
| | ---- | ---- | | |||
| | haha | 22 | | |||
| 显示效果:***加粗倾斜文字*** | |||
| > 一级引用 | |||
| > | |||
| > > 二级引用 | |||
| > > | |||
| > > > 三级引用 | |||
| ### 4.4 删除线 | |||
| [跳转到目录](#mulu) | |||
| ```markdown | |||
| ~~删除线文字~~ | |||
| ``` | |||
| ------ | |||
| 显示效果:~~删除线文字~~ | |||
| ------ | |||
| ## 5. 代码块 | |||
| ------ | |||
| ### 5.1 单行代码 | |||
| ------ | |||
| 单行代码使用一对反引号包裹。 | |||
| ------ | |||
| ```markdown | |||
| `printf("Hello World");` | |||
| ``` | |||
| 显示效果:`printf("Hello World");` | |||
| ### 5.2 多行代码 | |||
| 多行代码使用三个反引号包裹,并可以指定语言类型。 | |||
| ````markdown | |||
| ```c | |||
| #include <stdio.h> | |||
| int main(void) | |||
| { | |||
| printf("Hello World\n"); | |||
| return 0; | |||
| } | |||
| ``` | |||
| ```` | |||
| 显示效果: | |||
| ```c | |||
| #include <stdio.h> | |||
| int main(void) | |||
| { | |||
| printf("Hello World\n"); | |||
| return 0; | |||
| } | |||
| ``` | |||
| ## 6. 超链接 | |||
| # Markdown 学习笔记 | |||
| ### 6.1 文字超链接 | |||
| ## 目录 | |||
| ```markdown | |||
| [百度](https://www.baidu.com) | |||
| [必应](https://www.bing.com) | |||
| ``` | |||
| - [跳转到标题语法](#title) | |||
| - [跳转到列表语法](#list) | |||
| - [跳转到代码块语法](#code) | |||
| - [跳转到表格语法](#table) | |||
| - [跳转到学习总结](#summary) | |||
| 显示效果: | |||
| ------ | |||
| [百度](https://www.baidu.com) | |||
| <span id="title"></span> | |||
| [必应](https://www.bing.com) | |||
| ## 一、标题语法 | |||
| ### 6.2 图片超链接 | |||
| Markdown 使用 `#` 表示标题,`#` 越多,标题级别越低。 | |||
| 图片外层再包一层链接语法,即可点击图片跳转。 | |||
| ```markdown | |||
| # 一级标题 | |||
| ## 二级标题 | |||
| ### 三级标题 | |||
| [](https://www.baidu.com) | |||
| ``` | |||
| [返回目录](#markdown-学习笔记) | |||
| 显示效果: | |||
| ------ | |||
| [](https://www.baidu.com) | |||
| <span id="list"></span> | |||
| ## 7. 页面内跳转 | |||
| ## 二、列表语法 | |||
| ### 7.1 跳转到标题 | |||
| ### 1. 无序列表 | |||
| Markdown 可以通过标题生成锚点,并在文档内部跳转。 | |||
| ```markdown | |||
| - 第一项 | |||
| - 第二项 | |||
| - 第三项 | |||
| [跳转到表格](#10-表格) | |||
| ``` | |||
| 显示效果:[跳转到表格](#10. 表格) | |||
| ### 7.2 跳转到目录 | |||
| 可以在指定位置增加 HTML 锚点。 | |||
| ```html | |||
| <span id="custom-target"></span> | |||
| ``` | |||
| ### 2. 有序列表 | |||
| 然后使用链接跳转: | |||
| ```markdown | |||
| 1. 第一步 | |||
| 2. 第二步 | |||
| 3. 第三步 | |||
| [跳转到指定位置](#custom-target) | |||
| ``` | |||
| ### 3. 嵌套列表 | |||
| <span id="custom-target"></span> | |||
| 显示效果:[跳转到指定位置](#custom-target) | |||
| ## 8. 图片 | |||
| 图片语法由说明文字和图片路径组成。 | |||
| ```markdown | |||
| - 软件学习 | |||
| 1. Typora | |||
| 2. SourceTree | |||
| 3. IAR | |||
| - 代码学习 | |||
| - C语言 | |||
| - 单元测试 | |||
|  | |||
| ``` | |||
| [返回目录](#markdown-学习笔记) | |||
| 显示效果: | |||
|  | |||
| ------ | |||
| 图片引用注意事项: | |||
| <span id="code"></span> | |||
| - 图片建议统一放在当前文档目录下的 `pictures` 文件夹中。 | |||
| - 推荐使用相对路径,例如 `pictures/图片名称.png`。 | |||
| - 不建议使用本机盘符或用户桌面目录这类绝对路径。 | |||
| - 图片文件名应尽量清晰,便于后续维护。 | |||
| ## 三、代码块语法 | |||
| ## 9. 分割线 | |||
| ### 1. 单行代码块 | |||
| 分割线可以使用三个或更多 `-`、`*`、`_`。 | |||
| ```markdown | |||
| `printf("Hello World");` | |||
| --- | |||
| ``` | |||
| ### 2. 多行代码块 | |||
| 显示效果: | |||
| ```c | |||
| #include <stdio.h> | |||
| *** | |||
| int main(void) | |||
| { | |||
| printf("Hello World\n"); | |||
| return 0; | |||
| } | |||
| ``` | |||
| +++ | |||
| [返回目录](#markdown-学习笔记) | |||
| --- | |||
| ------ | |||
| --- | |||
| <span id="table"></span> | |||
| ## 10. 表格 | |||
| ## 四、表格语法 | |||
| 表格使用 `|` 分隔列,第二行用于控制表头。 | |||
| ```markdown | |||
| | 序号 | 软件 | 作用 | | |||
| | ---- | ---- | ---- | | |||
| | 1 | Typora | 编写 Markdown 文档 | | |||
| | 2 | SourceTree | 代码版本管理 | | |||
| | 3 | IAR | 嵌入式工程开发 | | |||
| | 1 | SourceTree | 代码版本管理 | | |||
| | 2 | IAR | 嵌入式工程开发 | | |||
| | 3 | Visual Studio | C/C++ 工程开发和调试 | | |||
| ``` | |||
| 显示效果: | |||
| | 序号 | 软件 | 作用 | | |||
| | ---- | ---------- | ------------------ | | |||
| | 1 | Typora | 编写 Markdown 文档 | | |||
| | 2 | SourceTree | 代码版本管理 | | |||
| | 3 | IAR | 嵌入式工程开发 | | |||
| | 序号 | 软件 | 作用 | | |||
| | ---- | ---- | ---- | | |||
| | 1 | SourceTree | 代码版本管理 | | |||
| | 2 | IAR | 嵌入式工程开发 | | |||
| | 3 | Visual Studio | C/C++ 工程开发和调试 | | |||
| ## 11. 引用 | |||
| 引用使用 `>` 表示,可以用于说明重点、备注或引用内容。 | |||
| ```markdown | |||
| > 一级引用 | |||
| > | |||
| > > 二级引用 | |||
| ``` | |||
| [返回目录](#markdown-学习笔记) | |||
| 显示效果: | |||
| ------ | |||
| > 一级引用 | |||
| > | |||
| > > 二级引用 | |||
| <span id="summary"></span> | |||
| ## 12. 学习总结 | |||
| ## 五、学习总结 | |||
| ## 12.1 考试知识点补充(按章节归类) | |||
| 通过本次学习,掌握了 Markdown 的标题、列表、代码块、表格以及自定义锚点跳转的基本用法。 | |||
| ### 标题和快捷键补充 | |||
| 自定义锚点跳转的核心写法是: | |||
| Markdown 标题使用 `#` 表示,几个 `#` 就是几级标题。常见编辑器中也可以用快捷键设置标题,例如: | |||
| ```html | |||
| <span id="summary"></span> | |||
| | 标题级别 | 语法 | 常见快捷键 | | |||
| |---|---|---| | |||
| | 一级标题 | `# 标题` | `Ctrl + 1` | | |||
| | 二级标题 | `## 标题` | `Ctrl + 2` | | |||
| | 三级标题 | `### 标题` | `Ctrl + 3` | | |||
| 考试中问“三级标题的快捷键”,应选 `Ctrl + 3`。 | |||
| ### 列表语法补充 | |||
| 无序列表常用符号包括: | |||
| ```markdown | |||
| - 内容 | |||
| + 内容 | |||
| * 内容 | |||
| ``` | |||
| 然后通过下面这种方式跳转: | |||
| `~` 不是无序列表符号。列表嵌套时,子级列表通常需要在上一层列表下方缩进,一般按一次 `Tab` 即可形成下一级列表。 | |||
| 在有序列表或无序列表末尾,如果想退出列表并创建一个不带符号的空行,通常连续按两次 `Enter`。 | |||
| ### 文字样式补充 | |||
| 常见文字样式写法如下: | |||
| | 效果 | 写法 | | |||
| |---|---| | |||
| | 斜体 | `*文本*` 或 `_文本_` | | |||
| | 加粗 | `**文本**` 或 `__文本__` | | |||
| | 删除线 | `~~文本~~` | | |||
| 文字样式符号一般紧贴文字,不需要在符号和文字之间额外加空格。例如斜体写成 `*文本*`,删除线写成 `~~文本~~`。 | |||
| ### 代码补充 | |||
| 如果要把单词或短语显示为行内代码,使用一对反引号: | |||
| ```markdown | |||
| [跳转到学习总结](#summary) | |||
| `code` | |||
| ``` | |||
| [返回目录](#markdown-学习笔记) | |||
| 如果要显示多行代码块,使用三个反引号包裹: | |||
| ````markdown | |||
| ```c | |||
| int main(void) | |||
| { | |||
| return 0; | |||
| } | |||
| ``` | |||
| ```` | |||
| 常见编辑器中,代码块快捷键可能是 `Ctrl + Shift + K`,而 `Ctrl + K` 往往不是完整代码块的快捷键。考试时要结合题目所给选项判断。 | |||
| 通过本次学习,掌握了 Markdown 的常用语法,包括标题、列表、文字样式、代码块、超链接、页面内跳转、图片、分割线、表格和引用。 | |||
| 整理 Markdown 文档时,需要特别注意目录结构和图片路径。文档和图片一起提交时,应优先使用相对路径,这样在其他电脑或仓库环境中打开文档时,图片也能正常显示。 | |||
| @@ -1,5 +1,7 @@ | |||
| # SourceInsight 学习文档 | |||
| [TOC] | |||
| ## 1. 软件介绍 | |||
| SourceInsight 是一款代码阅读和编辑工具,常用于 C/C++ 等工程代码的查看、跳转、搜索和维护。 | |||
| @@ -49,11 +51,11 @@ SourceInsight 中的工程用于管理一组代码文件。创建工程后,可 | |||
| 5. 选择工程文件保存路径; | |||
|  | |||
|  | |||
| 6. 选择需要管理的源码目录; | |||
|  | |||
|  | |||
| 7. 根据提示完成工程创建; | |||
| @@ -61,7 +63,7 @@ SourceInsight 中的工程用于管理一组代码文件。创建工程后,可 | |||
| 9. 选择需要加入工程的源码文件; | |||
|  | |||
|  | |||
| 10. 点击"Close",完成工程新建。 | |||
| @@ -85,11 +87,11 @@ SourceInsight 中的工程用于管理一组代码文件。创建工程后,可 | |||
| 4. 选择 **Open Project **; | |||
|  | |||
|  | |||
| 5. 在窗口中选择工程文件; | |||
|  | |||
|  | |||
| 6. 点击“OK”; | |||
| @@ -113,7 +115,7 @@ SourceInsight 不仅可以查看已有文件,也可以新建和编辑代码文 | |||
| 2. 选择 **New**; | |||
|  | |||
|  | |||
| 3. 在新建文件窗口中输入或编辑代码内容; | |||
| @@ -129,11 +131,11 @@ SourceInsight 不仅可以查看已有文件,也可以新建和编辑代码文 | |||
| 9. 选择 **Add and Remove Project Files**; | |||
|  | |||
|  | |||
| 10. 将新建文件添加到工程中; | |||
|  | |||
|  | |||
| 11. 添加完成后,同步符号表。 | |||
| @@ -197,13 +199,13 @@ SourceInsight 不仅可以查看已有文件,也可以新建和编辑代码文 | |||
| 3. 选择 **Synchronize Files**; | |||
|  | |||
|  | |||
| 4. 在弹出的窗口中确认同步范围; | |||
| 5. 点击"Start",开始同步; | |||
|  | |||
|  | |||
| 6. 等待同步完成; | |||
| @@ -1132,7 +1134,7 @@ Project → Synchronize Files | |||
| HAL_GPIO_WritePin | |||
| ``` | |||
| 3. 将鼠标光标放在该符号上; | |||
| 3. 将鼠标光标放在该符号上; | |||
| 4. 右键点击该符号; | |||
| @@ -1428,4 +1430,40 @@ SourceInsight 主要用于代码查看、编辑和引用分析。 | |||
| 搜索引用:用于查找函数、变量和宏的使用位置。 | |||
| ``` | |||
| ### 10.1 考试知识点补充(按章节归类) | |||
| #### 工程添加与符号同步补充 | |||
| 1. `Add Tree` 用于添加指定文件夹以及其子目录下的源代码文件。 | |||
| 2. `Add All` 表示添加指定范围内的全部匹配文件;`Remove Tree` 表示移除目录树中的文件。 | |||
| 3. 添加文件或工程结构发生变化后,如果出现函数名不识别、跳转失败、函数黑名等问题,可执行 `Project -> Synchronize Files`,并勾选 `Force all files to be re-parsed` 强制重新解析所有文件。 | |||
| 4. `Project -> Rebuild Project` 是工程重建操作,也可用于重新生成工程索引和符号信息。 | |||
| 5. 关闭并重启 Source Insight、重新添加项目文件、删除项目后重新创建,也可能解决符号索引异常,但优先应先同步和强制重解析。 | |||
| 6. 符号表同步的作用是建立代码、函数、宏定义、变量定义之间的关系,方便互相跳转和查找引用。 | |||
| #### 窗口与视图补充 | |||
| 1. `View -> Panels -> Context Window` 用于打开或关闭上下文窗口。 | |||
| 2. `Symbol Window` 通常显示当前文件或当前上下文中的符号,不只是全局符号,也可能包含局部符号。 | |||
| 3. 符号窗口可用于查看函数、变量、宏、参数等符号及其位置;它不是用于查看项目文件夹结构。 | |||
| 4. 关联窗口用于查看函数和参数、定义之间的关联关系,不是用来查看工程文件夹内容。 | |||
| 5. `Overview` 窗口可用于查看整个文件的代码结构。 | |||
| 6. 视图切换用于改变打开文件窗口的排列模式,不止两种方式。常见方式包括 `Cascade`、`Tile Horizontal`、`Tile Vertical`、单窗口、双窗口等。 | |||
| 7. `Tile Horizontal` 用于水平平铺多个打开的文件窗口。 | |||
| 8. Source Insight 可以保存窗口布局,保存的布局适用于打开的文件窗口,也可以通过工具栏按钮快速切换保存的布局,常见布局可保存为 `Layout A-D`。 | |||
| #### 搜索和引用补充 | |||
| 1. `Lookup References` 是搜索引用的常用方式,工具栏图标通常是大写 `R`。 | |||
| 2. Lookup References 可设置是否区分大小写、是否跳过无效代码等搜索选项。 | |||
| 3. Source Insight 中常用搜索引用方式包括 `Lookup References`、`Find in Files`、`Search Files`。 | |||
| 4. `Search Files` 中勾选 `Include Subdirectories` 可以递归搜索子文件夹。 | |||
| 5. 通过文件结构、定义和符号索引,可以进行快速查找和定位到项目中的位置。 | |||
| 6. 如果搜索结果不完整,应检查文件是否已加入工程、符号表是否同步、是否需要强制重新解析,以及是否开启了递归搜索。 | |||
| #### 编码和使用特点补充 | |||
| 1. Source Insight 适合大工程、多层次代码的阅读,支持关键字高亮、函数名、宏定义等符号显示,索引和查找功能较强。 | |||
| 2. Source Insight 默认并不一定无需设置即可完美支持 UTF-8。遇到中文乱码或编码异常时,应检查文件编码和软件编码设置。 | |||
| 在实际嵌入式代码开发中,SourceInsight 可以帮助快速理解工程结构、定位代码位置、分析函数调用关系,提高代码阅读和维护效率。 | |||
| @@ -1,5 +1,7 @@ | |||
| # VS2019 单元测试学习文档 | |||
| [TOC] | |||
| ## 1. 学习目标 | |||
| 本篇文档用于学习在 Visual Studio 2019 平台下进行 C/C++ 单元测试的基本方法。学习重点包括单元测试创建、测试样例书写、测试运行、代码覆盖度、运行性能分析以及单元测试调试。 | |||
| @@ -717,6 +719,20 @@ Assert failed. Expected:<3>. Actual:<4>. | |||
| | 分支覆盖率 | 统计 `if`、`else`、`switch` 等分支是否都被执行过 | | |||
| | 块覆盖率 | 统计基本代码块是否被执行过 | | |||
| 错题补充: | |||
| 路径覆盖率比行覆盖率、函数覆盖率和分支覆盖率要求更高。分支覆盖率主要关注每个判断分支的真假结果是否都执行过,而路径覆盖率关注程序中所有可能执行路径是否都被测试用例走到。 | |||
| 因此,路径覆盖率的计算和测试用例设计通常比分支覆盖率更复杂,不是更简单。尤其当程序中存在多个 `if`、循环或嵌套判断时,可能路径数量会快速增加,实际项目中很难做到完全路径覆盖。 | |||
| 简单理解: | |||
| ```text | |||
| 行覆盖率:代码行有没有执行到 | |||
| 分支覆盖率:判断条件的各个分支有没有执行到 | |||
| 路径覆盖率:不同分支组合形成的执行路径有没有执行到 | |||
| ``` | |||
| 例如下面代码: | |||
| ```cpp | |||
| @@ -880,7 +896,7 @@ UnitTestDemo | |||
| ```text | |||
| 视图 -> 其他窗口 -> Fine Code Coverage | |||
| ``` | |||
|  | |||
|  | |||
| 4. 在测试资源管理器中点击: | |||
| @@ -1439,7 +1455,41 @@ VS2019 单元测试验收时,应重点掌握以下内容: | |||
| | 打开监视窗口 | `调试 -> 窗口 -> 监视` | | |||
| | 打开调用堆栈 | `调试 -> 窗口 -> 调用堆栈` | | |||
| ## 14. 学习结论 | |||
| ## 14.学习结论 | |||
| ### 14.1 考试知识点补充(按章节归类) | |||
| #### 单元测试概念补充 | |||
| 1. 单元测试主要用于验证程序中单个模块、函数或单元的功能是否符合预期,不是用来验证整个系统功能是否符合预期。 | |||
| 2. 单元测试的优点包括:可以自动化运行,帮助确认新代码没有破坏原有功能;可以较早发现问题,避免问题到集成或部署阶段才暴露;测试用例本身也能作为功能行为的补充说明;代码重构时可以帮助确认功能没有被破坏。 | |||
| 3. 单元测试通常不是纯手动执行,也不需要等到代码部署后才运行。 | |||
| #### 单元测试创建与运行补充 | |||
| 1. 在 VS2019 中添加本机单元测试项目的常见路径是:右键解决方案 -> 添加 -> 新建项目 -> 本机单元测试项目。 | |||
| 2. 单元测试项目和被测项目通常放在同一个解决方案中管理,测试项目通过包含头文件、链接被测代码或库文件来调用被测函数。 | |||
| 3. 测试失败时,应结合测试资源管理器中的失败信息、断言提示、断点调试、监视窗口和调用堆栈进行定位。 | |||
| #### Assert 方法补充 | |||
| 常见断言方法包括: | |||
| | 断言方法 | 作用 | | |||
| |---|---| | |||
| | `Assert.AreEqual(expected, actual)` | 判断实际值是否等于期望值 | | |||
| | `Assert.IsTrue(condition)` | 判断条件是否为真 | | |||
| | `Assert.ThrowsException<TException>(delegate)` | 判断代码是否抛出指定异常 | | |||
| `Assert.Print(message)` 不是常用的 MSTest 断言方法,不能和上面三个混为一类。 | |||
| #### 代码覆盖率补充 | |||
| 1. Fine Code Coverage 插件可以用于在 VS2019 Community 中查看单元测试代码覆盖率。 | |||
| 2. 常见覆盖率类型包括语句覆盖率、行覆盖率、分支覆盖率、条件覆盖率、路径覆盖率。 | |||
| 3. 条件覆盖率关注每个布尔条件的 `true` 和 `false` 结果是否都被测试到。 | |||
| 4. 分支覆盖率关注判断结构中各个分支是否被执行。 | |||
| 5. 路径覆盖率关注所有可能执行路径,通常比分支覆盖率更复杂。 | |||
| 通过本次学习,掌握了在 VS2019 平台下进行 C/C++ 单元测试的基本流程。单元测试不是简单地运行程序,而是通过测试框架对指定函数或模块进行自动化验证。 | |||
| @@ -1456,4 +1506,24 @@ VS2019 单元测试验收时,应重点掌握以下内容: | |||
| 单元测试的核心价值是:让代码修改后能够快速验证原有功能是否仍然正确,从而提高代码质量和维护效率。 | |||
| ## 15. 错题整理 | |||
| ### 15.1 路径覆盖率和分支覆盖率 | |||
| 错题: | |||
| ```text | |||
| 路径覆盖率是指测试用例覆盖了所有可能的执行路径,其覆盖率计算通常比分支覆盖率简单。 | |||
| ``` | |||
| 正确答案:错误。 | |||
| 错因分析:题目前半句“路径覆盖率覆盖所有可能执行路径”是对的,但后半句“计算通常比分支覆盖率简单”是错的。路径覆盖率要考虑不同分支组合形成的完整执行路径,复杂度通常高于分支覆盖率。 | |||
| 记忆要点: | |||
| ```text | |||
| 分支覆盖率看单个判断分支。 | |||
| 路径覆盖率看多个判断组合后的执行路线。 | |||
| 路径覆盖率更严格,也更难完全覆盖。 | |||
| ``` | |||
| @@ -1,5 +1,7 @@ | |||
| # Visual Studio 2019 学习文档 | |||
| [TOC] | |||
| ## 1. 学习目标 | |||
| 本文档用于记录 Visual Studio 2019 的基础操作学习内容,主要围绕工程创建、工程配置和工程调试三个方面展开。 | |||
| @@ -68,7 +70,7 @@ VS2019 中常见的层级关系如下: | |||
| 简单理解:解决方案是一个大文件夹,项目是里面的具体工程,文件是工程中真正参与编译和管理的代码文件。 | |||
|  | |||
|  | |||
| ## 4. 工程创建 | |||
| @@ -152,7 +154,7 @@ VS2019 中常见的层级关系如下: | |||
| 8. 创建完成后,在右侧 `解决方案资源管理器` 中可以看到解决方案和项目。 | |||
|  | |||
|  | |||
| #### 4.1.3 创建完成后的工程结构 | |||
| @@ -226,7 +228,7 @@ VS2019 中常见文件后缀如下: | |||
| 7. 在 `解决方案资源管理器` 中确认项目是否正常显示。 | |||
|  | |||
|  | |||
| #### 4.2.3 只打开文件和打开项目的区别 | |||
| @@ -291,7 +293,7 @@ VS2019 中常见文件后缀如下: | |||
| 重新加载项目 | |||
| ``` | |||
|  | |||
|  | |||
| 4. 项目恢复正常显示; | |||
| @@ -308,6 +310,10 @@ VS2019 中常见文件后缀如下: | |||
| 注意:卸载项目不会删除磁盘上的代码文件,也不会删除 `.vcxproj` 项目文件。 | |||
| 错题补充: | |||
| 已卸载的项目仍然保留在解决方案中,可以通过右键项目选择 `重新加载项目` 恢复使用,不需要重新添加到解决方案。只有项目被“移除”出解决方案,或者 `.sln` 中已经没有该项目记录时,才需要通过 `添加 -> 现有项目` 重新加入。 | |||
| ### 4.4 设置启动项 | |||
| #### 4.4.1 启动项的含义 | |||
| @@ -820,6 +826,10 @@ int Add(int a, int b) | |||
| 在配置管理器中可以查看每个项目是否参与当前解决方案生成。 | |||
| 错题补充: | |||
| 解决方案配置主要指 `Debug`、`Release` 以及自己新建的自定义配置;`x86`、`Win32`、`x64` 属于平台配置,不属于解决方案配置。考试中如果问“解决方案配置选项”,应优先判断是不是编译模式,而不是处理器平台。 | |||
| ### 5.3 平台配置 | |||
| 平台配置用于选择程序生成的平台类型,常见有 `Win32` 和 `x64`。 | |||
| @@ -890,6 +900,16 @@ int Add(int a, int b) | |||
| 6. 重新生成项目。 | |||
| 错题补充: | |||
| 创建控制台应用程序或修改项目配置时,需要区分下面几个概念: | |||
| 1. 启用预编译头后,工程会生成并使用 `.pch` 文件。首次编译可能稍慢,但后续编译可以加快常用头文件的处理速度; | |||
| 2. 如果把输出类型从控制台应用程序改成类库,原来的 `main` 函数不会被 VS 自动删除,但它已经不再作为有效入口点使用; | |||
| 3. 平台目标设置为 `x64` 后,程序只能在 64 位 Windows 上运行,不能在 32 位 Windows 上运行; | |||
| 4. 在调试配置中启用本机代码调试,可以用于 C# 调用非托管 C++ DLL 时的混合调试; | |||
| 5. `.NET Core 3.1` 项目不能直接引用 `.NET Framework 4.8` 类库,但可以引用兼容的 `.NET Standard` 类库。 | |||
| ### 5.5 输出路径配置 | |||
| 输出路径用于设置编译生成文件的保存位置。 | |||
| @@ -930,6 +950,10 @@ int Add(int a, int b) | |||
| 配置输出路径可以让生成文件结构更清晰,避免 Debug、Release、Win32、x64 文件混在一起。 | |||
| 错题补充: | |||
| VS2019 中常见的路径配置主要包括输出路径、头文件路径、源文件加入项目、库文件路径等。`调试路径`不是基础工程路径配置中的常规分类,不能和头文件路径、源文件路径、库文件路径、输出路径并列理解。 | |||
| ### 5.6 头文件路径配置 | |||
| 当代码中使用 `#include` 引用其他目录下的头文件时,需要配置头文件搜索路径。 | |||
| @@ -1156,6 +1180,15 @@ printf("log enable\n"); | |||
| 3. 主程序和静态库项目的运行库配置尽量保持一致; | |||
| 4. 如果运行库不一致,可能出现链接冲突或运行异常。 | |||
| 错题补充: | |||
| `/MDd` 对应“多线程调试 DLL”,表示 Debug 版本使用动态调试运行库;`/MTd` 对应“多线程调试”,表示 Debug 版本使用静态调试运行库。两者都带 `d`,都和 Debug 有关,但关键区别是: | |||
| ```text | |||
| /MDd:动态调试运行库,DLL 方式 | |||
| /MTd:静态调试运行库,静态链接方式 | |||
| ``` | |||
| ### 5.12 安全检查 | |||
| 安全检查用于增强程序运行时的安全性,例如检测部分缓冲区溢出问题。 | |||
| @@ -1177,6 +1210,27 @@ printf("log enable\n"); | |||
| 一般情况下建议保持默认启用,不建议随意关闭。只有在明确知道关闭原因,并且项目要求关闭时,才进行修改。 | |||
| ### 5.13 编译器优化等级配置 | |||
| 编译器优化等级用于控制编译器在生成代码时是否进行性能或体积优化。优化等级会影响程序运行效率,也会影响调试体验。 | |||
| 常见选项如下: | |||
| | 选项 | 含义 | 常见场景 | | |||
| |---|---|---| | |||
| | `/Od` | 禁用优化 | Debug 调试常用 | | |||
| | `/O1` | 优先减小代码体积 | 对程序体积敏感的 Release 场景 | | |||
| | `/O2` | 优先提高运行速度 | 常规 Release 发布场景 | | |||
| | `/Ox` | 启用多项优化 | 高优化场景,通常接近 `/O2` 但不等同于“只在 64 位额外优化” | | |||
| 注意事项: | |||
| 1. Debug 模式通常默认使用 `/Od`,方便断点调试和查看变量; | |||
| 2. Release 模式通常会启用 `/O1` 或 `/O2` 等优化; | |||
| 3. `/O2` 会启用较多速度优化,部分变量可能被放入寄存器或被优化掉,调试时可能出现变量值不可查看或显示不稳定; | |||
| 4. `/O1` 主要偏向减小生成文件体积,运行效率通常不如 `/O2`; | |||
| 5. `/Od` 的重点是保留调试友好性,不代表会自动删除无用函数或死代码。 | |||
| ## 6. 工程生成和运行 | |||
| ### 6.1 生成解决方案 | |||
| @@ -1506,6 +1560,10 @@ unsigned char buffer[4] = {0x11, 0x22, 0x33, 0x44}; | |||
| 3. 多线程程序是否出现线程卡死; | |||
| 4. 多线程调试时切换不同线程观察执行状态。 | |||
| 错题补充: | |||
| 线程窗口不是只有多线程程序才会显示内容。即使是单线程程序,调试时通常也会显示当前进程的主线程。因此“单线程程序中线程窗口为空、没有任何内容”这种说法是错误的。 | |||
| ### 7.9 调用堆栈窗口 | |||
| 调用堆栈窗口用于查看函数调用关系。程序运行到断点暂停时,调用堆栈可以显示当前函数是被哪些函数一级一级调用进来的。 | |||
| @@ -2034,6 +2092,41 @@ Shift + F11:跳出当前函数 | |||
| ## 12. 学习结论 | |||
| ### 12.1 考试知识点补充(按章节归类) | |||
| #### 工程创建与文件管理补充 | |||
| 1. 一个解决方案可以包含多个项目,多个项目可以同时加载到解决方案中,并可以根据需要设置不同的启动项。 | |||
| 2. 设置启动项目的常用方法是:右键项目 -> 设为启动项目;也可以右键解决方案 -> 属性 -> 启动项目进行配置。 | |||
| 3. 卸载项目只是将项目从当前解决方案加载状态中临时移除,保留磁盘上的项目文件;已卸载项目可右键选择 `重新加载项目` 恢复。 | |||
| 4. `排除文件`只是让文件不参与当前项目编译,不会从磁盘永久删除;删除文件才可能影响磁盘文件。 | |||
| 5. 项目中的文件不一定必须位于项目目录下,可以通过“包括在项目中”或“添加现有项”引用外部文件。 | |||
| 6. 从头编写代码创建工程时,适合选择 `空项目(Empty Project)`,再手动添加 `.c/.cpp`、`.h` 等文件。 | |||
| #### 工程配置补充 | |||
| 1. 修改解决方案配置、平台配置、输出目录、头文件路径、库文件路径、宏定义、运行库、安全检查等配置后,通常需要重新编译或重新生成项目才能生效。 | |||
| 2. `Debug` 和 `Release` 属于解决方案配置;`x86`、`Win32`、`x64` 属于平台配置。 | |||
| 3. `Debug` 通常包含调试信息、优化较少;`Release` 通常优化较多、调试信息较少。 | |||
| 4. 路径配置常见类型包括:头文件路径、源文件路径或源文件加入项目、库文件路径、输出路径;调试路径不是基础路径配置的常规分类。 | |||
| 5. 头文件路径配置位置是:项目 -> 属性 -> 配置属性 -> C/C++ -> 常规 -> 附加包含目录。 | |||
| 6. 宏定义配置位置是:项目 -> 属性 -> 配置属性 -> C/C++ -> 预处理器 -> 预处理器定义。宏既可以在项目属性中配置,也可以在代码中通过 `#define` 定义。 | |||
| 7. 安全检查配置位置是:项目 -> 属性 -> 配置属性 -> C/C++ -> 代码生成 -> 安全检查。`/GS` 用于启用缓冲区安全检查,可能增加少量代码体积和运行开销。 | |||
| 8. 运行库常见选项包括 `/MD`、`/MDd`、`/MT`、`/MTd`;`/MT` 使用静态运行库,运行时不依赖外部运行库 DLL。 | |||
| 9. 编译器优化等级包括 `/Od`、`/O1`、`/O2`、`/Ox`。Debug 默认通常是 `/Od`,Release 常用 `/O1` 或 `/O2`。优化等级越高,执行速度可能越快,但编译时间可能增加,调试变量也可能被优化掉。 | |||
| 10. 创建控制台应用程序时,启用预编译头会生成 `.pch` 文件;改为类库后原 `main` 不会自动删除,但不再作为程序入口点;x64 程序不能在 32 位 Windows 上运行。 | |||
| #### 调试操作补充 | |||
| 1. 断点可以点击代码行左侧空白处创建,也可以右键断点进行禁用、启用、删除或设置条件。 | |||
| 2. 条件断点由代码断点和条件组合而成,只有变量值或表达式满足条件时才会中断。 | |||
| 3. 常用调试窗口包括:监视窗口、内存窗口、调用堆栈窗口、线程窗口、寄存器窗口。 | |||
| 4. 内存窗口可以查看指定内存地址的内容,不只是查看变量值。 | |||
| 5. 线程窗口可查看线程 ID、线程名称、当前执行位置和线程状态;单线程程序调试时通常也会显示主线程。 | |||
| 6. 线程窗口中可以右键线程并选择“冻结”来暂停该线程执行;切换线程后,调用堆栈窗口会随当前线程更新。 | |||
| 7. 调用堆栈窗口用于查看函数调用层次,程序发生未处理异常时可帮助定位异常发生位置;双击堆栈行通常可跳转到对应源代码位置。 | |||
| 8. 单步调试常用操作:`Step Over / F10` 表示逐过程,不进入函数;`Step Into / F11` 表示逐语句,进入函数;`Step Out / Shift+F11` 表示跳出当前函数;`F5` 是继续运行,不是单步。 | |||
| 通过本次学习,掌握了 Visual Studio 2019 的基本工程创建、文件管理、工程配置和调试方法。VS2019 不只是代码编辑器,更重要的是它通过解决方案和项目来管理编译、链接和调试流程。 | |||
| 在实际使用中,需要重点关注以下几点: | |||
| @@ -2056,4 +2149,96 @@ Shift + F11:跳出当前函数 | |||
| 调试工具如何帮助定位问题。 | |||
| ``` | |||
| 掌握这些基础操作后,后续学习静态库生成与使用、单元测试等内容会更加容易。 | |||
| 掌握这些基础操作后,后续学习静态库生成与使用、单元测试等内容会更加容易。 | |||
| ## 13. 错题整理 | |||
| ### 13.1 线程窗口 | |||
| 错题: | |||
| ```text | |||
| 线程窗口在单线程程序中显示为空,无任何内容。 | |||
| ``` | |||
| 正确答案:错误。 | |||
| 错因分析:单线程程序也至少有一个主线程,调试时线程窗口通常会显示该主线程。线程窗口在多线程调试中更常用,但不是只有多线程程序才有内容。 | |||
| ### 13.2 已卸载项目能否重新加载 | |||
| 错题: | |||
| ```text | |||
| 已卸载的项目无法重新加载,必须重新添加到解决方案。 | |||
| ``` | |||
| 正确答案:错误。 | |||
| 错因分析:卸载项目只是暂时不加载、不参与生成,项目仍在解决方案中。右键已卸载项目,选择 `重新加载项目` 即可恢复。 | |||
| ### 13.3 编译器优化等级 | |||
| 错题: | |||
| ```text | |||
| 在 VS2019 中,关于编译器优化等级配置,下列描述正确的是? | |||
| ``` | |||
| 正确选项要点:`/O2` 会启用速度优化,可能让变量被放入寄存器或被优化掉,影响调试查看;`/O1` 偏向减小代码体积,运行效率通常低于 `/O2`。 | |||
| 错因分析:Debug 模式通常使用 `/Od`,不是默认启用 `/O1`;`/Od` 的重点是方便调试,不是自动清理死代码;`/Ox` 也不能简单理解成“只在 64 位下等同于 `/O2`”。 | |||
| ### 13.4 解决方案配置 | |||
| 错题: | |||
| ```text | |||
| 下列属于 Visual Studio 中解决方案配置的选项有? | |||
| ``` | |||
| 正确答案:`Debug`、`Release`、自定义配置。 | |||
| 错因分析:`x86`、`Win32`、`x64` 属于平台配置,不属于解决方案配置。解决方案配置回答“用 Debug 还是 Release 编译”,平台配置回答“生成 32 位还是 64 位程序”。 | |||
| ### 13.5 路径配置分类 | |||
| 错题: | |||
| ```text | |||
| 路径配置包含哪些类型? | |||
| ``` | |||
| 正确要点:头文件路径、源文件加入项目、库文件路径、输出路径是常见路径相关配置;`调试路径`不是基础工程路径配置中的常规分类。 | |||
| 错因分析:看到“路径”两个字时不能全选,要判断它是否属于工程配置中常见的路径类型。 | |||
| ### 13.6 控制台项目配置 | |||
| 错题: | |||
| ```text | |||
| 在 VS2019 中创建控制台应用程序时,关于项目配置的以下描述,正确的是? | |||
| ``` | |||
| 正确要点: | |||
| 1. 预编译头会生成 `.pch` 文件,后续编译可加快; | |||
| 2. 输出类型改为类库后,`main` 函数不会自动删除,但不再作为有效入口点; | |||
| 3. `x64` 程序不能在 32 位 Windows 上运行; | |||
| 4. 启用本机代码调试可用于 C# 和非托管 C++ DLL 的混合调试; | |||
| 5. `.NET Core 3.1` 可引用兼容的 `.NET Standard` 类库,但不能直接引用 `.NET Framework 4.8` 类库。 | |||
| 错因分析:平台目标、输出类型、预编译头、混合调试和目标框架引用规则属于不同配置点,做多选题时要逐条判断。 | |||
| ### 13.7 运行库配置 | |||
| 错题: | |||
| ```text | |||
| 运行库配置中,“多线程调试DLL”对应的标识是? | |||
| ``` | |||
| 正确答案:`/MDd`。 | |||
| 错因分析:`/MDd` 和 `/MTd` 都是 Debug 调试运行库,但 `/MDd` 是动态 DLL 运行库,`/MTd` 是静态运行库。看到“DLL”就对应 `MD`,看到“调试”就对应末尾的 `d`。 | |||
| @@ -0,0 +1,39 @@ | |||
| # 本周个人复盘 | |||
| ## 1. 本周工作内容 | |||
| 这周主要是在学基础学习里面的几个软件和相关知识点,包括 SourceTree、Markdown、IAR、SourceInsight、Visual Studio 2019,还有库相关的内容,也就是静态库和动态库的生成与调用。通过这一周的学习,我对这些软件的基本使用流程有了一个大概的了解,也整理了对应的学习文档。 | |||
| 目前除了单元测试这一块还没有完全完成,其他几个模块基本都已经学完了,对应的文档也整理了一版。不过现在这些文档还不能说完全没有问题,后面还需要继续对照验收要求,把操作步骤、截图、注意事项这些内容再补充完善一下。单元测试这一块后面也要尽快补上,不能让它一直空着。 | |||
| ## 2. 周一目标回顾 | |||
| 周一给自己定的目标是完成基础学习阶段所有相关技术点的学习,并且把对应的学习文档整理出来,最好能做到文档验收一次通过。 | |||
| 从这周的完成情况来看,大部分内容已经完成了,但是还没有完全达到最开始的目标。主要是单元测试还没完全补齐,另外已经写好的文档也还需要再检查和完善,所以后面还要继续收尾。 | |||
| ## 3. 个人进度汇报 | |||
| 目前基础学习整体已经完成了大部分。SourceTree、Markdown、IAR、SourceInsight、Visual Studio 2019 和库相关内容都已经学完并整理了文档,单元测试相关内容还需要继续学习和补充。 | |||
| 现在的问题是,有些内容虽然文档里已经写了,但实际操作还不够熟练。比如 IAR 的工程配置、VS 里面库的调用、SourceTree 的分支和冲突处理,这些内容看着文档能做,但如果完全不看文档,还是容易卡住。所以接下来不能只停留在“文档写完了”,还要多练几遍操作。 | |||
| ## 4. 本周遇到的困难 | |||
| 这周暂时没有遇到解决不了的问题。主要困难还是软件比较多,知识点也比较杂,整理文档花了比较多时间。有时候为了把截图、步骤和说明写清楚,会占用比较长的时间,导致理论复习和实操练习的时间相对少了一些。 | |||
| 后面需要调整一下时间分配,不能把大部分时间都花在文档格式和截图整理上,还要留出足够时间去理解知识点和反复练操作。 | |||
| ## 5. 下周计划 | |||
| 下周主要有三件事。第一件是把单元测试这一块补上,包括单元测试的创建、测试样例编写、代码覆盖率、运行性能和调试这些内容,同时把对应文档整理完整。 | |||
| 第二件是加强基础软件的实操练习,尽量在不看学习文档的情况下,把 SourceTree、IAR、SourceInsight、Visual Studio 2019 以及库的生成和调用这些操作练熟,尤其是容易出错的配置和调试部分。 | |||
| 第三件是开始学习 PLC 相关知识点,先了解 PLC 的基本概念、应用场景和后续学习要求,为下一阶段任务提前做准备。 | |||
| ## 6. 个人优缺点评价 | |||
| 这周做得比较好的地方是,整体学习进度还算能跟上,除了单元测试以外,大部分基础学习内容都已经学完并整理了文档。遇到一些操作步骤比较复杂的地方,也能通过截图和文字记录下来,方便后面复习。 | |||
| 不足的地方也比较明显,就是写文档花的时间太长了,导致理论学习和实操练习时间有点少。有些内容现在还是“看着文档会做”,但还没有达到完全熟练的程度。下周需要把重点从“把文档写完”转到“真正把操作练熟”,同时也要补一下理论知识,避免考试或者验收的时候只记得步骤,但说不清楚原理和作用。 | |||
| @@ -0,0 +1,168 @@ | |||
| # 上位机软件练习题 | |||
| 题型:单选、多选、判断 | |||
| 题量:120 题 | |||
| 范围:Visual Studio 2019、库、单元测试。 | |||
| ### 单选题 | |||
| 1. VS 中管理一个或多个项目的是:A. 解决方案 B. 断点 C. DLL D. Watch | |||
| 2. C/C++ 项目文件常见后缀是:A. `.vcxproj` B. `.eww` C. `.md` D. `.png` | |||
| 3. 设置运行哪个项目应配置:A. 启动项 B. 标签 C. 贮藏 D. 符号表 | |||
| 4. 头文件路径通常配置在:A. C/C++ 附加包含目录 B. 链接器输入 C. 测试窗口 D. Git 日志 | |||
| 5. 库目录通常配置在:A. 链接器常规附加库目录 B. C/C++ 输出 C. Markdown D. SourceTree | |||
| 6. 具体库文件名通常配置在:A. 链接器输入附加依赖项 B. C/C++ 常规 C. Watch D. 表格 | |||
| 7. Debug/Release 属于:A. 解决方案配置 B. 图片格式 C. Git 区域 D. 单元测试断言 | |||
| 8. Win32/x64 属于:A. 平台配置 B. 标题等级 C. 分支类型 D. 表格格式 | |||
| 9. 静态库常见后缀是:A. `.lib` B. `.dll` C. `.md` D. `.sln` | |||
| 10. 动态库常见后缀是:A. `.dll` B. `.h` C. `.png` D. `.gitignore` | |||
| 11. 头文件主要用于:A. 函数声明 B. 运行时加载 C. 保存提交 D. 显示覆盖率 | |||
| 12. `__declspec(dllexport)` 用于:A. 导出 DLL 函数 B. 创建分支 C. 写引用 D. 查看寄存器 | |||
| 13. DEF 文件中常用导出关键字是:A. EXPORTS B. WATCH C. COMMIT D. TABLE | |||
| 14. 显式加载 DLL 常用:A. LoadLibrary B. git add C. Assert D. [TOC] | |||
| 15. 获取 DLL 函数地址常用:A. GetProcAddress B. git log C. Make D. fetch | |||
| 16. 释放 DLL 常用:A. FreeLibrary B. git push C. Rebuild D. branch | |||
| 17. 单元测试 AAA 指:A. Arrange/Act/Assert B. Add/Apply/Abort C. API/App/ASM D. Area/Array/Address | |||
| 18. 单元测试判断结果常用:A. 断言 B. 分支 C. 标签 D. 链接器 | |||
| 19. 查看测试结果常用:A. 测试资源管理器 B. SourceTree C. IAR Memory D. Markdown 表格 | |||
| 20. 代码覆盖度表示:A. 测试执行代码比例 B. DLL 大小 C. 提交数量 D. 图片数量 | |||
| 21. 找不到头文件应检查:A. 附加包含目录 B. 运行时 DLL C. SourceInsight 书签 D. Git 标签 | |||
| 22. 无法解析外部符号常见原因:A. 未链接实现或库 B. 图片缺失 C. 标题错误 D. 符号表未同步 | |||
| 23. 运行时找不到 DLL 应检查:A. DLL 是否在可搜索路径 B. Markdown 是否加粗 C. Git 是否提交 D. IAR 分组 | |||
| 24. 条件断点用于:A. 条件满足才暂停 B. 自动生成 DLL C. 删除项目 D. 创建测试 | |||
| 25. 调用堆栈窗口用于:A. 查看调用链 B. 配置库路径 C. 写表格 D. 新建分支 | |||
| ### 多选题 | |||
| 26. VS 工程创建相关包括:A. 创建项目 B. 打开项目 C. 加载/卸载项目 D. 设置启动项 | |||
| 27. VS 文件相关操作包括:A. 创建文件 B. 打开文件 C. 包含文件 D. 排除文件 | |||
| 28. VS 工程配置包括:A. 解决方案配置 B. 平台配置 C. 项目类型配置 D. 路径配置 | |||
| 29. VS 路径配置包括:A. 输出路径 B. 头文件路径 C. 源文件路径 D. 库文件路径 | |||
| 30. VS 调试断点操作包括:A. 创建 B. 删除 C. 禁用 D. 启用 | |||
| 31. VS 调试窗口包括:A. 监视窗口 B. 内存窗口 C. 线程窗口 D. 调用堆栈窗口 | |||
| 32. VS 单步调试包括:A. 全速运行 B. 重新运行 C. 逐过程 D. 逐语句 | |||
| 33. 静态库相关包括:A. 基本概念 B. 生成 C. 工程配置调用 D. 代码语句加载 lib | |||
| 34. 动态库生成方式包括:A. 导出语句 B. DEF 文件 C. 模块定义文件 D. Markdown 标题 | |||
| 35. 动态库调用方式包括:A. 工程配置调用 B. 代码加载 lib C. 代码加载 dll D. SourceTree 贮藏 | |||
| 36. 调用库常见需要:A. 头文件 B. 库目录 C. 库文件名 D. 平台一致 | |||
| 37. DLL 运行失败可能原因:A. DLL 找不到 B. 平台不一致 C. 导出名不对 D. 缺少依赖 DLL | |||
| 38. 单元测试内容包括:A. 测试创建 B. 测试样例书写 C. 代码覆盖度 D. 测试调试 | |||
| 39. 测试样例常见关注:A. 正常值 B. 边界值 C. 异常情况 D. 随机无意义输入 | |||
| 40. AAA 测试结构包括:A. 准备数据 B. 执行动作 C. 断言结果 D. 删除项目 | |||
| 41. 单元测试调试可用:A. 设置断点 B. 调试所选测试 C. 单步进入被测函数 D. 监视变量 | |||
| 42. 覆盖率结果可帮助:A. 发现未覆盖代码 B. 补充测试用例 C. 观察测试范围 D. 保证完全无 bug | |||
| 43. VS 常见问题包括:A. 找不到头文件 B. 找不到库文件 C. 无法解析外部符号 D. Debug/Release 差异 | |||
| 44. 静态库和动态库对比维度包括:A. 链接阶段 B. 运行依赖 C. 发布方式 D. 代码复用 | |||
| 45. 显式加载 DLL 时应检查:A. LoadLibrary 返回值 B. GetProcAddress 返回值 C. 函数指针是否有效 D. FreeLibrary 释放 | |||
| ### 判断题 | |||
| 46. 一个 VS 解决方案可以包含多个项目。 | |||
| 47. 排除文件等同于从磁盘永久删除文件。 | |||
| 48. 宏定义通常属于预处理相关配置。 | |||
| 49. 静态库通常在链接阶段合入程序。 | |||
| 50. 动态库通常在运行时加载。 | |||
| 51. 使用 DLL 时一定不需要头文件。 | |||
| 52. `.lib` 既可能是静态库,也可能是动态库的导入库。 | |||
| 53. 平台不一致可能导致库链接失败。 | |||
| 54. Debug 和 Release 配置可能不同。 | |||
| 55. 单元测试可以帮助验证函数行为。 | |||
| 56. 覆盖率越高,测试质量一定越高。 | |||
| 57. 测试失败时可以调试所选测试。 | |||
| 58. 监视窗口可以查看变量值。 | |||
| 59. 调用堆栈可查看函数调用链。 | |||
| 60. 找不到 DLL 通常属于运行时问题。 | |||
| ## 第二轮拓展题 | |||
| ### 单选题 | |||
| 61. VS 中 `.sln` 文件表示:A. 解决方案文件 B. 动态库文件 C. Markdown 文件 D. 补丁文件 | |||
| 62. VS 中 `.cpp` 文件通常用于:A. C++ 源代码实现 B. 库目录 C. 图片 D. 标签 | |||
| 63. VS 中 `.h` 文件通常用于:A. 声明 B. 运行 DLL C. 保存测试结果 D. 保存截图 | |||
| 64. 添加项目到解决方案是为了:A. 同一解决方案管理多个项目 B. 删除源码 C. 创建 Git 标签 D. 生成 Markdown | |||
| 65. 卸载项目后通常:A. 暂不加载该项目 B. 从磁盘删除项目 C. 自动删除源码 D. 自动生成 DLL | |||
| 66. 包含文件到项目表示:A. 让项目管理该文件 B. 从磁盘删除 C. 创建分支 D. 生成补丁 | |||
| 67. 配置管理器常用于:A. 管理配置和平台 B. 写 Markdown C. 查看 IAR 寄存器 D. 搜索引用 | |||
| 68. C/C++ 宏定义常配置在:A. 预处理器 B. 链接器输入 C. 测试资源管理器 D. SourceTree | |||
| 69. 链接器输入附加依赖项填写:A. 库文件名 B. 头文件目录 C. 图片目录 D. 断点名称 | |||
| 70. 链接器常规附加库目录填写:A. 库所在目录 B. 函数名 C. Markdown 标题 D. Git 标签 | |||
| 71. 静态库项目输出通常是:A. `.lib` B. `.dll` C. `.md` D. `.eww` | |||
| 72. 动态库项目主要输出通常是:A. `.dll` B. `.md` C. `.png` D. `.patch` | |||
| 73. 动态库的导入库 `.lib` 主要用于:A. 链接阶段 B. Markdown 显示 C. Git 推送 D. IAR 下载 | |||
| 74. DLL 文件主要用于:A. 运行阶段加载 B. 写提交说明 C. 生成目录 D. 显示表格 | |||
| 75. 找不到 `.lib` 多发生在:A. 链接阶段 B. Markdown 渲染 C. Git fetch D. SourceInsight 搜索 | |||
| 76. 找不到 `.dll` 多发生在:A. 运行阶段 B. 编写文档阶段 C. 创建标签阶段 D. 添加图片阶段 | |||
| 77. 单元测试项目通常用于:A. 验证被测代码行为 B. 生成图片 C. 创建远程仓库 D. 配置芯片 | |||
| 78. 测试资源管理器用于:A. 查看和运行测试 B. 查看 Git 分支 C. 查看 IAR 内存 D. 写表格 | |||
| 79. `Assert::AreEqual` 常用于:A. 判断实际值与预期值相等 B. 加载 DLL C. 创建项目 D. 合并分支 | |||
| 80. 测试覆盖率低说明:A. 有代码未被测试执行 B. 一定没有 bug C. DLL 找不到 D. Git 未提交 | |||
| 81. 调试测试时可选择:A. 调试所选测试 B. 删除所有测试 C. 创建分支 D. 生成 Markdown | |||
| 82. VS 条件断点适合:A. 特定条件下暂停 B. 自动导出 DLL C. 删除项目 D. 提交代码 | |||
| 83. 线程窗口用于:A. 查看线程信息 B. 查看 Markdown C. 查看 Git 标签 D. 查看库文件名 | |||
| 84. 内存窗口用于:A. 查看内存数据 B. 查看远程地址 C. 查看目录 D. 查看表格 | |||
| 85. Debug 正常 Release 异常可能与:A. 优化或配置差异 B. 图片路径 C. 标题层级 D. SourceTree 标签 | |||
| ### 多选题 | |||
| 86. VS 解决方案可包含:A. 应用程序项目 B. 静态库项目 C. 动态库项目 D. 单元测试项目 | |||
| 87. VS 工程配置应关注:A. 当前配置 B. 当前平台 C. 配置页位置 D. 配置作用 | |||
| 88. 调用静态库可能需要:A. 头文件 B. `.lib` C. 库目录 D. 附加依赖项 | |||
| 89. 调用动态库可能需要:A. 头文件 B. 导入库 `.lib` C. DLL 文件 D. 运行路径 | |||
| 90. DLL 导出方式包括:A. `__declspec(dllexport)` B. DEF 文件 C. 模块定义文件 D. Markdown 表格 | |||
| 91. 显式加载 DLL 相关 API 包括:A. LoadLibrary B. GetProcAddress C. FreeLibrary D. 函数指针调用 | |||
| 92. VS 调试常用窗口包括:A. 监视 B. 内存 C. 线程 D. 调用堆栈 | |||
| 93. VS 断点操作包括:A. 创建 B. 删除 C. 禁用 D. 条件断点 | |||
| 94. 单元测试常见断言可用于判断:A. 相等 B. 不相等 C. 是否为真 D. 是否为空 | |||
| 95. 单元测试用例可覆盖:A. 正常值 B. 边界值 C. 异常输入 D. 错误路径 | |||
| 96. 覆盖率查看可帮助:A. 发现未测试代码 B. 补充测试 C. 分析测试范围 D. 完全证明无 bug | |||
| 97. VS 常见路径问题包括:A. 头文件路径错 B. 库目录错 C. DLL 运行路径错 D. 输出路径混乱 | |||
| 98. 无法解析外部符号可能原因:A. 未添加库 B. 函数实现缺失 C. 平台不一致 D. 声明和实现不匹配 | |||
| 99. VS 文件管理包括:A. 新建 B. 打开 C. 包含 D. 排除 | |||
| 100. 学习 VS 应掌握:A. 解决方案和项目关系 B. 配置路径 C. 调试方式 D. 常见错误排查 | |||
| 101. 静态库特点包括:A. 链接进程序 B. 发布依赖少 C. 可复用代码 D. 可能增大 exe | |||
| 102. 动态库特点包括:A. 运行时加载 B. 可共享 C. 需要 DLL 可被找到 D. 可减少重复部署 | |||
| 103. 单元测试流程包括:A. 创建测试项目 B. 编写测试用例 C. 运行测试 D. 查看失败原因 | |||
| 104. 单元测试调试时可使用:A. 断点 B. 单步 C. 监视 D. 调用堆栈 | |||
| 105. VS 常见配置组合包括:A. Debug Win32 B. Debug x64 C. Release Win32 D. Release x64 | |||
| ### 判断题 | |||
| 106. `.sln` 是 VS 解决方案文件。 | |||
| 107. 一个解决方案中只能有一个项目。 | |||
| 108. 头文件路径配置错误可能导致找不到头文件。 | |||
| 109. 库目录错误可能导致找不到库文件。 | |||
| 110. 附加依赖项通常填写库文件名。 | |||
| 111. `.dll` 文件通常在运行阶段需要被找到。 | |||
| 112. `.lib` 一定只表示静态库,不可能是导入库。 | |||
| 113. 静态库和动态库都可用于代码复用。 | |||
| 114. 平台不一致可能导致链接或运行问题。 | |||
| 115. Debug 与 Release 配置可能不同。 | |||
| 116. 单元测试只要能运行就不需要断言。 | |||
| 117. AAA 结构有助于组织测试代码。 | |||
| 118. 覆盖率高不代表一定没有 bug。 | |||
| 119. 调试单元测试可以帮助定位失败原因。 | |||
| 120. VS 库调用只需要记住截图,不需要理解 `.h`、`.lib`、`.dll` 的作用。 | |||
| ## 答案 | |||
| 1.A 2.A 3.A 4.A 5.A 6.A 7.A 8.A 9.A 10.A | |||
| 11.A 12.A 13.A 14.A 15.A 16.A 17.A 18.A 19.A 20.A | |||
| 21.A 22.A 23.A 24.A 25.A | |||
| 26.ABCD 27.ABCD 28.ABCD 29.ABCD 30.ABCD 31.ABCD 32.ABCD | |||
| 33.ABCD 34.ABC 35.ABC 36.ABCD 37.ABCD 38.ABCD 39.ABC 40.ABC | |||
| 41.ABCD 42.ABC 43.ABCD 44.ABCD 45.ABCD | |||
| 46.对 47.错 48.对 49.对 50.对 51.错 52.对 53.对 54.对 55.对 | |||
| 56.错 57.对 58.对 59.对 60.对 | |||
| ### 上位机软件第二轮答案 | |||
| 61.A 62.A 63.A 64.A 65.A 66.A 67.A 68.A 69.A 70.A | |||
| 71.A 72.A 73.A 74.A 75.A 76.A 77.A 78.A 79.A 80.A | |||
| 81.A 82.A 83.A 84.A 85.A | |||
| 86.ABCD 87.ABCD 88.ABCD 89.ABCD 90.ABC 91.ABCD 92.ABCD 93.ABCD | |||
| 94.ABCD 95.ABCD 96.ABC 97.ABCD 98.ABCD 99.ABCD 100.ABCD | |||
| 101.ABCD 102.ABCD 103.ABCD 104.ABCD 105.ABCD | |||
| 106.对 107.错 108.对 109.对 110.对 111.对 112.错 113.对 114.对 115.对 | |||
| 116.错 117.对 118.对 119.对 120.错 | |||
| @@ -0,0 +1,167 @@ | |||
| # 上位机软件练习题2 | |||
| 题型:单选、多选、判断 | |||
| 题量:120 题 | |||
| 难度:极高 | |||
| 范围:Visual Studio 2019、库、单元测试 | |||
| ## 单选题 | |||
| 1. VS 中头文件能找到但链接时报无法解析外部符号,最可能说明:A. 声明找到了但实现未链接到 B. 头文件路径一定错误 C. Markdown 图片缺失 D. SourceTree 未提交 | |||
| 2. 同一个库 Debug 可用 Release 不可用,最可能检查:A. 不同配置下的路径、库名和运行库设置 B. Markdown 标题 C. Git 标签 D. SourceInsight 书签 | |||
| 3. x64 项目链接 Win32 库,可能导致:A. 平台不一致的链接问题 B. 图片路径错误 C. Markdown 表格错 D. Git fetch 失败 | |||
| 4. 动态库隐式链接时,编译链接阶段通常需要:A. 头文件和导入库 `.lib` B. 只需要 `.dll` C. 只需要 `.md` D. 只需要 `.png` | |||
| 5. 动态库运行时找不到 DLL,最常见解决方式是:A. 将 DLL 放到 exe 同级目录或 PATH 可搜索目录 B. 删除头文件 C. 删除 `.lib` D. 改 Markdown | |||
| 6. `.lib` 文件既可能是静态库,也可能是:A. 动态库的导入库 B. Markdown 文件 C. 图片文件 D. Git 补丁 | |||
| 7. 使用 `LoadLibrary` 显式加载 DLL 后,获取函数地址应使用:A. `GetProcAddress` B. `git apply` C. `Assert::AreEqual` D. `[TOC]` | |||
| 8. `GetProcAddress` 返回空指针时,最合理做法是:A. 判断失败并避免调用空函数指针 B. 直接调用 C. 删除 DLL D. 创建 Git 标签 | |||
| 9. 使用 C++ 导出 DLL 函数时,为减少函数名修饰影响,常配合:A. `extern "C"` B. `git add` C. `# 标题` D. `Watch` | |||
| 10. DEF 文件中用于列出导出函数的关键字通常是:A. EXPORTS B. IMPORTS C. COMMIT D. ASSERT | |||
| 11. 单元测试中 Arrange 阶段主要做:A. 准备测试数据和环境 B. 执行被测函数 C. 判断结果 D. 删除项目 | |||
| 12. 单元测试中 Act 阶段主要做:A. 调用被测行为 B. 准备头文件 C. 配置库目录 D. 创建标签 | |||
| 13. 单元测试中 Assert 阶段主要做:A. 校验实际结果和预期结果 B. 加载图片 C. 生成 DLL D. 拉取代码 | |||
| 14. 覆盖率高但测试仍可能不足,原因是:A. 覆盖率只说明执行过,不代表断言充分 B. 覆盖率越高一定无 bug C. 覆盖率只看图片 D. 覆盖率只看 Git | |||
| 15. 单元测试项目找不到被测头文件,优先检查:A. 测试项目附加包含目录 B. DLL 运行路径 C. Git 标签 D. Markdown 引用 | |||
| 16. 单元测试链接不到被测函数,优先检查:A. 被测实现或库是否链接进测试项目 B. 测试名称 C. 图片格式 D. 行号显示 | |||
| 17. VS 中“排除在项目外”更准确含义是:A. 不参与当前项目管理/编译,不一定删除磁盘文件 B. 永久删除磁盘文件 C. 删除远程仓库 D. 删除 DLL | |||
| 18. 安全检查、运行库等配置差异常导致:A. 不同配置下行为或链接差异 B. Markdown 无法预览 C. SourceTree 无法合并 D. IAR 无法打开 | |||
| 19. 调用堆栈窗口在调试中用于:A. 查看当前调用链 B. 配置库路径 C. 生成测试 D. 创建解决方案 | |||
| 20. 条件断点最适合:A. 特定变量值或特定条件时暂停 B. 生成静态库 C. 添加文件 D. 写目录 | |||
| ## 多选题 | |||
| 21. VS 调用库时常见配置包括:A. 附加包含目录 B. 附加库目录 C. 附加依赖项 D. 平台配置一致 | |||
| 22. 动态库隐式链接运行时可能需要:A. `.h` B. `.lib` C. `.dll` D. DLL 可被系统找到 | |||
| 23. 动态库显式加载需要关注:A. LoadLibrary 返回值 B. GetProcAddress 返回值 C. 函数指针类型匹配 D. FreeLibrary 释放 | |||
| 24. 无法解析外部符号可能原因包括:A. 未链接库 B. 函数实现缺失 C. 声明和实现不一致 D. 平台不一致 | |||
| 25. 运行时找不到 DLL 可能原因包括:A. DLL 不在 exe 同级目录 B. PATH 找不到 C. 缺少依赖 DLL D. 编译器不识别 Markdown | |||
| 26. 静态库和动态库对比应关注:A. 链接阶段 B. 运行依赖 C. 发布方式 D. 代码复用方式 | |||
| 27. 单元测试用例设计应考虑:A. 正常值 B. 边界值 C. 异常输入 D. 错误路径 | |||
| 28. 一个好的单元测试通常应具备:A. 目标明确 B. 断言清晰 C. 可重复运行 D. 依赖随机外部状态越多越好 | |||
| 29. 单元测试调试可使用:A. 断点 B. 单步进入 C. 监视窗口 D. 调用堆栈 | |||
| 30. 覆盖率结果可用于:A. 发现未执行代码 B. 补充用例 C. 评估测试范围 D. 证明程序完全正确 | |||
| 31. VS 工程配置易混点包括:A. Debug/Release B. Win32/x64 C. C/C++ 附加包含目录 D. 链接器附加库目录 | |||
| 32. 文件“包含/排除/移除/删除”的区别需要理解,因为它们可能影响:A. 是否参与编译 B. 是否仍在磁盘 C. 项目文件记录 D. Git 跟踪状态 | |||
| 33. DLL 导出函数时应关注:A. 导出方式 B. 函数名修饰 C. 调用约定 D. 头文件声明一致 | |||
| 34. 测试资源管理器可用于:A. 查看测试列表 B. 运行测试 C. 查看失败信息 D. 调试测试 | |||
| 35. VS 常见错误排查思路包括:A. 先判断编译错误、链接错误还是运行错误 B. 检查路径配置 C. 检查平台配置 D. 检查库文件和 DLL | |||
| ## 判断题 | |||
| 36. 头文件能找到,只能说明声明可见,不代表实现已经链接成功。 | |||
| 37. `.lib` 文件一定都是静态库。 | |||
| 38. 动态库运行时需要确保 DLL 能被找到。 | |||
| 39. x64 项目通常不能直接链接 Win32 库。 | |||
| 40. `LoadLibrary` 成功后无需检查 `GetProcAddress` 返回值。 | |||
| 41. DEF 文件可以用于管理 DLL 导出函数。 | |||
| 42. 覆盖率高说明代码被执行多,但不一定说明测试断言充分。 | |||
| 43. 单元测试只要写了测试函数,不写断言也能充分验证逻辑。 | |||
| 44. Debug 和 Release 的配置可能不同。 | |||
| 45. VS 中不同平台配置下库目录可能需要分别配置。 | |||
| 46. 调试所选测试可以帮助定位单元测试失败原因。 | |||
| 47. 排除文件一定会从磁盘删除文件。 | |||
| 48. 无法解析外部符号通常属于链接阶段问题。 | |||
| 49. 找不到 DLL 通常属于运行阶段问题。 | |||
| 50. VS 库调用只要把文件放在同一个文件夹,不需要任何配置。 | |||
| ## 答案 | |||
| 1.A 2.A 3.A 4.A 5.A 6.A 7.A 8.A 9.A 10.A | |||
| 11.A 12.A 13.A 14.A 15.A 16.A 17.A 18.A 19.A 20.A | |||
| 21.ABCD 22.ABCD 23.ABCD 24.ABCD 25.ABC 26.ABCD 27.ABCD 28.ABC | |||
| 29.ABCD 30.ABC 31.ABCD 32.ABCD 33.ABCD 34.ABCD 35.ABCD | |||
| 36.对 37.错 38.对 39.对 40.错 41.对 42.对 43.错 44.对 45.对 | |||
| 46.对 47.错 48.对 49.对 50.错 | |||
| ## 高难拓展题 | |||
| ### 单选题 | |||
| 51. 场景51:查看覆盖率时,头文件可见但无法解析外部符号,最合理的判断是:A. 说明声明可见但实现或库未正确链接 B. 说明头文件路径一定错 C. 说明 Markdown 图片错 D. 说明 Git 未提交 | |||
| 52. 场景52:配置库目录时,Debug 正常 Release 异常,最合理的判断是:A. 只修改图片 B. 检查不同配置下优化、运行库、路径和库文件设置 C. 只改文件名 D. 只删除解决方案 | |||
| 53. 场景53:排查运行库时,x64 项目链接 Win32 库,最合理的判断是:A. 只影响 Markdown B. 只影响 SourceTree C. 可能出现平台不一致链接问题 D. 一定能正常链接 | |||
| 54. 场景54:查看调用堆栈时,隐式调用 DLL,最合理的判断是:A. 只需要 README B. 只需要图片 C. 只需要 Git 标签 D. 链接阶段通常需要头文件和导入库,运行阶段需要 DLL | |||
| 55. 场景55:实操验收时,运行时找不到 DLL,最合理的判断是:A. 检查 exe 同级目录或 PATH 可搜索路径 B. 检查 Markdown 表格 C. 检查 SourceInsight 书签 D. 检查 Git 标签 | |||
| 56. 场景56:创建解决方案后,GetProcAddress 失败,最合理的判断是:A. 重新创建分支 B. 应检查导出名、调用约定和返回值 C. 直接调用空指针 D. 删除头文件 | |||
| 57. 场景57:配置 Release 时,DEF 文件导出函数,最合理的判断是:A. 只能用于 Git B. 只能查看内存 C. 可集中管理 DLL 导出符号 D. 只能生成 Markdown | |||
| 58. 场景58:链接静态库时,单元测试没有断言,最合理的判断是:A. 覆盖率一定最高 B. 一定无法编译 C. 一定找不到 DLL D. 难以真正验证结果正确性 | |||
| 59. 场景59:运行 exe 时,覆盖率高但仍有 bug,最合理的判断是:A. 覆盖率不等于断言充分或场景完整 B. 覆盖率高必然无 bug C. 覆盖率只看 DLL D. 覆盖率只看 Git | |||
| 60. 场景60:编写单元测试时,测试项目找不到被测头文件,最合理的判断是:A. 检查 Markdown 引用 B. 检查测试项目附加包含目录 C. 检查 DLL 运行路径 D. 检查 Git 标签 | |||
| 61. 场景61:查看覆盖率时,测试项目无法链接被测函数,最合理的判断是:A. 检查标题层级 B. 检查 SourceInsight 全屏 C. 检查被测实现或库是否链接进测试项目 D. 检查图片路径 | |||
| 62. 场景62:配置库目录时,排除在项目外,最合理的判断是:A. 一定永久删除 B. 一定删除 Git 历史 C. 一定删除 DLL D. 不参与当前项目管理或编译,不一定删除磁盘文件 | |||
| 63. 场景63:排查运行库时,附加依赖项,最合理的判断是:A. 通常填写要链接的库文件名 B. 填写头文件目录 C. 填写图片路径 D. 填写提交说明 | |||
| 64. 场景64:查看调用堆栈时,附加库目录,最合理的判断是:A. 填写测试名称 B. 通常填写库文件所在目录 C. 填写函数声明 D. 填写 Markdown 标题 | |||
| 65. 场景65:实操验收时,附加包含目录,最合理的判断是:A. 填写 Git 分支 B. 填写断点条件 C. 通常填写头文件搜索目录 D. 填写 DLL 运行路径 | |||
| 66. 场景66:创建解决方案后,LoadLibrary 成功后,最合理的判断是:A. 无需检查任何结果 B. 自动执行单元测试 C. 自动提交代码 D. 仍需检查 GetProcAddress 获取函数地址是否成功 | |||
| 67. 场景67:配置 Release 时,调用堆栈窗口,最合理的判断是:A. 用于查看当前函数调用链 B. 用于配置库目录 C. 用于生成 DLL D. 用于 Markdown 目录 | |||
| 68. 场景68:链接静态库时,条件断点,最合理的判断是:A. 用于删除项目 B. 适合满足特定条件才暂停 C. 用于创建静态库 D. 用于添加头文件 | |||
| 69. 场景69:运行 exe 时,平台配置不一致,最合理的判断是:A. 只影响文档标题 B. 不会影响库调用 C. 可能导致链接或运行问题 D. 只影响图片显示 | |||
| 70. 场景70:编写单元测试时,运行库配置不一致,最合理的判断是:A. 一定没有影响 B. 只影响 Git C. 只影响 SourceInsight D. 可能引发链接或运行行为差异 | |||
| 71. 场景71:查看覆盖率时,头文件可见但无法解析外部符号,最合理的判断是:A. 说明声明可见但实现或库未正确链接 B. 说明头文件路径一定错 C. 说明 Markdown 图片错 D. 说明 Git 未提交 | |||
| 72. 场景72:配置库目录时,Debug 正常 Release 异常,最合理的判断是:A. 只修改图片 B. 检查不同配置下优化、运行库、路径和库文件设置 C. 只改文件名 D. 只删除解决方案 | |||
| 73. 场景73:排查运行库时,x64 项目链接 Win32 库,最合理的判断是:A. 只影响 Markdown B. 只影响 SourceTree C. 可能出现平台不一致链接问题 D. 一定能正常链接 | |||
| 74. 场景74:查看调用堆栈时,隐式调用 DLL,最合理的判断是:A. 只需要 README B. 只需要图片 C. 只需要 Git 标签 D. 链接阶段通常需要头文件和导入库,运行阶段需要 DLL | |||
| 75. 场景75:实操验收时,运行时找不到 DLL,最合理的判断是:A. 检查 exe 同级目录或 PATH 可搜索路径 B. 检查 Markdown 表格 C. 检查 SourceInsight 书签 D. 检查 Git 标签 | |||
| 76. 场景76:创建解决方案后,GetProcAddress 失败,最合理的判断是:A. 重新创建分支 B. 应检查导出名、调用约定和返回值 C. 直接调用空指针 D. 删除头文件 | |||
| 77. 场景77:配置 Release 时,DEF 文件导出函数,最合理的判断是:A. 只能用于 Git B. 只能查看内存 C. 可集中管理 DLL 导出符号 D. 只能生成 Markdown | |||
| 78. 场景78:链接静态库时,单元测试没有断言,最合理的判断是:A. 覆盖率一定最高 B. 一定无法编译 C. 一定找不到 DLL D. 难以真正验证结果正确性 | |||
| 79. 场景79:运行 exe 时,覆盖率高但仍有 bug,最合理的判断是:A. 覆盖率不等于断言充分或场景完整 B. 覆盖率高必然无 bug C. 覆盖率只看 DLL D. 覆盖率只看 Git | |||
| 80. 场景80:编写单元测试时,测试项目找不到被测头文件,最合理的判断是:A. 检查 Markdown 引用 B. 检查测试项目附加包含目录 C. 检查 DLL 运行路径 D. 检查 Git 标签 | |||
| ### 多选题 | |||
| 81. 场景81:配置依赖项时,调用库需要检查,正确的有:A. 头文件路径 B. 库目录 C. 库文件名 D. 以上说法都不需要关注 | |||
| 82. 场景82:调试断点时,DLL 运行失败可能原因,正确的有:A. DLL 缺失 B. 依赖 DLL 缺失 C. 与该场景无关的图片格式 D. 导出名不匹配 | |||
| 83. 场景83:排除文件时,显式加载 DLL 需要,正确的有:A. LoadLibrary B. 只重启软件即可 C. 函数指针类型匹配 D. FreeLibrary | |||
| 84. 场景84:复习错题时,单元测试设计应覆盖,正确的有:A. 完全不需要检查当前配置 B. 边界值 C. 异常输入 D. 错误路径 | |||
| 85. 场景85:配置 Debug 时,测试失败排查,正确的有:A. 失败信息 B. 断言位置 C. 调用堆栈 D. 被测代码逻辑 | |||
| 86. 场景86:切换 x64 时,VS 常见错误阶段,正确的有:A. 编译阶段 B. 链接阶段 C. 运行阶段 D. 以上说法都不需要关注 | |||
| 87. 场景87:调用动态库时,Debug/Release 差异可能来自,正确的有:A. 优化等级 B. 运行库 C. 与该场景无关的图片格式 D. 宏定义 | |||
| 88. 场景88:显式加载 DLL 时,Win32/x64 差异可能影响,正确的有:A. 库兼容 B. 只重启软件即可 C. 依赖 DLL D. 平台工具链 | |||
| 89. 场景89:测试失败时,动态库导出需关注,正确的有:A. 完全不需要检查当前配置 B. 函数名修饰 C. 调用约定 D. 头文件声明 | |||
| 90. 场景90:配置头文件时,覆盖率结果用途,正确的有:A. 发现未执行代码 B. 补充测试 C. 评估测试范围 D. 证明完全无 bug | |||
| 91. 场景91:配置依赖项时,调用库需要检查,正确的有:A. 头文件路径 B. 库目录 C. 库文件名 D. 以上说法都不需要关注 | |||
| 92. 场景92:调试断点时,DLL 运行失败可能原因,正确的有:A. DLL 缺失 B. 依赖 DLL 缺失 C. 与该场景无关的图片格式 D. 导出名不匹配 | |||
| 93. 场景93:排除文件时,显式加载 DLL 需要,正确的有:A. LoadLibrary B. 只重启软件即可 C. 函数指针类型匹配 D. FreeLibrary | |||
| 94. 场景94:复习错题时,单元测试设计应覆盖,正确的有:A. 完全不需要检查当前配置 B. 边界值 C. 异常输入 D. 错误路径 | |||
| 95. 场景95:配置 Debug 时,测试失败排查,正确的有:A. 失败信息 B. 断言位置 C. 调用堆栈 D. 被测代码逻辑 | |||
| 96. 场景96:切换 x64 时,VS 常见错误阶段,正确的有:A. 编译阶段 B. 链接阶段 C. 运行阶段 D. 以上说法都不需要关注 | |||
| 97. 场景97:调用动态库时,Debug/Release 差异可能来自,正确的有:A. 优化等级 B. 运行库 C. 与该场景无关的图片格式 D. 宏定义 | |||
| 98. 场景98:显式加载 DLL 时,Win32/x64 差异可能影响,正确的有:A. 库兼容 B. 只重启软件即可 C. 依赖 DLL D. 平台工具链 | |||
| 99. 场景99:测试失败时,动态库导出需关注,正确的有:A. 完全不需要检查当前配置 B. 函数名修饰 C. 调用约定 D. 头文件声明 | |||
| 100. 场景100:配置头文件时,覆盖率结果用途,正确的有:A. 发现未执行代码 B. 补充测试 C. 评估测试范围 D. 证明完全无 bug | |||
| 101. 场景101:配置依赖项时,调用库需要检查,正确的有:A. 头文件路径 B. 库目录 C. 库文件名 D. 以上说法都不需要关注 | |||
| 102. 场景102:调试断点时,DLL 运行失败可能原因,正确的有:A. DLL 缺失 B. 依赖 DLL 缺失 C. 与该场景无关的图片格式 D. 导出名不匹配 | |||
| 103. 场景103:排除文件时,显式加载 DLL 需要,正确的有:A. LoadLibrary B. 只重启软件即可 C. 函数指针类型匹配 D. FreeLibrary | |||
| 104. 场景104:复习错题时,单元测试设计应覆盖,正确的有:A. 完全不需要检查当前配置 B. 边界值 C. 异常输入 D. 错误路径 | |||
| 105. 场景105:配置 Debug 时,测试失败排查,正确的有:A. 失败信息 B. 断言位置 C. 调用堆栈 D. 被测代码逻辑 | |||
| ### 判断题 | |||
| 106. 场景106:运行 exe 时,头文件能找到不代表实现已经链接成功。 | |||
| 107. 场景107:编写单元测试时,VS 中只要头文件可见就不会有链接问题。 | |||
| 108. 场景108:查看覆盖率时,.lib 既可能是静态库,也可能是导入库。 | |||
| 109. 场景109:配置库目录时,单元测试不需要断言也能充分验证逻辑。 | |||
| 110. 场景110:排查运行库时,动态库运行时需要 DLL 可被找到。 | |||
| 111. 场景111:查看调用堆栈时,单元测试不需要断言也能充分验证逻辑。 | |||
| 112. 场景112:实操验收时,平台不一致可能导致库链接失败。 | |||
| 113. 场景113:创建解决方案后,DLL 找不到通常属于 Markdown 语法问题。 | |||
| 114. 场景114:配置 Release 时,覆盖率高不代表一定无 bug。 | |||
| 115. 场景115:链接静态库时,DLL 找不到通常属于 Markdown 语法问题。 | |||
| 116. 场景116:运行 exe 时,调试所选测试可帮助定位失败。 | |||
| 117. 场景117:编写单元测试时,覆盖率可以完全证明程序没有 bug。 | |||
| 118. 场景118:查看覆盖率时,排除文件不一定删除磁盘文件。 | |||
| 119. 场景119:配置库目录时,覆盖率可以完全证明程序没有 bug。 | |||
| 120. 场景120:排查运行库时,无法解析外部符号通常属于链接阶段问题。 | |||
| ## 高难拓展题答案 | |||
| 51.A 52.B 53.C 54.D 55.A 56.B 57.C 58.D 59.A 60.B | |||
| 61.C 62.D 63.A 64.B 65.C 66.D 67.A 68.B 69.C 70.D | |||
| 71.A 72.B 73.C 74.D 75.A 76.B 77.C 78.D 79.A 80.B | |||
| 81.ABC 82.ABD 83.ACD 84.BCD 85.ABCD 86.ABC 87.ABD 88.ACD | |||
| 89.BCD 90.ABCD 91.ABC 92.ABD 93.ACD 94.BCD 95.ABCD 96.ABC | |||
| 97.ABD 98.ACD 99.BCD 100.ABCD 101.ABC 102.ABD 103.ACD 104.BCD | |||
| 105.ABCD | |||
| 106.对 107.错 108.对 109.错 110.对 111.错 112.对 113.错 114.对 115.错 | |||
| 116.对 117.错 118.对 119.错 120.对 | |||
| @@ -0,0 +1,257 @@ | |||
| # 三门考试复习计划 | |||
| ## 考试信息 | |||
| 考试时间:2026 年 7 月 10 日下午 | |||
| 考试科目: | |||
| | 科目 | 题量 | 主要复习范围 | | |||
| | ---- | ---- | ---- | | |||
| | 通用软件考试 | 110 题 | Git、SourceTree、Markdown、SourceInsight | | |||
| | 嵌入式软件考试 | 60 题 | IAR 工程操作、工程配置、工程调试、静态库 | | |||
| | 上位机软件考试 | 60 题 | Visual Studio 2019、静态库/动态库、单元测试 | | |||
| 说明:本计划按 `1_基础学习` 文件夹中的 txt 范围拆分。若老师现场有额外说明,以老师说明为准。 | |||
| ## 总体策略 | |||
| 1. 先复习范围最广、题量最大的通用软件考试。 | |||
| 2. 再复习操作细节多、容易混淆的 IAR。 | |||
| 3. 最后复习 VS、库、单元测试,把配置路径、断点调试、库调用方式和测试流程记牢。 | |||
| 4. 每轮复习都按“概念 -> 操作步骤 -> 易错点 -> 自测题”的顺序走。 | |||
| 5. 不建议今晚死磕一门到底,要让三门都至少过一遍。 | |||
| ## 今晚复习安排 | |||
| ### 18:30 - 18:45 准备阶段 | |||
| - 打开 `1_基础学习` 中 7 个范围 txt。 | |||
| - 打开自己整理的 7 份 Markdown 学习文档。 | |||
| - 准备纸笔,专门记录易混点。 | |||
| - 明确三门考试的对应范围。 | |||
| ### 18:45 - 20:15 通用软件第一轮 | |||
| 复习范围: | |||
| - `SourceTree/SourceTree.md` | |||
| - `Markdown/Markdown.md` | |||
| - `SourceInsight/SourceInsight.md` | |||
| 重点: | |||
| - Git 的工作区、暂存区、本地仓库。 | |||
| - 仓库、节点、分支的概念。 | |||
| - SourceTree 的创建、打开、克隆、获取、拉取、推送、提交、重置、回滚。 | |||
| - 分支的新建、切换、合并、删除、制造冲突、解决冲突。 | |||
| - `.gitignore`、停止跟踪、贮藏、丢弃、移除、标签、补丁、变基。 | |||
| - Markdown 标题、列表、文字样式、代码块、超链接、图片、表格、引用、目录和页内跳转。 | |||
| - SourceInsight 的工程/文件操作、符号表同步、视图切换、常用窗口、搜索引用。 | |||
| 复习方法: | |||
| 1. 先看每份文档目录。 | |||
| 2. 每个小节只问自己两个问题:这个概念是什么?操作入口在哪里? | |||
| 3. SourceTree 重点对比概念:获取 vs 拉取、重置 vs 回滚、丢弃 vs 移除、合并 vs 变基。 | |||
| 4. Markdown 重点手写语法。 | |||
| 5. SourceInsight 重点记菜单入口和窗口作用。 | |||
| ### 20:15 - 20:30 休息 | |||
| - 离开屏幕。 | |||
| - 不刷手机长内容。 | |||
| - 回来后先口头复述刚才的 Git 三个区域。 | |||
| ### 20:30 - 21:45 嵌入式软件第一轮 | |||
| 复习范围: | |||
| - `IAR/IAR.md` | |||
| 重点: | |||
| - 工作区、工程、分组、文件之间的关系。 | |||
| - IAR 各类型文件含义。 | |||
| - 新建/打开工作区,新建/打开工程,导入/添加工程。 | |||
| - 设备配置、编译配置、优化等级、硬件浮点、预处理、链接文件。 | |||
| - 头文件路径、库文件路径、输出路径、输出文件。 | |||
| - 调试器配置。 | |||
| - 静态库封装和调用。 | |||
| - 断点、条件断点、Watch、寄存器、内存、栈、汇编、调用堆栈、单步调试。 | |||
| 复习方法: | |||
| 1. 按“工程操作 -> 工程配置 -> 工程调试”三段复习。 | |||
| 2. 每个配置项都记住:在哪里配置、配置什么、配置错会出现什么现象。 | |||
| 3. 静态库部分重点记:生成库需要哪些文件,调用库需要哪些配置。 | |||
| 4. 调试部分重点记:断点、Watch、寄存器、内存、调用堆栈分别看什么。 | |||
| ### 21:45 - 22:00 休息 | |||
| - 只休息,不继续看资料。 | |||
| - 回来后快速写出 IAR 工程配置相关关键词。 | |||
| ### 22:00 - 23:15 上位机软件第一轮 | |||
| 复习范围: | |||
| - `VisualStudio/VisualStudio.md` | |||
| - `Library/Library.md` | |||
| - `UnitTest/UnitTestVisualStudio.md` | |||
| 重点: | |||
| - VS 解决方案、项目、文件之间的关系。 | |||
| - 创建/打开项目,加载/卸载项目,设置启动项,添加项目,包含/排除文件。 | |||
| - 解决方案配置、平台配置、项目类型、输出路径、头文件路径、源文件路径、库文件路径。 | |||
| - 宏定义、运行库配置、调用库配置、安全检查。 | |||
| - VS 断点、条件断点、监视、内存、线程、调用堆栈、单步调试。 | |||
| - 静态库和动态库的概念、生成、调用方式。 | |||
| - 动态库导出语句、DEF 文件、隐式链接、显式加载。 | |||
| - 单元测试创建、测试样例、断言、代码覆盖度、运行性能、调试测试。 | |||
| 复习方法: | |||
| 1. VS 配置一定要用“菜单路径 + 配置项 + 作用”三件套记忆。 | |||
| 2. 库相关重点对比 `.h`、`.lib`、`.dll` 的作用。 | |||
| 3. 单元测试重点记 AAA 结构:Arrange、Act、Assert。 | |||
| 4. 调试类题目重点记窗口用途。 | |||
| ### 23:15 - 23:45 做练习题第一遍 | |||
| 使用 `练习题.md`: | |||
| - 通用软件先做选择题和判断题。 | |||
| - IAR 做概念题和操作题。 | |||
| - 上位机做库、VS 配置、单元测试题。 | |||
| - 做错的题在题号前标记 `*`。 | |||
| ### 23:45 - 00:10 错题回看 | |||
| - 只看错题相关文档,不重新通读全部内容。 | |||
| - 每个错题用一句话写出正确原因。 | |||
| - 睡前最后复述三件事: | |||
| 1. Git 三个区域。 | |||
| 2. IAR 静态库调用步骤。 | |||
| 3. VS 调用库需要配置哪些内容。 | |||
| ### 00:10 前后休息 | |||
| 不建议继续熬太晚。明天上午还要做第二轮巩固,睡眠不足会明显影响选择题判断速度。 | |||
| ## 明天上午复习安排 | |||
| ### 08:00 - 08:20 快速唤醒 | |||
| - 不看新内容。 | |||
| - 快速翻目录。 | |||
| - 回忆三门考试范围。 | |||
| - 把昨晚错题再看一遍。 | |||
| ### 08:20 - 09:20 通用软件第二轮 | |||
| 重点压缩到高频考点: | |||
| - Git 三个区域。 | |||
| - SourceTree:提交、重置、回滚、分支、合并、冲突、拉取、推送、贮藏、补丁、标签。 | |||
| - Markdown:标题、列表、加粗/斜体/删除线、代码块、链接、图片、表格、引用、页内跳转。 | |||
| - SourceInsight:新建工程、添加文件、同步符号表、搜索引用、常用窗口。 | |||
| 目标: | |||
| - 做题时看到“获取/拉取”“重置/回滚”“丢弃/移除”能立刻区分。 | |||
| ### 09:20 - 10:20 嵌入式软件第二轮 | |||
| 重点压缩到高频考点: | |||
| - IAR 工作区和工程关系。 | |||
| - 工程配置入口。 | |||
| - 设备、优化等级、硬件浮点、预处理、链接文件、路径配置、输出文件、调试器。 | |||
| - 静态库封装与调用。 | |||
| - 调试窗口和单步调试按钮。 | |||
| 目标: | |||
| - 看到配置类题目能知道大概在哪个配置页。 | |||
| - 看到调试类题目能知道应该打开哪个窗口。 | |||
| ### 10:20 - 10:35 休息 | |||
| - 不看屏幕。 | |||
| - 简单活动一下。 | |||
| ### 10:35 - 11:35 上位机软件第二轮 | |||
| 重点压缩到高频考点: | |||
| - VS 解决方案、项目、文件。 | |||
| - 配置管理器、平台配置、项目类型、输出路径、包含目录、库目录、附加依赖项。 | |||
| - Debug/Release、Win32/x64。 | |||
| - 静态库和动态库区别。 | |||
| - `.h`、`.lib`、`.dll` 的作用。 | |||
| - DLL 隐式链接和显式加载。 | |||
| - 单元测试创建、测试资源管理器、断言、覆盖率、运行时间、调试测试。 | |||
| 目标: | |||
| - 看到“无法解析外部符号”“找不到头文件”“找不到 DLL”能判断原因。 | |||
| ### 11:35 - 12:05 练习题第二遍 | |||
| - 只做昨晚错题和不确定题。 | |||
| - 对照答案快速纠正。 | |||
| - 不再扩展新资料。 | |||
| ### 12:05 - 12:25 考前速记 | |||
| 把下面内容写在纸上或脑中过一遍: | |||
| 1. Git:工作区 -> 暂存区 -> 本地仓库 -> 远程仓库。 | |||
| 2. SourceTree:获取只下载远程信息,拉取等于获取加合并。 | |||
| 3. Markdown:图片 ``,链接 `[文字](地址)`。 | |||
| 4. SourceInsight:添加文件后若无法跳转,先同步符号表。 | |||
| 5. IAR:头文件路径、库文件路径、链接文件、输出路径是配置题高频点。 | |||
| 6. VS:头文件路径在 C/C++ 附加包含目录,库目录在链接器常规,库文件名在链接器输入。 | |||
| 7. 静态库编译时合入 exe,动态库运行时加载 dll。 | |||
| 8. 单元测试:Arrange、Act、Assert。 | |||
| ### 12:25 后 | |||
| - 吃饭,休息。 | |||
| - 不再重看大段文档。 | |||
| - 考前 15 分钟只看错题标记和速记内容。 | |||
| ## 每门考试答题策略 | |||
| ### 通用软件考试 | |||
| - 题量最大,先做确定题。 | |||
| - 概念题要抓关键词:工作区、暂存区、本地仓库、远程仓库、分支、节点。 | |||
| - SourceTree 操作题优先判断操作目的:保存修改、撤销修改、合并代码、同步远程、制作补丁。 | |||
| - Markdown 题按语法符号判断。 | |||
| ### 嵌入式软件考试 | |||
| - IAR 题目多是“配置项在哪里、作用是什么、调试看什么”。 | |||
| - 遇到工程配置题,先判断属于编译器、链接器、调试器还是路径配置。 | |||
| - 遇到调试题,先判断是变量、寄存器、内存、栈、汇编还是调用关系。 | |||
| ### 上位机软件考试 | |||
| - VS 配置题优先判断是 C/C++ 还是链接器。 | |||
| - 库相关题先判断静态库还是动态库。 | |||
| - 单元测试题重点看测试创建、断言、覆盖率、性能和调试。 | |||
| ## 考前优先级 | |||
| 如果时间不够,按下面顺序保底: | |||
| 1. SourceTree 的核心概念和常用操作。 | |||
| 2. VS 的路径配置和库调用配置。 | |||
| 3. IAR 的工程配置和调试窗口。 | |||
| 4. 静态库/动态库区别。 | |||
| 5. 单元测试基本流程。 | |||
| 6. Markdown 常用语法。 | |||
| 7. SourceInsight 常规操作。 | |||
| @@ -0,0 +1,168 @@ | |||
| # 嵌入式软件练习题 | |||
| 题型:单选、多选、判断 | |||
| 题量:120 题 | |||
| 范围:IAR。 | |||
| ### 单选题 | |||
| 1. IAR 中管理多个工程的环境是:A. 工作区 B. Watch C. Memory D. Markdown | |||
| 2. IAR 工程文件常见后缀是:A. `.ewp` B. `.md` C. `.dll` D. `.png` | |||
| 3. IAR 工作区文件常见后缀是:A. `.eww` B. `.sln` C. `.lib` D. `.diff` | |||
| 4. IAR 分组主要用于:A. 组织工程文件 B. 配置远程仓库 C. 生成 Markdown D. 创建 DLL | |||
| 5. 设置活动工程用于:A. 指定当前编译调试目标 B. 创建标签 C. 写表格 D. 运行测试 | |||
| 6. 设备配置用于:A. 选择目标芯片 B. 写提交说明 C. 生成目录 D. 搜索引用 | |||
| 7. 优化等级属于:A. 编译配置 B. 工作区文件 C. 断言 D. Git 标签 | |||
| 8. 硬件浮点配置应匹配:A. 芯片能力 B. Markdown 语法 C. Git 分支 D. 图片格式 | |||
| 9. 宏定义通常在:A. 预处理配置 B. Watch 窗口 C. Memory 窗口 D. SourceTree 标签 | |||
| 10. 头文件找不到应检查:A. 头文件路径 B. 调用堆栈 C. 标签 D. 书签 | |||
| 11. 链接文件主要描述:A. 存储布局 B. 图片路径 C. 远程仓库 D. 测试名称 | |||
| 12. 输出路径决定:A. 生成文件保存位置 B. 分支名称 C. 标题层级 D. 覆盖率 | |||
| 13. 生成 hex/bin 应关注:A. 输出文件配置 B. Git 拉取 C. Markdown 引用 D. SourceInsight 视图 | |||
| 14. 调试器配置影响:A. 下载和调试连接 B. 表格格式 C. 提交历史 D. 图片大小 | |||
| 15. Watch 窗口用于:A. 查看变量 B. 查看提交 C. 查看图片 D. 查看表格 | |||
| 16. Registers 窗口用于:A. 查看寄存器 B. 创建补丁 C. 生成 DLL D. 写标题 | |||
| 17. Memory 窗口用于:A. 查看内存 B. 查看标签 C. 查看分支 D. 查看链接 | |||
| 18. Call Stack 用于:A. 查看调用关系 B. 配置头文件 C. 创建工作区 D. 推送代码 | |||
| 19. 逐语句通常会:A. 进入函数内部 B. 跳过所有函数 C. 删除断点 D. 创建库 | |||
| 20. 逐过程通常会:A. 不进入函数内部执行完调用 B. 删除工程 C. 清空内存 D. 添加文件 | |||
| 21. 条件断点用于:A. 条件满足才中断 B. 永不生效 C. 自动生成库 D. 自动提交 | |||
| 22. 静态库封装输出通常是:A. 库文件 B. Markdown C. 图片 D. Git 标签 | |||
| 23. 调用静态库通常需要:A. 头文件和库文件 B. 只要图片 C. 只要 README D. 只要符号表 | |||
| 24. Rebuild All 表示:A. 全部重新编译 B. 只运行 C. 只打开 D. 只提交 | |||
| 25. Make 通常表示:A. 按需编译 B. 删除仓库 C. 创建标签 D. 写表格 | |||
| ### 多选题 | |||
| 26. IAR 工程操作包括:A. 新建工作区 B. 打开工程 C. 添加工程 D. 新建分组 | |||
| 27. IAR 各类型文件可能包括:A. 工作区文件 B. 工程文件 C. 源文件 D. 头文件 | |||
| 28. IAR 工程配置包括:A. 设备配置 B. 编译配置 C. 调试器配置 D. 库相关配置 | |||
| 29. 编译配置可能包括:A. 优化等级 B. 硬件浮点 C. 预处理 D. 链接文件 | |||
| 30. 路径配置可能包括:A. 头文件路径 B. 库文件路径 C. 输出路径 D. 图片网络路径 | |||
| 31. 输出文件可能包括:A. hex B. bin C. map D. Markdown 表格 | |||
| 32. IAR 调试断点操作包括:A. 设置 B. 禁用 C. 启用 D. 删除 | |||
| 33. IAR 调试信息窗口包括:A. Watch B. Registers C. Memory D. Call Stack | |||
| 34. 单步调试操作包括:A. 逐过程 B. 逐语句 C. 复位 D. 跳出 | |||
| 35. 静态库封装通常要注意:A. 设备兼容 B. 编译选项 C. 头文件 D. 库文件输出 | |||
| 36. 静态库调用通常要配置:A. 头文件路径 B. 库文件路径 C. 添加库文件 D. 包含头文件 | |||
| 37. 链接失败可能原因:A. 库文件未添加 B. 库路径错误 C. 平台不兼容 D. 函数未实现 | |||
| 38. 下载失败可能原因:A. 调试器配置错误 B. 硬件连接问题 C. 目标设备不匹配 D. Markdown 语法错误 | |||
| 39. 断点不生效可能原因:A. 优化影响 B. 未下载正确程序 C. 代码未执行到 D. 断点被禁用 | |||
| 40. 查看程序运行状态可用:A. 变量监控 B. 寄存器 C. 内存 D. 调用堆栈 | |||
| 41. IAR 工程目录和文件目录关系可能是:A. 工程引用磁盘文件 B. 分组不一定等于文件夹 C. 文件可来自不同目录 D. 分组一定创建真实目录 | |||
| 42. 预处理配置可能影响:A. 宏定义 B. 条件编译 C. 头文件查找 D. Git 提交 | |||
| 43. 链接文件配置可能影响:A. Flash 分配 B. RAM 分配 C. 中断向量位置 D. Markdown 目录 | |||
| 44. 输出路径配置可能影响:A. obj 位置 B. exe/hex 位置 C. map 位置 D. Git 远程地址 | |||
| 45. 调试时常见操作包括:A. 下载并调试 B. 设置断点 C. 单步执行 D. 查看变量 | |||
| ### 判断题 | |||
| 46. IAR 工作区可以包含多个工程。 | |||
| 47. IAR 分组一定等同真实磁盘文件夹。 | |||
| 48. 设备配置错误可能导致编译或调试异常。 | |||
| 49. 头文件路径错误可能导致找不到头文件。 | |||
| 50. 链接文件与存储布局有关。 | |||
| 51. 输出路径会影响生成文件保存位置。 | |||
| 52. Watch 窗口可查看变量。 | |||
| 53. Registers 窗口可查看寄存器。 | |||
| 54. Memory 窗口可查看指定地址数据。 | |||
| 55. Call Stack 可查看函数调用关系。 | |||
| 56. 禁用断点等同于删除断点。 | |||
| 57. 条件断点适合循环中特定条件才暂停。 | |||
| 58. 静态库调用只需要 `.a/.lib` 文件,不需要头文件。 | |||
| 59. Rebuild All 通常比 Make 更彻底。 | |||
| 60. 硬件浮点配置应考虑芯片支持情况。 | |||
| ## 第二轮拓展题 | |||
| ### 单选题 | |||
| 61. IAR 中打开已有工作区通常打开:A. `.eww` 文件 B. `.md` 文件 C. `.dll` 文件 D. `.patch` 文件 | |||
| 62. IAR 中新建工程后通常需要先配置:A. 目标设备 B. Git 远程 C. Markdown 表格 D. 单元测试 | |||
| 63. IAR 中添加源文件到工程是为了:A. 参与工程编译管理 B. 生成图片 C. 创建标签 D. 推送远程 | |||
| 64. IAR 中工程分组的主要意义是:A. 让工程结构更清晰 B. 自动创建库 C. 自动下载 D. 自动测试 | |||
| 65. IAR 找不到库文件通常检查:A. 库路径和库文件是否添加 B. Markdown 目录 C. Git 分支 D. SourceInsight 书签 | |||
| 66. IAR 中 `.icf` 文件常与:A. 链接配置 B. 图片显示 C. Git 提交 D. 单元测试相关 | |||
| 67. IAR 中 map 文件通常用于:A. 查看链接和内存分布 B. 记录 Markdown 目录 C. 保存远程地址 D. 保存图片 | |||
| 68. IAR 中下载调试前应确认:A. 调试器和硬件连接 B. Git 标签 C. 表格样式 D. 文档标题 | |||
| 69. Watch 窗口看不到变量可能与:A. 优化等级或作用域有关 B. 图片路径有关 C. Git 远程有关 D. Markdown 引用有关 | |||
| 70. 查看函数当前调用路径应使用:A. Call Stack B. `.gitignore` C. DEF 文件 D. 目录 | |||
| 71. 查看汇编指令应使用:A. Disassembly/汇编窗口 B. SourceTree C. Markdown D. VS 测试 | |||
| 72. 单步跳出通常表示:A. 执行完当前函数并返回调用处 B. 进入函数 C. 删除断点 D. 创建工作区 | |||
| 73. IAR 静态库封装时应关注:A. 输出类型为库 B. 输出类型为 Markdown C. 输出类型为图片 D. 输出类型为 Git | |||
| 74. 调用静态库时头文件的作用是:A. 提供声明 B. 保存机器码 C. 保存截图 D. 保存提交 | |||
| 75. 调用静态库时库文件的作用是:A. 提供实现供链接 B. 写标题 C. 显示图片 D. 生成目录 | |||
| 76. IAR 编译报错通常发生在:A. 语法或编译配置阶段 B. 运行时 DLL 阶段 C. Git 推送阶段 D. Markdown 渲染阶段 | |||
| 77. IAR 链接报错通常发生在:A. 符号解析或内存分配阶段 B. 写文档阶段 C. 创建分支阶段 D. 搜索引用阶段 | |||
| 78. 条件编译主要受:A. 宏定义影响 B. 图片影响 C. 提交说明影响 D. 标签影响 | |||
| 79. 输出 hex 文件通常用于:A. 烧录或发布固件 B. 写 Markdown C. 提交 Git D. 创建补丁 | |||
| 80. IAR 工程配置修改后通常需要:A. 重新编译验证 B. 删除全部文件 C. 创建 DLL D. 新建表格 | |||
| 81. Debug 调试时设置断点的位置应是:A. 可能执行到的代码行 B. 图片文件 C. `.gitignore` D. 远程地址 | |||
| 82. 禁用断点后:A. 可再次启用 B. 断点永久删除 C. 工程删除 D. 变量清空 | |||
| 83. 删除断点后:A. 需要重新设置才会生效 B. 可自动恢复 C. 仍然中断 D. 生成库 | |||
| 84. IAR 中 Reset 调试操作通常表示:A. 复位目标程序 B. 重置 Git 分支 C. 删除文档 D. 清理表格 | |||
| 85. IAR 中调试信息不一致时可能需要:A. 确认编译版本和下载程序一致 B. 删除截图 C. 改标题 D. 创建标签 | |||
| ### 多选题 | |||
| 86. IAR 新建工程后常见配置包括:A. 设备 B. 编译选项 C. 链接文件 D. 调试器 | |||
| 87. IAR 文件路径相关配置包括:A. 头文件路径 B. 库文件路径 C. 输出路径 D. Git 远程路径 | |||
| 88. IAR 输出相关文件可能包括:A. hex B. bin C. map D. out | |||
| 89. IAR 调试前应确认:A. 工程可编译 B. 调试器配置正确 C. 硬件连接正常 D. 程序已下载或可下载 | |||
| 90. 静态库封装完成后通常提供:A. 头文件 B. 库文件 C. 使用说明 D. 必要配置说明 | |||
| 91. 静态库调用失败可能原因:A. 头文件路径错 B. 库文件未添加 C. 设备或编译选项不兼容 D. 函数声明不匹配 | |||
| 92. IAR 断点相关操作包括:A. 设置 B. 禁用 C. 启用 D. 条件断点 | |||
| 93. 调试变量异常时可检查:A. Watch 表达式 B. 优化等级 C. 变量作用域 D. 程序是否运行到相关代码 | |||
| 94. 内存查看相关内容包括:A. 地址 B. 数据宽度 C. 内存区域 D. 当前值 | |||
| 95. 调用堆栈可辅助判断:A. 函数调用顺序 B. 当前停在哪里 C. 谁调用了当前函数 D. Git 提交历史 | |||
| 96. 编译配置可能影响:A. 代码大小 B. 执行效率 C. 调试体验 D. 硬件适配 | |||
| 97. 链接配置可能影响:A. Flash 布局 B. RAM 布局 C. 启动地址 D. 输出 map 信息 | |||
| 98. 工程操作需要掌握:A. 新建工作区 B. 打开工程 C. 添加文件 D. 设置活动工程 | |||
| 99. IAR 常见问题排查包括:A. 找不到头文件 B. 链接失败 C. 下载失败 D. 断点不生效 | |||
| 100. 学习 IAR 时应理解:A. 操作入口 B. 配置作用 C. 错误现象 D. 排查方式 | |||
| 101. 预处理配置可能包括:A. 宏定义 B. 条件编译 C. 包含路径 D. 头文件查找 | |||
| 102. 静态库工程与普通应用工程的区别可能在:A. 输出类型 B. 生成目标 C. 调用方式 D. 源码组织 | |||
| 103. Make 与 Rebuild All 的区别可体现在:A. 是否全量重新编译 B. 编译耗时 C. 使用场景 D. 输出验证 | |||
| 104. IAR 调试窗口可帮助查看:A. 变量 B. 寄存器 C. 内存 D. 汇编 | |||
| 105. IAR 学习文档应记录:A. 操作步骤 B. 配图 C. 注意事项 D. 常见问题 | |||
| ### 判断题 | |||
| 106. IAR 工作区文件通常用于管理工作区信息。 | |||
| 107. 工程分组只是视图组织方式之一,不一定等于磁盘目录。 | |||
| 108. 设备配置与目标芯片相关。 | |||
| 109. 头文件路径配置错误可能导致编译找不到头文件。 | |||
| 110. 库文件路径配置错误可能导致链接失败。 | |||
| 111. 链接文件与 Flash/RAM 分配无关。 | |||
| 112. 输出 hex/bin 配置与生成烧录文件有关。 | |||
| 113. Watch 窗口可以查看表达式或变量。 | |||
| 114. Call Stack 可以辅助分析函数调用关系。 | |||
| 115. 逐语句和逐过程调试行为完全相同。 | |||
| 116. 条件断点能减少无意义中断。 | |||
| 117. 静态库调用时无需考虑头文件声明。 | |||
| 118. Rebuild All 通常会重新编译全部相关文件。 | |||
| 119. 下载调试失败时应检查硬件连接和调试器配置。 | |||
| 120. IAR 只需要会点按钮,不需要理解配置作用。 | |||
| ## 答案 | |||
| 1.A 2.A 3.A 4.A 5.A 6.A 7.A 8.A 9.A 10.A | |||
| 11.A 12.A 13.A 14.A 15.A 16.A 17.A 18.A 19.A 20.A | |||
| 21.A 22.A 23.A 24.A 25.A | |||
| 26.ABCD 27.ABCD 28.ABCD 29.ABCD 30.ABC 31.ABC 32.ABCD 33.ABCD | |||
| 34.ABCD 35.ABCD 36.ABCD 37.ABCD 38.ABC 39.ABCD 40.ABCD | |||
| 41.ABC 42.ABC 43.ABC 44.ABC 45.ABCD | |||
| 46.对 47.错 48.对 49.对 50.对 51.对 52.对 53.对 54.对 55.对 | |||
| 56.错 57.对 58.错 59.对 60.对 | |||
| ### 嵌入式软件第二轮答案 | |||
| 61.A 62.A 63.A 64.A 65.A 66.A 67.A 68.A 69.A 70.A | |||
| 71.A 72.A 73.A 74.A 75.A 76.A 77.A 78.A 79.A 80.A | |||
| 81.A 82.A 83.A 84.A 85.A | |||
| 86.ABCD 87.ABC 88.ABCD 89.ABCD 90.ABCD 91.ABCD 92.ABCD 93.ABCD | |||
| 94.ABCD 95.ABC 96.ABCD 97.ABCD 98.ABCD 99.ABCD 100.ABCD | |||
| 101.ABCD 102.ABCD 103.ABCD 104.ABCD 105.ABCD | |||
| 106.对 107.对 108.对 109.对 110.对 111.错 112.对 113.对 114.对 115.错 | |||
| 116.对 117.错 118.对 119.对 120.错 | |||
| @@ -0,0 +1,167 @@ | |||
| # 嵌入式软件练习题2 | |||
| 题型:单选、多选、判断 | |||
| 题量:120 题 | |||
| 难度:极高 | |||
| 范围:IAR | |||
| ## 单选题 | |||
| 1. IAR 中工程能看到某个文件,但磁盘上移动该文件后编译失败,说明:A. 工程引用依赖实际文件路径 B. 分组等于真实目录 C. IAR 自动复制所有文件 D. 工作区不需要文件 | |||
| 2. IAR 中分组和磁盘目录的关系更准确的是:A. 分组主要是工程视图组织方式,不一定等于磁盘目录 B. 二者必然相同 C. 分组只能放头文件 D. 分组只能放库文件 | |||
| 3. IAR 中设备型号配置错误,最可能影响:A. 编译、链接或调试目标匹配 B. Markdown 图片 C. Git 提交 D. SourceTree 标签 | |||
| 4. 使用硬件浮点配置时,最需要关注:A. 目标芯片和运行环境是否支持 B. 是否写了 README C. 是否创建 Git 标签 D. 是否显示行号 | |||
| 5. IAR 中头文件路径配置正确但仍报函数未定义,最可能还需要检查:A. 源文件或库文件是否参与链接 B. 图片路径 C. Markdown 表格 D. SourceInsight 主题 | |||
| 6. IAR 链接文件配置错误,可能导致:A. 存储地址分配异常或链接失败 B. Git 分支丢失 C. Markdown 无法预览 D. SourceTree 无法克隆 | |||
| 7. map 文件最适合用于分析:A. 符号和内存分布 B. Markdown 标题 C. Git 标签 D. SourceInsight 书签 | |||
| 8. 静态库调用时只添加头文件路径但不添加库文件,最可能出现:A. 链接阶段找不到函数实现 B. 编译器找不到头文件 C. 图片无法显示 D. 分支冲突 | |||
| 9. 静态库使用时,库文件和调用工程编译选项不兼容,可能导致:A. 链接或运行异常 B. Markdown 表格错位 C. Git 远程丢失 D. SourceInsight 全屏 | |||
| 10. Watch 中变量显示 optimized away 或无法查看,可能与:A. 优化等级和变量作用域有关 B. `.gitignore` 有关 C. Markdown 链接有关 D. 标签有关 | |||
| 11. 调试时程序没有停在断点处,以下最可能原因是:A. 代码未执行到该处或断点被优化影响 B. 图片路径错误 C. Git 未 push D. 表格列数不对 | |||
| 12. IAR 中“逐过程”和“逐语句”的关键区别是:A. 是否进入函数内部 B. 是否生成 hex C. 是否提交 Git D. 是否添加头文件 | |||
| 13. IAR 中调用堆栈窗口最适合判断:A. 当前函数由哪些函数调用而来 B. 库文件路径 C. Markdown 目录 D. 远程仓库地址 | |||
| 14. 在调试中查看某一固定地址处外设寄存器或变量数据,最适合:A. Memory 窗口 B. SourceTree C. Markdown D. 标签 | |||
| 15. 生成 bin/hex 文件失败,较应检查:A. 输出文件相关配置 B. Git 分支 C. 图片链接 D. Markdown 引用 | |||
| 16. 静态库封装时应提供头文件,主要因为:A. 调用者需要函数声明 B. 头文件保存机器码 C. 头文件用于烧录 D. 头文件用于 Git 合并 | |||
| 17. IAR 中 Rebuild All 相比 Make 更适合:A. 怀疑中间文件不一致时全量重编 B. 只想查看日志 C. 只想打开工程 D. 只想生成 Markdown | |||
| 18. 下载失败时最优先排查方向通常包括:A. 调试器配置、硬件连接、目标设备 B. Markdown 标题 C. Git 标签 D. SourceInsight 书签 | |||
| 19. 断点“禁用”和“删除”的区别是:A. 禁用保留断点但暂不生效,删除则移除 B. 完全相同 C. 删除后仍自动生效 D. 禁用会删除代码 | |||
| 20. 条件断点适合:A. 循环次数多但只关心特定变量值 B. 生成 DLL C. 创建标签 D. 写表格 | |||
| ## 多选题 | |||
| 21. IAR 工程配置中可能影响编译结果的有:A. 设备配置 B. 优化等级 C. 宏定义 D. 头文件路径 | |||
| 22. IAR 工程配置中可能影响链接结果的有:A. 链接文件 B. 库文件路径 C. 添加的库文件 D. 源文件是否参与工程 | |||
| 23. 静态库封装时应关注:A. 输出类型 B. 头文件接口 C. 设备/编译选项兼容 D. 生成库文件位置 | |||
| 24. 静态库调用时应关注:A. 头文件路径 B. 库文件路径 C. 库文件是否添加 D. 函数声明是否一致 | |||
| 25. IAR 调试时可辅助定位问题的窗口包括:A. Watch B. Registers C. Memory D. Call Stack | |||
| 26. 断点不生效可能原因包括:A. 代码未执行到 B. 断点被禁用 C. 优化影响 D. 下载程序不是当前版本 | |||
| 27. 链接失败可能原因包括:A. 函数未实现 B. 库文件未添加 C. 链接文件配置错误 D. 内存空间不足 | |||
| 28. 头文件找不到可能原因包括:A. 路径未配置 B. 文件名不匹配 C. 文件未放在配置路径下 D. include 写法错误 | |||
| 29. IAR 输出相关配置可能影响:A. hex 文件 B. bin 文件 C. map 文件 D. 输出目录 | |||
| 30. 调试器配置错误可能导致:A. 无法下载 B. 无法连接目标板 C. 调试启动失败 D. Markdown 不显示图片 | |||
| 31. 工程目录与文件目录不一致时,需要注意:A. 工程引用路径 B. 文件移动影响 C. 相对路径关系 D. 分组只是视图组织 | |||
| 32. 预处理配置可能影响:A. 条件编译 B. 宏开关 C. 头文件搜索 D. 最终编译内容 | |||
| 33. 链接文件通常与哪些内容有关:A. Flash 地址 B. RAM 地址 C. 启动地址 D. 段分配 | |||
| 34. IAR 调试时单步操作包括:A. Step Over B. Step Into C. Step Out D. Reset | |||
| 35. 做 IAR 实操验收时,应该能说明:A. 配置在哪里 B. 配置什么 C. 配置作用 D. 常见错误现象 | |||
| ## 判断题 | |||
| 36. IAR 工程分组一定会在磁盘创建真实目录。 | |||
| 37. 设备配置和目标芯片选择有关。 | |||
| 38. 头文件路径正确只能保证声明能被找到,不一定保证函数实现能链接到。 | |||
| 39. 链接文件配置与内存布局有关。 | |||
| 40. 静态库调用时只要有头文件就一定能链接成功。 | |||
| 41. Watch 变量显示异常可能与优化等级有关。 | |||
| 42. Memory 窗口适合查看指定地址数据。 | |||
| 43. Call Stack 可以帮助理解当前断点处的调用关系。 | |||
| 44. 条件断点可以减少循环调试中的无效暂停。 | |||
| 45. Rebuild All 通常比 Make 更彻底。 | |||
| 46. 下载失败只可能是代码语法错误导致。 | |||
| 47. 禁用断点和删除断点不是同一个概念。 | |||
| 48. 静态库封装时不需要考虑调用方如何包含头文件。 | |||
| 49. IAR 配置题不仅要记位置,还要理解作用。 | |||
| 50. IAR 工程能编译通过就一定说明调试器配置正确。 | |||
| ## 答案 | |||
| 1.A 2.A 3.A 4.A 5.A 6.A 7.A 8.A 9.A 10.A | |||
| 11.A 12.A 13.A 14.A 15.A 16.A 17.A 18.A 19.A 20.A | |||
| 21.ABCD 22.ABCD 23.ABCD 24.ABCD 25.ABCD 26.ABCD 27.ABCD 28.ABCD | |||
| 29.ABCD 30.ABC 31.ABCD 32.ABCD 33.ABCD 34.ABCD 35.ABCD | |||
| 36.错 37.对 38.对 39.对 40.错 41.对 42.对 43.对 44.对 45.对 | |||
| 46.错 47.对 48.错 49.对 50.错 | |||
| ## 高难拓展题 | |||
| ### 单选题 | |||
| 51. 场景51:配置设备时,工程分组和磁盘目录不一致,最合理的判断是:A. 分组主要是工程视图组织方式,文件仍依赖真实路径 B. 分组一定创建真实文件夹 C. 分组只能放头文件 D. 分组会自动复制文件 | |||
| 52. 场景52:设置断点时,头文件能找到但链接失败,最合理的判断是:A. SourceTree 未推送 B. 声明可见不代表实现或库已参与链接 C. 头文件路径一定错误 D. Markdown 图片错误 | |||
| 53. 场景53:整理工程文件时,链接文件配置错误,最合理的判断是:A. 只影响 Git 分支 B. 只影响 Markdown 表格 C. 可能影响 Flash/RAM 分配或链接结果 D. 只影响截图 | |||
| 54. 场景54:排查库文件时,静态库与调用工程设备配置差异,最合理的判断是:A. 一定没有影响 B. 只影响图片显示 C. 只影响文件名 D. 可能引起链接或运行兼容问题 | |||
| 55. 场景55:实操验收时,Watch 变量不可见,最合理的判断是:A. 可能受优化等级、作用域或当前停靠位置影响 B. 说明工作区损坏 C. 说明 .gitignore 错误 D. 说明 VS 平台错误 | |||
| 56. 场景56:新建工程后,断点不生效,最合理的判断是:A. 只新建标签 B. 检查断点状态、优化、代码是否执行到以及下载版本 C. 只修改 README D. 只删除分组 | |||
| 57. 场景57:链接失败时,下载失败,最合理的判断是:A. 优先执行 git fetch B. 优先生成目录 C. 优先检查调试器配置、硬件连接和目标设备 D. 优先检查 Markdown 表格 | |||
| 58. 场景58:调试暂停时,生成 hex/bin 失败,最合理的判断是:A. 检查 SourceTree 标签 B. 检查 Markdown 引用 C. 检查网页链接 D. 检查输出文件配置和编译链接是否成功 | |||
| 59. 场景59:调用静态库时,调用静态库缺少头文件,最合理的判断是:A. 编译阶段可能找不到声明 B. 运行时找不到 DLL C. 只影响图片 D. 只影响提交说明 | |||
| 60. 场景60:查看变量时,调用静态库缺少库文件,最合理的判断是:A. SourceInsight 无法打开 B. 链接阶段可能找不到实现 C. 编译阶段一定找不到头文件 D. Markdown 无法预览 | |||
| 61. 场景61:配置设备时,map 文件用途,最合理的判断是:A. 保存截图 B. 生成 Markdown 目录 C. 查看符号和内存分布 D. 创建 Git 标签 | |||
| 62. 场景62:设置断点时,逐语句与逐过程区别,最合理的判断是:A. 二者完全相同 B. 逐过程会删除断点 C. 逐语句会生成库 D. 逐语句可能进入函数内部,逐过程通常跳过函数内部 | |||
| 63. 场景63:整理工程文件时,Call Stack 的用途,最合理的判断是:A. 查看当前调用链 B. 配置库路径 C. 创建工作区 D. 生成 bin | |||
| 64. 场景64:排查库文件时,Memory 窗口用途,最合理的判断是:A. 管理远程仓库 B. 查看指定地址数据 C. 查看提交历史 D. 显示 Markdown 表格 | |||
| 65. 场景65:实操验收时,硬件浮点配置,最合理的判断是:A. 只影响 SourceTree B. 只影响标签 C. 应匹配芯片和运行环境支持 D. 只影响文档排版 | |||
| 66. 场景66:新建工程后,预处理宏配置,最合理的判断是:A. 只影响调试器连接 B. 只影响图片显示 C. 只影响提交说明 D. 会影响条件编译和编译内容 | |||
| 67. 场景67:链接失败时,Rebuild All 使用场景,最合理的判断是:A. 怀疑中间文件不一致时全量重新编译 B. 只想查看 Git 日志 C. 只想改标题 D. 只想搜索引用 | |||
| 68. 场景68:调试暂停时,静态库封装交付内容,最合理的判断是:A. 只需要 Markdown 标题 B. 通常需要提供库文件、头文件和使用说明 C. 只需要截图 D. 只需要 .gitignore | |||
| 69. 场景69:调用静态库时,调试版本和下载版本不一致,最合理的判断是:A. 只影响图片 B. 只影响表格 C. 可能导致断点或现象与源码不一致 D. 一定不影响调试 | |||
| 70. 场景70:查看变量时,输出路径配置,最合理的判断是:A. 影响 Git 远程地址 B. 影响 Markdown 标题 C. 影响 SourceInsight 书签 D. 影响生成文件保存位置 | |||
| 71. 场景71:配置设备时,工程分组和磁盘目录不一致,最合理的判断是:A. 分组主要是工程视图组织方式,文件仍依赖真实路径 B. 分组一定创建真实文件夹 C. 分组只能放头文件 D. 分组会自动复制文件 | |||
| 72. 场景72:设置断点时,头文件能找到但链接失败,最合理的判断是:A. SourceTree 未推送 B. 声明可见不代表实现或库已参与链接 C. 头文件路径一定错误 D. Markdown 图片错误 | |||
| 73. 场景73:整理工程文件时,链接文件配置错误,最合理的判断是:A. 只影响 Git 分支 B. 只影响 Markdown 表格 C. 可能影响 Flash/RAM 分配或链接结果 D. 只影响截图 | |||
| 74. 场景74:排查库文件时,静态库与调用工程设备配置差异,最合理的判断是:A. 一定没有影响 B. 只影响图片显示 C. 只影响文件名 D. 可能引起链接或运行兼容问题 | |||
| 75. 场景75:实操验收时,Watch 变量不可见,最合理的判断是:A. 可能受优化等级、作用域或当前停靠位置影响 B. 说明工作区损坏 C. 说明 .gitignore 错误 D. 说明 VS 平台错误 | |||
| 76. 场景76:新建工程后,断点不生效,最合理的判断是:A. 只新建标签 B. 检查断点状态、优化、代码是否执行到以及下载版本 C. 只修改 README D. 只删除分组 | |||
| 77. 场景77:链接失败时,下载失败,最合理的判断是:A. 优先执行 git fetch B. 优先生成目录 C. 优先检查调试器配置、硬件连接和目标设备 D. 优先检查 Markdown 表格 | |||
| 78. 场景78:调试暂停时,生成 hex/bin 失败,最合理的判断是:A. 检查 SourceTree 标签 B. 检查 Markdown 引用 C. 检查网页链接 D. 检查输出文件配置和编译链接是否成功 | |||
| 79. 场景79:调用静态库时,调用静态库缺少头文件,最合理的判断是:A. 编译阶段可能找不到声明 B. 运行时找不到 DLL C. 只影响图片 D. 只影响提交说明 | |||
| 80. 场景80:查看变量时,调用静态库缺少库文件,最合理的判断是:A. SourceInsight 无法打开 B. 链接阶段可能找不到实现 C. 编译阶段一定找不到头文件 D. Markdown 无法预览 | |||
| ### 多选题 | |||
| 81. 场景81:切换工程时,IAR 链接失败可能原因,正确的有:A. 库文件未添加 B. 函数实现缺失 C. 链接文件配置错误 D. 以上说法都不需要关注 | |||
| 82. 场景82:排查头文件时,断点不生效可能原因,正确的有:A. 代码未执行到 B. 断点被禁用 C. 与该场景无关的图片格式 D. 下载程序不是当前源码 | |||
| 83. 场景83:查看 map 时,静态库调用需要关注,正确的有:A. 头文件路径 B. 只重启软件即可 C. 库文件添加 D. 设备和编译选项兼容 | |||
| 84. 场景84:复习配置项时,调试器连接失败可能检查,正确的有:A. 完全不需要检查当前配置 B. 调试器类型 C. 目标设备 D. Markdown 目录 | |||
| 85. 场景85:编译失败时,预处理配置可能影响,正确的有:A. 宏定义 B. 条件编译 C. 头文件查找 D. 最终参与编译的代码 | |||
| 86. 场景86:下载失败时,输出相关文件,正确的有:A. hex B. bin C. map D. 以上说法都不需要关注 | |||
| 87. 场景87:封装静态库时,调试窗口用途,正确的有:A. Watch 看变量 B. Registers 看寄存器 C. 与该场景无关的图片格式 D. Call Stack 看调用链 | |||
| 88. 场景88:配置输出文件时,工程文件管理要注意,正确的有:A. 工程引用路径 B. 只重启软件即可 C. 分组与目录关系 D. 文件移动后的影响 | |||
| 89. 场景89:查看内存时,验收时应能说明,正确的有:A. 完全不需要检查当前配置 B. 配置作用 C. 错误现象 D. 排查方法 | |||
| 90. 场景90:配置链接文件时,编译配置可能影响,正确的有:A. 代码大小 B. 执行效率 C. 调试体验 D. 硬件适配 | |||
| 91. 场景91:切换工程时,IAR 链接失败可能原因,正确的有:A. 库文件未添加 B. 函数实现缺失 C. 链接文件配置错误 D. 以上说法都不需要关注 | |||
| 92. 场景92:排查头文件时,断点不生效可能原因,正确的有:A. 代码未执行到 B. 断点被禁用 C. 与该场景无关的图片格式 D. 下载程序不是当前源码 | |||
| 93. 场景93:查看 map 时,静态库调用需要关注,正确的有:A. 头文件路径 B. 只重启软件即可 C. 库文件添加 D. 设备和编译选项兼容 | |||
| 94. 场景94:复习配置项时,调试器连接失败可能检查,正确的有:A. 完全不需要检查当前配置 B. 调试器类型 C. 目标设备 D. Markdown 目录 | |||
| 95. 场景95:编译失败时,预处理配置可能影响,正确的有:A. 宏定义 B. 条件编译 C. 头文件查找 D. 最终参与编译的代码 | |||
| 96. 场景96:下载失败时,输出相关文件,正确的有:A. hex B. bin C. map D. 以上说法都不需要关注 | |||
| 97. 场景97:封装静态库时,调试窗口用途,正确的有:A. Watch 看变量 B. Registers 看寄存器 C. 与该场景无关的图片格式 D. Call Stack 看调用链 | |||
| 98. 场景98:配置输出文件时,工程文件管理要注意,正确的有:A. 工程引用路径 B. 只重启软件即可 C. 分组与目录关系 D. 文件移动后的影响 | |||
| 99. 场景99:查看内存时,验收时应能说明,正确的有:A. 完全不需要检查当前配置 B. 配置作用 C. 错误现象 D. 排查方法 | |||
| 100. 场景100:配置链接文件时,编译配置可能影响,正确的有:A. 代码大小 B. 执行效率 C. 调试体验 D. 硬件适配 | |||
| 101. 场景101:切换工程时,IAR 链接失败可能原因,正确的有:A. 库文件未添加 B. 函数实现缺失 C. 链接文件配置错误 D. 以上说法都不需要关注 | |||
| 102. 场景102:排查头文件时,断点不生效可能原因,正确的有:A. 代码未执行到 B. 断点被禁用 C. 与该场景无关的图片格式 D. 下载程序不是当前源码 | |||
| 103. 场景103:查看 map 时,静态库调用需要关注,正确的有:A. 头文件路径 B. 只重启软件即可 C. 库文件添加 D. 设备和编译选项兼容 | |||
| 104. 场景104:复习配置项时,调试器连接失败可能检查,正确的有:A. 完全不需要检查当前配置 B. 调试器类型 C. 目标设备 D. Markdown 目录 | |||
| 105. 场景105:编译失败时,预处理配置可能影响,正确的有:A. 宏定义 B. 条件编译 C. 头文件查找 D. 最终参与编译的代码 | |||
| ### 判断题 | |||
| 106. 场景106:调用静态库时,工程分组不一定等于磁盘目录。 | |||
| 107. 场景107:查看变量时,IAR 只要能打开工程就不需要理解配置作用。 | |||
| 108. 场景108:配置设备时,头文件路径正确不代表函数实现已链接。 | |||
| 109. 场景109:设置断点时,禁用断点等同于删除断点。 | |||
| 110. 场景110:整理工程文件时,链接文件与存储布局有关。 | |||
| 111. 场景111:排查库文件时,禁用断点等同于删除断点。 | |||
| 112. 场景112:实操验收时,Watch 显示可能受优化影响。 | |||
| 113. 场景113:新建工程后,设备配置与目标芯片无关。 | |||
| 114. 场景114:链接失败时,Rebuild All 通常比 Make 更彻底。 | |||
| 115. 场景115:调试暂停时,设备配置与目标芯片无关。 | |||
| 116. 场景116:调用静态库时,条件断点适合特定条件下暂停。 | |||
| 117. 场景117:查看变量时,头文件路径错误不会影响编译。 | |||
| 118. 场景118:配置设备时,下载失败需要检查硬件连接和调试器配置。 | |||
| 119. 场景119:设置断点时,头文件路径错误不会影响编译。 | |||
| 120. 场景120:整理工程文件时,静态库交付通常需要头文件。 | |||
| ## 高难拓展题答案 | |||
| 51.A 52.B 53.C 54.D 55.A 56.B 57.C 58.D 59.A 60.B | |||
| 61.C 62.D 63.A 64.B 65.C 66.D 67.A 68.B 69.C 70.D | |||
| 71.A 72.B 73.C 74.D 75.A 76.B 77.C 78.D 79.A 80.B | |||
| 81.ABC 82.ABD 83.ACD 84.BCD 85.ABCD 86.ABC 87.ABD 88.ACD | |||
| 89.BCD 90.ABCD 91.ABC 92.ABD 93.ACD 94.BCD 95.ABCD 96.ABC | |||
| 97.ABD 98.ACD 99.BCD 100.ABCD 101.ABC 102.ABD 103.ACD 104.BCD | |||
| 105.ABCD | |||
| 106.对 107.错 108.对 109.错 110.对 111.错 112.对 113.错 114.对 115.错 | |||
| 116.对 117.错 118.对 119.错 120.对 | |||
| @@ -0,0 +1,276 @@ | |||
| # 通用软件练习题 | |||
| 题型:单选、多选、判断 | |||
| 题量:220 题 | |||
| 范围:Git、SourceTree、Markdown、SourceInsight。 | |||
| ### 单选题 | |||
| 1. Git 中实际编辑文件所在区域是:A. 工作区 B. 暂存区 C. 本地仓库 D. 远程仓库 | |||
| 2. `git add` 的作用是:A. 加入暂存区 B. 提交到远程 C. 删除分支 D. 创建标签 | |||
| 3. `git commit` 的作用是:A. 提交到本地仓库 B. 拉取代码 C. 克隆仓库 D. 删除文件 | |||
| 4. `git status` 用于:A. 查看状态 B. 创建仓库 C. 合并分支 D. 生成补丁 | |||
| 5. `git log` 用于:A. 查看提交历史 B. 创建分支 C. 删除标签 D. 应用补丁 | |||
| 6. 创建本地仓库常用:A. `git init` B. `git pull` C. `git push` D. `git am` | |||
| 7. 克隆远程仓库常用:A. `git clone` B. `git branch` C. `git tag` D. `git reset` | |||
| 8. 查看分支常用:A. `git branch` B. `git log` C. `git add` D. `git rm` | |||
| 9. 合并分支常用:A. `git merge` B. `git init` C. `git status` D. `git apply` | |||
| 10. SourceTree 中“获取”对应:A. fetch B. pull C. push D. commit | |||
| 11. SourceTree 中“拉取”对应:A. fetch+merge B. add C. tag D. stash | |||
| 12. SourceTree 中“推送”用于:A. 本地提交同步到远程 B. 删除本地文件 C. 创建 Markdown D. 打开工程 | |||
| 13. 临时保存未提交修改应使用:A. 贮藏 B. 标签 C. 删除分支 D. 克隆 | |||
| 14. 撤销某次提交但保留历史适合:A. 回滚提交 B. 硬重置 C. 删除仓库 D. 清理文件 | |||
| 15. `.gitignore` 用于:A. 忽略不跟踪文件 B. 保存提交说明 C. 创建补丁 D. 合并冲突 | |||
| 16. Git 冲突常发生在:A. 合并或拉取 B. 写标题 C. 查看图片 D. 新建表格 | |||
| 17. Git 标签常用于:A. 标记版本 B. 保存临时修改 C. 删除文件 D. 添加头文件 | |||
| 18. 补丁常用于:A. 传递代码修改 B. 生成动态库 C. 查看寄存器 D. 写测试断言 | |||
| 19. `git apply` 主要用于:A. 应用普通补丁 B. 运行程序 C. 创建表格 D. 查看内存 | |||
| 20. `git am` 主要用于:A. 应用带提交信息的补丁 B. 创建工程 C. 删除图片 D. 同步符号表 | |||
| 21. 变基常见作用是:A. 让历史更线性 B. 删除全部提交 C. 生成 DLL D. 创建 Markdown | |||
| 22. Markdown 一级标题写法是:A. `# 标题` B. `## 标题` C. `> 标题` D. `| 标题 |` | |||
| 23. Markdown 加粗写法是:A. `**文字**` B. `*文字*` C. `~~文字~~` D. `` `文字` `` | |||
| 24. Markdown 倾斜写法是:A. `*文字*` B. `**文字**` C. `#文字` D. `![文字]` | |||
| 25. Markdown 删除线写法是:A. `~~文字~~` B. `##文字` C. `[文字]` D. `|文字|` | |||
| 26. Markdown 单行代码写法是:A. 反引号包裹 B. 双星号包裹 C. 方括号包裹 D. 井号包裹 | |||
| 27. Markdown 图片语法是:A. `` B. `[说明](路径)` C. `<img>` D. `{img}` | |||
| 28. Markdown 链接语法是:A. `[文字](地址)` B. `` C. `#文字` D. `>文字` | |||
| 29. Markdown 表格表头分隔行常用:A. `| --- | --- |` B. `###` C. `***文字***` D. `git add` | |||
| 30. Markdown 引用写法是:A. `> 内容` B. `# 内容` C. `| 内容` D. `! 内容` | |||
| 31. Markdown 分割线可写为:A. `---` B. `+++` C. `===` D. `///` | |||
| 32. Markdown 目录常见写法是:A. `[TOC]` B. `[IMG]` C. `[DLL]` D. `[GIT]` | |||
| 33. Markdown 图片路径推荐:A. 相对路径 B. 桌面绝对路径 C. 临时路径 D. 不写路径 | |||
| 34. SourceInsight 主要用于:A. 代码查看和编辑 B. 生成 DLL C. 版本提交 D. 单元测试 | |||
| 35. SourceInsight 添加文件后无法跳转,优先:A. 同步符号表 B. 删除工程 C. 创建标签 D. 推送代码 | |||
| 36. SourceInsight 搜索引用用于:A. 查找符号使用位置 B. 编译程序 C. 运行测试 D. 生成 hex | |||
| 37. SourceInsight Project Window 用于:A. 查看工程文件 B. 查看 Git 远程 C. 查看测试覆盖率 D. 查看 DLL | |||
| 38. SourceInsight Symbol Window 用于:A. 查看符号 B. 查看提交 C. 查看断言 D. 查看平台 | |||
| 39. SourceInsight Bookmark Window 用于:A. 管理书签 B. 管理远程仓库 C. 管理库目录 D. 管理 DLL | |||
| 40. SourceInsight Relation Window 用于:A. 查看符号关系 B. 创建补丁 C. 编译链接 D. 创建表格 | |||
| 41. SourceTree 中创建本地仓库对应:A. 初始化仓库 B. 生成库 C. 单元测试 D. 同步符号 | |||
| 42. SourceTree 中打开本地仓库需要:A. 选择已有仓库路径 B. 配置芯片 C. 配置链接文件 D. 配置覆盖率 | |||
| 43. SourceTree 中克隆仓库需要:A. 远程地址和本地路径 B. 头文件路径 C. DLL 名称 D. 测试名称 | |||
| 44. SourceTree 中删除分支前应注意:A. 确认分支不再需要 B. 必须删除主分支 C. 必须清空仓库 D. 必须删除远程 | |||
| 45. SourceTree 中解决冲突后通常需要:A. 提交解决结果 B. 删除所有文件 C. 新建工作区 D. 创建目录 | |||
| 46. SourceTree 中丢弃操作会:A. 放弃未提交修改 B. 生成提交 C. 推送远程 D. 创建标签 | |||
| 47. 停止跟踪文件但保留本地文件常用:A. `git rm --cached` B. `git clone` C. `git init` D. `git log` | |||
| 48. 远程仓库常见地址协议是:A. HTTPS/SSH B. PNG/JPG C. Debug/Release D. Win32/x64 | |||
| 49. 快进合并特点是:A. 分支指针直接前移 B. 一定产生冲突 C. 一定生成补丁 D. 一定失败 | |||
| 50. 非快进合并可能产生:A. 合并提交 B. Markdown 表格 C. DLL 文件 D. IAR 工作区 | |||
| ### 多选题 | |||
| 51. Git 常见区域包括:A. 工作区 B. 暂存区 C. 本地仓库 D. 远程仓库 | |||
| 52. SourceTree 仓库相关操作包括:A. 创建本地仓库 B. 打开本地仓库 C. 克隆远程仓库 D. 获取 | |||
| 53. SourceTree 节点相关操作包括:A. 提交 B. 重置 C. 回滚提交 D. 编译工程 | |||
| 54. SourceTree 分支相关操作包括:A. 新建分支 B. 合并分支 C. 删除分支 D. 切换分支 | |||
| 55. SourceTree 冲突相关操作包括:A. 制造冲突 B. 解决冲突 C. 标记解决 D. 提交结果 | |||
| 56. SourceTree 远程同步相关操作包括:A. 获取 B. 拉取 C. 推送 D. 同步符号表 | |||
| 57. Git 补丁相关命令可能包括:A. `git diff` B. `git apply` C. `git format-patch` D. `git am` | |||
| 58. `.gitignore` 适合忽略:A. 编译输出 B. 临时文件 C. 日志文件 D. 必须提交的源码 | |||
| 59. Markdown 标题可包括:A. 一级标题 B. 二级标题 C. 三级标题 D. 调试标题 | |||
| 60. Markdown 列表包括:A. 无序列表 B. 有序列表 C. 嵌套列表 D. 仓库列表 | |||
| 61. Markdown 文字样式包括:A. 加粗 B. 倾斜 C. 加粗倾斜 D. 删除线 | |||
| 62. Markdown 代码块包括:A. 单行代码 B. 多行代码 C. 指定语言代码块 D. Git 仓库 | |||
| 63. Markdown 超链接相关包括:A. 文字链接 B. 图片链接 C. 页内跳转 D. 库链接配置 | |||
| 64. Markdown 其他常见语法包括:A. 图片 B. 表格 C. 引用 D. 分割线 | |||
| 65. 页面内跳转可跳到:A. 标题 B. 目录 C. 自定义 id D. 本地仓库对象 | |||
| 66. SourceInsight 常规操作包括:A. 工程新建/添加 B. 文件新建/添加 C. 符号表同步 D. 搜索引用 | |||
| 67. SourceInsight 视图相关包括:A. 水平平铺 B. 垂直平铺 C. 层叠显示 D. 单窗口显示 | |||
| 68. SourceInsight 常用窗口包括:A. Project Window B. Symbol Window C. Relation Window D. Bookmark Window | |||
| 69. SourceInsight 搜索引用可用于:A. 函数 B. 变量 C. 宏 D. 图片尺寸 | |||
| 70. Git 分支操作可能包括:A. 创建 B. 切换 C. 合并 D. 删除 | |||
| 71. 解决冲突时通常需要:A. 打开冲突文件 B. 修改冲突内容 C. 标记为已解决 D. 提交 | |||
| 72. 重置类型常见包括:A. soft B. mixed C. hard D. dynamic | |||
| 73. 标签操作包括:A. 创建标签 B. 删除标签 C. 推送标签 D. 查看标签 | |||
| 74. 贮藏操作可能包括:A. 创建贮藏 B. 应用贮藏 C. 删除贮藏 D. 查看贮藏 | |||
| 75. 变基操作需要注意:A. 公共分支谨慎使用 B. 可能改写历史 C. 操作前确认状态 D. 一定不会冲突 | |||
| 76. SourceTree 可视化界面常见内容包括:A. 文件状态 B. 提交历史 C. 分支图 D. IAR 寄存器 | |||
| 77. Markdown 图片不显示可能原因:A. 路径错误 B. 图片文件不存在 C. 使用了本机绝对路径且环境变化 D. 图片语法错误 | |||
| 78. SourceInsight 搜索结果不完整可能原因:A. 未同步符号表 B. 文件未加入工程 C. 搜索范围不对 D. 工程解析不完整 | |||
| 79. Git 提交前应关注:A. 修改内容 B. 暂存文件 C. 提交说明 D. 是否误提交无关文件 | |||
| 80. 拉取前应关注:A. 本地是否有未提交修改 B. 当前分支是否正确 C. 远程是否有更新 D. Markdown 是否加粗 | |||
| ### 判断题 | |||
| 81. Git 是分布式版本控制系统。 | |||
| 82. SourceTree 是 Git 图形化工具之一。 | |||
| 83. `git add` 会直接推送到远程仓库。 | |||
| 84. `git commit` 会生成本地提交。 | |||
| 85. `git push` 用于推送本地提交到远程。 | |||
| 86. `git pull` 通常会更新当前本地分支。 | |||
| 87. 获取和拉取完全一样。 | |||
| 88. 重置和回滚提交完全一样。 | |||
| 89. 硬重置使用不当可能丢失修改。 | |||
| 90. 贮藏可以临时保存未提交修改。 | |||
| 91. `.gitignore` 可用于忽略编译产物。 | |||
| 92. 已跟踪文件写入 `.gitignore` 后一定自动停止跟踪。 | |||
| 93. 标签适合标记重要版本。 | |||
| 94. 分支可以用于并行开发。 | |||
| 95. 合并分支一定不会产生冲突。 | |||
| 96. Markdown 文件常用 `.md` 后缀。 | |||
| 97. Markdown 中 `#` 可表示标题。 | |||
| 98. Markdown 中 `` 表示图片。 | |||
| 99. Markdown 中 `[文字](地址)` 表示链接。 | |||
| 100. Markdown 中三个反引号可表示多行代码块。 | |||
| 101. Markdown 表格通常使用 `|` 分隔列。 | |||
| 102. Markdown 引用可使用 `>`。 | |||
| 103. Markdown 图片建议使用相对路径。 | |||
| 104. SourceInsight 可用于代码查看和编辑。 | |||
| 105. SourceInsight 符号表同步会影响跳转和引用搜索。 | |||
| 106. SourceInsight 不能添加文件。 | |||
| 107. SourceInsight 可以进行视图切换。 | |||
| 108. SourceInsight 可以搜索函数引用。 | |||
| 109. SourceInsight 行号显示属于常用视图功能。 | |||
| 110. SourceInsight 搜索引用前不需要关注工程文件是否完整。 | |||
| ## 第二轮拓展题 | |||
| ### 单选题 | |||
| 111. Git 中 HEAD 通常指向:A. 当前分支的最新提交 B. 暂存区文件 C. 远程仓库地址 D. Markdown 标题 | |||
| 112. `git diff` 常用于:A. 查看修改差异 B. 创建工作区 C. 删除远程仓库 D. 生成 DLL | |||
| 113. `git remote -v` 用于:A. 查看远程仓库地址 B. 查看 Markdown 目录 C. 查看 IAR 设备 D. 查看 VS 断点 | |||
| 114. SourceTree 中文件状态“未暂存”表示:A. 修改还未加入暂存区 B. 修改已经提交 C. 文件已推送 D. 文件已删除远程 | |||
| 115. SourceTree 中文件状态“已暂存”表示:A. 修改已准备进入下一次提交 B. 修改已推送远程 C. 修改已被忽略 D. 修改已丢弃 | |||
| 116. 解决冲突时,冲突标记 `<<<<<<<` 通常表示:A. 冲突内容开始 B. 表格开始 C. 图片开始 D. 测试开始 | |||
| 117. `origin` 通常表示:A. 默认远程仓库名 B. 默认分支名 C. 默认标签名 D. 默认文件名 | |||
| 118. `main` 或 `master` 通常表示:A. 主分支名称 B. 暂存区名称 C. 补丁名称 D. 图片名称 | |||
| 119. SourceTree 的历史视图主要用于:A. 查看提交记录 B. 配置芯片 C. 编写代码 D. 生成测试 | |||
| 120. SourceTree 中“检出”分支的含义是:A. 切换到该分支 B. 删除该分支 C. 合并该分支 D. 标记该分支 | |||
| 121. Markdown 中 `### 标题` 表示:A. 三级标题 B. 一级标题 C. 引用 D. 表格 | |||
| 122. Markdown 中 `***文字***` 表示:A. 加粗倾斜 B. 代码块 C. 图片 D. 分割线 | |||
| 123. Markdown 中嵌套列表主要依靠:A. 缩进 B. 分号 C. 反斜杠 D. 文件后缀 | |||
| 124. Markdown 中多行代码块结束标记是:A. 三个反引号 B. 一个井号 C. 一个星号 D. 一个竖线 | |||
| 125. Markdown 页内跳转链接通常使用:A. `#锚点` B. `.dll` C. `.lib` D. `git://` | |||
| 126. SourceInsight 中同步符号表的目的主要是:A. 更新符号索引 B. 生成可执行文件 C. 提交代码 D. 创建静态库 | |||
| 127. SourceInsight 中打开多个文件后进行平铺显示属于:A. 视图切换 B. 版本管理 C. 编译配置 D. 单元测试 | |||
| 128. SourceInsight 中 Context Window 主要用于:A. 查看上下文信息 B. 推送代码 C. 生成 DLL D. 设置断点 | |||
| 129. SourceInsight 中 Overview 常用于:A. 查看代码缩略视图 B. 创建仓库 C. 配置库目录 D. 运行测试 | |||
| 130. SourceInsight 搜索引用前,工程文件应:A. 已正确添加并同步 B. 全部删除 C. 全部压缩 D. 全部提交远程 | |||
| 131. Git 中工作区修改未 add 时,commit 默认不会提交该修改。正确操作是先:A. add B. push C. tag D. clone | |||
| 132. SourceTree 中“丢弃”适合处理:A. 确定不要的未提交修改 B. 已发布版本 C. 远程仓库地址 D. 测试报告 | |||
| 133. 创建补丁前最好确认:A. 修改内容是否正确 B. 显示器亮度 C. 字体颜色 D. 图片格式 | |||
| 134. 应用补丁失败时可能需要:A. 检查补丁上下文和冲突 B. 删除所有源码 C. 重装系统 D. 创建 DLL | |||
| 135. Markdown 文档中图片不显示,最先检查:A. 图片路径 B. Git 分支 C. IAR 设备 D. VS 平台 | |||
| 136. Markdown 中表格列对齐可通过:A. 第二行冒号位置 B. 提交说明 C. 文件名 D. 标签 | |||
| 137. SourceInsight 新建工程后添加源码目录是为了:A. 让工具解析代码 B. 生成单元测试 C. 创建动态库 D. 推送远程 | |||
| 138. SourceInsight 中搜索变量引用可帮助:A. 判断变量使用位置 B. 生成 bin C. 清理解决方案 D. 创建补丁 | |||
| 139. Git 中“提交节点”可以理解为:A. 一次版本快照 B. 一个图片文件 C. 一个测试断言 D. 一个窗口布局 | |||
| 140. SourceTree 中“日志/历史”里每个点通常代表:A. 一次提交 B. 一个目录 C. 一个头文件路径 D. 一个窗口 | |||
| 141. Git 中本地仓库提交后,不推送远程时远程仓库:A. 不会自动获得该提交 B. 一定自动同步 C. 一定删除分支 D. 一定产生冲突 | |||
| 142. 多人协作前先拉取通常是为了:A. 减少与远程差异 B. 删除本地代码 C. 关闭软件 D. 生成图片 | |||
| 143. `.gitignore` 修改后也需要:A. 提交到仓库才能共享规则 B. 放入 DLL C. 放入 IAR D. 删除本地仓库 | |||
| 144. Git 中 stash pop 与 stash apply 的区别常见是:A. pop 应用后删除该贮藏 B. apply 一定删除贮藏 C. 二者都删除仓库 D. 二者都提交远程 | |||
| 145. SourceTree 删除标签时应区分:A. 本地标签和远程标签 B. 图片和表格 C. 头文件和源文件 D. Debug 和 Release | |||
| 146. Markdown 中 HTML 锚点可写为:A. `<span id="xxx"></span>` B. `git add xxx` C. `#include xxx` D. `LoadLibrary` | |||
| 147. Markdown 引用中嵌套引用可使用:A. 多个 `>` B. 多个 `#` C. 多个 `|` D. 多个 `;` | |||
| 148. SourceInsight 行号显示便于:A. 定位代码位置 B. 链接库文件 C. 生成补丁 D. 配置平台 | |||
| 149. SourceInsight Full Screen 表示:A. 全屏显示 B. 全量编译 C. 全部提交 D. 全部删除 | |||
| 150. SourceInsight Project Symbol List 主要展示:A. 工程符号列表 B. Git 远程列表 C. DLL 列表 D. 测试列表 | |||
| 151. Git 中分支合并前应确认:A. 当前所在分支 B. 图片路径 C. 字体大小 D. 屏幕分辨率 | |||
| 152. Git 中强制操作前应确认:A. 是否会丢失修改 B. 是否改变主题 C. 是否打开图片 D. 是否显示行号 | |||
| 153. SourceTree 中提交说明建议:A. 清晰描述修改内容 B. 留空 C. 只写一个点 D. 写随机字符 | |||
| 154. Markdown 文档结构清晰主要依赖:A. 标题层级 B. DLL 文件 C. 仓库地址 D. 调试器 | |||
| 155. Markdown 中代码块指定 `c` 的作用是:A. C 语言高亮 B. 自动编译 C. 自动提交 D. 自动生成库 | |||
| 156. SourceInsight 中添加文件失败时应检查:A. 文件路径和工程设置 B. Git 标签 C. 单元测试 D. DLL 位置 | |||
| 157. SourceInsight 中符号无法跳转可能是:A. 符号表未更新 B. Markdown 表格错 C. Git 未 push D. DLL 缺失 | |||
| 158. Git 中远程分支更新后本地看不到,可能需要:A. fetch B. commit C. add D. init | |||
| 159. SourceTree 中“移除”文件一般表示:A. 从版本管理或项目状态中移除文件 B. 创建标签 C. 生成文档 D. 搜索引用 | |||
| 160. Markdown 中文档内部目录有助于:A. 快速跳转 B. 编译链接 C. 查看寄存器 D. 运行测试 | |||
| ### 多选题 | |||
| 161. Git 提交前可检查:A. 文件差异 B. 暂存区内容 C. 提交说明 D. 当前分支 | |||
| 162. Git 远程协作常见操作包括:A. fetch B. pull C. push D. clone | |||
| 163. SourceTree 中历史记录可查看:A. 提交节点 B. 分支走向 C. 作者信息 D. 提交说明 | |||
| 164. SourceTree 冲突解决后可能需要:A. 编辑冲突文件 B. 标记解决 C. 添加到暂存区 D. 提交 | |||
| 165. 补丁使用场景包括:A. 临时传递修改 B. 代码评审 C. 跨仓库应用修改 D. 保存局部改动 | |||
| 166. Markdown 文档可包含:A. 标题 B. 列表 C. 图片 D. 代码块 | |||
| 167. Markdown 图片链接需要关注:A. 图片文件是否存在 B. 路径是否正确 C. 是否使用相对路径 D. 文件名是否一致 | |||
| 168. Markdown 表格由哪些部分组成:A. 表头 B. 分隔行 C. 内容行 D. 列分隔符 | |||
| 169. Markdown 页内跳转方式包括:A. 标题锚点 B. 自定义 id C. 目录链接 D. 图片文件名直接跳转 | |||
| 170. SourceInsight 工程管理包括:A. 新建工程 B. 打开工程 C. 添加文件 D. 同步符号表 | |||
| 171. SourceInsight 常用面板可能包括:A. Project Window B. Symbol Window C. Context Window D. Relation Window | |||
| 172. SourceInsight 搜索引用结果不准确时可检查:A. 工程文件完整性 B. 符号表同步 C. 搜索范围 D. 代码是否能被解析 | |||
| 173. Git 重置前应确认:A. 重置类型 B. 目标提交 C. 是否有未保存修改 D. 是否影响历史 | |||
| 174. Git 回滚提交适合:A. 保留历史 B. 撤销已提交修改 C. 团队协作更安全 D. 删除全部仓库 | |||
| 175. Git 分支适合:A. 开发新功能 B. 修复 bug C. 保持主线稳定 D. 并行试验 | |||
| 176. SourceTree 标签相关操作包括:A. 创建 B. 删除 C. 推送 D. 查看 | |||
| 177. 贮藏适合在以下场景使用:A. 临时切换任务 B. 当前修改不想提交 C. 拉取前保存工作区 D. 永久删除代码 | |||
| 178. Markdown 文字格式包括:A. 加粗 B. 倾斜 C. 删除线 D. 行内代码 | |||
| 179. Markdown 代码块优势包括:A. 保留格式 B. 便于阅读 C. 可语法高亮 D. 自动运行程序 | |||
| 180. SourceInsight 视图排列包括:A. 层叠 B. 水平平铺 C. 垂直平铺 D. 双窗口 | |||
| 181. Git 忽略文件常见对象包括:A. 编译输出 B. 临时文件 C. 日志 D. 用户本地配置 | |||
| 182. SourceTree 中分支图可帮助判断:A. 分支关系 B. 合并情况 C. 提交顺序 D. 编译错误行号 | |||
| 183. Markdown 文档验收时应注意:A. 内容完整 B. 图片可显示 C. 路径相对 D. 格式清晰 | |||
| 184. Git 常见风险操作包括:A. hard reset B. 强制推送 C. 删除分支 D. 丢弃修改 | |||
| 185. SourceInsight 常见用途包括:A. 阅读代码 B. 查找引用 C. 查看符号关系 D. 工程代码管理 | |||
| 186. Git 提交粒度建议:A. 修改内容相关 B. 不混入无关文件 C. 说明清晰 D. 越大越好 | |||
| 187. SourceTree 中远程操作可能需要:A. 网络连接 B. 远程地址 C. 权限认证 D. 本地仓库 | |||
| 188. Markdown 中链接可能指向:A. 网页 B. 本地相对文件 C. 文档内标题 D. 图片外层跳转 | |||
| 189. SourceInsight 添加代码目录后应关注:A. 文件是否加入工程 B. 符号是否识别 C. 搜索是否正常 D. Git 是否推送 | |||
| 190. 学习这些通用工具时应掌握:A. 概念 B. 操作入口 C. 操作步骤 D. 易错点 | |||
| ### 判断题 | |||
| 191. 本地提交后必须 push,远程仓库才会同步该提交。 | |||
| 192. `git diff` 可帮助查看修改差异。 | |||
| 193. `origin` 通常是默认远程仓库名。 | |||
| 194. 分支切换前应关注工作区是否有未保存修改。 | |||
| 195. 冲突文件中的冲突标记需要人工处理。 | |||
| 196. 回滚提交会直接删除历史提交,不留下记录。 | |||
| 197. 贮藏适合临时保存工作区修改。 | |||
| 198. `.gitignore` 本身也可以纳入版本管理。 | |||
| 199. Markdown 中 `###` 表示三级标题。 | |||
| 200. Markdown 中图片语法和普通链接语法完全一样。 | |||
| 201. Markdown 表格第二行用于分隔表头和内容。 | |||
| 202. Markdown 使用相对路径更利于文档迁移。 | |||
| 203. SourceInsight 添加文件后不需要同步符号表也一定能搜索完整。 | |||
| 204. SourceInsight 可以通过搜索引用查看函数在哪里被调用。 | |||
| 205. SourceInsight 视图切换能提高多文件阅读效率。 | |||
| 206. SourceInsight 的 Project Window 可辅助查看工程文件。 | |||
| 207. Git 硬重置不会有任何风险。 | |||
| 208. SourceTree 图形界面也可以进行 Git 常用操作。 | |||
| 209. Markdown 代码块可以用于展示 C 语言代码。 | |||
| 210. SourceInsight 符号表状态会影响跳转体验。 | |||
| 211. 拉取远程代码前最好确认本地修改状态。 | |||
| 212. 标签常用于版本发布节点。 | |||
| 213. 补丁可以用来保存或传递一组修改。 | |||
| 214. SourceTree 中丢弃修改前应确认修改不再需要。 | |||
| 215. Markdown 文档中截图越多越好,不需要文字说明。 | |||
| 216. Git 分支可以用于隔离不同任务。 | |||
| 217. SourceInsight 只能查看代码,不能搜索引用。 | |||
| 218. Markdown 页内跳转可以通过标题锚点实现。 | |||
| 219. 变基操作可能改写提交历史。 | |||
| 220. 学习软件操作时只记截图,不理解概念也足够应对所有题目。 | |||
| ## 答案 | |||
| 1.A 2.A 3.A 4.A 5.A 6.A 7.A 8.A 9.A 10.A | |||
| 11.A 12.A 13.A 14.A 15.A 16.A 17.A 18.A 19.A 20.A | |||
| 21.A 22.A 23.A 24.A 25.A 26.A 27.A 28.A 29.A 30.A | |||
| 31.A 32.A 33.A 34.A 35.A 36.A 37.A 38.A 39.A 40.A | |||
| 41.A 42.A 43.A 44.A 45.A 46.A 47.A 48.A 49.A 50.A | |||
| 51.ABCD 52.ABCD 53.ABC 54.ABCD 55.ABCD 56.ABC 57.ABCD 58.ABC | |||
| 59.ABC 60.ABC 61.ABCD 62.ABC 63.ABC 64.ABCD 65.ABC 66.ABCD | |||
| 67.ABCD 68.ABCD 69.ABC 70.ABCD 71.ABCD 72.ABC 73.ABCD 74.ABCD | |||
| 75.ABC 76.ABC 77.ABCD 78.ABCD 79.ABCD 80.ABC | |||
| 81.对 82.对 83.错 84.对 85.对 86.对 87.错 88.错 89.对 90.对 | |||
| 91.对 92.错 93.对 94.对 95.错 96.对 97.对 98.对 99.对 100.对 | |||
| 101.对 102.对 103.对 104.对 105.对 106.错 107.对 108.对 109.对 110.错 | |||
| ### 通用软件第二轮答案 | |||
| 111.A 112.A 113.A 114.A 115.A 116.A 117.A 118.A 119.A 120.A | |||
| 121.A 122.A 123.A 124.A 125.A 126.A 127.A 128.A 129.A 130.A | |||
| 131.A 132.A 133.A 134.A 135.A 136.A 137.A 138.A 139.A 140.A | |||
| 141.A 142.A 143.A 144.A 145.A 146.A 147.A 148.A 149.A 150.A | |||
| 151.A 152.A 153.A 154.A 155.A 156.A 157.A 158.A 159.A 160.A | |||
| 161.ABCD 162.ABCD 163.ABCD 164.ABCD 165.ABCD 166.ABCD 167.ABCD 168.ABCD | |||
| 169.ABC 170.ABCD 171.ABCD 172.ABCD 173.ABCD 174.ABC 175.ABCD 176.ABCD | |||
| 177.ABC 178.ABCD 179.ABC 180.ABCD 181.ABCD 182.ABC 183.ABCD 184.ABCD | |||
| 185.ABCD 186.ABC 187.ABCD 188.ABCD 189.ABC 190.ABCD | |||
| 191.对 192.对 193.对 194.对 195.对 196.错 197.对 198.对 199.对 200.错 | |||
| 201.对 202.对 203.错 204.对 205.对 206.对 207.错 208.对 209.对 210.对 | |||
| 211.对 212.对 213.对 214.对 215.错 216.对 217.错 218.对 219.对 220.错 | |||
| @@ -0,0 +1,277 @@ | |||
| # 通用软件练习题2 | |||
| 题型:单选、多选、判断 | |||
| 题量:220 题 | |||
| 难度:极高 | |||
| 范围:Git、SourceTree、Markdown、SourceInsight | |||
| ## 单选题 | |||
| 1. 在 Git 中,某文件已经被提交过,之后又被加入 `.gitignore`,但仍然出现在修改列表中,最可能的原因是:A. 文件已经被 Git 跟踪 B. `.gitignore` 只能忽略文件夹 C. `.gitignore` 只能忽略远程文件 D. SourceTree 不支持 `.gitignore` | |||
| 2. 在 SourceTree 中执行“获取”后,发现远程分支有新提交,但当前工作区代码没有变化,最合理的解释是:A. 获取只更新远程跟踪信息,不一定合并到当前分支 B. 获取失败 C. 远程仓库为空 D. 本地仓库损坏 | |||
| 3. 已经提交到本地仓库但尚未推送远程的提交,若执行硬重置到更早提交,最可能的风险是:A. 本地提交可能丢失 B. 远程仓库一定被删除 C. `.gitignore` 一定失效 D. Markdown 图片路径一定改变 | |||
| 4. 团队协作中,想撤销一个已经推送到远程的错误提交,更推荐使用回滚提交而不是硬重置,主要原因是:A. 回滚会保留历史,更适合协作 B. 回滚一定不产生新提交 C. 硬重置只能用于图片 D. 回滚会自动解决所有冲突 | |||
| 5. 分支 A 和分支 B 都修改了同一文件同一行,合并时最可能出现:A. 冲突 B. 标签 C. 贮藏 D. 忽略规则 | |||
| 6. 对一个公共分支执行 rebase 的主要风险是:A. 可能改写提交历史,影响他人协作 B. 一定删除工作区 C. 一定删除远程仓库 D. 一定生成 DLL | |||
| 7. SourceTree 中“贮藏”最适合的场景是:A. 当前修改暂时不提交,但需要切换任务 B. 永久删除历史 C. 发布版本 D. 忽略编译文件 | |||
| 8. `git apply` 应用补丁失败,最可能优先检查:A. 补丁上下文是否与当前代码匹配 B. 是否安装 IAR C. 是否打开 VS D. Markdown 表格是否有边框 | |||
| 9. `git am` 与 `git apply` 相比,更强调:A. 保留提交信息并形成提交 B. 只能应用图片 C. 只能用于忽略文件 D. 只能在 SourceInsight 中使用 | |||
| 10. Markdown 中 `[TOC]` 无法显示目录,最可能原因是:A. 当前编辑器或渲染器不支持该扩展 B. 标题级别太多 C. 文件必须是 `.txt` D. Git 未提交 | |||
| 11. Markdown 图片在自己电脑能显示,别人电脑不显示,最可能原因是:A. 使用了本机绝对路径 B. 图片太大 C. 标题层级错误 D. 使用了有序列表 | |||
| 12. Markdown 页内跳转到标题失败,较可能的原因是:A. 锚点名称与渲染后的标题锚点不一致 B. 表格太长 C. 图片不存在 D. Git 分支过多 | |||
| 13. SourceInsight 中代码文件已经存在磁盘中,但工程中无法搜索到其中函数,最可能原因是:A. 文件未加入工程或符号表未同步 B. 文件名太短 C. Git 未提交 D. Markdown 未生成目录 | |||
| 14. SourceInsight 搜索引用结果明显不完整,优先处理方式是:A. 同步符号表并确认工程文件范围 B. 删除 Git 仓库 C. 改 VS 平台 D. 重新生成 DLL | |||
| 15. 在 SourceInsight 中,Project Window 和 Symbol Window 的区别更准确的是:A. 前者看工程文件结构,后者看符号 B. 前者看远程仓库,后者看 DLL C. 前者调试内存,后者创建补丁 D. 二者完全相同 | |||
| 16. 某同学把编译输出目录提交进 Git,最合适的改进是:A. 加入 `.gitignore` 并停止跟踪已提交文件 B. 删除 Git C. 只改文件名 D. 改 Markdown 标题 | |||
| 17. 在合并冲突文件中看到 `=======`,它通常用于:A. 分隔两边冲突内容 B. 表示表格标题 C. 表示代码块结束 D. 表示标签删除 | |||
| 18. SourceTree 中“丢弃”未提交修改前最应该确认:A. 这些修改确实不再需要 B. 是否已生成目录 C. 是否有 DLL D. 是否有书签 | |||
| 19. Git 标签和分支最核心的区别之一是:A. 标签通常固定指向某个版本,分支会随提交移动 B. 标签只能保存图片 C. 分支不能合并 D. 标签一定比分支新 | |||
| 20. Markdown 中想展示一段 C 代码并保留缩进,最合适的是:A. fenced code block B. 表格 C. 引用 D. 图片 | |||
| 21. SourceInsight 中 Relation Window 更适合辅助查看:A. 符号之间的关系 B. Git 远程地址 C. VS 库目录 D. IAR 链接文件 | |||
| 22. 如果 SourceTree 中显示本地分支 ahead 2,通常表示:A. 本地有 2 个提交尚未推送 B. 远程比本地多 2 个提交 C. 工作区有 2 个文件 D. 有 2 个冲突 | |||
| 23. 如果 SourceTree 中显示本地分支 behind 3,通常表示:A. 远程有 3 个提交本地还没有 B. 本地有 3 个提交未推送 C. 有 3 个标签 D. 有 3 个忽略文件 | |||
| 24. Markdown 中普通链接和图片链接最主要的语法差异是:A. 图片语法前面多一个 `!` B. 链接必须大写 C. 图片必须使用绝对路径 D. 链接不能使用括号 | |||
| 25. 对已跟踪的大文件想从 Git 跟踪中移除但保留本地文件,较合适的是:A. `git rm --cached` B. `git clone` C. `git tag` D. `git init` | |||
| ## 多选题 | |||
| 26. 下列哪些情况可能导致 Git 合并冲突?A. 两个分支修改同一文件同一位置 B. 一边删除文件另一边修改该文件 C. 多人修改同一逻辑区域 D. 只是查看日志 | |||
| 27. 下列哪些操作可能改写或移动分支历史?A. reset B. rebase C. commit D. checkout 到已有提交后创建分支 | |||
| 28. 下列关于 fetch 和 pull 的说法正确的是:A. fetch 获取远程信息 B. pull 通常包含 fetch 和合并/变基 C. fetch 不一定改变工作区代码 D. pull 可能产生冲突 | |||
| 29. 下列哪些内容适合加入 `.gitignore`?A. 编译输出目录 B. 临时文件 C. 用户本地 IDE 缓存 D. 项目必要源码 | |||
| 30. 下列哪些属于 SourceTree 中需要谨慎使用的操作?A. 硬重置 B. 丢弃修改 C. 删除分支 D. 强制推送相关操作 | |||
| 31. 下列关于补丁的说法正确的是:A. 可以保存一组修改 B. 可以用于代码传递 C. 应用时可能冲突 D. 永远不需要检查内容 | |||
| 32. Markdown 图片显示失败可能原因包括:A. 路径错误 B. 图片文件不存在 C. 使用了本机绝对路径 D. 文件名大小写或字符不一致 | |||
| 33. Markdown 页内跳转可以基于:A. 标题生成的锚点 B. 自定义 HTML id C. 目录链接 D. 随机中文字符串且不匹配任何锚点 | |||
| 34. SourceInsight 搜索引用依赖哪些条件?A. 文件加入工程 B. 符号表同步 C. 搜索范围正确 D. 代码能被工具解析 | |||
| 35. SourceInsight 常用窗口中,可能用于代码结构或符号查看的有:A. Project Window B. Symbol Window C. Project Symbol List D. Relation Window | |||
| 36. 下列哪些属于 Git 三个主要本地区域相关概念?A. 工作区 B. 暂存区 C. 本地仓库 D. 远程服务器机房 | |||
| 37. 下列哪些情况适合使用 stash?A. 当前修改未完成但需要切换分支 B. 拉取前临时保存本地修改 C. 暂时搁置实验性修改 D. 发布正式版本标签 | |||
| 38. 下列哪些操作完成后通常需要再次提交?A. 解决合并冲突 B. 修改冲突文件 C. 回滚产生新修改 D. 仅查看日志 | |||
| 39. 下列关于标签的说法正确的是:A. 可标记版本 B. 可推送到远程 C. 可删除 D. 通常不随新提交自动移动 | |||
| 40. Markdown 文档验收时比较重要的是:A. 结构清晰 B. 图片可打开 C. 路径相对 D. 内容覆盖要求 | |||
| 41. SourceTree 分支图可以帮助判断:A. 提交先后关系 B. 分支合并情况 C. 分支分叉位置 D. C 代码语法是否正确 | |||
| 42. 下列哪些属于 SourceInsight 视图切换或窗口管理内容?A. 水平平铺 B. 垂直平铺 C. 层叠窗口 D. 全屏显示 | |||
| 43. Git reset 的不同模式可能影响:A. 分支指针 B. 暂存区 C. 工作区 D. 远程仓库一定同步 | |||
| 44. 下列关于回滚提交的说法正确的是:A. 会产生新的反向提交 B. 适合保留历史 C. 团队协作中较安全 D. 必然删除原提交 | |||
| 45. 下列哪些属于 Markdown 文本组织能力?A. 标题层级 B. 列表 C. 表格 D. 引用 | |||
| ## 判断题 | |||
| 46. fetch 后本地当前分支代码一定立即变化。 | |||
| 47. pull 可能触发冲突。 | |||
| 48. 已经被 Git 跟踪的文件,不会因为写入 `.gitignore` 就自动停止跟踪。 | |||
| 49. hard reset 使用不当可能丢失本地修改。 | |||
| 50. revert 通常通过新提交撤销旧提交影响。 | |||
| 51. rebase 永远不会产生冲突。 | |||
| 52. SourceTree 中丢弃修改前应确认修改不再需要。 | |||
| 53. Markdown 使用本机绝对图片路径更适合团队提交。 | |||
| 54. Markdown 中三个反引号可以用于多行代码块。 | |||
| 55. SourceInsight 符号表同步与搜索引用结果可能有关。 | |||
| 56. SourceInsight 中工程没有加入某文件,也可能导致该文件里的符号搜索不到。 | |||
| 57. 标签通常适合标记重要版本节点。 | |||
| 58. Git 分支只能创建,不能删除。 | |||
| 59. 补丁应用前最好确认当前代码状态。 | |||
| 60. 只会背命令,不理解操作影响,也能稳定处理所有冲突。 | |||
| ## 答案 | |||
| 1.A 2.A 3.A 4.A 5.A 6.A 7.A 8.A 9.A 10.A | |||
| 11.A 12.A 13.A 14.A 15.A 16.A 17.A 18.A 19.A 20.A | |||
| 21.A 22.A 23.A 24.A 25.A | |||
| 26.ABC 27.AB 28.ABCD 29.ABC 30.ABCD 31.ABC 32.ABCD 33.ABC 34.ABCD 35.ABCD | |||
| 36.ABC 37.ABC 38.ABC 39.ABCD 40.ABCD 41.ABC 42.ABCD 43.ABC 44.ABC 45.ABCD | |||
| 46.错 47.对 48.对 49.对 50.对 51.错 52.对 53.错 54.对 55.对 | |||
| 56.对 57.对 58.错 59.对 60.错 | |||
| ## 高难拓展题 | |||
| ### 单选题 | |||
| 61. 场景61:目录跳转时,已跟踪文件加入忽略规则后仍显示修改,最合理的判断是:A. 先取消跟踪或从索引移除,再依靠忽略规则避免后续纳入 B. 反复提交空提交 C. 删除整个远程仓库 D. 把文件改成图片格式 | |||
| 62. 场景62:标签发布时,fetch 后远程分支更新但当前文件未变化,最合理的判断是:A. fetch 只适用于标签 B. fetch 只更新远程跟踪信息,是否合并取决于后续操作 C. fetch 会自动硬重置本地 D. fetch 会删除本地提交 | |||
| 63. 场景63:提交拆分时,pull 前工作区有未提交修改,最合理的判断是:A. 先改 Markdown 标题 B. 只新建标签即可 C. 先确认、提交或贮藏本地修改,避免合并时相互影响 D. 直接删除工作区 | |||
| 64. 场景64:工程维护时,公共分支上想撤销已推送提交,最合理的判断是:A. 优先 hard reset 后强推 B. 删除 .gitignore C. 重新安装 SourceTree D. 优先考虑 revert,保留历史并生成反向提交 | |||
| 65. 场景65:操作验收时,合并冲突文件出现冲突标记,最合理的判断是:A. 人工选择和整理最终内容,再标记解决并提交 B. 保留所有冲突标记 C. 把文件加入 .gitignore D. 只执行 fetch | |||
| 66. 场景66:远程同步前,stash pop 后出现冲突,最合理的判断是:A. 删除所有分支 B. 解决冲突并确认贮藏处理状态 C. 说明仓库必然损坏 D. 只需关闭编辑器 | |||
| 67. 场景67:版本回退时,format-patch 与普通 diff 补丁的区别,最合理的判断是:A. 普通 diff 会生成 DLL B. format-patch 只能用于 Markdown C. format-patch 更强调提交信息,git am 可按提交应用 D. 二者完全等同且都不能应用 | |||
| 68. 场景68:文档验收时,标签被用于版本发布,最合理的判断是:A. 标签会随分支自动前进 B. 标签只能标记图片 C. 标签会清空工作区 D. 标签通常固定指向某个提交,适合标记里程碑 | |||
| 69. 场景69:分支切换前,Markdown 图片换电脑不显示,最合理的判断是:A. 优先检查是否使用本机绝对路径以及图片是否随文档提交 B. 把标题改成一级即可 C. 执行 git pull 一定修复 D. 改成有序列表即可 | |||
| 70. 场景70:代码阅读时,Markdown 页内跳转失败,最合理的判断是:A. 把表格改成引用 B. 检查目标锚点与链接中的 id 或标题锚点是否一致 C. 删除所有图片 D. 创建 Git 分支 | |||
| 71. 场景71:目录跳转时,SourceInsight 添加源码后跳转不完整,最合理的判断是:A. 修改 VS 平台 B. 删除 Markdown 目录 C. 同步符号表并确认文件已加入工程范围 D. 执行 git push | |||
| 72. 场景72:标签发布时,SourceInsight 搜索宏引用不全,最合理的判断是:A. 只修改图片路径 B. 只创建标签 C. 只运行单元测试 D. 检查符号表、搜索范围以及宏所在文件是否被解析 | |||
| 73. 场景73:提交拆分时,SourceTree 显示 ahead,最合理的判断是:A. 表示本地有提交尚未推送到远程 B. 表示远程有提交未拉取 C. 表示工作区无修改 D. 表示仓库没有分支 | |||
| 74. 场景74:工程维护时,SourceTree 显示 behind,最合理的判断是:A. 表示 Markdown 语法错误 B. 表示远程有提交本地尚未合入 C. 表示本地提交未推送 D. 表示补丁应用成功 | |||
| 75. 场景75:操作验收时,hard reset 前的风险判断,最合理的判断是:A. 只影响远程仓库 B. 只影响图片显示 C. 确认目标提交和未保存修改,因为可能丢弃工作区内容 D. 不用确认任何状态 | |||
| 76. 场景76:远程同步前,git rm --cached 的典型用途,最合理的判断是:A. 删除远程仓库 B. 创建补丁 C. 合并分支 D. 停止跟踪但保留本地文件 | |||
| 77. 场景77:版本回退时,rebase 后提交历史变化,最合理的判断是:A. 可能改写提交基底,使历史更线性但需注意协作风险 B. 一定不会冲突 C. 一定删除所有标签 D. 只会改变 Markdown | |||
| 78. 场景78:文档验收时,SourceInsight Project Window 与 Symbol Window 区别,最合理的判断是:A. 后者用于 Git 推送 B. 前者偏工程文件结构,后者偏符号浏览 C. 二者完全一样 D. 前者用于单元测试 | |||
| 79. 场景79:分支切换前,Markdown 表格渲染异常,最合理的判断是:A. 禁用断点 B. 生成静态库 C. 检查竖线、表头分隔行和单元格格式 D. 创建远程仓库 | |||
| 80. 场景80:代码阅读时,提交前发现混入无关文件,最合理的判断是:A. 强制全部提交 B. 删除历史 C. 改文件后缀 D. 取消暂存无关文件或拆分提交,保持提交粒度清晰 | |||
| 81. 场景81:目录跳转时,已跟踪文件加入忽略规则后仍显示修改,最合理的判断是:A. 先取消跟踪或从索引移除,再依靠忽略规则避免后续纳入 B. 反复提交空提交 C. 删除整个远程仓库 D. 把文件改成图片格式 | |||
| 82. 场景82:标签发布时,fetch 后远程分支更新但当前文件未变化,最合理的判断是:A. fetch 只适用于标签 B. fetch 只更新远程跟踪信息,是否合并取决于后续操作 C. fetch 会自动硬重置本地 D. fetch 会删除本地提交 | |||
| 83. 场景83:提交拆分时,pull 前工作区有未提交修改,最合理的判断是:A. 先改 Markdown 标题 B. 只新建标签即可 C. 先确认、提交或贮藏本地修改,避免合并时相互影响 D. 直接删除工作区 | |||
| 84. 场景84:工程维护时,公共分支上想撤销已推送提交,最合理的判断是:A. 优先 hard reset 后强推 B. 删除 .gitignore C. 重新安装 SourceTree D. 优先考虑 revert,保留历史并生成反向提交 | |||
| 85. 场景85:操作验收时,合并冲突文件出现冲突标记,最合理的判断是:A. 人工选择和整理最终内容,再标记解决并提交 B. 保留所有冲突标记 C. 把文件加入 .gitignore D. 只执行 fetch | |||
| 86. 场景86:远程同步前,stash pop 后出现冲突,最合理的判断是:A. 删除所有分支 B. 解决冲突并确认贮藏处理状态 C. 说明仓库必然损坏 D. 只需关闭编辑器 | |||
| 87. 场景87:版本回退时,format-patch 与普通 diff 补丁的区别,最合理的判断是:A. 普通 diff 会生成 DLL B. format-patch 只能用于 Markdown C. format-patch 更强调提交信息,git am 可按提交应用 D. 二者完全等同且都不能应用 | |||
| 88. 场景88:文档验收时,标签被用于版本发布,最合理的判断是:A. 标签会随分支自动前进 B. 标签只能标记图片 C. 标签会清空工作区 D. 标签通常固定指向某个提交,适合标记里程碑 | |||
| 89. 场景89:分支切换前,Markdown 图片换电脑不显示,最合理的判断是:A. 优先检查是否使用本机绝对路径以及图片是否随文档提交 B. 把标题改成一级即可 C. 执行 git pull 一定修复 D. 改成有序列表即可 | |||
| 90. 场景90:代码阅读时,Markdown 页内跳转失败,最合理的判断是:A. 把表格改成引用 B. 检查目标锚点与链接中的 id 或标题锚点是否一致 C. 删除所有图片 D. 创建 Git 分支 | |||
| 91. 场景91:目录跳转时,SourceInsight 添加源码后跳转不完整,最合理的判断是:A. 修改 VS 平台 B. 删除 Markdown 目录 C. 同步符号表并确认文件已加入工程范围 D. 执行 git push | |||
| 92. 场景92:标签发布时,SourceInsight 搜索宏引用不全,最合理的判断是:A. 只修改图片路径 B. 只创建标签 C. 只运行单元测试 D. 检查符号表、搜索范围以及宏所在文件是否被解析 | |||
| 93. 场景93:提交拆分时,SourceTree 显示 ahead,最合理的判断是:A. 表示本地有提交尚未推送到远程 B. 表示远程有提交未拉取 C. 表示工作区无修改 D. 表示仓库没有分支 | |||
| 94. 场景94:工程维护时,SourceTree 显示 behind,最合理的判断是:A. 表示 Markdown 语法错误 B. 表示远程有提交本地尚未合入 C. 表示本地提交未推送 D. 表示补丁应用成功 | |||
| 95. 场景95:操作验收时,hard reset 前的风险判断,最合理的判断是:A. 只影响远程仓库 B. 只影响图片显示 C. 确认目标提交和未保存修改,因为可能丢弃工作区内容 D. 不用确认任何状态 | |||
| 96. 场景96:远程同步前,git rm --cached 的典型用途,最合理的判断是:A. 删除远程仓库 B. 创建补丁 C. 合并分支 D. 停止跟踪但保留本地文件 | |||
| 97. 场景97:版本回退时,rebase 后提交历史变化,最合理的判断是:A. 可能改写提交基底,使历史更线性但需注意协作风险 B. 一定不会冲突 C. 一定删除所有标签 D. 只会改变 Markdown | |||
| 98. 场景98:文档验收时,SourceInsight Project Window 与 Symbol Window 区别,最合理的判断是:A. 后者用于 Git 推送 B. 前者偏工程文件结构,后者偏符号浏览 C. 二者完全一样 D. 前者用于单元测试 | |||
| 99. 场景99:分支切换前,Markdown 表格渲染异常,最合理的判断是:A. 禁用断点 B. 生成静态库 C. 检查竖线、表头分隔行和单元格格式 D. 创建远程仓库 | |||
| 100. 场景100:代码阅读时,提交前发现混入无关文件,最合理的判断是:A. 强制全部提交 B. 删除历史 C. 改文件后缀 D. 取消暂存无关文件或拆分提交,保持提交粒度清晰 | |||
| 101. 场景101:目录跳转时,已跟踪文件加入忽略规则后仍显示修改,最合理的判断是:A. 先取消跟踪或从索引移除,再依靠忽略规则避免后续纳入 B. 反复提交空提交 C. 删除整个远程仓库 D. 把文件改成图片格式 | |||
| 102. 场景102:标签发布时,fetch 后远程分支更新但当前文件未变化,最合理的判断是:A. fetch 只适用于标签 B. fetch 只更新远程跟踪信息,是否合并取决于后续操作 C. fetch 会自动硬重置本地 D. fetch 会删除本地提交 | |||
| 103. 场景103:提交拆分时,pull 前工作区有未提交修改,最合理的判断是:A. 先改 Markdown 标题 B. 只新建标签即可 C. 先确认、提交或贮藏本地修改,避免合并时相互影响 D. 直接删除工作区 | |||
| 104. 场景104:工程维护时,公共分支上想撤销已推送提交,最合理的判断是:A. 优先 hard reset 后强推 B. 删除 .gitignore C. 重新安装 SourceTree D. 优先考虑 revert,保留历史并生成反向提交 | |||
| 105. 场景105:操作验收时,合并冲突文件出现冲突标记,最合理的判断是:A. 人工选择和整理最终内容,再标记解决并提交 B. 保留所有冲突标记 C. 把文件加入 .gitignore D. 只执行 fetch | |||
| 106. 场景106:远程同步前,stash pop 后出现冲突,最合理的判断是:A. 删除所有分支 B. 解决冲突并确认贮藏处理状态 C. 说明仓库必然损坏 D. 只需关闭编辑器 | |||
| 107. 场景107:版本回退时,format-patch 与普通 diff 补丁的区别,最合理的判断是:A. 普通 diff 会生成 DLL B. format-patch 只能用于 Markdown C. format-patch 更强调提交信息,git am 可按提交应用 D. 二者完全等同且都不能应用 | |||
| 108. 场景108:文档验收时,标签被用于版本发布,最合理的判断是:A. 标签会随分支自动前进 B. 标签只能标记图片 C. 标签会清空工作区 D. 标签通常固定指向某个提交,适合标记里程碑 | |||
| 109. 场景109:分支切换前,Markdown 图片换电脑不显示,最合理的判断是:A. 优先检查是否使用本机绝对路径以及图片是否随文档提交 B. 把标题改成一级即可 C. 执行 git pull 一定修复 D. 改成有序列表即可 | |||
| 110. 场景110:代码阅读时,Markdown 页内跳转失败,最合理的判断是:A. 把表格改成引用 B. 检查目标锚点与链接中的 id 或标题锚点是否一致 C. 删除所有图片 D. 创建 Git 分支 | |||
| 111. 场景111:目录跳转时,SourceInsight 添加源码后跳转不完整,最合理的判断是:A. 修改 VS 平台 B. 删除 Markdown 目录 C. 同步符号表并确认文件已加入工程范围 D. 执行 git push | |||
| 112. 场景112:标签发布时,SourceInsight 搜索宏引用不全,最合理的判断是:A. 只修改图片路径 B. 只创建标签 C. 只运行单元测试 D. 检查符号表、搜索范围以及宏所在文件是否被解析 | |||
| 113. 场景113:提交拆分时,SourceTree 显示 ahead,最合理的判断是:A. 表示本地有提交尚未推送到远程 B. 表示远程有提交未拉取 C. 表示工作区无修改 D. 表示仓库没有分支 | |||
| 114. 场景114:工程维护时,SourceTree 显示 behind,最合理的判断是:A. 表示 Markdown 语法错误 B. 表示远程有提交本地尚未合入 C. 表示本地提交未推送 D. 表示补丁应用成功 | |||
| 115. 场景115:操作验收时,hard reset 前的风险判断,最合理的判断是:A. 只影响远程仓库 B. 只影响图片显示 C. 确认目标提交和未保存修改,因为可能丢弃工作区内容 D. 不用确认任何状态 | |||
| 116. 场景116:远程同步前,git rm --cached 的典型用途,最合理的判断是:A. 删除远程仓库 B. 创建补丁 C. 合并分支 D. 停止跟踪但保留本地文件 | |||
| 117. 场景117:版本回退时,rebase 后提交历史变化,最合理的判断是:A. 可能改写提交基底,使历史更线性但需注意协作风险 B. 一定不会冲突 C. 一定删除所有标签 D. 只会改变 Markdown | |||
| 118. 场景118:文档验收时,SourceInsight Project Window 与 Symbol Window 区别,最合理的判断是:A. 后者用于 Git 推送 B. 前者偏工程文件结构,后者偏符号浏览 C. 二者完全一样 D. 前者用于单元测试 | |||
| 119. 场景119:分支切换前,Markdown 表格渲染异常,最合理的判断是:A. 禁用断点 B. 生成静态库 C. 检查竖线、表头分隔行和单元格格式 D. 创建远程仓库 | |||
| 120. 场景120:代码阅读时,提交前发现混入无关文件,最合理的判断是:A. 强制全部提交 B. 删除历史 C. 改文件后缀 D. 取消暂存无关文件或拆分提交,保持提交粒度清晰 | |||
| 121. 场景121:目录跳转时,已跟踪文件加入忽略规则后仍显示修改,最合理的判断是:A. 先取消跟踪或从索引移除,再依靠忽略规则避免后续纳入 B. 反复提交空提交 C. 删除整个远程仓库 D. 把文件改成图片格式 | |||
| 122. 场景122:标签发布时,fetch 后远程分支更新但当前文件未变化,最合理的判断是:A. fetch 只适用于标签 B. fetch 只更新远程跟踪信息,是否合并取决于后续操作 C. fetch 会自动硬重置本地 D. fetch 会删除本地提交 | |||
| 123. 场景123:提交拆分时,pull 前工作区有未提交修改,最合理的判断是:A. 先改 Markdown 标题 B. 只新建标签即可 C. 先确认、提交或贮藏本地修改,避免合并时相互影响 D. 直接删除工作区 | |||
| 124. 场景124:工程维护时,公共分支上想撤销已推送提交,最合理的判断是:A. 优先 hard reset 后强推 B. 删除 .gitignore C. 重新安装 SourceTree D. 优先考虑 revert,保留历史并生成反向提交 | |||
| 125. 场景125:操作验收时,合并冲突文件出现冲突标记,最合理的判断是:A. 人工选择和整理最终内容,再标记解决并提交 B. 保留所有冲突标记 C. 把文件加入 .gitignore D. 只执行 fetch | |||
| 126. 场景126:远程同步前,stash pop 后出现冲突,最合理的判断是:A. 删除所有分支 B. 解决冲突并确认贮藏处理状态 C. 说明仓库必然损坏 D. 只需关闭编辑器 | |||
| 127. 场景127:版本回退时,format-patch 与普通 diff 补丁的区别,最合理的判断是:A. 普通 diff 会生成 DLL B. format-patch 只能用于 Markdown C. format-patch 更强调提交信息,git am 可按提交应用 D. 二者完全等同且都不能应用 | |||
| 128. 场景128:文档验收时,标签被用于版本发布,最合理的判断是:A. 标签会随分支自动前进 B. 标签只能标记图片 C. 标签会清空工作区 D. 标签通常固定指向某个提交,适合标记里程碑 | |||
| 129. 场景129:分支切换前,Markdown 图片换电脑不显示,最合理的判断是:A. 优先检查是否使用本机绝对路径以及图片是否随文档提交 B. 把标题改成一级即可 C. 执行 git pull 一定修复 D. 改成有序列表即可 | |||
| 130. 场景130:代码阅读时,Markdown 页内跳转失败,最合理的判断是:A. 把表格改成引用 B. 检查目标锚点与链接中的 id 或标题锚点是否一致 C. 删除所有图片 D. 创建 Git 分支 | |||
| ### 多选题 | |||
| 131. 场景131:临时插单时,导致冲突的情况,正确的有:A. 两个分支改同一行 B. 一边删除一边修改同一文件 C. 多人改同一逻辑块 D. 以上说法都不需要关注 | |||
| 132. 场景132:引用搜索时,拉取前应确认,正确的有:A. 当前分支 B. 工作区是否干净 C. 与该场景无关的图片格式 D. 显示器亮度 | |||
| 133. 场景133:复习自测时,Markdown 图片稳定显示需要,正确的有:A. 相对路径 B. 只重启软件即可 C. 文件名一致 D. 本机桌面绝对路径 | |||
| 134. 场景134:文档提交前,SourceInsight 搜索引用可靠性依赖,正确的有:A. 完全不需要检查当前配置 B. 符号表同步 C. 搜索范围正确 D. 工程源码可解析 | |||
| 135. 场景135:冲突处理时,适合忽略的文件,正确的有:A. 编译输出 B. 临时文件 C. 本地 IDE 缓存 D. 核心源码 | |||
| 136. 场景136:补丁交付时,补丁应用失败可能原因,正确的有:A. 代码上下文不匹配 B. 当前分支不对 C. 已有冲突 D. 以上说法都不需要关注 | |||
| 137. 场景137:多人协作时,Git 历史视图可帮助判断,正确的有:A. 提交顺序 B. 分支分叉 C. 与该场景无关的图片格式 D. C 语言语法正确性 | |||
| 138. 场景138:历史整理时,文档验收应关注,正确的有:A. 范围覆盖 B. 只重启软件即可 C. 路径可迁移 D. 结构清楚 | |||
| 139. 场景139:图片迁移时,危险操作前应确认,正确的有:A. 完全不需要检查当前配置 B. 是否有未提交修改 C. 是否影响公共历史 D. 是否更换主题 | |||
| 140. 场景140:文件忽略时,SourceTree 可执行的 Git 操作,正确的有:A. 提交 B. 拉取 C. 推送 D. 分支合并 | |||
| 141. 场景141:临时插单时,导致冲突的情况,正确的有:A. 两个分支改同一行 B. 一边删除一边修改同一文件 C. 多人改同一逻辑块 D. 以上说法都不需要关注 | |||
| 142. 场景142:引用搜索时,拉取前应确认,正确的有:A. 当前分支 B. 工作区是否干净 C. 与该场景无关的图片格式 D. 显示器亮度 | |||
| 143. 场景143:复习自测时,Markdown 图片稳定显示需要,正确的有:A. 相对路径 B. 只重启软件即可 C. 文件名一致 D. 本机桌面绝对路径 | |||
| 144. 场景144:文档提交前,SourceInsight 搜索引用可靠性依赖,正确的有:A. 完全不需要检查当前配置 B. 符号表同步 C. 搜索范围正确 D. 工程源码可解析 | |||
| 145. 场景145:冲突处理时,适合忽略的文件,正确的有:A. 编译输出 B. 临时文件 C. 本地 IDE 缓存 D. 核心源码 | |||
| 146. 场景146:补丁交付时,补丁应用失败可能原因,正确的有:A. 代码上下文不匹配 B. 当前分支不对 C. 已有冲突 D. 以上说法都不需要关注 | |||
| 147. 场景147:多人协作时,Git 历史视图可帮助判断,正确的有:A. 提交顺序 B. 分支分叉 C. 与该场景无关的图片格式 D. C 语言语法正确性 | |||
| 148. 场景148:历史整理时,文档验收应关注,正确的有:A. 范围覆盖 B. 只重启软件即可 C. 路径可迁移 D. 结构清楚 | |||
| 149. 场景149:图片迁移时,危险操作前应确认,正确的有:A. 完全不需要检查当前配置 B. 是否有未提交修改 C. 是否影响公共历史 D. 是否更换主题 | |||
| 150. 场景150:文件忽略时,SourceTree 可执行的 Git 操作,正确的有:A. 提交 B. 拉取 C. 推送 D. 分支合并 | |||
| 151. 场景151:临时插单时,导致冲突的情况,正确的有:A. 两个分支改同一行 B. 一边删除一边修改同一文件 C. 多人改同一逻辑块 D. 以上说法都不需要关注 | |||
| 152. 场景152:引用搜索时,拉取前应确认,正确的有:A. 当前分支 B. 工作区是否干净 C. 与该场景无关的图片格式 D. 显示器亮度 | |||
| 153. 场景153:复习自测时,Markdown 图片稳定显示需要,正确的有:A. 相对路径 B. 只重启软件即可 C. 文件名一致 D. 本机桌面绝对路径 | |||
| 154. 场景154:文档提交前,SourceInsight 搜索引用可靠性依赖,正确的有:A. 完全不需要检查当前配置 B. 符号表同步 C. 搜索范围正确 D. 工程源码可解析 | |||
| 155. 场景155:冲突处理时,适合忽略的文件,正确的有:A. 编译输出 B. 临时文件 C. 本地 IDE 缓存 D. 核心源码 | |||
| 156. 场景156:补丁交付时,补丁应用失败可能原因,正确的有:A. 代码上下文不匹配 B. 当前分支不对 C. 已有冲突 D. 以上说法都不需要关注 | |||
| 157. 场景157:多人协作时,Git 历史视图可帮助判断,正确的有:A. 提交顺序 B. 分支分叉 C. 与该场景无关的图片格式 D. C 语言语法正确性 | |||
| 158. 场景158:历史整理时,文档验收应关注,正确的有:A. 范围覆盖 B. 只重启软件即可 C. 路径可迁移 D. 结构清楚 | |||
| 159. 场景159:图片迁移时,危险操作前应确认,正确的有:A. 完全不需要检查当前配置 B. 是否有未提交修改 C. 是否影响公共历史 D. 是否更换主题 | |||
| 160. 场景160:文件忽略时,SourceTree 可执行的 Git 操作,正确的有:A. 提交 B. 拉取 C. 推送 D. 分支合并 | |||
| 161. 场景161:临时插单时,导致冲突的情况,正确的有:A. 两个分支改同一行 B. 一边删除一边修改同一文件 C. 多人改同一逻辑块 D. 以上说法都不需要关注 | |||
| 162. 场景162:引用搜索时,拉取前应确认,正确的有:A. 当前分支 B. 工作区是否干净 C. 与该场景无关的图片格式 D. 显示器亮度 | |||
| 163. 场景163:复习自测时,Markdown 图片稳定显示需要,正确的有:A. 相对路径 B. 只重启软件即可 C. 文件名一致 D. 本机桌面绝对路径 | |||
| 164. 场景164:文档提交前,SourceInsight 搜索引用可靠性依赖,正确的有:A. 完全不需要检查当前配置 B. 符号表同步 C. 搜索范围正确 D. 工程源码可解析 | |||
| 165. 场景165:冲突处理时,适合忽略的文件,正确的有:A. 编译输出 B. 临时文件 C. 本地 IDE 缓存 D. 核心源码 | |||
| 166. 场景166:补丁交付时,补丁应用失败可能原因,正确的有:A. 代码上下文不匹配 B. 当前分支不对 C. 已有冲突 D. 以上说法都不需要关注 | |||
| 167. 场景167:多人协作时,Git 历史视图可帮助判断,正确的有:A. 提交顺序 B. 分支分叉 C. 与该场景无关的图片格式 D. C 语言语法正确性 | |||
| 168. 场景168:历史整理时,文档验收应关注,正确的有:A. 范围覆盖 B. 只重启软件即可 C. 路径可迁移 D. 结构清楚 | |||
| 169. 场景169:图片迁移时,危险操作前应确认,正确的有:A. 完全不需要检查当前配置 B. 是否有未提交修改 C. 是否影响公共历史 D. 是否更换主题 | |||
| 170. 场景170:文件忽略时,SourceTree 可执行的 Git 操作,正确的有:A. 提交 B. 拉取 C. 推送 D. 分支合并 | |||
| 171. 场景171:临时插单时,导致冲突的情况,正确的有:A. 两个分支改同一行 B. 一边删除一边修改同一文件 C. 多人改同一逻辑块 D. 以上说法都不需要关注 | |||
| 172. 场景172:引用搜索时,拉取前应确认,正确的有:A. 当前分支 B. 工作区是否干净 C. 与该场景无关的图片格式 D. 显示器亮度 | |||
| 173. 场景173:复习自测时,Markdown 图片稳定显示需要,正确的有:A. 相对路径 B. 只重启软件即可 C. 文件名一致 D. 本机桌面绝对路径 | |||
| 174. 场景174:文档提交前,SourceInsight 搜索引用可靠性依赖,正确的有:A. 完全不需要检查当前配置 B. 符号表同步 C. 搜索范围正确 D. 工程源码可解析 | |||
| 175. 场景175:冲突处理时,适合忽略的文件,正确的有:A. 编译输出 B. 临时文件 C. 本地 IDE 缓存 D. 核心源码 | |||
| 176. 场景176:补丁交付时,补丁应用失败可能原因,正确的有:A. 代码上下文不匹配 B. 当前分支不对 C. 已有冲突 D. 以上说法都不需要关注 | |||
| 177. 场景177:多人协作时,Git 历史视图可帮助判断,正确的有:A. 提交顺序 B. 分支分叉 C. 与该场景无关的图片格式 D. C 语言语法正确性 | |||
| 178. 场景178:历史整理时,文档验收应关注,正确的有:A. 范围覆盖 B. 只重启软件即可 C. 路径可迁移 D. 结构清楚 | |||
| 179. 场景179:图片迁移时,危险操作前应确认,正确的有:A. 完全不需要检查当前配置 B. 是否有未提交修改 C. 是否影响公共历史 D. 是否更换主题 | |||
| 180. 场景180:文件忽略时,SourceTree 可执行的 Git 操作,正确的有:A. 提交 B. 拉取 C. 推送 D. 分支合并 | |||
| ### 判断题 | |||
| 181. 场景181:工程维护时,fetch 不一定改变当前工作区文件。 | |||
| 182. 场景182:操作验收时,pull 永远不会产生冲突。 | |||
| 183. 场景183:远程同步前,revert 通常通过新提交撤销旧提交影响。 | |||
| 184. 场景184:版本回退时,hard reset 对工作区永远没有风险。 | |||
| 185. 场景185:文档验收时,Markdown 相对路径更适合提交共享。 | |||
| 186. 场景186:分支切换前,hard reset 对工作区永远没有风险。 | |||
| 187. 场景187:代码阅读时,SourceInsight 符号表状态会影响跳转体验。 | |||
| 188. 场景188:目录跳转时,Markdown 图片必须使用本机绝对路径才稳定。 | |||
| 189. 场景189:标签发布时,解决冲突后通常需要再次提交。 | |||
| 190. 场景190:提交拆分时,Markdown 图片必须使用本机绝对路径才稳定。 | |||
| 191. 场景191:工程维护时,标签适合标记发布版本。 | |||
| 192. 场景192:操作验收时,冲突标记可以直接保留进最终代码。 | |||
| 193. 场景193:远程同步前,stash 可用于临时保存未提交修改。 | |||
| 194. 场景194:版本回退时,冲突标记可以直接保留进最终代码。 | |||
| 195. 场景195:文档验收时,提交前检查 diff 有助于避免误提交。 | |||
| 196. 场景196:分支切换前, | |||
| 197. 场景197:代码阅读时,fetch 不一定改变当前工作区文件。 | |||
| 198. 场景198:目录跳转时,pull 永远不会产生冲突。 | |||
| 199. 场景199:标签发布时,revert 通常通过新提交撤销旧提交影响。 | |||
| 200. 场景200:提交拆分时,hard reset 对工作区永远没有风险。 | |||
| 201. 场景201:工程维护时,Markdown 相对路径更适合提交共享。 | |||
| 202. 场景202:操作验收时,hard reset 对工作区永远没有风险。 | |||
| 203. 场景203:远程同步前,SourceInsight 符号表状态会影响跳转体验。 | |||
| 204. 场景204:版本回退时,Markdown 图片必须使用本机绝对路径才稳定。 | |||
| 205. 场景205:文档验收时,解决冲突后通常需要再次提交。 | |||
| 206. 场景206:分支切换前,Markdown 图片必须使用本机绝对路径才稳定。 | |||
| 207. 场景207:代码阅读时,标签适合标记发布版本。 | |||
| 208. 场景208:目录跳转时,冲突标记可以直接保留进最终代码。 | |||
| 209. 场景209:标签发布时,stash 可用于临时保存未提交修改。 | |||
| 210. 场景210:提交拆分时,冲突标记可以直接保留进最终代码。 | |||
| 211. 场景211:工程维护时,提交前检查 diff 有助于避免误提交。 | |||
| 212. 场景212:操作验收时, | |||
| 213. 场景213:远程同步前,fetch 不一定改变当前工作区文件。 | |||
| 214. 场景214:版本回退时,pull 永远不会产生冲突。 | |||
| 215. 场景215:文档验收时,revert 通常通过新提交撤销旧提交影响。 | |||
| 216. 场景216:分支切换前,hard reset 对工作区永远没有风险。 | |||
| 217. 场景217:代码阅读时,Markdown 相对路径更适合提交共享。 | |||
| 218. 场景218:目录跳转时,hard reset 对工作区永远没有风险。 | |||
| 219. 场景219:标签发布时,SourceInsight 符号表状态会影响跳转体验。 | |||
| 220. 场景220:提交拆分时,Markdown 图片必须使用本机绝对路径才稳定。 | |||
| ## 高难拓展题答案 | |||
| 61.A 62.B 63.C 64.D 65.A 66.B 67.C 68.D 69.A 70.B | |||
| 71.C 72.D 73.A 74.B 75.C 76.D 77.A 78.B 79.C 80.D | |||
| 81.A 82.B 83.C 84.D 85.A 86.B 87.C 88.D 89.A 90.B | |||
| 91.C 92.D 93.A 94.B 95.C 96.D 97.A 98.B 99.C 100.D | |||
| 101.A 102.B 103.C 104.D 105.A 106.B 107.C 108.D 109.A 110.B | |||
| 111.C 112.D 113.A 114.B 115.C 116.D 117.A 118.B 119.C 120.D | |||
| 121.A 122.B 123.C 124.D 125.A 126.B 127.C 128.D 129.A 130.B | |||
| 131.ABC 132.ABD 133.ACD 134.BCD 135.ABCD 136.ABC 137.ABD 138.ACD | |||
| 139.BCD 140.ABCD 141.ABC 142.ABD 143.ACD 144.BCD 145.ABCD 146.ABC | |||
| 147.ABD 148.ACD 149.BCD 150.ABCD 151.ABC 152.ABD 153.ACD 154.BCD | |||
| 155.ABCD 156.ABC 157.ABD 158.ACD 159.BCD 160.ABCD 161.ABC 162.ABD | |||
| 163.ACD 164.BCD 165.ABCD 166.ABC 167.ABD 168.ACD 169.BCD 170.ABCD | |||
| 171.ABC 172.ABD 173.ACD 174.BCD 175.ABCD 176.ABC 177.ABD 178.ACD | |||
| 179.BCD 180.ABCD | |||
| 181.对 182.错 183.对 184.错 185.对 186.错 187.对 188.错 189.对 190.错 | |||
| 191.对 192.错 193.对 194.错 195.对 196.错 197.对 198.错 199.对 200.错 | |||
| 201.对 202.错 203.对 204.错 205.对 206.错 207.对 208.错 209.对 210.错 | |||
| 211.对 212.错 213.对 214.错 215.对 216.错 217.对 218.错 219.对 220.错 | |||