[Blog][Domain] programb.blog.csdn.net

| **实施阶段** | 贯穿整个开发生命周期，尤其在编码前的需求与设计阶段 | 主要在编码完成后进行（单元测试除外） || **成本效益** | 成本低、效率高，越早发现问题修复代价越小 | 相对成本较高，尤其是后期才发现重大缺陷 || **参与者** | 项目经理、需求分析师、开发人员、测试人员、用户代表等 | 测试工程师、自动化测试工具、测试环境 || **示例活动** | 走查（Walkthrough）、技术评审（Technical Review）、审查（Inspection） | 单元测试、

- **打勾评审制**：在每次发布前由QA、开发、产品共同核对。- **优先级标记**：对关键项标注“必过”（P0），非关键为“建议优化”（P2）。- **持续迭代更新**：根据历史缺陷分析补充新检查项。

某零售企业战略目标为“提升顾客忠诚度”。 - 识别CSF：“精准会员营销”“个性化推荐”“售后服务响应速度”； - 对应信息需求：会员消费行为数据、偏好标签、客服记录； - 信息系统规划：建设CRM系统、用户画像引擎、智能客服平台； - 最终实现：通过信息系统支持关键成功因素，推动战略落地。

- **依赖开发者对系统的理解深度**：若对算法实现细节掌握不全，可能导致遗漏关键假设。 - **初始假设集构建耗时**：需全面列举可能性，工作量大，尤其在高复杂度算法中更明显。 - **验证成本高**：每个假设都需要设计专门测试用例验证，可能增加调试开销。

### 总结判断准则| 特征 | 倾向于代码逻辑错误 | 倾向于外部环境因素 ||------|------------------|--------------------|| 复现稳定性 | 总是复现 | 间歇性、条件性出现 || 环境依赖 | 所有环境均出错 | 仅特定环境出错 || 输入一致性 | 相同输入必出错 | 相同输入结果不一 || 外部依赖 | 移除后仍出错 | Mock 后问题消失 || 日志特征 | 明确报错位置、堆栈清晰 | 超时、断连、资源不足 |

### ⚠️ 注意事项1. **组合爆炸问题**：n 个条件 → $2^n$ 种组合，当 n 较大时测试成本极高。2. **优化策略**： - 使用**边界值 + 等价类划分**减少冗余用例； - 采用**正交试验法**或**成对测试（Pairwise Testing）** 降低数量； - 工具辅助生成（如 PICT、AllPairs）。3. **工具支持**：使用覆盖率工具（如 JaCoCo、gcov、Coverage.py）验证是否真正覆盖了所有条件组合。---

### 三、最佳实践建议：1. **优先处理数值型输入**：适用于范围明确的字段（如金额、数量、年龄、日期等）；2. **多维输入时组合使用**：若多个参数均有范围，可先单变量分析边界+等价类，再考虑组合；3. **配合错误推测法补充异常场景**：如负数、极大数据、特殊字符等；4. **自动化测试中复用模板**：建立“边界+等价类”用例生成规则库，提升回归测试效率。

假设某输入要求为“年龄在 1~150 之间”： - **等价类划分**： - 有效等价类：1 ≤ 年龄 ≤ 150 - 无效等价类：年龄 < 1，年龄 > 150 - **边界值分析**： - 测试点：0, 1, 2, 149, 150, 151 - 综合设计时，既覆盖了有效/无效类，又强化了边界测试，提高缺陷检出率。

### 5. **持续维护与更新矩阵**- 定期审查用户数据变化（每季度一次）- 跟踪新发布的浏览器版本和 OS 更新- 建立“兼容性基线”文档，记录已验证的环境组合

7. **兼容性质量** - 客户端兼容性：跨浏览器（Chrome、Firefox、Safari 等）、跨设备（PC、手机、平板）表现一致。 - 服务器端兼容性：支持不同操作系统、数据库、中间件配置下的部署与运行。识别参与同一事件响应的类集合是基于线程的测试（Thread-Based Testing）的关键步骤。该过程通常结合系统设计文档、用例分析和动态行为建模来完成，具体方法如下：

