从校门出来就踏入现在的公司，整整一年了。昨天提交了辞呈，感觉自己又迈出了人生的一小步。想想不管怎么说自己还是成长了，当初从校园走出来时只是是一名对软件测试一无所知的待业毕业生，经过一年的努力和挣扎已华丽转变成一名具有一定竞争力的测试工程师。去年的4月11号到GZ找工作，面试时处处碰壁。直到后来遇到现在公司的XK，才让我有一个成长的机会，一直认为他就是我的第一个伯乐。还有差不多一个月的时间，就要现在的一切工作、同事告别，重新启航，在这里也先祝愿自己下一个旅程一切都顺顺利利的。趁着有时间并利用51testing这个平台，敲下一些文字记录下自己这一年来收获的点滴，同时自己也深知在软件测试这个领域上我的目光还是很狭隘，希望看到我这篇感悟的前辈多多指点，先谢谢了。

　　在公司工作一年的时间里主要是负责公司和移动合作的项目，手机杀毒软件。整体测试的过程：开需求讨论会、熟悉需求、编写测试计划、编写测试用列、用列评审、执行测试、回归测试、集成测试、系统测试、客户验收测试，这大概就是我这一年来的工作内容，其中还会会掺杂一些其他的测试进来，比如说：接口测试、服务器的压力测试、病毒查杀测试。

　　（一）关于用例编写的感悟：需求阶段，只拿着一份需求没有UI、产品就进行用例编写，个人感觉就好像是摸着石头过河，暂且只能根据需求依葫芦画瓢，自己也会在心里根据需求描述想像着产品的样子和在操着的过程会出现哪些场景。对于我来说需求阶段用例的编写还是存在一定困难的，因为我们公司的需求基本上比较粗糙的，但这样也不尽是坏事，可以锻炼我们测试人员的沟通能力。在编写用例时发现产品具体实现的细节需求上是没有提或者不合理，这个时候测试人员就要主动和产品人员沟通了，要问清楚他们产品的交互具体怎么实现，同时对于不合理的地方站在用户的角度提出自己的看法。尽早发现问题提出问题可以使我们的产品更完善同时也减少开发人员的工作量还方便自己编写用例。在需求阶段只能根据需求编写用例，可能考虑到场景不是那么全面；刚开始的时候我一直为这个纠结，一直自问：为什么有些测试场景在没有拿到产品前我没有想到呢？但随着工作的深入，发现没必要纠结，因为测试有时候也是需要灵感，同时在进实际测试的时候还可以继续增加和完善用例。在遇到逻辑实现比较复杂的模块如何编写的用列，这个对于很多刚接触测试的新人来说还是有点困难的，后来我发现一个好点子：画好该模块的流程图，同时让开发人员帮自己看下流程图的思路是否和他开发的代码实现的逻辑一致，如果得到了开发人员的认同，那么自己的思路就应该很清晰了。根据做好的流程图参考需求组织文字就可以写出简单明了的用例，同时这样做也可以达到黑盒测试代替白盒测试。这些就是我工作一年来关于用列编写的拙见吧，总之现在的我坚信用例是整个测试过程的基石。但编写用例的整个过程也比较繁琐的，要写好一套完整、高效的测试用例我认为必须要有好的脑子、平静安稳的耐心、善于沟通的嘴巴、联系实际的想象力、不断完善和改进的激情。

　　（二）用例评审这个工作环节个人感觉是对自己帮助最大的环节，因为相关的测试人员、开发人员、项目经理、部门经理等会对自己编写的用例进行一个审评，大家会在会议上点出用例不足或者遗漏的地方，特别是测试人员有某些功能实现逻辑没有理清的就可以和开发人员交流、理顺。但在这个环节作为一名测试人员也一定要虚心虚心再虚心，用接受批评和自我批评的态度来接受大家提出的建议，这样可以让自己突破自己，超越自我。当然在用列评审会之前，可以拿出自己的用列主动请教公司工作经验丰富的前辈，让他们帮忙修正或者提出更好的编写建议，根据他们的建议修改，在评审会上也方便他们更好的指出。在职场上永远把自己当成新人，虚心接受批评，主动学习，一定会不断进步的。

版权声明：本文出自 leihuai2006 的51Testing软件测试博客：http://www.51testing.com/?403264

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。