05-系统技术架构师必备——软件工程方法与UML建模体系

关键词UML建模、Scrum、敏捷开发、软件测试、白盒测试、McCabe复杂度、瀑布模型、RUPUML软件工程敏捷开发软件测试ScrumRUP系统架构建模系统技术架构师必备——软件工程方法与UML建模体系摘要UML建模和软件工程方法是系统技术架构师与开发团队沟通的通用语言。本文深入讲解UML 2.x的13种图、软件开发模型的选型策略、白盒测试覆盖强度的完整 hierarchy以及McCabe环路复杂度的实际计算方法。文章包含笔者在多个大型项目中的建模经验和测试策略设计案例。一、架构师是团队的翻译官为什么UML建模能力决定你的上限做了十几年技术我越来越深刻地认识到一个事实架构师的核心能力不是写代码而是沟通。你要跟产品经理沟通业务需求跟开发团队沟通技术方案跟测试团队沟通质量要求跟运维团队沟通部署策略。如果每个沟通场景都用各自的语言项目很快就会陷入混乱。2016年我加入一个大型银行的核心系统改造项目项目团队有将近200人外包人员占了一大半。当时最大的痛点不是技术难度而是沟通效率。产品经理写的需求文档是Word格式的开发人员看完按照自己的理解开始编码测试人员又按照另一套理解写测试用例。到了集成测试阶段发现三方理解完全不一致返工的工作量超过总工时的30%。后来我们引入了UML作为统一建模语言强制要求所有需求必须用用例图描述所有接口设计必须有时序图所有状态流转必须有状态机图。刚开始团队有抵触情绪觉得画图浪费时间但推行了两个月之后大家明显感觉到返工率下降了新人上手速度变快了跨团队沟通顺畅多了。UML的价值不在于图本身而在于它提供了一套标准化的视觉语言让不同背景的人能够基于同一套符号体系进行交流。架构师作为技术团队的枢纽如果不会UML就像一个翻译官不懂外语根本无法胜任自己的角色。我在面试架构师候选人时经常会问一个开放性问题请描述一下你最近设计的一个系统的架构。如果候选人只能口述或者用一些不标准的符号在白板上乱画我通常会打一个大大的问号。一个合格的架构师应该能够用标准的UML图清晰地表达系统的静态结构和动态行为。当然UML也不是万能的。我反对为了画图而画图画一堆没人看的模型那是形式主义。UML的正确用法是刚好够用——在需要澄清复杂逻辑的时候画一个时序图在需要跟业务方确认需求范围的时候画一个用例图在需要梳理状态流转的时候画一个状态机图。每一张图都应该有其明确的目的和受众。下面我就结合自己的实战经验系统地梳理一下UML 2.x的建模体系和软件工程方法。二、UML 2.x建模体系全景结构图 vs 行为图UML 2.x规范定义了13种图分为两大类结构图Structure Diagram和行为图Behavior Diagram。这个分类本身就很有启发性——结构图描述的是系统由什么组成行为图描述的是系统能做什么。--------------------------------------------------------------- | UML 2.x 13种图 | --------------------------------------------------------------- | | | --------------------- ----------------------------- | | | 结构图(6种) | | 行为图(7种) | | | --------------------- ----------------------------- | | | 类图(Class) | | 用例图(Use Case) | | | | 对象图(Object) | | 活动图(Activity) | | | | 组件图(Component) | | 状态机图(State Machine) | | | | 部署图(Deployment) | | 序列图(Sequence) | | | | 包图(Package) | | 通信图(Communication) | | | | 组合结构图(Composite)| | 交互概览图(Interaction) | | | | | | 时序图(Timing) | | | --------------------- ----------------------------- | | | ---------------------------------------------------------------在这13种图中实际工作中最常用的是类图、用例图、序列图、状态机图、活动图和组件图。其他的几种图使用频率较低但在特定场景下也很有价值。比如对象图用于展示系统在某一时刻的快照部署图用于描述系统的物理部署拓扑。我在一个物联网平台项目里大量使用组件图来描述系统的模块划分。那个项目涉及设备接入层、数据处理层、业务逻辑层、展示层四个层次每个层次内部又有多个组件。用组件图可以清晰地表达组件之间的依赖关系和接口契约比纯文字描述要直观得多。包图在大型项目的代码组织阶段也很有用。它可以展示代码的命名空间/包结构以及包之间的依赖关系。我在代码评审时发现如果包之间的依赖关系形成了环那说明架构设计上存在问题需要通过包图来识别和消除这些循环依赖。三、类图四种关系深度解析依赖、关联、聚合、组合、泛化类图是UML中最基础也最重要的图它展示了系统的静态结构类、接口以及它们之间的关系。很多开发者对类图里的各种箭头分不清楚这里我用一个循序渐进的方式来梳理。类图中的关系从弱到强可以分为四个层次依赖 关联 聚合/组合 泛化。依赖Dependency是最弱的关系用带箭头的虚线表示。它表示一个类的变化可能会影响到另一个类。典型场景是一个类的方法参数、局部变量或者返回值用到了另一个类。------------------ ------------------ | OrderService |-------------| PaymentClient | | | use | | ------------------ ------------------依赖关系的特点是临时性和单向性。OrderService在执行某个方法时临时用到了PaymentClient但PaymentClient不是OrderService的一个固有组成部分。关联Association比依赖更强用实线表示。它表示两个类之间有结构化的连接关系。关联可以是有方向的单向关联也可以是无方向的双向关联。------------------ 1 * ------------------ | Department |----------| Employee | ------------------ ------------------ | | | 1 | 1..* v v --------- --------- | Manager | | Staff | --------- ---------关联关系通常对应类的成员变量。如果一个类把另一个类作为自己的属性长期持有那就是关联关系。关联关系还可以表达多重性multiplicity比如一个部门有多个员工1对多一个员工只能属于一个部门多对1。聚合Aggregation和组合Composition都是关联的特殊形式表达的是整体-部分的关系。聚合用空心菱形表示组合用实心菱形表示。两者的区别是聚合的部分可以独立于整体存在组合的部分不能独立于整体存在。聚合关系 组合关系 ------------------ ------------------ | University |----------o| Department | | | | | ------------------ ------------------ | | 组合的部分不能 | 独立于整体存在 v --------- | Office | ---------举个实际的例子大学University和系Department是聚合关系——如果大学解散了系还可以并入其他大学继续存在。订单Order和订单项OrderItem是组合关系——如果订单被删除了订单项也就没有任何意义了必须同时删除。我在建模时的一个经验是如果你不确定是聚合还是组合可以先画关联关系然后在代码实现阶段根据生命周期的依赖关系来判断。如果部分的创建和销毁与整体绑定那就是组合如果部分可以独立创建和销毁那就是聚合。泛化Generalization是最强的关系用带空心三角形的实线表示。它就是我们常说的继承关系子类继承父类的属性和方法。------------------ | PaymentMethod | | pay() | ------------------ /_\ | ---------- | | ---v--- ---v-------- | Alipay | | WeChatPay | -------- ------------泛化关系在类图中非常容易识别但使用时需要特别谨慎。我在前面讲LSP的时候提到过继承是强耦合关系一旦使用了继承子类就彻底绑定了父类的实现。在现代的面向对象设计中有一条经验法则优先使用组合而非继承。当你想表达is-a关系时先考虑是否可以用接口来实现只有当确实存在代码复用的需求且继承层次很浅时才考虑用类继承。四、用例图三种关系包含、扩展、泛化的精准使用用例图是UML中唯一直接面向业务人员的图它描述了系统的功能需求以及用户参与者与这些功能之间的交互。用例图看似简单但要画好并不容易尤其是三种关系include、extend、generalization的用法很多人经常搞混。包含关系Include表示一个用例的行为总是包含另一个用例的行为。典型的场景是多个用例共享一段共同的流程。比如下单、“退货”、换货三个用例都需要用户登录验证这个步骤那么就可以抽取出用户登录验证作为一个独立的用例被其他用例包含。-------- | 用户 | ------- | --------------------- | | | | v v v v ----- ---- ---- ---- | 下单 | | 退货 | | 换货 | | ... | ----- ---- ---- ---- | | | -------------- | v --------------- | include | | 用户登录验证 | ----------------包含关系的特点是强制性的。执行包含用例时被包含的用例一定会执行。这对应代码中的子程序调用。扩展关系Extend表示在特定条件下一个用例的行为可以扩展另一个用例的行为。扩展是有条件的、可选的。比如下单用例可以扩展一个使用优惠券的行为但不是所有下单都会使用优惠券。-------- -------- | 用户 | | 用户 | ------- ------- | | v v ------ ---------- | 下单 |------------------|extend | ------ | 使用优惠券 | | ----------- v ------- | 支付 | -------扩展关系的特点是条件触发。只有当扩展点满足特定条件时扩展用例才会执行。这对应代码中的条件判断或者AOP的切面逻辑。我在建模时判断用include还是extend的经验是如果这段逻辑是一定要做的用include如果是可能做也可能不做取决于条件的用extend。另一个判断角度是如果从多个用例中提取的公共逻辑用include如果一个用例在特定场景下有额外的行为用extend。泛化关系Generalization在用例图中表示用例之间的继承关系。子用例继承父用例的行为并可以重写或者扩展。比如支付是一个父用例“支付宝支付”、“微信支付”、银行卡支付是它的子用例。-------- | 用户 | ------- | v -------------- | 支付 | -------------- / | \ / | \ v v v ------ ---- ----- | 支付宝 | | 微信 | | 银行卡| ------- ----- ------用例泛化在实际的业务建模中并不常用因为用例的粒度通常不需要到这么细的层次。但如果你确实需要表达多种实现方式的概念用例泛化是一个合理的选择。五、序列图 vs 通信图什么时候画时序图什么时候画协作图序列图Sequence Diagram和通信图Communication DiagramUML 1.x中叫协作图都是交互图描述的是对象之间的消息传递。但它们关注的侧重点不同序列图强调时间顺序通信图强调对象之间的链接关系。序列图是我日常工作中使用频率最高的UML图之一。它清晰地展示了参与交互的对象按时间顺序发送和接收的消息。横轴是参与交互的对象纵轴是时间从上到下推进。用户 前端App API网关 订单服务 库存服务 数据库 | | | | | | |--------| | | | | 提交订单 | |---------| | | | 请求创建订单 | | |---------| | | 校验参数 | | | |---------| | 扣减库存 | | | | |---------| 更新库存 | | | | |---------| 返回结果 | | | |---------| 库存扣减成功 | | | |-------------------| 保存订单 | | | |-------------------| 返回订单ID | | |---------| | | 返回订单信息 | |---------| | | | 返回响应 |--------| | | | | 展示结果我在画序列图时通常遵循以下规范第一对象从左到右按调用顺序排列发起者在最左边依赖者在最右边。第二同步调用用实线箭头返回消息用虚线箭头。第三激活条Activation Bar表示对象正在处理消息的时间段这有助于识别性能瓶颈。第四循环和条件分支用alt、loop、opt等组合片段Combined Fragments来表示。通信图则更适合展示对象之间的结构关系。它用对象之间的链接线来表示它们可以通信消息编号表示调用的顺序。通信图的优势在于可以在一张图里展示更多的对象和它们之间的复杂关系劣势是对时间顺序的表达不如序列图直观。----------------- | OrderService | ---------------- | -------------------------------- | 1: createOrder() | | v v v ------------- ------------ ----------- | OrderRepo | | InventorySvc| | PaymentSvc | ------------- ------------ ----------- | 2: save() | 1.1: deduct() | 1.2: pay() v v v ---- ------ ------- | MySQL | | Redis | | 支付宝 | ------- ------- --------我通常在以下场景选择序列图需要精确展示消息的时间顺序需要表达复杂的控制流循环、条件、并行需要分析性能瓶颈。在以下场景选择通信图需要展示大量对象之间的复杂链接关系对象的拓扑结构比消息顺序更重要需要在一张图里展示全局的交互概览。从UML 2.x开始交互概览图Interaction Overview Diagram把活动图和交互图结合了起来可以在高层用活动图展示流程在具体的步骤中嵌入序列图或通信图。我在写架构设计文档时经常用这种组合方式既保证了高层概览的清晰又能在需要时展开详细的交互逻辑。六、状态机图在复杂业务中的应用状态机图State Machine Diagram描述了一个对象在其生命周期内所经历的状态序列以及引起状态转移的事件和动作。这个图在处理复杂业务状态时非常有价值但经常被国内开发团队忽视。我在一个供应链金融平台项目中深刻体会到了状态机图的价值。那个平台的核心业务流程是融资申请一个申请单从创建到放款要经历十几个状态草稿→已提交→风控审核中→风控通过→风控拒绝→人工复核中→复核通过→合同签署中→合同已签→放款审批中→放款通过→已放款→还款中→已结清。每个状态下允许的操作不同状态之间的转移有严格的规则。最初开发团队没有用状态机图状态转移的逻辑散落在各个Service方法里。结果上线后频繁出现状态不一致的问题同一个申请单被两个人同时操作最终状态跟预期不符某些状态下本不该允许的操作被执行了退款后状态没有正确回退。我介入后做的第一件事就是画了一张完整的状态机图跟业务方逐条确认状态转移规则。-------- | 草稿 | ------- | submit() v ---------------- | 已提交 | ---------------- | autoAudit() ------------------------ | | v v ---------------- ---------------- | 风控审核通过 | | 风控拒绝 | ---------------- ---------------- | | manualReview() | contract() v v ---------------- ---------------- | 人工复核中 | | 合同签署中 | ---------------- ---------------- | approve() / reject() | contractSigned() v v ---------------- ---------------- | 复核通过/拒绝 | | 放款审批中 | ----------------- ---------------- | approveLoan() v ---------------- | 已放款 | ---------------- | startRepayment() v ---------------- | 还款中 | ---------------- | complete() v ---------------- | 已结清 | -----------------有了这张图之后我们把状态转移的逻辑集中到了一个状态机引擎里所有的状态转移都必须通过引擎来执行引擎负责校验转移的合法性、执行转移前后的动作、记录转移历史。状态不一致的问题迎刃而解。状态机图的一个关键概念是转移Transition它由三部分组成触发事件Event、守卫条件Guard和动作Action。用完整的语法表示就是event [guard] / action。比如 submit() [amount 10000] / sendToRiskEngine 表示当提交事件发生时如果金额大于10000就发送到风控引擎。对于复杂的状态机UML还提供了子状态机Submachine State和组合状态Composite State的概念可以把一个大的状态机拆分成多个层次每一层关注不同粒度的状态。我在一个电商订单系统里用过这种分层状态机顶层是订单的粗粒度状态待支付、已支付、已发货、已完成已支付内部又细分为拣货中、已打包、待出库等子状态。七、软件开发模型选型没有银弹软件开发模型规定了软件开发过程中各阶段的顺序、活动和交付物。作为架构师选择合适的开发模型是项目成功的重要前提。不同的项目、不同的团队、不同的环境适合的模型完全不同。7.1 瀑布模型银行核心系统的无奈之选瀑布模型是最传统的软件开发模型把开发过程划分为需求、设计、编码、测试、维护等线性阶段每个阶段完成后才进入下一个阶段。---------- ---------- ---------- ---------- ---------- | 需求分析 | - | 系统设计 | - | 编码实现 | - | 测试验证 | - | 运维交付 | ---------- ---------- ---------- ---------- ---------- | | | | | v v v v v 需求规格 设计文档 源代码 测试报告 用户手册 说明书 (概要/详细) 可执行程序 缺陷报告 部署文档瀑布模型的优点是阶段清晰、文档完备、管理简单。但它有一个致命的假设需求在项目初期就可以被完全确定而且在后续阶段不会发生变化。这个假设在现实世界中几乎从未成立过。然而我在一个银行核心系统的项目中却不得不选择了瀑布模型。不是因为瀑布有多好而是因为银行的监管要求决定了它必须这样。银行的核心系统变更需要经过严格的审批流程每个阶段必须有完备的文档留痕监管部门要审查需求规格说明书、设计文档、测试报告。在这种环境下敏捷开发的快速迭代反而会成为合规的障碍。所以我的观点是没有最好的模型只有最合适的模型。在强监管、需求稳定的场景下瀑布模型仍然是合理的选择。但在互联网产品这种需求变化快的场景下瀑布模型就是不合适的。7.2 螺旋模型风险驱动的迭代螺旋模型由Barry Boehm在1988年提出它把瀑布模型的系统化和快速原型的迭代特征结合起来并加入了风险分析。螺旋模型的核心思想是软件开发是一个不断降低风险的过程。计划 | v 风险分析 --------------------- 工程实施 ^ | | v --------------------------- 客户评估螺旋模型把项目分成多个周期cycle每个周期经历四个象限制定计划、风险分析、工程实施、客户评估。每个周期产出一个原型风险被逐步识别和消除。我在一个大型ERP系统的开发中用过螺旋模型。那个项目的需求非常复杂涉及多个业务部门的流程重组很多需求在初期根本无法明确。我们用螺旋模型第一个周期做了一个原型来验证技术可行性第二个周期验证了核心业务流程第三个周期集成了外部系统接口第四个周期才进入完整的开发和测试。每个周期结束后都有明确的决策点继续下一个周期还是调整方案还是终止项目。螺旋模型特别适合大型、复杂、高风险的项目。但它的成本也比较高每个周期都需要做风险评估和原型开发对于小型项目来说可能得不偿失。7.3 RUP四阶段先启→细化→构建→移交Rational Unified ProcessRUP是IBM提出的一种重量级迭代开发框架。它把项目生命周期划分为四个顺序的阶段每个阶段包含一个或多个迭代。---------- ---------- ---------- ---------- | 先启 | -| 细化 | -| 构建 | -| 移交 | | Inception| | Elaboration| |Construction| | Transition | ---------- ---------- ---------- ---------- | | | | v v v v 确定项目 分析核心 开发剩余 部署到 范围和 架构消除 构件完成 生产环境 可行性 主要风险 所有功能 用户培训 里程碑 里程碑 里程碑 里程碑 生命周期 生命周期 初始运行 产品发布 目标 架构基线 能力先启Inception阶段的目标是确定项目的范围和可行性产出项目愿景和用例模型。细化Elaboration阶段的目标是分析核心架构消除主要的技术风险产出架构基线。构建Construction阶段是主要的编码和测试阶段完成系统的所有功能。移交Transition阶段把系统部署到生产环境进行用户培训和系统切换。RUP的一个核心理念是用例驱动、架构中心、迭代增量。用例驱动意味着所有的开发活动都围绕用例展开架构中心意味着架构设计在早期就要确定并作为后续开发的基线迭代增量意味着系统是一步步构建出来的每个迭代都有可运行的增量。我在2009年到2012年期间参与过几个用RUP方法论的项目。客观地说RUP的理论体系非常完善但实施成本也很高。它需要专门的工具支持Rational Rose、ClearCase等需要大量的文档和评审对于中小团队来说负担较重。后来敏捷方法论兴起后RUP逐渐被Scrum、Kanban等轻量级框架取代。但RUP中的一些思想比如架构基线、风险驱动的迭代仍然值得借鉴。7.4 敏捷开发四条价值观、十二条原则敏捷开发是我在过去十年中使用最多的方法论。它不只是一个具体的开发模型更是一套价值观和原则。敏捷宣言的四条价值观是个体和互动高于流程和工具工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划。这四条价值观不是说要放弃流程、文档、合同和计划而是说在发生冲突时左边的价值优先于右边。很多对敏捷的误解都源于把这句话理解成了不要文档、不要计划。敏捷宣言的十二条原则进一步阐述了这些价值观。其中我最认同的几条是第一我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。这意味着迭代周期要短每个迭代都要交付可工作的软件而不是等到项目结束才给客户看成果。第二欢迎对需求提出变更即使在开发后期也一样。这与瀑布模型完全相反敏捷认为变化是不可避免的与其抵制变化不如建立响应变化的能力。第三工作的软件是进度的首要度量标准。这句话对架构师特别重要。很多架构师喜欢画精美的架构图、写详细的设计文档但这些都不是真正的进度。只有能跑起来的代码才是进度。我在推行敏捷的团队中通常会把迭代周期控制在两周。两周足够完成一个有价值的用户故事又不会因为周期太长而失去灵活性。每个迭代结束都有可演示的软件每个迭代开始都有计划会议每天都有站会同步进度每个迭代结束都有回顾会议总结经验。八、软件测试策略质量不是测出来的是设计出来的作为架构师我对测试的态度有一个转变的过程。早年我觉得测试是测试团队的事开发只要把功能做出来就行。后来经历了几次因为测试覆盖不足导致的线上事故我才深刻认识到质量是设计出来的不是测出来的但测试是验证质量的重要手段。8.1 白盒测试覆盖强度层次白盒测试White-box Testing基于代码的内部结构来设计测试用例。白盒测试有多种覆盖标准它们构成了一个层次关系------------------------------------------------------------------ | 白盒测试覆盖强度层次 | ------------------------------------------------------------------ | | | 语句覆盖 (Statement Coverage) | | | | | v | | 判定覆盖 / 分支覆盖 (Decision/Branch Coverage) | | | | | v | | 条件覆盖 (Condition Coverage) | | | | | v | | 判定-条件覆盖 (Decision-Condition Coverage) | | | | | v | | 条件组合覆盖 (Multiple Condition Coverage) | | | | | v | | 路径覆盖 (Path Coverage) ---- 最强但通常不可行 | | | ------------------------------------------------------------------语句覆盖是最弱的覆盖标准要求每条可执行语句至少被执行一次。但它不能保证所有的判定分支都被覆盖。比如一个if语句如果测试用例只覆盖了true分支false分支没覆盖语句覆盖指标可能显示100%但实际上有一个分支没测到。判定覆盖也叫分支覆盖要求每个判定的true和false分支都至少执行一次。这比语句覆盖强但还不够。比如一个判定条件是A B判定覆盖只要求整个判定的结果为true和false各一次但条件A和B各自为true/false的组合可能没覆盖全。条件覆盖要求每个条件的所有可能取值都至少出现一次。比如A B要求A为true和false都出现过B为true和false也都出现过。但条件覆盖有一个问题它可能只覆盖了条件的取值但没覆盖判定的结果。比如测试用例1Atrue, Bfalse判定结果为false测试用例2Afalse, Btrue判定结果也为false。两个条件都覆盖到了但判定结果始终为false。判定-条件覆盖结合了判定覆盖和条件覆盖要求每个判定的所有结果都出现且每个条件的所有取值也都出现。这比单独的判定覆盖或条件覆盖都强。条件组合覆盖要求每个判定中所有条件的各种可能组合都至少出现一次。比如A B有四种组合(true,true)、(true,false)、(false,true)、(false,false)四种都要覆盖。这是最严格的覆盖标准之一但测试用例数量会随条件数指数增长。路径覆盖要求覆盖程序中所有可能的执行路径。理论上最强但对于有循环的程序路径数是无限的所以实际上不可行。我在团队里通常要求核心业务的单元测试至少达到判定覆盖Branch Coverage80%以上关键路径要达到条件组合覆盖。Jacoco是Java项目里常用的覆盖率工具它可以生成详细的覆盖率报告包括类、方法、行、分支等维度的覆盖情况。8.2 McCabe环路复杂度McCabe环路复杂度Cyclomatic Complexity是衡量代码复杂度的经典指标由Thomas McCabe在1976年提出。它衡量的是一个模块的判定结构的复杂程度复杂度越高测试和维护的难度越大。McCabe环路复杂度的计算有三种等价的方法方法一V(G) E - N 2P其中E是控制流图中的边数N是节点数P是连通分量的个数通常P1。方法二V(G) 判定节点数 1其中判定节点指的是产生分支的语句比如if、while、for、case等。注意switch语句中每个case都算作一个判定节点和||的每个条件也算作一个判定节点在短路求值的语义下。方法三V(G) 区域数把控制流图看作平面图区域数包括外部区域就是环路复杂度。举个例子publicvoidprocess(Orderorder){if(ordernull){// 判定节点1thrownewIllegalArgumentException();}if(order.getAmount()100){// 判定节点2applyDiscount(order);}for(Itemitem:order.getItems()){// 判定节点3checkInventory(item);}}这个方法的判定节点数是3两个if一个for所以V(G) 3 1 4。这意味着至少需要4个测试用例才能达到判定覆盖。McCabe建议模块的环路复杂度应该控制在10以下。超过10的模块通常意味着逻辑过于复杂应该考虑重构拆分。我在代码评审时会把SonarQube扫描出来的高复杂度方法作为重点关注对象要求开发者给出重构方案。但环路复杂度也不是越低越好。我见过有人为了降低复杂度把本来逻辑内聚的代码强行拆分成多个方法结果代码变得更加跳跃难读。我的建议是如果一个方法的逻辑天然就是复杂的比如一个状态机的核心流转逻辑适当的高复杂度是可以接受的但要通过清晰的命名和注释来弥补。8.3 测试分层策略软件测试不是单一的活动而是一个分层的体系。从下到上通常分为单元测试、集成测试、系统测试、验收测试。------------------------------------------------------------- | 验收测试 (Acceptance) | | 用户视角验证业务价值 | | 自动化/手工测试 | ------------------------------------------------------------- | 系统测试 (System) | | 端到端测试验证完整系统行为 | | API测试、UI自动化测试 | ------------------------------------------------------------- | 集成测试 (Integration) | | 模块间接口测试验证协作正确性 | | 数据库集成、消息队列集成、外部服务集成 | ------------------------------------------------------------- | 单元测试 (Unit) | | 开发者视角验证最小功能单元 | | 隔离依赖Mock外部组件 | -------------------------------------------------------------单元测试是最基础的测试由开发者在编码阶段编写。单元测试应该只测试一个最小的功能单元通常是一个方法并且隔离所有的外部依赖。Spring框架里的MockBean、Mockito框架都是用来做依赖隔离的。我要求团队里的核心代码必须达到单元测试的判定覆盖80%以上。这个数字不是拍脑袋定的而是基于行业经验和我们的项目特点。覆盖率达到80%以上时剩余的未覆盖代码通常是异常分支和防御性代码对核心逻辑的影响较小。集成测试验证多个模块协作时的正确性。比如订单服务和库存服务的集成测试要验证下单时库存确实被扣减了取消订单时库存确实被恢复了。集成测试通常需要连接真实的数据库、消息队列等基础设施所以执行速度比单元测试慢。我在项目中引入了TestContainers来管理集成测试的依赖。TestContainers可以在测试运行时自动启动Docker容器MySQL、Redis、Kafka等测试结束后自动销毁。这样每个开发人员都可以在本地运行完整的集成测试不需要依赖共享的测试环境。系统测试验证整个系统的功能和非功能需求。系统测试通常由QA团队主导包括功能测试、性能测试、安全测试、兼容性测试等。自动化系统测试通常基于SeleniumWeb UI、Appium移动端或者RestAssuredAPI。验收测试是用户视角的测试验证系统是否满足业务需求。验收测试通常由业务人员或者产品经理参与可以是手动的UATUser Acceptance Testing也可以是基于BDDBehavior Driven Development框架如Cucumber的自动化测试。我在推行测试策略时有一个测试金字塔的理念单元测试应该最多占比70%以上集成测试次之占比20%左右系统测试和UI测试最少占比10%左右。这样的金字塔结构能保证测试的稳定性底层测试不容易因为UI变动而失败和执行效率底层测试执行速度快。九、形式化方法安全攸关系统的数学验证形式化方法Formal Methods使用数学化的规约语言和验证技术来保证软件系统的正确性。它跟传统的测试方法有本质区别测试只能证明缺陷存在不能证明缺陷不存在而形式化方法可以通过数学证明来确保系统在某些属性上是完全正确的。我在一个轨道交通信号系统的项目中接触过形式化方法。那个项目的安全等级要求达到SIL 4Safety Integrity Level 4是最高安全等级。在这种场景下传统的测试方法是不够的因为测试无法覆盖所有可能的输入组合和执行路径。形式化方法通常包括两个核心活动形式化规约Formal Specification和形式化验证Formal Verification。形式化规约用精确的数学语言来描述系统的行为消除自然语言描述的歧义。常用的规约语言有Z语言、B方法、VDM、TLA等。我在那个轨道交通项目里用的是B方法它基于集合论和一阶逻辑可以把系统的状态和状态转移用数学公式精确描述。形式化验证则通过定理证明或者模型检测来验证系统是否满足其规约。定理证明需要人工辅助把系统的正确性证明分解成一系列引理然后用证明工具如Coq、Isabelle来辅助验证。模型检测则是自动化的它遍历系统的所有可能状态检查是否有违反规约的情况。形式化方法的优点是它能在开发早期发现设计层面的缺陷而且这些缺陷用测试是很难发现的。缺点是成本极高需要专门的培训和工具而且只适用于规模相对较小的关键模块。对于大多数业务系统来说形式化方法是不必要的。但在航空航天、核能、轨道交通、医疗器械等安全攸关的领域形式化方法是确保系统安全的重要手段。作为架构师我们需要了解形式化方法的存在和适用场景即使我们自己在日常工作中不直接使用它。十、结语UML建模和软件工程方法是架构师的基本功但这并不意味着我们要成为画图狂魔或者流程奴隶。工具的价值在于帮助我们更好地思考和沟通而不是取代思考本身。回顾我这些年的实践我认为一个好的架构师应该具备这样的能力面对复杂的业务需求能够快速选择合适的UML图来梳理和表达面对不同的项目特点能够选择合适的开发模型和测试策略面对团队的不同成熟度能够找到规范和效率的平衡点。建模和工程方法的学习没有捷径唯一的途径就是在实际项目中不断实践、反思和改进。画一百张图不如认真画好一张图学十种模型不如精通一两种最适合你团队的模型。希望这篇文章能给你的架构实践带来一些启发。文章声明本文仅供学习参考请勿用于商业用途。