测试日记

关掉视频，卸载游戏后，让我有时间去发呆，这一发呆就不得了，一开始是不适应，没了游戏的寄托，与周围的环境瞬间有些格格不入，我那无处安放的小手。

安静下来后，我发现自己需要对今天发生在自己身边的事进行思考。

我的工作就是找bug，每次发现bug，总有说不出的成就感，工作中难免需要沟通，沟通多了就难免会产生冲突，面对多次的冲突，我总能看到别人身上的问题，但我却很难发现自己身上的问题，尽管我知道自己身上存在很多的问题。

比如，今天，在与后端同事沟通的过程中，我总能发现他身上一些自恋的事情，总是自信的以为，自己已经解决了bug，如果我在针对这个bug提出质疑，那么，他们会一口否决，肯定是你测试的方法有问题，先是质疑你，而不是先去看你是如何测试，业务的逻辑如何，只靠自己的理解去写代码。

人在做决策的时候，往往依赖印象、直觉、经验，这些都是大脑在无声无息的进行的，如果能察觉到这其中的印象并非如眼前所示、直觉并非完全准确、经验的不足，那就不会冒然决策，而会先去思考判断，这种印象的本质，其中的差别是什么，这种直觉来源于何处，有没有更准确的做法，这种经验值不值得信任，可靠的地方在哪里，局限又在哪里。

比如，我遇到一个很多人都会遇到的问题，开发做你隔壁，你为了偷懒，发现问题就直接跟他说，然后你们也很有默契，但问题来了，时间久了，你会忘了你都发现了什么问题，开发也忘了自己改过哪些问题，如果不做记录，在强大的记忆，也会随着工作任务的繁琐而遗忘。所以，我养成的习惯是，只要不是特别重大的缺陷，都会在缺陷工具上提缺陷，一是为了记录，二是为了提高工作效率，即使开发做你隔壁，有时候，你会忘了自己跟他说过什么，正好他又在忙其他工作，他也忘了你跟他说过什么。

大脑时刻都会有想法，如果你不记录你的想法，你是很难清楚自己当时在想什么，是怎么想的！如果你不记录，你就很难去发现自己思考的漏洞。

最近有一个对自身比较大的发现。自己总是无法逻辑清晰的去测试一个业务逻辑，虽然业务逻辑很复杂，导致自己每次测试时候，都按照固有的习惯去测试，这是公司的流程导致的，进度紧张，工作量大，需求不明确，开发代码质量差，而造成了一种繁琐的测试。一个业务功能反侧多次，一个功能影响了其他的功能，缺少足够的全面测试。

要想尽量的发现问题，按照过去的习惯肯定是不行的，那么就要去熟悉业务需求，尽可能的了解需求，才能更快的发现问题，和增加测试的效率。

软件的逻辑非常简单。所有的代码，都是为了数据的传递，一个功能，要深刻的去理解它的基本需求和限制条件，以及边界条件，那么模块关联以后，往这3个方面去执行，能快速发现问题，和快速的验证问题。

测试中，沟通是最关键，发现问题，如果让开发快速明白你的问题，能节省不少的时间。

我发现，有时候，会陷入个人情绪影响中，讨论了半天，没有一个结果，原因是逻辑复杂，双方都没有明确需求，最后跑去问产品，其二，双方沟通能力比较弱，无法通过简单的比喻去描述复杂的逻辑结构，其三，陷入争论的漩涡，从讨论问题上升到谁是谁非。

沟通最有效的方法是，倾听，然后发现对方的漏洞，再用他能理解的语言给予更正，而不是一味的去灌输自己的那一套。