对面试班驳的记忆
第一次面试失败原因：1、学了后面忘了前面，没有及时回顾以前的知识2、紧张是最大的障碍，记得那次问的问题很简单，但是很多平时脱口而出的知识点，这时候却怎么也想不起来，主要问了以下几部分内容：OSI七层结构、白盒和黑盒测试有什么异同，编写用例有哪些方法，软件测试生命周期，软件开发模式有哪些，如何提交缺陷，Linux常用命令有哪些，SQL语句：增、删、改、查、创建视图、创建存储过程等，软件测试需要哪些素质，你以前工作还不错，现在为什么选择测试，你认为你做测试工作的优势是什么？总之问了很多，不过问题都不难
失败后，我采取的对策；买了个可随身携带的小本子，花了一下午时间总结一下面试中问过的问题，晚上又到网上查了很多面试中可能问到的问题，一一记录下来，后来又花了2天时间把所有学习中的重要知识点记录下来，再后来的2天我出现在了秦淮河边，手里拿着那个小本子（后来送朋友了）.....
第二次面试：失败原因对待遇问题回答的失败：
第一轮笔试，考的是开发的试卷C/C++，C占10% C++占60%，智力题30%，因为没学过C++，所以C++都是根着自己的推想答题的，C语言只有2题，一个选择题一个编程题（考了指针）智力题总共4题，比较简单都做对了，具体题目记不清了（面试结束回家等通知，回家的路上买了本C++从入门到精通）
第二轮测试王经理面试：问了很多测试方面的问题，都是对答如流，但后来问了2个开发的问题，一个面向对象语言的，刚好看到过，回答上了，还有个是架构方面的，没回答上来，我说不好意思我不会（后来才知道，勇敢的承认自己不会要比乱回答好的多）面试的过程很愉快，面试结束后，王经理说，请稍等一下，人事部陈经理有些人事方面的问题要问一下
第三轮人事陈经理面试：开始问了一些问题：怎样做好测试，为什么选择测试行业，等等都回答的很好，最后聊到薪水的时候，陈经理问：假如我们公司录用你，你期望的月薪是多少？我说：作为一个测试新人来讲，测试经验对我来说很重要，薪水多少并不重要（犯了个巨大的错误，对薪水要求过低会给对方造成缺乏自信的误解）陈经理说：“薪水不重要，那公司不给薪水你也愿意做吗？怎么可能？”听到这句话，我知道＇成功的母亲＇又来看我了．
失败后，我采取的对策：记录下人事问的问题，修改了下对薪水问题的回答：测试经验的积累对于一个测试新人来讲无疑是最大的财富，但人要生存，又必需有经济收入，我期望的薪水就是经验财富与物质财富的平衡点：月薪***（回答的时候面带笑容，语速不能太快，最好能像和朋友聊天一样），当天又到网上查了很多面试陷阱
第三次面试，成功的开始，成功原因对基本知识的掌握、自信、礼仪
第一轮上机面试：参与面试的共六个人，公司直接给个系统，让我们开始测试，然后写份测试报告，时间2个小时
这是我第一次接触真实项目的上机操作，紧张是难免的，但是很快就进入状态，首先看了下测试说明（缺陷提交规范），然后开始看需求文档，看完后，打开系统，打开需要测试模块的每个功能模块，粗略看下有哪些功能，然后进入了漫长的测试（没有用例，只能通过自己对系统的理解去测，再次说明需求理解对测试的重要性）房间里只剩下6个相对静止的人……
时间不因为我们的“静止”而静止，终于上机时间到了，把测试报告提交到指定文件夹下，当时测试说明中明确规定，以姓名_日期.TXT命名报告， 可打开文件夹，有WORD，有Execl，有的命名格式也不对……
上机结束了，大家自我感觉都很不错，当时我表现的并不好，找了23个BUG，第3，这时经理和我们讲，你们要是没什么疑问就先回去等消息吧，我把椅子还原到原来位子，因为是最后一个走，和经理说了声：**经理，谢谢您，再见，然后又和另外一位在办公室的员工说了声再见，然后随手把门轻轻的带上
第三天，6个人中只有2个人接到电话面试通知，其中有一个是我
又过了2天，电话面试开始了，有点紧张，但问的问题基本上都回答上来了，电话面试结束前，问了下，请问经理您贵姓，他说他姓王，我说谢谢您王经理，希望以后有机会向您学习测试经验（可以不失时机的表达一下自己对学习的渴望，语气要诚恳）
又过了2天，接到经理打给我的电话，面试通过了，6个人只有一个通过
成功经验：1、熟悉系统，不错发BUG，严格按要求做（当然公司有什么不合理的地方可以提建议）
2、礼仪、礼貌（一般比较正规的公司都会注意到这些细节）
3、学会总结，不要让自己在同一个地方跌倒
下面总结一下测试新人，怎样快速找出系统的不足或缺陷
1、阅读需求文档，深入了解系统，磨刀不误砍柴工，不要还没弄清需求就开测了，（一个星期前，公司刚进一个新人，TD上查看了下他们发的BUG，发现好几个是需求不明确误发的）心想：原来是这个系统啊，项目实训的时候做过和这个类似的项目，于是就把实训的系统需求硬生生的搬到当前系统来，这样做的风险太大，因为每个系统的需求都不一样，不能生搬硬套，打个比方：假设要你制造一辆轿车，你以前制造过普桑，就把你制造普桑的技术拿去制造林肯，这样做显然不合适。熟悉系统（一般公司都会有系统熟悉情况考核）所以请一定要认真的阅读需求文档（有的公司叫产品定义）
2、熟悉测试用例，这是测试执行的一个导向，要想快速高效率的执行用例，必须在熟悉系统的同时，熟悉用例，熟悉每条用例覆盖的需求，这样执行起来才能事半功倍
3、记住自己在工作中扮演的角色是测试而不是开发 。珍惜时间，避免不必要的浪费。作为一个测试新人来讲，刚开始接触项目，有很多时候发现BUG，只是知道它的表象特征，却无法弄清这个缺陷是由什么引起的，这里就存在一个误区，花过多的时间去寻找原因，因为受个人所学习知识和经验上的限制，有的缺陷很难短时间内找到产生原因，与其这样浪费时间，不如将BUG重现给开发看一下，让开发找原因，那样即不耽误下面的测试也能在短时间内找出原因，从根本上解决BUG。
4、一旦发现缺陷，应立刻提交。有几种情况：测试就像是一场优胜劣汰的战斗，你的动作慢了，成果就是别人的了。
1）作为一个测试新人来讲，测试的第一步，可能是从执行用例开始，而成功的用例（项目刚开始时）可以发现很多系统中存在的问题，同一条case里的不同STEP就可能发现多个BUG，那么对于这样的情况，我们要做的是：发现就提交，不要等到所有STEP都执行完再提交。那样说不定已经被别人提交了。
2）‘抛开’需求说明书（即不用看需求说明书，对需求也特别熟悉），以快取胜。假设你和同事同时发现了个BUG（双方都不知道对方在提交），而你对需求不熟悉，不太确信是个BUG，然后又去翻需求，翻完回来再提交，结果这时候同事已经提交了，那么不好意思，你的BUG只能作CLOSED_Nbug处理了，如果一定要加上一个批注，那么将是，重复提交（测试新人，备注里不建议加测试建议（即怎样修改可以避免此缺陷），因为有可能会对开发产生误导）特别说明：1）速度和效率同时考虑，尽量别发错BUG；2）公平竞争，还要考虑团队合作，在别人的测试模块发现BUG，建议告知对方提，与同事交流的时候，同事讲到的缺陷，而缺陷管理工具中没提，应该让对方提交上去
5、新版本发布：
1）验证FIXED缺陷，如果验证通过了，把状态改为CLOSED（关闭的时候一定要加个备注，（比如：某月某日某版本验证通过。）对于开发修改了，但是与需求有出入的，且与测试经理确认可以这样修改时，备注建议这样写：某月某日某版本验证通过，修改为……），如果没通过改为OPEN（同样加个备注：某月某日某版本验证未通过），这里存在一个误区，有的人会把状态改为REOPEN，如果是公司要求的，那无可厚非，如果没有要求，建议改为OPEN，因为REOPEN是已经确认修改并且该BUG已经改为CLOSED状态后，才需要修改为REOPEN状态的。（有很多公司是不允许出现REOPEN状态的（针对开发），一旦出现，开发此模块的程序员绩效可能会被大打折扣，我现在所在的公司就是这样的）
2）冒下烟确保主流程畅通，然后再进行功能测试，着重测试有修改的或者与所修改模块有调用关系的模块和发现BUG比较多的模块（公司发布版本会邮件通知修改的模块与修复的BUG），未改动的模块建议做个流程测试。特别说明：主流程走不通，应立刻MSN给项目负责人（组长或经理，如果有本项目MSN群，直接在群里讲就可以了）
6、如果版本未更新，
1)建议着重进行业务逻辑方面测试，在电脑上以文档形式画出简单的业务逻辑图，重点说明：一定 要尽量考虑所有的情况，因为这样的BUG要么就没有，一旦有就是HIGH
2)建议进行环境测试（当然要根据需求测试相应的环境）
3)严格核对需求文档，防止需求遗漏
7、严格按照缺陷提交说明提交BUG，因为这有可能涉及BUG的统计问题，（一般公司的缺陷描述：系统名称_功能模块，缺陷描述，要具体问题具体对待）
优先级和严重程度不要夸大也不要降低，实事求是，因为这与开发和测试的绩效考评有挂钩，要是夸大缺陷，会影响开发的绩效考评，降低会影响自己的绩效考评，建议：系统级（影响流程）和跳黄页（报服务器错误的，这类缺陷有的是服务器配置错误导致，建议先检查配置后提交）建议为高，功能实现建议为中，界面易用，或者不影响系统使用的其他问题建议为低，具体级别公司会有规定，如果没有规定，可按照以上建议划分。
8、测试没有空闲。项目在不同阶段，会有些时间很‘空闲’。建议：
1）把测试管理工具中的缺陷分类导出，总结一下哪些模块容易产生哪些缺陷，重点看一下自己没发现或没有考虑到的缺陷，有多余时间可以看一下CLOSED_NBUG、ByDesign、Rejected、Deferred的缺陷：(下面是为什么看这些状态BUG的原因，但是超过10000字写不下了,我把写好的WORD文档放附件了)
第一次面试失败原因：1、学了后面忘了前面，没有及时回顾以前的知识2、紧张是最大的障碍，记得那次问的问题很简单，但是很多平时脱口而出的知识点，这时候却怎么也想不起来，主要问了以下几部分内容：OSI七层结构、白盒和黑盒测试有什么异同，编写用例有哪些方法，软件测试生命周期，软件开发模式有哪些，如何提交缺陷，Linux常用命令有哪些，SQL语句：增、删、改、查、创建视图、创建存储过程等，软件测试需要哪些素质，你以前工作还不错，现在为什么选择测试，你认为你做测试工作的优势是什么？总之问了很多，不过问题都不难
失败后，我采取的对策；买了个可随身携带的小本子，花了一下午时间总结一下面试中问过的问题，晚上又到网上查了很多面试中可能问到的问题，一一记录下来，后来又花了2天时间把所有学习中的重要知识点记录下来，再后来的2天我出现在了秦淮河边，手里拿着那个小本子（后来送朋友了）.....
第二次面试：失败原因对待遇问题回答的失败：
第一轮笔试，考的是开发的试卷C/C++，C占10% C++占60%，智力题30%，因为没学过C++，所以C++都是根着自己的推想答题的，C语言只有2题，一个选择题一个编程题（考了指针）智力题总共4题，比较简单都做对了，具体题目记不清了（面试结束回家等通知，回家的路上买了本C++从入门到精通）
第二轮测试王经理面试：问了很多测试方面的问题，都是对答如流，但后来问了2个开发的问题，一个面向对象语言的，刚好看到过，回答上了，还有个是架构方面的，没回答上来，我说不好意思我不会（后来才知道，勇敢的承认自己不会要比乱回答好的多）面试的过程很愉快，面试结束后，王经理说，请稍等一下，人事部陈经理有些人事方面的问题要问一下
第三轮人事陈经理面试：开始问了一些问题：怎样做好测试，为什么选择测试行业，等等都回答的很好，最后聊到薪水的时候，陈经理问：假如我们公司录用你，你期望的月薪是多少？我说：作为一个测试新人来讲，测试经验对我来说很重要，薪水多少并不重要（犯了个巨大的错误，对薪水要求过低会给对方造成缺乏自信的误解）陈经理说：“薪水不重要，那公司不给薪水你也愿意做吗？怎么可能？”听到这句话，我知道＇成功的母亲＇又来看我了．
失败后，我采取的对策：记录下人事问的问题，修改了下对薪水问题的回答：测试经验的积累对于一个测试新人来讲无疑是最大的财富，但人要生存，又必需有经济收入，我期望的薪水就是经验财富与物质财富的平衡点：月薪***（回答的时候面带笑容，语速不能太快，最好能像和朋友聊天一样），当天又到网上查了很多面试陷阱
第三次面试，成功的开始，成功原因对基本知识的掌握、自信、礼仪
第一轮上机面试：参与面试的共六个人，公司直接给个系统，让我们开始测试，然后写份测试报告，时间2个小时
这是我第一次接触真实项目的上机操作，紧张是难免的，但是很快就进入状态，首先看了下测试说明（缺陷提交规范），然后开始看需求文档，看完后，打开系统，打开需要测试模块的每个功能模块，粗略看下有哪些功能，然后进入了漫长的测试（没有用例，只能通过自己对系统的理解去测，再次说明需求理解对测试的重要性）房间里只剩下6个相对静止的人……
时间不因为我们的“静止”而静止，终于上机时间到了，把测试报告提交到指定文件夹下，当时测试说明中明确规定，以姓名_日期.TXT命名报告， 可打开文件夹，有WORD，有Execl，有的命名格式也不对……
上机结束了，大家自我感觉都很不错，当时我表现的并不好，找了23个BUG，第3，这时经理和我们讲，你们要是没什么疑问就先回去等消息吧，我把椅子还原到原来位子，因为是最后一个走，和经理说了声：**经理，谢谢您，再见，然后又和另外一位在办公室的员工说了声再见，然后随手把门轻轻的带上
第三天，6个人中只有2个人接到电话面试通知，其中有一个是我
又过了2天，电话面试开始了，有点紧张，但问的问题基本上都回答上来了，电话面试结束前，问了下，请问经理您贵姓，他说他姓王，我说谢谢您王经理，希望以后有机会向您学习测试经验（可以不失时机的表达一下自己对学习的渴望，语气要诚恳）
又过了2天，接到经理打给我的电话，面试通过了，6个人只有一个通过
成功经验：1、熟悉系统，不错发BUG，严格按要求做（当然公司有什么不合理的地方可以提建议）
2、礼仪、礼貌（一般比较正规的公司都会注意到这些细节）
3、学会总结，不要让自己在同一个地方跌倒
下面总结一下测试新人，怎样快速找出系统的不足或缺陷
1、阅读需求文档，深入了解系统，磨刀不误砍柴工，不要还没弄清需求就开测了，（一个星期前，公司刚进一个新人，TD上查看了下他们发的BUG，发现好几个是需求不明确误发的）心想：原来是这个系统啊，项目实训的时候做过和这个类似的项目，于是就把实训的系统需求硬生生的搬到当前系统来，这样做的风险太大，因为每个系统的需求都不一样，不能生搬硬套，打个比方：假设要你制造一辆轿车，你以前制造过普桑，就把你制造普桑的技术拿去制造林肯，这样做显然不合适。熟悉系统（一般公司都会有系统熟悉情况考核）所以请一定要认真的阅读需求文档（有的公司叫产品定义）
2、熟悉测试用例，这是测试执行的一个导向，要想快速高效率的执行用例，必须在熟悉系统的同时，熟悉用例，熟悉每条用例覆盖的需求，这样执行起来才能事半功倍
3、记住自己在工作中扮演的角色是测试而不是开发 。珍惜时间，避免不必要的浪费。作为一个测试新人来讲，刚开始接触项目，有很多时候发现BUG，只是知道它的表象特征，却无法弄清这个缺陷是由什么引起的，这里就存在一个误区，花过多的时间去寻找原因，因为受个人所学习知识和经验上的限制，有的缺陷很难短时间内找到产生原因，与其这样浪费时间，不如将BUG重现给开发看一下，让开发找原因，那样即不耽误下面的测试也能在短时间内找出原因，从根本上解决BUG。
4、一旦发现缺陷，应立刻提交。有几种情况：测试就像是一场优胜劣汰的战斗，你的动作慢了，成果就是别人的了。
1）作为一个测试新人来讲，测试的第一步，可能是从执行用例开始，而成功的用例（项目刚开始时）可以发现很多系统中存在的问题，同一条case里的不同STEP就可能发现多个BUG，那么对于这样的情况，我们要做的是：发现就提交，不要等到所有STEP都执行完再提交。那样说不定已经被别人提交了。
2）‘抛开’需求说明书（即不用看需求说明书，对需求也特别熟悉），以快取胜。假设你和同事同时发现了个BUG（双方都不知道对方在提交），而你对需求不熟悉，不太确信是个BUG，然后又去翻需求，翻完回来再提交，结果这时候同事已经提交了，那么不好意思，你的BUG只能作CLOSED_Nbug处理了，如果一定要加上一个批注，那么将是，重复提交（测试新人，备注里不建议加测试建议（即怎样修改可以避免此缺陷），因为有可能会对开发产生误导）特别说明：1）速度和效率同时考虑，尽量别发错BUG；2）公平竞争，还要考虑团队合作，在别人的测试模块发现BUG，建议告知对方提，与同事交流的时候，同事讲到的缺陷，而缺陷管理工具中没提，应该让对方提交上去
5、新版本发布：
1）验证FIXED缺陷，如果验证通过了，把状态改为CLOSED（关闭的时候一定要加个备注，（比如：某月某日某版本验证通过。）对于开发修改了，但是与需求有出入的，且与测试经理确认可以这样修改时，备注建议这样写：某月某日某版本验证通过，修改为……），如果没通过改为OPEN（同样加个备注：某月某日某版本验证未通过），这里存在一个误区，有的人会把状态改为REOPEN，如果是公司要求的，那无可厚非，如果没有要求，建议改为OPEN，因为REOPEN是已经确认修改并且该BUG已经改为CLOSED状态后，才需要修改为REOPEN状态的。（有很多公司是不允许出现REOPEN状态的（针对开发），一旦出现，开发此模块的程序员绩效可能会被大打折扣，我现在所在的公司就是这样的）
2）冒下烟确保主流程畅通，然后再进行功能测试，着重测试有修改的或者与所修改模块有调用关系的模块和发现BUG比较多的模块（公司发布版本会邮件通知修改的模块与修复的BUG），未改动的模块建议做个流程测试。特别说明：主流程走不通，应立刻MSN给项目负责人（组长或经理，如果有本项目MSN群，直接在群里讲就可以了）
6、如果版本未更新，
1)建议着重进行业务逻辑方面测试，在电脑上以文档形式画出简单的业务逻辑图，重点说明：一定 要尽量考虑所有的情况，因为这样的BUG要么就没有，一旦有就是HIGH
2)建议进行环境测试（当然要根据需求测试相应的环境）
3)严格核对需求文档，防止需求遗漏
7、严格按照缺陷提交说明提交BUG，因为这有可能涉及BUG的统计问题，（一般公司的缺陷描述：系统名称_功能模块，缺陷描述，要具体问题具体对待）
优先级和严重程度不要夸大也不要降低，实事求是，因为这与开发和测试的绩效考评有挂钩，要是夸大缺陷，会影响开发的绩效考评，降低会影响自己的绩效考评，建议：系统级（影响流程）和跳黄页（报服务器错误的，这类缺陷有的是服务器配置错误导致，建议先检查配置后提交）建议为高，功能实现建议为中，界面易用，或者不影响系统使用的其他问题建议为低，具体级别公司会有规定，如果没有规定，可按照以上建议划分。
8、测试没有空闲。项目在不同阶段，会有些时间很‘空闲’。建议：
1）把测试管理工具中的缺陷分类导出，总结一下哪些模块容易产生哪些缺陷，重点看一下自己没发现或没有考虑到的缺陷，有多余时间可以看一下CLOSED_NBUG、ByDesign、Rejected、Deferred的缺陷：(下面是为什么看这些状态BUG的原因，但是超过10000字写不下了,我把写好的WORD文档放附件了)
----------------------------------------------------------------------------------------------------------------------
