如何将测试刨根问底！

前言

试问：针对测试人员，是否需要有一套完善、系统的排除问题的手段？

回答：针对这个问题，我从下面几个方面来细致解答。

---

目录

情商很重要

方式方法很重要

逻辑思维很重要

总结很重要

---

解决一个问题：情商很重要。

场景：假设有一个沟通能力不强的人，你有问题需要和他沟通并排查。结果可想而知，肯定会很困难，可能连问题都沟通不明白。

结论：测试是需要与各类人群打交道的比较特殊的“销售”，要将你手上bug卖给他们，不是所有的开发人员都会买你这个“产品”的，如何让他们买？可能除了开发个人素质上区别的话，更多需要你的人际交往能力，沟通能力。并且最终联调解决问题，必然需要各种辅助技能

解决一个问题：方式方法很重要。

场景：如何知道数据库每个表对应的字段含义：当初懵懂的问了CTO，他的解答为，不能看单个表的某些信息，而是从全局上、需求上、功能方面考虑。比如：收发消息场景，肯定要有人（from，to）、时间、身份、渠道等等，从自身项目中去总结这些字段含义

结论：成功的因素往往并不全是因为他的天赋和努力，而是他有自己一套完整体系的学习方式和方法，来支撑他有这样的成就。测试亦是如此，掌握一套适合自己的、有效率的学习方法，会事半功倍

解决一个问题：逻辑思维方式很重要

1.测试工程师在测试安卓sdk时，发现一个客服这边收到两条重复的消息：

解决：
①、确定访客是否发出去两条消息 –> 直观查看或者查im消息
②、确定客服前端是否针对一个消息出两条 –> 前端开发者工具，查看后端返回结果
③、查询数据库，来确定这个会话的这两条是否是同一个msgid —> sql查询数据库即可
④、查询这个消息im是否发出来两条msgid一样的消息 —> 可排除是im发出来重复的消息还是客服处理问题。由于客服应该是做了消息的去重，所以问题出现的话，是否是并发导致的？利用接口查询im消息即可

2.一个会话不调度引起的思考

解决：
①、坐席是否满足可调度的状态，例如：连接状态、客服状态和接待人数。
②、首先分析坐席所在技能组的情况。
③、查询redis，查看坐席的真实状态值
④、查询坐席真实已接待会话数和可接待会话数
等等…

3.数据库schema更新引发的问题，沙箱测试突然间发现我的账号登录不上了，百般不得其解

解决：后来查看是options接口报错500，一番咨询开发，询问才发现options表中个别开关时间戳的值显示了 00:00:00，然后再去询问运维发现，他们在沙箱更新数据库的schema。

结论：从上诉的三个例子来看，我们更应该关注的是解决问题的思路，这其实对就要对你的要求更高，思维固然很重要，然而更需要很多辅助工具来支持你的判断、观点。
例如这三个例子分别是业务流程上、使用存储工具和数据库使用。最好要在业务很精的基础上，做横向扩展。包括并不仅限于：linux命令、数据库、redis等存储工具等

解决一个问题：总结很重要

古人云：前事不忘后事之师。

在现今以我理解为：无论前人还是自己所做之事，要记住或记录并加以总结。

对于我自己而言，我每年都会做一个年终总结，算是对这一年我所做过的事、所学过的知识做一个全面概括的认识。这不仅仅是为了记录，而是在于“总结”二字。总结是对这些知识点、过程、思路做一个全方位的扫描，发现有不严谨、不完美的地方，会及时发现并将其修正。这样做的好处在于，你所做过的事动了脑、将其加强记忆或找到更好的方向。

文章 –>【这就是我的测试人生】就是我对2017年的总结，所学过的技术、所做过的事。