我是个很啰嗦的人，内容比较多还是大致区分一下内容

我莽去硬件公司测试了----
“你不能只关注程序，程序必须烧录在主板之后才能运行”。。“你应该观察板子这边几个风扇控制等等控制信号的输出的波形是否正确”
储能 BMS 的 C 研发在我学习了解 BMS 测试时经常这么说。公司划分了硬件设计部门和软件部门，BMS 是一个整体，脱离了硬件的程序就是所谓软件，而我是研发部门目前第一个招聘入职的测试人员。
我了解嵌入式包括硬件相关和传统软件测试（我并没有测试过手机平台，都是各种 java 开发 B/S 架构的项目）差异很大，在最近一次裁员之后考虑到常州本地的 软件服务市场可能并不好做了。毅然投入硬件厂商，因为我觉得无论是什么测试，哪怕对象不是软件其本质目标都是一致的，都是质量控制的一个环节。而公司目前情况特殊，毕竟如果一个公司告诉你我们当前测试岗你是第一个，其实有点经验的工作人员会觉得这是天崩开局，而我正好不在乎。
我们这边的研发团队成员并不多，甚至没有产品经理（硬件迭代比较少，特别是嵌入式程序经过一段时间迭代之后功能是很稳定的）。当研发经理希望我先了解 BMS 功能（一块主板，对的一块板子）我挺蒙的。不管懂不懂把产品相关的文档能看的都看了，关键的测试方式，工作方式相关的内容其实还是需要相关研发人员手把手带着做一遍的，这里并没有什么惭愧的，测试工作本身就是从研发负责自测延申后独立出来的。

