感慨大公司就是不一样。突然感觉自己好渺小。好羡慕那些在大公司的人，羡慕那种技术很好闻什么什么都会的人。自己好自卑。

多谢大家光顾，以后我也会把和测试相关的工作学习生活的内容写在这里，共同学习探讨。下面言归正传，说下我在这段时间面试碰到的题目，相信对大家准备面试会有帮助，多多支持！

先说笔试：一般的公司会通过笔试淘汰一部分不符合他们公司职位要求的人员，毕竟每个公司具体岗位不一样，总希望招到能尽快上手的人，就像你做了2年多的纯功能方面的测试，而人家希望有点编程能力的做性能方面的测试，估计你会在笔试中被淘汰。所以笔试也是很重要的部分，当然你够牛就直接面吧。

1.编程基础，我不知道有多少做测试的朋友讨厌编程或者做软件开发，我个人是比较讨厌的，虽然学校里学的是计算机，但是到毕业也没正儿八经地写过超过百行的代码，但没写过不代表读不懂。所以选择填空还是可以应付的。对于可能的编程题，我是准备了一些如冒泡，折半算法、strcpy/strcmp/strlen原函数等。编程的能力是需要积累的过程，所以贵在平时。对于编程能力是否有助与测试这个论坛上讨论过的问题，我的观点是第一至少你找工作时用的着，第二如果做性能测试应该也需要，第三如果有2年以上的测试经历应该也会觉得非常有必要。本人也正硬着头皮再学c，虽然学了忘忘了学。

2.数据库知识，建议准备好sql语言，装个mysql自己通过敲命令，能掌握高级查询使用基本可以应对了。

3.软件测试理论，这个大家都不陌生，也是必考的了，应该可以轻松应付。要注意准备下web测试和性能测试这块，现在做web的公司好多。

4.根据公司具体的职位要求可以准备的有linux的命令，CMMI的基础知识，TCP/IP的基础知识，通信的如3G网络类知识等。

下面说面试：通过面试真的能看出很多，技术、经验、性格人品等，当然都是通过你的答题来让人家了解的。

1.请自我介绍一下。这个必答题。对于不善于表达的朋友要准备一把，我就是这种类型，好处是起码说起话来可以比较流利。说性格时可以提对做测试有优势点。

2.说说你以前公司的测试流程。必答题。主要结合自己的项目经验相信讲一个自己做过的项目，从立项到测试结束，当然侧重测试和自己所做的内容。这里面试官一般都会根据你说的再提问。

3.你是怎样做出自己的职业选择或者自己的职业规划。这题也经常问。可以从自己的优点说如何适合做软件测试，对与职业规划，我一般说在技术上往资深测试工程师发展。

4.你觉得自己作为测试工程的优势在哪里？/你认为自己比你的同事优秀在哪里？也经常问，可以从性格出发，讲自己优点，以及在项目中表现，领导的良好评价等，总之“恰当”地往好处说，不要言过其实，让人怀疑你的人品哦。说说自己的缺点？这个也不好回答，最好能恰当地引申回答到优点上。

5.一个测试中不堪回首，或者让你很郁闷的事情。我被问到了，当时想不起来，后来想想可以讲一个项目中的失误及后果，然后讲自己如何去成功弥补及教训经验。我如果提前想一下就不会该说什么了。

6.你的好友是如何评价你的？你的项目组长是如何评价你的？ 这类题也经常问。回答总要往好处说，但是你要自信地回答。

7.在成年后，哪些成绩给你带来最大程度的满足？蛮不错的题。记得我但是答的是第一次自己带一个小项目，顺利完成测试任务。

8.列举几个可能碰到的题，大家可以想想。

测试时你提交的bug被研发拒绝或者他认为不是问题，你如何处理？

测试与开发沟通如何提高效率和改善沟通效果？测试工程师的素质和技能？

你在压力下能工作的很好嘛？测试计划包括哪些？

9.你期望的薪水？问的很多啦，根据自己能力和公司的大小，可以搜索下了解下情况。在工作难找的情况下OFFER到手实在些，骑驴找马总容易很多。

关于这些面试题，自己想不好的可以网上搜搜，51上也有很多关于答题的技巧和答案。最后要说下心态，面试的时候自信最重要，自信也来自良好的准备，所以面多了总结下，下次就更自信了。想想没被录用只能说明公司不适合你，或者人家要不起你。说的废话蛮多的，最后希望Tester在自己的职业道路上走地顺利......

　　一、根基不牢

　　问题：利用等价类划分的方法，对某问题设计测试用例。

　　分析：98%以上的应聘者只知道按照有效等价类和无效等价类进行划分，殊不知此种分类方法只是等价类划分的一个典型应用而已，等价类划分远非只能划分为有效和无效两类。根据种种划分依据，还可以进一步划分很多其他类别。

　　问题：根据事件描述，画出对应的因果图。

　　分析：标准答案中只画了“两条恒等，两条非，一个与，一个或”。如此简单的问题，上百名应聘者中竟然无一人答对，痛心啊。黑盒测试方法就那么几种，既然你已知这个名，怎么就不知道多看几眼。

　　小结：

　　上面提到的是软件测试的最基本的方法，作为从业测试实际工作已经有1-2年的应聘人员，未能真正领悟，实属不应该，心浮气躁，忽视了你身边最简单，也是最厉害的技能。根基不牢，怎么可能把测试做深。

　　二、专业不精

　　问题：音视频文件都有哪些格式，这些格式之间有什么差别？

　　分析：此问题是问那些做过多媒体方面测试的，但是我们的应聘者向来都是拿来主义，别人给我什么媒体文件我就用什么做测试，而根本不管不问。“为什么 MIDI文件比WAV文件小那么多？我们如何知道扩展名是.Mpeg的文件是Mpeg1格式的还是Mpeg2格式的？”，面对这些问题，应聘者默默无语，只是无奈的笑笑。不去看别人，想想自己测试涉及的专业，是否把那个行业知识搞清楚了呢？

　　问题：测试脚本运行不畅如何调试？

　　分析：此问题是问那些标明自己熟练掌握WinRunner、Robot、QTP等测试工具的应聘人员，但是当真正问到他们关于脚本的具体调试时，有7成以上人员表示他们只是参加测试培训时老师讲过，或者自己在网上看过相关资料，另外有2成以上人员表示他们虽然用过，但是只是简单的录制回放，根本不会自己调试。可能是迫于无奈吧，简历里面什么都不写，可能面试的机会都没有，但是简历如此夸大的来写，终归是浪费自己的面试时间和路费。

　　小结：

　　从事测试仅1-2年时间，要想测试也精通，专业也精通确实不易，但是不说精通，至少也该知道个60%才对的起你的测试工作。一两年时光如此荒废，静下心来反思一下，身边还有哪些技能我们应该掌握扎实一点呢。

　　三、无测试体系概念，忽视理论

　　问题：请说出软件测试的定义，BUG的定义。

　　分析：99%的人不能说出这两个测试名词的定义，只是在给我解释测试是为了发现bug之类的片面理解，残留的几个人也说得不够准确。这两个词目前尚不能说业内已经有了成熟统一的定义，但是无论是对是错，身为测试人员已经数年，自己竟然说不出这两个词的概念，多少也说不过去啊。有些人和我说，理论名词概念不重要，我会做测试就是了。想想金庸老先生早就告诉我们，武功仅有招式是不够的，必须配合上什么心法口诀才能行。你只会测试执行的招式，却不懂测试理论的心法，怎么能够修炼成上乘的软件测试呢？

　　问题：请介绍一下你们的测试流程，流程和过程有什么不同，为什么好的测试需要好的流程？

