一、什么是“薛定谔的猫”理论

    基本理解：一只猫，被关在一个密闭无窗的盒子里，盒子里有一些放射性物质。一旦放射性物质衰变，有一个装置就会使锤子砸碎毒药瓶，将猫毒死。反之，衰变未发生，猫便能活下来。

二、人的思维局限性

    之前的博客写过有关故障方面的：，故障产生的根本原因多种多样，但究其一点可归结为：人思维的局限性。回顾起来，无论多么牛的技术人员，当面临从0到1的项目时，为什么会出现那么多的问题(此时的测试人员常常感慨：若干年有经验的老手为何和初出茅庐的新手做出来的东西相差无几)，个人认为，最根本原因：人思维的局限性。某一段时间内，人可以cover住几个点的东西，但一旦需要关注的东西成倍的增加，cover住的难度就会呈指数级别的增加，人不难很好的cover住。

    工作中，历经了几次产品从0到1的过程，前端到后端，web网站，小程序，APP端等等，尽管技术人员的所谓“工作经验”相差很大，开发周期不等，最终提测处理的“半成品”的质量相差无几。提测版本到上线版本，中间隔了几百个bug的距离。

    即便是十分成熟的产品，也需要测试人员来专门测试，如果是核心业务，甚至需要更多的测试和时间，归结到一点，还是开发人员，或者说人的思维局限性的限制。

    人思维的局限性不仅体现在不能同时很好的关注多个点，而且不能把心态很明确的区分开来。拿技术人员开发产品来说，设计和编码的时候，需要你是一个建造者；而测试的时候，需要你是一个摧毁者。二者不可兼得，本质属于心态上的不可兼得。

    因此，开发人员在编写代码时由于思维局限“犯了错误”，有测试人员来check；但测试人员check时“犯了错误”，又如何来应对呢？

三、测试思维的核心思想

    时时刻刻指导QA人员来做质量保障的思想：“薛定谔的猫”。

    无论外界的条件如何（例如：开发人员告诉你并未改动代码肯定不会有问题；做了同路径的测试，不用全量了；评估下来，某块功能非核心，也未受本次的任务影响，加上时间紧，任务重，可以跳过了...），测试头脑中最为核心的思路必须使用“薛定谔的猫”：某个项功能，只有被验证是正常的情况下，才可打钩；否则最终的结果会是个问号。

    to be or not to be ,需要你的亲自验证啊。

    整个产品质量保障过程中，一直要遵守这条最重要的规则。一旦由于测试周期长、产品“审美疲劳”、被反反复复的产品“折腾”N遍，想放弃[测试原则]的时候，记得：放空你的大脑后，把自己扮演成小白用户，反复“拷问”自己的产品。