什么是测感呢？
举几个例子：“在一堆乱七八糟的工牌中每个人都能够快速找到自己的工牌。用的是什么算法？”“如果一群姑娘站在你面前，你一眼看过去，就知道哪个长的漂亮，哪个是你喜欢的哪一型的，不需要用尺子量一量身高，再量一量三围。又用了什么算法？”“一接电话就知道是身边的哪位朋友，这时又用了什么算法？”，“盲人知道自家客厅，卧室的哪个方位，为什么看不见也能知道呢？”所以，测感，直面解释，就是你一眼看上去，对产品业务逻辑及系统结构有一种直觉。
“业务逻辑上下文不连贯，不同业务之间的逻辑冲突，系统实现隐患风险，不同系统之间的耦合影响”等Bug实际上说的就是根据测感分析后的结论。
测感不是你看到某个产品用户反馈问题多的时候，不分青红皂白猛扎进去找问题，那不是测感；
测感也不是你看到某个系统长期无变化，看不顺眼就去找问题，那也不是测感。
“测感”完全是测试工程师自身在测试工作中的亲身体验，而无法从别人那里学来。
“测感”是测试经验和测试理念的综合积累，是亲身感受到的产品、系统“综合信息”的沉淀。
“测感”只能在测试中体验，很难用语言表达，不要把“测感”与非理性划等号。
测感这东西，除了精研各种技术分析的理论外，主要的还是来源于实战。每天不断的看产品、写代码、做测试，做了个五六年的人，想没有测感都不行。
所谓测感,其实就是条件反射，这个条件反射如何产生就是测多了,如何为测多了,就是不断的经验积累。当你测多了，测的时间长，形成了自己的系统，有了自己的方法。
也许有的人测感天生比他人强些，但是这也不完全是天生赋有的，通过不断的训练，只坚持不懈地努力，大多数人会进步很快。
测感训练方法：
良好的测感是测试的必备条件，测感需练，要训练，通过训练大多数人会进步。如何训练测感，可从以下几个方面进行：
一、坚持每天测试，测试的重点在review设计文档，review被测代码，编写测试代码，运行、再运行。 因为产品就在那里，有项目没项目都可以不断的测试。
二、关注每天的被测系统的表现，性能上升下降、bug上升下降。
三、上线后，被测系统成为业务产品。在系统层面要继续关注它的性能上升下降。业务层面，曾经的Bug现在成为了用户反馈，客服量，关注它们的上升下降。
四、条件反射训练。找出一些经典问题并努力解决它们，也许是系统的疑难杂症，也许是业务的复杂变化，不断的刺激自己的大脑。
五、训练自己每日快速浏览系统和产品动态数据情况及可能存在的问题隐患。
六、最核心的是有一套适合自己的操作方法，特别是适合自己。方法又来自上面的这些训练。
总结（复盘）就是利用静态再看一遍项目过程全貌，这针对你动态测试来不及观察、来不及总结等等情况，在产品稳定运行后或者定时你又进行一次翻阅各个环节，进一步明确一下，明确那些系统的压力主要来自哪里，产品的缺陷、客服的问题、系统的故障，产生这些情况原因是什么？哪些业务上涨时期系统和用户的表现是什么，业务稳定期系统和用户的表现是什么？Bug量涨跌主要原因是什么乃至访问量涨跌、用户量涨跌的主要原因是什么等等情况，需要你重新对产品进行复合一遍，更了解业务的变化。
测感并不是一时一刻的反应，而是在经过长期艰苦的锻炼后养成的与自己溶为一体的本能的潜意识反应，他的背后是许多长期统计数据和符合逻辑思维的依据支持的。就象一名枪手，他与枪已经融为一体了。不是在某个时刻，而是在任一时刻，他的枪都能和他一起发射。而出枪的速度和准确率绝对是有保证的，但是那是几年甚至更久和几万甚至几十万子弹的代价。
有人说艺术需要灵感，测感则是灵感的一种表现形式。灵感无法凭空而来，需要日日夜夜的训练。同样测感也无法凭空而来，同样需要日日夜夜的testing而来。