　　分析：但凡做过1、2年测试的人都能给我说出他们先做什么后做什么，但是当我继续问“这是否可以叫做过程？流程和过程有什么差别”，应聘者一棒子被打晕，继续追问“为什么好的测试需要好的流程”的时候，早已经找不到东南西北了。每天公司各项制度叫你做什么你就做什么，让你怎么做你就怎么做，完全不管不顾为什么，那么自己岂不成了没头脑的工具。这样你能干的工作别人也能做，自己的优势不就没有了吗。

　　小结：

　　目前测试业内流传着学院派和实践派的说法，学院派的理论给人的感觉往往是好听但不实用，而实践派的知识，往往能够立即见效。所以眼下测试培训往往实践派的更受欢迎。继续引用金庸先生的观点，练武分练内气宗，练外剑宗，但是真正的高手是内外兼修。如果我们不想只做普通的测试小弟子的话，就要理论实践并重，方能有所作为。

四、周边知识知之甚少

　　问题：能给我介绍一下软件工程中的瀑布模型吗？

　　分析：又是8成应聘者不会回答，都是曾在遥远的学生时代有所耳闻，现今早已忘得一干二净了。软件测试因何而生——软件危机，软件危机导致软件工程的兴起，软件工程中又包含软件测试，就好像鱼儿活在水里，如果没有软件工程这个水，哪里能够养活这软件测试的鱼，如果我们对于身边的软件工程不够了解，怎么可能在里面自由的畅游呢。

　　问题：用你最熟悉的开发语言实现sum=1+2+3+…+100

　　分析：保守统计7成以上的应聘者写出来的程序无法执行或者运行结果错误，更少有人能够一气呵成，而且精准。这道编程题难吗？肯定不难，那么为何答错，自己没有真正写过程序，即使写过几行，也早就是如烟往事了。做测试一定需要懂开发吗？这个问题讨论以久，当然不一定，但是如果要做好测试，做深测试，分析问题原因，提出问题解决方案，编写测试脚本或工具，哪一个又能离开软件开发呢？

　　小结：

　　我们学习测试也应该有个先后顺序，有步骤。掌握周边知识的紧迫程度可能不如测试知识和行业知识。但是对于我们已经从业1-2年的测试人员来说，学校里面学到的知识不应该丢，之后的发展中，周边知识的学习也应该开始了。周边知识的范畴其实很广，还包括各种其他测试理念的学习，机械工业出版社翻译的那套测试丛书就很不错，观点众多而新颖，博众家之长，集大成，向来都是大家风范。

　　五、缺乏必要的责任心、细心、耐心、虚心等

　　问题：请数出下图中三角形的个数（平面图，有几根弧线做干扰）

　　分析：我总是问自己，这道题真有这么难吗？连中小学生都能数对的十几个三角形，到了我们这二十几岁的年轻人手中，正确率才1%，为什么？其实就是现在我们已经很少有人能够静下心来，耐心细致的去做事情了。很多应聘者告诉我她的优点就是“踏实，坐的住，正适合这繁琐的测试工作”。我需要的不是坐在那里不做事或者做错事的人，而是需要能够按时保质量完成测试工作的测试人员。

　　问题：你离职的原因？

　　分析：这是面试中最常见的问题了。应聘者往往也是充分准备，理由多种多样，但是看看应聘者的工作记录统计，70%应聘者平均跳槽频率是1年/次（实习情况除外），不会都那么凑巧吧，赶上什么公司倒闭，每隔一年就会想一次自己学不到东西，需要去外面看看。而在我看来，真正的原因更多的应该是希望通过跳槽提高工资，或者因为自身水平不足被公司炒鱿鱼吧。

　　小结：

　　我并不认为所有的人都适合做测试。非技术素质方面，这点或者那点不足够优秀也很正常，心浮气躁也可以理解。但是作为用人单位，理解归理解，却也不会用不胜任岗位，或性价比不高的人员。那么对于此类应聘者，我的忠告就是，要么你另谋高就，要么你就放低姿态，培养好你必备的素质后再谈。

　　六、缺乏诚信

　　这一点本应该被归在上一条素质中，但是这点的重要性我认为远超过了上一条所列各项，因此单独提出。相关表现主要体现在：1、虚报自己历史工薪；2、笔试题目作弊；3、编造离职原因；4、虚报学历，工作经验；5、夸大自己工作技能等。对于严重缺乏诚信的，一旦发现，其他表现再好，也无济于事了。

　　另外其实还有个大家都爱犯的通病，不知道如何问问题，言之无物，有的时候自己都不知道想问什么，但却心里总觉得自己是好学的是在请教，殊不知你并没有真正的在做事情，你并没有搞清楚事物的根本。

　　想学好一个东西，首要的就是要学好如何问问题。

　　最近在繁忙而复杂的找工作过程中，遇到问题无数，今日阅读若干文章感触颇深。自己的成败荣辱仿佛一瞬间集中在眼前。自己审视自己，真的，我还差的很多。

    请了一天半的假去面试,搞得像做贼一样,主管好象挺有意见,说一堆的事等着我做.也难怪,他们七八个软件开发人员配我这么一个不是很专业的测试,纵使我有三头六臂也力不丛心.
    第一家去文思,先笔试,不是很难,部份测试相关的理论,数据库查询和一些计算机基础知识,记得其中有一题是有个项目一个月完成,让你做项怎么试计划随后是由技术人员面试,问了些测试流程,类似之前公司是怎么进行测试工作的,其它问的什么也不记得了,因为我提过我没写过代码,于是问我平时有没有写些C语言的程序,像杨辉三角之类的,写个最简单的九九乘法表怎么写,我第一反应就是两个循环,一个控制行一个控制列就这么随意忽悠过去了,感觉一般般.下午复试,一车二十来人直接拉到了华为在滨江的驻地,要上缴有存储卡的手机,保安检查包包后才允许进入,里面空空的没几个人,但是每张桌子下都有一床被子,小小地震惊了下,原来真地像传说中的华为的员工都会加班到直接在公司睡觉(后来跟同学提起,才知道原来那是他们午休的时候用的,每个人都必须抱着床垫到指定休息室熄灯午睡).先做半小时笔试,只是从试题中抽取几题,都是C语言的基础题,不过做得比较差劲,远离C这么多年能忘的都忘了.然后也是由技术人员面试,和文思问的差不多,答得个人认为也比较差劲,随口而出,没没好好整理过,另外由于我们现在的公司根本就没什么测试流程和版本控制可言,自己几乎都没什么项目经验,这次的面试结果应该没什么机会了,在回来的车上文思的人力资源美眉说这次主要招敏捷测试的,比做开发的要求还高,模糊了开发与测试的概念,也不知道是真是假.
   第二家去三汇软件,招聘信息上说是要招5个测试,结果去了才知道只招一个,和我的初衷有些出入.正是因为现在公司就我一个做测试,什么都是自己学,甚至是流程或方法都弄错了也不得而知,所以很想能进入一个测试团队,从别人身上真正学到些有用的东西.三汇软件目前没有专门的测试人员,想招个能力强点的并希望在不久的将来能组建一个测试团队.双方有了这样个矛盾,结果也是可想而知的,不过面试没有问到很专业的东东,不过面议状态是最好的一次,人力资源美眉还说等他们组建好测试团队需要招专门的测试人员是如果我还有意去的话到时直接打电话她,说是肯定仍记得我的.不管是真是假,人力资源做得不错,至少给应聘人员留下了很好的印象.
    第三家是东软的杭州办事处,感觉这次是挺专业的面试,也是最受益匪浅的一次,让我看到了自己测试经验的严重不足,一大早去做笔试,好几十人,有开发有测试. 笔试题目全是围绕着测试知识,有不定项选择和填空,名词解释,简答及应用题.其中有印象的是,什么是数据字典,作用是什么,用在什么阶段,oracle中主键与唯一索引的区别,测试用例及分析测试用例注意事项,用自己的语言描述软件测试工作主要阶段.大型金融门户网站系统软件的测试重点及注意事项等.其中一题写测试用例的应用题最直接让我看到了自己离专业测试的差距.然后是面试,除了问为什么跳槽等一些常规问题外也问了一些怎么开展测试工作等问题,还有QTP的使用等,会结合你现在公司做的项目提出一些测试方法的问题,老实说现在公司做黑盒每天这边点点那边点点,诸如常用的什么等价类方法怎么实际运用到测试工作中我都不得而知,面试的整个感觉自己太失败了,都开始怀疑自己是不是测试人员了,项目经验太缺乏,知道也没什么好结果临走很谦虚的问了下面试官我的薄弱点,数据库方面比较弱,要加强linux,数据库及自动化方面的知识与能力,顺带又提了下我的优点可能算作安慰,就是我的性格很适合做测试,没任何一点浮躁的表现这个是做测试是最需的.
   从东软出来我立马做出一个决定,暂停找工作,没有测试团队的小公司是不会去的,而有规范测试流程测试团队的公司以我现在这么点专业知识很难达到他们的要求,对linux一窍不通,数据库也几乎什么都不知道,只晓得最简单的select,没有任何的编程经验,且现在公司这么多工作也不允许我经常请假,综合之下,还是觉得应该有针对性地恶补下规范的测试理论知识,总结下自己的测试经验,对linux与数据库一定有有个全面的了解,至少基本的操作都要会.只要能在面试中遇到这些都能有问必答,条理清晰,以确保面试过关.51testing的每周一问很不错,面试中会提到的问题很多应该里面就有,多研究研究.
 

