Flyleaves

导航

测试新人如何提高自己

  刚毕业那会儿进公司,记得大约有半个月是不在项目里的。先熟悉下部门的业务,看看需求文档,翻翻老员工的用例。经理也在部门例会上找老员工对我们进行指导,讲解他们是怎么写用例的。每周六,公司也找了高级别的测试经理给我们上课,传授一些测试基础知识。就这样,我正式进入了测试启蒙阶段,从做一个小项目开始,慢慢的一个个小项目结束,不断提高,到现在介入中型、大型的项目。
  当然前面这些都是公司安排好的,如果没有这样的指导,作为测试新人应该怎么办呢?
  首先要熟悉部门业务,了解目前一共有哪些项目,你可能会投入哪个项目,这样就可以有优先级的看需求。看需求一定要仔细,如果看不透彻,很容易漏掉测试点,或者发现不了需求存在的问题。遇到不明白的地方,应及时询问项目中的测试、产品人员,并在需求文档做好批注,另存为自己的批注版;流程不明确的时候,可以借助流程图,让流程更直观、完善;突然想到一个测试点,可以添加到思维导图中,并且检查测试点是否能添加到其他分支模块。当你看完需求后,能给任何人讲清楚需求的整体架构,具体流程,每个细节,那你才算掌握了这个需求,才能从整个业务架构出发,及早发现更多漏洞。
  上面说的是有文档的需求,已经有所参考,那么,如何理解还几乎没有文档的新需求呢?这就需要我们不断的思考,一边和产品人员沟通,一边在脑海描绘产品的原型,每个页面,每个按钮,大概的样子和流程,问明白所有测试点的预期结果,并做好记录。如果沟通完成后,你依旧能给任何人讲清楚需求,或者可以回答测试经理提出的所有疑问,就可以认为理解了新需求。等产品做出来,对比下你理解的需求,如果发现有不一致的地方,就是一个待处理的问题了。
  非常熟练地把需求转换成测试用例,是个很强的能力,这时候就体现需求理解的价值了。需求掌握地差不多后,就可以练习下设计用例的思想。设计方法有很多,常见的有边界值、等价类、错误推断、探索式测试等等。在需求转换用例时,融入这些用例设计,需要自己不断练习和摸索,也可以寻求带教人的帮助或者查阅相关资料进行提高。用例编写有个值得注意的地方:通常每个公司的用例规范是不同的。虽然用例表达的内容是相同的,但为符合部门习惯,尽可能做到用例编写规范一致。
  用例会设计了,就要深一步做测试框架,上文提到的思维导图,就是一个很好的工具。一个项目,总会存在某些固定的测试点,比如和病毒防火墙的冲突性、不同浏览器的兼容性、普通平台的兼容性、版本升级、更新、卸载等等操作。通过思维导图不断完善、归纳,就可以很好的记录测试点,最终形成一个测试框架,可以让任何人来使用,既提高了编写用例的效率,也防止了测试点的遗漏。
  测试框架确定了,保证功能测试用例八九不离十,就可以进行bug预防了。我们进行大量长期的测试后,发现了大约80%的bug,在这个项目中会出现,那个项目中也会出现。我们可以把这些常见的bug总结归类,通过联系开发负责人或者开发总监,推进制定开发规范,防止相似的bug每次都出现。同时我们也可以制定测试规范,把发现这些常见bug的方法,写入测试规范,对常见bug进行双重预防。把这些测试规范加入测试框架中,基本保证常见的bug尽可能少出现,提高整体项目质量,规范了团队的开发能力和测试能力,对个人的技能也有很好的提升。
  测试中难免遇到项目紧急上线或紧急需求变更,这时候就要用到探索式测试,在没有时间写用例,没有时间与更多的人评审和沟通的情况下,只能根据经验和探索式测试技巧,快速生成测试策略,合理保证项目成功上线。想了解探索式测试的方法,可以参考吴老《功能测试三剑客》视频,专门讲解了:功能测试框架、bug预防和探索式测试(关注微信公众号GloryRoadTrain,回复数字1,即可查看所有视频)。
  如果新手已经把功能测试三剑客做的很好,就可以从手工测试转向自动化测试、性能测试的学习了。当然这个不在测试新人的学习范畴,对新人来说,打好基础,比什么都重要!

                                                                                                                                 记光荣之路吴老3月11日早晨分享

作者:Flyleaves
出处:http://www.cnblogs.com/Flyleaves/
参考声源:http://m.ximalaya.com/zhubo/44966139
本文版权归作者、微信公众号光荣之路和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

posted on 2016-03-12 15:00  Flyleaves  阅读(1176)  评论(0编辑  收藏  举报