——工作流程和基础术语
作为一个刚刚离开校园的小青年，虽然在学校学过少许测试方面的知识，但是真正进入到工作岗位，却发现自己掌握的知识在这个行业里想要入门都还不够，看着忙碌的前辈们再对比清闲的自己，甚至不知道自己的工作到底从何下手。本篇文章我站在一个大菜鸟的角度写给刚到工作岗位一个月以内的小菜鸟们，希望能帮你们解决一下刚入职所遇到的一些疑惑。
刚到工作岗位一开始一般都会看很多文档，这些文档很详细的解答了各种你脑海里的疑惑，然而“详细”并不总是优点，正式因为详细，海量的概念和文字涌入脑海，最后能留下来的也只是寥寥无几。假设文档的内容是100%，前辈们的意识里你至少掌握了70%，然而你最终掌握的概念也许不到50%。当然，这也是因人而异，本人是不太爱看纯文字纯概念的文档，所以从文档中掌握的知识较少。通过后来实践之后，再回来看文档，才逐渐掌握了更多知识。通过自己的掌握，为了给更多和我一样不愿意看海量文档的人提供方便，我把自己掌握的知识浓缩到自己的文字里面，本篇文章先讲工作流程和基础术语两方面。
文档中对于工作流程的介绍其实不少，但是由于都是概念性的文字，以及很多没有接触过的英文缩写，所以即使看几遍也仍然不是很了解。但是了解整个工作流程对于自己对自己现在所做的工作定位很重要。知道自己现在所做的工作是为后面哪些后续工作做准备，在自己之前，前辈们有做过哪些前置准备，找到相应工作的负责人，方便在自己工作过程中遇到问题时联系。同时，对整个工作流程了解以后才能知道自己所做工作在项目中的重要性，来判断遇到的问题是自己解决还是寻求帮助。
测试工作是贯穿整个软件生命周期的，所以从需求评审阶段，测试人员就要开始介入项目了。在需求评审之后修改完善需求之后再评审记录问题到最后定稿，整个过程中的会议都需要测试参加，因为只有亲自参加了会议，能最好的掌握需求，同时对于需求中一些测试难点也可以第一时间提出。
项目启动以后，开发针对需求文档和交互设计文档开始开发程序，此时测试人员同样需要根据这两个文档开始编写测试用例，一个测试人员的智慧和经验最直观的表现就展示在测试用例上，这考验一个人是否能将问题考虑得全面且具体。此时编写的测试用例会在之后开发完成后执行，所以在编写用例时除了考虑覆盖是否全面，还要考虑是否可实现，是否方便实现。
在这个阶段，除了编写测试用例，还有一项工作就是搭建测试环境，这是一项复杂且具有一定难度的工作。搭建测试环境包括有资源申请、防火墙申请和验证、BSP与ESB域名申请、war包初始化等，需要用到的工具和系统有跳板机、RSMS、管控平台等，当然这些工作肯定不止一个人来完成，需要多人配合，同时和开发保持沟通，以及通过邮件让所有关联方了解项目进度。
到这一步基本的准备工作就告一段落了，等待提测的发起，之后便是测试用例的执行，除了测试用例中写到的操作，自己可以进行一些探索性测试，之后还有兼容性、稳定性等，测试同时也与关联方保持联系，及时反馈，修改后及时回归验证，重复这个过程直到达到要求。这些步骤都是在测试环境进行的，到了生产环境后，还需要进行生产验证。
在进行测试的过程中，每天除了和关联方保持联系使其了解项目进度，还需要每天提交测试日报，来通过数据直观的展现项目中的困难以及进行的程度。通过修改以及各种会议沟通，来使结果让各个关联方都满意后，产品就可以发布了。
之前的工作流程描述中，对于一些专业术语的描述我可以使用中文而不是英文缩写，为了便于菜鸟的阅读。然而在真正的开会或者与前辈沟通的时候，时常会听到一些类似于UAT、SIT之类的简称，这些描述在前辈们眼中也许是耳熟能详，然而在一般新人眼中却很少全部理解，菜鸟们往往可以通过百度来得到缩写的含义，但是并不是所有缩写都能那么轻易的搜到，比如ET，众所周知的ET有个外星人的名字，所以你如果直接搜索ET很难得到自己想要的答案；再比如OP，OP也有动漫或电视剧片头曲的意思，这里我给一个小建议，假如你想要知道OP的含义，你可以搜索“QA PM ER OP”这样搜，多输几个专业性的英文缩写，或者直接“测试 ET”，这样可以排除很多无关的答案。下面为例方便菜鸟们理解，节约网上搜索的时间，我尽可能全面地对自己在沟通过程中遇到疑惑的一些术语进行解释。
我到公司接触的第一个英文缩写是MRD，就是我当时读得最多的需求文档，完整的称呼为市场需求文档（Market Requirement Document），另外的还有PRD和BRD，产品需求文档（Product Requirement Document）是MRD在产品功能上的具体化，而商业需求文档（Business Requirement Document）是高层作为决策评估的重要依据。
在测试工作方面有SIT、UAT、ET。通过每个缩写最后一个字母都是T大概就能猜出这个T是test的缩写系统集成测试（System Integration Testing）和用户验收测试（User Acceptance Testing）具有明显的先后顺序，即先SIT后UAT。而探索性测试（Exploratory Testing）则可能发生在任何测试环节中，有点类似于即兴测试（ad hoc testing），ET需要经验的智慧的沉淀，往往能发现一些潜在的危害。
关联人员方面我所接触到的有PM、PMO、UED、RD、QA、FE，OP企业把项目分配给项目经理（Project Management）由他来产出需求以及决策、计划、组织等。项目管理办公室（Project Management Office）是项目的核心干系人，对PM起到支援的作用，也具有决策的职权。用户体验设计（User Experience Design）通过对用户体验的心理感受的研究，从而在产品策划和设计方面发挥重要作用。研发（Research and Development）也就是我们平时口中的开发，负责用代码将需求实现。质量保证（Quality Assurance）就是我们平时说的测试，也正是我现在所做的工作。前端（Front-End）主要担任前端的开发。运维（Operations）主要负责维护服务器正常供应服务。
感觉自己掌握了一定量的能力之后，个人认为有一个很好的方法用来检验自己学习情况，同时进一步提高能力，就是修改优化参与项目时所给你的文档，比如那些操作流程之类的说明文档，即使写得比较详细了，但是新人往往还是会觉得跨跃性比较大，很难懂。而此时的自己正处于新人和熟手之间，站在这样一个中庸的角度来细化文档，不仅有利于自己对这项能力的提升，同时也能检验自己对于之前的学习是否落到实处。
讲到这里，在入职一个月以内所需要了解的就已经讲得差不多了，其实往往阻碍新人的都是一些鸡毛蒜皮的小障碍，然而也同样因为是小事时常被自己所忽略，后果可能导致自己在一条一条的路上都难以前进，希望这篇文章能够帮到更多的新人跨越入职的第一个瓶颈。
