想想从去年2013-3月份实习开始，到现在进入公司参与测试工作实际上已经快两年了，说实话，当初找测试工作的原因真的很简单（不知道大部分人是不是都这样？）：快毕业了！学过一些编程知识（c,c++等），知道一些数据库的操作，想赶紧找份工作！发现做开发还不行，那就找测试吧！----当时真是这么想的。结果就是大四下学期，几乎住在了广工教六（因为我是汕大的，又想在广州找份工作），花了一个半月的时间，简直浑天暗地，苦攻测试知识（主攻这个），数据库知识，操作系统，编程，数据结构，面试题；边找工作，边看书，那时候招聘会多，赶场赶得厉害，累到爆！面试了很多，被刷掉很多次，最后感觉实在坚持不下去了，想回校的时候，终于拿了两份offer，拿到第二份offer的时候，简直高兴的狂奔（是的，当时的情况就是这样的，我在广工体育馆上面狂奔了！），后面就进了第二份offer的公司，开始与测试结缘了！
关于应届生面试经验，其实很难讲，我觉得首先你得具备最起码的你职位所需求的东西，如测试，那就基本的测试理论、测试方法、测试用例设计方法，还有多去做一些面试例子题等，然后，你有一些编程能力，数据库能力，逻辑思维好，有些算法基础这些就最好不过了（当然你在这些方面很好的话，去做开发吧，哈哈），最后，我想说的是要自信！和有自己的想法或坚持（也可以说是原则吧），关于软测面试的书，本人推荐一本，感觉还不错，蔡为东的《软件工程师面试指导》，里面基本的都有讲到。
下面开始吐槽这两年来（两年工作经历，加班太多，算三年工作经验吧）的工作感想，一进来，正常的业务培训，简单的工作内容，去公司所负责的网点见习，分小组，每周总结啥的，很正常的实习经历；不得不说，实习期间除了钱少（一个月1K！只能用来交房租和吃饭），公司的氛围，人员相处，特别是我们测试部的人，真的非常nice，让我这个白白嫩嫩的应届生觉得，"哇靠!这就是公司啊！跟我想象中的强烈竞争很不一样,这公司，不错！",接下来就是回校答辩，回来正式入职！开始真正的工作了。
正常的工作，这里我可以分三部分来讲：
首先，可以先说下目前我们的测试流程（我所了解到的，版本负责人应该比我清楚，到时候问下，更新下）：
开发那边，我知道的就是：需求--需求评审（参加过几次）--设计人员根据需求，设计版本任务--版本负责人分配任务给开发人员--开发人员负责开发、处理bug和一些运维的事
测试会从需求评审阶段（主要是根据经验，看需求的合理性，需求与产品实现能力，需求会对产品及用户造成的影响）介入--然后根据版本任务内容，进行评审（主要是评审版本内容的测试优先级，并根据测试人员的定位，分配任务，评审任务完成时间，进度安排，人员协调等）--各个测试人员完成自己版本内容的用例编写设计（忙的时候就不写了，唉~）--用例评审（各个测试人员讲下自己的用例，然后其他人给建议，这个其实很重要，有利于测人员了解每个人的测试用例设计思路，并相应的了解每个人测试内容涉及到的知识，同时，集思广益，有利于用例的广度和深度，发现更多的bug，但因为赶进度和时间的问题，总是做的很少！）--执行首轮测试，bug的跟踪管理（我们这边用的是TD）--交叉测试（就是每个人去测别人的测试项，其实这个有利有弊，不好的是，分到自己完全不熟的项，还得找首轮测这项的人了解下，然后再重新想测试用例，再测，很花时间；重要的是当首轮测试人员和开发都不在的时候，你可以想象那时候的痛苦！好处就是，不同人的测试思路，用例，测试方法的不同，有些bug，你没发现，他发现了，而且影响还挺大！那时候，就是谢天谢地了！其实，这里可以希望版本负责人可以多考虑下测试组员的定位，让定位相似至少不要差很远且让对彼此测试项都有些了解的人进行交叉，避免沟通带来的大量时间的损失。）--回归测试--版本测试总结，生成测试报告，对版本上载进行评估--版本上载跟进（这个很辛苦，基本上都是通宵熬夜，主要是验证基本主要业务功能和新上载的功能是否可以实现，是否不会报错，是否有其他不可预估的影响等），这就是大概的流程（加吐槽）了。
接着是工作内容：
1、版本测试，到现在为止，我所知道的我们公司的版本测试就是，了解需求—>了解开发上载的功能（不懂找开发，必要时拉上设计）—>根据需求，功能设计测试用例—>执行测试—>bug的跟踪管理......(后面的都像上面的流程差不多)，版本测试也就是大家所说的黑盒测试，你也可以理解为，根据功能在前台点点点，然后看是否会报错；（说到这，你会不会以为好简单！--too young!），首先，我得说下，我很佩服那些版本测试做得很好的人！就我们公司来说，版本测试涉及面非常广，虽然表面上就一个系统，上载一些功能项而已，可是考验的功力，我只能说，我在这工作近两年了，能达到50%，我都会偷笑了！我觉得，任何测试，都必须从自己产品的业务需求出发（个人见解），所以在设计测试用例时，业务的实现就是我们的出发点，要考虑业务成功是怎样的，失败时怎样的，什么情况下会成功，什么情况下会失败，边界情况怎样,特殊情况等等，当然这只是其中一个业务，当还存在其他业务项有关联时，我们又要考虑业务间的影响，当你的系统有多个地方用时，你又要考虑，这个地方上这个业务项，别的地方会不会有影响，影响大不大，当有多个业务项一起上时，彼此间又该怎么搞?......这就是版本测试需要考虑的地方之一，在我了解的范围内，优秀的版本测试人员首先需要对整个产品的业务功能都有一定的熟悉，即使它很多，然后对不同点的具体实现结果，影响范围以及特殊业务都要知道，这样才可以尽可能的精简自己的用例的同时提高用例的覆盖率；然后还要会对测试项的优先级，严重性进行判断（这需要时间经验的积累），对测试工作进行安排（很多时候你会发现，一大堆任务摆在你面前，根本连写用例的时间都没有，测试的时间也会很吃紧！）