很久没上来了,一直出差。再说比较懒,再加上北方的冷天气,我更懒得动了。给一直关心我的朋友道个歉,2012了,认真学习,不带遗憾。

  出差半年跟了第一个项目,做配置管理,具体的业务不方便说,只是这半年下来,才发现整个测试工作、甚至整个产品进度都围绕一个东西展开--缺陷,也是我们所说的BUG。

  在这里,我也不想阐述什么是,为什么是。国内任何一本测试教程上都会告诉你,这个是设计开发不满足需求的地方。其实做了一段时间测试后,你会得出一个结论:衡量测试人员的实力的测试设计,包括方案设计和用例设计。这句话没错,这是测试人员掌握基本的能力。但是做过项目迭代才知道,用例设计的完整度总是落后于实际的测试执行的,换句话说,不是每轮都有时间给你补用例或者完善的。测试执行也很能体现你测试的功底。

  记得项目紧急的时候,一般都是直接甩给你一个安装包,自己安装环境,测试一下,告诉我结果,那些地方存在缺陷。测试完成后版本评审,各大“主席”汇聚一堂,作为测试人员的你怎么让各方神圣认同你的观点?空口说净是扯,要有问题单记录吧!所以各位测试同仁们,我们发现的缺陷不能只告诉开发,哎呀这儿有个问题,这个设计不对,这儿数组越界了。每一个缺陷都被记录,才能提供给终的决策者,这个版本的质量到底怎么样,能不能发布,是否还需要进一步迭代?如果你没有这些管理工具,一是测试结果得不到体现,二也没办法分析,这个系统好是一套成熟的系统,支持搜索等功能。

  项目要发布的时候,无论是版本经理还是开发leader还是测试经理,都是会去库中搜索还有多少缺陷遗留,只有这样才能确定版本是否能够正常发布,测试经理也可以根据此结果和相关人员交流以保证产品质量,更好的给版本质量提供保证。测试完成测试经理会问具体的测试人员,这轮测试怎么样,发现了多少个问题,严重等级怎么样,这样版本经理询问的时候,大家都是根据你提供的数据来判断产品的质量怎么样的。

  既然问题单如此重要,那我们该如何提高我们的效率?在恒定的测试时间内发现更多的缺陷?个人的一点小经验,给大伙分享。

  (1)通过设计能够发现的:熟读需求,记得每个点的具体情况,每个点都覆盖,设计完成后对比,尽量不做到遗漏,此处可以参考测试设计部分的要求。对于每轮都需要冒烟的,又不经常变的,可以考虑自动化,使用脚本帮你验证。

  (2)多看,可以像老鼠一样,各处巡逻,查看别人是怎么提单的,都出现在什么地方?我怎么没发现?尤其应该关注和自己执行相同的用例的同事,这样的横向对比好使。

  (3)多总结,多沟通,有些问题是在沟通中出现的。所以很好的口才和习惯可以让你事半功倍。总结总结,下次我碰到上次遗漏的地方我不会再遗漏了。

  所以我记得有个牛人说他们招人不招技术牛的,只招聊的来的。共勉共勉!