题外话
最近有点心浮气躁，在几个群里发过牢骚，有过埋怨，有过稚嫩，有过冲动，也砸了一个键盘，一个人晚上散过心，呵呵倒是让不少朋友见笑了，仔细想想也许是一种蜕变，觉得自己还是很幼稚，不够成熟，总是想留住年轻，不想这么快老掉，所以无时无刻的都在表现自己，仿佛向所有人说，我还小一样，呵呵。
难得静下来，整理下思路写下这篇博文实属不易，困境从不缺少，能走出困境的人，必有其过人之处，如果能将困境变为利境的人，必有其独特的见解，或者是人生观，或者是生活观，或者是价值观，总有和人不一样的观念。
古人云：达者，一日三省吾身。我不是什么达者，但却能做到三日一省吾身，三日不能醒悟，四日或许就能恍然大悟，四日不能，五日也许就醍醐灌顶了，呵呵。非常感谢侯老师的提醒，也很感谢很多群友，同行的开导，若非如此，也许我还在泥足深陷。
原本计划写两篇博文，一为用专业的眼光看待自己的工作，一为我个人的困境，既然现在困境有转变的趋势，不如一起写了下来，作为新人之路系列博文的第五篇博文吧，我相信我的生活和工作都很普通，自然我所遇见的事情，会有很多人也会遇见，这也算是我将自己的一些心得共享吧，别人的始终是别人的，不要试图完全照搬我的心得，只有自己的才是最好的，吸取百家所长，总结出自己的经验，写出自己的心得，那时才是提高了，一味的模仿永远不能超越。
正文
最近的工作其实挺忙的，工作确实是测试，但是却没有用到测试上的技术，不管是工具，还是用例都没有用到，只是测试，很多人都是如此，测试，只是测试。
其实测试不只是测试。
大家都知道测试的两个发展方向，一为管理，一为技术，如果你发现你所在的测试工作没有技术的影子，那你是否尝试过从管理的角度来理解呢？
昨日将手上的一个项目从头到尾测了一遍，整整8个小时，没有测完，但确实很累，不断的针对同一个功能点的不同可能性，晚上到家心里疲惫不堪，一点点不顺心就大发脾气，把一个外接键盘砸得稀烂还不解气，又做了几个俯卧撑，力气发泄出去了，头脑慢慢冷静了，决定出去散散心，专往人少的地方走，环境安静下来了，心也静了下来，开始试着分析自己这段时间的情况，那是相当糟糕。
问题一，为什么如此急躁，怎么能不急躁
太过急躁，因为一些事情，我对自己的要求很严格，对自己的职业规划也很严格，有个很明确的目标，最多5年达到什么什么程度，最好3年达到什么程度，仔细想一想其实，真的太急躁了。
针对这个问题，我告诉自己，“现在要做的，只是学习和积累，学习什么，学习技术，理论上的知识只能通过自己体会，学是学不来的，并且相对于理论，我的技术已经跟不上理论的成长脚步了，为了让技术和理论平衡，所以应该学习技术，积累工作的经验，工作的每一分每一秒都是一种经验，如何安排工作的空闲时间，如何安排工作，不至于工作量分布不均匀一会强度很大一会强度很小，在和开发人员对Bug进行定位时也可以吸收相关经验，比如，在界面删除一个数据，但是数据库中这条数据还存在，这时就可以根据经验来判断有可能该功能是虚拟删除不是物理删除，可以说每一个BUG都是一份经验，区别只是你看见没有，想到没有。”如此想来，其实我要学的要做得还有很多，远远不是自己所想的没有可以学的了，自己很厉害了，呵呵现在觉得这种想法很幼稚，学无止境啊，何况自己还是个初出茅庐的菜鸟呢。
测试行业所需要学习的东西实在太多太多，如何选择学什么，单从工作角度来讲，目前我工作的内容是WEB测试，工作的内容是功能黑盒测试，并且，接触不到数据库，这时，很明确了，我在前面的一篇博文中提及过，要向自动化提高，加之对QTP有一定的了解，但是不够，那么很自然的选择了QTP，不怕大家笑话，我只会QTP，但不会用QTP测试，好了，这是我的一个学习方向了。
第一个问题解决了，心也静下来了，对以后至少2，3个月的日子不会再这般迷茫了，为什么是2，3个月？呵呵因为我自信啊，我认为2，3个月我能够学会用QTP测试，当然不是精通。。。。第二个问题来了。
第二个问题，工作这么段时间，自己有没有得到提高
相信也是大家闲暇时常常想起的，测试到底有木有前途，看看人家开发的工作，都是技术上的，项目完了人家的代码能力实实在在提高了，技术水平实实在在掌握了，再看看自己，这个项目完了，自己了解的业务就都没用了，虽然不是什么都没学到，但是和开发一笔却觉得自己学的太少，因为测试的基础是业务，是需求，一个项目完了也就意味着你了解的业务没用了，你了解的需求没用了，即使你说再做相同的业务能够容易上手，但假若业务跨度很大呢，这个项目是做管理的，下个项目是做商务的，对比看看现下的招聘内容，熟悉各种自动化工具，熟悉各种数据库，熟悉各种语言，各种各样的优先考虑，再来看看自己花了很多时间很多心力做完了一个项目，即使做得很好，你也会觉得自己还是没有多大的提高，还是不能去应聘薪资高点的工作，你们有这种感觉吗？
其实相对于开发人员显性能力的提高，测试人员的提高很多是隐性的，单从技术的角度来讲，测试员是拍马也赶不上开发人员的进步的，这很容易理解，你的测试脚本如果比你的项目脚本还多的话。。呵呵呵可能吗？
我来谈谈测试人员的隐性提高吧，在我们的测试过程中，即使是再枯燥的测试，也有可以学到的技术，这一点在昨日对整个系统做测试时，感触很深。
其一，严谨性
就一般的测试而言，往往只是判断功能是否能够正常实现，但慢慢的你在工作中会发现有些缺陷，是分角色的，相同的功能，管理员是正确的，普通用户是错误的，单独点击是正确的，执行了一个前提操作，再次点击就是错误的，在工作中，随着这样的BUG的积累，你在测试的时候就会有意思的更严谨的去思考，哪怕即使是一个发布和编辑的功能，你都会考虑到除了单独的测发布，编辑这两条用例，还有发布后编辑和编辑后发布这样的2条用例，你的测试工作将更加严谨。
其二，计划性
在工作中，尤其是一个人负责一个项目的新人朋友，我相信没有人指导的你们，很迷惑，对自己的工作没有办法做一个评估，对自己的工作量没有办法进行安排，工作闲得时候埋怨没事做，工作大得时候埋怨太累，其实工作量是可以自我控制的，这个控制是相对的，即时是工作量很大的时候，你也应该先在自己的心里构建一个流程，画上一幅画，将这个系统的布局，功能点的分布都在心里过一遍，再开始有计划的测试，哪些功能模块是关联起来的，哪些功能是独立的，对于这个的掌握尤为重要，假若工作量为100.有效率的进行测试你的工作量就只有100，如果经验丰富的话，比如你能够确定某个表单是相同的，这里不会出现的错误，另一个地方绝对不会出现，因为都是用得同一张表单，那么你的实际工作量可能只有80，而如果你不能进行判断，并且你甚至在开始测试前对整个系统都不在心里或纸上大致的分析下，那你的工作量很有可能是200，比如你在测试添加的时候，没有测试到删除，那么你测试删除的时候就会再走一次添加，这就是无意义的工作量。所以计划性很重要，并且只能在你工作中学习到。
其三，预见性和可分析性
这一点，有点不好讲，还是举个列子吧，测试同样的一个功能模块，测试员甲使用了10条测试数据，测试员乙使用了1条测试数据，都达到了相同的覆盖率和测试效果，那么这里就可以看出测试员乙的测试数据更具备针对性，也就是测试员乙在测试时更具备预见性，相同的一个功能页面，两个输入框，一个输入框要求数字，一个输入框要求字母，甲在测试第一个输入框时考虑几个方面但在对待第二个输入框时只为了快速操作随手输入了几个字母，这种情况经常发生吧，对吗？而乙在测试时，数据是关联的，即考虑了甲的输入限定也考虑了第二个输入框的限制，也就是乙的一组用例对应了2个输入框，这种做法无疑让你的每一份工作都有了应有的效益，也减少了你过多的工作量，这里实质上就是一个预见性和可分析性的工作经验，乙在看见该功能模块后，能够预见各个功能模块的关联操作，并记录好自己使用的测试数据，如果该测试数据到中途走不通了，就分析数据，寻找原因，这里就是一个针对性的测试，而甲所做得就是广散网，缺少了针对性，自然，工作起来就很枯燥了，乙就不一样，他的每一分工作时间都是在思考中的，每一个步骤，每一个操作都是有目的的有意义的。随着我们工作的时间积累，这一点会越来越明显，比如一个10年测试经验的人绝对不会再去对一个输入框做一系列的等价类边界值划分，他们只需要输入几个特殊的数据，就可以实现很好的覆盖，对于一个有经验的测试员，他所使用的每一个数据不说百分之百都有价值，但百分之八十都有可分析性，让开发人员能够从这些数据中快速定位Bug，这份能力减少的不仅仅是测试员的工作量也减少了开发人员的工作量。
其四，判断力
作为测试员在判断是否是Bug的时候是需要具备一定的判断力的，最低要求能够判断这是不是缺陷，之前的博文中提及过，现在的很多开发人员已经在进行自测了，也就是单独对功能点进行测试的时代正在蜕变，在我们寻找Bug的时候已经不能局限于点击按钮是否报错，而应该从更深层次去定义缺陷，这里就需要足够的判断力，虽然我们常常说测试要从文档开始进行，文档测试通过后再来开发，但实际中很多时候测试人员的介入已经是在项目中期或者晚期，这个时候项目都快要完成了你再测试文档也没有多少用了，这个时候你就要根据实际情况考虑功能的合理性，也就是将文档测试上得技巧运用在实际测试中，假如你判断某个地方在设计的时候是有问题的，你就应该提出来，而不是他不报错就可以了，比如一个页面有两个查看的功能一个名为查阅，一个名为查看，实现的功能和方式完全一样，这个时候你可以很直接的要求只保留一个查看功能，这是对设计上的缺陷要有足够的判断力。另外在判断缺陷严重程度和优先级也会在我们工作的过程中逐渐提高，刚接触测试的时候，也许你认为只要是Bug都是万恶的，都应该立即改掉，接触一段时间后，你开始意识到有些Bug是可以滞后修改的，有些bug是可以允许的，熟练后你甚至会认为有些明显是缺陷的地方是不需要管得，最直接的列子对于注册用户名和密码，新人也许会纠结在需求不明中，用户没有限定数据类型，没有限定长度，没有一个标准怎么测？熟练后，就不会考虑这个问题，根据实际项目如果用户对登录本身并不重视，只是起一个登录作用不需要做都少验证，那么就可能只测一下正确能不能登录，错误能不能登录一些情况而不会过多的去考虑长度，数据类型，这些都需要判断力，也正是我们测试的一种经验，是我们在工作中可以提高的能力。
以上四点严谨性，计划性，预见性和可分析性，还有判断力，都是我认为在我们测试工作中每时每刻都在用，并且能随时带给我们好处的，如果是开发人员的经验在于代码等显性的能力，那么测试员的经验就在于这类隐形的能力。
有的人，工作一年，没有一点进步，有的人一年后，效率和质量都有很大提高，这就是经验，工作经验并不一定等于工作年限，只是因为测试人员的能力很多都是隐形的，没有办法直观看到，面试官只能通过工作年限来判断一个人的工作经验，这是一种测试职业不可避免的无奈，这一点在抱怨也没有用的。
这是我问自己的第二个问题，在回忆了一遍昨日的整个工作情况后给自己做得总结，因为在回忆中发现其实原来这样做可以省下很多工作量，其实这样做能更好，原来还有这个地方没有测到，就是这些其实和原来，让我觉得提升的空间还有很多，测试的工作也不再是测试，而是对自己测试能力的提升，其实任何行业只要你发现了自己提升的痕迹，那么动力就这么简单就来了。
第三个问题：浅谈面试
其实这个问题比较私人了，主要是对自己的一种反省，平常生活中的点点滴滴都是值得我们细细品味的，前段时间参加了2次面试，都被刷下来了，这个结果我心理很清楚，所以也谈不上失落，这里只是谈一谈对待面试的时候，我的心态，由于现实原因我十分明白自己面试的机会为0，当然这些现实原因我是在简历中有提到的，当接到面试电话的时候其实心里很惊讶，仔细看了一下对方的岗位要求发现自己一样都不符合，唯一符合的就是对测试的了解，抱着好奇的心态也抱着学习的心态参加了这次面试，接待我的是一位联想的面试官，这是我真正意义上的第一次面试，有点紧张，在交谈中我发现其实面试没有自己想得那么吓人，整个气氛还是很平和的，从面试官的交谈中学习到了很多东西，也在回答面试官的问题时发现自己哪些地方不足，第一次面试主要让自己了解到技术上得差距和经验上得差距，也让自己对面试不再那么紧张，第二次面试，是游戏测试员的职位，这次或许因为跨了行业，了解到的就更多了，我现在是在做WEB测试，对于游戏测试一窍不通，到场后先是一轮笔试，笔试上得题目看了后觉得对测试很不重视，近15道题，测试的只有2道，这时我心里有了点抵触，我很喜欢测试这个职业，不希望去做测试机器，然后开始了面试，和面试官的交谈中，发现项目测试和产品测试本质上的不同，项目一般相对产品较小，所以测试的时候整个流程都是很活得，特别是一个人一个项目，整个测试过程都是你一个人控制，非常的灵活，而产品测试不一样，每一个环节都要求的非常严格，非常的死，这个死不是死板，而是牢固，在和面试官的经理交流中了解到，产品的测试如果不严格的控制和管理，那么如果一个小得细节忽略了，需要改动的就是整个所有的环节，如果一个用例没有合格或者擅自改动了，那么影响的将是所有后续升级后续优化和后续相关用例的使用，不是不活，是不敢灵活，影响实在太大，风险实在太大，这是两种完全不同的测试道路，同时也发现自己不适合走这条线路，我的思想很活跃，不会一成不变的去用别人的知识，我喜欢根据自己的实际情况对别人的技巧进行修改，整合，最后形成我自己的风格。
说了这么多，其实想表达的就一个，珍惜你的面试机会，也尊重你的面试官，对于得到面试机会却不去面试的人，我只能为你惋惜，某种意义来讲，面试经验比工作经验更加难得，人的一生能够工作几十年，而面试呢，一次面试算一个小时吧，你一生能面试几十个小时呢？并且，面试官在和你交流的时候，你能从中学到很多东西，管中窥豹可见一斑，或许不能提高你的测试能力，但却可以给你指明一条大概的方向，能够排除掉你的一些不适合的道路，能够缩小你的可选内容，呵呵其实有时候，可以选择的东西多了也不好。
这里有我昨日思考的三个问题，也有我的答案，生活和工作本身就是一本书，而我们有的人是真的在读书，从书里面学到很多知识和技巧，而有的人则是在翻书，或许翻书的日子过的比较快，一翻一天就过去了，而读书的人往往要读很久一天才会过去，但是。。。。呵呵。。你们明白中间的差距的。。。。