PS:附上东软的测试用例应用题,有关保险的我也一窍不通,所以这个用例我一看就晕了~~,还请各位兄弟姐妹们提点一下.利用等价类划分方法,针对保险费率计算规则设计出足够多的测试用例,并详细描述用例整个步骤,其中保险计算方法为投保额*保险率,保险费率按点数几算,10点以下费率为0.6%,10点以下为0.1%
年龄 20-39  6点
    40-59  4点
    60以上20以下 2点
性别 mail  5点  femial  3点
婚姻 已婚3点,未婚5点
抚养人数 一人扣0.5点,最多扣3点(四舍五入取整)

通用指标（指Web应用服务器、数据库服务器必需测试项)

Web服务器指标

数据库服务器性能指标

系统的瓶颈定义

稳定系统的资源状态

　　通俗理解：

　　日访问量

　　常用页面最大并发数

　　同时在线人数

　　访问相应时间

　　案例：

　　最近公司一个项目，是个门户网站，需要做性能测试，根据项目特点定出了主要测试项和测试方案：

　　一种是测试几个常用页面能接受的最大并发数(用户名参数化，设置集合点策略)

　　一种是测试服务器长时间压力下，用户能否正常操作(用户名参数化，迭代运行脚本)

　　一种则需要测试服务器能否接受10万用户同时在线操作，如果是用IIS做应用服务器的话，单台可承受的最大并发数不可能达到10万级，那就必须要使用集群，通过多台机器做负载均衡来实现；如果是用websphere之类的应用服务器的话，单台可承受的最大并发数可以达到10万级，但为性能考虑还是必须要使用集群，通过多台机器做负载均衡来实现；通常有1个简单的计算方式，1个连接产生1个session，每个session在服务器上有个内存空间大小的设置，在NT上是3M，那么10万并发就需要300G内存，当然实际使用中考虑其他程序也占用内存，所以准备的内存数量要求比这个还要多一些。还有10万个用户同时在线，跟10万个并发数是完全不同的2个概念。这个楼上已经说了。但如何做这个转换将10万个同时在线用户转换成多少个并发数呢？这就必须要有大量的历史日志信息来支撑了。系统日志需要有同时在线用户数量的日志信息，还需要有用户操作次数的日志信息，这2个数据的比例就是你同时在线用户转换到并发数的比例。另外根据经验统计，对于1个JAVA开发的WEB系统（别的我没统计过，给不出数据），一般1台双CPU、2G内存的服务器上可支持的最大并发数不超过500个（这个状态下大部分操作都是超时报错而且服务器很容易宕机，其实没什么实际意义），可正常使用（单步非大数据量操作等待时间不超过20秒）的最大并发数不超过300个。假设你的10万同时在线用户转换的并发数是9000个，那么你最少需要这样的机器18台，建议不少于30台。当然，你要是买个大型服务器，里面装有200个CPU、256G的内存，千兆光纤带宽，就算是10万个并发用户，那速度，也绝对是嗖嗖的。

　　另外暴寒1下，光设置全部进入运行状态就需要接近6个小时。具体的可以拿1个系统来压一下看看，可能会出现以下情况：

　　1、服务器宕机；

　　2、客户端宕机；

　　3、从某个时间开始服务器拒绝请求，客户端上显示的全是错误；

　　4、勉强测试完成，但网络堵塞或测试结果显示时间非常长。假设客户端和服务器之间百兆带宽，百兆/10000=10K，那每个用户只能得到10K，这个速度接近1个64K的MODEM上网的速度；另外以上分析全都没考虑系统的后台，比如数据库、中间件等。

　　1、服务器方面：上面说的那样的PC SERVER需要50台；

　　2、网络方面：按每个用户50K，那至少5根百兆带宽独享，估计仅仅网络延迟就大概是秒一级的；

　　3、如果有数据库，至少是ORACLE，最好是SYSBASE，SQL SERVER是肯定顶不住的。数据库服务器至少需要10台4CPU、16G内存的机器；

　　4、如果有CORBA，那至少再准备10台4CPU、16G内存的机器；再加上负载均衡、防火墙、路由器和各种软件等，总之没个1000万的资金投入，肯定搞不定。

　　这样的门户系统，由于有用户权限，所以并不象jackie所说大多是静态页面。但只要是多服务器的集群，那么我们就可以通过1台机器的测试结果来计算多台机器集群后的负载能力的，最多额外考虑一下负载均衡和路由上的压力，比如带宽、速度、延迟等。但如果都是在1台机器上变化，那我们只能做一些指标上的计算，可以从这些指标上简单判断一下是否不可行，比如10万并发用户却只有1根百兆带宽，那我们可以计算出每个用户只有1K带宽，这显然是不可行的。但实际的结果还是需要测试了才知道，毕竟系统压力和用户数量不是线性变化的。

　　这一类系统的普遍的成熟的使用，以及很多软件在方案设计后就能够大致估算出系统的性能特点，都导致了系统在软件性能方面调优的比例并不大（当然不完全排除后期针对某些代码和配置进行优化后性能的进一步提高），更多的都是从硬件方面来考虑，比如增加内存、硬盘做RAID、增加带宽、甚至增加机器等。

　　网络技术中的10M 带宽指的是以位计算， 就是 10M bit /秒 ，而下载时的速度看到的是以字节（Byte）计算的，所以10M带宽换算成字节理论上最快下载速度为： 1.25 M Byte/秒!

这一个多月来对我来说是一笔宝贵的财富，在广州大大小小的软件公司基本跑个遍

面试了10家，最后第九家收留了我，虽然我不是很满意，但没办法，金融危机下工作不好找（深深体会ing)

回顾过去，是为了更好展望未来，是时候写点东西来记录下我一个多月的面试经历我是去年底就辞职的，两年的工作就是点点击击，美其名曰黑盒测试，性能测试。

出来后因为临近春节就没去找工作，从02-15号开始网上群发，陆陆续续收到很多面试的机会，基本上两天一个面试。

