测试团队系统#
---
创建日期: 2024-05-20
发布日期: 2025-05-31
---
（来个了结吧，放在草稿里干啥？）
我从A公司离开，觉得流程不正规，什么归档都没有。 没办法，团队太小，在边缘，没什么沟通。
到了Z公司，沟通多，团队分工清晰，文档系统是有在运作的。 但是也越来感觉到，太围绕着人与文档，工作固然能持续，效率并不高。 如果认真想做一份文档，需要筛选信息。 文档质量需要依赖作者的态度，否则日后想要校验，都无从下手。
我很希望有结构化的数据、统一的入口、唯一的信息源。 也算尝试过，没什么结果。 有些行业到了电子化，却没有到数字化。 就也回归到欣赏人的灵活性与文档的传承功能。
虽然没有一个框架能够容纳所有信息、覆盖所有结构、适用所有情况。 但构建系统的尝试我始终觉得该做，效率提升绝非是一星半点。 而且，许多事情，到了跟前，才能发现更多可能。
（然而有些情况，站在原地，看着别人的高峰，就也想到那，一直做方案，不切实解决当下问题、好高骛远，怠矣！）
场景现状#
我们收到来自客户的产品需求，开始评估、研发，再到后来样机生产，进行测试等。 前后、上下游的事情就不过多描述了，单独说测试环节。
测试算是一个多节点的工作，有对产品的理解，有振动噪声这种垂直领域，有数采设备，有项目管理等等。
上游设计开发，会有不同的型号，这部分是基础的产品信息。 相应的测试需求，来自于客户，就需要制定测试计划，组织人员、生产装配、以及设备等等。 同时编写测试大纲，测试大纲会参考历史项目经验，哪些测试项目需要执行、哪些可以忽略。 整个过程需要进度跟踪。 当前这些记录在表格中，做时间计划，做资源分配，做产品定义。 定义测试过程也是在表格中，有步骤、需要采集的信息、测试符合的标准。
等到需要测试的时候，我们需要输入不同的参数同时收集数据。 过程中可能会遇到这样那样的事件，也需要记录下来。 当前测试数据就是存放在硬盘的文件存储中，可能到处都是。 过程中的记录、事件也是一行行填充下来。 等到要回顾数据的时候，需要加载对于的数据，也需要对照着记录回顾发生了什么。
而后是数据分析，结果存储，统计性后处理，以及跨项目、跨类别的对比。 常常分析是一次性的，找到输入，运用工具，分析的结果可能又存储在另一个表格中。 一个项目的结果与另一个项目的结果是独立的，如何分析的、如何格式的、如何存储的都可能不一样。 作为单个项目的分析结论并没有什么影响，可若要回放分析过程、变更参数分析，或者对比不同的项目，那就要重新组织结果或者一切重来一遍。
再将这些内容反馈到设计的修改，当然本身也值得进入知识库，以及更新模板。 所有的这些都在各自负责人员的文档中。
需求组成#
大致内容同上，有：
产品信息库
项目管理
资源管理
测试需求
测试记录表（logbook）
历史数据
分析工具 及其 数据库
失效数据库
涉及 项目管理、执行管理、存储与分析、知识与归档。
首先需要有产品信息库，能轻易获得各个项目产品型号，子型号，以及相关的基础数据。 有唯一的信息源，不同的部门可以使用一致的数据。
需要项目管理，时间、资源计划安排，进度跟踪。
测试需求，根据历史经验（以及客户需求），需要进行哪些类型的测试。 因为也有不少相同的测试，只是参数上有些不同， 能够直接在系统中选择需要什么类型的测试， 最后自动生成大纲。
测试记录与历史数据能够还原当时的测试过程。
分析工具系统，能够进行不同类型的分析。 将分析结果推送到数据库，做统计性分析。 不过每个分析只能对外输出一种默认模型表征，内部的模型需要在分析程序中详细查看。 所以也支持历史分析载入。
对于众多的分析结果，统计性数据，能够进行跨项目或者跨类型分析。 并由此将异常归纳，做失效数据库，而且能够为后续测试计划提供依据。
抽象核心#
其实系统的核心是将一个个的文档或者视觉信息转变成参数化数据的模块。 再由结构化的信息“编译”成传统文档或视觉信息。 两种方式本质信息是一样的。 只是结构化的数据更容易同步、修改、版本控制、编译。
结构化数据也有自己的问题。 例如版本兼容性，需求变化时数据结构需要变化却不一定兼容历史（需求变化除了来自外部，甚至随着时间变化理解不同，同一个人的需求也会变化）； 例如需要额外运营维护，因为结构化数据本身还是需要由前端将消息展示出来，单独的数据本身不适用于阅读。
每个模块数据抽象来看包含三个需求，
模板
对象
版本控制
当介入的人少时，自己可以有结构地将信息放好。 要做跨类型分析，或者跨项目分析，都很容易。 当“合作”的时候，每个人有自己的“风格”，可能就乱了，也需要时间理解。 （现在的自己和过去的自己也会有想法不一的时候）
系统的存在，其实强制输入方式，会丢失一部分信息。（不过可以使用链接的方式将其它信息用更灵活的系统（画布）来存储，不过这样又造成了割裂）
结构化的信息相互之间易于传递，也意味着每个服务需要提供接口。 面向 API，与面向人很类似，只不过每个API只负责自己的事情，而人可能掌握多方面的信息。 每个应用向不同的API去查询，并提供自己的服务。
混合系统#
理想情况，所有的子系统在一个平台上。 现在的最便利的平台，就是基于网页的、所有人可访问的平台。
可这意味着需要大量的从头开始的工作。 而许多的工具、服务是可以模仿系统的（模仿而非仿真），比如文件管理器、云存储同步、电子表格。
在需求还没有定稿时，使用现有工具去搭建混合系统。 保证流程相同，只是形式不一。
能够把事情完成
可用性、通用性
提供服务
统一平台
AI 系统#
每个人能接收到的信息有限，不能看到全局、不容易还原真相。 如果当有一个人能够接收所有输入，做出的判断、资源安排或许会更有效些，但是谁也没有这种能力与精力。
初识神经网络时，许多人都有这种想法，例如振动数据： 直接把振动数据扔给模型，告诉我们异常之处。 且不说不同的产品，选点不同其结果并不可相提并论。 信号中所含有用信息，或者万分之一，且我们认为量大的信息，对训练不值一提，不能让模型真正理解其产生的物理规则。
其实我仍然在做着学生时代所听闻的事情：按照特性进行故障诊断，或者做自动化专家系统。 而在新的时代，许多人都想有个AI系统，问“嘿，我得到了这么一个结果，你能根据历史数据告诉我是什么原因吗？”。
这种系统要么需要独立调教，比如专业的振动分析，或者专业的视觉检测。 那么需要给这个系统提供有效的输入（信息筛选），合适的算法以及大量数据。 然而对于我们来说大量的数据对训练模型可能只是杯水车薪。 如此细分的领域，不同于语言大模型，因为语言本身很难说有对错之分。
要么先会通用逻辑，能够理解并思考输入的含义，成为一个真正的电子的工程师。 接收各种输入，将信息整合并分析。
常常要用理智告诉自己，现在的科技并没有到这一步，也不知道会不会到这一步。 但是又会不断地想象，谁知道这天是不是真的能到来。
得在一个范围内，每个公司有自己的指挥核心， 成为最重要的资产之一。 但那个时候，普通人就只是成为了一个执行机构。 纵使过上了不需要劳动的生活，我们这些不习惯于想象与创造的人，又该如何自处？
其它#
我知道做系统不容易，也觉得维护、升级还不破坏原有体系很难。 每个人想法不同，要限制在一个框架内，则要求框架本身得是优秀的设计。 每当想到系统设计时会心潮澎湃，可是过段时间没什么进展又想撒手不管。 也不想把人带到一条看似宽敞的道路，却发现后面的难以走下去。 于是这些年，更多的是原有方式的增强，可有可无，像长距离走路偶尔碰到的电动人行道。 而系统重构，则像是全程自动送达目的地，很美好，却成本极大、需要运维。
我始终超脱不了自己的狭隘，因为自己没有资源，因为不知道能做到的边界在哪里。 当然每个层面的人都会遇到这样的问题。 只是有的人或坚持、或找到了方法让这些发生，有的人放弃了、失去了方向。