刚毕业那会儿进公司，记得大约有半个月是不在项目里的。先熟悉下部门的业务，看看需求文档，翻翻老员工的用例。经理也在部门例会上找老员工对我们进行指导，讲解他们是怎么写用例的。每周六，公司也找了高级别的测试经理给我们上课，传授一些测试基础知识。就这样，我正式进入了测试启蒙阶段，从做一个小项目开始，慢慢的一个个小项目结束，不断提高，到现在介入中型、大型的项目。
当然前面这些都是公司安排好的，如果没有这样的指导，作为测试新人应该怎么办呢？
首先要熟悉部门业务，了解目前一共有哪些项目，你可能会投入哪个项目，这样就可以有优先级的看需求。看需求一定要仔细，如果看不透彻，很容易漏掉测试点，或者发现不了需求存在的问题。遇到不明白的地方，应及时询问项目中的测试、产品人员，并在需求文档做好批注，另存为自己的批注版；流程不明确的时候，可以借助流程图，让流程更直观、完善；突然想到一个测试点，可以添加到思维导图中，并且检查测试点是否能添加到其他分支模块。当你看完需求后，能给任何人讲清楚需求的整体架构，具体流程，每个细节，那你才算掌握了这个需求，才能从整个业务架构出发，及早发现更多漏洞。
上面说的是有文档的需求，已经有所参考，那么，如何理解还几乎没有文档的新需求呢？这就需要我们不断的思考，一边和产品人员沟通，一边在脑海描绘产品的原型，每个页面，每个按钮，大概的样子和流程，问明白所有测试点的预期结果，并做好记录。如果沟通完成后，你依旧能给任何人讲清楚需求，或者可以回答测试经理提出的所有疑问，就可以认为理解了新需求。等产品做出来，对比下你理解的需求，如果发现有不一致的地方，就是一个待处理的问题了。
非常熟练地把需求转换成测试用例，是个很强的能力，这时候就体现需求理解的价值了。需求掌握地差不多后，就可以练习下设计用例的思想。设计方法有很多，常见的有边界值、等价类、错误推断、探索式测试等等。在需求转换用例时，融入这些用例设计，需要自己不断练习和摸索，也可以寻求带教人的帮助或者查阅相关资料进行提高。用例编写有个值得注意的地方：通常每个公司的用例规范是不同的。虽然用例表达的内容是相同的，但为符合部门习惯，尽可能做到用例编写规范一致。
用例会设计了，就要深一步做测试框架，上文提到的思维导图，就是一个很好的工具。一个项目，总会存在某些固定的测试点，比如和病毒防火墙的冲突性、不同浏览器的兼容性、普通平台的兼容性、版本升级、更新、卸载等等操作。通过思维导图不断完善、归纳，就可以很好的记录测试点，最终形成一个测试框架，可以让任何人来使用，既提高了编写用例的效率，也防止了测试点的遗漏。
测试框架确定了，保证功能测试用例八九不离十，就可以进行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
本文版权归作者、微信公众号光荣之路和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
