从事软件测试，我不建议大家盲目地每天都陷入到工作本身里面去，其实偶尔跳出来对工作进行自我总结（也可以像我这样偶尔来写写笔记），对于像我这种从培训班出身的非科班程序员来说，也是可以帮助自己更清晰地了解测试工作这一岗位，对今后明确技能提升、明确职场发展方向，都是有帮助的。 或者，你也可以理解成，当你遇到一个不懂技术、不知道什么是软件测试的伙伴时，在向他介绍测试工作、或者说交谈各自所从事的工作的意义的时候，能够用最精练的语句来让朋友明白：沃焯，原来你的工作还是很厉害的！（我~骄~傲~） 所以今天的笔记，来和大家聊聊软件架构和产品的功能逻辑： 软件大家都比较清楚了，在一个完整的计算机系统当中，只要不是硬件设备，其他的都可以算作软件；而软件架构则用来确保产品的各项功能逻辑能够顺利实现。 拿现在我们人手一部的智能手机来说吧，一键开机的同时，电源负责给各硬部件通电，确保软件能够开始正常运转。顺序是这样的：通电后手机系统负责检测各器件与模组，然后逐个加载各部件软件系统，直到各个软硬件全部启动完成，然后就是坐等手机主人通过操作来发送各项指令，进行应用程序的启动与运作了。（看似不起眼的几分钟，想不到会有这么多流程吧？） “基于产品功能逻辑来确定系统整体实现框架，并定义和划分各模块的功能”——这就是软件架构。 为什么在日常软件开发和测试的过程中，我们要强调【架构】要能快速应对各种变化？ 答案显而易见，因为我们需要程序员伙伴们把各【模块】的功能定义清楚，以确保各模块在逻辑上低耦合（即减少模块间的相关性）；这样做也是为了确保产品在发生新功能增加、系统优化和bug 修复时，把修改带来的影响范围限制在最小，从而确保软件架构在整体上的稳定性。 这里我对【模块】这个词还是比较喜欢的，你可以把它理解成积木的一部分，想要搭建什么样的建筑模型，随时拿过来把它安上去即可，【模块】本身就放在那，自由灵活、而且又不必重复设计，对其他积木的影响也几乎为0，是不是很赞？ 试想，如果每个项目都能做软件系统架构的最优，那么也就可以大大节省开发和测试的工作时间，大大提升产品团队效率，当然也就意味着可以少点点点、少加班熬夜、少996内卷了吧！！！ （莫名崇拜架构师，也难怪人家薪资高，合理）#软件测试# #it培训# #教育培训# #软件架构# #产品功能# #功能测试#