1.测试初识
　　我们先来看看测试工作做的是什么，首先根据产品需求文档了解整体的逻辑，然后根据需求写明详细的测试用例，
　　后通过各种手段（白盒、灰盒、性能、自动化、黑盒等）去检测，基本上也是产品上线的最后几关。在这过程中，更重要的是发现问题，
　　提交相关实施人员。事实而言，这种流程模式只是最基本的。
　　2.我对测试的理解
　　我觉得正真的测试应该分为三部分：
　　1）根据文档或用例测试软件相关bug，提交给相关人员；
　　2）分析问题产生的原因和趋势，帮助开发者发现当前软件开发中的缺陷；
　　3）会从用户体验的角度去思考产品体现的概念，提出可行性改进意见。
　　第一点主要是最基础性的工作。测试人员首先会根据需求文档文档编写详细的测试用例，在这期间往往会提出一些严谨或极端的用例，如边界值等问题，这些元素有些会在需求文档中说明，有些则没有。虽是细节性的问题，但往往可能因为其中一点而使得软件使用变得很差劲。如果我们从整体角度看待，产品做的会偏重于整块的工作，测试会注重流程和细节反馈问题。因此好的测试环节必然少不了对整块需求的理解。从整个行业来看，至少一半以上的工作量都在于发现软件问题，提交并再次检验，保证软件质量。
　　到了第二点，基本上是一个测试工作的提升环节。我们从一个产品的本质上去思考，为什么会测出各种各样的问题，测试往往是对代码结果检验。只是尽可能地发现错误与问题，毕竟不会存在百分百无漏洞的软件。即便是最专业的测试水准，从大众的不同角度看来，也存在不同的问题。因此从测试中找出问题的成因会更加重要。因为这往往会带动一些开发过程中的效率和质量保证。举个例子，程序开发往往会注重实施的结果，通过不同的方法编写代码，达到产品需求的实现。但从个人意识去判断，很难发现代码自身的问题，很多时候也是因为时间的紧张。因此测试若能分析一些漏洞产生的原因，自然会对整个流程体系把握更加到位，甚至在很大程度上告诉开发者的问题，第二点其实主要依赖于白盒测试。
　　第三点说的是产品结果层，程序开发实现了效果，但到了用户层面可能是另外一种传递概念。除了产品人员需要从用户角度出发，测试往往也会从一线的角度去思考，毕竟测试从整体角度来看称作第一用户也没有错。目前来看，整个测试环境达到这一点的并不是很多，像类似于一些成熟的体系如谷歌等在这一块做的恰到好处。在《谷歌软件测试之道》中，测试工作从最基础的环节到了最高层的环节基本就是用户体验测试层。这也很好理解，测试人员面对开发者是发现代码结果问题，面向用户则是使用问题的记录。软件最终面向的是一线用户，用户所提的问题需要发现对的点去加以改正。因此以用户的角度去看待测试会使得软件测试工作更加顺畅，同时产品也会因为测试的直接进入尽快得到优化反馈。
　　总之，测试工作不仅仅是提出bug，同时也是对开发和产品设计改进的重要一步。
　　3.测试协调
　　测试协调主要是测试工作在产品、设计、研发等不同层面的协调和完成交付样本。与产品工作可看作是前后互补，产品对文档负责，协调各个资源；测试看重开发结果，指出各个环节问题。因此除了专业的规范性外，充分理解各个环节模块也是有必要的。
　　1）现在常常有一种说法，软件测试往往从开发中甚至是开发后才开始介入，这明显是有问题的。从整体上来说，一个产品只要各个环节充分了解才可能到达策划方案的效果，不仅研发、设计如此，测试人员更应该如此去实施。充分了解需求是最基本的工作。从个体角度看，如果测试人员在中期后介入，往往很难明确各个模块的业务线，对于重点测试的模块也较难把握。因此，测试至少在开发前就要介入进来，甚至是需求策划或评审时。
　　2）在产品实施中，测试该怎么样达到完美的状态呢？首先来说，一个产品在开发后的结果拆分就三种：业务逻辑、产品数据、视觉效果，分别对应前端、后端和设计层面。对于前端而言，测试需要判断业务逻辑和功能的准确性，如模块划分，反馈信息是否按照文档中去走。如果存在不合理的地方要立即记录下来。数据则是后台返回的数据，如数组排序、字段是否准确，此时往往通过极限测试发现很多问题，再次进行记录。对于视觉而言，看UI效果图实现效果一致，是否有对需求改动的地点，有误的地方也要记录出来。
　　3）实际的工作也就两条线，一是对需求充分理解后，根据用例对功能、设计、数据等层面整理出存在问题的地方，二是通过测试工具记录相应的问题并进行问题解决后的再次记录。
　　4）把握先记录，再与产品需求对比，而后统一提交各个人员。这样也不会耽误别人的思路，如果遇到问题就提肯定是影响效率的。同时在正式测试期间，不能一开始就陷入细节，如按钮颜色、翻译等问题。一定要保证逻辑和功能的完全再去记录细节。从软件开发而言，做业务处理、模块逻辑关系往往是复杂的，细节问题可以随时改动。
　　4.如何让测试工作做的更加主动
　　可能有很多的同学认为测试工作是一个没有主动产出成果的工作，只能在产品周期中的最后一关中起到作用，那我们该如何来改变这一个被动的局面呢，我画了一个初略的产品测试流程图，我想分为“测试前”，“测试进行中”，“测试结束后”这三部分来规划我们的工作，从而让我们测试工作可以更加的积极主动的来推进整个产品开发运作。
　　1）测试前，其实也就是在需求发布期，我们可以积极的参与到需求讨论会中，以测试的角度来提出对需求的改进建议，其实测试中很多遇到的bug都是需求不合理或描述不清导致，所以我们应该在早期就要把这些潜伏的问题扼杀在摇篮中
　　2）测试进行中，这个时候我们应该及时的更新发布测试状态，确定好bug优先级，有问题积极和相关人员沟通
　　3）测试结束后，其实这个时候我们的测试工作并没有结束，其实在上文的第二部分我已经讲到，这个时候我们要做的工作就是“从用户体验的角度去思考产品体现的概念，提出可行性改进意见”，用户体验型的问题有时候点子虽小，却对产品的改进至关重要！
　　我想从上面三个阶段的切入，不被动，不盲从，才是一个合格的测试部门。

