从事软件测试工作已经半年多了，刚入职的时候还是一个缺乏实际经验的小白，而现在拿到需求之后也能比较快速地熟悉业务并顺利开展测试，虽然不能说掌握了很多技能，但是相比之前也是有不少收获的，在这个过程中我总结了一点自己的心得，主要是觉得自己刚入行时做得不够好的一些方面吧。
在工作中要学会主动
记得我刚来的时候，对一切都不太熟悉，尤其是测试的系统，这个时候师傅会让我自己去熟悉。
在操作系统的过程中会遇到不理解的地方，当时因为刚来比较害羞，不太敢去问师傅，结果等师傅第二天问我系统熟悉得怎么样的时候，我说有地方不太懂，师傅说：“你怎么不当时直接问我呢？下次有问题记得要主动问我哦。工作中大家其实都很忙，人家也没有主动去教你的义务，遇到问题不主动问，最后害的只是你自己。”
从那以后，我也就慢慢尝试主动去问问题了，事实证明，当你把自己的问题说出来的时候并不困难，不要觉得不好意思，脸皮厚一些，多向别人讨教，这就是一个学习的过程，既能展示自己的思辨能力，也能学习到同事的优秀经验，何乐而不为呢？
当然，主动提问是好事，但是也不能一遇到问题就去问别人，我们要尽可能先自己去思考问题，然后带着自己的理解和疑惑去请教，这样会使得沟通问题更有效率，别人也会更愿意与你交谈。
学会自我总结
在平常的测试过程中，会接触到不同的平台或系统，它们并不是完全不同的，在设计测试策略、书写测试用例、执行测试用例等方面其实都是可以总结出一套共性的点或者说规律的，总结了这些规律可以帮助我们在后续的工作中快速熟悉业务，提高测试效率等。
除了共性的点，也会遇到一些特殊情况，比如之前在测试过程中发现了一个漏测的问题，这个测试点很容易被忽略，通过总结之后我会加深印象，后续测试过程中也会特别注意，避免在今后类似的场景中遗漏。
工作中还可能有一些从师傅或者同事那里学习的经验，我们也要学会自多多思考，最好是能形成一套思维体系，最终为自己所用，而不是被动去接受，毕竟自己大脑里的知识是别人偷不走的。
学会高效沟通
从事测试这个工作，我发现有相当部分的时间花在了沟通上面：
比如需求不明确的时候，得找产品沟通；
提的缺陷开发可能不接受，得和开发沟通；
测试进度上有问题，得和项目沟通。
这些沟通会占用我们不少的时间，但是测试的时间是有限的，沟通花费的时间过多意味着测试时间会减少，最坏的情况就是测试时间不足导致项目交付进度延缓或者说仓促上线导致一些线上问题的产生，这个对于测试的口碑和整个项目的用户体验是很不利的。
既然沟通是必不可少的环节，而时间又有限，那我们只能从提高沟通效率去入手。比如：
01
在沟通问题之前，我们可以自己先梳理一下，可以把能想到的各种可能性列举出来，在描述的时候尽量精简，必要的时候辅以截图、表格、流程图等方便大家去理解问题。
02
如果问题涉及到的相关人员不止一个，可以考虑拉一个群或者小会，召集大家一起当面说明问题，这比一个个单独沟通要有效率得多。
在实际的工作中，沟通是一件非常重要的事情，沟通能力也是保证同事之间高效协同工作的关键。
沟通能力不是与生俱来的，需要我们在平时工作中去学习和改进，当你看到别人沟通事情毫不费力的时候，不妨去请教一下。
学会记录留档
学会记录留档，适当保护自己。第三点中我讲到工作中的大部分时间是在沟通，其实除了沟通，还有需求评审、用例评审等会议，假如说今天花了1个小时开会，1个小时与各方沟通问题，那这两个小时的工作成果如何体现呢？如何确保大家最终的理解是转移至的呢？
其实不论是会议讨论的内容还是自己私下沟通的结果，我们都要把沟通确认的内容及时、完整、正确的记录下来。
特别是那些容易有歧义的地方：
重要的内容建议用文档形式记录
次要的沟通内容保留聊天记录、截图等
必要的时候可以把沟通内容再次同步确认
这样可以确保大家最终理解与接收的信息是一致的，如果后期遇到推诿扯皮的情况，也可以进行追溯，可以减少一些不必要的麻烦。
比如需求评审的时候，对于开发某个功能大家讨论了A、B、C三种方案，最终定下来用方案A去实现。结果提测的时候开发说是按照方案C去实现的，并且事先没有与产品经理、测试同步，方案C进行测试耗费的时间会比A多一倍，这很明显是开发不遵守需求评审的结果导致的，如果碰到开发不认账的时候可以拿出当时的会议记录佐证，开发也就无话可说了。
这样做的目的不是为了让我们逃避责任，而是适当的保护自己。测试该担的责任要勇于承担，但是不由测试导致的问题也不应该当冤大头去承受。
以上是个人入职半年以来的一些心得体会，希望对初入职场的同学们有所帮助，谢谢！
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
