共计 2483 个字符，预计需要花费 7 分钟才能阅读完成。
深刻理解测试过程中被测系统的架构与数据流，有助于了解业务逻辑，梳理业务用例以及促成部门协同。
更深的了解业务逻辑是指要剖析公司是做什么的，公司的重要的商务决策是什么，公司外部数据流是怎么运行的，有哪些常见的业务场景。这也能考验对公司业务的负责水平，能够更好的去服务业务部门，为公司发明价值。
开源我的项目 litemall 零碎架构上面以开源我的项目 litemall 为例，剖析一下这个我的项目中的零碎架构。
litemall 这款产品是一个小的商城，以 SpringBoot 作为后端，Vue 管理员联合微信小程序作为前端，Vue 用户作为挪动端。
零碎架构 litemall 的零碎架构如图所示：
编辑
技术架构
litemall 的技术架构如图所示：
编辑
开源我的项目 Mall 的零碎架构
Mall 我的项目是一套电商零碎，包含前台商城零碎及后盾管理系统，基于 SpringBoot + MyBatis 实现，采纳 Docker 容器化部署。前台商城零碎蕴含首页门户、商品举荐、商品搜寻、商品展现、购物车、订单流程、会员中心、客户服务、帮忙核心等模块。后盾管理系统蕴含商品治理、订单治理、会员治理、促销治理、经营治理、内容治理、统计报表、财务管理、权限治理、设置等模块。
零碎架构
Mall 的零碎架构如图所示：
编辑
业务架构
Mall 的业务架构如图所示：
编辑
公司架构组成
通过 litemall 和 mall 两个开源我的项目能够看出，为了更好的服务公司，须要理解公司的架构，公司架构个别分为业务架构和零碎架构。
业务架构
商业模式：也是目前大家最关怀的问题，公司怎么使得收益最大化。例如抖音的盈利模式以及其中裂变零碎是怎么参加的，这就须要理解你身处的业务部门的业务模式以及技术栈，以及公司的倒退模式与将来趋势。业务数据：理解角色、资源和数据。例如公司的账户管理中心中的角色有管理员、用户等，而这些角色又能够分为输入内容的人和生产内容的人，除了角色，还须要理解公司平台上的外围资源的品种以及数据信息。业务流程：理解业务数据中角色，角色的行为以及数据之间的集成关系。零碎架构
零碎架构就是要把业务架构进行落地施行，实现其中的商业模式与业务流程。
架构角色与技术栈：架构角色根本不会变，而技术栈会随着技术的倒退而一直变动。其中的具体实现有：网关：Apache/Nginx/F5
利用开发：SpringBoot/SpringCloud
通信协定：Dubbo/HTTP/PB
数据处理：Hadoop/Spark/Flink
数据存储：Redis/MySQL/Oracle/ES
文档存储：MongoDB/HBase/Neo4j
部署架构：架构角色的集成关系，对应业务架构中的业务流程。建模语言 UML
为疾速理解公司的架构，能够应用对立的建模语言 UML 来剖析公司架构。罕用的编译语言工具有：
plantuml（举荐）yed
draw.io
processon
visio (不罕用)
以 plantuml 工具为例，能够设计以下图模型剖析公司架构：
用例图：用来形容商业模式、业务角色
时序图：用来形容业务流程、调用关系
部署图：用来形容零碎架构与集成关系
流动图：用来剖析业务逻辑
应用用例图梳理业务流程
@startuml left to right direction actor User as user actor Admin as admin package 商品 {usecase “ 公布商品 ” usecase “ 浏览商品 ” usecase “ 购买商品 ” usecase “ 下架商品 ”} package 订单 {usecase “ 结算订单 ” usecase “ 查问订单 ” usecase “ 退款 ” usecase “ 治理订单 ”} admin -up-> 公布商品 admin -up-> 下架商品 admin -up-> 治理订单 user –> 浏览商品 user –> 购买商品 user –> 结算订单 user –> 结算订单 user –> 查问订单 user –> 退款 @enduml
编辑
应用思维导图剖析性能点
@startmindmap scale 380 height <&flag>Debian <&globe>Ubuntu Linux Mint Kubuntu Lubuntu KDE Neon <&graph>LMDE <&pulse>SolydXK <&people>SteamOS * <&star>Raspbian with a very long name <s>Raspmbc</s> => OSMC <s>Raspyfi</s> => Volumio legend right Short legend endlegend @endmindmap
编辑
应用时序图剖析数据流
scale 300 height 用户 -> 认证核心: 登录操作 认证核心 -> 缓存: 寄存 (key=token+ip,value=token)token 用户 <- 认证核心 : 认证胜利返回 token 用户 -> 认证核心: 下次访问头部携带 token 认证 认证核心 <- 缓存: key=token+ip 获取 token 其余服务 <- 认证核心: 存在且校验胜利则跳转到用户申请的其余服务 其余服务 -> 用户: 信息
编辑
应用流动图剖析测试用例
@startuml scale 580 height start repeat :Test something; if (Something went wrong?) then (no) #palegreen:OK; break endif ->NOK; :Alert “Error with long text”; repeat while (Something went wrong with long text?) is (yes) not (no) ->//merged step//; :Alert “Success”; stop @enduml
编辑
梳理好业务用例的实质是在测试过程中，更全面的测试公司的业务。例如简单的电商零碎或者保险行业的管理系统，外部波及的业务流以及用户的品种都很简单多样，不了解其中的业务逻辑和数据，就很难编写一个笼罩欠缺的业务用例。
更好的与研发运维进行跨部门协同是指当产品呈现问题时，研发和运维都会排查。作为测试，要去理解呈现的问题并帮忙研发运维去解决，这样能够放慢部门协同进度。