引言
在学校的时候，更多的是学习理论知识，停留在纸上谈兵，没什么机会接触到大项目。而在公司，作为一个实习生的时候，学习与实操并重，学习是为了更好的应用到实际工作中，而在工作中又会加深对知识的理解，二者相辅相成。
那么，从一个在校生，到成为一个实习生：
身份转变之间，要如何适应新环境？
作为qa新人，如何快速上手测试新需求？
如何培养测试思维？
下面是我对实习过程中的一点经验总结与分享，希望能给大家带来帮助。
1. 如何熟悉环境
刚入职的时候，面对陌生的环境、陌生的同事以及未知的工作内容，感觉不适应是很正常的。为了跳出这种不适应，要做的第一件事就是积极地融入环境。
我的建议是：
①多逛一逛公司园区，对园区环境以及办公环境熟悉：
比如说餐厅、快递柜、健身房、大门小门的位置；
比如饮水机、电梯、厕所的位置；
②如果可以的话，多和同事交流、约饭：
多和同事交流有利于快速熟悉工作环境和工作内容； 有聊得来的人、结伴的人，这样就不会轻易感到孤单啦；
③多参加活动：
比如我们公司经常会组织各种活动，比如烹饪课，公司产品内测活动； 还有不定时福利：10元理发、线下特卖会；
④关注公司大群，公众号-行政福狸和网易邮箱大师：
行政福狸上可以看今日菜单、班车、俱乐部等等； 公司大群、网易邮箱大师经常会收到活动安排、假期安排的通知；
虽然这些都是工作以外的事情，但是如果说对公司熟悉度高，对一些活动的参与度高，对公司的归属感也会逐渐提升，幸福感UP。
2. 积极交流沟通
在遇到不懂的工具、平台或者流程时，一定要主动去和导师或者同事沟通、沟通、再沟通！要知道主动才是变革的催化剂，这是非常重要的一步，因为初来乍到的我们最缺的就是经验，只要知道了怎么去做，我们就可以开始积累属于自己的经验啦。
可能在学校的时候，遇到了困难，我们比较倾向于自己解决问题，抱着问题一直死磕下去。但是作为一个实习生，效率是很重要的，不必要的时间浪费有可能会对项目进度带来影响。所以，大胆的去提问吧！提问之前，自己先想办法解决，要有自己的思考和尝试。注意提问时，问题描述要尽可能的简洁+清晰+完整。
对于qa来说，在介入需求的时候，需要跟产品、开发一起合作。在工作过程中，我们并不是独立的，我们是一个团队，朝着一个目标去奋斗，所以积极交流沟通是非常必要以及重要的。
另外，在交流沟通时，如果遇到了让自己情绪不好的情况，要注意先处理心情、再处理事情，因为心情不好会影响到你对事物的判断性。如果自己处理不好，就及时找导师沟通。因为作为一个新人，没有什么经验，遇到自己处理不好的情况，去请教更有经验的导师，最不容易出错。
3. 如何快速上手新需求
如果我们对业务不够熟悉，不仅会导致测试进度慢，还容易遗漏场景，用例覆盖不全，可能验完还存在大量bug。所以我们首先要做的，就是熟悉业务场景。
我一开始熟悉业务的时候，在大量的业务文档中进行阅读，看完了就忘了不说，还很难一下子找到自己想要的东西。光看真的很难在脑海里建立起联系，建议边看边梳理，或者边看边走流程，自己画一下流程图、关系图之类的。
还有，由于新人对于接触的业务没有一个整体的框架的概念，应该优先去看或者先去梳理能建立起框架的资料，比如需求相关的产品策划或者交互稿。策划和交互稿是产品前辈们梳理出来的精华，是对于某个需求的核心内容，同时一般也会有图形界面、流程图、逻辑图等等。在脑海里有了一个大致的框架之后，再看文档进行补充，参考文档走一遍流程，就能比较熟悉了。
其实在介入了几个需求之后，能很明显的感觉到自己的成长了。以前遇到报错直接丢给开发，现在遇到报错学会了先看日志，排查下问题。
4. 关于测试规范的感悟
无规矩不成方圆，无规范难以协同。测试规范的确定是为了让测试与开发、产品更好的合作，降低沟通成本，提高效率，以实现高质量的需求。
这里对于测试规范不再赘述，结合开发流程谈谈感悟。
开发流程：
一点感悟：
①在梳理用例的时候，不明确的点，一定要跟产品确认好，推动产品补充到交互稿上，在群里同步，避免出现测试开发理解不一致的情况。
②冒烟提测之前，一定要让开发和产品都确认过终版冒烟用例，避免冒烟失败后的扯皮；
③测试执行过程中的bug必须新建jira，不要只有口头沟通；
④有风险的项目，要发送测试进度报告；
⑤线上bug优先级高，需要积极响应，第一时间拉群与产品开发确认；
⑥质量即需求。质量也是需求，只不过是隐式的需求。将质量视为需求，而不是开发的辅助，能更好的提升我们的使命感责任感，从而将质量这个需求更好的设计和实现。
5. 知识沉淀与分享
之前在校的时候，我经常会刷算法题，然后把自己的解题思路都写在博客上，感觉每次写博客都是一次对知识的复盘，思路往往也会更加清晰，对算法的理解也会加深。但是在工作中，当导师鼓励我去分享的时候，我觉得我作为一个新人，我懂的大家都懂，应该没什么好分享的吧？分享了会不会对大家没有帮助呀？
现在我懂了，正是因为我是新人，所以我有更多可以分享的东西。比如我现在写的这篇文章，正是因为我是新人，所以我能为更多的新人带来能感同身受、可参考性高的东西。
其实在平时的工作中，如果我们把遇到的一些问题记录下来，那么这个文档就是可复用的、可参考的，可以拿来做分享，看看大家有没有相似的问题，一起讨论一起解决。有的时候你的问题，可能已经被别人解决了，那么通过分享，你也可以解决你的问题，这就是分享的魅力，一起进步。
6. 小结
6.1 收获与成长
在严选供应链这边实习了快四个月，感觉还是在实践和踩坑中成长的最快。
首先是对于业务的熟悉度提高了很多。
商品从提出到上架的流程，我都去大致走过一遍了，对于介入过相关需求的业务，我也做了梳理总结，产出了两个文档。
其次，是我在测试过程中的收获。
从一开始的优化小需求，到接手了一个新功能，再到跨系统的联调大需求，随着我的测试经验的积累，编写用例也越来越得心应手。在这个过程中，我慢慢地总结出了编写用例的要点：
case要描述完整：写清楚前置条件、执行步骤和预期结果；
case要比较全面：不拘泥于格式，只要用例覆盖完整、描述清楚就行。
在测试过程中，我学会了用F12开发者工具抓包，用mobaxterm查日志、查询和修改数据库表，还有一些工具平台的使用，并且实现了一些自动化。
6.2 反思与改进
1、用例场景覆盖不全
在测试优化需求的时候，对于后续的操作带来的影响没有考虑到，结果出现了一个线上bug；
反思：需求的联动影响面评估不足，应该要关注对新功能有影响的场景。
2、过分追求一条数据的用例覆盖度
在测试一个新功能的时候，为了一次性构造适用所有用例的数据，花了好多时间，结果最后不仅数据没构造好，还把自己搞懵了，非常低效的一次尝试。
反思：对于这种需要构造大量数据的验证，最好分开来构造，免得遗漏或者重复验证，验证过了的可以打上标记，这样比较清晰且不容易混淆。
3、自动化用例编写
反思：对于自动化用例的编写，我还有很多不足之处。比如数据复原、数据清洗，我一开始都没考虑到。鉴于经验比较少，我应该先去参考他人的自动化用例，看看别人都是怎么写的，然后不懂的地方去请教导师和同事，多去尝试，争取写出稳定的可复用的自动化用例。
作者简介
又到了作者简介的时间，这次小编想换种特别的想法，先让大家一睹作者的风采
大家是不是在感叹，原来才华和美貌是可以集于一身的，想跟这么优秀的妹子共事吗？戳下面原文链接加入我们吧！