其中的面试又分为面试型和笔试型，有的公司是技术的人和你面谈，有的需要笔试再面谈，有的先是HR面再技术面。

两年后的面试让我发现了很多东西，在广州这边 1.很多公司对测试已经较为重视，虽然很少成立相应的部门，但起码对测试的要求提高，06的时候广州这边做测试的还很少，现在需求是多了，但要求也高，不仅仅是黑盒测试，更要求你要有相应的编程，脚本开发，懂Linux shell，自动化（其实真正用到的又有多少）

2.做测试的MM有明显增多的趋势，而且有的公司干脆写明不招男性测试

3.做测试的越来越多，竞争大，一个公司一般只招两三名测试人员

其中有一家大公司（集团公司）的MM让我印象非常地深刻，和我一样年轻，她面试我的时候从来没有用眼睛看着我一秒，可能是我不够帅，而是斜向一边，侧面对着我，可能是我的回答让她不满意，她最后对我说：都说现在你们不好找工作，我们公司却找不到一位合适的员工，我都面试了七八个了。

还有一家我非常非常想进入的，很好的公司，它需要的3年以上的工作经验，我也投了简历（我只有两年），两个小时笔试题，一个小时等侍，半小时面谈，有三个面试官，从头到尾我都被他们三个BS，不精通开发，不精通shell编程，写出的存储过程错，触发器错误百出，这是我见过的对测试要求最高的公司。

面试是人生必经的，面试是一道镜子，让你认清了自己，剖析自己

从今天开始，面向大海，春暧花开。

从今天开始，我要好好学习，天天向上。

说真的，有很多间叫我去复试，但我最后都没把握住

没有研究深入，沟通能力欠缺，说真的，有点紧张，平常会的都没说好，有时候答非所问以下是面试我经常被问的题目，包括笔试。

笔试：

编程：用任何一种程序设计语言写出1到100相加的结果

int i=1; int sum=0; while(i<=100) sum=sum+i; i++;

全局变量和局部变量的区别可以从作用域和存储域来说，全局一般是在静态存储区，局部是存储在内存中的栈中，全局作用在整个工程，程序都有效，局部只在方法内有效，涵数结束后从内存消失

接口和抽象类的相同点和区别 参数传递有几种，分别是什么 有哪些常见的排序：冒泡排序，简章排序，插入

有哪些区别

最大公倍数，素数，最小公倍数用一种语言写出来

一般很少问到编程的东西，但一个优秀的测试工程师肯定需要懂点开发的知识

一般问到编程的知识的公司对测试的要求也高，薪水也很高

 数据库：主要有两道题，网上有，很常见的其他的基本的SQL操作语句 Linux 主要是针对那些简历上说熟悉LINUX系统的人基本的shell命令，查内存，CPU，硬盘深一点的：写出一些shell编程测试：

简单介绍下你公司的测试流程

测试计划包括哪些内空，你觉得哪些是最重要的

测试用例包括哪些内空，哪个是最重要的

缺陷报告包括哪些内空，哪个是最重要，BUG描述

如何与开发人员沟通，如何与客户沟通

BUG的跟踪

熟悉白盒测试么

测试的方法有哪些测试

眼镜，水杯，椅子，反正随便一个物品

用你以往的项目经验说下你怎么测试

让你印象最深刻的三个BUG，在以往的工作中

你觉得测试从哪个阶段介入最好

你为什么选择这个行业

你以后想怎么发展

你会自动化测试么，LR，TD，QTP，WINRUNNER

说出基本的操作步骤测试过程，

测试执行，测试工具哪个更重要

当时我说测试过程，后来面试官说测试执行最重要，他说公司还没有测试流程，只有搞懂业务流程，执行好测试才能建立测试流程测试策略是什么

WEB测试有哪些安全性测试有哪些

B／S结构和C／S结构有什么区别

B／S结构和C／S结构用到的测试方法有什么不同

测试用例覆盖率的问题，这个问得很深

怎么是覆盖率，怎么才算覆盖较高的测试用例

什么是好的测试用例，有没有100%覆盖的用例

总结一下你对测试几年的理解

网络：

OSI七层结构，TCP／IP四层协议

ARP，RARP，ICMP属于哪一层

TCP与UDP的区别

还有很多很多

在软件工程论坛上，kasad“问偶然性不可重现BUG怎么处理？”我和一些网友进行了讨论，下面就是整理的一些记录，主要是me的。

一、一定要提交！！

1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5． 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。

二、程序不是测试人员写的，出问题也不是测试人员的原因
至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。
测试人员的任务只是尽力重现问题，而不是必须重现三、下次再遇到的时候，拉他们来看就可以了
因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。
 
而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。

四、你可以告诉程序员，测试过程是没有错误的。 
测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。
需要让程序员理解，测试人员是帮助他们的，不是害他们的。
 
客户那里发现问题比测试员发现问题结果要严重的多五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。 
在我们这里上面的事情，和程序员相互只能商议解决，并没有谁高谁低。
问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。
 
实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现（比较严重的问题才如此处理，小问题经理之间商量商量可能就算了）。
至于测试人员必须重现bug，你杀了我好了，我每次测试项目都有无法重现的问题，很多我能找到大概的原因，有些根本无法重现（仅仅出现一次）。
 
这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位（哼，程序有bug，是否可以说程序员工作不到位的呀）。

六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。
我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过，这样就避免了很多的问题其实只要自己尽到心就可以了，管别人怎么说呢。

七、我们使用的状态有： >程序员处理的状态（由测试员提交的Action）：等待处理的，再次出现的。 
测试员处理的状态（由程序员提交的Action）：已经修改的，暂不修改的，系统限制的，使用错误的，无法再现的。测试员可以修改记录。 
 
经理处理的状态（由测试员提交Action）：管理员处理的。经理还可以删除记录。
 
按照比较标准的说法，其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态，我们为了省事，统一使用了“等待处理的”。
 
最后结项的时候，缺陷的状态对我们来说有两种，“已经关闭的”（由测试员或经理确认）和“暂不修改的”（比如下一个版本处理等）。
 
呵呵，状态多，有些烦琐，特别是程序员很多的时候都不清楚应该回复什么状态，但我个人觉得对测试人员来说，这些状态比较清晰明了，容易处理。

八、一个叫doer_ljy(可战)的网友回复了一些内容，我个人认为不很妥当，就回复了一些内容，绿颜色的是doer_ljy(可战)的内容： 

关于“无法重现”我看是有这么个问题存在。
首先如果你在测试之前有严格的测试计划，就很难出现“无法重现”这种现象。“无法重现”的意思是不知道怎么操作才能再次看见这个BUG。那么这个BUG多半是“计划外”的。

不清楚你是否是测试人员。“计划外”这个词，对测试员来说应该不存在。测试用例的粒度一直是个在讨论中的问题，测试人员很难有时间和精力写出包含内容、数据、步骤等等全部操作一切的测试用例（说白了，只要一个长手识字的人，按照测试单做，就能发现所有的问题，呵呵，有软件蓝领的感觉了）。即使真的有，意义也不大，测试很多的时候，是发散性的思维，带点创造性，想事先考虑完全，很难。所以更多时候，是在测试过程中逐步对用例等进行完善，所以说“计划外”最好不要提。
 
说说我现在测试的一个项目，有一个业务，首先查询出人员，有个“全选”按钮，“全选”后，再用鼠标一个一个取消选择，这个时候进行业务办理的时候，就会提示“没有选择人员”，至今为止一切都正常，但是这个时候再次点选人员进行业务处理，仍然会提示“没有选择人员”，这就是一个缺陷了。这个问题我想一般人都不会在测试用例中考虑到吧，因为发生的条件很苛刻：不用“全选”按钮的时候不会发生；全选后点击“取消全选”按钮再办理业务不会发生；全选全消后，先点击人员再办理业务也不会发生。
 
