软件测试工做近两年来的感想和将来规划（一）

想一想从去年2013-3月份实习开始，到如今进入公司参与测试工做实际上已经快两年了，说实话，当初找测试工做的缘由真的很简单（不知道大部分人是否是都这样？）：快毕业了！学过一些编程知识（c,c++等），知道一些数据库的操做，想赶忙找份工做！发现作开发还不行，那就找测试吧！----当时真是这么想的。结果就是大四下学期，几乎住在了广工教六（由于我是汕大的，又想在广州找份工做），花了一个半月的时间，简直浑天暗地，苦攻测试知识（主攻这个），数据库知识，操做系统，编程，数据结构，面试题；边找工做，边看书，那时候招聘会多，赶场赶得厉害，累到爆！面试了不少，被刷掉不少次，最后感受实在坚持不下去了，想回校的时候，终于拿了两份offer，拿到第二份offer的时候，简直高兴的狂奔（是的，当时的状况就是这样的，我在广工体育馆上面狂奔了！），后面就进了第二份offer的公司，开始与测试结缘了！

  关于应届生面试经验，其实很难讲，我以为首先你得具有最起码的你职位所需求的东西，如测试，那就基本的测试理论、测试方法、测试用例设计方法，还有多去作一些面试例子题等，而后，你有一些编程能力，数据库能力，逻辑思惟好，有些算法基础这些就最好不过了（固然你在这些方面很好的话，去作开发吧，哈哈），最后，我想说的是要自信！和有本身的想法或坚持（也能够说是原则吧），关于软测面试的书，本人推荐一本，感受还不错，蔡为东的《软件工程师面试指导》，里面基本的都有讲到。

  下面开始吐槽这两年来（两年工做经历，加班太多，算三年工做经验吧）的工做感想，一进来，正常的业务培训，简单的工做内容，去公司所负责的网点见习，分小组，每周总结啥的，很正常的实习经历；不得不说，实习期间除了钱少（一个月1K！只能用来交房租和吃饭），公司的氛围，人员相处，特别是咱们测试部的人，真的很是nice，让我这个白白嫩嫩的应届生以为，"哇靠!这就是公司啊！跟我想象中的强烈竞争很不同,这公司，不错！",接下来就是回校答辩，回来正式入职！开始真正的工做了。

  正常的工做，这里我能够分三部分来说：

  首先，能够先说下目前咱们的测试流程（我所了解到的，版本负责人应该比我清楚，到时候问下，更新下）：

  开发那边，我知道的就是：需求--需求评审（参加过几回）--设计人员根据需求，设计版本任务--版本负责人分配任务给开发人员--开发人员负责开发、处理bug和一些运维的事

  测试会从需求评审阶段（主要是根据经验，看需求的合理性，需求与产品实现能力，需求会对产品及用户形成的影响）介入--而后根据版本任务内容，进行评审（主要是评审版本内容的测试优先级，并根据测试人员的定位，分配任务，评审任务完成时间，进度安排，人员协调等）--各个测试人员完成本身版本内容的用例编写设计（忙的时候就不写了，唉~）--用例评审（各个测试人员讲下本身的用例，而后其余人给建议，这个其实很重要，有利于测人员了解每一个人的测试用例设计思路，并相应的了解每一个人测试内容涉及到的知识，同时，集思广益，有利于用例的广度和深度，发现更多的bug，但由于赶进度和时间的问题，老是作的不多！）--执行首轮测试，bug的跟踪管理（咱们这边用的是TD）--交叉测试（就是每一个人去测别人的测试项，其实这个有利有弊，很差的是，分到本身彻底不熟的项，还得找首轮测这项的人了解下，而后再从新想测试用例，再测，很花时间；重要的是当首轮测试人员和开发都不在的时候，你能够想象那时候的痛苦！好处就是，不一样人的测试思路，用例，测试方法的不一样，有些bug，你没发现，他发现了，并且影响还挺大！那时候，就是谢天谢地了！其实，这里能够但愿版本负责人能够多考虑下测试组员的定位，让定位类似至少不要差很远且让对彼此测试项都有些了解的人进行交叉，避免沟通带来的大量时间的损失。）--回归测试--版本测试总结，生成测试报告，对版本上载进行评估--版本上载跟进（这个很辛苦，基本上都是通宵熬夜，主要是验证基本主要业务功能和新上载的功能是否能够实现，是否不会报错，是否有其余不可预估的影响等），这就是大概的流程（加吐槽）了。

 

 

  接着是工做内容：

  一、版本测试，到如今为止，我所知道的咱们公司的版本测试就是，了解需求—>了解开发上载的功能（不懂找开发，必要时拉上设计）—>根据需求，功能设计测试用例—>执行测试—>bug的跟踪管理......(后面的都像上面的流程差很少)，版本测试也就是你们所说的黑盒测试，你也能够理解为，根据功能在前台点点点，而后看是否会报错；（说到这，你会不会觉得好简单！--too young!），首先，我得说下，我很佩服那些版本测试作得很好的人！就咱们公司来讲，版本测试涉及面很是广，虽然表面上就一个系统，上载一些功能项而已，但是考验的功力，我只能说，我在这工做近两年了，能达到50%，我都会偷笑了！我以为，任何测试，都必须从本身产品的业务需求出发（我的看法），因此在设计测试用例时，业务的实现就是咱们的出发点，要考虑业务成功是怎样的，失败时怎样的，什么状况下会成功，什么状况下会失败，边界状况怎样,特殊状况等等，固然这只是其中一个业务，当还存在其余业务项有关联时，咱们又要考虑业务间的影响，当你的系统有多个地方用时，你又要考虑，这个地方上这个业务项，别的地方会不会有影响，影响大不大，当有多个业务项一块儿上时，彼此间又该怎么搞?......这就是版本测试须要考虑的地方之一，在我了解的范围内，优秀的版本测试人员首先须要对整个产品的业务功能都有必定的熟悉，即便它不少，而后对不一样点的具体实现结果，影响范围以及特殊业务都要知道，这样才能够尽量的精简本身的用例的同时提升用例的覆盖率；而后还要会对测试项的优先级，严重性进行判断（这须要时间经验的积累），对测试工做进行安排（不少时候你会发现，一大堆任务摆在你面前，根本连写用例的时间都没有，测试的时间也会很吃紧！）