最开始艰难的适应入手期-----
其实针对 BMS 主板的测试有很多环节已经在其他部门测试过了。硬件团队会对组件进行验证，而生产部门已经有研发大佬搭建了整套的自动化测试 (UI 工具) 进行快速功能验证。测试台模拟了主板所需的所有外部接口和上下游通信，通过 PC 端的 UI 测试工具模拟上游程序对 BMS 进行主要功能的快速验证。生产部的同事将主板接入之后十几秒就能完成一个主板的基本功能验证。（我寻思还要我干嘛，UI 自动化工具都直接搞了）。
当然，那位研发大佬因为身兼数职 (老板觉得好用所以使劲用所以压力其实挺大）所以对于初入岗位啥都要问的测试人员来说脾气并不好。对于新入行的测试人员来说需要的学习过程其实是公司的某种成本。我自然应该有自知之明，在学习和实践过程输出更多的人性化便于阅读的-h 的操作说明文档、过程文档。
其实单纯一个 BMS 相关嵌入式的学习阻塞颇多，在知道了一个产品应有的测试姿势，也就等于找到了入口。那么具体要测试什么功能，有哪些功能以及如何去测试就成了问题。研发部推出了一个研发来负责编写【功能说明文档】，我确实从中了解了功能骨架，但是文字描述太宽泛，需要深入到可以产出测试步骤始终缺少了一部分内容，而这部分内容在我硬着头皮推进的时候还遇到了几个研发踢皮球的情况。
研发人员提供的描述大致：当状态机收到命令进入充电模式时，步骤 XX 进行参数校验。
测试人员不知道进行了什么参数，（实际测试在这里不通过出现异常），于是研发进一步翻代码进行转译。参数校验步骤内有 9 个校验动作依次进行
然后测试人员不知道这些校验的参数如何得到，又应该是多少才可以通过。
到这里研发开始扯皮（似乎阅读有难度，希望你去问其他研发，其他研发又继续转）。
最后当然解决了，因为我跟研发经理申请了源码权限。以我七八年前二级 C 的了色水平尝试直接阅读理解，结合开发设计手册还真能定位到对应模块最终完全解决了这个问题。
有点有意思的是，传统的 java 上我一直认为研发在有代码权限的情况不存在无法解答的代码逻辑。在嵌入式团队碰到这种情况其实我有点儿意外，因为 java 开发会出现踢皮球的情况多数是因为缺陷难以定位，所以推给其他关联模块尝试想让别人自证无误先。结果在代码细节问答环节竟然能遇到需要自己绕一圈自己看代码的情况。
当然，上面绕了一大圈的解决的问题。只不过是在功能测试的环节完成了一个小小测试案例的测试数据准备环节。相当于为了一条测试案例的 1 个步骤的正常打通投入了数个人天。

入职阶段小结-----
此前说到，BMS 也就是电池管理系统本身是一个整体，我负责的范围主要是烧录在控制板的程序。这个整体在产品的生产、验收阶段公司分别也有对应的冒烟和整机调试测试工作来进行一定程度的验证。但是疏漏就是在运维阶段的系统更新会绕过上述质量流程而引发大问题（我初入公司就碰到了某个项目发布的更新缺陷导致所有 BMS 无法远程升级，然后全跑去项目现场顶着打太阳爬梯子拧螺丝然后刷修复程序）深刻体会到硬件相关缺陷撇开责任不谈哪怕不影响核心那要修复的代价也很爆炸。所以 BMS 代码本身在内部需要补上测试验证环节是必要的，而且就我的测试职责范围不在硬件整体而是缩小到烧录了程序的主板也减轻了我的压力（毕竟硬件是真不懂呐），我之前阅读源码解读的校验逻辑等等，补充的其实是 BMS 下游被控子系统需要配合。对传统软件理解就是需要写一个接口桩，这个接口桩需要一些处理逻辑。我在这期间文档化整理了 BMS 作为一个黑盒测试时，它的上游、下游对主要功能的配合协作关系，并编写了一个小程序可以完全仿真下游系统响应。

调试部门----
小公司的软件开发也好测试也好大概都跑不掉和运维实施团队一家亲，然后就是出差啊之类干一些自己讨厌的事情。只是我目前业务了解太少，菜的没有能力支撑罢了。公司现有一个调试部门，他们的责任是对整个产品进行系统验证，通常有一份验证清单需要按次序执行，也是某种测试流程，特点是验证内容十分固定无非是需准备工作各有不同。这个调试工作是出厂前的整机功能验证，其实类似于软件系统发布之前的系统测试或者验收测试。只是我目前还没有能力负责这类工作而已，我觉得作为一个测试人员从质量保证的角度考虑，这个产品相关的所有测试相关工作我应该是都深入了解，明白他们是如何保障整体产品质量以及是否存在可能的疏漏。只不过初来乍到屁都不懂还是听从研发经理安排去做事情就好（毕竟狭义上的软件测试服务于研发工作）。

嵌入式相关的一些小认知----
回忆起来有一位测试同事曾经在上海做过嵌入式测试的描述 “就是一堆脚本挨个执行就完了”，我其实反复在加深嵌入式的测试很有在完成构建之后因为产品本身变化不大，它的测试其实一直在进行某种主线回归测试的认知。我那位曾经做过嵌入式测试的同学会这么说应该是因为那个公司测试的方案和产品等等都已经固化下来，对应的测试人员只是在框架内维护自动化脚本，执行测试脚本。自动化测试在 JAVA 开发的 B/S 架构产品也经常接触，但是总觉得实用性不强，而在嵌入式这块反而是很实在的东西，我自然也更愿意去主动寻找好的自动化方案来减轻我的测试工作。
当然了，因为 BMS 其实涉及很多模拟信号输入。想要做全面覆盖测试依赖各种仿真设备（都得买或者讨巧去凑合）其实并不容易。反而都是需要专项测试的内容。所谓使用自动化轻松快速验证的内容有其局限性。

后续-----
真真的天崩开局是要测试的产品别说没几个文档，连源码都没几个注释。之前的 BMS 源码基本上每一行都有注释啊！