　　5.测试的一些跨界延生
　　前段时间和一位做测试的小同学聊天，可能也是初生牛犊不怕虎吧，那位小同学壮志激昂的就说“我觉得测试这份工作很简单啊，就随便点点就会了啊”，我记得我刚毕业那会儿也犯了和这位小同学一样的毛病，浅尝辄止。任何一个工作，如果你永远只顾着自己的一亩三分地的话，不去深究，不去扩展，那永远都只能做井底之蛙。
　　对于测试工作，我想可以有以下几条发展的路线：
　　1.对测试技术工作本身很感兴趣的，精通“白盒，性能测试，自动化测试，黑盒”中两门以上的，那么你可以往测试技术大牛的路线发展。
　　2.测试工作中，你有积极的去学习了解 产品，开发，运营 的相关知识，精通用户体验，可以经常从产品层及用户的角度去考虑，善于把控整个产品开发节奏，那么你有做产品经理或者项目经理的潜质，自己可以勇敢的去做一些尝试，现实中测试的转做产品经理项目经理不在少数。
　　3.其实第三条路线可以是第二条的提升，如果是希望从事管理岗位的同学，后期可以往测试经理，技术经理的方向发展，当然需要做一些针对性的学习训练。提升自己相应技能水平。
　　总的来说，技多不压身，你了解学习的越多，即使目前用不上，我想总会有用武之地的一天，机会总是留给有准备的人！