简介这是一份西门子Desigo CC楼宇自动化系统用户界面的中文培训手册UserInterface_BA面向楼宇自动化工程师、系统集成商及运维操作人员用于系统学习GUI操作和事件响应流程。手册对应西门子官方内部培训章节内容聚焦用户界面布局、主要应用程序、工作流驱动的窗格概念、摘要栏、系统浏览器及事件处理机制能帮助读者从整体到细节建立清晰的操作认知。包体为单个PDF文档共1个文件压缩包大小仅2.41MB便于下载后离线查阅。目前已有1577人学习下载在同类楼宇自控资料中具有较高参考价值。资源内详细讲解摘要栏菜单、过滤与警报可视化、快速/调查/辅助事件处理程序以及系统浏览器默认视图和自定义视图的用法并配有工程场景说明适合需要提升Desigo CC日常操作效率的工程技术人员。1. 为什么界面需求越改越乱BA手册就是用来收口的一份标着「Desi GO CC手册-02-UserInterface-BA-CN(用户界面)」的文档躺在项目共享目录里业务方催着确认界面改动开发说没看到需求边界测试说不知道按什么验收。这种场面几乎每个做过界面类需求的人都遇过。所谓用「BA-CN(用户界面)」命名的中文业务分析手册本质不是设计稿也不是开发文档而是把「界面长什么样、什么时候出现、给谁看、不能干什么」写成一组可核对、可引用、可验收的条目。它解决的是三拨人的对不齐业务方以为说清了研发以为理解了测试以为没有漏——结果一上线全是差异。这篇文章就围绕这种手册怎么读、怎么拆、怎么落地讲透帮你在下一份界面需求里少开三次会、少改两轮稿。2. 读懂用户界面BA手册的结构编号、三层骨架与状态定义拿到这种手册第一反应别去翻页面截图先看它的结构。界面类BA手册普遍采用「模块编号 视角标识 语言版本」的命名方式。标题里的02是文档族内的模块序号UserInterface标明本条基线管的是界面BA指业务分析视角CN是中文版本。理解这套编号的意义在于跨文档引用时你会知道该引用谁评审会上讨论「第3页那个问题」时你可以精确到条目编号而不是让所有人翻页找。2.1 先花十分钟读编号02、UserInterface、BA、CN各代表什么编号不是随便排的。02说明这是该产品文档族里的第二篇通常意味着前一篇是总体说明或数据模型后一篇可能是交互逻辑或接口定义。你在引用时会写「见CC手册-02-UserInterface-BA-CN-3.2.1」其中3.2.1是条目号。没有这个习惯的团队沟通成本会显著上升。BABusiness Analysis这个视角决定了手册的写法。它不回答「按钮用什么颜色、圆角几个像素」而是回答「这个按钮在什么业务条件下出现、点击后系统该做什么、没有权限的人看到什么」。这是业务分析与UI设计的关键差异UI稿管视觉BA手册管行为和条件。很多团队把这两者混在一起结果后期视觉改了、行为没改或者行为改了、文案没同步。CN语言版本旗标在多语言产品里作用更大。同一套界面CN版和EN版可能字段长度不同、日期格式不同、文案变量位置不同。手册名里带上CN意味着它所描述的中文界面才是这条基线的唯一事实来源。我一般的做法是拿到手册先花十分钟建一个「阅读索引」把文档里的一级章节号、对应页面名称和涉及角色写在一张纸上后面拆任务时直接按这个索引走。2.2 组件、页面、流程BA手册的三层骨架不管手册章节怎么排内容上都逃不开三层组件层、页面层、流程层。先把这三层分清后面所有拆解都顺手。组件层描述最小界面单元比如表格、下拉框、日期选择器。BA手册里对组件的定义往往不写长相而写行为契约这个下拉框的数据源是什么、是否支持搜索、选完是否触发刷新。页面层是组件的集合描述一个页面内有哪些组件、它们之间的联动关系。流程层则横跨多个页面描述一个业务操作从入口到结束经过哪些界面、每步的判定条件是什么。三层模型的价值在于定位问题测试报一个「搜索后表格数据不对」的缺陷如果手册里组件层写了搜索触发逻辑、页面层写了表格刷新规则那么这个缺陷应该定位到页面层还是组件层就有了依据。实际项目中很多团队只有页面截图和原型缺的就是这一层结构化描述。我给需求时习惯先画一张「页面-组件-流程」对照表把手册条目归位。表格是最适合做这种归位的工具。列名可以是条目编号、层级组件/页面/流程、所属页面、行为描述、涉及角色。每次评审会带着这张表去讨论就不会发散。2.3 每种界面状态都该有书面定义从空态到异常态界面BA手册最容易被跳读的部分是状态定义。大多数人只关心「正常长什么样」但真正决定开发量和测试量的是那些不常出现的状态。至少六种状态需要手册覆盖正常态、空态、加载态、禁用态、错误态、无权限态。空态指的是列表没有任何数据时显示什么加载态指请求进行中用户看到了什么错误态指接口返回失败时页面怎么表达。无权限态更关键它决定了一个角色点进去是被引导、被提示还是看到置灰。这些状态如果不写开发就会按自己习惯实现测试就会按自己理解验收。等到用户真正遇到空数据或接口超时界面表现五花八门。所以每次评审我必问的一句话是「这个页面的空态和错误态手册里有没有条目」没有就当场补。状态定义的输出不一定要长关键是成文。每条状态定义建议写成「条件 表现 操作」三要素什么条件下触发、界面上显示什么、用户此时能做什么。这样一个条目开发可以直接翻译成代码分支测试可以直接翻译成用例。3. 从手册条目到可执行任务拆页面清单、字段表与验收断言读懂了结构接下来就是把手册变成能排期、能分工、能验收的东西。这一步我见过太多团队跳过——业务分析师写完手册开发直接看原型写代码手册成了摆设。问题在于手册的语序是「业务视角」开发的执行是「实现视角」中间缺了一层翻译。3.1 把「业务描述」翻译成页面清单第一步做页面清单。梳理手册里所有页面条目给每个页面生成一行记录。清单至少包含页面编号、页面名称、入口来源、包含组件清单、涉及角色、操作按钮。别小看这张表它能照出手册里的重复页面和缺失页面。实际操作时我见过某项目手册里写了「用户查询页」和「用户管理页」研发一看两个页面列表部分完全一样只是操作列不同。按页面清单归并后原来排两周的活缩成一周半。这就是页面清单的价值砍掉重复合并同构。页面编号页面名称入口来源涉及角色关键组件操作按钮UI-01-01用户列表首页导航-用户中心管理员搜索框、数据表格、分页器新建、编辑、停用UI-01-02用户详情用户列表-点击行管理员、审计员信息展示区、操作按钮区编辑、重置密码、查看日志3.2 字段定义表控件类型、校验规则与默认值页面清单定下后开始拆字段。每一块表单、每一列表格数据都要落到字段定义表。这张表是开发写代码的底稿也是测试写用例的底稿。字段定义表的列建议固定字段名中文字段名对应英文key、控件类型输入框、下拉、日期、单选、是否必填、长度限制、校验规则、默认值、来源用户输入/接口返回/字典项。校验规则一栏最容易漏比如手机号格式、金额精度、日期范围。这里必须强调一个经常翻车的点控件类型决定交互成本同一个字段用下拉还是输入框背后是多一套字典维护还是一套格式校验的问题。手册里如果只写了「状态」两个字开发大概率用一个自由输入框结果数据脏得没法看。字段定义表出现后这类问题会在评审阶段暴露而不是上线后。字段表的产出不需要代码但可以顺手标注哪些字段参与了联动。比如「所在部门」变更后「负责人」下拉的数据源要跟着换。这种联动关系单独列一列开发排期时能提前评估工作量。3.3 把BA描述改写成可验收断言BA手册的条目大多是自然语言「用户提交后系统提示成功并返回列表页。」这种描述看起来清楚实际验收时扯皮概率很高——什么叫「提示成功」文案是什么停留多久返回后列表刷新吗我的习惯是把每一条核心行为改写成可验收断言格式统一为给定条件执行操作预期结果。技术团队可以直接把它写成自动化用例。// 示例将BA条目翻译为代码级别的验收断言 // BA条目UI-03-02 用户点击提交申请后系统校验必填项 // 校验通过则弹出成功提示并跳转列表页且列表刷新。 describe(提交申请流程, () { it(必填项未填时阻塞提交, async () { await page.click(提交申请); const errorMsg await page.getText(error-tip); expect(errorMsg).toContain(请填写完整); // 断言提示文案 expect(await page.isVisible(success-modal)).toBe(false); // 断言未跳转 }); it(校验通过后提示成功并刷新列表, async () { await page.fill(apply-name, 测试项目); await page.click(提交申请); expect(await page.getText(success-tip)).toContain(提交成功); expect(await page.url()).toContain(/list); // 断言跳转地址 expect(await page.isRefreshCalled()).toBe(true); // 断言列表刷新 }); });3.4 反向检查描述里缺了「不显示」的场景把描述改写成断言的过程中自然而然会暴露手册缺口。最常见的一类是「只写了显示条件没写隐藏条件」。比如「管理员能看到导出按钮」反向问题是什么角色看不到看不到时是隐藏还是置灰点击后有没有二次确认导出期间用户重复点击怎么办这类问题我建议专门过一遍「反向检查清单」每个可见元素问一次——谁不能看、什么时候不显示、点击后有没有防重复、数据为空时显示什么。把这些问题补成新条目加进手册开发阶段就不会来反复问「这个要不要做」。4. CN环境下最容易漏的三块权限矩阵、多语言与异常态如果说前三章解决「怎么读、怎么拆」这一章解决「为什么拆的时候总漏东西」。中文环境下的界面BA手册我做了几轮之后发现有三块内容是重灾区权限描述散落、中文字符串没定规则、异常路径一片空白。而且这三个问题不是开发能自己兜底的必须在BA层面定清楚。4.1 权限矩阵是界面手册的隐藏主线界面手册里几乎每个按钮、每个页面都牵涉权限但很多手册把权限写在条目描述里分散且难查。正确做法是单独建一张权限矩阵手册主条目只引用矩阵中的角色编码。幂等、并发、超时这三类异常BA手册必须覆盖。幂等指用户连点两次提交会不会生成两条数据并发指两个用户同时改同一条数据谁覆盖谁超时指请求超过N秒无响应时界面表现。加N秒这个参数时不是拍脑袋定的。通常以接口的P95响应时间为基准如果接口平均值300ms那超时阈值设在5秒左右比较合理。设太短用户正常操作就被打断设太长用户会以为系统卡死。异常状态的定义方式和正常态一样也要写「条件 表现 操作」。比如「提交超时」条件是请求发出后5秒无响应表现为弹出「请求超时请重试」提示操作是用户可点击重试按钮。4.2 中文字段与多语言变量占位符、长度与时区CN版本的手册多语言问题是隐藏工作量。同一个字段中文显示「所属部门」切换到英文界面变成「Department」如果字段定义表没有对应的key开发就会写死中文后来做国际化时全要返工。字段定义表里每一行都应该预留「多语言key」这一列。比key更隐蔽的是文案变量。界面上常出现「共{0}条记录」这种动态文案{0}是后端返回的数字。手册里写了文案但没标哪个词是变量、变量是什么格式接口返回的数据就直接拼接格式一乱就出错。常见做法是统一规定「{0}、{1}」为变量占位符并在文案定义旁标注占位符含义。日期格式在中文环境下也有讲究。中国用户习惯看「2024-12-11」但系统接口可能返回「2024-12-11T10:30:00Z」这个UTC格式。界面上直接显示原始值会非常突兀。BA手册应该对时间显示格式做出约定列表页显示「YYYY-MM-DD HH:mm」详情页可以带时区标识。这个约定不写前端就会自己处理各页面格式不一致测试提一堆低优缺陷。4.3 异常态写在手册里才算数超时、幂等与并发排期时这些异常逻辑往往被认为「顺手做了」其实每一条都是实打实的开发量和测试量。以「提交申请」这个动作为例至少涉及三个异常分支超时用户点击后接口5秒未返回界面出现「提交中」状态还是直接报错错误后用户重试会不会造成重复提交幂等用户连点两次「提交」系统能否识别并阻止第二条并发两个用户同时编辑同一条记录后保存的一方应该收到提示还是直接覆盖这三个问题不在手册里定掉开发就会各写各的。我建议把这些异常分支单独列成「异常场景清单」每条标注触发条件、预期界面表现、用户操作范围。测试直接拿这个清单写用例比从正常流程反推异常要全面得多。5. 用户界面手册落地避坑五类典型问题与排查路径做了几个带界面BA手册的项目后我把翻过车的问题收敛成五类。每一类都是「现象 → 原因 → 解决」的结构你在自己项目里遇到可以直接照方抓药。5.1 条目粒度不一致业务写一页研发拆十页现象开发评估工作量时说手册里一条需求实际是五个任务评审会上来回掰扯半天。原因BA按业务操作写条目开发按代码改动点拆任务两者颗粒度根本不同。解决在拆解阶段就输出「需求条目 × 开发任务」映射表。一个BA条目可以对应多个开发任务但要明确哪个是主体、哪些是附带改动评审会焦点放在主体任务附带改动合并评估。5.2 布局用文字描述评审会上各人脑补出不同界面现象手册里写「按钮放在页面右上角」「列表左侧显示用户信息」结果开发做出来的界面布局跟业务方脑子里想象的完全两样。原因文字描述布局的空间信息太弱每个人在自己心里渲染的版本不同。解决复杂布局不能只写字配合线框草图或原型图。线框不需要高保真只标注区域、顺序和间距关系。评审时让业务方对着线框确认「是不是这个意思」再让开发按线框实现差异会缩小很多。5.3 权限散落在备注里查不到、对不上、验收才发现现象验收阶段发现普通用户能看到「删除」按钮但手册里只写了管理员权限没定义普通用户看到什么。原因权限被写进条目描述而没有单独成表测试用例也从没覆盖无权限场景。解决项目启动时就建权限矩阵每个按钮、每个字段都标注可见与可操作角色。矩阵表建议固定格式功能点、管理员、审计员、普通用户可见/可操作、访客。评审会逐行过一遍权限相关的问题一次聊清。5.4 多语言变量裸奔为「{0}」文案接手时根本不知道替换谁现象测试提缺陷——列表页显示「共{0}条」花了两天才定位到是接口字段没映射成功。原因BA手册里写了完整文案但没标注哪部分是动态变量前端拿到字符串直接渲染后端字段对不上就原样显示。解决手册每条文案都用「静态部分 变量标记」的格式定义例如「共{0}条记录{1}条未读」并注明{0}为总数、{1}为未读数均来自列表接口的total和unreadCount字段。后端按约定返回前端按key替换这个坑就不会出现。5.5 只有正常路径没有异常路径上线后第一次异常就翻车现象新功能上线第二天用户反馈导出Excel时点了没反应没有人预先定义过「导出期间重复点击」的交互。原因BA手册从头到尾在写正常的操作流异常情况一概没提。解决每个核心操作补「防重复」约定简单场景是提交按钮点击后立即置灰长耗时场景是展示加载状态并禁用按钮。这条约定成本很低但能挡住大量线上低级反馈。我在评审时会把「连点两次」当必问题养成习惯后团队整体质量会明显改善。6. 让手册活起来用界面走查单反向补齐BA条目BA手册最大的风险不是没人看而是评审通过后被锁进共享盘开发做开发的、测试测测试的手册和实现慢慢分家。我在项目后期有个固定动作用手写走查单的方式在界面开发完成后逐屏比对把手册缺漏补回来也把实现偏差记录在案。走查单不需要复杂一张A4纸分六列就够。每一行是一条走查项按页面顺序排列。我常用的走查单模板如下走查项检查方式通过标准状态对应BA条目备注空数据展示新账号登录打开列表页显示空态引导文案与操作按钮待查UI-01-01-04手册未定义空态需补加载状态弱网模拟打开详情页显示加载动效禁止出现白屏通过UI-01-02-02权限置灰普通角色登录查看删除按钮按钮置灰并带提示不可点击待查权限矩阵-行12文案变量构造含未读数数据查看提示数字正确替换无{0}裸奔通过UI-03-05-01连续点击点击导出快速再点两次第二次点击无效或按钮置灰待查无手册缺失需要补防重复约定走查单用起来之后会有两个明显收益。一是手册不再是静态文档每次走查都是一个逆向补齐的过程缺条目就补条目缺约定就补约定二是测试用例的来源变多了不再只靠分析师写好的验收标准走查单里每条「待查」都可以转成一条正式用例。配合走查单我习惯把「无对应BA条目」的界面元素单独记在一个清单里每周清一次。要么补手册要么确认是临时实现到版本发布时所有的界面元素都能追溯到一个条目。这套机制跑过两个项目后我发现最大的变化不是缺陷变少了而是评审会从「吵架会」变成了「核对会」。做了三个带界面BA手册的项目之后我的习惯是任何界面改动无论多小先更新手册再加代码。手册更新在前代码实现紧跟走查单兜底——这个顺序能保证需求和实现永远不脱节。如果你手上也有一份静静躺在共享盘里的界面手册从今天起给它配一张走查单让旧文档重新产生价值。希望帮到你。本文还有配套的精品资源点击获取