**举例说明**： - 对一个电商网站做**性能测试**：模拟1000个用户同时登录，查看平均响应时间为800ms，CPU使用率为65%，符合要求。 - 做**压力测试**：模拟1万个用户同时下单，导致数据库连接池耗尽，系统出现错误页面——此时关注的是系统是否能返回友好提示、能否在流量回落后续服务。

- ✅ **异常安全**：无论是否发生异常，资源都能被释放。- ✅ **代码简洁**：无需在多处写 `delete` 或 `close()`。- ✅ **避免资源泄漏**：只要对象是局部变量或成员变量，就能保证析构。- ✅ **通用性强**：可用于内存、锁、socket、GUI 句柄等所有资源。

1. 使用线程安全集合（如 `ConcurrentHashMap`）2. 尽量使用不可变对象（Immutable Object）3. 对复合操作（检查再插入）使用原子方法（如 `putIfAbsent`）4. 必要时使用 `synchronized` 或 `Lock` 控制临界区5. 避免在迭代过程中直接修改集合（应使用并发集合或复制副

### 特性与应用场景：- **高性能**：Go 编译为机器码直接运行，执行效率接近 C/C++，远高于解释型语言。- **高并发**：通过 **goroutine**（轻量级线程）和 **channel**（通信机制）实现 CSP（Communicating Sequential Processes）模型，使得并发编程更安全、直观。- **简洁高效**：语法清晰，学习成本低，强制格式化（如 `gofmt`）提升代码一致性。- **云原生首选**：Docker、Kubernetes 等关键基础设施均

| `nn.BCEWithLogitsLoss()` | 推荐用于二分类，数值更稳定 || `torch.sigmoid()` | 将输出转为 [0,1] 概率 || `(prob > 0.5).float()` | 获得预测类别 || `torch.no_grad()` | 推理时禁用梯度以提升效率 |

| **初学深度学习、做课程项目、写论文复现** | ✅ **PyTorch** || **快速搭建模型、不关心底层细节** | ✅ **TensorFlow + Keras** || **想进入企业级 AI 工程或部署场景** | 可学 TensorFlow 生态 || **科研、读论文、参加竞赛（如 Kaggle）** | ✅ **PyTorch** |

### 五、总结建议- 🎯 微调数据不是越多越好，而是要**高质量、高代表性、高安全性**。- 👨‍⚕️ 医生深度参与是成败关键，不能完全依赖AI自动生成。- 🔐 安全第一：所有数据必须经过伦理审查与合规审批。- 📊 持续迭代：上线后收集实际反馈，不断补充新数据优化模型

1. 进入 **应用使能 > 服务编排**2. 拖拽添加“LLM 推理节点”3. 选择已部署的 LoRA 模型服务4. 配置提示模板（Prompt Template）5. 发布为 REST API，支持 OpenAI 风格接口调用：

| 🔄 **迭代优化** | 如果生成不满意，可在聊天窗口继续输入：“改为使用 UUID 主键”、“增加密码哈希逻辑”，然后重新运行 Composer。 || 🔗 **结合上下文** | 在打开 Composer 前，先打开几个已有文件（如 `main.py` 或 `database.py`），AI 会自动学习项目风格。 || 📁 **智能路径推断** | 不必写全路径，说“生成 controllers/user.ts”即可，Cursor 会按常见结构放置。 || ⚙️ **支持多语言/框架**

### 4. **最佳实践建议**- **禁止直接部署未经审查的 AI 生成代码**- 建立“AI 生成 → 自动扫描 → 单元测试 → 人工复核”的流水线- 在敏感系统（金融、医疗）中限制 AI 生成代码的使用范围- 训练组织内部专用模型，避免泄露私有逻辑

