【转】作好软件测试须要具有的思惟方式

　最近部门来了好几位应届毕业生加入团队，咱们也大张旗鼓的组织了集中式的培训，其中我须要对关于 测试 工做进行简介，在培训内容中，我特意整理和回顾了作好 软件测试须要具有的思惟方式，当时也就4张PPT。在此，我再详细整理出文字内容也分享出来给广大的同行。

　　首先，从需求，用户及研发角度考虑，要想为产品贡献最大的力量，就不能只专一于作好测试保证质量这一个方面，而应该是从多个角度全面衡量。

　　从图中，体现出咱们也应该站在用户的角度，研发的角度来考虑产品的总体规划。

　　 用户思惟

　　在工做中，一部分测试同行特别是初入者在对待需求时都过于被动，不太会把产品各个模块的业务串联起来，成了由于需求来了因此作需求，纯粹看着需求文档就开始作 测试用例的设计了，并无想着先把需求理顺了想明白了再开始着手。其实这个阶段也便是很是重要的需求分析及功能点拆解，即便说这主要是产品经理们的主要工做，可是他们也并不是圣贤，对产品设计的细节考虑可能并不周全，甚至严重时会出现较大的需求漏洞，引起较严重的影响。而咱们也应该具有该项能力，若是不能站在公司战略层面考虑该需求对业务上能带来哪些促进，也至少能站在用户的角度考虑能给用户带来什么价值，能知足用户哪方面的需求，同时能及时发现对于用户操做过程当中的体验问题，在糗事百科创始人著做的《结网》一书中，也提出了用户体验的三大原则：别让我等，别让我想，别让我烦。我以为做为一名合格的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. 全局思惟

　　即能把握整个项目的多个方面，多个团队的任务及分工，总体的数据流及业务流，从全局思考是否知足业务需求，这其实并不仅是说对于需求的评审，更多的是关注上下游相关联的系统或接口等，凡是涉及跨团队开展的工做，必定就须要更多的沟通协调，很明显的就体如今对业务理解不正确，接口定义有误，具备全局思惟的人更能在大型项目中游刃有余，体现其leader的潜质，毕竟作leader就须要关注本部门以外其余部门都在干些什么，以备能作出对大局有利的决定。

　　 4. 两极思惟

　　即站在事情的两个极端来考虑，好比数据上的无穷大与无穷小，在数据存储上， 数据库层面字段设置为int与bigint所支持的数量级是不同的，基于业务数据，若是存在超过int的长度的数据，那么在存储上以及代码中，都须要作相应支持，不然就只会显示到该类型的最大值了，并且在业务层面也常常有两个极端的状况，好比商家入驻开店，不少时候都只是考虑到开店该怎么作，却忽略关店的状况。其实在边界值 用例设计方法中也用到了两极思惟模式。

　 　5. 简单思惟

　　简单思惟表如今不少方面，好比常常很是严重的bug均可能是犯了一个很简单的错误引发，在处理测试环境时常常出现没法正常访问，也许可能只是磁盘空间满了而已或者一个简单的配置不正确引发，在平常工做中这样的例子很是多，咱们也要善于一层一层剥开问题的现象，找到其本质，就比如剥洋葱同样，不要一开始就把问题想的过于复杂，每每事情并无那么复杂。

　 　6. 比较思惟

　　比较思惟其实贯穿在咱们整个测试生涯中，测试原本也就是一种验证，根据实际结果跟预期结果对比。并且咱们在平时工做排查问题时，也有很是多须要去对比的，好比配置文件的差别，环境的差别引发的不正常结果，此外，咱们也经过svn中代码diff的差别来明确改动的范围制定回归策略。还好比在作一些先后两个版本吐出的数据差别时，页面显示差别时，均可以使用diff的思想来开展自动化的工做，大大提升效率。其中，包括我好久以前写的《我在兰亭这三年（九）之AutoDiff自动化测试框架》也是基于比较的思惟。

　　总之，用好了以上几种思惟方式，我想在之后的测试工做中，必定更加的游刃有余，有效且高效！