最全软件测试之对于测试的反思及思考_软件测试思考讨论，2024年最新详解系列文章

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

1.针对一个页面，从页面的完整性(包括字段、输入框、功能点)出发

2.对于分页，考虑未在首页的时候的测试，末页的情况。

3.对条件的查询来说，要针对于单个输入框的测试、交叉输入框的测试

4.对于删除、修改等，要考虑你删除完、修改完等测试用例的执行，往返测试

5.访问的渠道，通过搜索引擎、浏览器、收藏夹等通道进入。

6.先测什么而后测什么，不放过任何软件的死角。在测试中，一定要系统的看待问题，功能模块A的改动会否影响到其他模块的功能，不能想当然，一定要系统性的看待。有时候一个内存地址的改变，都有可能引起整个软件的崩溃

7.针对性能这块，应该采取什么手段进行操作，以便更全面去覆盖所有的点。性能通常进行负载测试、压力测试、安全性测试来校验。但如何入手得经过实践出真知。

8.针对于测试数据准备，我理解的数据准备原则应该是对web网站还是客户端来对于需要填写的数据进行验证，但有的数据是系统本身自带，需公司提供数据进行测试。但具体的数据需要多少还是很迷茫，数据来源从哪方面入手。执行是应该怎么执行

9.通过冒烟测试与第一轮迭代测试，发现许多不足的问题。1.不管你在进行什么样的测试，你必须依托于测试用例来执行，但对于一些用力不足的地方，可以不用依托于测试用例，如数据验证、随机测试等。在执行测试发现BUG了，要记录到缺陷管理系统，并记录BUG摘要、BUG的描述和步骤，这样不但可以节省测试人员与开发人员之间交流BUG的时间，还可以加速开发人员解决BUG的进度。

10.当提交BUG完，需开发人员去修复，并且发布，发布之后，测试人员在重新执行已发布的BUG，看是否解决，对于已解决选择关闭，对于未解决提出反馈。对全部已发布的BUG执行完，召开剩下未解决和已反馈BUG会议，会议主要针对于开发这边是什么问题导致这个BUG未解决还是遇到什么瓶颈，需要提供帮助。

11.测试人员和开发人员之间的协调能力很重要，遇到BUG或在规定时间BUG没解决，容易造成双方有争执现象，在开发和测试感觉必须要搭一个桥梁来使双方都能更好的处理之间产生的问题。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

T行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**