- **主瓣展宽 vs. 旁瓣抑制**：窗函数越平滑，旁瓣越低，但主瓣越宽 → 频率分辨率下降；- **相干增益损失**：加窗会降低信号总能量，需做幅度补偿；- **最佳实践建议**： - 若已知频率为 DFT 频点对齐 → 可使用矩形窗； - 一般情况推荐使用汉宁窗或海明窗； - 对动态范围要求高时用布莱克曼窗； - 使用零填充（Zero-Padding）可改善视觉分辨率（但不提高真实分辨率）。

| 场景 | 评估重点 ||------|----------|| 智能客服群组协作 | 回答一致性、服务口径统一 || 数据分析智能体团队 | 结论准确性、数据引用一致性 || 内容创作协同写作 | 风格统一性、情节连贯性 |

4. **微调与过滤**： 在基础语言模型之上，GitHub 对模型进行了进一步微调，使其更适应 IDE 中的实时补全场景。同时，通过内容过滤机制减少对不安全或低质量代码的推荐。

α 测试与 β 测试是软件发布前的重要用户验收测试手段，适用于多用户使用的产品类软件，用以替代对每个用户逐一进行的验收测试，提升效率并发现真实使用场景中的问题。

**回归测试** - **测试样本**：选择具有代表性的测试用例，覆盖软件的核心功能，而非全部功能。 - **测试重点**：重点关注因代码变更而受到影响的功能模块以及已被修改的软件构件，确保变更未引入新缺陷。 - **设计原则**：测试用例应聚焦于主要功能中常见的错误类型（如边界值、异常处理等），避免进行全量回归测试，以提升效率和可行性。

- 使用**捕捉 / 回放工具**（Capture/Playback Tools）自动记录用户操作并重放，提高效率和一致性，并便于前后结果对比。 - **测试子集包含的三种典型用例类型**（虽未图示，但通常包括）： 1. **发现过缺陷的用例**：历史上曾暴露错误的测试用例，可靠性高，优先回归； 2. **核心功能用例**：覆盖系统关键业务流程的测试用例，确保主路径正常； 3. **高频使用场景用例**：代表用户常用操作路径的测试用例，影响面广，

自顶向下集成测试是一种从主控模块（顶层模块）开始，逐步向下集成子模块的测试策略。在该方法中，主控模块首先作为驱动模块进行测试，而其下层尚未实现的子模块则用桩模块（Stub）代替。随着集成的推进，按照深度优先或广度优先的方式，逐步用实际模块替换对应的桩模块，并持续进行测试和回归测试，以确保接口正确性和功能稳定性。

单元测试环境的核心构成包括驱动模块、被测模块和桩模块。驱动模块用于调用被测模块，模拟上层模块的行为；被测模块是当前需要测试的程序单元；桩模块则代替被测模块所依赖的下层模块，返回预设的模拟数据，以隔离外部依赖。在该环境中，测试用例的设计需覆盖多个关键点：接口的正确性（输入输出是否符合规范）、局部数据结构（如变量、数组的处理是否正确）、边界条件（如最大值、最小值、空值等场景）、独立路径（确保每条执行路径都被覆盖）以及错误处理路径（异常输入或运行时错误能否被妥善处理）。

一、单元测试的重点检查维度 1. **输入 / 输出与文件操作** - 检查函数或方法对输入参数的处理是否正确，输出结果是否符合预期。 - 验证 I/O 格式（如输入格式解析、输出格式生成）是否一致且规范。 - 文件操作中需确认文件是否在使用前正确打开，在使用后及时关闭，避免资源泄漏。

二、传统软件测试策略与单元测试 1. **测试策略的核心要素**： - 整合多种测试用例设计方法（如等价类划分、边界值分析、因果图等）； - 包含完整的测试生命周期：测试计划制定 → 用例设计 → 测试执行 → 结果分析与报告； - 兼具灵活性以适应不同项目特点，同时保持流程严谨，便于进度控制与质量管理； - 遵循分层测试流程：单元测试 → 集成测试 → 确认测试（验收测试）→ 系统测试。

