软件测试最全测试思维，2024年最新金三银四我带你去BAT面试现场

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

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

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

在工作中，一部分测试同行特别是初入者在对待需求时都过于被动，不太会把产品各个模块的业务串联起来，成了因为需求来了所以做需求，纯粹看着需求文档就开始做测试用例的设计了，并没有想着先把需求理顺了想明白了再开始着手。

其实这个阶段也即是非常重要的需求分析及功能点拆解，即使说这主要是产品经理们的主要工作，但是他们也并非圣贤，对产品设计的细节考虑可能并不周全，甚至严重时会出现较大的需求漏洞，引发较严重的影响。而我们也应该具备该项能力，如果不能站在公司战略层面考虑该需求对业务上能带来哪些促进，也至少能站在用户的角度考虑能给用户带来什么价值，能满足用户哪方面的需求，同时能及时发现对于用户操作过程中的体验问题.

在糗事百科创始人著作的《结网》一书中，也提出了用户体验的三大原则：别让我等，别让我想，别让我烦。我觉得作为一名合格的QA是需要具备这方面能力的，但是在实际工作实操中还是需要具备沟通技巧，毕竟能对于用户体验方面的改进需要产品经理拍板，如果的的确确非常明显的体验问题，是有必要坚持真理说服他们优化的，否则还是把话语权留给他们，我们只是提供建议吧，不然工作中的火药味一定会很浓。

架构思维

要想设计一份有效的测试用例，就必须要对软件开发设计思路有深入的了解，我们也经常有类似的事情，业务需求未做任何改变，而架构做了优化，如果单纯地拿着一份根据业务整理出的用例是无法准确而有效的测试的，架构的调整包括：底层数据结构的调整如分库分表，服务化（SOA），日志的收集处理以及容灾处理等等，另外，为了能有助于测试开展，我们同样需要了解开发技术，毕竟在测试环境的搭建及维护，测试过程中各种场景的模拟特别是异常情况，以及自动化测试，如果不借助于开发技术，自动化工作也是很难开展的。

比如被测系统依赖其他系统发的一条MQ消息而做相应的处理，那自动化代码中为了验证该逻辑，就需要MOCK这条消息（即设置桩Stub）并且发送到某个管道中，让被测应用接受并处理它，如果连MQ是什么都不知道，也不知道如何在代码中发送消息，那这个部分的自动化测试是没法开展下去了。

上面只是举了一个例子，总结一下，需要具备的架构思维包括：

1）了解并熟悉开发使用的技术及开发框架，比如用到的Spring MVC，Mybatis，Redis，前端HTML，JS，相关协议等（视不同项目具体情况而有所不同）；

2）理解研发设计的架构及设计思路，并考察开发设计是否满足业务需求；

3）Review技术方案时，考察是否满足易维护性，易扩展以及对性能和安全的要求，并且在关键业务出现异常时是否添加报警等，而这一点也是大多数从事功能测试的同学最易忽略的。

测试思维

如果要特意区分用户思维和架构思维的话，在测试过程中，就要额外关注：以严谨的测试设计方法覆盖需求功能点及代码分支，具有场景思维和对异常情况的考察。对此我们可以细化总结为以下几点：

1.逆向思维

比如我们经常需要对接口做测试，通过输入验证输出，如果我们使用各种输入都无法得到接口设计中某一种输出的情况时，就需要从输出来逆向推导输入，另外比如验证一些异常情况，接口需要返回一些error code，使用正常手段是肯定不能得到的，就需要为了出现该error code借助环境及工具来模拟。另外，我们在分析很多问题时，同样也离不开逆向思维。

2. 组合思维

比如软件在多用户，多进程，多次执行等情况下，都可能出现意想不到的缺陷，甚至对于复杂的业务场景，在对同一份数据进行操作时，不同子业务并行执行情况下，都有可能造成数据上的错误，特别是对于与核心数据有关的业务上（如money），是否添加行级锁都是需要测试到的，同时，不同业务不同的操作顺序，组合方式下，不同的维度等都有可能出现bug。

3. 全局思维

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

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

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

包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新**

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