其次，成熟的测试人员及时无法再现BUG，也能准确的描述出BUG发生之前几个步骤的操作方法，测试用例情况。这些对开发人员分析BUG原因很重要。所谓的BUG发现环境。

呵呵，看来我不是成熟的测试人员。手工测试，比较熟练的时候，和打字可以说差不多，应该进行到哪里，心中是有数的，但让我完全从头到尾的重复，不容易呀。写测试缺陷报告单的时候，也只是说明操作步骤和发生的现象。其实无法重现的问题，既然说“无法重现”，也就是测试人员已经对这个现象进行了多次的验证，一般从程序外部来说，测试人员的操作比程序员要熟练的。
 
最后，我不同意测试人员不假思索把发现的“问题”直接推给编码人员的做法。毕竟是大家合作，目标是一致的。测试人员总是处在BUG发生的第一现场，应该帮助分析出现问题的原因。确认是不是自己的此时Miss。
 
测试人员提交任何一个问题，都会经过反复的验证，如果容易重现，早就提出来了。绝对不是在推脱责任，还是那句话，对程序的结构，做的人当然比不做的人要清楚。另外，除非程序员询问，否则我不会给程序员提出修改分析和建议！！测试人员的任务是发现问题，解决问题是程序员的事情。这么做可能会影响程序员思考问题的思路；而且测试人员做的多了，程序员不但不感激，可能反而会反感（好像程序员对测试人员有好印象的不多）。

再说两个我这两天遇到的问题。第一个就是我们的程序有一个锁定数据的功能。锁定后，在其它的业务，此数据将不能再使用。我当时发现这个功能无效，而且经过了几次的验证都不行，我当然就提出了。但是程序员那里说此功能好使，我再验证的时候，就没有问题了，这个问题当时可以重现（但是我不可能遇到问题就拉程序员来看吧），后来却没有了，只能放在那里，最后关闭掉。第二个就是在一个界面中，录入有顺序要求，必须先选择一个ListBox（必填）再进行Edit的录入，但一次操作我没有选择 ListBox就录入的Edit，也正常保存了。后来无论我怎么操作此问题都没有出现（不够成熟呀），我就放弃了，也没有提交记录（为了避免麻烦）。
 
测试人员的时间是有限的，进度给的都很少，一般连用例都没有时间写，还要去花很多时间验证“无法重现”的问题？反正10分钟如果试验不出来，我就会放弃。严重的就提交，不影响的就当不知道。
 
下面是其它一些人的观点：
doublefalse(散诸怀抱)：如果不能重现的bug确实比较麻烦，但最好在测试过程中注意干净环境、正确的操作、相同的数据源，只要真的有问题，一定能否复现的。呵呵，多试试！！！我们以前一直有客户反映入库的数据经常有无关数据，但在家里测试没有问题，后来才发现是汉字编码错位，这样同样的字，错位后就变成另外的东西了。
 
liuxiaoyuzhou(蟀哥)：遇到过同样的问题!主要是记住BUG出现的环境!测试的时候这是关键!在我们这里不能从现的BUG,是测试人员的工作不到位!我们这里程序员比测试人员说话有力度!郁闷呀!
 
ericzhangali(另一个空间)：首先一定要提交bug；其次不要企图RD一定去解这个bug；某些时候还得关闭这个bug。如果RD认为是测试错误，（不明白什么叫测试错误，是不是说他从测时要告诉你千万不要怎么怎么做，否则后果自负啊，）那也没什么办法，如果沟通解决不了，爱咋认为就咋认为吧。
 
darkcat_c(错了重来)：没有bug是不可以重现的，bug本事是建立在标准的规程上所出现的异常，如果你按test case步骤做的话不太可能出现此类bug。作为测试人员一定要具备良好的记忆能力，一旦出现一些不知如何产生的bug，至少你要知道刚才你大致进行了那些操作。良好的分析能力，尽管你只是测试，但你应该全面的了解程序的架构，和一些重要的内部细节，不然你这个测试就是不合格的。定位bug是开发的事情，而重现一个bug是测试的本职工作，不要把所有的事情推给开发，不然你的确比开发要低一等。（编者按：这种话，不愿意去辩驳，标准开发人员的看法，也许应该让他们也来做做测试）

liyan_1014(雁子)：我觉得应该是这么处理：

1、一定提交bug，必须由负责bug的tester详细描述测试操作步骤，bug发生的症状，并将bug发生的具体环境也描述清楚；这样对于再次重现也有一定的参考性。

2、测试和开发之间是需要良好沟通的，如果得到的回复是操作错误，那么请开发人员解释，为什么会允许存在操作错误，一般来说，对于错误控制，开发那边应该能很好的把握。

3、沟通方面是需要方式的，开发人员对于自己完成的程序有一种满足感，一般来说是不允许别人来破坏他的这种感觉，如果沟通的时候尽可能是一种建议的形式，让开发人员自己指出自己的程序缺陷，这样对于开发人员来说是可以接受。

以上仅是个人工作中的经验，呵呵~~~~

每个Oracle用户都有一个名字和口令,并拥有一些由其创建的表、视图和其他资源。Oracle角色（role）就是一组权限（privilege）(或者是每个用户根据其状态和条件所需的访问类型)。用户可以给角色授予或赋予指定的权限，然后将角色赋给相应的用户。一个用户也可以直接给其他用户授权。

    数据库系统权限（Database System Privilege）允许用户执行特定的命令集。例如，CREATE TABLE权限允许用户创建表，GRANT ANY PRIVILEGE 权限允许用户授予任何系统权限。

    数据库对象权限（Database Object Privilege）使得用户能够对各个对象进行某些操作。例如DELETE权限允许用户删除表或视图的行，SELECT权限允许用户通过select从表、视图、序列（sequences）或快照 （snapshots）中查询信息。

一、创建用户

   Oracle内部有两个建好的用户：SYSTEM和SYS。用户可直接登录到SYSTEM用户以创建其他用户，因为SYSTEM具有创建别的用户的权限。在安装Oracle时，用户或系统管理员首先可以为自己建立一个用户。例如：

    create user user01 identified by u01;

    该命令还可以用来设置其他权限，详细情况参见自学资料。要改变一个口令，可以使用alter user命令：

    alter user user01 identified by usr01;

    现在user01的口令已由“u01”改为“usr01”。

    除了alter user命令以外，用户还可以使用password命令。如果使用password命令，用户输入的新口令将不在屏幕上显示。有dba特权的用户可以通过password命令改变任何其他用户的口令；其他用户只能改变自己的口令。

    当用户输入password命令时，系统将提示用户输入旧口令和新口令，如下所示：

    password

    Changing password for user01

    Old password:

    New password:

    Retype new password:

    当成功地修改了口令时，用户会得到如下的反馈：

    Password changed

二、删除用户

    删除用户，可以使用drop user命令，如下所示：

    drop user user01;

   如果用户拥有对象，则不能直接删除，否则将返回一个错误值。指定关键字CASCADE，可删除用户所有的对象，然后再删除用户。下面的例子用来删除用户与其对象：

    drop user user01 CASCADE;

