1. 为什么单独给ETestDEV5写一篇“系统管理”而不是塞到配置章节里讲不绕弯子先说结论我做嵌入式测试平台维护这么多年见过太多项目“功能都调通了最后倒在管理缺位上”。ETestDEV5作为嵌入式测试系统的开发与执行环境前面教程把用例设计、脚本开发、资源通道配置、测试执行都讲了很多但一旦进入多人协作或长期交付阶段大家发现最麻烦的不是哪条测试用例不会写而是这些人、这些设备、这些工程文件、这些日志记录到底该由谁管、按什么规则管、出了问题去哪里翻证据。这就是系统管理要解决的事也是我特意把它单独拿出来讲的原因。ETestDEV5里的系统管理不只是改个密码、加个用户那么简单。它是整个测试平台的“资源边界”和“行为边界”。说通俗一点单机自己玩的时候你可以随意删文件、覆盖工程、插拔设备没人拦你但当一组人在共享一套测试机柜、一套板卡资源和一批测试报告时没有明确的管理规则随便一次覆盖保存可能就让前面好几天的调试成果作废。系统管理管的是四类东西人能干什么、设备能被谁用、数据存在哪里、出问题后如何追溯。这四类东西互相牵连缺一环都会出乱子。1.1 一个我亲手经历过的问题公共工程被覆盖早年间做一个控制器测试项目两位测试设计工程师为了赶节点用同一个登录账号在同一台开发机的公共目录下改同一个工程。A上午改了参数文件没有关闭工程就先去吃饭B下午打开同一工程继续改保存后直接把A的修改覆盖掉了。更麻烦的是A的修改没有单独另外存一份B也没有意识到自己覆盖了别人的东西。等到联试时发现动作模型参数不对整个组花了接近一天才定位到是文件互相覆盖造成的问题。那件事之后我给自己定了一条规矩只要使用ETestDEV5的人数超过三人就必须把系统管理模块从第一天启用起来而不是等问题出现再补。工程之间的覆盖保护、不同用户对同一工程文件的写入权限、版本更替时能不能回滚这些都要靠系统管理的功能来约束。平台本身不会主动判断谁的行为是对的、谁的动作是错的它只能依据管理员配置的权限和资源策略去阻止不合理的操作。1.2 ETtestDEV5系统管理到底在管哪些对象很多人一开始会把系统管理和“系统设置”混为一谈觉得就是改一改软件语言、切换一下界面主题、配置一下IP地址。实际上系统管理的对象是下面这张表里的内容每一样都直接影响测试平台能不能安全稳定地跑起来管理对象包含内容缺少管理时常见现象用户与角色登录账号、归属部门、密码策略、角色权限越权操作无法追溯删库跑路都看不见记录证书与许可证加密锁、授权文件、并发点数、到期时间工程师换电脑后平台无法启动现场抓瞎设备与通道授权机柜、板卡、串口、CAN、以太网通道的占用分配多人同时申请同一通道测试执行互相打断工程与数据资产测试工程、脚本、参数文件、测试报告、中间结果版本覆盖、数据丢失交付时找不到最终基线日志与审计登录日志、操作日志、运行日志、存储告警设备异常后无法定位责任边界说不清楚备份与恢复配置数据、用户权限、许可证绑定、工程归档系统重装后恢复缓慢甚至授权彻底丢失所以维护ETestDEV5的真正含义是维护这些对象之间的关系而不是只在某个功能菜单里点了几个按钮就结束。测试平台本质上是“硬件资源软件工具工程数据”的集合体系统管理是让三者保持稳定关系的那套规则。1.3 管理端什么时候用、谁来用ETestDEV5的系统管理端通常运行在服务器的管理控制台里单机部署时由本机管理员负责项目组部署时最好由专门的系统管理员来维护用户、许可和备份而不是让每一个测试人员都拿管理员权限。测试设计人员的主要精力应该放在用例和脚本内容上测试执行人员只需要按规程启动执行并查看报告审核人员需要能只读查看审计记录。如果团队里所有人都能删工程、改设备绑定、看别人的私有数据那权限管理的意义就已经消失了。提示小型项目可以接受一个人身兼数职但建议至少做到“执行角色不能用管理员账号登录”“设计角色不能随意删除归档”“审核角色必须能查看操作记录”这三条底线。如果做不到系统的审计和追溯能力基本是摆设。2. 谁的账号能碰什么用户、角色与设备许可的配置细节用户与权限是系统管理里最基础也最容易被忽视的模块。很多项目的权限配置思路是“先给管理员遇事再说”结果管理员账号在五六个人手里传来传去最后谁都说不清某次误操作是谁做的。ETestDEV5里的用户体系设计其实是够用的问题往往出在实施者没有认真拆角色。2.1 用户主数据的创建与维护在系统管理端新增用户时建议按完整字段录入不要只填一个登录名。一个规范的用户信息至少包括登录名、显示姓名、所属部门或项目组、角色、初始密码、密码有效期、账号启用时间、账号过期时间。其中“所属部门”和“角色”关系到后续数据权限的分配不要随便填。密码策略方面ETestDEV5一般会提供最小长度、复杂度、有效期等配置项。我建议不要图省事把所有密码都设成同一个弱口令至少要做到8位以上包含大小写字母、数字和特殊字符。平台服务器如果部署在Linux上还需要注意操作系统层面和应用层面两套账号的区别操作系统账号用于保证服务进程的启动权限和文件所有权应用账号用于界面登录和权限审计。两者不能混为一谈。账号停用采用“禁用而不是删除”是更稳妥的做法。禁用可以保留该用户的历史操作记录与文件归属关系删除则可能把历史数据中的“操作人”字段变成一串无意义的ID。换人交接时比较合理的做法是把离职人员的账号禁用再让接替者使用自己的新账号登录不要长期共用原账号。2.2 角色授权拆分到什么粒度才合适系统管理模块里角色通常不等于“某一个具体的人”而是一组权限的集合。ETestDEV5的常见角色拆分可以参考下面这张表角色典型权限适用人群系统管理员用户管理、角色授权、许可证维护、全局参数配置、备份恢复专职运维或项目负责人测试设计开发新建/修改测试工程、编辑脚本、配置测试参数、申请设备通道测试开发工程师测试执行员加载测试工程、查看用例、启动执行、查看结果报告不修改工程内容实验室操作人员审核/质量只读权限可以查看审计日志和测试报告不能修改配置质量管理人员授权时最值得注意的几个点第一删除权限要单独控制不要给普通测试设计角色全局删除权限。第二修改设备通道绑定关系这类高影响操作尽量只交给设备负责人或管理员。第三测试执行员如果只负责按规程执行就不需要授予脚本编辑权限这样能防止执行者在现场临时改参数而无人知晓。不同角色在同一个测试工程上的协作很多平台是用“只读/可写/独占”这类资源锁机制实现的。使用ETestDEV5时设计者A打开某个工程开始编辑系统会建议自动对该工程加编辑锁执行员B此时如果还想去执行该工程的测试要么等待A保存释放要么以只读方式加载。这样做不是限制效率而是保护双方不被对方的操作覆盖或干扰。2.3 设备通道授权不能只看“能不能登录”ETestDEV5里的系统管理和普通办公系统最大的差异在于系统管理的权限最终要落到底层设备通道上。嵌入式测试平台连接着机柜里的板卡、串口、CAN总线、以太网接口等资源。举例来说一个项目里有两套测试夹具分别用CAN0和CAN1与待测设备通信。如果两个测试设计人员同时申请了CAN0通道做报文发送后启动的一方就很可能导致前一方的报文链路被复位或数据冲突。所以设备通道的授权通常包含两层逻辑第一层是用户有没有操作某类设备的权限第二层是某条设备通道此刻有没有被其他会话占用。管理端应当能看到“在线用户列表”“各用户占用的资源通道”“通道持续占用时长”这类信息。现场排障时遇到过“测试执行时提示设备被占用”多数情况下都不是权限配置错误而是另一台终端上的用户没有正常退出把通道一直拽在手里。管理端的“强制释放资源”功能要慎用只有在确认占用方确实空闲或已经下班后才能执行否则可能打断一个正在跑的长时间测试。2.4 证书与许可证的绑定管理ETestDEV5的许可证管理是系统管理里最容易出“隐性故障”的模块。很多平台的授权不是简单一个加密狗插上就行可能是授权文件绑定服务器IP、MAC地址或者通过中心许可证服务器动态分配并发点数。常见维护要点有四条第一服务器端的IP、MAC地址尽量不要随意改动改动前先确认授权是否需要重新申请。第二如果采用中心许可证服务器要留意客户端在切换网络环境后能否正常连回服务器比如笔记本在办公室用有线到了实验室切到无线IP网段变化可能导致客户端暂时获取不到许可。第三并发许可数量是有限资源若大量测试人员长时间挂在工程上不退出后面的人可能无法获取执行许可要在管理端设置合理的会话空闲超时。第四不要在维护系统时随意改时间许可证过期判断和系统时钟直接相关时间被回改或往前拨太多都会造成授权失效或日志时间错乱。提示每次对服务器做系统升级、重装或虚拟机迁移前先到许可证管理界面确认当前授权方式和绑定信息把授权码、证书文件、MAC地址记录在案。否则系统装完发现授权找不回来现场只能干等。3. 磁盘和数据库里躺着多少历史资产目录、存储与清理策略系统管理里的“存储管理”看起来不如权限那么敏感但实际出乱子的频率最高。很多测试平台跑着跑着突然变慢、报告生成失败、执行中止最终原因往往就是磁盘满了或日志文件膨胀到了失控状态。3.1 为什么测试平台的存储问题比办公系统更突出ETestDEV5这种嵌入式测试平台在运行时会产生大量非结构化数据。除了测试工程、脚本、模型文件之外还有底层的CAN报文记录、串口收发缓存、运行日志、故障截图、测试过程录波文件。这些东西单个体积不大但在长时间测试或多通道并发记录时增长很快。一个项目如果连续跑一个通宵的耐久性测试采集到的过程数据可能轻松达到几十GB。如果运维人员还用普通办公电脑“C盘满了清理一下”的思路去处理很容易误删还在归档期内的数据。所以存储管理不是“等满了再删”而是从一开始就要规划好数据的分类存放和保留周期。3.2 推荐的工程目录结构在ETestDEV5服务端的部署目录下我建议从一开始就按下面这种思路划分目录不要把工程数据、临时文件、报告输出全部堆在同一层/data/etestdev5/ config/ # 数据库配置、服务端配置文件、系统级参数 projects/ # 当前开发中的测试工程 P001_控制器项目/ source/ # 工程源码和模型脚本 release/ # 经过评审的正式版本 output/ # 测试报告和导出结果 temp/ # 临时调试文件允许定期清理 archive/ # 已结题项目的长期归档区 logs/ # 服务端运行日志和管理日志 dbbackup/ # 定期数据库备份目录结构本身只是一种约定重要的是让不同权限的人对应不同的目录。开发中的工程放在projects下设计人员有写权限release目录下存放经过评审的正式版本一般只读temp目录允许随时清理archive目录一旦存放结题数据就不允许普通用户修改。这样既保证协作顺畅又避免“谁都能改生产数据”的隐患。在Linux部署环境下管理员可以直接用命令行查看磁盘和目录占用情况df -h du -sh /data/etestdev5/* | sort -h这两条命令非常基础但非常管用。第一条看整个磁盘剩余空间第二条看ETestDEV5数据目录下每个子目录的占用大小按从大到小排序后一眼就能看出是哪个目录在疯狂涨。3.3 日志文件与临时文件的自动清理很多平台自身有日志滚动策略但在实际运维中我更倾向于把“平台内建的清理策略”和“操作系统层面的定时任务”结合起来。平台内建的策略适合处理它自己认识的文件比如执行日志、报表临时文件操作系统层面的计划任务适合处理一些约定目录下的临时文件。下面的find命令可以清理7天前的临时调试目录但使用时一定要确认目录名规范避免误删正式数据find /data/etestdev5/projects -maxdepth 3 -type d -name temp_* -mtime 7 -exec rm -rf {} \;注意这类清理命令上线前一定要先手动执行一次确认列出的文件都是可删除的再加到cron里。不要一上来就写一个find然后挂着自动跑尤其不要直接在根目录或整个数据目录上做递归清理。平台运行过程中有些文件虽然看起来是旧的但可能还有进程引用着粗暴删除可能导致数据库或报表模块出现读不到文件的异常。3.4 数据库体积和备份文件的维护测试报告、用例执行记录、操作日志等数据最终会落到平台的数据库中。数据库文件不会像日志那样一天涨几个GB但它有个特点删除记录后文件体积不一定立即缩小需要定期做整理和压缩。这部分建议使用平台自带的数据库维护或备份工具来操作而不是直接手工去删数据库目录里的文件。备份文件本身也是存储占用大户。每做一次全量备份可能生成几GB的压缩包如果每天都做全量备份磁盘很快会被备份文件占满。比较合理的做法是日常做增量备份每周做一次全量备份超过一个月的旧备份可以按项目要求迁移到其他存储或磁带库中。4. 运行日志、审计记录与告警出问题之后能不能说清楚全靠它系统管理里最容易被忽略、出事时又最重要的功能就是日志和审计。我经常对团队里的人说一句实话功能没调通可以靠加日志、加打印一点一点试但如果是多人操作导致的问题没有审计日志你连问题是谁在什么时候引发的都说不清后面所有的排查都是猜。4.1 ETtestDEV5中应该重点关注的几类日志在ETestDEV5系统管理中日志至少应该分成下面几类来查看和维护日志类别记录内容典型用途登录日志用户登录/退出时间、登录IP、登录结果发现异常登录、确认谁在用系统操作日志谁在什么时间新增/修改/删除了什么配置或工程追查误操作、满足质量管理审计执行日志测试工程加载、测试步骤执行、断言结果、异常退出信息复现测试过程、定位测试链路问题系统资源日志设备通道占用/释放、许可证申请/归还、服务启停记录处理设备占用冲突、排查服务异常不要等到出问题了才去看日志。建议在系统管理端开启“操作审计”功能确保所有影响系统状态的行为都有记录包括用户的登录和退出、工程导入导出、设备绑定关系变更、用户权限调整、备份恢复操作等。审计功能如果默认是关闭的一定要手动打开。没有操作日志的测试平台在质量体系外审或项目归零时是非常被动的。4.2 日志级别、保留周期与磁盘阈值ETestDEV5一般允许设置日志级别常见级别从低到高是调试、信息、警告、错误。调试级别记录的信息最详细但产生的日志量也最大不适合长期开启。日常运行时建议将测试执行日志保持在“信息”级别这样既能清楚看到执行步骤和结果又不会让日志文件暴涨。只有在定位疑难故障时再临时将某个模块的日志切到“调试”级别复现问题后马上改回来。对于保留周期我建议按下面的经验值设置数据类型建议保留周期说明执行日志至少30天覆盖一个完整测试阶段的排障需求操作审计日志至少一个项目周期或半年便于质量回溯和权限审查正式的测试报告结题后长期归档不能简单删除需要转存储临时调试文件最多7天超过期限后可自动清理存储告警是另一个重要配置。更推荐的做法是把磁盘剩余空间阈值设为20%也就是说磁盘使用率达到80%时就触发告警而不是等到95%再报警。因为告警出来后管理员还需要时间处理日志归档、清理临时文件或迁移数据等满了再处理往往已经来不及。ETestDEV5的管理端一般支持配置告警接收邮箱或其他通知方式建议设置两个以上接收人避免单人休班时漏掉。4.3 日志在排查故障时到底怎么用举个例子现场反馈“测试任务开始时提示无法连接设备但昨天还可以”。直接看系统管理里的日志通常会比在界面里反复试更有效率。排查顺序可以是这样先看登录日志确认当前用户是不是正常登录、有没有被锁定再看许可证日志确认并发点数是否已经耗尽、授权是否在有效期内然后看资源日志确认要用的设备通道是不是被其他会话占用最后看执行日志确认是建链握手超时还是配置加载失败。这个排查顺序的本质是“先排除权限和资源问题再查底层通信问题”。权限和资源问题在管理端通常一眼就能看到底层通信问题则需要结合抓包或驱动日志来分析。如果你一上来就打开抓包工具往往抓了半天也找不到原因因为问题可能根本不在通信链路上而是这台设备已经被人申请占用了。注意系统管理日志里的时间戳非常关键。如果服务器时间没有同步或有人手动改过时间日志的先后顺序会变得不可信。建议所有部署在Linux上的ETestDEV5服务器都开启NTP时间同步确保审计日志、执行日志、系统事件的时间基准一致。5. 备份恢复与版本升级不是没人愿意做而是不知道到底要备份哪些东西备份和恢复在系统管理里属于那种“做了看不出成绩、不做迟早出大事”的工作。很多运维人员知道要备份但备份范围不对或者恢复顺序不对等灾难真的发生时照样手忙脚乱。ETestDEV5这类测试平台有一个特点它的运行环境不仅包含软件本身还包含授权绑定、设备资源配置、用户权限、历史工程数据等多层内容。只拷贝一个安装目录根本不算完整备份。5.1 备份到底要备份什么针对ETestDEV5完整备份应至少包含以下内容用户账号和角色权限配置重点是用户与角色的关联关系许可证授权信息包括授权码、证书文件、绑定信息设备资源配置比如板卡类型、通道参数、通信连接配置平台配置参数包括日志级别、告警阈值、存储路径设置工程数据包括当前项目目录、测试脚本、参数文件、历史报告数据库内容包括测试执行记录、报告条目、运行元数据等在Linux环境中可以使用tar命令把数据目录打成压缩包tar -czvf /backup/etestdev5_backup_20250612.tar.gz /data/etestdev5/config /data/etestdev5/projects /data/etestdev5/dbbackup但要注意数据库在运行状态下直接打包文件不一定能得到一个数据一致性的备份。更稳妥的方式是先使用平台自带的备份功能或数据库工具导出再对导出结果进行归档。简单粗暴地直接拷贝运行中的数据库目录容易造成备份文件在恢复时打不开或数据不一致。5.2 恢复操作的正确顺序做好备份之后恢复顺序也同样重要。ETestDEV5系统恢复时如果顺序搞反可能出现平台能启动但授权异常、或者用户能登录但工程引用不完整的情况。通常按下面的顺序来做第一步确认备份文件完整最好先做一次校验和比对。第二步安装与备份时相同版本或兼容版本的基础平台软件。第三步恢复配置文件和服务端参数。第四步恢复用户权限和角色配置。第五步恢复许可证授权重新注册授权文件或连接许可证服务器。第六步恢复数据库和工程数据并逐一验证关键工程能否正常加载。最后随机用几个不同角色的账号登录一遍确认权限边界和日志功能都正常。很多现场人员在“恢复后系统能启动”这一步就以为大功告成结果等到测试执行员反馈“我能登录但加载不了设备通道”才发现设备资源配置没有恢复。所以恢复后的验证一定不能只验证管理员账号要把设计、执行、审核这几个角色的核心路径都走一遍。5.3 版本升级最容易踩的几个坑ETestDEV5的版本升级表面上是替换安装包、更新程序文件实际上涉及元数据表结构变化、配置文件格式变更、授权兼容性等多个方面。版本升级前一定要先看版本差异说明确定从当前版本是否能直接升级到目标版本还是需要先升级到某个中间版本。跳过中间版本直接升有可能出现配置项无法识别或工程文件不兼容。升级前建议做三件事第一把升级作为一项独立任务安排在维护窗口里不要在当天有重要测试执行任务时临时升级。第二进行完整备份并且把备份文件单独放到不会被升级过程影响的目录。第三通过导出或截图方式保留当前的许可证信息、用户角色列表和关键资源配置方便升级后逐项核对。升级完成后的回归验证至少要覆盖四件事管理员能否正常登录并授权、各角色账号权限是否和升级前一致、设备通道能否正常识别与占用、执行日志和审计日志是否能正常写入。如果升级后发现部分功能不正常在条件允许时不要犹豫直接回滚到旧版本备份。很多人在新版本环境里反复调了半天最后发现问题其实是新版与某硬件驱动的兼容性导致的回滚反而最快。6. 日常维护里真正见效的几个小习惯前面几节基本把ETestDEV5系统管理的主要模块讲了一遍但系统管理最终是“做出来的”不是“配出来的”。最后分享几个我自己在实际维护中觉得特别好用的小习惯希望能帮助减少加班。第一个习惯每次变更系统配置之前先写下“回滚条件”再操作。比如要修改某个设备的通道参数先想清楚如果改完测试执行异常我能不能马上改回原来的值原来的值记录在哪里有时我就在管理端旁边放一个文本文件把变更前的配置值和变更原因顺手记下来看起来土但特别实用。第二个习惯权限上坚持“最小授权逐步追加”。给一个新来的测试人员开账号先只给执行相关的权限等确认他熟悉平台规范后再根据实际需要增加编辑权限。不要怕这样显得小气权限控制得越清楚后面出问题时的排查成本越低。第三个习惯每周固定花十分钟看一眼系统管理的运行概览。重点看磁盘剩余空间、许可证使用率、在线用户数、最近几天的登录失败记录、系统日志有没有新的错误级别信息。十分钟看完绝大多数隐患都能被提前发现而不是等到测试任务执行到一半时被系统告警打断。第四个习惯在团队内部约定一套简单的变更通知规则。谁升级了平台补丁、谁修改了设备绑点、谁导入了新的测试工程至少要在项目群里发一句话。系统管理真正有效的状态不是所有人都懂那些菜单而是所有人都知道哪些动作会影响别人。最后说一句实在的ETestDEV5的功能再强也挡不住混乱的使用习惯反过来只要系统管理的用户、权限、数据、日志几条线是清楚的整个测试平台就能长期稳定地支撑项目交付。希望这篇教程能帮你在实际部署和运维中少走一些弯路。
1. 为什么单独给ETestDEV5写一篇“系统管理”而不是塞到配置章节里讲不绕弯子先说结论我做嵌入式测试平台维护这么多年见过太多项目“功能都调通了最后倒在管理缺位上”。ETestDEV5作为嵌入式测试系统的开发与执行环境前面教程把用例设计、脚本开发、资源通道配置、测试执行都讲了很多但一旦进入多人协作或长期交付阶段大家发现最麻烦的不是哪条测试用例不会写而是这些人、这些设备、这些工程文件、这些日志记录到底该由谁管、按什么规则管、出了问题去哪里翻证据。这就是系统管理要解决的事也是我特意把它单独拿出来讲的原因。ETestDEV5里的系统管理不只是改个密码、加个用户那么简单。它是整个测试平台的“资源边界”和“行为边界”。说通俗一点单机自己玩的时候你可以随意删文件、覆盖工程、插拔设备没人拦你但当一组人在共享一套测试机柜、一套板卡资源和一批测试报告时没有明确的管理规则随便一次覆盖保存可能就让前面好几天的调试成果作废。系统管理管的是四类东西人能干什么、设备能被谁用、数据存在哪里、出问题后如何追溯。这四类东西互相牵连缺一环都会出乱子。1.1 一个我亲手经历过的问题公共工程被覆盖早年间做一个控制器测试项目两位测试设计工程师为了赶节点用同一个登录账号在同一台开发机的公共目录下改同一个工程。A上午改了参数文件没有关闭工程就先去吃饭B下午打开同一工程继续改保存后直接把A的修改覆盖掉了。更麻烦的是A的修改没有单独另外存一份B也没有意识到自己覆盖了别人的东西。等到联试时发现动作模型参数不对整个组花了接近一天才定位到是文件互相覆盖造成的问题。那件事之后我给自己定了一条规矩只要使用ETestDEV5的人数超过三人就必须把系统管理模块从第一天启用起来而不是等问题出现再补。工程之间的覆盖保护、不同用户对同一工程文件的写入权限、版本更替时能不能回滚这些都要靠系统管理的功能来约束。平台本身不会主动判断谁的行为是对的、谁的动作是错的它只能依据管理员配置的权限和资源策略去阻止不合理的操作。1.2 ETtestDEV5系统管理到底在管哪些对象很多人一开始会把系统管理和“系统设置”混为一谈觉得就是改一改软件语言、切换一下界面主题、配置一下IP地址。实际上系统管理的对象是下面这张表里的内容每一样都直接影响测试平台能不能安全稳定地跑起来管理对象包含内容缺少管理时常见现象用户与角色登录账号、归属部门、密码策略、角色权限越权操作无法追溯删库跑路都看不见记录证书与许可证加密锁、授权文件、并发点数、到期时间工程师换电脑后平台无法启动现场抓瞎设备与通道授权机柜、板卡、串口、CAN、以太网通道的占用分配多人同时申请同一通道测试执行互相打断工程与数据资产测试工程、脚本、参数文件、测试报告、中间结果版本覆盖、数据丢失交付时找不到最终基线日志与审计登录日志、操作日志、运行日志、存储告警设备异常后无法定位责任边界说不清楚备份与恢复配置数据、用户权限、许可证绑定、工程归档系统重装后恢复缓慢甚至授权彻底丢失所以维护ETestDEV5的真正含义是维护这些对象之间的关系而不是只在某个功能菜单里点了几个按钮就结束。测试平台本质上是“硬件资源软件工具工程数据”的集合体系统管理是让三者保持稳定关系的那套规则。1.3 管理端什么时候用、谁来用ETestDEV5的系统管理端通常运行在服务器的管理控制台里单机部署时由本机管理员负责项目组部署时最好由专门的系统管理员来维护用户、许可和备份而不是让每一个测试人员都拿管理员权限。测试设计人员的主要精力应该放在用例和脚本内容上测试执行人员只需要按规程启动执行并查看报告审核人员需要能只读查看审计记录。如果团队里所有人都能删工程、改设备绑定、看别人的私有数据那权限管理的意义就已经消失了。提示小型项目可以接受一个人身兼数职但建议至少做到“执行角色不能用管理员账号登录”“设计角色不能随意删除归档”“审核角色必须能查看操作记录”这三条底线。如果做不到系统的审计和追溯能力基本是摆设。2. 谁的账号能碰什么用户、角色与设备许可的配置细节用户与权限是系统管理里最基础也最容易被忽视的模块。很多项目的权限配置思路是“先给管理员遇事再说”结果管理员账号在五六个人手里传来传去最后谁都说不清某次误操作是谁做的。ETestDEV5里的用户体系设计其实是够用的问题往往出在实施者没有认真拆角色。2.1 用户主数据的创建与维护在系统管理端新增用户时建议按完整字段录入不要只填一个登录名。一个规范的用户信息至少包括登录名、显示姓名、所属部门或项目组、角色、初始密码、密码有效期、账号启用时间、账号过期时间。其中“所属部门”和“角色”关系到后续数据权限的分配不要随便填。密码策略方面ETestDEV5一般会提供最小长度、复杂度、有效期等配置项。我建议不要图省事把所有密码都设成同一个弱口令至少要做到8位以上包含大小写字母、数字和特殊字符。平台服务器如果部署在Linux上还需要注意操作系统层面和应用层面两套账号的区别操作系统账号用于保证服务进程的启动权限和文件所有权应用账号用于界面登录和权限审计。两者不能混为一谈。账号停用采用“禁用而不是删除”是更稳妥的做法。禁用可以保留该用户的历史操作记录与文件归属关系删除则可能把历史数据中的“操作人”字段变成一串无意义的ID。换人交接时比较合理的做法是把离职人员的账号禁用再让接替者使用自己的新账号登录不要长期共用原账号。2.2 角色授权拆分到什么粒度才合适系统管理模块里角色通常不等于“某一个具体的人”而是一组权限的集合。ETestDEV5的常见角色拆分可以参考下面这张表角色典型权限适用人群系统管理员用户管理、角色授权、许可证维护、全局参数配置、备份恢复专职运维或项目负责人测试设计开发新建/修改测试工程、编辑脚本、配置测试参数、申请设备通道测试开发工程师测试执行员加载测试工程、查看用例、启动执行、查看结果报告不修改工程内容实验室操作人员审核/质量只读权限可以查看审计日志和测试报告不能修改配置质量管理人员授权时最值得注意的几个点第一删除权限要单独控制不要给普通测试设计角色全局删除权限。第二修改设备通道绑定关系这类高影响操作尽量只交给设备负责人或管理员。第三测试执行员如果只负责按规程执行就不需要授予脚本编辑权限这样能防止执行者在现场临时改参数而无人知晓。不同角色在同一个测试工程上的协作很多平台是用“只读/可写/独占”这类资源锁机制实现的。使用ETestDEV5时设计者A打开某个工程开始编辑系统会建议自动对该工程加编辑锁执行员B此时如果还想去执行该工程的测试要么等待A保存释放要么以只读方式加载。这样做不是限制效率而是保护双方不被对方的操作覆盖或干扰。2.3 设备通道授权不能只看“能不能登录”ETestDEV5里的系统管理和普通办公系统最大的差异在于系统管理的权限最终要落到底层设备通道上。嵌入式测试平台连接着机柜里的板卡、串口、CAN总线、以太网接口等资源。举例来说一个项目里有两套测试夹具分别用CAN0和CAN1与待测设备通信。如果两个测试设计人员同时申请了CAN0通道做报文发送后启动的一方就很可能导致前一方的报文链路被复位或数据冲突。所以设备通道的授权通常包含两层逻辑第一层是用户有没有操作某类设备的权限第二层是某条设备通道此刻有没有被其他会话占用。管理端应当能看到“在线用户列表”“各用户占用的资源通道”“通道持续占用时长”这类信息。现场排障时遇到过“测试执行时提示设备被占用”多数情况下都不是权限配置错误而是另一台终端上的用户没有正常退出把通道一直拽在手里。管理端的“强制释放资源”功能要慎用只有在确认占用方确实空闲或已经下班后才能执行否则可能打断一个正在跑的长时间测试。2.4 证书与许可证的绑定管理ETestDEV5的许可证管理是系统管理里最容易出“隐性故障”的模块。很多平台的授权不是简单一个加密狗插上就行可能是授权文件绑定服务器IP、MAC地址或者通过中心许可证服务器动态分配并发点数。常见维护要点有四条第一服务器端的IP、MAC地址尽量不要随意改动改动前先确认授权是否需要重新申请。第二如果采用中心许可证服务器要留意客户端在切换网络环境后能否正常连回服务器比如笔记本在办公室用有线到了实验室切到无线IP网段变化可能导致客户端暂时获取不到许可。第三并发许可数量是有限资源若大量测试人员长时间挂在工程上不退出后面的人可能无法获取执行许可要在管理端设置合理的会话空闲超时。第四不要在维护系统时随意改时间许可证过期判断和系统时钟直接相关时间被回改或往前拨太多都会造成授权失效或日志时间错乱。提示每次对服务器做系统升级、重装或虚拟机迁移前先到许可证管理界面确认当前授权方式和绑定信息把授权码、证书文件、MAC地址记录在案。否则系统装完发现授权找不回来现场只能干等。3. 磁盘和数据库里躺着多少历史资产目录、存储与清理策略系统管理里的“存储管理”看起来不如权限那么敏感但实际出乱子的频率最高。很多测试平台跑着跑着突然变慢、报告生成失败、执行中止最终原因往往就是磁盘满了或日志文件膨胀到了失控状态。3.1 为什么测试平台的存储问题比办公系统更突出ETestDEV5这种嵌入式测试平台在运行时会产生大量非结构化数据。除了测试工程、脚本、模型文件之外还有底层的CAN报文记录、串口收发缓存、运行日志、故障截图、测试过程录波文件。这些东西单个体积不大但在长时间测试或多通道并发记录时增长很快。一个项目如果连续跑一个通宵的耐久性测试采集到的过程数据可能轻松达到几十GB。如果运维人员还用普通办公电脑“C盘满了清理一下”的思路去处理很容易误删还在归档期内的数据。所以存储管理不是“等满了再删”而是从一开始就要规划好数据的分类存放和保留周期。3.2 推荐的工程目录结构在ETestDEV5服务端的部署目录下我建议从一开始就按下面这种思路划分目录不要把工程数据、临时文件、报告输出全部堆在同一层/data/etestdev5/ config/ # 数据库配置、服务端配置文件、系统级参数 projects/ # 当前开发中的测试工程 P001_控制器项目/ source/ # 工程源码和模型脚本 release/ # 经过评审的正式版本 output/ # 测试报告和导出结果 temp/ # 临时调试文件允许定期清理 archive/ # 已结题项目的长期归档区 logs/ # 服务端运行日志和管理日志 dbbackup/ # 定期数据库备份目录结构本身只是一种约定重要的是让不同权限的人对应不同的目录。开发中的工程放在projects下设计人员有写权限release目录下存放经过评审的正式版本一般只读temp目录允许随时清理archive目录一旦存放结题数据就不允许普通用户修改。这样既保证协作顺畅又避免“谁都能改生产数据”的隐患。在Linux部署环境下管理员可以直接用命令行查看磁盘和目录占用情况df -h du -sh /data/etestdev5/* | sort -h这两条命令非常基础但非常管用。第一条看整个磁盘剩余空间第二条看ETestDEV5数据目录下每个子目录的占用大小按从大到小排序后一眼就能看出是哪个目录在疯狂涨。3.3 日志文件与临时文件的自动清理很多平台自身有日志滚动策略但在实际运维中我更倾向于把“平台内建的清理策略”和“操作系统层面的定时任务”结合起来。平台内建的策略适合处理它自己认识的文件比如执行日志、报表临时文件操作系统层面的计划任务适合处理一些约定目录下的临时文件。下面的find命令可以清理7天前的临时调试目录但使用时一定要确认目录名规范避免误删正式数据find /data/etestdev5/projects -maxdepth 3 -type d -name temp_* -mtime 7 -exec rm -rf {} \;注意这类清理命令上线前一定要先手动执行一次确认列出的文件都是可删除的再加到cron里。不要一上来就写一个find然后挂着自动跑尤其不要直接在根目录或整个数据目录上做递归清理。平台运行过程中有些文件虽然看起来是旧的但可能还有进程引用着粗暴删除可能导致数据库或报表模块出现读不到文件的异常。3.4 数据库体积和备份文件的维护测试报告、用例执行记录、操作日志等数据最终会落到平台的数据库中。数据库文件不会像日志那样一天涨几个GB但它有个特点删除记录后文件体积不一定立即缩小需要定期做整理和压缩。这部分建议使用平台自带的数据库维护或备份工具来操作而不是直接手工去删数据库目录里的文件。备份文件本身也是存储占用大户。每做一次全量备份可能生成几GB的压缩包如果每天都做全量备份磁盘很快会被备份文件占满。比较合理的做法是日常做增量备份每周做一次全量备份超过一个月的旧备份可以按项目要求迁移到其他存储或磁带库中。4. 运行日志、审计记录与告警出问题之后能不能说清楚全靠它系统管理里最容易被忽略、出事时又最重要的功能就是日志和审计。我经常对团队里的人说一句实话功能没调通可以靠加日志、加打印一点一点试但如果是多人操作导致的问题没有审计日志你连问题是谁在什么时候引发的都说不清后面所有的排查都是猜。4.1 ETtestDEV5中应该重点关注的几类日志在ETestDEV5系统管理中日志至少应该分成下面几类来查看和维护日志类别记录内容典型用途登录日志用户登录/退出时间、登录IP、登录结果发现异常登录、确认谁在用系统操作日志谁在什么时间新增/修改/删除了什么配置或工程追查误操作、满足质量管理审计执行日志测试工程加载、测试步骤执行、断言结果、异常退出信息复现测试过程、定位测试链路问题系统资源日志设备通道占用/释放、许可证申请/归还、服务启停记录处理设备占用冲突、排查服务异常不要等到出问题了才去看日志。建议在系统管理端开启“操作审计”功能确保所有影响系统状态的行为都有记录包括用户的登录和退出、工程导入导出、设备绑定关系变更、用户权限调整、备份恢复操作等。审计功能如果默认是关闭的一定要手动打开。没有操作日志的测试平台在质量体系外审或项目归零时是非常被动的。4.2 日志级别、保留周期与磁盘阈值ETestDEV5一般允许设置日志级别常见级别从低到高是调试、信息、警告、错误。调试级别记录的信息最详细但产生的日志量也最大不适合长期开启。日常运行时建议将测试执行日志保持在“信息”级别这样既能清楚看到执行步骤和结果又不会让日志文件暴涨。只有在定位疑难故障时再临时将某个模块的日志切到“调试”级别复现问题后马上改回来。对于保留周期我建议按下面的经验值设置数据类型建议保留周期说明执行日志至少30天覆盖一个完整测试阶段的排障需求操作审计日志至少一个项目周期或半年便于质量回溯和权限审查正式的测试报告结题后长期归档不能简单删除需要转存储临时调试文件最多7天超过期限后可自动清理存储告警是另一个重要配置。更推荐的做法是把磁盘剩余空间阈值设为20%也就是说磁盘使用率达到80%时就触发告警而不是等到95%再报警。因为告警出来后管理员还需要时间处理日志归档、清理临时文件或迁移数据等满了再处理往往已经来不及。ETestDEV5的管理端一般支持配置告警接收邮箱或其他通知方式建议设置两个以上接收人避免单人休班时漏掉。4.3 日志在排查故障时到底怎么用举个例子现场反馈“测试任务开始时提示无法连接设备但昨天还可以”。直接看系统管理里的日志通常会比在界面里反复试更有效率。排查顺序可以是这样先看登录日志确认当前用户是不是正常登录、有没有被锁定再看许可证日志确认并发点数是否已经耗尽、授权是否在有效期内然后看资源日志确认要用的设备通道是不是被其他会话占用最后看执行日志确认是建链握手超时还是配置加载失败。这个排查顺序的本质是“先排除权限和资源问题再查底层通信问题”。权限和资源问题在管理端通常一眼就能看到底层通信问题则需要结合抓包或驱动日志来分析。如果你一上来就打开抓包工具往往抓了半天也找不到原因因为问题可能根本不在通信链路上而是这台设备已经被人申请占用了。注意系统管理日志里的时间戳非常关键。如果服务器时间没有同步或有人手动改过时间日志的先后顺序会变得不可信。建议所有部署在Linux上的ETestDEV5服务器都开启NTP时间同步确保审计日志、执行日志、系统事件的时间基准一致。5. 备份恢复与版本升级不是没人愿意做而是不知道到底要备份哪些东西备份和恢复在系统管理里属于那种“做了看不出成绩、不做迟早出大事”的工作。很多运维人员知道要备份但备份范围不对或者恢复顺序不对等灾难真的发生时照样手忙脚乱。ETestDEV5这类测试平台有一个特点它的运行环境不仅包含软件本身还包含授权绑定、设备资源配置、用户权限、历史工程数据等多层内容。只拷贝一个安装目录根本不算完整备份。5.1 备份到底要备份什么针对ETestDEV5完整备份应至少包含以下内容用户账号和角色权限配置重点是用户与角色的关联关系许可证授权信息包括授权码、证书文件、绑定信息设备资源配置比如板卡类型、通道参数、通信连接配置平台配置参数包括日志级别、告警阈值、存储路径设置工程数据包括当前项目目录、测试脚本、参数文件、历史报告数据库内容包括测试执行记录、报告条目、运行元数据等在Linux环境中可以使用tar命令把数据目录打成压缩包tar -czvf /backup/etestdev5_backup_20250612.tar.gz /data/etestdev5/config /data/etestdev5/projects /data/etestdev5/dbbackup但要注意数据库在运行状态下直接打包文件不一定能得到一个数据一致性的备份。更稳妥的方式是先使用平台自带的备份功能或数据库工具导出再对导出结果进行归档。简单粗暴地直接拷贝运行中的数据库目录容易造成备份文件在恢复时打不开或数据不一致。5.2 恢复操作的正确顺序做好备份之后恢复顺序也同样重要。ETestDEV5系统恢复时如果顺序搞反可能出现平台能启动但授权异常、或者用户能登录但工程引用不完整的情况。通常按下面的顺序来做第一步确认备份文件完整最好先做一次校验和比对。第二步安装与备份时相同版本或兼容版本的基础平台软件。第三步恢复配置文件和服务端参数。第四步恢复用户权限和角色配置。第五步恢复许可证授权重新注册授权文件或连接许可证服务器。第六步恢复数据库和工程数据并逐一验证关键工程能否正常加载。最后随机用几个不同角色的账号登录一遍确认权限边界和日志功能都正常。很多现场人员在“恢复后系统能启动”这一步就以为大功告成结果等到测试执行员反馈“我能登录但加载不了设备通道”才发现设备资源配置没有恢复。所以恢复后的验证一定不能只验证管理员账号要把设计、执行、审核这几个角色的核心路径都走一遍。5.3 版本升级最容易踩的几个坑ETestDEV5的版本升级表面上是替换安装包、更新程序文件实际上涉及元数据表结构变化、配置文件格式变更、授权兼容性等多个方面。版本升级前一定要先看版本差异说明确定从当前版本是否能直接升级到目标版本还是需要先升级到某个中间版本。跳过中间版本直接升有可能出现配置项无法识别或工程文件不兼容。升级前建议做三件事第一把升级作为一项独立任务安排在维护窗口里不要在当天有重要测试执行任务时临时升级。第二进行完整备份并且把备份文件单独放到不会被升级过程影响的目录。第三通过导出或截图方式保留当前的许可证信息、用户角色列表和关键资源配置方便升级后逐项核对。升级完成后的回归验证至少要覆盖四件事管理员能否正常登录并授权、各角色账号权限是否和升级前一致、设备通道能否正常识别与占用、执行日志和审计日志是否能正常写入。如果升级后发现部分功能不正常在条件允许时不要犹豫直接回滚到旧版本备份。很多人在新版本环境里反复调了半天最后发现问题其实是新版与某硬件驱动的兼容性导致的回滚反而最快。6. 日常维护里真正见效的几个小习惯前面几节基本把ETestDEV5系统管理的主要模块讲了一遍但系统管理最终是“做出来的”不是“配出来的”。最后分享几个我自己在实际维护中觉得特别好用的小习惯希望能帮助减少加班。第一个习惯每次变更系统配置之前先写下“回滚条件”再操作。比如要修改某个设备的通道参数先想清楚如果改完测试执行异常我能不能马上改回原来的值原来的值记录在哪里有时我就在管理端旁边放一个文本文件把变更前的配置值和变更原因顺手记下来看起来土但特别实用。第二个习惯权限上坚持“最小授权逐步追加”。给一个新来的测试人员开账号先只给执行相关的权限等确认他熟悉平台规范后再根据实际需要增加编辑权限。不要怕这样显得小气权限控制得越清楚后面出问题时的排查成本越低。第三个习惯每周固定花十分钟看一眼系统管理的运行概览。重点看磁盘剩余空间、许可证使用率、在线用户数、最近几天的登录失败记录、系统日志有没有新的错误级别信息。十分钟看完绝大多数隐患都能被提前发现而不是等到测试任务执行到一半时被系统告警打断。第四个习惯在团队内部约定一套简单的变更通知规则。谁升级了平台补丁、谁修改了设备绑点、谁导入了新的测试工程至少要在项目群里发一句话。系统管理真正有效的状态不是所有人都懂那些菜单而是所有人都知道哪些动作会影响别人。最后说一句实在的ETestDEV5的功能再强也挡不住混乱的使用习惯反过来只要系统管理的用户、权限、数据、日志几条线是清楚的整个测试平台就能长期稳定地支撑项目交付。希望这篇教程能帮你在实际部署和运维中少走一些弯路。
