本文主要是介绍点点点还有没有做下去的必要，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
大家好，我是洋子，最近工作特别忙，好久没更文章了
因为组织架构调整，原先的组长调离我所在已经3年多的业务线，我就承担起组长的角色了，除了日常跟进需求测试，还跟RD、跨业务线负责人开会，协助组内QA人力等。有机会跟大家分享，从纯执行层到有一点管理属性的转变（思维、做事方法）
时常有新人，特别是还在实习的同学来问，测试和测开到底有什么区别，我去一家公司测开岗位实习，跟测试一样全是在点点点（需求评审-设计测试用例-执行测试），没有做过开发的工作，担心没有成长太无聊，实习经历也不知道怎么写到简历上，担心没有竞争力
面对这样的情况，咱们该破局？
第一个是摆正心态，招聘实习生进去"打杂"是一件很正常的事情，mentor或者leader不太会一开始把核心工作交给实习生去干，先踏实把业务测试做好，做好基础工作才有机会承接其他工作
第二个是学会思考，有些同学抱怨天天点点点，觉得每天都在做重复的事情，却从来不会思考，其实对于QA要学习的东西也还蛮多的，做好功能测试只是其中很小的一部分，依据将近4年的测试工作经验，我认为在实际工作当中有比较重要的几点可以学习
如果非要总结一下方法论，可以用下面几个关键字概括，了解需求、理解业务、揣摩设计、思考实现、项目管理、质量与效率、通用能力
了解需求
洋子也算是带过几个实习生了，有的同学就是需求都没了解清楚就开始测试，可见这个需求测试质量无法保障。了解需求就是做测试最前置的步骤，我们一般通过查看需求PRD和交互文档来设计测试用例，不要小看这一步，如果QA对需求理解不到位，和PM或者RD存在差异，就可能会导致漏测的发生
业务理解
每次测试的需求，也许改动的只是当前业务的一个很小的功能模块，整个业务的全局构成是什么样子的，核心功能是什么，有哪些入口可以体验，哪些地方需要重点保障等等，了解整个业务员的全貌，能帮助我们完善用例设计，对于测试，应该要比产品更熟悉业务
系统架构设计
一般来说理解业务的基础上，如果还能了解系统的架构设计，那是更好的，线上问题的发生，往往就是出来对于系统架构设计理解还不到位
系统架构设计到底是什么
架构是一个很宽泛的概念，指在设计和构建软件系统或计算机系统时所采用的整体结构和组织方式。它涉及到系统的各个组成部分之间的关系、交互方式、功能划分、数据流动、通信方式等方面的决策和规划。
光看概念还是有些抽象，日常工作当中我们看开发给出的需求技术方案里面就包含了架构设计部分，如果是一些比较小的需求，则直接用功能流程图、时序图展示
思考实现
每测试一个需求，其实在测试过程当中，我们还可以去看RD的代码，进行code review，思考代码为什么这样写，这样写有什么好处和弊端
比如邀请好友进行助力这样的场景，有一个助力接口，在实际情况下可能出现多人同时进行助力的并发场景，为了避免程序出错，可以在处理的过程进行加锁，加锁虽然能保证数据一致性，但牺牲了多人可以同时给一个人助力的可能，有用户体验受损的风险
项目管理&流程优化
每一个需求上线，安排的时间都比较紧张，需求发布、开发、测试都有严格的排期，把控项目节奏了，及时同步项目风险也是一项重要技能
对于项目当前不合理的地方，从QA角度可以提出建议，要求PM、RD、UI等角色进行流程优化，或者用技术手段来改进，比如RD缺乏自测，提测质量差，要求RD写单测case，在CI流水线卡单测增量行覆盖率等
质量保障体系&效率提升
对于质量方面，完善好监控是基础手段，对于效率提升方面，可以做自动化测试，甚至根据业务特点自己开发工具，这里只是举个简单的例子，实际质量保障体系和效率提升有很多工作可以去做，为了帮助大家打开全局视野，后续收集一些大厂成熟的质效保障体系方案进行分享
通用能力
沟通，问题推进，资源协调，超强的学习能力，毕竟每天都有新知识、新业务、新场景
最后想跟大家说的就是学会复盘和总结，漏测的Bug，工作上还有哪些可以优化和改进的地方，都是可以拿出来好好分析的
这篇关于点点点还有没有做下去的必要的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
