ETestDEV5教程系列更新到第10篇今天聊系统管理。这个模块在测试工具里往往不是最显眼的但恰恰是决定一个平台能不能在团队里长期稳定用下去的关键底座。前面几篇我们讲了测试设计、测试执行、报告生成那些功能解决的是“怎么测”的问题而系统管理解决的是“谁能用、能干什么、出问题怎么追溯”的问题。如果你正在负责ETestDEV5的环境搭建、权限分配或者被领导扔过来做平台管理员那这篇内容值得完整看完。就算你只是普通测试工程师了解系统管理的套路也能帮你减少很多“怎么没权限”“配置怎么又变了”的日常困扰。1. 系统管理模块在ETestDEV5里的定位与整体设计思路1.1 为什么一个测试工具也要搞系统管理很多人刚接触测试工具时会有个错觉装好了能写用例能跑测试能出报告不就行了吗为什么还要折腾用户、角色、字典、日志这些东西这个想法在一个人自用时没问题但ETestDEV5这类平台通常部署在测试部门或者项目组的公共服务器上面对的是多个人、多个项目、多个角色的协同场景。一旦超过三五个用户管理的复杂度就上来了。没有账号权限控制就意味着任何一个人都能改动测试配置、删除历史数据、篡改测试结果。这种混乱在嵌入式软件测试这种对追溯性要求很高的领域是致命的。嵌入式测试有个特点就是测试结果往往要跟软件版本、硬件环境、测试人员强关联。一旦出现问题客户也好质量部门也好第一个问题就是谁在什么时间、用哪个环境、执行了哪些操作如果系统管理模块没有把账号、日志、权限这些基础打好这个问题根本回答不上来。从另一个角度看系统管理也是测试平台“工程化”的体现。一个工具能不能从“个人脚本”升级为“团队基础设施”就看它对用户、权限、配置、数据的管理是否规范。ETestDEV5把系统管理做成一个独立模块而不是把配置散落在各个功能页面里本质上就是在告诉你这些事应该被统一管理而不是靠运维人员手工改配置文件。1.2 ETestDEV5系统管理包含哪些子功能从实际的界面布局和常用需求来看ETestDEV5的系统管理模块通常会包含下面这些子功能名称和菜单位置在不同版本里会有差异但逻辑基本一致。子功能核心用途主要使用人群用户管理维护账号、初始密码、账号状态、所属部门系统管理员角色管理定义角色配置角色可访问的菜单和操作权限系统管理员权限分配将角色分配给用户形成完整的账号授权链系统管理员字典管理维护下拉选项、状态字段、枚举值等基础数据系统管理员、测试组长日志管理记录登录、操作、异常等行为支撑审计追溯系统管理员系统参数配置管理存储路径、并发数、超时时间、密码策略等全局配置系统管理员数据备份与恢复备份数据库和测试工程文件异常时恢复数据系统管理员、运维这个结构其实是很多企业管理系统的标准范式。用户管“谁”角色管“能干什么”字典管“选项从哪来”日志管“发生过什么”参数管“系统怎么跑”备份管“数据怎么保”。六个部分组合起来就构成了一个测试平台在运行层面最基础的保障体系。如果你以前只是用过ETestDEV5进行单纯的测试操作我建议你花点时间把这几个子功能逐一点开看看不需要修改任何配置先建立整体认知。很多奇怪的问题比如“为什么我登录后看不到某个菜单”“为什么这个下拉选项没了”“为什么测试报告路径变了”答案都藏在系统管理里。2. 用户与权限管理实操要点2.1 创建用户与账号状态管理的完整步骤用户管理是整个系统管理里操作频率最高的功能。一个常见的场景是新同事入职需要给他开通ETestDEV5账号或者外协人员短期参与项目只需要临时访问权限。这类操作如果流程不清晰很容易出现账号开多了、密码太弱、人走了账号还在等问题。在ETestDEV5中创建用户的常规路径是进入系统管理选择用户管理点击新增。需要填写的核心字段一般包括登录账号、用户姓名、初始密码、所属部门、手机号或邮箱以及最重要的“关联角色”。这里有个操作细节很多新手会直接创建一个用户然后完事了忘了关联角色结果这个人登录后看到的是一个空荡荡的界面什么东西都打不开。正确的顺序应该是先确保角色已经存在再创建用户最后把角色挂到用户上。账号状态管理这块值得单独说。ETestDEV5的用户状态一般分为启用、停用、锁定三种。启用和停用比较好理解锁定通常是连续输错密码触发的安全策略。实际操作中我建议全员默认开启“首次登录强制修改密码”避免初始密码长期不换。初始密码可以统一设成一个临时密码然后让用户在第一次登录时改成自己的密码。这样即使有人在微信群直接发了账号密码截图风险也能控制在一定范围内。2.2 角色与权限分配RBAC模型在测试平台里的落地权限管理如果做得不好很容易走两个极端要么所有人都是管理员要么每个人都要单独配置几十个权限点。ETestDEV5采用的角色权限模型就是业界标准的RBAC模型也就是“用户-角色-权限”三层结构。用户不直接跟权限挂钩而是通过角色间接获得权限。这样做的好处很明显人员的变动只需要调整用户和角色的关系不需要重新配置一颗完整的权限树。举个例子。你有一个测试组里面有测试设计、测试执行、测试组长三种角色。测试设计师需要能新建和编辑测试用例测试执行师需要能运行测试并录入结果而测试组长除了这两块还要能看到报告和审核数据。如果不用角色每个人来了都要逐个勾选权限菜单效率低还容易出错。用角色的话你只需要把三种角色的权限配一次之后无论是新员工入职还是岗位调整就是顺手改一下角色关联的事。在ETestDEV5里配置权限通常是在角色管理中创建一个新角色然后勾选这个角色可以访问的菜单和操作按钮。菜单权限好理解比如“测试设计”“测试执行”“测试报告”“系统管理”。操作按钮权限更细比如“新增”“编辑”“删除”“导出”“审核”。配置时一定要把握最小权限原则也就是“只给够完成工作的权限”。我见过一些团队为了保证省事直接把系统管理员角色复制一份改个名字就发给所有人。这是最大的坑。系统管理这个模块应该永远只对少数管理员开放普通测试人员连看到这个菜单都不需要。一旦普通用户能进入系统管理错误配置字典、误删日志、改了全局参数这些问题就防不胜防了。2.3 一个最小可用的权限分配参考方案考虑到很多团队第一次部署ETestDEV5时不知道怎么分角色我整理了一个比较通用的角色权限矩阵你可以根据自己的团队规模直接套用。功能模块项目经理测试组长测试设计测试执行系统管理员测试设计查看查看新增、编辑查看全部测试执行查看查看查看新增、执行全部测试报告查看查看、导出查看查看全部缺陷管理查看查看、审核新增新增全部字典管理无查看无无全部日志管理无查看无无全部用户与角色无无无无全部注意这个矩阵里“查看”和“编辑”是分开的。有些团队一开始把测试执行角色配了编辑测试用例的权限后来测试用例被人误改了也查不出来。权限细分的时候多花五分钟后面省的不止五小时。还有一个容易被忽略的点ETestDEV5的权限是通过菜单和按钮两级控制的光勾了菜单权限没勾按钮权限用户能看到页面但点不了新增按钮。配置完成后一定要用这个角色的账号实际登录测试一遍而不是只看配置界面的勾选结果。3. 字典管理配置化基础数据的正确玩法3.1 字典管理一般有啥用为什么说它是降本利器字典管理是系统管理里一个很容易被忽略但实际价值非常高的功能。很多人在前端系统里见过“字典管理”四个字但不知道它到底是干什么的。我用最直白的话解释系统里所有下拉框、选择框、状态标签的选项都来自字典。举个例子。测试用例有“优先级”字段选项是“高”“中”“低”。如果你不用字典管理这些选项要么写死在程序代码里要么散落在数据库的各个表里。想新增一个“紧急”级别就得让研发改代码、发版本。而有了字典管理你只需要在界面上新增一条字典项保存之后所有用到这个字段的地方全部自动多出新选项。在ETestDEV5这类测试工具里字典的典型应用场景包括测试用例优先级的选项、缺陷严重等级的选项、缺陷状态的流转选项、测试阶段的选项、项目类型的选项、测试环境类型的选项等等。可以说凡是界面上那种点击后弹出列表让你选的东西十有八九都是字典在起作用。这个设计对于测试平台管理员来说真的太重要了。嵌入式测试项目经常要根据客户要求调整缺陷等级定义比如某个客户要求把“轻微”拆成“轻微”和“提示”两个级别或者要求增加“致命”和“严重”之间的一个“高危”级别。这类需求如果走研发发版流程少说也要一两天而通过字典管理五分钟就搞定还不用中断系统使用。3.2 在ETestDEV5中配置字典项的操作步骤ETestDEV5的字典管理一般分为两级结构字典类型和字典项。字典类型是分类比如“缺陷严重等级”字典项是具体选项比如“致命”“严重”“一般”“轻微”。操作时一定要先理解这两级的关系不要混为一谈。以扩展“缺陷严重等级”为例操作路径是进入系统管理找到字典管理在左侧选择“缺陷严重等级”这个字典类型右侧点击新增字典项填写字典键值、字典标签、排序号、状态、备注保存即可。这里有几个字段的填法值得注意。字典键值一般是程序存储时使用的值比如数字1、2、3、4不要轻易改动因为一旦已经有数据用了这个键值改了会导致历史数据无法正常显示。字典标签是界面上展示给用户看的文字比如“致命”“严重”这个可以随时改。排序号控制选项在下拉框里的顺序。状态决定这个选项是否在界面上出现。一个实际的配置建议新增选项时键值继续往下排不要复用已经停用的键值。比如当前最高键值是4新增的“高危”可以设键值为5。即使后来“提示”要加在“轻微”后面键值也要按全局递增来分配而不是跟位置绑定。很多数据错乱的案例都是因为管理员觉得“这个选项在第三个位置所以键值必须是3”结果历史数据全乱了。3.3 字典管理的避坑经验改之前先想清楚三件事字典管理虽然操作简单但影响面很大因为它是全局性的配置。改一个字典项可能影响所有项目和所有历史数据。我在实际操作中总结出三个必须注意的坑。第一字典键值一旦被引用绝对不要修改。键值是数据表里真正存的东西标签只是给人看的。标签从“一般”改成“普通”没问题但键值从2改成5所有关联数据都要跟着变ETestDEV5不会自动帮你做数据迁移改完的后果就是历史报告里显示的缺陷等级全是错的。第二同一字典类型下的键值要保持全局唯一字典项之间的键值不能重复。如果你建了状态“已关闭”键值为1又建了状态“已完成”键值也为1程序判断状态时就会混乱明明选的是“已完成”保存后读出来却是“已关闭”。第三停用字典项要谨慎。把某个字典项状态改为“禁用”后新数据不能选它了但历史数据仍然引用着它。如果界面展示逻辑没有做兼容可能历史数据会显示成空白或者异常。稳妥的做法是先新增替用选项再停用旧选项并且留出一段过渡期而不是直接删除。删除字典项这个操作我建议谨慎为之不到万不得已不要删。字典管理用得好测试团队可以自己维护基础数据不用每次都提工单找研发。这也是ETestDEV5把系统管理开放给测试团队的意义所在。但权限越大责任越大字典改动之前最好在备注里写清楚修改原因和时间方便以后追溯。4. 系统日志与审计追踪出了问题找得到人4.1 ETestDEV5的日志体系应该怎么用系统日志可能是系统管理模块里最不受欢迎但又最关键的功能。平时没人看出了事谁都想知道去哪看。ETestDEV5的日志管理一般包含操作日志、登录日志、异常日志这几类。操作日志记录的是用户在系统里做了什么操作比如新增了一条测试用例、修改了测试配置、导出了一份报告、删除了一个项目。登录日志记录的是谁在什么时间、从哪个IP地址登录了系统登录是否成功。异常日志记录的是系统运行过程中出现的错误比如某个接口超时、某个文件读写失败。在实际的测试平台管理中日志的审计价值主要体现在几个方面定位误操作、追溯数据变更、排查账号安全问题、分析系统异常。尤其注意操作日志的字段。一条完整的操作日志通常包含操作人、操作时间、操作模块、操作类型、被操作对象、操作详情、操作结果。ETestDEV5在保存日志时会把请求的关键参数也记录下来所以不管操作是成功还是失败都能还原现场。日志保留策略也值得关注。在ETestDEV5的系统参数配置里一般可以设置日志保留天数默认可能是90天或者180天。对于嵌入式测试项目项目周期往往长达一年以上日志保留期最好覆盖整个项目周期否则项目结束后想追溯某个操作日志已经被清理了就尴尬了。日志会占用磁盘空间这个矛盾可以通过定期归档来解决而不是简单粗暴地缩短保留期。4.2 一个日志排查的实操示例分享一个我实际遇到过的场景。一位测试工程师反馈某份测试报告突然不见了怀疑是系统bug。如果只看业务功能这个问题可能查半天也摸不着头脑。但通过操作日志排查路径就很清晰。进入日志管理筛选操作模块为“测试报告”操作类型为“删除”时间范围选择报告丢失前的一周。几秒钟后日志列表里出现了两天前的一条记录某用户在工作时间之外删除了一份报告操作详情里明确显示了报告名称和ID。有了这条日志就可以直接去找相关同事确认操作意图了。如果发现是误操作通过ETestDEV5的数据备份或者回收站机制恢复数据即可。如果没有日志这个问题就只能靠猜最后很可能演变成一场扯皮。这个例子说明系统管理中的日志功能本质上是一个“后悔药”机制。它不能阻止操作发生但能在操作发生后快速定位责任人、还原操作现场。所以我强烈建议管理员定期检查日志管理模块是否正常运行确认日志有在记录而不是等到需要查日志那天才发现日志功能早就被关了。4.3 日志审计的日常巡检建议日志不是出了事才去看的平时也应该定期巡检。我个人的习惯是每周花十分钟看一下登录日志和异常日志。登录日志重点关注异常时间段、异常IP的登录尝试如果有连续多次密码错误说明可能有人在暴力破解账号。异常日志重点关注反复出现的报错比如某个存储路径写不进去、某个外部接口连接超时。ETestDEV5的日志管理界面一般支持组合筛选和导出定期把异常日志导出留档也是一个好习惯。如果条件允许还可以把日志输出到独立的日志服务器跟业务数据分离存储避免测试平台本身的磁盘空间成为瓶颈。当然这个属于运维层面的优化小团队可以根据实际情况决定是否落地。5. 系统参数配置与数据维护5.1 常用系统参数配置的作用和调优经验ETestDEV5的系统参数配置表面上是一堆不起眼的设置项实际上对系统运行的稳定性影响非常大。最常见的参数包括测试数据的默认存储路径、测试报告的导出路径、并发执行的任务数上限、用户登录超时时间、密码有效期、日志保留天数、文件上传大小限制等等。存储路径的配置尤其重要。嵌入式测试项目会有大量测试记录、日志文件、附件和报告如果不区分项目、不分目录地堆在一起时间久了会出现两个问题一是磁盘空间被撑满二是找数据特别难。我建议在配置存储路径时按照项目名称加日期分层的目录结构来规划例如测试数据根目录下面按项目ID分目录每个项目目录里再按日期分子目录。ETestDEV5支持在系统参数里设置路径模板你可以根据自己的命名规范调整。并发执行数的配置直接影响测试任务的执行效率。举个例子默认并发数是2当你同时提交多个测试任务时后面的任务就得排队等待。如果服务器CPU和内存资源有富余可以适当调大并发数比如调到4或者按照物理核数的一半来设置。但如果服务器本身配置一般强行调高并发数反而会导致单个任务执行变慢甚至内存溢出。这个参数没有绝对标准最好在项目不忙的时候做一轮压测找到一个平衡点。登录超时时间和密码有效期属于安全类的参数。嵌入式测试项目经常有外协人员参与如果登录后一直挂着不操作账号很容易被滥用。建议把登录超时时间设为15到30分钟密码有效期设为90天左右。注意密码有效期调短之后用户会频繁收到修改密码的提醒可能有抵触情绪所以最好提前通知。5.2 数据备份与恢复多少人栽在没有备份上系统管理里还有一个平时用不上、但关键时刻能救命的功能就是数据备份。ETestDEV5的数据包括两部分数据库里的业务数据比如用户信息、测试用例、测试结果、字典配置、系统参数以及文件系统里的测试工程文件、测试报告、附件等。备份时要确保两部分都覆盖到。ETestDEV5一般提供手动备份和自动备份两种方式。手动备份适合在关键操作前做比如升级版本、批量导入测试数据、调整字典结构之前先手动备份一份操作出问题可以快速回退。自动备份适合定期执行比如每天凌晨。备份内容的保留可以根据磁盘空间和项目周期来定。我遇到过不止一次这样的事某团队觉得数据备份太麻烦一直没配置结果一次误操作把一个项目的测试用例表全删了又因为操作日志保留期太短查不到详细信息最后只能凭记忆重新录入一部分用例浪费了大量时间。备份这件事真的不能省。备份文件本身也要注意安全。ETestDEV5的备份文件可能包含完整的测试数据和用户信息属于敏感数据存放位置要严格控制访问权限最好加密处理。恢复演练也是一个容易被忽视的环节。有的人配置了自动备份但从没有实际恢复过等到真正需要恢复数据时才发现备份文件损坏或者不完整。建议每隔一个季度做一次恢复演练确认备份文件可以用。这个时间成本不算高但带来的确定性很值。6. 常见问题与排查技巧实录6.1 用户无法登录的常见原因系统管理相关的日常问题里用户无法登录绝对排第一。ETestDEV5中遇到这种情况先不要慌按照下面的顺序排查。第一检查账号状态。用户管理界面里找到这个账号看是否处于“停用”或“锁定”状态。停用通常是管理员手动操作的锁定一般是连续多次密码错误触发的。如果是锁定管理员可以手动解锁或者等锁定期过后自动解锁。第二检查密码是否过期。如果启用了密码有效期策略密码到期后用户第一次登录会直接被拒绝提示修改密码。第三检查登录日志。日志里会记录登录失败的具体原因比如“密码错误”“账号禁用”“IP不在白名单”这是最直接的线索。还有一种情况是用户自己把账号密码忘了。这时管理员可以在用户管理里重置密码重置后用户需要按密码策略重新设置。注意重置密码之后最好确认一下用户第一次登录时是否需要强制改密否则不改默认密码后面又是一次安全隐患。6.2 权限不生效的排查思路另外一个高频问题是明明给用户分配了角色和权限用户也说已经重新登录了但使用起来还是提示没有权限。碰到这种情况先检查ETestDEV5的菜单权限和按钮权限是否都勾选了。只给了菜单权限没给按钮权限用户能看到页面但点不了按钮提示也就很正常了。然后确认角色是否真的保存成功有时配置了角色之后忘了点保存或者分配到用户之后没有再次保存权限自然就不会生效。最后还要考虑浏览器缓存的问题。特别是前端页面更新过权限配置后浏览器里可能还留着旧的权限数据让用户强制刷新页面或者清除缓存再看。一个比较实用的技巧是权限配置完成后不要只看配置界面直接用一个只有该角色的测试账号实际登录走一遍操作流程确认每个菜单、每个按钮都能按预期工作。这样可以把问题在还来得及修改的时候暴露出来。6.3 字典修改后界面没变化的处理办法字典管理也是容易出问题的地方。常见的情况是管理员在后台新增了一个字典项保存成功但回到业务界面发现下拉框里仍然看不到新选项。第一步先在字典管理里确认这个字典项的状态是“启用”而不是“禁用”。第二步确认排序号设置正确如果排序号特别大新选项可能会被排在下拉列表很靠后的位置被忽略了。第三步考虑浏览器缓存。字典配置保存在服务端但前端界面可能缓存了旧的字典列表强制刷新页面通常就能解决。第四步如果以上都排查了还是不行检查系统日志有没有异常有时是缓存服务需要手动刷新。ETestDEV5有些版本在修改字典后需要等一会儿才会同步到所有在线用户遇到这种情况等一两分钟再刷新看看。6.4 日志文件占用磁盘空间过大日志功能正常运转之后一个新问题会慢慢出现磁盘空间不够了。特别是日志保留天数设置得很长、系统使用频率又高的时候日志文件增长速度会比较快。解决思路有两个维度。一是调整日志保留策略把保留天数和日志级别调整到合适的值。比如把调试级别的日志关闭或降级只保留信息级别以上的日志可以大幅减少日志量。二是定期归档和清理把超过一定时期的日志导出到外部存储后再清理ETestDEV5服务器上的日志。无论用哪种方式都要以不影响审计追溯为前提。清理日志之前最好确认这些日志已经被正确归档。6.5 常见问题速查表为了方便读者直接收藏我把上面这些问题整理成一个速查表。问题现象可能原因处理方法用户无法登录账号停用、密码过期、账号锁定检查账号状态重置密码解锁提示无权限角色未分配、按钮权限未勾选、浏览器缓存检查角色关联勾选按钮权限强制刷新字典新增后不显示状态禁用、排序靠后、缓存未刷新启用字典项调整排序刷新页面日志磁盘占满保留天数过长、日志级别过高调整保留策略清理并归档日志数据被误删无操作日志、备份缺失配置日志和自动备份定期恢复演练系统参数修改后不生效需要重启服务、浏览器缓存确认是否需要重启刷新缓存6.6 系统管理规范化的三个建议最后分享三个我在实际运维中积累的经验。第一ETestDEV5的系统管理应该有明确的责任人不要出现“大家都能登后台”的情况。哪怕团队只有五个人也要指定一个管理员其他人用普通测试账号工作。第二所有涉及权限、字典、参数的修改都养成在备注里记录原因的习惯方便后续人员理解当初为什么这么配。第三定期做一次权限复核比如每季度检查一次用户列表删除离职人员的账号调整岗位变动人员的角色。有些人会问系统管理这么复杂是不是应该让运维或者专业的系统管理员来做这件事。我的建议是测试平台的管理员最好由懂测试流程的人担任因为系统管理里的很多配置比如字典项怎么设计、角色权限怎么划分、日志保留多久都需要理解测试业务的逻辑。技术背景可以慢慢补但不懂业务的管理员很容易把权限和字典配置得看似规范、实际难用。系统管理这个模块用到深处其实就是一种工程素养。很多准备信息系统管理工程师等相关方向的测试同学日常工作中接触到的用户管理、权限管理、备份恢复、日志审计都是这套逻辑。ETestDEV5只是把这些能力做成了一款测试工具里的标准配置。再分享一个小技巧每次ETestDEV5升级版本之前先进入系统管理导出一份完整的权限配置和字典配置备份升级后再逐项比对。版本升级偶尔会带来默认参数的变化一不小心就可能让之前的自定义配置失效。有这个备份在手升级之后恢复配置就是几分钟的事没有这个备份只能凭记忆重新配那才叫痛苦。系统管理不是最花哨的功能但它决定了整个测试平台的管理质量。把这套东西理顺了ETestDEV5才能真正成为你手里的趁手工具而不是一个越用越乱的软件。 
长河君 · 2026/9/9 21:02:36 · 阅读 1.2k ETestDEV5系统管理全解析：权限、字典与日志审计实战
ETestDEV5教程系列更新到第10篇今天聊系统管理。这个模块在测试工具里往往不是最显眼的但恰恰是决定一个平台能不能在团队里长期稳定用下去的关键底座。前面几篇我们讲了测试设计、测试执行、报告生成那些功能解决的是“怎么测”的问题而系统管理解决的是“谁能用、能干什么、出问题怎么追溯”的问题。如果你正在负责ETestDEV5的环境搭建、权限分配或者被领导扔过来做平台管理员那这篇内容值得完整看完。就算你只是普通测试工程师了解系统管理的套路也能帮你减少很多“怎么没权限”“配置怎么又变了”的日常困扰。1. 系统管理模块在ETestDEV5里的定位与整体设计思路1.1 为什么一个测试工具也要搞系统管理很多人刚接触测试工具时会有个错觉装好了能写用例能跑测试能出报告不就行了吗为什么还要折腾用户、角色、字典、日志这些东西这个想法在一个人自用时没问题但ETestDEV5这类平台通常部署在测试部门或者项目组的公共服务器上面对的是多个人、多个项目、多个角色的协同场景。一旦超过三五个用户管理的复杂度就上来了。没有账号权限控制就意味着任何一个人都能改动测试配置、删除历史数据、篡改测试结果。这种混乱在嵌入式软件测试这种对追溯性要求很高的领域是致命的。嵌入式测试有个特点就是测试结果往往要跟软件版本、硬件环境、测试人员强关联。一旦出现问题客户也好质量部门也好第一个问题就是谁在什么时间、用哪个环境、执行了哪些操作如果系统管理模块没有把账号、日志、权限这些基础打好这个问题根本回答不上来。从另一个角度看系统管理也是测试平台“工程化”的体现。一个工具能不能从“个人脚本”升级为“团队基础设施”就看它对用户、权限、配置、数据的管理是否规范。ETestDEV5把系统管理做成一个独立模块而不是把配置散落在各个功能页面里本质上就是在告诉你这些事应该被统一管理而不是靠运维人员手工改配置文件。1.2 ETestDEV5系统管理包含哪些子功能从实际的界面布局和常用需求来看ETestDEV5的系统管理模块通常会包含下面这些子功能名称和菜单位置在不同版本里会有差异但逻辑基本一致。子功能核心用途主要使用人群用户管理维护账号、初始密码、账号状态、所属部门系统管理员角色管理定义角色配置角色可访问的菜单和操作权限系统管理员权限分配将角色分配给用户形成完整的账号授权链系统管理员字典管理维护下拉选项、状态字段、枚举值等基础数据系统管理员、测试组长日志管理记录登录、操作、异常等行为支撑审计追溯系统管理员系统参数配置管理存储路径、并发数、超时时间、密码策略等全局配置系统管理员数据备份与恢复备份数据库和测试工程文件异常时恢复数据系统管理员、运维这个结构其实是很多企业管理系统的标准范式。用户管“谁”角色管“能干什么”字典管“选项从哪来”日志管“发生过什么”参数管“系统怎么跑”备份管“数据怎么保”。六个部分组合起来就构成了一个测试平台在运行层面最基础的保障体系。如果你以前只是用过ETestDEV5进行单纯的测试操作我建议你花点时间把这几个子功能逐一点开看看不需要修改任何配置先建立整体认知。很多奇怪的问题比如“为什么我登录后看不到某个菜单”“为什么这个下拉选项没了”“为什么测试报告路径变了”答案都藏在系统管理里。2. 用户与权限管理实操要点2.1 创建用户与账号状态管理的完整步骤用户管理是整个系统管理里操作频率最高的功能。一个常见的场景是新同事入职需要给他开通ETestDEV5账号或者外协人员短期参与项目只需要临时访问权限。这类操作如果流程不清晰很容易出现账号开多了、密码太弱、人走了账号还在等问题。在ETestDEV5中创建用户的常规路径是进入系统管理选择用户管理点击新增。需要填写的核心字段一般包括登录账号、用户姓名、初始密码、所属部门、手机号或邮箱以及最重要的“关联角色”。这里有个操作细节很多新手会直接创建一个用户然后完事了忘了关联角色结果这个人登录后看到的是一个空荡荡的界面什么东西都打不开。正确的顺序应该是先确保角色已经存在再创建用户最后把角色挂到用户上。账号状态管理这块值得单独说。ETestDEV5的用户状态一般分为启用、停用、锁定三种。启用和停用比较好理解锁定通常是连续输错密码触发的安全策略。实际操作中我建议全员默认开启“首次登录强制修改密码”避免初始密码长期不换。初始密码可以统一设成一个临时密码然后让用户在第一次登录时改成自己的密码。这样即使有人在微信群直接发了账号密码截图风险也能控制在一定范围内。2.2 角色与权限分配RBAC模型在测试平台里的落地权限管理如果做得不好很容易走两个极端要么所有人都是管理员要么每个人都要单独配置几十个权限点。ETestDEV5采用的角色权限模型就是业界标准的RBAC模型也就是“用户-角色-权限”三层结构。用户不直接跟权限挂钩而是通过角色间接获得权限。这样做的好处很明显人员的变动只需要调整用户和角色的关系不需要重新配置一颗完整的权限树。举个例子。你有一个测试组里面有测试设计、测试执行、测试组长三种角色。测试设计师需要能新建和编辑测试用例测试执行师需要能运行测试并录入结果而测试组长除了这两块还要能看到报告和审核数据。如果不用角色每个人来了都要逐个勾选权限菜单效率低还容易出错。用角色的话你只需要把三种角色的权限配一次之后无论是新员工入职还是岗位调整就是顺手改一下角色关联的事。在ETestDEV5里配置权限通常是在角色管理中创建一个新角色然后勾选这个角色可以访问的菜单和操作按钮。菜单权限好理解比如“测试设计”“测试执行”“测试报告”“系统管理”。操作按钮权限更细比如“新增”“编辑”“删除”“导出”“审核”。配置时一定要把握最小权限原则也就是“只给够完成工作的权限”。我见过一些团队为了保证省事直接把系统管理员角色复制一份改个名字就发给所有人。这是最大的坑。系统管理这个模块应该永远只对少数管理员开放普通测试人员连看到这个菜单都不需要。一旦普通用户能进入系统管理错误配置字典、误删日志、改了全局参数这些问题就防不胜防了。2.3 一个最小可用的权限分配参考方案考虑到很多团队第一次部署ETestDEV5时不知道怎么分角色我整理了一个比较通用的角色权限矩阵你可以根据自己的团队规模直接套用。功能模块项目经理测试组长测试设计测试执行系统管理员测试设计查看查看新增、编辑查看全部测试执行查看查看查看新增、执行全部测试报告查看查看、导出查看查看全部缺陷管理查看查看、审核新增新增全部字典管理无查看无无全部日志管理无查看无无全部用户与角色无无无无全部注意这个矩阵里“查看”和“编辑”是分开的。有些团队一开始把测试执行角色配了编辑测试用例的权限后来测试用例被人误改了也查不出来。权限细分的时候多花五分钟后面省的不止五小时。还有一个容易被忽略的点ETestDEV5的权限是通过菜单和按钮两级控制的光勾了菜单权限没勾按钮权限用户能看到页面但点不了新增按钮。配置完成后一定要用这个角色的账号实际登录测试一遍而不是只看配置界面的勾选结果。3. 字典管理配置化基础数据的正确玩法3.1 字典管理一般有啥用为什么说它是降本利器字典管理是系统管理里一个很容易被忽略但实际价值非常高的功能。很多人在前端系统里见过“字典管理”四个字但不知道它到底是干什么的。我用最直白的话解释系统里所有下拉框、选择框、状态标签的选项都来自字典。举个例子。测试用例有“优先级”字段选项是“高”“中”“低”。如果你不用字典管理这些选项要么写死在程序代码里要么散落在数据库的各个表里。想新增一个“紧急”级别就得让研发改代码、发版本。而有了字典管理你只需要在界面上新增一条字典项保存之后所有用到这个字段的地方全部自动多出新选项。在ETestDEV5这类测试工具里字典的典型应用场景包括测试用例优先级的选项、缺陷严重等级的选项、缺陷状态的流转选项、测试阶段的选项、项目类型的选项、测试环境类型的选项等等。可以说凡是界面上那种点击后弹出列表让你选的东西十有八九都是字典在起作用。这个设计对于测试平台管理员来说真的太重要了。嵌入式测试项目经常要根据客户要求调整缺陷等级定义比如某个客户要求把“轻微”拆成“轻微”和“提示”两个级别或者要求增加“致命”和“严重”之间的一个“高危”级别。这类需求如果走研发发版流程少说也要一两天而通过字典管理五分钟就搞定还不用中断系统使用。3.2 在ETestDEV5中配置字典项的操作步骤ETestDEV5的字典管理一般分为两级结构字典类型和字典项。字典类型是分类比如“缺陷严重等级”字典项是具体选项比如“致命”“严重”“一般”“轻微”。操作时一定要先理解这两级的关系不要混为一谈。以扩展“缺陷严重等级”为例操作路径是进入系统管理找到字典管理在左侧选择“缺陷严重等级”这个字典类型右侧点击新增字典项填写字典键值、字典标签、排序号、状态、备注保存即可。这里有几个字段的填法值得注意。字典键值一般是程序存储时使用的值比如数字1、2、3、4不要轻易改动因为一旦已经有数据用了这个键值改了会导致历史数据无法正常显示。字典标签是界面上展示给用户看的文字比如“致命”“严重”这个可以随时改。排序号控制选项在下拉框里的顺序。状态决定这个选项是否在界面上出现。一个实际的配置建议新增选项时键值继续往下排不要复用已经停用的键值。比如当前最高键值是4新增的“高危”可以设键值为5。即使后来“提示”要加在“轻微”后面键值也要按全局递增来分配而不是跟位置绑定。很多数据错乱的案例都是因为管理员觉得“这个选项在第三个位置所以键值必须是3”结果历史数据全乱了。3.3 字典管理的避坑经验改之前先想清楚三件事字典管理虽然操作简单但影响面很大因为它是全局性的配置。改一个字典项可能影响所有项目和所有历史数据。我在实际操作中总结出三个必须注意的坑。第一字典键值一旦被引用绝对不要修改。键值是数据表里真正存的东西标签只是给人看的。标签从“一般”改成“普通”没问题但键值从2改成5所有关联数据都要跟着变ETestDEV5不会自动帮你做数据迁移改完的后果就是历史报告里显示的缺陷等级全是错的。第二同一字典类型下的键值要保持全局唯一字典项之间的键值不能重复。如果你建了状态“已关闭”键值为1又建了状态“已完成”键值也为1程序判断状态时就会混乱明明选的是“已完成”保存后读出来却是“已关闭”。第三停用字典项要谨慎。把某个字典项状态改为“禁用”后新数据不能选它了但历史数据仍然引用着它。如果界面展示逻辑没有做兼容可能历史数据会显示成空白或者异常。稳妥的做法是先新增替用选项再停用旧选项并且留出一段过渡期而不是直接删除。删除字典项这个操作我建议谨慎为之不到万不得已不要删。字典管理用得好测试团队可以自己维护基础数据不用每次都提工单找研发。这也是ETestDEV5把系统管理开放给测试团队的意义所在。但权限越大责任越大字典改动之前最好在备注里写清楚修改原因和时间方便以后追溯。4. 系统日志与审计追踪出了问题找得到人4.1 ETestDEV5的日志体系应该怎么用系统日志可能是系统管理模块里最不受欢迎但又最关键的功能。平时没人看出了事谁都想知道去哪看。ETestDEV5的日志管理一般包含操作日志、登录日志、异常日志这几类。操作日志记录的是用户在系统里做了什么操作比如新增了一条测试用例、修改了测试配置、导出了一份报告、删除了一个项目。登录日志记录的是谁在什么时间、从哪个IP地址登录了系统登录是否成功。异常日志记录的是系统运行过程中出现的错误比如某个接口超时、某个文件读写失败。在实际的测试平台管理中日志的审计价值主要体现在几个方面定位误操作、追溯数据变更、排查账号安全问题、分析系统异常。尤其注意操作日志的字段。一条完整的操作日志通常包含操作人、操作时间、操作模块、操作类型、被操作对象、操作详情、操作结果。ETestDEV5在保存日志时会把请求的关键参数也记录下来所以不管操作是成功还是失败都能还原现场。日志保留策略也值得关注。在ETestDEV5的系统参数配置里一般可以设置日志保留天数默认可能是90天或者180天。对于嵌入式测试项目项目周期往往长达一年以上日志保留期最好覆盖整个项目周期否则项目结束后想追溯某个操作日志已经被清理了就尴尬了。日志会占用磁盘空间这个矛盾可以通过定期归档来解决而不是简单粗暴地缩短保留期。4.2 一个日志排查的实操示例分享一个我实际遇到过的场景。一位测试工程师反馈某份测试报告突然不见了怀疑是系统bug。如果只看业务功能这个问题可能查半天也摸不着头脑。但通过操作日志排查路径就很清晰。进入日志管理筛选操作模块为“测试报告”操作类型为“删除”时间范围选择报告丢失前的一周。几秒钟后日志列表里出现了两天前的一条记录某用户在工作时间之外删除了一份报告操作详情里明确显示了报告名称和ID。有了这条日志就可以直接去找相关同事确认操作意图了。如果发现是误操作通过ETestDEV5的数据备份或者回收站机制恢复数据即可。如果没有日志这个问题就只能靠猜最后很可能演变成一场扯皮。这个例子说明系统管理中的日志功能本质上是一个“后悔药”机制。它不能阻止操作发生但能在操作发生后快速定位责任人、还原操作现场。所以我强烈建议管理员定期检查日志管理模块是否正常运行确认日志有在记录而不是等到需要查日志那天才发现日志功能早就被关了。4.3 日志审计的日常巡检建议日志不是出了事才去看的平时也应该定期巡检。我个人的习惯是每周花十分钟看一下登录日志和异常日志。登录日志重点关注异常时间段、异常IP的登录尝试如果有连续多次密码错误说明可能有人在暴力破解账号。异常日志重点关注反复出现的报错比如某个存储路径写不进去、某个外部接口连接超时。ETestDEV5的日志管理界面一般支持组合筛选和导出定期把异常日志导出留档也是一个好习惯。如果条件允许还可以把日志输出到独立的日志服务器跟业务数据分离存储避免测试平台本身的磁盘空间成为瓶颈。当然这个属于运维层面的优化小团队可以根据实际情况决定是否落地。5. 系统参数配置与数据维护5.1 常用系统参数配置的作用和调优经验ETestDEV5的系统参数配置表面上是一堆不起眼的设置项实际上对系统运行的稳定性影响非常大。最常见的参数包括测试数据的默认存储路径、测试报告的导出路径、并发执行的任务数上限、用户登录超时时间、密码有效期、日志保留天数、文件上传大小限制等等。存储路径的配置尤其重要。嵌入式测试项目会有大量测试记录、日志文件、附件和报告如果不区分项目、不分目录地堆在一起时间久了会出现两个问题一是磁盘空间被撑满二是找数据特别难。我建议在配置存储路径时按照项目名称加日期分层的目录结构来规划例如测试数据根目录下面按项目ID分目录每个项目目录里再按日期分子目录。ETestDEV5支持在系统参数里设置路径模板你可以根据自己的命名规范调整。并发执行数的配置直接影响测试任务的执行效率。举个例子默认并发数是2当你同时提交多个测试任务时后面的任务就得排队等待。如果服务器CPU和内存资源有富余可以适当调大并发数比如调到4或者按照物理核数的一半来设置。但如果服务器本身配置一般强行调高并发数反而会导致单个任务执行变慢甚至内存溢出。这个参数没有绝对标准最好在项目不忙的时候做一轮压测找到一个平衡点。登录超时时间和密码有效期属于安全类的参数。嵌入式测试项目经常有外协人员参与如果登录后一直挂着不操作账号很容易被滥用。建议把登录超时时间设为15到30分钟密码有效期设为90天左右。注意密码有效期调短之后用户会频繁收到修改密码的提醒可能有抵触情绪所以最好提前通知。5.2 数据备份与恢复多少人栽在没有备份上系统管理里还有一个平时用不上、但关键时刻能救命的功能就是数据备份。ETestDEV5的数据包括两部分数据库里的业务数据比如用户信息、测试用例、测试结果、字典配置、系统参数以及文件系统里的测试工程文件、测试报告、附件等。备份时要确保两部分都覆盖到。ETestDEV5一般提供手动备份和自动备份两种方式。手动备份适合在关键操作前做比如升级版本、批量导入测试数据、调整字典结构之前先手动备份一份操作出问题可以快速回退。自动备份适合定期执行比如每天凌晨。备份内容的保留可以根据磁盘空间和项目周期来定。我遇到过不止一次这样的事某团队觉得数据备份太麻烦一直没配置结果一次误操作把一个项目的测试用例表全删了又因为操作日志保留期太短查不到详细信息最后只能凭记忆重新录入一部分用例浪费了大量时间。备份这件事真的不能省。备份文件本身也要注意安全。ETestDEV5的备份文件可能包含完整的测试数据和用户信息属于敏感数据存放位置要严格控制访问权限最好加密处理。恢复演练也是一个容易被忽视的环节。有的人配置了自动备份但从没有实际恢复过等到真正需要恢复数据时才发现备份文件损坏或者不完整。建议每隔一个季度做一次恢复演练确认备份文件可以用。这个时间成本不算高但带来的确定性很值。6. 常见问题与排查技巧实录6.1 用户无法登录的常见原因系统管理相关的日常问题里用户无法登录绝对排第一。ETestDEV5中遇到这种情况先不要慌按照下面的顺序排查。第一检查账号状态。用户管理界面里找到这个账号看是否处于“停用”或“锁定”状态。停用通常是管理员手动操作的锁定一般是连续多次密码错误触发的。如果是锁定管理员可以手动解锁或者等锁定期过后自动解锁。第二检查密码是否过期。如果启用了密码有效期策略密码到期后用户第一次登录会直接被拒绝提示修改密码。第三检查登录日志。日志里会记录登录失败的具体原因比如“密码错误”“账号禁用”“IP不在白名单”这是最直接的线索。还有一种情况是用户自己把账号密码忘了。这时管理员可以在用户管理里重置密码重置后用户需要按密码策略重新设置。注意重置密码之后最好确认一下用户第一次登录时是否需要强制改密否则不改默认密码后面又是一次安全隐患。6.2 权限不生效的排查思路另外一个高频问题是明明给用户分配了角色和权限用户也说已经重新登录了但使用起来还是提示没有权限。碰到这种情况先检查ETestDEV5的菜单权限和按钮权限是否都勾选了。只给了菜单权限没给按钮权限用户能看到页面但点不了按钮提示也就很正常了。然后确认角色是否真的保存成功有时配置了角色之后忘了点保存或者分配到用户之后没有再次保存权限自然就不会生效。最后还要考虑浏览器缓存的问题。特别是前端页面更新过权限配置后浏览器里可能还留着旧的权限数据让用户强制刷新页面或者清除缓存再看。一个比较实用的技巧是权限配置完成后不要只看配置界面直接用一个只有该角色的测试账号实际登录走一遍操作流程确认每个菜单、每个按钮都能按预期工作。这样可以把问题在还来得及修改的时候暴露出来。6.3 字典修改后界面没变化的处理办法字典管理也是容易出问题的地方。常见的情况是管理员在后台新增了一个字典项保存成功但回到业务界面发现下拉框里仍然看不到新选项。第一步先在字典管理里确认这个字典项的状态是“启用”而不是“禁用”。第二步确认排序号设置正确如果排序号特别大新选项可能会被排在下拉列表很靠后的位置被忽略了。第三步考虑浏览器缓存。字典配置保存在服务端但前端界面可能缓存了旧的字典列表强制刷新页面通常就能解决。第四步如果以上都排查了还是不行检查系统日志有没有异常有时是缓存服务需要手动刷新。ETestDEV5有些版本在修改字典后需要等一会儿才会同步到所有在线用户遇到这种情况等一两分钟再刷新看看。6.4 日志文件占用磁盘空间过大日志功能正常运转之后一个新问题会慢慢出现磁盘空间不够了。特别是日志保留天数设置得很长、系统使用频率又高的时候日志文件增长速度会比较快。解决思路有两个维度。一是调整日志保留策略把保留天数和日志级别调整到合适的值。比如把调试级别的日志关闭或降级只保留信息级别以上的日志可以大幅减少日志量。二是定期归档和清理把超过一定时期的日志导出到外部存储后再清理ETestDEV5服务器上的日志。无论用哪种方式都要以不影响审计追溯为前提。清理日志之前最好确认这些日志已经被正确归档。6.5 常见问题速查表为了方便读者直接收藏我把上面这些问题整理成一个速查表。问题现象可能原因处理方法用户无法登录账号停用、密码过期、账号锁定检查账号状态重置密码解锁提示无权限角色未分配、按钮权限未勾选、浏览器缓存检查角色关联勾选按钮权限强制刷新字典新增后不显示状态禁用、排序靠后、缓存未刷新启用字典项调整排序刷新页面日志磁盘占满保留天数过长、日志级别过高调整保留策略清理并归档日志数据被误删无操作日志、备份缺失配置日志和自动备份定期恢复演练系统参数修改后不生效需要重启服务、浏览器缓存确认是否需要重启刷新缓存6.6 系统管理规范化的三个建议最后分享三个我在实际运维中积累的经验。第一ETestDEV5的系统管理应该有明确的责任人不要出现“大家都能登后台”的情况。哪怕团队只有五个人也要指定一个管理员其他人用普通测试账号工作。第二所有涉及权限、字典、参数的修改都养成在备注里记录原因的习惯方便后续人员理解当初为什么这么配。第三定期做一次权限复核比如每季度检查一次用户列表删除离职人员的账号调整岗位变动人员的角色。有些人会问系统管理这么复杂是不是应该让运维或者专业的系统管理员来做这件事。我的建议是测试平台的管理员最好由懂测试流程的人担任因为系统管理里的很多配置比如字典项怎么设计、角色权限怎么划分、日志保留多久都需要理解测试业务的逻辑。技术背景可以慢慢补但不懂业务的管理员很容易把权限和字典配置得看似规范、实际难用。系统管理这个模块用到深处其实就是一种工程素养。很多准备信息系统管理工程师等相关方向的测试同学日常工作中接触到的用户管理、权限管理、备份恢复、日志审计都是这套逻辑。ETestDEV5只是把这些能力做成了一款测试工具里的标准配置。再分享一个小技巧每次ETestDEV5升级版本之前先进入系统管理导出一份完整的权限配置和字典配置备份升级后再逐项比对。版本升级偶尔会带来默认参数的变化一不小心就可能让之前的自定义配置失效。有这个备份在手升级之后恢复配置就是几分钟的事没有这个备份只能凭记忆重新配那才叫痛苦。系统管理不是最花哨的功能但它决定了整个测试平台的管理质量。把这套东西理顺了ETestDEV5才能真正成为你手里的趁手工具而不是一个越用越乱的软件。