难点一：UML图到底谁是“戏精”，谁是“道具”？（行为 vs. 结构）
你的困惑：每次选“哪些是行为图”都手抖，感觉除了类图，其他都像在“动”。
把软件系统想象成一部话剧。
结构图 = 剧组名单 + 舞台布景清单
类图：这是演员表。上面写了有哪几个角色（类），每个角色是啥性格（属性），以及角色之间可能是父子、夫妻还是仇敌（关系）。它不演戏，只管谁在。
构件图/部署图：这是道具清单和舞台设备图。写明灯光、音响、背景板（构件）都在哪，怎么连接。它是静态的配置。
行为图 = 剧本 + 实际演出
用例图：这是剧情简介海报。告诉你这出戏主要讲哪几个故事（用例），以及每个故事涉及哪几个主要角色（参与者）。它定义了“演什么”。
活动图：这是详细的分镜头脚本。描述完成一个剧情（比如“求婚”）需要先做什么、再做什么、有哪些判断分支。它是工作流的步骤。
顺序图：这是一次具体对白的台词本。精确展示在某一幕里，角色A在什么时间点对角色B说了什么（消息），B又如何回应。它是对象间的即时通讯记录。
状态图：这是某个角色的心理变化轨迹。比如一个“门”的角色，从“锁着”到“开着”到“坏了”，需要什么事件触发，变了状态后有什么反应。它关注一个对象的内心戏。
一句话记住：问“如何工作/演出”的，找行为图（剧本、台词、心理）。问“由谁/什么组成”的，找结构图（演员表、道具单）。
难点二：OO测试 vs 传统测试，差别到底多大？
你的困惑：知道“测试对象不同”，但感觉换汤不换药。
传统（结构化）测试 = 测试一条“流水线”
你的测试单元是一个个加工工序（函数）。比如一道“西红柿炒蛋”流水线，你分别测试：“打蛋机”（函数A）能否打好蛋，“切菜机”（函数B）能否切好西红柿。最后测试整条线连起来能不能出菜。
核心是：输入原料 -> 处理 -> 输出成品。工序之间主要通过明确的接口（传送带）传递半成品。
面向对象测试 = 测试一个“智能机器人团队”
你的测试单元是一个个机器人（对象）。每个机器人有内部状态（电量、记忆）和技能（方法）。
测试一个“厨师机器人”，你不仅要测它的“炒菜”技能，还要测它“炒完菜”后，内部状态（比如“疲惫值”升高）是否正确，以及它和“送菜机器人”协作时，消息发得对不对。
最大的麻烦来了：继承和多态。好比你有基础款厨师机器人，又升级了一个“川菜特化版”继承了它。你不能只测基础款，还得测特化版重写后的“炒菜”技能是不是更麻更辣。这叫“里氏替换”，子类必须能顶替父类，但行为可以个性化。
本质区别：传统测试关心流程和数据；OO测试关心对象的责任、状态和对象间的协作契约。OO测试因为对象有“记忆”（状态）和“社会关系”（多态、关联），所以更复杂。
难点三：CMM能力等级，别再死记硬背了！
你的困惑：已定义、已管理、优化级，名字太像，老是记混谁高谁低。
场景化：用“做饭水平”来理解
初始级：看心情做饭
状态：今天做得好，明天可能糊了。完全依赖大厨当天的手感和心情。不可预测。
可重复级：有菜谱就能做
状态：拿到一个详细的菜谱（上次成功的经验），能基本复现出一样的菜。靠好文档（菜谱）保证重复成功。
已定义级：开了个标准化连锁店
状态：所有分店都用同一套标准操作流程（SOP）。土豆切几厘米、炒几分钟全有规定。不管谁做，味道基本一致。核心是“标准化”。
已管理级：连锁店装了智能监控系统
状态：不仅按SOP做，还实时收集数据：今天出菜平均时间、客户满意度评分、食材浪费率。如果发现出菜慢了，能用数据知道是哪个环节拖后腿。核心是“用数据量化管理”。
优化级：总部的研发厨房
状态：分析所有分店的数据，发现SOP里“小火炖10分钟”其实优化为“98度焖9分钟”口感更好、更省燃气。然后主动更新SOP，推广到全公司。核心是“基于数据，持续优化改进流程本身”。
这下明白了吧？优化级是最高级，因为它不满足于标准化和量化，而是用量化驱动变革，让整个组织越变越好。
