先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7
深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）
正文
先进行需求分析，找出需求规格说明书中不明确、或有疑虑的地方，与需求人员（产品）确认商讨，给出明确定义。
在测试过程中发现没有明确和有疑惑点的，也要与需求人员确认商讨，要求给出明确写定义，之后完成测试用例。
无法及时确定的，可先编写大概框架，之后再将测试用例细化，补充完善。
2、需求变更导致的bug
需求规格变更，导致原来的测试用例与现在的规格不相符合。我们在执行测试用例过程中，如果碰到测试用例与规格不相符合的地方，我们需要记录下，并根据新规格补充完善测试用例，对存在有疑问的地方需要和产品或设计进行沟通和确认，可以要求需求规格进行明确定义，事后将新增的、修改的测试用例整理成文，发给组内同事组织评审，并将评审之后的用例更新到用例库中去。
3、测试用例覆盖不全导致的bug
因为测试用例场景设计导致缺陷遗漏是在所难免的，编写测试用例的同事不可能把所有的场景都能想周全，把所有的场景下的情况都写成测试用例这也是不大现实的。对于外部反馈的缺陷，是因为场景设计不全引起的，我们先分析出现问题的场景是客户必须的场景还是偶然的场景，如果该场景是客户操作习惯，我们可以通过和技术接口人沟通，确认该场景的一些具体细节，在完善测试用例的过程中我们也要考虑一些和该场景相关联的场景，将多种场景下测试用例及时完善、评审，增加到用例库中
4、未严格执行导致的bug
我们需要面对现实，测试用例并不能覆盖所有的使用场景，但是，测试用例是按需求根据规格编写的，经过了需求分析、开发、测试及其他相关人员的评审，最大程度的保证用例的准确性、全面性。测试用例不一定能保证所有的场景和功能点都能覆盖到，但是严格按照测试用例执行测试，能最大程度上保证我们的软件质量，尽量避免出现缺陷。就一句话，我们在测试过程中要严格按照测试用例执行，不要因为测试用例的繁琐而抛弃测试用例，进行随意的测试。如果是因为测试过程中随意的测试，导致出现遗漏问题，实在是不应该。
5、测试时间不足导致的bug
根据功能模块划分测试优先级，主要的功能模块优先级最高，安排有经验的人测试，安排新手测试一些不重要的功能模块或者很少使用的功能模块，在后续测试过程中，由有经验的同学将新手测试过的模块进行冒烟测试，确认是否有明显BUG；
尽量避免在一些和开发扯不清的情况下浪费自己的时间，如果因为开发人员排查问题占用的时间较长，可以告诉测试负责人，由测试负责人采取相应措施，通过协商来避免类似问题蔓延；
增加测试人力
加班
6、测试环境&测试数据导致的bug
原因：环境的组合是无穷的，没有足够的时间、人力和其他资源成本在足够在足够多的环境中测试。
措施：保证主要的操作系统环境，网络环境
操作系统：针对当前使用比例来排序
网络环境：正常网速、低网速
7、开发引入新的bug
验证开发人员修复的BUG，并将相关联的功能点遍历到
方法：根据开发人员的水平，选择合适的回归测试策略。
结语
最重要的是：不要因为漏测，而互相指责或推卸责任。
作为测试人员，让我们把这种情况作为一个机会来审查测试过程，看看问题在哪里，并防止它再次发生。团队里的每个成员都应该为质量负责，而不仅仅是测试人员。
资源分享
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
117)]
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