三、3种标准角色

    Qracle为了兼容以前的版本，提供了三种标准的角色（role）：CONNECT、RESOURCE和DBA。

    1. CONNECT Role(连接角色)

    临时用户，特别是那些不需要建表的用户，通常只赋予他们CONNECTrole。CONNECT是使用Oracle的简单权限，这种权限只有在对其他用户的表有访问权时，包括select、insert、update和delete等，才会变得有意义。拥有CONNECT role的用户还能够创建表、视图、序列（sequence）、簇（cluster）、同义词（synonym ）、会话（session）和与其他数据库的链（link）。

    2. RESOURCE Role(资源角色)

    更可靠和正式的数据库用户可以授予RESOURCE role。RESOURCE提供给用户另外的权限以创建他们自己的表、序列、过程（procedure）、触发器（trigger）、索引（index）和簇（cluster）。

    3. DBA Role(数据库管理员角色)

    DBA role拥有所有的系统权限----包括无限制的空间限额和给其他用户授予各种权限的能力。SYSTEM由DBA用户拥有。下面介绍一些DBA经常使用的典型权限。

   （1）grant（授权）命令

    下面对刚才创建的用户user01授权，命令如下：

    grant connect, resource to user01;

   （2）revoke（撤消）权限

    已授予的权限可以撤消。例如撤消（1）中的授权，命令如下：

    revoke connect, resource from user01;

    一个具有DBA角色的用户可以撤消任何别的用户甚至别的DBA的CONNECT、RESOURCE 和DBA的其他权限。当然，这样是很危险的，因此，除非真正需要，DBA权限不应随便授予那些不是很重要的一般用户。

    撤消一个用户的所有权限，并不意味着从Oracle中删除了这个用户，也不会破坏用户创建的任何表；只是简单禁止其对这些表的访问。其他要访问这些表的用户可以象以前那样地访问这些表。

四、创建角色

   除了前面讲到的三种系统角色----CONNECT、RESOURCE和DBA，用户还可以在Oracle创建自己的role。用户创建的role可以由表或系统权限或两者的组合构成。为了创建role，用户必须具有CREATE ROLE系统权限。下面给出一个create role命令的实例：

    create role STUDENT;

    这条命令创建了一个名为STUDENT的role。

    一旦创建了一个role，用户就可以给他授权。给role授权的grant命令的语法与对对用户的语法相同。在给role授权时，在grant命令的to子句中要使用role的名称，如下所示：

    grant select on CLASS to STUDENT;

   现在，拥有STUDENT角色的所有用户都具有对CLASS表的select权限。

五、删除角色

   要删除角色，可以使用drop role命令，如下所示：

   drop role STUDENT;

   指定的role连同与之相关的权限将从数据库中全部删除。

一.角色以及入口：

角色：系统管理员，开发人员

入口：服务管理

二.页面元素检查：

对页面初始化的检查,即页面打开后,对页面不做任何操作时的元素检查。（破页；js错；demo对比等）

1、查询条件：

   服务名称：文本输入框，默认为空。

   服务类型：下拉列表选择，默认为"请选择"。

   服务代码：文本输入框，默认为空。

   业务类型：下拉列表选择，默认为"请选择"。

   审核标志：下拉列表选择，默认为"请选择"。

   开始时间：通过控件选择，时间范围。

   结束时间：通过控件选择，时间范围。

2、查询结果列表：

   搜索结果显示字段为：选择，服务名称，服务类型，服务代码， 审核标志， 是否邮件报警，是否短信报警，开始时间，结束时间，备注。

   默认结果列表无数据。

3. 翻页显示格式

4. 控件名称

   该页面包括如下控件名称：查询，重置，新增，修改，删除，审核，上一页，下一页。

三.页面控件组合的功能矩阵：

1. 日期控件

  1）开始时间：选择起始时间后，联动显示出结束时间选择，结束时间小于起始时间日期的日不能选择。

  2）结束时间：选择起始时间后，联动显示出结束时间选择，结束时间小于起始时间日期的日不能选择。。

2. 单条件查询

     1）服务名称支持模糊查询。

     2）分发类型，审核标志默认查询，查询到全部未删除的数据记录。

     3）以开始时间范围进行查询，查询到开始时间为所选择范围内未删除的数据记录，如果只选择起始时间，不选择结束时间，则默认结束时间为当前时间，

     如果只选择结束时间，不选择起始时间，则默认起始时间为系统最早数据的开始时间。

     4）以结束时间范围进行查询，查询到开始时间为所选择范围内的未删除的数据记录，如果只选择起始时间，不选择结束时间，则默认结束时间为当前时间，

     如果只选择结束时间，不选择起始时间，则默认起始时间为系统最早数据的开始时间。

3. 组合条件查询

     1）默认条件查询：查询出全部的未删除的数据记录。

     2）全空条件查询：查询出全部的未删除的数据记录。

     3）全选条件查询：一次只能查询出一条数据记录。

4. 重置按钮

     1）输入查询条件，点击重置按钮，查询条件返回默认状态。

5. 新增按钮

     1）点击新增按钮，进入新增服务页面。

6. 修改按钮

     1）进入服务查询页面，查询到服务数据，不选择任何一条数据，点击"修改"按钮，系统给出相应提示信息。

     2）以非系统管理员身份登陆系统，进入服务查询页面，查询到服务数据，选择一条审核状态为"已审核"的服务，点击"修改"按钮，系统给出不能修改的提示信息。

     3）以系统管理员身份登陆系统，进入服务查询页面，查询到服务数据，选择一条审核状态为"已审核"的服务，点击"修改"按钮，系统给出相应提示，但是可以进入编辑页面。

7. 删除按钮

     1）进入服务查询页面，查询到服务数据，不选择任何一条数据，点击"删除"按钮，系统给出相应提示信息。

     2）以非系统管理员身份登陆系统，进入服务查询页面，查询到服务数据，选择一条审核状态为"已审核"的服务，点击"删除"按钮，系统给出不能删除的提示信息。

     3）以系统管理员身份登陆系统，进入服务查询页面，查询到服务数据，选择一条审核状态为"已审核"的服务，点击"删除"按钮，系统给出相应提示，如果确定删除，则删除成功。

8.审核按钮

     进入服务审核页面，查询到服务数据，选择一条服务数据记录，点击[详情]按钮，弹出新窗口显示出该数据详细的信息内容。

     审核页面内容：

     服务基本信息：服务名、服务类型、服务代码、分发业务类型、开始时间、结束时间、是否邮件报警、否短信报警。

     分发步骤信息：步骤序号、分发步骤名、步骤类型、SQL名、SQL详情。

                  若一个步骤有多个固化SQL，则显示多条记录。

                  选中分发步骤中的一条记录，则SQL详情中显示该SQL名对应的SQL信息。

四.查询结果的校验：

1、查询无结果：右下角有 ：not result to display的提示信息，结果显示栏无数据结果。

2、有结果时检查：

   1）所有结果数据与数据库是否匹配，右下角显示查询结果数据是否和数据库匹配，用sql核对。

   2）结果中每个字段值与数据库某个字段值匹配，且表示形式符合需求。

   3）翻页、排序、链接显示检查。

   4）选择数据，一次只能选择一条数据。

五.用例划分说明：

1. 单条件查询

2. 按钮功能检查

3. 页面检查

4. 组合条件查询

5.  翻页检查

水因地而制行，兵因敌而制胜——测试感悟（针对手动、黑盒）

北大方正技术研究院 李守亮

1999年6月

编者按：这是一篇好文章，不在于他的文笔，而在于他的用"心"工作，用心总结。是他的工作经验和心路历程的记录，值得大家学习。

一直以来，总想写一写关于测试方面的文章。今天，真的接到这个题目时，却欲言又止，迟迟不能落笔。在这里，我也只将自己的实际经验介绍给大家，抛砖引玉，和大家共同探讨。

刚开始做测试的同事会有一种感觉，认为测试实际上是在充当这个产品的第一用户。也有人认为，测试其实很简单，没有什么技术可言。

其实，测试说易也易，因为进入门槛低；说难也难，因为测深测精不简单。黑盒测试很讲究策略，测试也是一门学问。

