一提到测试，大家马上会想到Bug，测试仅仅就是为了发现Bug吗？
在《软件工程》中提到：
在《软件测试的艺术》中提到：
- 软件测试的目的就是尽早发现Bug的测试。
- 一个成功的测试就是发现了至今为止尚未发现的Bug的测试。
这么多经典书籍都告诉我们“软件测试的目的就是发现Bug”，不管你用什么方法，黑盒，白盒，或是灰盒，仅是方法不同，而其聚焦点是相同的。我们所
有的前期测试设计工作都是围绕如何高效发现Bug而着想，如测试方案的设计、测试用例的设计、测试执行过程的控制等等。但是，测试的价值真的仅仅是发现
Bug吗？
“意识决定行动，行动决定结果”、“心态决定命运，态度决定一切”，这些都是众所周知的名言，但是要真正应用起来，好难。对于测试工作，除了需要过硬的测试技术外，还必须有正确的测试心态，不同的心态反映了不同的测试境界高度，体现出不同的结果。
最近正在看软件测试核心精解，和大家分享一下我所认识的测试三重境界：
测试的第一重境界：围着Bug转
围着bug转可以分为三个阶段：发现bug，定位bug，关闭bug。三个阶段可以看做是一个bug的生命周期，环环相扣，并且对测试的要求也是越来越高。
1.发现Bug：
找bug的过程是漫长的，反反复复、枯燥无味，这个过程大家应该都是深有体会的，但只要你坚持走下去，肯定会找到一堆堆的Bug。Bug是找不完的，并不是没有Bug了，而是你暂时没有看到它。
2.定位Bug：
在微软，几乎所有的测试人员都拥有深入调试程序的技能。测试不仅要以最短路径重现问题，还要分析问题的影响范围，甚至给开发人员提出解决方案。这就
要求测试要比开发有更高的设计分析能力、代码调试能力、解决问题的能力。亲，看到这里，你应该对老大为什么安排“Java学习”释然了吧。
定位Bug可以从两个方面来理解：以最短路径重现必发Bug；重现偶发Bug。
要解决Bug，首先开发要重现此Bug。如果测试提交的Bug步骤描述中能给出最短的必发路径，可以明显缩短开发分析和定位问题的时间，实际上也是为测试争取了更多的时间。
对于偶发的Bug，从程序的角度来看，并没有偶发的Bug存在，之所以认为它是偶发，是因为我们未找到必发的绝对路径。重现偶发Bug，是一种耐心与技术的挑战！
3.关闭Bug：
对于测试来说，当然希望提交的每个Bug都能得到解决，但是总会遇到一些Bug，开发会认为“无效”或“推迟修复”。一些测试会找开发理论，被开发说了一通后，只能不情不愿地“关闭”此Bug。这当然不是我们想要的，这里充满着沟通的艺术。
卡耐基说：如果你想赢得人心，首先要让他相信你是最真诚的朋友。呵呵，这个好像有点难，实际一点的，上次参加清照“裸聊”时，清照提到她以前的方法：“放低姿态，多向开发请教些问题，既学习到了知识，还搞好了关系。等你熟悉了系统，又能多发现些bug”。
测试的第二重境界：站在Bug上
让我们回到标题，“测试的价值仅仅是发现Bug吗？”
测试团队是整个项目大家庭中的一员，在软件质量上要尽可能早、尽可能多的发现Bug，这也是软件测试的根本，是质量上能给项目做出贡献的地方。那么在成本和时间上，测试可以做些什么？如何做呢？其实也就是测试如何配合项目成功做正确的事，并正确的做事。
我想对于测试，做正确的事就是站在用户的角度，进行常用功能重点测试，而避免非常用功能的过度测试，浪费成本。正确的做事就是采用合理、全面的测试方法验证软件是否符合用户的需求，不想当然地通过用户根本不可能用到的非法操作或后门进行验证。
测试工作可以在提高关键质量目标的同时，为项目降低成本、减少时间。更快的进度、更低的成本、更高的质量。这样，应该不会被认为“测试的价值仅仅是找Bug”了吧。
测试的第三重境界：挑战零缺陷
一个小故事：有一天，一个村民在河边走，看到有个人在河里快要淹死了，他跳进河里把这个人救了上来。还没等休息，他看到河里还有一个人，于是他一边
喊着，一边又跳进河里救人。河里出现了更多的溺水者，更多的人被喊过来加入救人的行列。在一团混乱中，有个人走开了，沿着河朝上游走去。一个人叫住他问：
“你去哪里？我们需要你的帮助。“，他说到：”我要找出是谁在把这些人扔到河里。“
是谁把Bug扔了进来？我们也需要找出问题的根源，分析提出防范措施。从测试技术的角度出发，一线的测试才能提出更多的、更实际的软件设计质量防控错误。
“零缺陷”是一个体系，不是依赖于某个人某个团队就能做好，需要围绕产品的整个链路中所有团队都参与进来，同时需要有高层领导充当质量的倡导者。比如说清照，也是上次“裸聊“讲的：”有问题要爆出来，如果搞不定，告诉我，我来搞；如果你们都不爆，我怎么搞？“。
终于写完了，这么多东西，很多都是从书上看到的， 如果你问我到什么程度，借用发哥说的“我才刚起步”。亲，一起走吧！
