《三十六计》是根据我国古代卓越的军事思想和丰富的斗争经验总结而成的兵书，古人用兵最讲究谋略，在中国古代战争史上，精彩的谋略计策层出不穷，令人眼花缭乱，但万变不离其宗，大抵都逃不过这三十六计的范围。时至今日，“三十六计”在我们日常的工作和生活中，同样可以有很广泛的应用。我是一名软件测试工程师，并热爱软件测试这一职业，目前从事测试已有一段时间，我很愿意将自已在从事软件测试工作中积累的一些经验，以及一些心得体会，借助三十六计中的若干计谋加以说明，与诸位同行分享。
总说
【原文】
六六三十六，数中有术，术中有数。阴阳燮理，机在其中。机不可设，设则不中。
【解析】
“兵以诈立”，多谋者胜。用兵要讲究谋略，“运筹帷幄，决胜千里之外”。同样的道理，无论从事什么样的工作，都需要讲究方式、方法。有了正确的方式方法，或者适时的运用一些小技巧，往往可以收到事半功倍的奇效。
第一计 瞒天过海
【原文】
备周则意怠；常见则不疑。阴在阳之内，不在阳之对。太阳，太阴。
【译文】
防备周全时，更容易麻痹大意；习以为常的事，也常会失去警戒。秘密潜藏在公开的事物里，并非存在于公开暴露的事物之外。公开暴露的事物发展到极端，就形成了最隐秘的潜藏状态。
【解析】
long,long ago,there is a 很厉害的程序员，名叫关羽，他是计算机专业科班出身，又拥有二十几年的编程开发经验，是当之无愧的资深软件工程师。虽然关羽的专业水平无庸置疑，但是他有一个缺点，就是自视过高，骄傲不可一世，他常常认为自己写的代码十分完美，几乎已经到了自恋的程度。他看不起测试人员，对他们提出的程序错误不仅不屑修改，甚至于不肯承认，并经常与测试人员起争执。有一年他在湖北荆州负责一个十分重要的大型系统的开发，而负责这个系统测试工作的正是关羽向来都瞧不起的吕蒙。这个吕蒙原本学历不高，只有中专文化程度，并且还不大注重学习，提高自己的能力。直到有一次被他的上司孙权教育了一顿，从此发奋图强，进步神速，技术能力迅速提高，早已不是当日的吴下阿蒙。起先吕蒙将发现的错误上报给关羽，关羽并不理会，还是如同以往一样，找出许多理由来搪塞，一会儿说这是个技术难点，无法修改，一会儿又说这是当初的需求没有写清楚。这吕蒙早就清楚关羽的为人，从此也不与关羽多加争辩，只是兢兢业业的做着自己的工作，将自己在测试过程中发现的所有小错误一一如实记录了下来。等到测试报告出来的时候，关羽傻了眼。由于他一时疏忽而犯下的一个小错误，并且错误扩散到整个系统的每个角落，已经无法修改。客户大为不满，项目终于失败！而老板一气之下也把关羽炒了鱿鱼。关羽的一世英名就这样毁在自己的大意上面。这就是在IT业界流传很广，十分有名的“关羽大意失荆州”的故事。
从这个故事中我们可以得到以下几个教训：
1、越是厉害的人物，越容易阴沟里翻船，水平很高的程序员，也很容易因为不注意细节而犯下一些低级的错误。所以身为一名测试者，不能迷信权威或专家，对就是对，错就是错，要勇于怀疑一切。时刻牢记我们代表的是最终用户，并建立这样一个观点：即使一个错误不是程序本身的原因，而是因为操作不便而使用户造成，严格说来，那仍然是一个错误。
2、测试者与开发者的地位是相对独立，但绝不是势同水火，双方彼此同样是项目组的成员，在保证软件产品质量这个大方向上是一致的，彼此都应该互相尊重对方的劳动成果，虚心对待。关羽的直接领导诸葛亮早就告诫过他这一点，让他一定要尊重测试组的劳动成果，不要双方闹翻。可关羽硬是不听，于是造成项目失败。
3、在测试工作中，测试者与程序员的沟通是十分重要的。在双方互相尊重的基础上，彼此都要本着对事不对人的原则，保持严谨的科学态度，共同完成软件的开发。上面的故事中，吕蒙的做法其实也不是十分的正确，不仅遭到了大量关羽的fans的指责，而且长久背负着做人不厚道的骂名，这些倒不重要，更为重要的是，最终整个系统、整个开发团队失败了，他同样是个失败者。更好的做法是在测试的工作中，就要注重沟通问题，当一个错误一直不被修改的时候，与开发人员沟通失败后，应该及时上报给项目的管理者，尽早寻求解决的方法，而不是将错误一直留到测试结束后才暴露出来，此时的错误可能已经造成十分严重的后果，测试报告写得再漂亮也已经没有多大的意义。基于以上陈词，本庭宣判：本案关羽负主要责任，吕蒙负次要责任。关羽斩首，吕蒙打五十大板！^_^
4、想要做好测试工作，学历和技术并不是最重要的，重要的是要有责任心和细心，中专毕业证书是中专学校发的，大学毕业证书是大学发的，而有了责任心和细心的测试员，就不再是普通的测试工程师，而是优秀的测试工程师了。
在开发一个软件产品的过程中，每一个程序员都需要跟成千上万行的代码打交道，他们自己写的代码就像大宝SOD蜜一样的天天见，看多了难免叫人头昏眼花胸闷心烦……再加上每天都看见的东西，很容易就会产生思维定式。一个人偶尔犯错并不可怕，可怕的是他对错误熟视无睹，错啊错啊的就习惯了，于是很自然的把错的当成对的。俗话说“老虎也有打盹的时候”，水平再高的程序员也会有犯错误的时候，因此必然会有一些错误和缺陷是很难被自身发现的，其原因可能是他在阅读需求规格的时候惦记着那天和女朋友吵架的事情开了小差，从而没有好好地理解需求；也可能是他那天正好失恋心情不好而犯迷糊，更可气的是他居然说女朋友都跟别人跑了我的程序写得那么好有什么用，我偏要这么写……所以说没有BUG的软件是不存在的（否则广大和我一样的软件测试工作者靠什么混饭吃？^_^）。
“阴在阳之内，不在阳之对”，我们那些无比智慧而英明的祖先在这里清楚的告诉我们，一个软件产品中最大、最致命的BUG，往往不是如你想象的那么隐蔽、那么难找，而经常是潜伏在你最没有防备、以为最不可能出错的那些地方。这便再一次的证明了这样一个道理：在软件的世界里，不是缺少BUG，而是缺少发现BUG的眼睛！