年度总结 —— 2023技术栈建立

        23年已经步入尾声了，决定花点时间总结一下今年。总的来说，今年的收获是非常大的，是在具体业务上的理解，遇见 bug 后的沟通，遇见棘手问题后的应对，都有了比较大的提高。想了一下这篇总结的思路，决定用两段工作经历，从两个不同的角度来写。以及最后一些总结。

--------------------------------------------------------------------------------------------------------------------------------

Part 1

--------------------------------------------------------------------------------------------------------------------------------

        2-6月，是刚进职场，角色是产品测试工程师，对整机做功能测试（黑盒）。公司的业务是一个智能健身设备，需要测试的模块有 BMS，HMI，Motor control，整个硬件(整个机器，对应配件)还有后面加入的 App 测试。我是那家公司的第一个测试，很多工作和基础的文档都是从那时候开始建立的，所以从测试角度是存在一些问题的。

1. 没有 PRD 文件，拿到的是各个部门对功能的一个描述，主观性比较大，而且描述的不清楚，对一些名称的描述没有说明，也没有现有的 testcase 可供参考
2. 没有对BUG追踪，新需求描述的工具，例如JIRA等
3. 研发和测试的沟通，抓不到关键信息，复现困难
4. 大boss对于测试工作量可视化比较关心，对于bug描述要求再研发群直接发出来，导致研发测试关系比较紧张

        对于这些问题，解决方案是，从最开始手动操作，熟悉每个功能的实现，对应的边界点，一些 feature 是怎样的。到后来去设计一些 case 验证常规使用区间的稳定，针对模块的特点，对边界的测试。一些模块状态转换可能出现问题的场景，设计；最后总结了两份材料，一份是测试用例信息，一份就是对功能描述的信息（方便后续的测试同事加入时，更快的上手）。对 fail 的用例，多次反复验证，整理复现路径，并且提供给对应部门的研发，测试资料。以及bug修复后，新版本旧版本的对比验证，不同硬件结构的对比验证，并且最后把验证通过的要求也写在后续测试报告文档的最前面，起到规范操作。整个过程是一个自己摸索和不断和对应模块的研发沟通的过程，总的来说，有效的沟通可以加速对整个产品的理解，进而更加有针对性的测试。

        到后来设计一整套回归测试的用例，制定测试计划，自己写一份测试报告，来阐述一个版本中，用例通过情况，对不通过的进行说明，提供复现路径。整个过程，不仅仅是对业务的不断熟悉的过程，也是对测试思维的锻炼。业务通过和开发的不断沟通来进步，对于测试思维的理解，就是通过之前实习的一些经验，加上看了一些测试方面的书，例如《软件测试的艺术》，《硬件产品经理手册》，《测试架构师修炼之道》等等。在实际工作中，来理解书中的一些思路。也就是在这个时候开始知道了，很多时候光看一些帖子，是不够的，整个知识体系还是需要看一些相关的书籍来支撑的。其中提到了一本关于硬件产品经理的书，这个是因为当时产品还没有量产，甚至可以说是刚刚进入试产，当时的 mentor 那家公司的 CEO 希望可以了解一些各方面的知识，这样在测试的时候，思考的角度更全一些。

        最后在这家公司的成果就是：

1. 顺利推动了产品的进度，从研发阶段顺利推进到试产阶段
2. 找到了大概五个P0级别（可能影响生命安全的 bug）
3. 还有在 MKT团队出差前对使用固件版本提供测试报告和质量保障。
4. 还有就是发现了bug 300-500个（每周20个bug以上）
5. 编写原始测试资料，测试团队从1个人变成3个人，充当测试leader角色

        工作了三个多月，就离职了，大概 gap 了半个月入职了现在这家公司。至于为什么离职换到现在这家公司，最主要的原因还是上家公司对于技术的要求比较低，更多的是一种测试的思维，产品的思维的形成。主要的提升可能就是测试思维和工作思维（如何沟通，如何安排自己的工作时间和计划），在大环境不稳定的情况下，没有技术的加持，后期过的非常没有安全感。当然也有部分小公司的通病，管理不规范，996+加班，领导疯狂push，薪资状况不理想等等。不过最主要还是没有技术栈作为支撑，没有安全感。

