软件测试新人如何提升自己？

　　首先要熟悉部门业务，了解目前一共有哪些项目，你可能会投入哪个项目，这样就可以有优先级的看需求。看需求一定要仔细，如果看不透彻，很容易漏掉测试点，或者发现不了需求存在的问题。遇到不明白的地方，应及时询问项目中的测试、产品人员，并在需求文档做好批注，另存为自己的批注版;流程不明确的时候，可以借助流程图，让流程更直观、完善;突然想到一个测试点，可以添加到思维导图中，并且检查测试点是否能添加到其他分支模块。当你看完需求后，能给任何人讲清楚需求的整体架构，具体流程，每个细节，那你才算掌握了这个需求，才能从整个业务架构出发，及早发现更多漏洞。

 　　上面说的是有文档的需求，已经有所参考，那么，如何理解几乎没有文档的新需求呢?这就需要我们不断的思考，一边和产品人员沟通，一边在脑海描绘产品的原型，每个页面，每个按钮，大概的样子和流程，问明白所有测试点的预期结果，并做好记录。如果沟通完成后，你依旧能给任何人讲清楚需求，或者可以回答测试经理提出的所有疑问，就可以认为理解了新需求。等产品做出来，对比下你理解的需求，如果发现有不一致的地方，就是一个待处理的问题了。

　　非常熟练地把需求转换成测试用例，是个很强的能力，这时候就体现出需求理解的价值了。需求掌握地差不多后，就可以练习下设计用例的思想。设计方法有很多，常见的有边界值、等价类、错误推断、探索式测试等等。在需求转换用例时，融入这些用例设计，需要自己不断练习和摸索，也可以寻求带教人的帮助或者查阅相关资料进行提高。用例编写有个值得注意的地方：通常每个公司的用例规范是不同的。虽然用例表达的内容是相同的，但为符合部门习惯，尽可能做到用例编写规范一致。

　　用例会设计了，就要深一步做测试框架，上文提到的思维导图，就是一个很好的工具。一个项目，总会存在某些固定的测试点，比如和病毒防火墙的冲突性、不同浏览器的兼容性、普通平台的兼容性、版本升级、更新、卸载等等操作。通过思维导图不断完善、归纳，就可以很好的记录测试点，最终形成一个测试框架，可以让任何人来使用，既提高了编写用例的效率，也防止了测试点的遗漏。

　　测试框架确定了，保证功能测试用例八九不离十，就可以进行bug预防了。我们进行大量长期的测试后，发现了大约80%的bug，在这个项目中会出现，那个项目中也会出现。我们可以把这些常见的bug总结归类，通过联系开发负责人或者开发总监，推进制定开发规范，防止相似的bug每次都出现。同时我们也可以制定测试规范，把发现这些常见bug的方法，写入测试规范，对常见bug进行双重预防。把这些测试规范加入测试框架中，基本保证常见的bug尽可能少出现，提高整体项目质量，规范了团队的开发能力和测试能力，对个人的技能也有很好的提升。

　　以上内容为大家介绍了软件测试新人如何提升自己，本文由多测师亲自撰写，希望对大家有所帮助。