网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
测试用例可以把产品需求转换为可操作的步骤【步骤、操作、输入、输出、优先级等】，
从而指导测试人员按部进行测试。
2、验证产品的需求是否合理
产品的逻辑关系会在用例设计时得到推敲验证，从而得出相应结论。
3、帮助评审需求，补充需求细节
编写测试用例时会考虑各种正常异常测试场景【逆向思维】、数据【边界值等】以及兼容性、性能等测试，
会对这些细节部分的处理进行一定的补充与完善。
4、加深测试人员对产品的认识和印象
需求评审时可能用两个小时，讲了一个需要两百个小时投入的需求。
大部分内容只是泛泛的讲解一遍，真整编写用例时，测试人员对需求一句一句的解读，从而转化成可执行的用例，这个阶段才是测试对需求认识更彻底的时刻。
5、便于测试负责人跟进测试进度
负责人根据用例的多少、复杂程度来评估相应的测试用例执行工时；以测试记录来评判测试过程的输出；从而跟进相应的测试进度与输出。
6、帮助发现拓展测试范围
用例设计是可以结合测试方法，从而拓展测试范围，不局限于双眼所看到的表面内容。
7、方便回归测试，复查BUG是否还会出现
回归测试时可以根据一轮测试的结果，重点复测出问题的用例以及功能，从而避免无序、无重点的回归测试。
8、测试结果可以体现测试通过率，作为产品质量评估
可以对测试结果进行统计，统计维度可以有：用例执行率、缺陷发现率、一轮测试通过率
9、培训新人，提高新人测试效率，节省对新人的指导时间
产品指导新人可以看PRD，开发指导新人可以看代码，测试指导新人看什么呢，当然是用例了。用例作为测试人员的核心输出，也是测试人员对产品知识的。
三、如何进行测试用例设计
测试用例设计分析是一个发散的过程，我们要考虑各种各样的场景、数据。
测试用例编写是一个收敛的过程，我们要把发散的思维转化为一条一条可执行的用例。
为了避免用例冗余、多、乱、无效、重复等问题，通常遵循以下原则进行用例设计。
从左到右，由上而下：
元素的布局，用户的操作，都是习惯“从左到右，由上而下”，设计用例时同样遵循这样的原则。
面对一个需求或一个全新的功能模块，在进行用例设计时，为了避免测试对象丢失，用例设计混乱无序，我们遵从“从左到右，由上而下”的原则。
依次对看到的测试对象进行用例设计，测试点发散，最终输出完整的测试用例。
按照上述原则编写的用例，覆盖所有可测对象，基本不会出现测试对象缺失，遗漏等现象。
但容易遗漏多测试对象组合的场景以及应用型测试场景。
从外到内，由点及面：
对于测试路径较深，链路较长的测试场景，我们遵循“从外到内”的设计思路，针对每一层测试路径上的对象，逐个进行设计。
再“由点及面”将路径整合，测试对象整合，以此来丰富场景型、应用型、组合型用例。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新**
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
