敏感
软件测试最本质的特征是要善于发现产品中的问题与不足。一个优秀的测试人员要对被测内容保持一种敏锐的感觉。这种感觉不仅仅是从产品的正面角度，也要从客户维度考虑，甚至有些时候还要保持对架构的敏感。比如说，我们的架构设计中包含了缓存、消息队列，那么我们在考虑测试方案时还需要充分考虑缓存清理、消息队列消费、超时重发等异常场景。这样的敏感度除了职业上的特征，还需要对测试经验和扎实技术基础的掌握，才能如猎狗般快速嗅探出其中的 “不对劲”。
技能掌握的层次
知识的掌握是分层次的，而在我们的测试领域亦然，我们一起由浅至深逐步探讨一下：
第一层：死记硬背
假设你明天要参加一场笔试，一家你非常心仪的公司。但是由于时间问题，你几乎没有做太多的准备，而你要笔试的内容是你几乎没有太多了解的领域。而你想在这场笔试中拿到高分，恰巧不久前刚刚有朋友参加了这场笔试，还全程记录了下来。于是，你找到了朋友中这个领域的专家，帮你做出了标准答案。你呢，花了一夜的时间把答案拼命背了下来。第二天你笔试的成绩，甚至可以比那些日常工作就是这个领域并且花了很多时间准备的人答的还要好。
当然，这样做的坏处就是这些所谓的知识，除了可以用在你这场笔试的卷子上，在其他情况下，这些知识就是完全无用的。想来高考补习班、考研押题班大多用的是这种方法，应试教育中标准答案的存在，给了人走捷径的可能。
第二层：记忆储备、理解、可检索
到了这一层，其实就是了解技术的背景是什么，在什么场景下运用，以及其中一些概念的含义，但可能在具体场景使用上的细节不太清楚，通俗来说，就是知道学了这个可以干什么，大体怎么做，但是落到具体实践上可能做不出来。
再举一个例子，今天你看到了一篇文章，是讲解关于 Jmeter+Beanshell 的使用，于是你明白了什么情况下可以使用 Beanshell，清楚了实际上 Beanshell 就是在 Jmeter 里执行 Java 类，但是具体怎么在 Jmeter 里配置使用就不是特别清楚了。
这天，有个朋友和你说：XX 啊，今天我想用 Jmeter 接口测试的过程中想额外地调用开发编写的一个 Java 类，可是不知道怎么做才好。
这时候，你提取到 Jmeter 和 Java 的相关信息了，根据之前记住的理解的，跟朋友说：你这个可以用 Beanshell 直接写一个 Java 类，然后在 Jmeter 里边调用啊。
朋友一听，非常高兴：XX，你好棒啊！
仔细分析了一下，其实呢这个时候你的头脑中对于 Beanshell 还只有一个大体的理解，当朋友说到 Jmeter、Java 一些关键字的时候，你自动检索了相关的知识出来，尽管并不太清楚细节，但至少是可以开始操作的。
当然，如果这时候朋友再多问一句的话就很尴尬了：那能教教我怎么做么？
第三层：消化、可为己用
如果说在第二层还仅仅停留在求 “知” 阶段的话，那么到这一层，就应该可以算作是由求知突破到了学技。简单来说，到了这一层，已经理解并消化了应该怎么做，并可以把自己的知识应用到解决实际问题上。
这一天，另一个朋友又和你说：XX 啊，今天我想用 Jmeter 接口测试的过程中对数据库进行备份还原处理，本来是可以用 DBUnit 来做的，但是在 Jmeter 里就不知道怎么把它们集成到一起了。
这时的对话里已经没有 Java 的相关信息了，但是你知道这是类似的场景，是可以处理的，于是跟朋友说：你这个可以用 Beanshell 引用 DBUnit 写一个数据库处理的类，然后在 Jmeter 里边添加 Beanshell 的处理器调用。
朋友一听，惊喜到：XX，你果然是 Jmeter 问题的解决专家啊，太给力了！能教教我怎么弄么？
你很自信的说：没问题，我一会帮你写个 demo 出来给你。
看，到这个时候，你的学习内容已经可以自由使用了，或者换句话说，只有到这里，你所学的知识才变成你自己的，而不是那些你只能检索的文字信息流了。当然，涉及到经验和熟练度的问题，当我们对知识使用考虑得越多，那么解决各种相关问题的速度就会越快。
第四层：深化、归纳、创新
到目前为止，我们的知识使用还仍然停留在模仿阶段，只是模仿的程度有高有低。从模仿到创造之间还需要一个归纳的过程。
还以刚才的例子，你发现原来 Beanshell 相关的需求有这么多，公司里组件使用非常频繁。与此同时，使用过程中还发现很多 Jmeter 不能兼容的场景。你发现当前的知识仅仅是掌握已经不够了，还要更进一步，所以你开始仔细研究 Jmeter 的底层代码，归纳总结自己的各种需求，最终二次开发增加了一个组件”Beanshell2.0”，使用这个组件可以完美兼容。
再后来，为了解决很多同事觉得 Jmeter 这些组件化不太便捷的情况，所以针对自己公司的现状，在 Jmeter 之上搭建了一条平台，可以简单配置进行接口自动化测试，并且兼容各种组件和”Beanshell2.0”。
这样，我们就通过了深化、归纳和创新，对知识和技能进行了进一步的整理，不仅仅变成了自己的，还创造出了前所未有的技能，也成为了新一轮知识的源头。
自我实践
听课只是在帮助你学习，但是如何将技能通汇贯通，熟练地去运用它，还需要自我实践的。听课的同时或者是之后，一定要实际去做一遍。比如 Vugen 脚本的录制、修改、参数化、校验点等等，只靠视频讲解是远远不够的，只有你理解一遍操作成功一次，才能够把技能的掌握程度提升到第三层。在操作的过程中你也会发现更多在听课过程中发现不到的细节问题，接下来解决问题的过程也是对知识的特殊场景记忆。
同时，移动端和零散时间也可以再次利用起来，把一些第一次没有听懂的内容，或者实践中有问题的地方，带着问题去二次学习，能够获得更大的收获。
错误日志的作用
不知道是不是因为我的要求过高导致的，我在去很多企业做内训、以及线上线下学员沟通都发现一个通病，80% 以上的测试人员不去看日志。很多人回答我说：测试为什么还要看日志，找开发不就好了？这是一种很浅显的理解，觉得测试人员最重要的就是发现问题，至于找问题，NoNo，那就交给开发人员搞定吧。
我们从两个角度来说日志的作用。先说我们在测试的过程中发现了 Bug，既然测试人员不需要修正 Bug，那么到底还需不需要能看懂日志，需不需要找到问题发生的点和原因呢？我个人觉得是十分必要的。在中小型公司里，之所以测试不受重视主要在于测试只去做 “测” 的工作，而实际上在一线互联网公司里，测试人员需要承担的职责更多，不仅仅是发现问题，还包括定位问题、指明解决问题的方法。
补充：
我说我做性能测试非常专业，我能够在项目设计阶段结合产品需求，和历史同类产品分析出大致的性能要求，并设计出完善的性能场景；发现问题我能够使用一系列工具来监控、定位核心问题，推动开发改动，规范编程行为，预防出现内存泄露、慢 SQL 等问题；通过数据工厂方式进行大数据量模拟；灰度环境进行全流程性能测试，并且在线上进行监控。
OK，这样的例子，如果你能举出来详细在项目中应用的一二三四五以及具体手段，这就叫 “一专”，一定可以成为某领域的专家，不仅仅是 “挖出了水”，还 “挖成了井”，并且保证自己在未来很长一段时间 “有水喝”。