-
一个软件测试工程师的工作心得(转)
2008-08-05 23:17:24
写这篇文章主要有两个目的。
1、 对自己这一年零八个月的工作进行回顾和总结，把第一份工作的记忆都写下来；
2、 自己做了一年多的软件测试工程师，对软件测试工作算是有一定程度的了解，希望与大家分享我的感受和经历。
先介绍一下我的背景：通信类院校05年毕业、本科、计算机专业，毕业后进入一家大型通信设备商工作，任职软件测试工程师。
一、T项目执行
05年7月13日入部门，此时才知道自己被分配到了测试部。部门主管把我领走后，就把我交给了导师。
入部门的头几天，主要熟悉公司的工作环境，认识部门同事，了解产品知识。由于我们是做传输设备的，所以当时学习的产品知识主要以SDH原理为主，包括SDH的帧结构、网络的保护和倒换等。
下面介绍一下我所做的项目。
项目名称：T软件
项目概况：该项目是在PC和Sun工作站上开发的软件，属于CS结构。Client端用Java开发(开始使用JDK1.3，后来改用JDK1.4)，实现跨平台；Server端用C++开发，使用ACE实现跨平台（Windows和Unix）。
人力投入：开发好像是9人，测试3人。（我来的时候是产品的第2个版本，人力投入大概如此）
我入部门几天后，T项目就进入了测试阶段。我的任务就是执行分配给我的测试用例。当时我只知道根据测试用例描述的内容，去点鼠标，如果发现程序出现错误或异常，就填写问题单。我就这样没有任何思考的按着测试用例点了3个月的鼠标 : )
现在想起当初的测试工作，实在有太多的不足，和待改进点。
1、 测试用例。对于一个软件的测试来讲，测试用例是至关重要的。测试用例要覆盖所有测试规格，而且测试用例要易于理解、易于执行，简单的讲就是要描述的规范。而当时我们的测试用例却是一团糟，最糟糕的是用例的质量很差，使用这些测试用例，根本无法保证产品质量。测试用例的预置条件、操作步骤、预期结果的描述也是乱糟糟的，而且用于存储测试用例的Excel表格设计的很差，界面很不友好，从一定程度上降低了测试效率。
2、 产品知识。T软件虽然是在PC和工作站上运行的，但是开发T软件的目的是为产品服务的，所以我们必须具备产品知识，才能更好的对T软件进行测试。恰巧当时包括我导师在内的3个人，都不太了解产品，所以就造成我们无法判断某些测试用例是否验证通过。从而导致了与开发人员的多次争吵。3、 软件测试的重点不明确。软件测试是软件工程中的一项重要活动，它尽可能发现程序中存在的缺陷，保证程序的质量。但软件作为一种商业品，有它的发布时限，老板说这个软件要1月份发布，你总不能测到12月份再给他发布吧。当时我们在一些小问题上与开发人员纠缠过多，而很多重点却没有得到重视，一些严重问题暴露的比较晚，导致测试时间延了又延，版本测了一个又一个，想起那些日子，只能如此描述：“累并痛苦着”。 : (
4、 测试流程的把握。7月份中旬，T项目从开发部转到测试部，进入了测试阶段，实际当时的产品质量并不能达到转测试的标准，而我们却让他们通过了转测试，结果就给我们自己带来了巨大的痛苦。而且后续的几个版本也如此，我们是测了一轮又一轮，测的我们都要绝望了。回头想一想，T软件还真的是我们测出来的，而不是开发写出来的 : )
5、 缺少针对性测试。软件也可以分很多种，不同的软件有不同的特点，自然就需要针对性的测试了，譬如GUI的软件与嵌入式软件的测试方法肯定有很大不同。最初我们在做T项目测试时，就缺少针对性方法。有两个教训让我们刻骨铭心：1、界面测试，T软件发布后没多久，其他组同事就发现某界面一个按钮的单词拼写错误——“rollback”被写成“roolback”；2、效率测试，软件测试到后期才发现T软件在实际环境中运行效率很低，根本无法满足达实际应用的需要。从那以后我们就准备了专门针对T软件的测试项目，包括：界面测试、效率测试、资料测试、稳定性测试等。
6、 沟通问题。自从工作开始，开发人员和测试人员的争吵从来就没有停止过。最初是什么问题都吵，很多没有意义的争吵甚至非理性的争吵，庆幸的是现在的争吵大多是有针对性的、理性的。个人觉得以前无为争吵过多的原因是：开发人员、测试人员的工作技能和职业素养都比较欠缺。吵了大半年后，人员提升了工作技能和职业素养后，吵架都吵的比较有默契了。当然最重要的是开发人员和测试人员的目标要一致：保证产品的质量，满足客户需求。
二、自动化测试
06年过完年后，我被主管派到一个大组去学习自动化测试技术。这个测试组是个比较大的测试组，总共有几十号人，其中有很多牛人。他们的自动化测试框架就是由几个牛人耗时1年多开发出来的。到现在，他们的自动化用例覆盖率约50％，应用率好像有70％，总之这个自动化测试框架还是满牛X的，不过就是整个框架实现太复杂了，涉及的编程脚本就用了三种 : (
下面简单介绍一下该GUI自动化测试框架。
测试工具：IBM Rational Robot
自动化测试技术：第三代自动化测试框架，叫什么DDE，具体什么意思已经记不住了 : )
测试脚本：Robot中使用的是sqabasic脚本（基于basic的一种脚本），另外还使用了TCL、COM组建等，并自行开发了一个抓包工具用于自动化测试。还有我们测试的产品界面是使用Java开发的，如果要让Robot能够正常识别界面，还需涉及到Java编程。呵呵，实现上可是够复杂的 : (
学习自动化的头一个星期，我只是学习该测试组的产品知识，学习如何使用自动化测试。后面的几个星期就开始承担自动化测试的建设任务了。想想当初自己还是满辛苦的，白天上班学习产品知识，晚上回家就对着电脑看basic脚本的语法，周末还去公司无偿加班看代码。在技术文档的选择上，我基本只看英文的，单词不懂就拿金山词霸查，实在看不懂了才会去找些中文的资料看。为什么要选择英文的呢？因为很多中国写书的人很浮躁，只想着快点把书出版了好赚钱，所以很多中文的资料质量很差。首先要贬低的就是那本谭教授的《C语言程序设计》。记得读大学时，照着谭教授的书敲程序，没多少程序能编译通过的，真是误人子弟。
当时带我学习自动化的导师姓L，他是个大忙人，有时一整天都在开会。L的师傅姓W，W是该自动化创始人之一。我呢，充其量算是徒孙一辈，呵呵。由于L太忙，而且不那么爱说话，于是乎我就只能自己对着文档看代码。
当时对我比较有用的文档就只有两篇：一篇是汇集型的chm文档，是篇比较全面的介绍，其中包括自动化框架的介绍，原理的介绍，各模块介绍，自动化执行的流程等；另外一篇则是由W写的自动化建设指导书，写的还是满不错的，在我有一定基础后，照着指导书就能完成简单的自动化建设。在我整个学习过程中，是按照以下的过程开展的：1、初步了解整个自动化和产品知识，尝试使用自动化进行测试；2、熟悉sqabasic语法；3、对着文档读代码，尝试调试脚本，跟踪到代码的最底层。
其实最好的学习方式就是实践，去做自动化建设。当有一定基础后，去完成导师交给的自动化建设任务，就是最好的学习方式。后来，我教别人的时候，也是安排实际任务给他做，然后再进行相应的引导。
在我的学习期间，有件事情让我满讨厌的。就是我必须给原部门的主管和测试组人员讲课，然后那些家伙会不停的提问，以检验我的学习效果。虽然这招很BT，但是对个人的成长还是满有利的。假设你学会了一项技能，此时你可能只在第一个层次上，如果你能够把这项技能教会别人，那么你的层次上升了一个档次。
记得当时是06年2月初去参加学习的，4月初就应急被调回原测试组了。总共不到两个月的时间，我总共完成了3个模块的自动化建设，第1个模块搞了3个多星期，第2个模块不到2个星期，第3个模块一个星期就搞完了（第3个模块算是友情支援呢，哈哈）。
4月初被调回原测试组后，就一直做救火的工作。差不多5月份的时候才正是开始做我们T项目的自动化。其实也就是把我学习的自动化框架移植过来，做T项目自动化测试。
另我比较遗憾的是，T项目的测试一直都很紧，而自动化测试并没有被推广和充分利用。直到我离职前，测试组为应付测试部自动化考核指标，才得到重视。这里我谈一下自己对自动化测试的理解。
1、 自动化测试用于提高测试效率；
2、 自动化测试可以完成一些无法手工完成的测试，例如长时间不间断的测试；
3、 自动化虽然能够发现问题，但主要是对继承的功能进行测试，保证以前的老功能。（这个跟项目有关， GUI自动化测试比较复杂，如果是嵌入式设备或芯片的自动化测试，对自动化测试的理解可能会不一样）三、开发小工具
我在自动化学习期间，表现出来的专业技能和良好的学习能力，得到了同事和主管的认可。鉴于此，在4月中旬的时候，测试组的Leader给我安排一个任务，使用Excel表格开发一个工具，用于收集和统计记录的数据。要求该工具能够代替手工计算，提升测试效率。任务完成的截至日期是五一。给我安排的时间大概为一周。
该工具的实现方式并不难，就是设计一个Excel表格，然后在里面嵌入VBA脚本，以宏的方式代替手工计算。对我来说最大的挑战就是：1、短时间内学会VBA编程；2、提取需求，设计Excel表格的格式，使该工具具有较好的易用性。
当我接到任务后，下班回家就开始到网上搜集关于VBA资料。当时我找了一个星期，都没有让我满意的文档。最终只找到一篇国人写的PDF文档，但是那篇PDF文档只是让我初步了解了VBA是个什么东东，并不能满足我的实际需求。最终，在写VBA脚本期间，我还是参考微软自带的帮助文档搞定的。（搞忘球当初是否装了MSDN）本来计划是在四月底的一个星期开展该项任务，但实际上直到4月的最后两天我才有时间。记得当时，我花了一天半的时间与我的客户——也就是我的同事，共同讨论需求，并设计Excel表格的格式，让其评审。最终写脚本花费了4月的最后一个下午，以及五一期间的三个下午的时间，总计4个下午的时间，完成该工具的开发。而且我五一期间的工作并没有申报加班，是无偿劳动啊 : (
另外，令我欣喜的是，从此我成了我们组的“牛人”，哈哈哈哈。。。。。。
其实工具开发完成后，还是有些问题，如：
1、 程序崩溃（不小心除了0，呵呵，加入异常处理就OK了）；
2、 有1/3的功能基本没有被使用（郁闷，花那么大精力。。。我的五一啊）；
3、自动生成的表格，奇丑无比（直到现在，我都没改，哈哈）。
记得当时有个做了5年以上C++的开发人员，看到我写的Excel表格，居然说“诶，这东西还满神奇的嘛”。我当时的一个感觉就是，晕，这个家伙工作效率肯定不高。
Excel还真是好用，功能强大啊！四、负责M项目测试
06年10月份，我开始独立负责M项目的测试工作。M项目是个小项目，大体情况如下：
代码量：大约10K行
开发语言：C#
软件环境：Windows PPC 2003
硬件环境：hp的PDA（具体型号忘了，反正是便宜货，大概1000块）
人力投入：开发3人，测试就我1人
M项目的测试需求分析、测试设计、测试用例编写、测试执行到测试报告，全部由我一个人搞定。
06年10月～12月中旬这段时间，主要是完成前期的测试分析与设计。12月中旬，就进入了实际的测试阶段，07年1月底，软件发布。回顾这4个月的工作，有做的好的，也有做的差的。下面对这些进行总结。
做的比较好的：
1、 测试进度把握比较好，在规定时间内，甚至提前完成了测试任务；
2、 与开发人员的沟通较好，使问题能够较顺利的解决，基本没有内耗，双方合作愉快；
3、 测试的重点把握较好，把很多严重问题，在测试前期就给暴露出来了；做的不好的，待改进的：
1、 前期的测试分析能力较弱，测试规格分析不全，测试用例编写质量不是高。到后期测试时，才发现很多规格没有覆盖到，需要补充测试用例。而且之前写的测试用例与实际测试情况，有些偏差，用例的可用性差，又花了很多时间去修改用例。
2、 前期的测试计划制定比较差，实际工作较之计划偏差过大。反正10月、11月那段时间，M项目的工作是乱七八糟的，还好关键时间点的把握还算到位。
3、 测试对象选择上疏忽，导致漏测。M程序是个工具软件，主要用于查询和设置设备的某些参数或配置。我当时只考虑到对所有支持的设备进行遍历，却未考虑到设备上所有单板的遍历。结果技术支持工程师到香港试用该工具时，发现某块叫PM1D的单板无法识别。后续，我们对大部分单板进行了遍历，还发现了很多隐藏的问题。这是一项较大的疏忽。
4、 在做内部模拟试验局测试时，对测试环境的选择有较大疏忽，导致漏测。在做内部试验局的时候，我为了偷懒只选择了3个不同设备的组网测试，而没有考虑到大规模组网情况下的测试。后来，技术支持工程师拿M软件到广州试用时，程序的某项功能就不正常了，原因就是大规模组网时，通信数据的传输是多包的，而M程序的底层函数没有对多包的情况进行处理，导致该项功能不正常。当时，在其他实验室是有类似环境的，而我却为了偷懒 : (
虽然M项目的测试有很多不足，但是总体情况良好，我对产品的质量有信心 : )五、救火
大概是06年7月份时，我们组组长跟我说，要派我到B组去学习3个星期。等我去了B组才发现自己是被派来救火的。来B组支援测试，主要是完成一项测试任务，说具体点，就是把一件事情干600多次，没任何技术含量。我当时真是郁闷坏了 : (
虽然心底是比较郁闷，但毕竟也就3个星期，想着忍忍就过去了。
具体的任务很简单：大概有80种板子，每种板子大概有8套软件，用T工具对80多块板子把8套软件都加一次，观察软件加载过程中，业务是否正常，板子加完软件后，运行是否正常。
还有一个也是其他组借调过来的新员工，跟我一起干这件事情。我600多次，他也差不多600次。还好这个家伙，心态很好，做事情也很勤奋。
最初B组给的方案是这样的：先用第1套软件把80多个板子加载一遍，再用第2套，第3套，直到第8套。
开始工作几天，我们就按这种方案执行，但按这种方案执行的效率很差。主要因为实验室常用的板子差不多只有30块，其他的板子都藏在箱子里，而且有些板子B组根本没有，需要到其他项目组去借，这样针对软件版本，对80多块板子进行轮循加载，效率就很低，因为每加一套软件，就要去寻找80多块板子。
当时，我和那个新员工都很愁，按照这种做法，这项任务3个星期根本就无法完成。B组负责带我们的两个员工，也表示比较无奈。
郁闷过的第2天一早，我就直接找B组的老大谈话，“按照你们提供的这种方案，我们在三个星期内根本无法完成任务，而且还有诸多其他困难：1、部分板子是坏的；2、某些板子实验室里根本就没有；3、对设备不熟悉。”
就这样，B组老大把组内相关骨干人员都叫过来开会，重新商讨了一套方案，并要求他们全力支持我们的工作。
开了会后，B组的人就比较支持我们的工作了，启用新的方案后，还提前了1天时间把工作完成 : )
这里我体会比较深的是：在做一份工作前，一定要弄清楚这项任务到底要做些什么、要怎么做、要做到什么程度，工作中还要定期汇报工作（基本上以日报、周报的形式，用邮件发送），如果出现了解决不了的困难，一定要向老大汇报，如果老大也解决不了，那他也不能责怪你无能 : )六、工作中的陷阱
在辞职前的几个月，有个师弟也是老乡X君，得知我做过自动化项目后，便来向我了解自动化测试相关的情况。
从与X的聊天过程中了解到，他也正在做自动化，他们组测试的产品规模比较大，不过做自动化的只有两个新人，而且是使用一种新的GUI测试工具。他在给我讲他们具体工作时，了解到他们的自动化测试非常原始，就是针对一个用例录制一套脚本，几百个测试用例，大概录制几百个脚本，根本没有对公共进行提取，更别提有什么自动化测试框架了。X君与另外一个人，在自动化方面都是新手，没有相关经验，他们不知道这样做会给后期的维护带来多大的麻烦。而且他们主管也不太懂GUI测试的自动化，只是每天要他们汇报工作进度，期望在两个月内完成那几百个脚本。
经过我细致询问后，我猜测他们做这项自动化工作，基本上是为了应付部门自动化考核而做的，而并非为了提高测试效率，保证产品质量。
我也可以体谅X君主管的难处：测试组人力本来就紧张，而部门又要考核自动化指标，他只有弄两个人来应付一下部门的考核了。
这样说来，X君和他另外一位同事就是受害者了，被安排做一件这么没意义的事情。对他们我只能表示同情了。
对于这类BT主管吩咐的没啥意义的事情，我的体会就是能推掉不做就不做，如果实在推不掉，就完全按照他的意思做，他要怎么做就怎么做，要做成什么样就做成什么样。实在搞郁闷了就老板炒鱿鱼吧。
七、其他
记得刚进公司那一阵，对我们新员工有这样那样的培训，估计转正前至少被培训了20门课吧。具体讲的都是产品知识、测试技能、编程方面的东东。那些讲课的老师水平也参差不齐，PPT写的水准也有好有坏。总体感觉就是那些培训是在浪费时间，如果自己看这些资料效果都要好很多。
在转正前，作为新员工要给部门的“老”员工讲课，讲自己所学习过的知识，然后下面的“老”员工会发狂了似的问你问题。现在我感觉这种方式真的是一种非常好的检验方法，不但检验了你的学习情况还锻炼了你讲解PPT的能力。
通过这种方式，我觉得自己在很多方面有提高：
1、 写PPT的水平。后续工作中，写PPT汇报工作，做的是又快，又漂亮。
2、 沟通能力。最初别人问我一个问题，我还没完全理解他的意图，就以自己的理解，淅沥哗啦的说了一堆别人不想知道的东东，搞得别人一头雾水。此后，别人每问我一个问题，我都会先把他的意图或意思搞搞清楚了，确认后，再以最精练的语言来回答他的问题。
3、 懂就是懂，不懂就别乱说。记得最早“老”员工问我一个我自己不是很懂的问题，我通常是按自己的理解方式，跟他胡吹一通。结果他再一细问，我就傻了。知道就知道，不知道就别乱说，这点很重要，尤其是在参加面试的时候，如果自己不是很动，别人一问你就会露馅。
写到这里，第一份工作的感受也写的差不多了。总的来说可以如此形容我这份工作：任务重、压力大、加班多，虽然公司也存在各种各样让人非常不爽的事情，但打心眼里我还是感谢它的——是它让我明白了什么是工作，锻炼了我的学习能力、抗压能力、沟通能力，培养了我的职业素养。虽然也有非常多的人在骂公司，但我希望它还是能越走越好！！！ -
软件测试面试
2008-05-19 16:41:03
前段时间公司招聘软件测试人员，虽然基本上都是招的应届毕业生，但我还是从现实以及网络上找到了一些应聘软件测试/QA的面试问题集，当然这个也都不会有标准答案的，现在只是以偶的一点理解加上网上的一些内容列举出来供有需要的XDJM们作一下参考：
1. 首先一般都是比较老套点的问题：介绍一下你的经历。
HOHO......这个问题我想谁都被问过吧，注意一下重点，不要紧张慢慢说就OK了。
2. 老套话说了就可以马上切入正题了。根据你的经验说说你对软件测试/质量保证的理解？
这个就要仁者见仁、智者见智了，也基本上都是书上的东东，如果能有一些自己独特的想法那就最好啦，呵呵 。
3. 理解完了那当然就要问一下是不是对软件测试了解啰。这就轮到问软件测试的流程是什么，你原先的公司又是怎么的流程了？
前面个问题也还是书本上的东西，一般介绍软测的书上都有，实际上国内一般的中小公司根本就达不到书上所说的那些个测试规范，测试流程也是如此，没办法，这就是现在我们整个大的测试环境，这个问题照着书上说的办就行了，后面那个知道该怎么做了吧，尽量把原来公司的测试流程言简意赅的表达出来。
4. 接着问题就可以有一大堆了，这些问题很多都是要看自己的测试经验以及对测试的理解来作答了，如：
(1) 你对SQA的职责和工作活动(如软件度量)的理解：
SQA就是独立于软件开发的项目组，通过对软件开发过程的监控，来保证软件的开发流程按照指定的CMM规程（如果有相应的CMM规程），对于不符合项及时提出建议和改进方案，必要是可以要高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入，从而减少后期软件的维护成本。ＳＱＡ主要的工作活动包括制定
SQA工作计划，参与阶段产物的评审，进行过程质量、功能配置及物理配置的审计等;对项目开发过程中产生的数据进行度量等等；
(2) 说说你对软件配置管理的理解：
项目在开发的过程中要用相应的配置管理工具对配置项（包括各个阶段的产物）进行变更控制，配置管理的使用取决于项目规模和复杂性能及风险的水平。软件的规模越大，配置管理就显得越重要。还有在配置管理中，有一个很重要的概念，那就是基线，是在一定阶段各个配置项的组合，一个基线就提供了一个正式的标准，随后的工作便基于此标准，并且只有经过授权后才能变更这个标准。配置管理工具主要有CC,VSS,CVS等，偶只用过CVS，对其它的不熟悉
(3) 怎样写测试计划和测试用例：
简单点，测试计划里应有详细的测试策略（测试方法等），合理详尽的资源安排等，至于测试用例，那是依赖于需求（包括功能与非功能需求）是否细化到功能点，是否可测试等。
(4) 说说主流的软件工程思想(如CMM，CMMI，RUP，XP，PSP，TSP等)的大致情况以及你对它们的理解：CMM:SW Capability Maturity Model 软件能力成熟度模型,其作用是用于软件过程的改进、评估及软件能力的评鉴
CMMI:Capability Maturity Model Integration 能力成熟度模型集成 CMMI融入了大部分最新的软件管理实践，同时弥补了SW-CMM模型中的缺陷
RUP:rational unified process 是软件工程化过程。它提供了在开发机构中分派任务和责任的纪律化方法.它的目标是在可预见的日程和预算前提下确保满足最终用户需求的高质量产品,个人认为：它的核心观念是开发的迭代，每个公司可以根据自身的软件开发的流程和待开发项目的特点对RUP进行适当的剪裁，制定出符
合自己的软件开发流程。
ＸＰ：extreme program，即极限编程的意思，适用于小型团队的软件开发，想上面第三个问题就可以结合原型法采用这样的开发流程。要明白测试对于xp开发的重要性，强调测试（重点是单元测试）先行的理念。编程可以明显提高代码的质量，持续集成对于快速定位问题很有好处。
PSP ,TSP 分别是个体软件过程（Personal Software Process），群组软件过程（Team Software Process）大家都知道，CMM只是告诉你怎么做但并没有告诉你如何做，所以PSP/TSP就是告诉你企业在实施CMM的过程中如何做，PSP强调建立个人技能（如何制定计划、控制质量及如何与其他人相互协作等等）而TSP着重于生产并交付高质量的软件产品（如何有效地规划和管理所面临的项目开发任务等等）
总之，单纯实施CMM，永远不能真正做到能力成熟度的升级，只有将实施CMM与实施PSP和TSP有机地结合起来，才能发挥最大的效力。因此，软件过程框架应该是CMM/PSP/TSP的有机集成。
(5) 对项目管理、白盒测试、单元测试、自动测试、性能测试、压力测试工具的了解程度和实际使用经验。(其实基本上也就是MI和Rational工具)：
这个就要看个人的了，没法说了
(6) 其它一些具体的技术知识(如各种计算机语言的了解程度、数据库等)；
5. 还有问一下你是怎样保证软件质量的，也就是说你觉得怎样才能最大限度地保证软件质量？
测试并不能够最大限度的保证软件的质量，软件的高质量是开发和设计出来的，而不是测试出来的，它不仅要通过对软件开发流程的监控，使得软件开发的各个阶段都要按照指定的规程进行，通过对各个阶段产物的评审，QA对流程的监控，对功能及配置的审计来达到开发的最优化。当然测试也是保证软件质量的一个重要方
式，是软件质量保证工程的一个重要组成部分。
6. 然后紧接着就基于目前中国的国情，大多数公司的软件项目进度紧张、人员较少、需求文档根本没有或者很不规范，你认为在这种情况下怎样保证软件的质量？(大多数公司最想知道的就是在这种困难面前你该怎么保证软件的质量，因为这些公司一般就是这种情况-----既不想投入过多又想保证质量，faint )
出现以上的情况，如果仅仅想通过测试来提高软件质量，那几乎是不可能，原因是没有足够的时间让你去测试，少而不规范的文档导致测试需求无法细化何谈足够且有针对性进行测试。所以，作为公司质量保证的你应该先后项目经理确定符合项目本身最适合的软件生命周期模型（比如RUP的剪裁，原型法）,明确项目的开发流程并督促项目组按照此流程开展工作，所有项目组成员（项目经理更加重要）都要制定出合理的工作计划，加强代码的单元测试，在客户既定的产品交付日期范围之内，进行产品的持续集成等等，如果时间允许可以再配合客户进行必要的系统功能测试。
7. 差不多了就该问一些只和软件测试相关的问题了，如：
(1) 你觉得怎样才能做一个(或者，怎样才能算一个)优秀的测试工程师？(faint，这个问题好像是必问的，答案也无非是什么要求全面的技术能力、缜密的逻辑思维、出色的沟通能力、还要有怀疑精神、幽默感、洞察力等等。啥叫优秀啊？该有的能力都有，不该有的也有，而且个个能力还都是出色的，这就是优秀，呵呵，
开玩笑的，反正这个问题差不多就这样，具体的什么要求网络上也到处都有。
(2) 还有其它的如对自己优缺点的评价、自己的职业理想、为何离开上一家公司、自己在职业生涯中印象最深的事情、能否出差和加班、能否承受压力和挑战、薪水要求、何时能到岗等等这些啥面试都要回答的问题，这个就只能自己斟琢着办了。
(3) 另外还有一个重要的问题就是语言能力啦，尤其是英语水平，这个的话每个具体的公司都有不同的要求，也就没啥好说的了。
差不多基本上就是这些了，如果有需要的可以有针对性的google一下，hoho...仅供参考!
做好软件测试的一些关键点
本文作者 未知 摘自 机电之家
1.测试人员必须经过测试基础知识和理论的相关培训。
2.测试人员必须熟悉系统功能和业务。
3.测试必须事先要有计划，而且测试方案要和整个项目计划协调好
4.必须事先编写测试用例，测试执行阶段必须根据测试用例进行
5.易用性，功能，分支，边界，性能等功能性和非功能性需要都要进行测试
6.对于复杂的流程一定要进行流程分支，组合条件分析，再进行等价类划分准备相关测试数据
7.测试设计的一个重要内容是要准备好具体的测试数据，清楚这个测试数据是测哪个场景或分支的
8.个人任务平均每三个测试用例至少应该发现一个BUG，否则只能说明测试用例质量不好
9.除了每日构建的冒烟测试可以考虑测试自动化外，其它暂时都不要考虑去自动化。
软件测试员自身素质培养
（1） 首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，我相信你一定能克服。
（2） 善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。别人认为是对的，我却认为不是
对的。
（3） 打破砂锅问到底的精神，对于只出现过一次的bug，一定找出原因，不解决誓不罢休。
（4） 保持一个良好的心情，否则可能无法把测试作好。不要把生活中的不愉快的情绪带到工作中来。
（5） 做测试时要细心，不是所有的bug都能很容易的找出，一定要细心才能找出这些bug。
（6） 灵活一些，聪明一点，多制造一些容易产生bug的例子。
（7） 在有条件的情况下，多和客户沟通，他们身上有你所需要的。
（8） 设身处地为客户着想，从他们的角度去测试系统。
（9） 不要让程序员，以“这种情况不可能发生”这句话说服你，相反，你应该去说服他，告诉他在客户心里，并不是这样的。
（10） 考虑问题要全面，结合客户的需求、业务的流程、和系统的构架，等多方面考虑问题。
（11） 提出问题不要复杂化，这一点和前面的有点矛盾，如果你是一新手，暂时不要管这一点，因为最终将有你的小组成员讨论解决。
（12） 追求完美，对于新测试员来说，努力的追求完美，这对你很好，尽管有些事无法做到，但你应该去尝试。
（13） 幽默感，能和开发小组?br /> -
用户注册和密码修改测试点
2007-09-08 16:31:57
一．用户注册
只从用户名和密码角度写了几个要考虑的测试点，如果需求中明确规定了安全问题，Email，出生日期，地址，性别等等一系列的格式和字符要求，那就都要写用例测了~
以等价类划分和边界值法来分析
1.填写符合要求的数据注册: 用户名字和密码都为最大长度 （边界值分析，取上点）
2.填写符合要求的数据注册 :用户名字和密码都为最小长度 （边界值分析，取上点）
3.填写符合要求的数据注册:用户名字和密码都是非最大和最小长度的数据（边界值分析，取内点）
4.必填项分别为空注册
5.用户名长度大于要求注册1位（边界值分析，取离点）
6.用户名长度小于要求注册1位（边界值分析，取离点）
7.密码长度大于要求注册1位（边界值分析，取离点）
8.密码长度小于要求注册1位（边界值分析，取离点）
9.用户名是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了,如含有空格，#等，看需求是否允许吧~）
10.密码是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了）
11.两次输入密码不一致(如果注册时候要输入两次密码，那么这个是必须的）
12.重新注册存在的用户
13.改变存在的用户的用户名和密码的大小写，来注册。（有的需求是区分大小写，有的不区分）
14.看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号显示
二．修改密码
当然具体情况具体分析哈~不能一概而论~
实际测试中可能只用到其中几条而已，比如银行卡密码的修改，就不用考虑英文和非法字符，更不用考虑那些ＴＡＰ之类的快捷键．
而有的需要根据需求具体分析了,比如连续出错多少次出现的提示，和一些软件修改密码要求一定时间内有一定的修改次数限制等等。1.不输入旧密码，直接改密码
2.输入错误旧密码
3.不输入确认新密码
4.不输入新密码
5.新密码和确认新密码不一致
6.新密码中有空格
7.新密码为空
8.新密码为符合要求的最多字符
9.新密码为符合要求的最少字符
10.新密码为符合要求的非最多和最少字符
11.新密码为最多字符-1
12.新密码为最少字符+1
13.新密码为最多字符+1
14.新密码为最少字符-1
15.新密码为非允许字符（如有的密码要求必须是英文和数字组成，那么要试汉字和符号等）
16.看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号
17.看密码是否区分大小写，新密码中英文小写，确认密码中英文大写．
18.新密码与旧密码一样能否修改成功．
有个朋友问我,注册的时候测试了密码长度,修改的时候为什么还要测试.
我在这里举个我亲身经历的例子,以前我玩一个游戏,叫恋爱盒子,在游戏里我把密码改成了xuewufengtian,后来怎么也上不去了.因为资料填写不全无法找回密码.后来我在一次注册过程中发现,注册的时候密码长度最长是10位,这时我灵机一动,用了原来的用户名和xuewufengt的密码就进去了. 这表明,修改密码时候的最大长度和注册及登陆的时候密码最大长度有可能是不一致的. -
测试人员面试三步曲
2007-09-08 16:29:48
第一步、投递简历
投递简历，让招聘公司发现你，一般有4种方式：
通过招聘网站搜索测试招聘信息，选择合适的公司和职位，投递简历；
通过招聘网站发布自己的简历，等待招聘公司发现并下载你的简历；
通过本公司内部招聘、内部人员推荐；
通过招聘会，现场投递简历。
以上4种招聘方式，最为常用的是1、2两种，而且结合使用，第3种的成功率最高，第4种应用很少。第1种方式是现在大多数测试朋友找工作的主要途径，目前，国内知名的人才招聘网站：中华英才网（www.chinahr.com）、51job前程无忧（www.51job.com）、卓博（www.jobcn.com）、中国国家人才网（www.newsjob.com.cn）、北京人才网（www.bjrc.com）等，相信各位想找工作的测试朋友，早已对这些网站如数家珍了。如果你想被猎头看重，那就赶快注册（更新）一下自己的简历吧，很快将会有一大堆公司给你打电话，通知你去面试，这就是第2种方式。一般说来，你在人才网上发布简历找工作的同时，猎头公司也在找你，所以说，1、2两种方式结合使用。接下来，我们再来探讨一下第3种方式。在外企以及一些大公司，为了减缓员工在从事一项工作几年之后产生的乏味情绪，特别推出一种内部招聘的方式，允许公司内部相关部门的相关人员的应聘，比如说作技术支持的要应聘作市场，作开发的要应聘作测试等等，或者在公司内部公布招聘信息，希望本公司的员工推荐符合招聘要求的人员，可以直接到公司进行面试。因为公司对内部员工相当了解，员工对招聘要求十分清楚，必然按要求搜寻符合条件的熟人进行推荐，所以，公司内部招聘、内部推荐十分容易成功。第4种招聘方式，近两年已经很少应用，因为招聘会有时间限制，还要跑到现场，在人山人海中搜寻符合自己条件的公司和职位，投递简历并进行简单面试，既费时、费力，效果也不佳，故而应用越来越少。第二步、准备面试
想要参加面试，就一定要做好面试的准备：
公司情况：
在接到面试通知时，一定要简单而客气地询问一下公司的情况， 正所谓知己知彼，百战不殆。看看公司是否有你所关注的地方，比如公司的规模、办公地点、测试组的情况等，最主要的要知道公司的主要业务，测试什么，软件还是硬件，那个行业的，问话不要多，否则对方很容易反感，最好是要来对方的公司网址，到网站上浏览一下，大体也就知道了。
穿衣戴帽：
陌生人见面，第一印象很重要，你给招聘方的第一印象，主要通过衣着来表现。我们这些测试人员，都是搞技术的IT人士，不能穿的象个新新人类，试想一下，你作为主考官，见一个身穿乞丐服、头戴鸭舌帽的人进来应聘测试工程师，你会相信他的技术吗。所以在面试时，一定要穿洁净、整齐的职业装或者夹克，或者适中的风衣。女士稍微画一点淡妆，男式记得刮胡子。头发都要梳的整齐。
言谈举止：
言谈举止要透出一股自信，让人感觉你就是很棒，什么任务都可以放心的交给你去作，你都能圆满完成。
证书、简历：
很多公司可能在通知你面试的时候，就会通知你带相关的学历证件、培训证书，如果招聘方没有通知，你可以礼貌的问一下，是否需要携带。至于你的简历，一定要多带上几份，不要以为招聘方看过你的简历，就一定有你的简历。因为也许是人事部发现了你的简历，通知测试部一同面试，或者测试部发现了你的简历，通知人事部一同面试，而面试又是在几天之后的事情，早不知把你的简历扔到哪里去了。你以为网站上有你的简历，可以直接打印，那你就错了。因为招聘负责人可能工作比较忙，比较累，应聘的人又那么多，手头没有现成的简历，随便应付一下，就打发你走了。感觉难受吧，可你改变不了人家，如果不想失去这次机会，就自己准备简历吧，需要就拿出来，不需要可以留着下次用。
语言表达：
面试的关键就是语言表达，看你是否能够很有条理的把自己的经历、知识、技能表达清楚，并且在讲的过程中，注意观察招聘方的表情，看人家是否感兴趣，如果人家皱眉头，表情不悦，就尽快结束自己的话题。因此，在面试之前，你可以自己练习练习。
知识、技能：
知识、技能是测试人员平时积累下来的宝贵财富，面试之前，你可以将其条分缕悉，以备面试时表达清楚。
英语能力：
国内企业对英语要求不是十分苛刻，只要有良好的英文文档阅读能力即可；倘若是外企或者承包外企项目的公司，对英语要求则十分严格：要求你能够用日常英语会话，能够用英语撰写测试文档，汇报测试工作。所以在学习测试知识和技能的同时，我们也要注意对英语知识的积累。
第三步、参加面试
在约定的时间、约定的地点，你最好准时出现，如果不能准时赴约，一定要提前打电话，告知对方是什么原因导致你迟到，多长时间以后能你到达约定地点。进入公司，会有接待人员招呼你坐下，通知招聘负责人接待你面试，此间接待人员会给你送上来一杯水。
1. 考试
招聘负责人给你一份试卷(一般为笔试，也有上机的，如果对英语有严格要求，还会有一份英文试卷)，规定一定的时限，到时间他来收卷。试卷的命题一般分为填空、选择、判断、逻辑推理、程序改错、简答，也有让你找bug的题，这些题给人的感觉都是在简单中透漏着怪异。如果你问为什么要有考试这一关，招聘人会告诉你，是想考察应聘者的能力。其实，不尽然，最根本是公司的质量保证体系，要求公司所有活动都得有记录，所以才出现了考试这回事。
2. 初试
初试是最关键的，几乎决定是否录用你。初试之前招聘负责人可能会寒暄几句，让你放松一下心情。招聘负责人一般有两位，一位负责测试技术，一位负责人事，招聘负责人会作自我介绍，也可能其中一位捎带介绍另一位的资历(比如留美博士)，表示这家公司很有诱惑力，连这么好的人才都吸引来了。接下来负责测试技术的会问你几个问题：
请你简单谈谈你的经历？
你在某某家公司主要作哪些工作？
测试过那些东西？
测试流程是什么？
手工测试还是自动测试？
使用过哪些测试工具？使用过Rational系列测试工具吗？
作过白盒测试吗？
作过XXX测试吗？以前接触过XXX吗？你对XXX了解到什么程度？（XXX代表招聘公司所要测试的东西）
平时使用哪些操作系统？Linux操作熟练吗？
以前作过开发吗？开发了哪些东西？使用的什么语言？
你觉得测试工程师应该具备哪些素质？
对一个测试工程师来说，什么素质最重要？
结合自己的实际工作，谈谈你对测试的理解？
为什么要离开上一家公司？
居住在哪里？离公司远不远？
有经验的招聘负责人都会简单介绍一下自己的公司（背景、主营业务、发展前景等），然后开始问问题。一般开门见山的问题是’请你简单谈谈你的经历？’，回答这个问题，只要简单的叙述你从毕业到现在都在那些公司作了那些事情即可，叙述时一定要从容、清晰而有条理，眼睛瞅着招聘负责人，观察其表情，如果有些不耐烦，要尽早结束这一话题。招聘负责人此时会大致浏览你的简历，在你叙述完自己的经历时，招聘人会就你简历的某一项问你，比如’你在某某家公司主要作什么？测试过那些东西？测试流程是什么？’，待你回答完这些之后，继而问你测试的具体细节，手工测试、自动测试、用过那些工具？是否作过白盒测试？使用过什么操作系统？熟悉那些语言？是否作过开发？如果你肯定回答这些问题，那么还要继续问具体操作，比如你答作过白盒测试，那么招聘人会问你测了哪些东西？怎么进行的？是独立进行的还是和别人一起进行的？测试出的bug 如何处理？是否作进一步的分析？……负责测试技术的问完后，就由负责人事的继续发问：
你的期望薪金是多少？税前还是税后？
一旦录用多长时间可以来上班？
你的户口在哪里？调档案是否有问题等？等你回答完毕，接下来他会告诉你：
公司是否有试用期，试用期多长时间；
试用期的薪金如何发放，其他待遇怎样处理；
如果符合初试条件，多长时间之内通知复试；
有无医疗保险、养老保险、失业保险、住房公基金等福利待遇。一般面试的会谈与过程掌控在招聘人手中，如果不想变得很被动，就要试着主动发问。不过，招聘人很少会给你机会，或者你问的不是时机，会让他很反感。只有到最后，招聘人才会说“我们的问题问完了，你有什么问题吗？”，这时你就可以放心大胆的问了，比如：
主要业务是什么？
现有规模怎么样？
测试组的情况怎么样？
作息制度等等？凡是你所关心的问题都可以问。之后是几句寒暄的话，诸如：
谢谢您来参加面试
耽误您宝贵时间了
我送您出门
ByeBye，再见（注明：如果是外企公司或承包外企项目的公司，几乎整个初试将用英语进行。）
这样，初试就结束了。一般初试后一周之内会通知你参加复试，如果没有接到通知，就不要再怀念这家公司了。假如你仍不死心，当然也可以打电话咨询一下，也许他们真的没有想好通知谁复试，也许因为你打了电话，通知复试就是你了；也许他们已经将你Pass掉了，就会委婉的告诉你，或者直截了当的告诉你。
3. 复试
在考试和初试综合成绩出来之后，招聘负责人决定推荐几位综合成绩好的初试者给老板（最终负责人），由其对你进行复试。谈话的内容与初试差不多，但你会觉得比较随和，因为大老板一般都很会做人，而且觉得你可能就是我们公司的员工了，所以会相对放松些。
经过复试之后，几乎当场或者很快就会给你电话，告知你被录用了，报到时需要携带哪些证件，询问你何时能够上班？如果复试后几天都没有讯息，就不要再等了，招聘公司已经将你Pass掉了。
(注明：不是所有公司的面试都有考试、初试、复试，但至少一次面谈是必需的)
各位测试朋友，在经历了投递简历 、准备面试 、参加面试的三步曲之后，总会有一家适合你的公司；如果你经历了几次都没能成功，请不要气馁，也许我们与这些公司之间真的是有些偏差，比如人家要求有手机测试经验，而我们没有，就不要怀疑自己能力不行； 比如人家要求熟练使用Rational系列测试工具，我们现在不擅长，就可以向熟悉Rational工具的人学习学习。总之，无论成功、失败，我们都要保持一种谦虚、自信的态度，来面对人生中的一次又一次面试。
-
面试试题（转）
2007-09-03 09:55:17
面试题目：
01. 为什么要在一个团队中开展软件测试工作？
因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。
02. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试
03. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同04. 的测试类型的区别与联系（如功能测试、性能测试……）
测试类型有：功能测试，性能测试，界面测试。
功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试
05. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、的区别与联系。
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
1、是否有不正确或遗漏的功能？
2、在接口上，输入是否能正确的接受？能否输出正确的结果？
3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
4、性能上是否能够满足要求？
5、是否有初始化或终止性错误？
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
1、对程序模块的所有独立的执行路径至少测试一遍。
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3、在循环的边界和运行的界限内执行循环体。
4、测试内部数据结构的有效性，等等。
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。
系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）
系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。
06. 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）
07. 您认为做好测试计划工作的关键是什么？
1. 明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
2．坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
3．采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4. 分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。
08. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
1．等价类划分
划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
2．边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3．错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
4．因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
08．您认为做好测试用例设计工作的关键是什么？
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题
09. 请以您以往的实际工作为例，10. 详细的描述一次测试用例设计的完整的过程。
就说最近的这次网站功能的测试吧
首先：得到相关文档（需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。
第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历3个步骤，网站才算完成了它的任务。有3个步骤呢，就可以分别对这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。
第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了tomcat，所以只要有tomcat即可
第四步：执行测试
11. 您以往是否曾经从事过性能测试工作？如果有，12. 请尽可能的详细描述您以往的性能测试工作的完整过程。
是的，曾经做过网站方面的性能测试，虽然做的时间并不久（2个月吧），当时呢，是有位网站性能测试经验非常丰富的前辈带着我一起做。
性能测试类型包括负载测试，强度测试，容量测试等
负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。
容量测试：确定系统可处理同时在线的最大用户数
在网站流量逐渐加大的情况下，开始考虑做性能测试了，首先要写好性能测试计划，根据运营数据得出流量最大的页面（如果是第一次的话，一般是首页，下载页，个人帐户页流量最大，而且以某种百分比），
Web服务器指标指标：
* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
* Successful Rounds：成功的请求；
* Failed Rounds ：失败的请求；
* Successful Hits ：成功的点击次数；
* Failed Hits ：失败的点击次数；
* Hits Per Second ：每秒点击次数；
* Successful Hits Per Second ：每秒成功的点击次数；
* Failed Hits Per Second ：每秒失败的点击次数；
* Attempted Connections ：尝试链接数；13. 您在从事性能测试工作时，14. 是否使用过一些测试工具？如果有，15. 请试述该工具的工作原理，16. 并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
17. 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？
18. 在您以往的工作中，19. 一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
20. 您以往所从事的软件测试工作中，21. 是否使用了一些工具来进行软件缺陷（Bug）的管理？如果有，22. 请结合该工具描述软件缺陷（Bug）跟踪管理的流程。
23. 您认为在测试人员同24. 开发人员的沟通过程中，25. 如何提高沟通的效率和改善沟通的效果？维持测试人员同26. 开发团队中其他成员良好的人际关系的关键是什么？
27. 在您以往的测试工作中，28. 最让您感到不29. 满意或者不30. 堪回首的事情是什么？您是如何来对待这些事情的？
31. 在即将完成这次笔试前，32. 您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会？（可以包括软件测试、过程改进、软件开发或者与此无关的其他方面）
33. 你对测试最大的兴趣在哪里？为什么？
最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了11，12点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1，2点我没有把握，其他点我都很有信心做好它。
刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。
不到一年半的测试工作中，当时的感动和热情没有减退一点（即使环境问题以及自身经验，技术的不足，做测试的你一定也能理解）。
我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。
第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。
34. 你的测试职业发展是什么？
测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，按如何做好测试工程师的11，12点要求自己，不断的更新自己改正自己，做好测试任务。
35. 你自认为测试的优势在哪里？
优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。
36. 你以前工作时的测试流程是什么？
公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。
37. 当开发人员说不38. 是BUG时，39. 你如何应付？
开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。
23．你为什么想离开目前的职务？
因为公司运作情况并不理想，公司需要调整部门体系，公司考虑到缩减部门人员，所以大批量的裁员（有6，7个），这是我的第一份工作，对公司也有较深的感情，因为在这里我找到了职业理想（就是测试），所以公司需要精简人员，我自愿退出。虽然很舍不得，但我将会有新的发挥能力的舞台。
24：你对我们公司了解有多少？25：你找工作时，最重要的考虑因素为何？
工作的性质和内容是否能让我发挥所长，并不断成长。
26：为什么我们应该录取你？
您可以由我过去的工作表现所呈现的客观数据，明显地看出我全力以赴的工作态度。
27：请谈谈你个人的最大特色。
我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。
28.白箱测试和黑箱测试是什么?什么是回归测试?
29。单元测试、集成测试、系统测试的侧重点是什么？
30。设计用例的方法、依据有那些？
31。一个测试工程师应具备那些素质和技能？
32.集成测试通常都有那些策略？
33.你用过的测试工具的主要功能、性能及其他？
34.一个缺陷测试报告的组成
35.基于WEB信息管理系统测试时应考虑的因素有哪些？
36.软件测试项目从什么时候开始，？为什么？
37.需求测试注意事项有哪些？
38.简述一下缺陷的生命周期
39.测试分析测试用例注意（事项）？
你在你所在的公司是怎么开展测试工作的？是如何组织的？
你认为理想的测试流程是什么样子？
你是怎样工作的？
软件测试活动的生命周期是什么？
请画出软件测试活动的流程图？
针对缺陷采取怎样管理措施？
什么是测试评估？测试评估的范围是什么？
如果能够执行完美的黑盒测试，还需要进行白盒测试吗？为什么？
测试结束的标准是什么？
软件验收测试除了alpha,beta测试以外,还有哪一种?
做测试多久了？
以前做过哪些项目？
你们以前测试的流程是怎样的？
<答：测试计划－测试用例设计－测试执行－测试分析报告>
用过哪些测试工具？
为什么选择测试这行？
<答：它是一个新兴的行业，有发展潜力，而且很锻炼人，需要掌握更多的技能，比做开发要更难>
为什么值得他们公司雇用？
如果我雇用你，你能给部门带来什么贡献？
如何从工作中看出你是个自动自觉的人
你的工作通常能在时限内完成吗.（我想问一下就是她问这个问题的动机是什么）
通常你对于别人批评你会有什么样的反应
如果明知这样做不对，你还会依主管的指过去做吗
如果你接到一个客户抱怨的电话，你确知无法解决他的问题，你会怎么处理
你觉得什么样的人最难相处
为什么值得他们公司雇用？
帮助公司提高软件质量和测试部门的技术水平
如果我雇用你，你能给部门带来什么贡献？
分享我的测试经验和测试技能，提高测试部门技术水平
如何从工作中看出你是个自动自觉的人
自动自觉范围太广
1. 工作成果
2. 工作质量
你的工作通常能在时限内完成吗.（我想问一下就是她问这个问题的动机是什么）
在有足够的资源和合理的工作量的情况下，完全可以按时完成，并能比一般人做的更好
通常你对于别人批评你会有什么样的反应
有错即改，无措勉之
如果明知这样做不对，你还会依主管的指过去做吗
在公司内部下级是否有申诉渠道？
如果你接到一个客户抱怨的电话，你确知无法解决他的问题，你会怎么处理
为什么抱怨？是怎么样的问题？
如果是客服问题，提交客服部门解决
如果是质量问题，分析原因，下一版本改进
你觉得什么样的人最难相处
自以为是的人
什么叫单元测试？
请就软件测试人员应该具备什么样的基本素质说说你的看法。
请就如何在开发中进行软件质量控制说说你的看法
简述软件测试的意义，以及软件测试的分类1、功能测试，性能测试，界面测试，安全测试（可以简单点，比如只涉及到COOKIES里的内容），压力测试（商业性质的网站） 等等，B/S软件也要根据其具体功能采用不同的测试策略。
2、态度、责任心、自信、敏锐的观察力、良好的发散思维
3、先设计后开发模式，加强单元测试，加强代码走查，有一套完整的白盒测试方法。关键是加强开发人员的质量意识，增进程序员向工程师水平发展。
4、意义嘛，就自己想吧。软件测试的分类，这个很多人都按各种方法去分。无明确答案给你。对测试的理解——基本的测试知识，对测试是否认可？ 75。
3、谈一谈过去自己的工作——了解经历、提供进一步提问的素材，表达能力
测试技能
测试设计的方法并举例说明——测试技术的使用
测试工具——熟悉程度，能否与当前工作匹配？
如何做计划？如何跟踪计划？——日常工作能力
如果开发人员提供的版本不满足测试的条件，如何做？——与开发人员协作的能力
熟悉unix系统、oracle数据库吗？——是否具备系统知识
做过开发吗？写过哪些代码？——开发技能
阅读英语文章，给出理解说明？——部分英语能力
文档的意义——是否善于思考？（最简单的概念，不同层次的理解）
假如进入我们公司，对我们哪些方面会有帮助？——讲讲自己的特长
随便找一件物品，让其测试——测试的实际操作能力
软件测试的方法有？
软件测试的过程？
有一个新的软件，假如你是测试工程师，该如何做？
软件测试分哪两种方法？分别适合什么情况？
2。一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。
3。软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。
4。测试用例通常包括那些内容？着重阐述编制测试用例的具体做法
5。在分别测试winform的C/S结构与测试WEB结构的软件是，应该采取什么样的方法分别测试？他们存在什么样的区别与联系？
6。在测试winform的C/S结构软件时，发现这个软件的运行速度很慢，您会认为是什么原因？您会采取哪些方法去检查这个原因？
7。描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程
你在五年内的个人目标和职业目标分别是什么？
分析这个问题是用来了解你的计划能力的，通过这个问题，面试人同时还可以知道你的目标是否符合企业对你的安排。
错误回答我想在将来的某个时候考虑这个问题。如今企业的领导者更换频繁，我认为做太多的个人计划是荒谬可笑的，不是吗？
评论这种回答属于令人反感的一类。首先，当有人想了解你的目标时，"将来的某个时候"这种通俗说法并不奏效。其次，认为企业很脆弱，领导者更换频繁，这种说法毫无疑问会令人反感，而且也是不合理的。最后，认为做计划可笑，看不起这个问题，而且反问面试人，这些都注定了这样的求职者最终会失败。
正确回答从现在起的五年之内，我希望能够在一个很好的职位上待几年，而且最好有一次晋升，然后就期待着下一步。不管是向上提升，还是在企业内横向调动，对我个人来说，我希望找到一家企业——一家愿意做相互投入的企业——待上一段时间。
评论这个问题没有回答得过分具体（那样可能会产生漏洞），而且它表明你有雄心，并且思考过在企业中的成长方式。通过表达横向调动和向上提升的愿望，表明你是一个有灵活性的人。
问题23 你怎样做出自己的职业选择？
分析 面试人提出这个问题是为了了解求职者的动机，看看他（她）应聘这份工作是否有什么历史渊源，是否有职业规划，是不是仅仅在漫无目的地申请很多工作。
错误回答 我一直都想在企业界工作。自孩提时代起，我就梦想自己至少也要成为大企业的副总裁。
评论 除了难以令人相信之外，这种回答还存在一个问题：它表明求职者会对副总裁以下的职位不感兴趣。
正确回答 在上大学四年级前的那个夏天，我决定集中精力在某一领域谋求发展。尽管我是学商业的，但是我不知道自己最终会从事哪一行业的工作。我花了一定的时间考虑自己的目标，想清楚了自己擅长做的事情以及想从工作中得到的东西，最后我得出了一个坚定的结论，那就是这个行业是最适合我的。
评论 这种回答表明，求职者认真地做过一些计划，缩小了自己的关注点，而且也认准了前进的方向。这种回答还表明，求职者理解个人职业规划的重要性，并且有能力做出认真的个人决策。
1. 你都用什么测试方法
2.怎么编写案例
3.怎么才能够全面的测试到每一个点
1. 你都用什么测试方法
针对不同的产品或者系统或者模块，有不同的测试方法。总体而言有白盒测试和黑盒测试。
2.怎么编写案例
案例的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同。总体而言测试案例根据系统的需求而定。
3.怎么才能够全面的测试到每一个点
测试的全面性主要需要在设计测试计划的时候考虑，从测试策略，产品需求等等多个角度考虑从而定义全部的测试点。
1、谈谈软件测试技术，以及如何提高
2、谈谈软件测试职业发展，以及个人的打算
3、谈谈软件测试在企业的地位，也可以结合软件生命周期来谈
有可能清晰的思路比确切的答案更重要
在这里，主要说下笔试和面试的问题，希望大家共同参考。
1，一般公司里实际的软件测试流程是什么样的？你们公司又是怎样的？
2，软件工程师要具有那些素质？
3，你会哪些测试工具？怎么操作？
4，你能不能说下你的3到5年的职业计划（规划）
5，你觉得你来应聘有那些优势？
其余的还好说，但就第4个问题，我感到不好说哦！希望大家给个意见
第一关：首先要自我介绍，自己的性格怎么样，目前的工作经历积累了一些什么经验取得了些什么值得一说的成果。然后要说说对软件测试怎么看？还有对于软件测试有什么自己的想法。为什么会想到要做这行（因为我的简历上的工作经历没有关于测试方面的）。哦，还有期望薪资。
第二关：认为软件测试人员所要具备的基本素质，如果遇到问题会怎样处理，如果得不到研发人员的配合（就是研发说这个不是问题）你又会怎么处理？然后就是一些基本概念，比如软件测试的流程有哪些？如果我上任了，首先会怎么开始自己的工作计划。
（前两关通过了后面这个就好过多了）
第三关：像我介绍了一下公司的情况，告诉我主要针对什么内容的测试，会不会使用数据库。告诉我大概要做哪些内容，详细的可以上岗以后慢慢熟悉。
大概就这么多了，这对没有经过这一关的不知道有没有帮助，仅供参考吧
我觉得就像李波说的，关键是要给对方留下好印象:)面试官最后会问你有什么问题要问吗。作为应聘者的你一般不要说没问题问，这会给面试官留下你不太重视这份工作的坏印象。所以如果你想得到这份工作的话应该抓住这最后的表现自己的机会：
你可以问：
1. 贵公司近期和远期的发展目标是什么？
2. 贵公司的主要竞争对手有哪些？
3. 贵公司有多少开发人员有多少测试人员？
4. 贵公司又进一步扩充测试人员的计划吗?
5. 如果我有幸能进入贵公司的话，我有怎么样的发展？
6. 测试人员的沟通能力很重要，贵公司有规范的沟通渠道吗？
7. 请介绍一下贵公司的福利情况。
8. 请问我什么时候能知道结果? -
面试时如何提问用人单位
2007-08-25 23:14:55
在面试结束前，大多数的主考官都会丢问题给求职者，最常见的就是：你有没有什么问题或疑问，想要提出来的？无论求职者是否有提出问题，其实，这个问题背后的真正含意，通常是主考官用来测试你对这份工作有多大的企图心、决心和热情。
因此，如果你害怕发问不妥当，或是不知道该从何问起，甚至回答没有问题时，都很可能会让主考官认为，你想要这份工作的企图心、决心还不够强。
相反的，求职者应该更积极、主动的利用面试最后一关的机会，适时的提出问题，这不但有助于主考官对你的印象能够加深，而且你也能趁此机会进一步了解这家公司的背景、企业文化是否适合你。
最重要的是，如果能够在面试时，提出漂亮的问题，录取的机率将会大大提高。所以，无论如何，前往面试前，先谨记10个可以反问主考官的问题，以便到时候可以提出。
1.贵公司对这项职务的工作内容和期望目标为和？有没有什么部分是我可以努力的地方？
2.贵公司是否有正式或非正式教育训练？
3.贵公司的升迁管道如何？
4.贵公司的多角化经营，而且在海内外都设有分公司，将来是否有外派、轮调的机会？
5.贵公司能超越同业的最大利基点为何？
6.在项目的执行分工上，是否有资深的人员能够带领新进者，并让新进者有发挥的机会？
7.贵公司强调的团队合作中，其它的成员素质和特性如何？
8.贵公司是否鼓励在职进修？对于在职进修的补助办法如何？
9.贵公司在人事上的规定和作法如何？
10.能否为我介绍一下工作环境，或者是否有机会能参观一下贵公司？
至于薪水待遇、年假天数、年终奖金、福利措施等问题，有些公司的主考官在面试时，会直接向求职者提出。如果对方没有提及，对社会新鲜人来说，在找第一份工作时，比较不适合提出，除非你有对方不得不录取你的条件。
标题搜索
我的存档
数据统计
- 访问量: 32567
- 日志数: 46
- 书签数: 1
- 建立时间: 2007-04-18
- 更新时间: 2008-08-05
