测试三大思维
1. 用户思维
2. 架构思维
3. 测试思维
首先，从需求、用户及研发角度考虑，要想为产品贡献最大的力量，就不能只专注于做好测试保证质量这一个方面，而应该是从多个角度全面衡量，即我们也应该站在用户的角度、研发的角度来考虑产品的整体规划。
1. 用户思维
在工作中，一部分测试同行特别是初入者在对待需求时都过于被动，不太会把产品各个模块的业务串联起来，成了因为需求来了所以做需求，纯粹看着需求文档就开始做测试用例的设计了，并没有想着先把需求理顺了想明白了再开始着手。
其实这个阶段也是非常重要的需求分析及功能点拆解，即使说这主要是产品经理们的主要工作，但是他们也并非圣贤，对产品设计的细节考虑可能并不周全，甚至严重时会出现较大的需求漏洞，引发较严重的影响。而我们也应该具备该项能力，如果不能站在公司战略层面考虑该需求对业务上能带来哪些促进，也至少能站在用户的角度考虑能给用户带来什么价值，能满足用户哪方面的需求，同时能及时发现对于用户操作过程中的体验问题。
在糗事百科创始人著作的《结网》一书中，也提出了用户体验的三大原则：别让我等，别让我想，别让我烦。作为一名合格的测试或 QA 是需要具备这方面能力的，但是在实际工作实操中还是需要具备沟通技巧，毕竟能对于用户体验方面的改进需要产品经理拍板。如果的的确确非常明显的体验问题，是有必要坚持真理说服他们优化的，否则还是把话语权留给他们，我们只是提供建议吧，不然工作中的火药味一定会很浓。
2. 架构思维
要想设计一份有效的测试用例，就必须要对软件开发设计思路有深入的了解，我们也经常有类似的事情，业务需求未做任何改变，而架构做了优化，如果单纯地拿着一份根据业务整理出的用例是无法准确而有效的测试的，架构的调整包括：底层数据结构的调整如分库分表，服务化（SOA），日志的收集处理以及容灾处理等等。
另外，为了能有助于测试开展，我们同样需要了解开发技术，毕竟在测试环境的搭建及维护，测试过程中各种场景的模拟特别是异常情况，以及自动化测试，如果不借助于开发技术，自动化工作也是很难开展的。
总结一下，需要具备的架构思维包括：
- 了解并熟悉开发使用的技术及开发框架，比如用到的 Spring MVC，Mybatis，Redis，前端 HTML，JS，相关协议等（视不同项目具体情况而有所不同）；
- 理解研发设计的架构及设计思路，并考察开发设计是否满足业务需求；
- Review 技术方案时，考察是否满足以下要求，而这一点也是大多数从事功能测试的同学最易忽略的。
-
- 易维护性：如回滚机制
- 易扩展性：代码写死与参数配置
- 性能：定时清理临时数据与日志
- 安全
- 在关键业务出现异常时是否添加报警等
3. 测试思维
在测试过程中，就要额外关注：以严谨的测试设计方法覆盖需求功能点及代码分支，具有场景思维和对异常情况的考察。对此我们可以细化总结为以下几点：
1）逆向思维
比如我们经常需要对接口做测试，通过输入验证输出，如果我们使用各种输入都无法得到接口设计中某一种输出的情况时，就需要从输出逆向推导输入。另外如验证一些异常情况，接口需要返回一些 error code，使用正常手段是肯定不能得到的，就需要为了出现该 error code 而借助环境及工具来模拟。另外，我们在分析很多问题时，同样也离不开逆向思维。
2）组合思维
比如软件在多用户，多进程，多次执行等情况下，都可能出现意想不到的缺陷，甚至对于复杂的业务场景，在对同一份数据进行操作时，不同子业务并行执行情况下，都有可能造成数据上的错误，特别是对于与核心数据有关的业务上（如 money），是否添加行级锁都是需要测试到的。同时，不同业务不同的操作顺序、组合方式下，不同的维度等都有可能出现 bug。
3）全局思维
即能把握整个项目的多个方面，多个团队的任务及分工，整体的数据流及业务流，从全局思考是否满足业务需求，这其实并不只是说对于需求的评审，更多的是关注上下游相关联的系统或接口等，凡是涉及跨团队开展的工作，一定就需要更多的沟通协调，很明显的就体现在对业务理解不正确，接口定义有误，具有全局思维的人更能在大型项目中游刃有余，体现其 leader 的潜质，毕竟做 leader 就需要关注本部门之外其他部门都在干些什么，以备能做出对大局有利的决定。
4）两极思维
即站在事情的两个极端来考虑，比如数据上的无穷大与无穷小，在数据存储上，数据库层面字段设置为 int 与 bigint 所支持的数量级是不一样的，基于业务数据，如果存在超过 int 的长度的数据，那么在存储上以及代码中，都需要做相应支持，否则就只会显示到该类型的最大值了，而且在业务层面也经常有两个极端的情况，比如商家入驻开店，很多时候都只是考虑到开店该怎么做，却忽略关店的情况。其实在边界值用例设计方法中也用到了两极思维模式。
5）简单思维
简单思维表现在很多方面，比如经常非常严重的 bug 都可能是犯了一个很简单的错误引起，在处理测试环境时经常出现无法正常访问，也许可能只是磁盘空间满了而已或者一个简单的配置不正确引起，在日常工作中这样的例子非常多，我们也要善于一层一层剥开问题的现象，找到其本质，就好比剥洋葱一样，不要一开始就把问题想的过于复杂，往往事情并没有那么复杂。
6）比较思维
比较思维其实贯穿在我们整个测试生涯中，测试本来也就是一种验证，根据实际结果跟预期结果对比。而且我们在平时工作排查问题时，也有非常多需要去对比的，比如配置文件的差异，环境的差异引起的不正常结果。此外，我们也可以通过 svn 中代码 diff 的差异来明确改动的范围制定回归策略。还比如在做一些前后两个版本吐出的数据差异时，页面显示差异时，都可以使用 diff 的思想来开展自动化的工作，大大提高效率。
