网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
很多时候没有需求评审，测试同学连业务是谁都不知道，经常是基于开发的讲解进行测试，写不写测试用例也是看自己习惯了，开发同学也不清楚测试同学要测什么，毕竟也没有时间进行测试用例评审(也没有人负责安排)。
缺乏沟通
没有每日站会和每周站会，开发和测试同学不会主动反馈进度和风险，即使是当前进度不理想的项目大家也都不提，即使要上线了没测完也不管，反正上线就完事，有时候项目经理会追问测试进度。
没有共享文档
所有的测试环境信息、数据库表字段信息、业务说明都是每个人自己保存着自己要用的，大家都不去维护一份公共文档。
没有输出
项目完成之后没有总结，出了线上问题大家也不会复盘，无论开发还是测试都没有整理业务文档、记录项目的习惯。
总而言之，就是十二分不规范。他们可能觉得，本来就够忙了，花时间整这些东西，不是更忙了吗。
殊不知因为流程的不规范，带来的是更低的研发效率和研发质量。遇到这些问题，可以从哪些方面进行改进呢？
流程规范
Testing
测试进度及计划面板
可以在一份共享表格中维护，可以是在一块白板里用便利贴跟进，列出目前开发中的、已提测待测试的、测试中的、已完成的任务，并且标明计划提测时间、实际提测时间、计划上线时间等信息，方便管理测试计划和测试进度。
技术评审
中大型项目在开发之前需要有技术评审，各端开发都需要参与，尽量避免由一个人决定怎么开发就怎么来。
提测规范
达到提测标准时需要发送提测邮件给测试同学，说明改动范围、影响点、自测情况、单元测试覆盖率等。
测试用例评审
中大型需求需要在测试前进行测试用例评审，相关的产品和开发都需要参与。
需求把控
Testing
需求实例化
沟通需求时，测试同学可以将需求用各种形式表现，便于产品、开发之间沟通和确认细节。
梳理流程图：复杂的交互可以画流程图，方便后面的测试同学理解需求。
组内需求沟通
如果是由几个测试同学跟进的大需求，在大家看了需求文档之后安排个小会议室，大家一起头脑风暴一下，由一个人先主讲整个过程，然后其他同学进行补充和提问，达到快速学习和掌握需求的效果。
快速确认测试点
如果是时间紧迫的需求，可以几个测试同学到一个小会议室，结合代码改动点快速确认当前实现是否符合目标，是否有逻辑问题，然后结合需求和改动点快速梳理测试点。
公共点整理：各个重要的模块注意事项和踩坑点汇总成一份各模块checklist，下次测该模块的同学就能尽量少踩坑。
总之，就是发挥主观能动性，有什么好的实践可以帮助提升测试质量和提高测试效率，就可以去做，最重要的是及时沟通。
团队成长
Testing
月度总结
每个月测试组内做一次总结，可以分享典型问题，可以提出一些大家觉得待改进的点，也可以随意吐槽。最后将大家提出的点整理好推动落地。
项目总结
大项目上线后，组织相关同学进行总结，每个人分享觉得自己做得好和做的不好的地方，总结可以改进的点并推动落地。
典型问题学习分享
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
扫一扫
593
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