系统测试是在软件开发完成、所有模块集成后，对整个系统作为一个整体进行的全面测试。其目的是验证系统是否满足规定的功能和非功能需求，确保系统在真实运行环境下的正确性、稳定性、安全性、兼容性和性能等质量特性符合预期。系统测试通常在集成测试之后进行，由独立测试团队在接近生产环境的测试环境中执行，涵盖功能测试、性能测试、安全测试、压力测试、恢复测试、兼容性测试等多种类型。

4. **数据库物理设计** - 数据库表结构：每张表的字段名、类型、长度、是否主键/外键、约束条件 - 索引设计：哪些字段建立索引，原因及性能考虑 - 视图、存储过程、触发器说明 - 数据分布与分区策略（如适用）

3. **主要内容差异** - **概要设计**包括： - 系统模块结构图 - 模块间调用关系与接口规范 - 数据库概念与逻辑结构设计 - 抽象数据类型定义 - **详细设计**包括： - 模块内部流程图或伪代码 - 类图、时序图等细化设计模型（OOD） - 具体的数据结构实现方式 - 接口参数的具体格式与传输协议 - 错误处理与安全控制细节

### 三、RTM的有效性衡量指标- **覆盖率**：每个需求是否都有对应的测试用例？- **一致性**：设计与实现是否偏离原始需求？- **变更响应速度**：需求变更后，相关工件更新是否及时？- **缺陷溯源能力**：发现缺陷时能否快速定位到对应需求？

DFD 中的“处理过程”（Process）直接对应系统的功能模块，因此可用于功能分解与描述：- **功能模块化表达**：每个处理框代表一个具体功能（如“验证用户身份”、“计算订单总价”）；- **分层细化功能**：通过多层 DFD（上下文图 → 0 层图 → 1 层图…），逐步展开复杂功能的内部逻辑；- **明确功能输入输出**：每个处理都有明确的数据输入与输出，有助于编写功能规格说明；- **揭示功能间依赖关系**：通过数据流连接不同处理，体现功能间的协作顺序。

1. **明确目标与范围**：在开始前定义项目背景、业务目标和系统边界，避免需求泛化或遗漏核心问题。2. **识别利益相关者**：包括最终用户、客户、管理者、运维人员等，确保各方视角都被覆盖。3. **建立信任关系**：通过沟通建立互信，鼓励用户表达真实需求而非表面诉求。4. **采用多种技术组合**：单一方法易有盲区，应结合访谈、观察、原型等多种手段交叉验证。5. **记录与反馈机制**：及时整理获取的信息，并通过摘要反馈给用户确认，防止误解。6. **管理冲突与优先级**：当需求冲突时，需引导

#### ✅ 结构化分析（SA）适用场景：- 系统逻辑清晰、以数据处理为主（如报表系统、批处理系统）- 业务流程固定、变更较少的传统行业系统（如银行后台、库存管理）- 小型或中等规模项目，开发团队习惯使用传统方法- 用户更关注“输入→处理→输出”的流程> 示例：工资计算系统、订单处理系统（基于事务流）

| 块大小 | $ s = \sqrt{n} $ || 块间顺序 | 必须有序（后一块 > 前一块最大值） || 索引查找方式 | 折半查找优先于顺序查找 || 索引内容 | 包含最大关键字、起始地址、块长 || 动态维护 | 预留空间 + 溢出处理 || 大规模扩展 | 多级索引结构 |

#### 2. **线程用于提升程序内部并发性能**- 在单个应用程序中启用多线程，可同时处理多项子任务，例如： - Web 服务器用多线程响应多个客户端请求； - 视频播放器一边解码画面，一边播放音频，一边下载缓冲数据。- 显著提高响应速度和 CPU 利用率，尤其在多核处理器上能真正并行执行。

简而言之，**AUP = RUP的核心框架 + 敏捷原则（如XP、Scrum）的实践精神**。它保留了RUP的四阶段结构（初始、精化、构建、转化），但在每个阶段内采用类似极限编程（XP）的小步快跑式开发，强调测试驱动、持续集成和用户反馈。