---------------------------------------------------------------------------------------------------------------------------------

part 2

---------------------------------------------------------------------------------------------------------------------------------

        6月-至今，是现在的这家公司做测试开发工程师，主要的业务涉及单元测试，模糊测试，Jenkins流水线，云测平台管理等。这段时间里，比较大的进步就是代码阅读能力和英语阅读能力。工作中的一个特点就是，很多业务需要自己去解决，所有在业务最终实现的过程中接触过或者简单使用过很多工具和技术，包括adb，qemu，selenium，postman，apk，ko等。之间也贯穿了多种编程语言，golang，python，java，shell，还有一些工具中的语言。

另外看了很多文档，然后需要自己通过文档的方式记录下来一些自己的理解，方便更进一步的学习。看了很多东西，包括Jenkins的官方文档中的一些使用，shell的一些高级应用，syzkaller的一些文档等等。当然，也看了一些书，例如《深入理解Android内核设计思想》，《go语言核心编程》，《Linux命令行与shell脚本编程大全》，总的来说，是有很大提高的。在写这篇文章的时候突然意识到读书笔记的重要，想细说的时候发现自己好像说不上来（因此，接下来在看书的时候会做一些笔记，方便举例说明，或者更深的理解）

        关于在这个阶段的一些工作逻辑的养成，以及一些自己的思考，都在写testdevelopment中了，这里就不做赘述了。文章地址：GitHub - AllenMing3/testdevelopment。

        那就对于waibao做一些自己的个人理解的分享吧。我觉得第一要说的是，不管是一份怎样的工作，必要的责任感还是需要有的。这是一份工作，也是一份自己的事业，在自己的能力范围内，把分内的事情都做完做好，其次才是需要对于业务有一些自己的思考。所有人都知道waibao的工作内容不是核心技术，工作内容杂，对个人提升有限，这点不假。但是环境如此，但我们可以选择在这样环境下如何生存。我觉得，在各项业务中，是可以有一个比较广的了解的，接触了很多业界很多成熟的优质的工具和技术逻辑，剩下的可能需要自己根据这些业务，自己做一些更深的探究了。就比如：在使用Jenkins流水线的时候，整条流水线的实现逻辑是怎么样的，哪个脚本文件去实现哪些功能，在脚本文件中函数的具体实现，对应的一些用法。以及出现问题的时候，如何通过log和对代码的熟悉程度。快速定位到问题出现的原因，以及找对应的人去解决。在代码实现的时候就可以一些相关的书，进一步理解代码的实现，这一点也可能是我目前的一个需要提升的地方，就是代码编写阅读能力到代码编写能力的鸿沟，目前也在试图找到一个办法来解决这个问题。

---------------------------------------------------------------------------------------------------------------------------------

part 3

---------------------------------------------------------------------------------------------------------------------------------

        这一部分说一下关于看书和对明年的期待吧。

        看书是今年才开始的，之前都是静不下心看书的类型。看的书涉及了很多部分，有技术类型的，经济类的，历史类的，还有一些其他各种各样的。感觉看书还是很有必要的，首先是技术，业务上的巩固，这个是立身之本了。其次就是长期自己一个人（不管是工作上还是下班后），面对孤独的一个比较好的解决办法，一些历史类的书，一些他人经历写成的小说，可以比较好的解闷方式，然后也会有一些自己的思考，健全人格吧。当然，还是有一些经济类的，身处当下每个人都希望更了解经济社会的规律来更好的保护自己，甚至给自己创造更多的收入。看书也是一个比较好的 work life balance 的体现吧。最后，看书应该也是一种价值投资，希望自己可以一直坚持下去。

        对于明年（2024年）的期待，还没想好。接下来几周好好想一想。不过可以肯定的事，主题应该是寻找更多的价值感。