软考软件设计师中级卡住最多人的往往不是算法和程序设计而是「软件设计、测试与维护」这一大块。原因很简单这块内容不像数据结构那样有标准答案也不像数据库那样有固定套路它偏工程、偏经验还喜欢在题干里埋坑。我从第一次备考时的65分到后来帮同事梳理考点前前后后把这章啃了三遍今天就把这一章的考点逻辑、真题命题思路和避坑经验一次性说透。先给还在观望的朋友一个定位软件设计师上午题75道选择这一章能占到8到12分下午题两道大题软件设计案例分析、测试与维护类题目也绕不开它。可以说这一章是上午题的“基本盘”和下午题的“压舱石”拿不下它证书基本没戏。这篇文章适合所有正在备考软考软件设计师中级、尤其是二刷三刷还卡在设计和测试知识点的考生。1. 这一章到底考什么分值与题型全景拆解1.1 上午题与下午题的分布规律先说上午题。软件设计师上午题一共75道覆盖计算机组成、操作系统、数据库、网络、软件工程、面向对象、数据结构、算法等十几个方向。其中「软件设计、测试与维护」相关的题目通常集中在第20到第35题之间而且有个明显特征概念题多计算题少但陷阱极多。我统计了近五年的真题分布内聚与耦合每年必考一道黑盒白盒测试方法判断隔年考软件维护的四种类型几乎年年出现软件配置管理中的基线概念也是高频选择。这些题看起来是送分题实际错误率常年排在所有题目的前五原因就是考生只记了概念的名字没记概念之间的边界。下午题这边更直接试题二或试题三经常给出一个系统的数据流图或者结构图让你补充缺失的加工、判断内聚耦合类型或者针对某个模块设计测试用例。试题四或试题五则偏向面向对象设计给出类图或用例图让你分析设计是否合理。无论是哪种形式软件测试的知识点都会以“设计测试用例”或“指出测试方法”的方式嵌入进去。1.2 从结构化到面向对象的演进逻辑这一章在教材里其实是按软件工程的历史线索展开的理解这条线比死记硬背重要得多。早期的软件规模小开发靠个人英雄主义后来软件危机爆发人们发现“想清楚再写”比“边写边想”靠谱得多于是有了结构化分析与设计。结构化方法的核心思想是“自顶向下、逐步分解”代表工具有数据流图DFD、数据字典、结构图SC、ER图。考试中经常让你根据一段需求描述画出第一层DFD或者指出某张DFD中丢失了哪个数据流这些都属于结构化方法的范畴。到了90年代系统越来越复杂数据流图那一套在大型系统面前开始吃力面向对象方法登场。它的核心是“对象”和“类”强调封装、继承、多态。对应到考试里就是类图、用例图、序列图的阅读与补全。很多考生把这两套方法割裂开学结果一做题就混。实际上考试并不要求你站队而是要求你看到结构化题目用结构化思路看到面向对象题目就切到面向对象思路。我后面会专门讲这两者的切换技巧。1.3 测试与维护的常驻考点分类测试部分的考点可以用一句话概括知道“什么时候测、怎么测、测什么”。什么时候测对应测试的生命周期阶段包括单元测试、集成测试、系统测试、验收测试怎么测对应动态测试中的白盒和黑盒方法以及静态测试中的代码审查等测什么对应测试用例设计包括语句覆盖、判定覆盖、条件覆盖、路径覆盖以及等价类划分、边界值分析、判定表等。维护部分则更偏向“分类学”改正性维护、适应性维护、完善性维护、预防性维护这四类必须能根据场景描述快速判断。另外还有软件可维护性的度量、软件配置管理中的版本控制与基线以及软件质量管理中的ISO/IEC 9126质量模型这些是上午题喜欢出概念辨析的地方。2. 软件设计考点精讲与记忆技巧2.1 内聚与耦合七种类型必须按强度排序背内聚与耦合是软件设计质量的两把标尺也是软考选择题里的“钉子户”。我的经验是能把这部分做成一张排序表选择题基本就稳了。内聚按强度从低到高依次是偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚、功能内聚。耦合按从低到高也就是从好到坏依次是非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。记忆上有个小技巧内聚从低到高记口诀“偶逻时过通顺功”谐音就是“藕落时过通顺功”耦合从低到高记“非数标控外公内”。背会口诀之后更关键的是理解边界。常考的一个坑是“控制耦合”和“标记耦合”的区分。控制耦合是一个模块传递的是控制信号比如一个flag或者开关值另一个模块根据这个值来选择执行路径标记耦合是传递的是数据结构但不使用其全部信息比如传一个整张表给函数函数只用了某一列。真题特别喜欢把这两类放到一个题干里让你选。另一个高频陷阱是“公共耦合”和“内容耦合”的区别。公共耦合是多个模块共享一个公共数据区域比如全局变量内容耦合是一个模块直接访问另一个模块的内部数据或代码在高级语言里通常表现为不通过接口直接修改别的模块的内部变量。这两个都代表设计得烂但烂的程度不同考试要你选“耦合程度最强”的那就是内容耦合。我在做题时总结出一条判断链路先看模块之间有没有直接数据传递没有就是非直接耦合再看传递的是一般数据还是控制信号如果传的是完整数据结构而接收方只用部分就是标记耦合如果涉及全局公共区就进一步判断是公共耦合还是内容耦合。按这个链路走正确率能稳定在九成以上。2.2 结构化设计从数据流图到结构图的映射结构化设计的大题通常分两种考法一种是给你DFD让你补缺失的数据流另一种是给你结构图让你判断模块分解是否合理。补数据流的题核心是“守恒”思想。数据流图中的每个加工都应当是平衡的即流入加工的数据流加上加工本身产出的数据流必须与数据字典中的描述一致。做题时我习惯先看加工名称和数据字典搞清楚这个加工“吃进什么、吐出什么”然后回到图上检查每一层父图和子图的接口是否对齐。父图中一条数据流到了子图必须拆解成子图中至少一条对应的数据流否则就是漏画了。结构图那边常考的是模块的扇入扇出是否合理。扇入指一个模块被多少个上层模块调用扇出指一个模块调用了多少个下层模块。经验值是扇出控制在3到4左右扇入越大越好因为说明复用程度高。真题会给一张结构图问你哪个模块设计不合理答案通常是某个中间模块扇出过高需要增加中间层次来降低扇出。这里有个经典误区很多人认为模块划分越细越好。实际上模块过多接口数量会爆炸增长模块间的耦合也会随之上升。模块划分的原则是“高内聚低耦合”的同时保持合理的粒度。我在复习时用一个例子理解一个核算工资的模块如果把“计算社保”“计算个税”“计算补贴”都拆成独立模块每个模块只干一件事这是好的但如果连“读取员工姓名”都单独拆一个模块那就过度设计了。2.3 面向对象设计原则与SOLID速记下午题近年越来越侧重面向对象设计特别是类图的设计合理性判断。这块对应的核心考点就是面向对象设计原则。SOLID五原则在软考大纲里不做强制英文名考察但中文含义必考单一职责原则强调一个类只负责一项职责开闭原则强调对扩展开放、对修改关闭里氏替换原则强调子类必须能替换其父类接口隔离原则强调客户端不应该依赖它不需要的接口依赖倒置原则强调抽象不应该依赖细节细节应该依赖抽象。真题经常这样考给出一个类图A类既负责数据存储又负责界面展示问违反了什么原则。答案是单一职责。又比如一个抽象类的高层模块直接依赖了一个具体实现类问违背了什么原则答案是依赖倒置。还有一个高频考点是组合聚合复用原则即优先使用对象组合而不是继承来实现复用。选择题里会给出一个场景某个类需要复用另一个类的功能选项里有“继承”和“组合”两种方案问你哪个更符合设计原则答案永远是组合。原因很简单继承会破坏封装性子类和父类耦合度过高父类一改子类就崩组合则是通过接口调用耦合度低。我复习面向对象设计原则时会把每个原则对应到一道真题的题干上而不是抽象地背句子。比如看到“新功能加不进去一加就改老代码”就对应开闭原则看到“一个类改了之后牵连一片其他功能”就对应单一职责看到“测试的时候发现基类有的功能子类全都不能用”就对应里氏替换原则。关键词触发式的记忆在考试时间紧张时最管用。3. 软件测试考点精讲白盒黑盒与用例设计3.1 测试的阶段划分与V模型软件测试这一章首先得把测试的阶段脉络捋清楚。软件测试分为单元测试、集成测试、系统测试、验收测试四个层次每个层次的测试对象、测试依据和测试人员都不同。单元测试针对的是程序中的最小模块通常由程序员自己完成测试依据是详细设计说明书主要用白盒测试方法。集成测试把多个模块合在一起测重点检查模块之间的接口依据是概要设计说明书常用黑盒加点白盒的混合方法。系统测试把整个系统放在真实或模拟环境中测依据是需求规格说明书全部用黑盒测试重点考察性能、安全性、兼容性。验收测试最后由用户或客户来做依据是用户需求关键指标是软件是否满足业务需求。考试常考的是V模型即把开发和测试的各个阶段对应起来需求分析对应验收测试、概要设计对应系统测试、详细设计对应集成测试、编码对应单元测试。记的时候想想字母V的形状左侧是开发活动右侧是测试活动一一对应且测试活动是延迟验证。这里有个易错点集成测试有两种策略非渐增式也叫大爆炸式和渐增式渐增式又分为自顶向下和自底向上。自顶向下需要写桩模块自底向上需要写驱动模块。真题会给出场景让你选策略比如“先测底层模块逐步向上不需要写桩模块”答案就是自底向上。3.2 白盒测试逻辑覆盖与环路复杂度计算白盒测试的题基本就是两类一类是逻辑覆盖法区分一类是环路复杂度计算。逻辑覆盖按强度从低到高是语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。考试最常见的场景是给出一个程序流程图问“至少要多少个测试用例才能满足判定覆盖”。这种题的做法是数清楚流程图里的判定节点判定覆盖要求每个判定的真分支和假分支至少被走过一次。两个判定就是两个二选一的分支要达到判定覆盖一般需要两组用例如果判定之间有依赖关系可能还得加。环路复杂度的计算用的是麦凯布公式V(G)E-N2其中E是边数N是节点数。另一种更快的算法是V(G)判定节点数1前提是程序只有一个入口一个出口。我推荐用判定节点数法因为画图数边太容易出错。但要注意有个变形公式V(G)E-N2P适用于有多个独立程序块的情况软考里面基本用不到不用花太多精力。记得有一年真题给了一段十行左右的伪代码要计算环路复杂度并指出基本路径的条数。环路复杂度的值就是基本路径的条数也是独立路径的上界。我从这道题里学到的经验是考场上一旦看到“圈复杂度”或者“环路复杂度”优先找判定语句if、while、for、case数清楚之后加一十秒钟出答案。3.3 黑盒测试等价类、边界值与判定表黑盒测试里最常考的是等价类划分和边界值分析两者几乎绑定出现。等价类划分是把输入域划分为若干个子集每个子集中的数据对发现错误是等效的然后从每个等价类中选取少量代表性数据作为测试用例。有效等价类验证程序是否实现了规格说明中的功能无效等价类验证程序能否正确拒绝非法输入。边界值分析则专门盯着输入域的边界因为大量错误往往发生在输入范围的边界附近而不是中间。经典例子是“输入1到100之间的整数”边界值要测0、1、2、99、100、101这六个数加上一个正常中间值比如50一共七个用例。考试中如果只让选一组最有效的答案一定是边界值而不是中间值。判定表法也是黑盒测试的高频工具适合处理“多个条件和多个动作”的场景。真题给一个判定表让你补全其中某个动作的取值。只要抓住两条规则列的“条件组合”决定该列的动作取值某条规则的条件如果包含了不可能组合则该规则可以合并。这种题的关键是细心把每个条件组合逐个对到表里一个都别漏。还有一类黑盒测试题考的是场景法或者错误推测法这类题通常放在下午的案例里让你根据业务流程设计测试场景。做法是梳理业务流程中的每个步骤把正常路径、异常路径、中断路径都列出来每条路径就是一个测试场景。4. 软件维护与配置管理容易被忽略的送分题4.1 四种维护类型一眼判断法软件维护这块的内容教材里篇幅不大但考试性价比极高。四个维护类型——改正性维护、适应性维护、完善性维护、预防性维护——几乎每年都考而且考法已经固化了给你一段具体场景让你判断属于哪种维护。我用一套“关键词判定法”来快速解题。改正性维护的关键词是“发现的错误”“缺陷”“故障”对应的是软件交付后暴露的bug这类维护占比约20%左右。适应性维护的关键词是“外部环境变化”“操作系统升级”“数据库版本更新”“新的法规”对应的是软件适应外部环境的变化占比约25%。完善性维护的关键词是“增加新功能”“改进性能”“提高易用性”这是占比最大的一类约50%。预防性维护的关键词是“为未来”“便于修改”“防止潜在问题”比如重构代码以提高可维护性占比约5%。考试最喜欢混淆的是适应性和完善性。记住一个判断标准外部环境变了你改软件是适应性你自己想加点功能提高用户体验是完善性。比如“操作系统从Windows 7升级到Windows 10软件需要调整兼容性”是适应性维护“软件增加了导出Excel报表的功能”是完善性维护。这两个例子记下来基本不会再错。4.2 可维护性与软件质量属性可维护性的度量在上午题里也会出现包括可理解性、可测试性、可修改性。可理解性考察的是别人能不能读懂你的代码与结构化程度、文档质量正相关可测试性考察的是软件是否容易设计测试用例、是否容易定位缺陷可修改性考察的是修改一个模块是否会引起大范围连锁反应与之直接相关的就是耦合度和内聚度。质量属性那边ISO/IEC 9126模型包含功能性、可靠性、易用性、效率、可维护性、可移植性六大特性。选择题最常见考法是给出一个具体描述让你选对应的质量特性比如“软件在一段时间内持续运行不出故障的能力”是可靠性“软件从一种环境迁移到另一种环境的能力”是可移植性“软件在单位时间内能处理的请求数量”是效率。另一个容易混淆的是可靠性和可用性。可靠性关注的是“不出故障”可用性关注的是“出故障后能多快恢复”两者的量化指标也不同可靠性用平均无故障时间MTBF衡量可用性用可用度系统正常运行时间占比衡量。历年真题里只要出现“平均无故障时间”答案基本上都在可靠性相关的选项里。4.3 配置管理核心概念配置管理在软考里属于理论性比较强的部分概念多但深度不深。核心概念有配置项、基线、配置控制委员会CCB、版本控制、配置审计。基线的定义是“一组经过正式评审和批准的配置项它作为后续开发工作的基础并且只能通过正式的变更控制流程才能修改”。这个定义是选择题的常考点注意关键词正式评审批准、基准、变更必须走流程。真题的干扰项通常会写成“基线可以随意修改”或者“基线是开发过程中的临时版本”一眼就能排除。配置控制委员会CCB负责审批变更请求做决策但不负责实施变更。这里的“负责审批、不负责实施”是选择题最爱挖的坑。我见过一道题选项说“配置管理员负责审批变更请求”这就是把CCB的职责安到了配置管理员头上属于典型的张冠李戴。配置管理员CMO的职责是版本管理、变更记录、配置审计的执行权限是“管”而不是“批”。版本控制这块软考主要考概念题比如“配置项的版本号规则”“受控状态下的配置项变更必须经过评审”等。另外还有个考法给你一个变更场景问变更控制的正确顺序。顺序是变更申请→变更评估→CCB审批→变更实施→变更验证与确认→变更发布并纳入基线。记住这个流程下午的案例题里如果让“指出变更控制流程中的错误”照着这个顺序对比就行了。5. 真题突破三道典型题的解题套路5.1 上午题模块间耦合类型判断拿一道典型的真题来说一个工资计算系统中的三个模块模块A读取员工基本信息模块B根据A传来的员工工资数据计算个税模块C直接修改了系统全局配置表中的参数供所有模块使用。问模块A与模块B之间、模块与全局配置表之间的耦合类型分别是什么。这道题的考点就是区分数据耦合、公共耦合和控制耦合。模块A传给B的是计算个税所需的工资数据是普通数据所以A到B是数据耦合。模块C修改的是供所有模块共用的全局配置表这属于公共数据区域所以C与系统之间的耦合是公共耦合。我做这类题的经验是先看模块间是否传递数据再看数据的性质。如果传递的是数据值选数据耦合或标记耦合具体看接收方是否使用全部字段如果传递的是控制标志选控制耦合如果共享公共区直接排除前面的选项在公共耦合和内容耦合之间选。大多数考题只要走到“数据还是控制”这一层就能锁定了。5.2 下午题给模块设计测试用例下午的测试题一般会给一段需求描述和模块代码或伪代码让你分别用等价类划分法和边界值分析方法设计测试用例。一类经典需求是“输入日期格式为YYYY-MM-DD年份范围1900到2100月份1到12日期1到月底”。如果要求用等价类划分法设计用例我会这样做年份的有效等价类是1900到2100无效等价类是小于1900和大于2100月份的有效等价类是1到12无效等价类是小于1和大于12日期需要结合月份判断可以粗分为有效日期和无效日期两类。每个有效等价类至少取一个代表值每个无效等价类也要单独设计用例因为程序往往对每个无效输入都有独立的错误提示。如果题目要求用边界值分析那年份边界就是1900、2100、1899、2101月份边界是1、12、0、13日期边界就取1、31和非法日期。边界值分析法的精髓是“把测试用例尽量往上边界和下边界凑”许多缺陷都发生在边界附近。我写这类题时有个习惯先把有效类和无效类单独列成两行再在每个类下面举出对应的测试输入和预期输出。这样阅卷老师一眼就能看到你的分析逻辑也方便自己写完复查有没有漏掉无效等价类。下午题是按点给分的分析过程比最终答案重要宁可多写一步推导也不能只写一个结论。5.3 案例分析软件维护类型判断与变更流程案例分析里维护类型的题通常是这样给出一个系统上线运营半年内的四条维护记录分别是修复了客户对账报表中某个计算公式的错误将数据库从MySQL 5.7升级到8.0后调整了连接配置根据客户需求增加了按部门汇总的统计功能重构了登录模块代码以提高后续修改的效率。问这四条分别属于哪种维护类型。第一条是修复已知错误对应改正性维护第二条是数据库环境升级后的适配对应适应性维护第三条是新增功能对应完善性维护第四条是为后续修改方便而重构对应预防性维护。这道题只要记住了四种类型的关键词一条条对号入座就行基本属于送分题。变更流程那道题常见错误是做变更时不写变更申请直接改代码改完之后不做回归测试变更完成之后没有更新基线。我在答题时会拿“申请→评估→审批→实施→验证→发布”这个六步流程当模板对照题干描述逐条找缺失或错误基本能拿全这部分的分数。6. 备考安排与避坑指南6.1 时间分配建议这章到底该花多久我给在职备考的同事的普遍建议是如果每天能坚持学1到2个小时这一章整体规划三到四周比较合理。第一周学软件设计部分重点是内聚耦合和数据流图第二周学测试部分重点是白盒黑盒方法和测试用例设计第三周学维护与配置管理这部分纯概念两到三天就能消化完剩余时间做历年真题第四周专门做错题回顾和下午题模拟。上午题和下午题的学习要同步推进不能只刷上午题。我的经验是上午题用来检查概念记忆是否牢固下午题用来检查分析能力是否达标。很多考生上午题能做对但下午题的案例分析题写不出完整的推理过程就是因为概念是背的没真正理解。每天花30分钟专门练一道下午题比周末集中做一套题效果要好。6.2 错题本应该怎么记按考点归因这一章的概念多、坑多错题本必须有但不能照抄题目。我的做法是把每道错题归因到具体考点比如“这道题错了是因为我把控制耦合和标记耦合搞混了”然后单独开一页写清楚这两者的区分方法附带一道对应真题和一句自己的理解。归因比抄题重要得多。原因很简单软考不考原题你抄再多的题目换个马甲可能依然不会。而归因能让你发现自己的薄弱模式。我当年统计过我的错题里有一半以上集中在控制耦合和适应性维护这两个点上针对性补强之后下午题模拟的正确率明显上升。错题本每周至少翻一遍考前两周只看错题本和总结的表格不再翻教材。如果错题本内容太多说明你还在“无效刷题”阶段需要停下来分析是不是基础知识没打牢。我当时整理完内聚耦合的排序表错题率直接下降一半可见结构化总结比盲目刷题高效得多。6.3 考场上的速答技巧与时间控制上午题这一章的内容单题作答时间控制在60秒以内。判断题要善于利用教材中的标准表述比如基线的定义、CCB的职责这类概念题选最贴近教材原文的一项不要自己发挥。经验性判断的题比如给场景判断维护类型用关键词匹配法看到“新功能”就选完善性维护看到“环境变化”就选适应性维护。下午题的时间控制更关键。建议先花5分钟浏览全部题目优先做自己最熟练的数据流图补全或测试用例设计题把复杂的面向对象设计题放到后面。测试用例设计题一定要把“输入、预期输出、覆盖的等价类或边界”写清楚不要只写输入数据。阅卷看的是分析过程不是最终答案。有个小技巧下午题答题时如果题目要求你指出设计中的错误每条错误尽量使用“模块XXX存在YYY问题应该ZZZ”的句式一条一行不要写成一整段。这样阅卷老师工作量小你的得分点也清晰。我在实际备考过程中的一点体会是这一章的内容说到底是“软件工程常识”的浓缩考点并不深奥但它考察的是你能不能站在工程角度思考问题。如果你平时写代码习惯性复制粘贴、从不考虑模块划分和测试用例学这章就会觉得抽象难懂反过来如果你养成了写模块先想接口、改代码先看影响面的习惯这章就是整场考试里最轻松的部分。所以不要只为了考试去背知识点试着把这些设计思想和测试方法带到你自己写的代码里你会发现软考的很多题目其实就是帮你审视自己做过的项目哪里出了问题。
软考软件设计师中级卡住最多人的往往不是算法和程序设计而是「软件设计、测试与维护」这一大块。原因很简单这块内容不像数据结构那样有标准答案也不像数据库那样有固定套路它偏工程、偏经验还喜欢在题干里埋坑。我从第一次备考时的65分到后来帮同事梳理考点前前后后把这章啃了三遍今天就把这一章的考点逻辑、真题命题思路和避坑经验一次性说透。先给还在观望的朋友一个定位软件设计师上午题75道选择这一章能占到8到12分下午题两道大题软件设计案例分析、测试与维护类题目也绕不开它。可以说这一章是上午题的“基本盘”和下午题的“压舱石”拿不下它证书基本没戏。这篇文章适合所有正在备考软考软件设计师中级、尤其是二刷三刷还卡在设计和测试知识点的考生。1. 这一章到底考什么分值与题型全景拆解1.1 上午题与下午题的分布规律先说上午题。软件设计师上午题一共75道覆盖计算机组成、操作系统、数据库、网络、软件工程、面向对象、数据结构、算法等十几个方向。其中「软件设计、测试与维护」相关的题目通常集中在第20到第35题之间而且有个明显特征概念题多计算题少但陷阱极多。我统计了近五年的真题分布内聚与耦合每年必考一道黑盒白盒测试方法判断隔年考软件维护的四种类型几乎年年出现软件配置管理中的基线概念也是高频选择。这些题看起来是送分题实际错误率常年排在所有题目的前五原因就是考生只记了概念的名字没记概念之间的边界。下午题这边更直接试题二或试题三经常给出一个系统的数据流图或者结构图让你补充缺失的加工、判断内聚耦合类型或者针对某个模块设计测试用例。试题四或试题五则偏向面向对象设计给出类图或用例图让你分析设计是否合理。无论是哪种形式软件测试的知识点都会以“设计测试用例”或“指出测试方法”的方式嵌入进去。1.2 从结构化到面向对象的演进逻辑这一章在教材里其实是按软件工程的历史线索展开的理解这条线比死记硬背重要得多。早期的软件规模小开发靠个人英雄主义后来软件危机爆发人们发现“想清楚再写”比“边写边想”靠谱得多于是有了结构化分析与设计。结构化方法的核心思想是“自顶向下、逐步分解”代表工具有数据流图DFD、数据字典、结构图SC、ER图。考试中经常让你根据一段需求描述画出第一层DFD或者指出某张DFD中丢失了哪个数据流这些都属于结构化方法的范畴。到了90年代系统越来越复杂数据流图那一套在大型系统面前开始吃力面向对象方法登场。它的核心是“对象”和“类”强调封装、继承、多态。对应到考试里就是类图、用例图、序列图的阅读与补全。很多考生把这两套方法割裂开学结果一做题就混。实际上考试并不要求你站队而是要求你看到结构化题目用结构化思路看到面向对象题目就切到面向对象思路。我后面会专门讲这两者的切换技巧。1.3 测试与维护的常驻考点分类测试部分的考点可以用一句话概括知道“什么时候测、怎么测、测什么”。什么时候测对应测试的生命周期阶段包括单元测试、集成测试、系统测试、验收测试怎么测对应动态测试中的白盒和黑盒方法以及静态测试中的代码审查等测什么对应测试用例设计包括语句覆盖、判定覆盖、条件覆盖、路径覆盖以及等价类划分、边界值分析、判定表等。维护部分则更偏向“分类学”改正性维护、适应性维护、完善性维护、预防性维护这四类必须能根据场景描述快速判断。另外还有软件可维护性的度量、软件配置管理中的版本控制与基线以及软件质量管理中的ISO/IEC 9126质量模型这些是上午题喜欢出概念辨析的地方。2. 软件设计考点精讲与记忆技巧2.1 内聚与耦合七种类型必须按强度排序背内聚与耦合是软件设计质量的两把标尺也是软考选择题里的“钉子户”。我的经验是能把这部分做成一张排序表选择题基本就稳了。内聚按强度从低到高依次是偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚、功能内聚。耦合按从低到高也就是从好到坏依次是非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。记忆上有个小技巧内聚从低到高记口诀“偶逻时过通顺功”谐音就是“藕落时过通顺功”耦合从低到高记“非数标控外公内”。背会口诀之后更关键的是理解边界。常考的一个坑是“控制耦合”和“标记耦合”的区分。控制耦合是一个模块传递的是控制信号比如一个flag或者开关值另一个模块根据这个值来选择执行路径标记耦合是传递的是数据结构但不使用其全部信息比如传一个整张表给函数函数只用了某一列。真题特别喜欢把这两类放到一个题干里让你选。另一个高频陷阱是“公共耦合”和“内容耦合”的区别。公共耦合是多个模块共享一个公共数据区域比如全局变量内容耦合是一个模块直接访问另一个模块的内部数据或代码在高级语言里通常表现为不通过接口直接修改别的模块的内部变量。这两个都代表设计得烂但烂的程度不同考试要你选“耦合程度最强”的那就是内容耦合。我在做题时总结出一条判断链路先看模块之间有没有直接数据传递没有就是非直接耦合再看传递的是一般数据还是控制信号如果传的是完整数据结构而接收方只用部分就是标记耦合如果涉及全局公共区就进一步判断是公共耦合还是内容耦合。按这个链路走正确率能稳定在九成以上。2.2 结构化设计从数据流图到结构图的映射结构化设计的大题通常分两种考法一种是给你DFD让你补缺失的数据流另一种是给你结构图让你判断模块分解是否合理。补数据流的题核心是“守恒”思想。数据流图中的每个加工都应当是平衡的即流入加工的数据流加上加工本身产出的数据流必须与数据字典中的描述一致。做题时我习惯先看加工名称和数据字典搞清楚这个加工“吃进什么、吐出什么”然后回到图上检查每一层父图和子图的接口是否对齐。父图中一条数据流到了子图必须拆解成子图中至少一条对应的数据流否则就是漏画了。结构图那边常考的是模块的扇入扇出是否合理。扇入指一个模块被多少个上层模块调用扇出指一个模块调用了多少个下层模块。经验值是扇出控制在3到4左右扇入越大越好因为说明复用程度高。真题会给一张结构图问你哪个模块设计不合理答案通常是某个中间模块扇出过高需要增加中间层次来降低扇出。这里有个经典误区很多人认为模块划分越细越好。实际上模块过多接口数量会爆炸增长模块间的耦合也会随之上升。模块划分的原则是“高内聚低耦合”的同时保持合理的粒度。我在复习时用一个例子理解一个核算工资的模块如果把“计算社保”“计算个税”“计算补贴”都拆成独立模块每个模块只干一件事这是好的但如果连“读取员工姓名”都单独拆一个模块那就过度设计了。2.3 面向对象设计原则与SOLID速记下午题近年越来越侧重面向对象设计特别是类图的设计合理性判断。这块对应的核心考点就是面向对象设计原则。SOLID五原则在软考大纲里不做强制英文名考察但中文含义必考单一职责原则强调一个类只负责一项职责开闭原则强调对扩展开放、对修改关闭里氏替换原则强调子类必须能替换其父类接口隔离原则强调客户端不应该依赖它不需要的接口依赖倒置原则强调抽象不应该依赖细节细节应该依赖抽象。真题经常这样考给出一个类图A类既负责数据存储又负责界面展示问违反了什么原则。答案是单一职责。又比如一个抽象类的高层模块直接依赖了一个具体实现类问违背了什么原则答案是依赖倒置。还有一个高频考点是组合聚合复用原则即优先使用对象组合而不是继承来实现复用。选择题里会给出一个场景某个类需要复用另一个类的功能选项里有“继承”和“组合”两种方案问你哪个更符合设计原则答案永远是组合。原因很简单继承会破坏封装性子类和父类耦合度过高父类一改子类就崩组合则是通过接口调用耦合度低。我复习面向对象设计原则时会把每个原则对应到一道真题的题干上而不是抽象地背句子。比如看到“新功能加不进去一加就改老代码”就对应开闭原则看到“一个类改了之后牵连一片其他功能”就对应单一职责看到“测试的时候发现基类有的功能子类全都不能用”就对应里氏替换原则。关键词触发式的记忆在考试时间紧张时最管用。3. 软件测试考点精讲白盒黑盒与用例设计3.1 测试的阶段划分与V模型软件测试这一章首先得把测试的阶段脉络捋清楚。软件测试分为单元测试、集成测试、系统测试、验收测试四个层次每个层次的测试对象、测试依据和测试人员都不同。单元测试针对的是程序中的最小模块通常由程序员自己完成测试依据是详细设计说明书主要用白盒测试方法。集成测试把多个模块合在一起测重点检查模块之间的接口依据是概要设计说明书常用黑盒加点白盒的混合方法。系统测试把整个系统放在真实或模拟环境中测依据是需求规格说明书全部用黑盒测试重点考察性能、安全性、兼容性。验收测试最后由用户或客户来做依据是用户需求关键指标是软件是否满足业务需求。考试常考的是V模型即把开发和测试的各个阶段对应起来需求分析对应验收测试、概要设计对应系统测试、详细设计对应集成测试、编码对应单元测试。记的时候想想字母V的形状左侧是开发活动右侧是测试活动一一对应且测试活动是延迟验证。这里有个易错点集成测试有两种策略非渐增式也叫大爆炸式和渐增式渐增式又分为自顶向下和自底向上。自顶向下需要写桩模块自底向上需要写驱动模块。真题会给出场景让你选策略比如“先测底层模块逐步向上不需要写桩模块”答案就是自底向上。3.2 白盒测试逻辑覆盖与环路复杂度计算白盒测试的题基本就是两类一类是逻辑覆盖法区分一类是环路复杂度计算。逻辑覆盖按强度从低到高是语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。考试最常见的场景是给出一个程序流程图问“至少要多少个测试用例才能满足判定覆盖”。这种题的做法是数清楚流程图里的判定节点判定覆盖要求每个判定的真分支和假分支至少被走过一次。两个判定就是两个二选一的分支要达到判定覆盖一般需要两组用例如果判定之间有依赖关系可能还得加。环路复杂度的计算用的是麦凯布公式V(G)E-N2其中E是边数N是节点数。另一种更快的算法是V(G)判定节点数1前提是程序只有一个入口一个出口。我推荐用判定节点数法因为画图数边太容易出错。但要注意有个变形公式V(G)E-N2P适用于有多个独立程序块的情况软考里面基本用不到不用花太多精力。记得有一年真题给了一段十行左右的伪代码要计算环路复杂度并指出基本路径的条数。环路复杂度的值就是基本路径的条数也是独立路径的上界。我从这道题里学到的经验是考场上一旦看到“圈复杂度”或者“环路复杂度”优先找判定语句if、while、for、case数清楚之后加一十秒钟出答案。3.3 黑盒测试等价类、边界值与判定表黑盒测试里最常考的是等价类划分和边界值分析两者几乎绑定出现。等价类划分是把输入域划分为若干个子集每个子集中的数据对发现错误是等效的然后从每个等价类中选取少量代表性数据作为测试用例。有效等价类验证程序是否实现了规格说明中的功能无效等价类验证程序能否正确拒绝非法输入。边界值分析则专门盯着输入域的边界因为大量错误往往发生在输入范围的边界附近而不是中间。经典例子是“输入1到100之间的整数”边界值要测0、1、2、99、100、101这六个数加上一个正常中间值比如50一共七个用例。考试中如果只让选一组最有效的答案一定是边界值而不是中间值。判定表法也是黑盒测试的高频工具适合处理“多个条件和多个动作”的场景。真题给一个判定表让你补全其中某个动作的取值。只要抓住两条规则列的“条件组合”决定该列的动作取值某条规则的条件如果包含了不可能组合则该规则可以合并。这种题的关键是细心把每个条件组合逐个对到表里一个都别漏。还有一类黑盒测试题考的是场景法或者错误推测法这类题通常放在下午的案例里让你根据业务流程设计测试场景。做法是梳理业务流程中的每个步骤把正常路径、异常路径、中断路径都列出来每条路径就是一个测试场景。4. 软件维护与配置管理容易被忽略的送分题4.1 四种维护类型一眼判断法软件维护这块的内容教材里篇幅不大但考试性价比极高。四个维护类型——改正性维护、适应性维护、完善性维护、预防性维护——几乎每年都考而且考法已经固化了给你一段具体场景让你判断属于哪种维护。我用一套“关键词判定法”来快速解题。改正性维护的关键词是“发现的错误”“缺陷”“故障”对应的是软件交付后暴露的bug这类维护占比约20%左右。适应性维护的关键词是“外部环境变化”“操作系统升级”“数据库版本更新”“新的法规”对应的是软件适应外部环境的变化占比约25%。完善性维护的关键词是“增加新功能”“改进性能”“提高易用性”这是占比最大的一类约50%。预防性维护的关键词是“为未来”“便于修改”“防止潜在问题”比如重构代码以提高可维护性占比约5%。考试最喜欢混淆的是适应性和完善性。记住一个判断标准外部环境变了你改软件是适应性你自己想加点功能提高用户体验是完善性。比如“操作系统从Windows 7升级到Windows 10软件需要调整兼容性”是适应性维护“软件增加了导出Excel报表的功能”是完善性维护。这两个例子记下来基本不会再错。4.2 可维护性与软件质量属性可维护性的度量在上午题里也会出现包括可理解性、可测试性、可修改性。可理解性考察的是别人能不能读懂你的代码与结构化程度、文档质量正相关可测试性考察的是软件是否容易设计测试用例、是否容易定位缺陷可修改性考察的是修改一个模块是否会引起大范围连锁反应与之直接相关的就是耦合度和内聚度。质量属性那边ISO/IEC 9126模型包含功能性、可靠性、易用性、效率、可维护性、可移植性六大特性。选择题最常见考法是给出一个具体描述让你选对应的质量特性比如“软件在一段时间内持续运行不出故障的能力”是可靠性“软件从一种环境迁移到另一种环境的能力”是可移植性“软件在单位时间内能处理的请求数量”是效率。另一个容易混淆的是可靠性和可用性。可靠性关注的是“不出故障”可用性关注的是“出故障后能多快恢复”两者的量化指标也不同可靠性用平均无故障时间MTBF衡量可用性用可用度系统正常运行时间占比衡量。历年真题里只要出现“平均无故障时间”答案基本上都在可靠性相关的选项里。4.3 配置管理核心概念配置管理在软考里属于理论性比较强的部分概念多但深度不深。核心概念有配置项、基线、配置控制委员会CCB、版本控制、配置审计。基线的定义是“一组经过正式评审和批准的配置项它作为后续开发工作的基础并且只能通过正式的变更控制流程才能修改”。这个定义是选择题的常考点注意关键词正式评审批准、基准、变更必须走流程。真题的干扰项通常会写成“基线可以随意修改”或者“基线是开发过程中的临时版本”一眼就能排除。配置控制委员会CCB负责审批变更请求做决策但不负责实施变更。这里的“负责审批、不负责实施”是选择题最爱挖的坑。我见过一道题选项说“配置管理员负责审批变更请求”这就是把CCB的职责安到了配置管理员头上属于典型的张冠李戴。配置管理员CMO的职责是版本管理、变更记录、配置审计的执行权限是“管”而不是“批”。版本控制这块软考主要考概念题比如“配置项的版本号规则”“受控状态下的配置项变更必须经过评审”等。另外还有个考法给你一个变更场景问变更控制的正确顺序。顺序是变更申请→变更评估→CCB审批→变更实施→变更验证与确认→变更发布并纳入基线。记住这个流程下午的案例题里如果让“指出变更控制流程中的错误”照着这个顺序对比就行了。5. 真题突破三道典型题的解题套路5.1 上午题模块间耦合类型判断拿一道典型的真题来说一个工资计算系统中的三个模块模块A读取员工基本信息模块B根据A传来的员工工资数据计算个税模块C直接修改了系统全局配置表中的参数供所有模块使用。问模块A与模块B之间、模块与全局配置表之间的耦合类型分别是什么。这道题的考点就是区分数据耦合、公共耦合和控制耦合。模块A传给B的是计算个税所需的工资数据是普通数据所以A到B是数据耦合。模块C修改的是供所有模块共用的全局配置表这属于公共数据区域所以C与系统之间的耦合是公共耦合。我做这类题的经验是先看模块间是否传递数据再看数据的性质。如果传递的是数据值选数据耦合或标记耦合具体看接收方是否使用全部字段如果传递的是控制标志选控制耦合如果共享公共区直接排除前面的选项在公共耦合和内容耦合之间选。大多数考题只要走到“数据还是控制”这一层就能锁定了。5.2 下午题给模块设计测试用例下午的测试题一般会给一段需求描述和模块代码或伪代码让你分别用等价类划分法和边界值分析方法设计测试用例。一类经典需求是“输入日期格式为YYYY-MM-DD年份范围1900到2100月份1到12日期1到月底”。如果要求用等价类划分法设计用例我会这样做年份的有效等价类是1900到2100无效等价类是小于1900和大于2100月份的有效等价类是1到12无效等价类是小于1和大于12日期需要结合月份判断可以粗分为有效日期和无效日期两类。每个有效等价类至少取一个代表值每个无效等价类也要单独设计用例因为程序往往对每个无效输入都有独立的错误提示。如果题目要求用边界值分析那年份边界就是1900、2100、1899、2101月份边界是1、12、0、13日期边界就取1、31和非法日期。边界值分析法的精髓是“把测试用例尽量往上边界和下边界凑”许多缺陷都发生在边界附近。我写这类题时有个习惯先把有效类和无效类单独列成两行再在每个类下面举出对应的测试输入和预期输出。这样阅卷老师一眼就能看到你的分析逻辑也方便自己写完复查有没有漏掉无效等价类。下午题是按点给分的分析过程比最终答案重要宁可多写一步推导也不能只写一个结论。5.3 案例分析软件维护类型判断与变更流程案例分析里维护类型的题通常是这样给出一个系统上线运营半年内的四条维护记录分别是修复了客户对账报表中某个计算公式的错误将数据库从MySQL 5.7升级到8.0后调整了连接配置根据客户需求增加了按部门汇总的统计功能重构了登录模块代码以提高后续修改的效率。问这四条分别属于哪种维护类型。第一条是修复已知错误对应改正性维护第二条是数据库环境升级后的适配对应适应性维护第三条是新增功能对应完善性维护第四条是为后续修改方便而重构对应预防性维护。这道题只要记住了四种类型的关键词一条条对号入座就行基本属于送分题。变更流程那道题常见错误是做变更时不写变更申请直接改代码改完之后不做回归测试变更完成之后没有更新基线。我在答题时会拿“申请→评估→审批→实施→验证→发布”这个六步流程当模板对照题干描述逐条找缺失或错误基本能拿全这部分的分数。6. 备考安排与避坑指南6.1 时间分配建议这章到底该花多久我给在职备考的同事的普遍建议是如果每天能坚持学1到2个小时这一章整体规划三到四周比较合理。第一周学软件设计部分重点是内聚耦合和数据流图第二周学测试部分重点是白盒黑盒方法和测试用例设计第三周学维护与配置管理这部分纯概念两到三天就能消化完剩余时间做历年真题第四周专门做错题回顾和下午题模拟。上午题和下午题的学习要同步推进不能只刷上午题。我的经验是上午题用来检查概念记忆是否牢固下午题用来检查分析能力是否达标。很多考生上午题能做对但下午题的案例分析题写不出完整的推理过程就是因为概念是背的没真正理解。每天花30分钟专门练一道下午题比周末集中做一套题效果要好。6.2 错题本应该怎么记按考点归因这一章的概念多、坑多错题本必须有但不能照抄题目。我的做法是把每道错题归因到具体考点比如“这道题错了是因为我把控制耦合和标记耦合搞混了”然后单独开一页写清楚这两者的区分方法附带一道对应真题和一句自己的理解。归因比抄题重要得多。原因很简单软考不考原题你抄再多的题目换个马甲可能依然不会。而归因能让你发现自己的薄弱模式。我当年统计过我的错题里有一半以上集中在控制耦合和适应性维护这两个点上针对性补强之后下午题模拟的正确率明显上升。错题本每周至少翻一遍考前两周只看错题本和总结的表格不再翻教材。如果错题本内容太多说明你还在“无效刷题”阶段需要停下来分析是不是基础知识没打牢。我当时整理完内聚耦合的排序表错题率直接下降一半可见结构化总结比盲目刷题高效得多。6.3 考场上的速答技巧与时间控制上午题这一章的内容单题作答时间控制在60秒以内。判断题要善于利用教材中的标准表述比如基线的定义、CCB的职责这类概念题选最贴近教材原文的一项不要自己发挥。经验性判断的题比如给场景判断维护类型用关键词匹配法看到“新功能”就选完善性维护看到“环境变化”就选适应性维护。下午题的时间控制更关键。建议先花5分钟浏览全部题目优先做自己最熟练的数据流图补全或测试用例设计题把复杂的面向对象设计题放到后面。测试用例设计题一定要把“输入、预期输出、覆盖的等价类或边界”写清楚不要只写输入数据。阅卷看的是分析过程不是最终答案。有个小技巧下午题答题时如果题目要求你指出设计中的错误每条错误尽量使用“模块XXX存在YYY问题应该ZZZ”的句式一条一行不要写成一整段。这样阅卷老师工作量小你的得分点也清晰。我在实际备考过程中的一点体会是这一章的内容说到底是“软件工程常识”的浓缩考点并不深奥但它考察的是你能不能站在工程角度思考问题。如果你平时写代码习惯性复制粘贴、从不考虑模块划分和测试用例学这章就会觉得抽象难懂反过来如果你养成了写模块先想接口、改代码先看影响面的习惯这章就是整场考试里最轻松的部分。所以不要只为了考试去背知识点试着把这些设计思想和测试方法带到你自己写的代码里你会发现软考的很多题目其实就是帮你审视自己做过的项目哪里出了问题。
![[AutoSar]在Davinci Configurator中导入Dbc Cdd 文件](http://pic.xiahunao.cn/yaotu/[AutoSar]在Davinci Configurator中导入Dbc Cdd 文件)