初涉测试的心路历程

        对测试的认识，每个测试人员都有一个过程。我对测试的认识，在每个阶段各不相同，其中也走了不少弯路。在此，我用第三人称把自己对测试工作的认识过程写出来，希望后来的同事能从中得到启发。

第一阶段学习+验证

对于新来的同事，刚刚涉及测试，往往踏不下心来。感觉测试是件没完没了地事情，并且单调重复、枯燥乏味，没有激情、没有成就感。这是很正常的现象，刚进入一个新的岗位，总有一个适应过程。

在这一阶段，新员工需要做的事情是，先学会使用所测的软件，熟悉他的每一个功能，弄清楚每一个功能的正确效果应该是什么？然后才开始尝试着去找一些肤浅的问题。这一阶段的感觉是："测试实际上就是验证产品每个功能的有效性"。新员工这一阶段虽然不太出成绩，但却很重要，因为这是以后工作的基础。

第二阶段与开发对立的误区

   当熟悉了所测产品的功能，并且找到测试的感觉后，就开始较深入地测试了。

在这一阶段，新员工会逐渐发现一些严重的BUG。当看到自己发现的问题被解决后，才真正感觉到自己在参与产品的生产。渐渐地，渐渐地，就会感觉到测试其实也挺有趣。尤其是发现一些死机或特别严重的错误时，有时会兴奋上几个小时。这是他进入状态的必然过程。

此时，他对测试的认识是："测试，就是要找出产品的缺陷，是证明当前产品不可用的一种行为"。这一阶段非常值得注意！很多软件公司常说："开发和测试的行为是对立和矛盾的"，这实际上是测试工作的误区。

第三阶段与开发主动配合

   随着测试经验的积累，对工作的认识也逐步深入。最后，他会发现，开发和测试之间，本质上是一个合作的过程，目标本是一致的。都是为了尽量减少发布产品中的错误，达到用户可接受的程度。于是，他会更多地站在用户角度考虑问题，测试的目的也越来越明确，工作也越来越主动。

第四阶段责任感+验证

   当经历了产品的几个生命周期之后，从不断的需求、开发、维护、升级循环过程中，逐渐认识到，测试实际上是降低产品风险的一种行为。逐步认识到，测试介入的环节越早，风险也就越小。

在和最终用户多次打交道，亲身体验用户的心情之后，油然而生出一种强烈的责任感，对测试的理解也随之升华为一种产品意识：测试工作和研发工作，实际上是一种荣辱与共的关系，取得的成绩和造成的失误，其荣誉和责任是同等的。此时，当他发现一个致命的错误或缺陷时，第二阶段的那种兴奋也许只会存在3秒钟。此时的他，更多考虑的是怎样帮助研发组尽快地把该问题解决掉。在这一阶段，测试工作中更注重产品的实用性和易用性。

   从学习阶段对产品的验证，到与研发的对立，到主动地和研发配合，到一种责任感使命感自发地对功能的验证，这是一个高级测试人员所必然要经历的一个心路历程。  

测试中的几种思维方式

   测试能否出成绩？以及测试工作的优劣，与个人的素质和修养有关。

测试工作说易也易，只要认真、负责，就能做出一些成绩。但说难也难，测试讲究很多方法和策略，要测的精，问题定位的及时准确，规律找的准确有效，那是需要下一番功夫的。在此，我把测试中常用的几种思维方式共享如下：  

正向思维  

         在测试一个产品之前，需要做的重要事情是，熟读产品的设计文档，详细了解每个功能的正确效果。然后针对每个模块，顺着程序员的思路，逐个验证，以验证测试功能的有效性。这是以后深入测试的基础，也是做自动测试的前提。

         搞清楚每个模块是干什么的，弄清楚正确的效果，才知道什么是错误的。这是非常关键的一个环节，如果在这方面不下功夫，也就很难测试出有价值的BUG。因为，很明显的错误结果可能就在你眼前大摇大摆地经过，而你却认为这是正确的！我就曾经一度陷入这一误区，好在很快地补上了这一课。  

逆向思维  

         关于"逆向思维"，我有两种解释，一是针对开发人员。

开发人员在调试或自测时，总爱顺着已有的思路进行。所以，在很多情况下容易忽略自己所犯的错误，例如边缘条件检查，异常处理等等。所谓当局者迷，旁观者清，是因为你可以跳出他的思维定式，从另外的角度来思考问题。所以，只要你肯动脑筋，不按他的逻辑进行检测，就一定能找出许多破绽。  

关于"逆向思维"的第二种解释，是针对具体问题。

当发生严重问题时，首先要保护好现场，然后努力地回忆，努力地理清思路。要善于从错误现象的最后一步往前倒推。例如死机问题，仅一个现象并不能说明问题，关键要找出它的规律。规律有时是最后一步操作导致，而有时则是前几十步操作的累加，这需要我们追忆刚才的几十步操作，并大胆怀疑其中的疑点，有目的的undo、redo。这一招叫顺藤摸瓜，抓住规律的尾巴，从最后一步开始。  

跳跃性思维  

         我也称它为联动思维。

有时，一个问题表现出来的现象和问题的本质会差着十万八千里，这类问题的规律也极难准确地捕捉到。处理这类问题，需要有扎实的测试基本功，并对产品非常地熟悉，才能把表面上毫不相关，却有着千丝万缕关系的孤立的两点联系起来；才能从一处错误得到启示，联想到其他模块也可能存在类似的问题......  

关于测试技巧  

黑盒测试，尤其是手工黑盒测试的业绩，有七成决定于个人因素。

测试需要有高度的责任心和使命感，要有主人翁精神。任何工作只有敬业才能做出成绩，工作主动了，自然会得到回报。  

在很多情况下，问题的现象出现了，但规律却不明显。当问题提交后，在开发那里却死活不能重现，这种情况是很尴尬和无奈的。所以，作为一个出色的测试工程师，仅仅捕获到问题的现象是远远不够的，还要找到其规律，甚至弄懂它更深层次的原因。

遇到这类问题怎么办？很多人可能就此放弃了，因为说他是"无规律或不能重现事件"。在我看来，这种说法是错误的。我认为，一定要树立起一个观念，那就是："任何错误的出现，都绝不是偶然的。每个错误现象背后都隐含着一个必然的规律，不管是肤浅的，还是深奥的。"而测试的目的，就是要把这个规律挖出来。因为，规律总结得越准确，对问题的定位和解决帮助就越大。  

         做好测试工作必须要做到几条：首先，要努力培养起对测试的兴趣；要培养对所测产品的感情，要像对待自己孩子一样去热爱它，呵护它。其次，要胆大并心细。要有游走于高山峡谷边缘的那种"如临深渊，如履薄冰"的胆量和谨慎。要敢于怀疑，大胆假设而小心求证。再次，要有耐心，戒骄戒躁，心要安静。  

如果说测试有技巧的话，也仅占到三成：

         1、对待问题要锲而不舍，并善于总结经验。

         举一个案例，对于"方正飞腾（报社专用排版软件）自动勾边死机问题"规律的发现，我现在还记忆犹新。我1997年刚接触这款软件时就遇到了该问题，但问题变化无常，当时找不到一点儿规律：有时，在关键位置点一下鼠标就死，有时点100多次才死，有时怎么点都不会死。该问题整整困扰了我一年，直到有一天，我盯着屏幕发呆，发现鼠标变成了漏斗，我随便点了一下<调整>按钮，程序立刻死机。当时灵机一动，莫非跟"自动存盘"有关？判断是正确的！一年来的谜终于被解开了，而受此启发，后来遇到"非法字体窗口"、"自动翻页"、以及"删除表格"所引发的死机，不到1秒的时间，我就准确定位与自动存盘有关。  

         对于疑难问题，不妨先放他一放，过几天再去想，说不定就会有新思路冒出来，有新灵感被激发出来。对于每一个解决的疑难问题，都要认真分析它的原因，总结定位经验，并推演联想到其他模块。测试过程是一个循序渐进的过程，是一个经验积累的过程。以一年的摸索换来若干个一秒钟的思索，值！还有很多典型案例，限于篇幅，不便罗列。  

         2、善于推理，善于运用逆向思维。善于换位思考，变换角色对待问题；

         3、善于和别人共享经验，站在别人已有的思路上进一步深入，多动脑筋，多动手。

         4、简化问题规律的步骤，弄清楚问题产生的原因，总结程序员的教训，对类似问题可以触类旁通。

         5、不断地怀疑，不断地推翻怀疑。突破跳出思维定式，大胆假设，小心求证。  

