很久没上来了，一直出差。再说比较懒，再加上北方的冷天气，我就更懒得动了。给一直关心我的朋友道个歉，2012了，认真学习，不带遗憾。
出差半年跟了第一个项目，做配置管理，具体的业务不方便说，只是这半年下来，才发现整个测试工作、甚至整个产品进度都围绕一个东西展开--缺陷，也就是我们所说的BUG。
在这里，我也不想阐述什么是，为什么是。国内任何一本测试教程上都会告诉你，这个是设计开发不满足需求的地方。其实做了一段时间测试后，你会得出一个结论：衡量测试人员的实力的测试设计，包括方案设计和用例设计。这句话没错，这是测试人员掌握基本的能力。但是做过项目迭代才知道，用例设计的完整度总是落后于实际的测试执行的，换句话说，不是每轮都有时间给你补用例或者完善的。测试执行也很能体现你测试的功底。
记得项目紧急的时候，一般都是直接甩给你一个安装包，自己安装环境，测试一下，告诉我结果，那些地方存在缺陷。测试完成后版本评审，各大“主席”汇聚一堂，作为测试人员的你怎么让各方神圣认同你的观点？空口说净是扯，要有问题单记录吧！所以各位测试同仁们，我们发现的缺陷不能只告诉开发，哎呀这儿有个问题，这个设计不对，这儿数组越界了。每一个缺陷都被记录，才能提供给最终的决策者，这个版本的质量到底怎么样，能不能发布，是否还需要进一步迭代？如果你没有这些管理工具，一是测试结果得不到体现，二也没办法分析，这个系统最好是一套成熟的系统，支持搜索等功能。
项目要发布的时候，无论是版本经理还是开发leader还是测试经理，都是会去库中搜索还有多少缺陷遗留，只有这样才能确定版本是否能够正常发布，测试经理也可以根据此结果和相关人员交流以保证产品质量，更好的给版本质量提供保证。测试完成测试经理会问具体的测试人员，这轮测试怎么样，发现了多少个问题，严重等级怎么样，这样版本经理询问的时候，大家都是根据你提供的数据来判断产品的质量怎么样的。
既然问题单如此重要，那我们该如何提高我们的效率？在恒定的测试时间内发现更多的缺陷？个人的一点小经验，给大伙分享。
（1）、通过设计能够发现的：熟读需求，记得每个点的具体情况，每个点都覆盖，设计完成后对比，尽量不做到遗漏，此处可以参考测试设计部分的要求。对于每轮都需要冒烟的，又不经常变的，可以考虑自动化，使用脚本帮你验证。
（2）、多看，可以像老鼠一样，各处巡逻，查看别人是怎么提单的，都出现在什么地方？我怎么就没发现？尤其应该关注和自己执行相同的用例的同事，这样的横向对比最好使。
（3）、多总结，多沟通，有些问题就是在沟通中出现的。所以很好的口才和习惯可以让你事半功倍。总结总结，下次我碰到上次遗漏的地方我就不会再遗漏了。
所以我记得有个牛人说他们招人不招技术最牛的，只招聊的来的。共勉共勉！