将军围猎  

曾经在文字所和测试中心流传一句话："软件里的bug如同海绵里的水，要想挤总会有的"。旧bug的修改往往会引发新bug的产生，所谓"按下葫芦起来瓢"。  

如何培养测试人员的对测试工作的兴趣呢？不妨把bug比作藏匿在深山丛林中的猎物，把自己比作围猎的将军。程序中的bug变化莫测，要有将军指挥作战的气度，怎样更快更准更有效地定位它们，捕获住它们？围追堵截之中，尽显英雄本色。  

兵法上说，水因地而制行，兵因敌而制胜。兵无常势，无恒形，能与敌变化而取制者，谓之神。仅仅通过黑盒测试，你就能知道程序员做了什么改动？怎样做的改动？还存在什么缺陷？并快速准确地把它定位出来。若能达到这种境界，让你的思维能力受到如此的锻炼和考验，难道还不会有成就感么？  

当你全身心地投入在测试中，你会感觉到测试，实际上是一场智力游戏。所谓"气痴者技精"，因为一进入状态，坐下来就会忘记时间的流逝。

工作快两年了，两年中大部分是跟着项目在跑，眼袋深了，人老了，人也变老了。有点迷茫，有点郁闷。下面是我老大给我们的一点忠告，记下来，自己好慢慢品尝。

无论做哪一行，工作一段时间后，都会感觉迷茫。主要的原因在于，在工作一定时间后，对工作方法和技术已经比较熟悉，工作已经不像当年刚入行时，具有新意和创新性，更多的可能是重复繁琐的工作，如果看到同学朋友，有了更好的发展，往往就会感到迷茫和郁闷，往往就怀疑自己当初的选择，甚至自我的感觉就像是被困在一个木桶里，动弹不得的，但是桶里面却又有很多飞虫不断地骚扰，心中虽有鸿心壮志，却总是一无所展。所以，此时此刻，人就会感觉郁闷，迷茫，麻木，感觉一身抱负没得舒展，更加郁闷的是，自己有什么抱负，也搞不清楚。人就是这样一种动物，当看到不光明或者看到不路的尽头的时候，往往就失去了动力。
      这种情况，大体上也不是现在才有的，大体上几千年前就有了，不信，你读读那些唐诗宋词，大多也会体味得到这种感觉。这也就是为什么，你读那些诗词的时候，为什么会有同感的原因了。这种情况，也不是只有你遇到，大体上所有人都遇到。这种情况，也不是你现在没有，以后就不会有，这个跟你当时的需求有关，如果你需要的东西，你一直拿不到，你肯定会感觉痛苦和迷茫，而人的欲望是无穷的，不是你想要什么就能得到什么的，所以郁闷的人自然就不少。
      为什么会有这种现象？其实，无论做什么或者学习什么，到了一程度后，就会遇到发展的瓶颈。就如练武功一样，练的境界越高，遇到的困难就越大，这就是为什么，高手总是极少的，越高的手越少。说回来，我们职业发展，如果你工作一段时间，感觉迷茫和郁闷，一方面说明你有上进心，一方面说明，你不知道如何处理遇到的情况，如何调整自己。我觉得，首先，最重要的是不能遇到瓶颈就轻易选择放弃，或者怀疑自己的选择。换一行后，工作两三年后，会遇到同样的问题的，同样会遇到发展的瓶颈，如果跨不过去，永远会觉得自己前面有道坎。不断的换行，不断地从头开始，只要跨不过那道坎，终究是一无是处的。其次，不要跟别人比，一般情况下，都是你看我好我看你好！因为你不知道别人的难处，只看到人家好的。这样越比较，自己就越痛苦。还要是做好自己，踏实地一步一步前进，机会总是留给有准备的人，所谓十年河东，十年河西，平淡中要做出不平淡的事情来，做好积累。我们需要做好坚持和忍耐。
      再说回我们，我感觉，目前我们大体会有以下几个方面，让我们感觉迷茫和痛苦的。
第一、测试人员的缺口很大，按道理应该是有发展潜力的。可能为什么我感觉不到？
第二、做测试两年多了，为什么还在从事简单重复的测试工作？难道我没的进步？
第三、我的优势在哪里？怎么样才能得到晋升或者加薪，怎么样才能得到别人尊重？
第四、有没有更轻松又能赚到更多钱或者有更好地位的工作，我做测试是不是亏了？
第五、同学中或者朋友中，有人已经取得成功，可是我为什么不能像他们那样？
      目前，随着国内企业对软件质量的重视，测试人员的缺口很大。就目前的人员结构来看，是两头小中间大，高层次的测试人才奇缺。目前高层次的测试人员，月薪一万以上，已经不稀奇。所以说，行业的需求是有的，关键是看自己如何提高自己技能。
      前几年，听了一个《成功学》讲座，感觉挺受启发的。一个人想富有，不能光想着钱，只想钱，钱是不会到你口袋的，应该想想，如何能让你成为某方面不可缺少的人，也就是说，要让组织你对有依赖，只有你成为组织中不可替代的人，你的收入自然就会不断地增长，自然你就会得到别人的尊重，因为他 需要你，你能给他们带来利益。当年，我的想法也很简单，在保证完成本职工作的基础上，我想成为性能测试最牛的人。于是我在业余时间，放了大量的精力在上面。通过很多项目的试验和改进，我自认为，这方面，我的水平还是可以的。其实，不断地做项目，对改进和验证我的工作方法和思路起了很大的作用。在每完成一个项目，我便会进行自我的总结，想想怎么样能更好地做好项目。我的做法很简单，每做完一个项目，我便会把OSSP中的过程和一些理论书再看一遍，看完后，你会发现工作中很多的不足，应该是如何做更好。
      还有一点要说的是，尽量自己独立地去负责一个项目。这样便能把自己的想法付之实现，通过不断的实践和改进，就能积累很多做项目的经验和具体的实施办法、还有技术。当然，你需要把你的想法，在实施前跟领导探讨一下。虽然独立负责一个项目，有时候会比较辛苦，但是，往往就是你建立别人对你的信任的时候。如果你做到了，组织对你的依赖度就会越来越高，你就会变得越来越重要，你就能上一个台阶。
     记住：独立地做事，通过实践来验证和改进你的工作，多花时间研究。这些很重要。

     希望各位朋友也能留下你的意见和建议，谢谢！

1。如何测试电脑关机功能

手工关机：1 点程序中的关机；2 在任务管理器中利用关机功能；

定时关机：写一些关机的批处理命令

硬件关机：1 电脑断电；2按开关机按钮

2。如何测试QQ传输文件功能

1 文件类型；2 文件大小；3 文件路径（是否支持比较深的路径）；4 是否在文件传送中可以取消；5 文件是否支持断点续传；6 是否能够发送，接收，拒绝传送

以上是在别人的基础上归纳了1下，希望有人补充说明