【www.gbppp.com--求职面试技巧】
【求职意向】测试工程师
简 历
姓名:*** 性别：男 年龄：23
学历：大 专 专业：软件测试 籍贯：**********
电话：********* E-mail：************
通讯地址：&&&&&&&&&&&&&&&&&&&&&&&&&&&&
1、熟悉自动化测试工具如： QuickTest Professiornal、WindRunner、LoadRunner进行功能和性能测试。
2、熟练使用测试管理工具TestDirector、bugzilla、bugfree，进行测试项目的管理、用例的设计、用例的执行等工作。
3、能够编写测试计划，熟练掌握测试用例设计方法，测试执行和缺陷跟踪，运用等价类，边界值等方法编写测试用例。
4、熟悉Java 、servlet、JavaScript、VBScript、XHTML等语言，熟练使用ASP、JSP技术, 熟练使用 MyEclipse、Dreamweaver、EditPlus工具，了解C#技术。
5、熟练使用 sql server数据库管理工具，了解MySQL、Oracle数据库。
6、会使用Microsoft Visio进行UML画图。
7、能够熟练的操作windows系统及一些office办公软件，了解Linux系统。
8、了解MIS、ERP等系统。
2009年11月——2009年12月
项目名称：极品时刻表
软件环境：windows
硬件环境：CPU：Intel Pentium Dual E2140 内存：2GB 硬盘：160GB 显卡：独显512MB 主频：2.7GHZ 责任描述：对其中极品时刻表、机票直通车等模块功能进行测试用例的编写和测试执行，编写测试计划、撰写测试报告、和提交相应的 bug 、跟踪 bug ，回归测试，以及用户使用文档的编写等。
项目描述：极品时刻表实现了在线和非在线查询的各项功能，以及在线娱乐和在线升级等功能。
2009年12月——2010年2月
项目名称：OA系统
开发工具：运用MySQL、MyEclispe、tomcat、JDK等。
硬件环境：CPU：Intel Pentium Dual E2140 内存：2GB 硬盘：160GB 显卡：独显512MB 主频：2.7GHZ 软件环境：windows
责任描述：对项目进行分析，提取测试需求，搭建测试环境等工作，运用TestDirector对图书管理、考勤等模块功能进行测试用例执行，以及用户文档的编写，和提交相应的测试报告和 bug 报告、跟踪 bug，回归测试等，并对登陆模块和考勤模块进行性能测试。
项目描述：OA系统是为了满足大型企业协同管理的需求而开发的新一代先进的协同平台套件系统。
2010年3月——至今
项目名称：门户网站测试
硬件环境：CPU：mobile amd sempron（tm） processor 3500+ 内存：1GB 硬盘：80GB 显卡：独显256MB 主频：1.8GHZ
软件环境：windows xp
责任描述：对项目进行分析，提取测试需求，测试计划的编写及测试用例的设计、执行；配合项目进度进行的高强度加急测试；跟踪并验证bug；测试文档存档等工作。
1、2007年9月——2010年6月 ******大学 软件测试 大专
2、2009年9月——2009年10月，于******教育中心进行为期两个月的软件测试实训。
2009年11月——2010年1月 中关村软件园实习 软件测试 测试组长
工作描述：测试用例的编写和测试执行，以及用户文档的编写，提交相应的测试报告和 bug 报告、跟踪 bug，回归测试等。
2010年3月——至今 北京天创时代信息技术有限公司 网站运营部 测试工程师 工作描述：测试计划的编写及测试用例的设计、执行；配合项目进度进行的高强度加急测试；跟踪并验证bug；测试文档存档；测试工作SOP修改完善、执行度。
能胜任重复性工作，有责任心、工作细致认真，有耐心，热爱软件测试工作。善于学习，理性、具良好的心理素质，工作适应能力强，踏实，稳健，善于沟通，注重团队合作精神。 【个人荣誉】
2007年12月，荣获校级“优秀共青团员”称号；
2008年4月，荣获校级“优秀信息员”称号；
2008年12月，荣获校级“优秀三好学生”称号；
电脑、看书、旅游、篮球、听歌等。
1,网络知识的了解，TCP三次握手。
2,SQL相关知识的了解。
3,测试流程的了解。
4,对测试相关工作的了解。
5,
项目名称：医院管理系统
开发语言：C++
测试工具：TestDirector
项目简介: 为方便医院管理，现实电脑化操作，提高各部门工作效率，同时防止处方外流，特制定医院管理系统。该系统主要分为门诊、住院、药房等三大核心模块，系统采用C/S架构，数据库为SQL server，整个项目时间为10个月，其中测试时间为2个月。
测试职责: 主要负责测试住院管理模块，根据测试计划和需求文档，对所测模块进行细化，再按其功能及业务流程设计、编写、优化测试用例，同时参与质量评估，对缺陷进行跟踪管理，并每天提交相应的缺陷报告和工作日志。
一、软通动力面试笔答
1.白箱测试和黑箱测试是什么?什么是回归测试?
2.单元测试、集成测试、系统测试的侧重点是什么？
单元测试的重点是系统的模块，包括子程序的正确性验证等。
集成测试的重点是模块间的衔接以及参数的传递等。
系统测试的重点是整个系统的运行以及与其他软件的兼容性。
3.设计用例的方法、依据有那些？
白盒测试用例设计有如下方法：基本路径测试\等价类划分\边界值分析\覆盖测试\循环测试\数据流测试\程序插桩测试\变异测试.这时候依据就是详细设计说明书及其代码结构吧；
黑盒测试用例设计方法：基于用户需求的测试\功能图分析方法\等价类划分方法\边界值分析方法\错误推测方法\因果图方法\判定表驱动分析方法\正交实验设计方法.依据是用户需求规格说明书，详细设计说明书
4.一个测试工程师应具备那些素质和技能？
掌握基本的测试基础理论
本着找出软件存在的问题的态度进行测试,即客观吧,不要以挑刺形象出现
可熟练阅读需求规格说明书等文档
以用户的观点看待问题
有着强烈的质量意识
细心和责任心
良好的有效的沟通方式（与开发人员及客户）
具有以往的测试经验
能够及时准确地判断出高危险区在何处.
5.集成测试通常都有那些策略？
大爆炸集成；自顶向下集成；自底向上集成；三明治集成；分层集成；基干集成；基于功能的集成；基于消息的集成；基于风险的集成；基于进度的集成.
6.你用过的测试工具的主要功能、性能及其他？
7.一个缺陷测试报告的组成？
缺陷跟踪报告:
编号，如：ut-dt00016
标题，如：文字排版功能.字间距.MarchCalculator计算错误
版本号，如：V1.3
执行状态，如：空白/草稿/提交/审批/分发/正在修改/修改完毕/正在确认/关闭„
修改记录，如：2003年7月2日；肖睿编制/修改；原因
测试环境和版本号码、程序编写人员
错误严重程度和优先级别
错误详细描述
重现步骤和方式、对应的测试记录编码
附件【软件测试项目】
建议修改方式
修改内容、结果及修改人员签字/日期
8.基于WEB信息管理系统测试时应考虑的因素有哪些？
1）功能测试
① 链接测试
② 表单测试
③ Cookies测试
④ 设计语言测试
⑤ 数据库测试
2）性能测试
① 连接速度测试
② 负载测试
③ 压力测试
3）可用性测试
① 导航测试
② 图形测试
③ 内容测试
④ 整体界面测试
4）客户端兼容性测试
① 平台测试
② 浏览器测试
5）安全性测试
9.软件本地化测试比功能测试都有哪些方面需要注意？
10.软件测试项目从什么时候开始，？为什么？
软件测试应该在需求分析阶段就介入，因为测试的对象不仅仅是程序编码，应该对软件开发过程中产生的所有产品都测试，并且软件缺陷存在放大趋势.缺陷发现的越晚，修复它所花费的成本就越大.
11.需求测试注意事项有哪些？
一个良好的需求应当具有以下特点：
● 完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
● 正确性：每一项需求都必须准确地陈述其要开发的功能。
● 一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。
● 可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
● 无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。【软件测试项目】
● 健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
● 必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。
● 可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
● 可修改性：每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
● 可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。
12.简述一下缺陷的生命周期
13.分析测试用例注意（事项）？
1）为什么要写用例：
我们编写测试用例，有如下的好处：
便于团队交流：假如说一个测试团队有10个成员，大家测试的时候都各自为政，没有统一的标准，测试的效率无疑会大打折扣；如果大家都遵循统一的用例规范去写，就会解决这一问题。
便于重复测试 ：大家知道，软件在实际开发过程中是会有不同版本的，比如会从1.0升级到10.0，那么如果不写测试用例的话，在测试10.0版本的时候，你能完全记得1.0版本时你做过哪些测试吗？测试用例就像一个备忘录一样，便于重复测试。
便于跟踪统计：这一点是针对测试经理或是项目经理来说的，项目负责人通过看测试用例的执行情况，就能了解到项目目前的概况，比如已经执行了哪些测试，还有哪些测试没有执行，测试没有通过的地方主要集中在哪些模块等。
便于用户自测：尤其是项目软件，有的时候用户希望自己测试一下软件产品，但是用户大都是非专业人士，他需要根据你写好的用例来更好的检验产品的质量
说了这么多编写测试用例的优点，那它有没有缺点呢？有一个明显的缺点就是需要花费大量的时间，通常编写测试用例的时间比实际执行测试的时间还要长，这一点大家会在实际工作中有深刻的体会
2）什么时候写用例：
什么时候写用例？这个问题没有统一的标准答案，但有一点可以肯定，就是测试用例要尽早编写。 大家认为在哪个阶段开始写用例比较好呢？
通常，我们都会在测试设计阶段来写用例，即《需求规格说明书》和《测试计划》都已完成之后
二、瑞星笔试题(15道)
1.一台计算机的IP是192.168.10.71子网掩码255.255.255.64与192.168.10.201是同一局域网吗？
2.internet中e-mail协仪，IE的协仪，NAT是什么，有什么好处，能带来什么问题？DNS是什么，它是如何工作的？
3.PROXY是如何工作的？
4.win2k系统内AT命令完成什么功能，Messenger服务是做什么，怎么使用？
5.进程，线程的定义及区别
本文以一个工作流测试项目为例， 总结了在测试过程中积累的经验，探讨了目前国内软件开发企业在软件测试过程中遇到的问题以及解决的方法。测试项目背景和实施情况工作流在某公司软件产品线中占有重要地位。
Workflow项目是5系列中的一个小版本，主要增加了任务代办、任务代理、以及任务交接等功能，同时还修复了一些易用性和功能性的Bug。下面，我们大概介绍一下这个项目的实施情况：
● 项目规模与测试人员配置：
○ 项目代码行数：5万行
○ 开发人员配置：开发人员5名、实习生1名
○ 测试人员配置：测试设计人员1名、测试执行人员2名、实习生1名
● 项目测试时的系统部署情况:
● 测试预期与测试执行情况整个测试项目是比较成功的，项目的时间执行情况和预期的测试指标度量都比较接近。发现Bug总数和缺陷密度都达到了要求的标准。当然，测试周期的实际值比计划值晚了两周，原?因是在系统测试后期，为了满足PSO部门提出的定时器需求造成了一定的延期。回顾整个项目的测试过程，我有几点小小的感悟，愿在此和大家一起分享。
测试如何尽早介入
基于以前的测试经验，我们也越来越认识到测试人员应该尽早介入项目的重要性。简单地沿用测试V模型往往出现很多问题，特别是在项目进度拖延的情况下更是如此。如果测试人员一味固执地被要求严格按照V模型定义的标准来开展测试工作的话，则结果往往是在项目初期测试人员工作量极度不饱和（很多测试人员无所事事），而到了项目后期，一旦项目经理决定压缩测试时间，测试人员就不得不加班加点地工作。但是，不少朋友实践“测试人员尽早介入”的效果并不理想，例如：
● 测试人员参加项目前期的各种会议，会被当作“专职的”会议记录员。
● 测试人员参加代码评审，又不甚了解程序开发语言，浪费了时间其丢失了自信。那么，在这个XXX5.2 Workflow项目中我们是怎么做的呢？实际上，在项目开发初期，测试人员可以开展很多有价值的工作，例如：
● 评审需求文档的正确性和可测试性；根据需求文档整理和分析测试需求，清晰明确的测试需求是测试设计的基础。
项目管理者联盟，项目管理问题。
● 在开发设计过程中，根据需求文档和设计文档进行测试设计，测试设计方案是测试用例的保证。
● 和项目团队中的集成组和开发组协?商软件版本的编译方式和编译进度以及测试人员提取版本的方式和进度。
● 开发人员每天下午4：30之前提交所有可编译的代码，每天晚上进行日编译； ● 开发经理根据版本稳定情况，每周提交测试申请单。
● 测试人员根据测试进度需要，提取测试版本。【软件测试项目】
● 提前准备测试环境，包括数据库环境，操作系统和web应用服务器，以及复杂集群环境。
● 如果项目需要，还可以在此阶段研究一下自动测试工具，包括一些准备外包测试的工作。根据产品的成熟度调整测试策略开发测试一盘棋。测试经理应该有大局观，保持测试策略总与开发的进展相一致，保证最终的软件成果最佳（而不是测试部发现Bug数最多）。在这个XXX5.2 Workflow项目过程中，我们合理制定了不同阶段的测试策略，收到了很好的效果。
产品开发期同情的测试
要忍！要在这个能够发现大批Bug的黄金时段学会做减法。就现实而言，这个阶段的产品，大多难以满足系统测试的条件。如果进行穷兵黩武式的测试，无疑会加重开发人员的焦虑心情，甚至对测试产生逆反心理。另一方面，测试工作不应停滞，特别是不少测试人员对产品的了解还流于皮毛，抓紧时间进行“测试练兵”非常有必要。因此，“产品开发期”的测试切忌生硬。其实，此时程序人员也知道产品还不成熟，所以要告诉测试执行人员：
● 这个阶段不要提交界面简单错误和易用性方面的Bug（可以先记录下来到项目末期提交），否则会使开发人员质疑测试人员只会发现简单的Bug。
● 换位思考，了解此时开发人员最关心的是功能是否能正确运行，多对基本功能进行测试。
产品成熟期积极的测试
随着产品的不断成熟，主要功能的实现已经趋于完善，关键路径的测试已经不成问题。此时的程序员们，压力已经大大减轻，他们的工作重点也从“构建”转移到了“修复Bug”，这个阶段程序人员对于Bug的接受程度是最高的，对Bug的修复和反馈也非常积极。于是，此时的测试工作应对整个产品的细节和所有路径进行覆盖测试，保证测试的全面性，层层深入地测试产品值得测试的各个部分，尽可能多的发现并报告Bug。
产品稳定期多样的测试
在这个阶段，可以尽情的向开发人员报告产品易用性和界面的Bug；可以充分发挥每个测试人员的想象力，根据以往的测试经验来搭建测试场景，构造测试数据；可以通过不同业务场景的不同操作，通过特殊的测试数据，以及相对复杂的集群测试环境来进行多样化测试。为什么？因为此时必须测试得更加深入，才能发现更深层次的Bug，于是多样性的测
试、探索式的测试必不可少。产品发布期谨慎的测试在临近产品发布的日子，包括测试在那的很多工作都变得谨慎起来：代码的提交权限受到了控制，只保留开发经理一个入口；测试的重点更加具有防御性，要仔细测试每个变更，还可以组织“结对测试”来增加测试的保障。测试经理应知人善任为了保证测试工作的质量，首当其冲地就是应该有专业的测试团队。在很多小的软件项目中，往往没有专门的测试团队。这样一来，到了代码基本完成之时，就只能从客户支持部门或研发部门抽调一些人手临时拼凑出“测试团队”进行几周的测试工作，测试质量难以保证。我们则会尽早规划测试团队的人员结构，完善测试团队的配置。每个测试人员的特点和强项常常不尽相同，例如，擅长测试数据质量的测试员，未必能胜任系统环境配置复杂的测试任务。总之，对测试经经理而言，做到知人善任非常重要。同时，在项目测试过程中及时进行调整有时也很必要。此次测试的工作流系统，要求测试人员不仅应掌握一定的工作流业务知识，还需要有较强的逻辑思维能力。而在此项目测试过程中，笔者发现一位测试人员对功能的细节过分关注，而对整个工作流程总是理解不到位。显然，其设计出的测试用例不能适应工作流测试的要求。于是，立即进行人员分工和测试任务的调整，保证了测试工作顺利进行。坚持立场，规范流程我们公司有严格的测试流程，所有提交测试的软件版本，在提交之前，都要完成必需的冒烟测试（Smoking Test）。冒烟测试是一种测试包，其目标是检查版本的基本功能。这个测试包是由测试人员根据测试用例中级别为“基本”的测试用例抽取出来的，如果该版本没有通过冒烟测试，则就可以说明该版本不太稳定，不值得提交测试人员进行系统测试。有的公司冒烟测试是由测试人员手工或者自动测试。在我们这个项目中，为了保证每个可测试版本的冒烟测试质量，是由开发人员负责完成的。他们知道，如果程序不能通过冒烟测试，测试小组就会拒绝该版本。因此，他们会填写一份提交测试申请表来申请进行系统测试。在这份表格中，不仅会明确版本号，修改或新增的功能详细说明，还会给测试人员提供此版本的测试重点，以及可能会影响到的功能。这些内容对测试人员都是至关重要和大有裨益的。
在项目测试过程中，我们也出现过打回某个版本的情况，拒绝测试。总结起来，基本上有以下几种情况：
● 由于任务查询的技术难度比较大，开发进度已经延期了5天，测试人员正在焦急的等待这部分的功能测试。可是，新提交的可测试版本中，这个功能根本就不能使用，如果进一步测试就是浪费时间，我们立即打回了这个测试版本。
● 新增了代办的功能，可是以往的代理功能中的增加代理人功能却不能正常使用，而增加代理人功能又是代办功能的基础，也就是说，在这个版本中，及时代办功能完全能够测试，可离开了增加代理人功能，代办测试是没有意义的。
● 在回归测试阶段，可测试版本的提交是比较频繁的。开发人员一旦解决了一部分bug就会提交一个可测试版本，如果此时测试人员并不急需更换版本，并且得知另一个版本会在几个小时之后就会完成，我们可以不测试这个版本。为了能更好的完成冒烟测试这个关键阶段，测试人员积极与开发人员配合：
● 负责提供冒烟测试案例。
● 如果测试人员处于版本等待阶段，主动和开发人员一起做冒烟测试。开展有效测试，提高测试效率有效的测试用例是软件测试成功的关键，有助于提高测试效率和测试覆盖率。在这个工作流软件测试项目中，我们从测试模型（Test Model）入手，结合丰富的测
试经验和专业知识，从繁多的测试用例中挑选出有效的用例，用尽可能少的测试输入，覆盖尽可能多的软件需求。主要采用了状态机模型和组合模型，并结合了正交设计技术和组合覆盖技术，完成了对整个系统的测试设计。详细内容可以参考笔者在《程序员》杂志2007年第4期上的文章《基于模型的有效测试用例设计——工作流系统测试实战》一文。知己知彼，合力制胜提供服务使测试人员有机会赢得程序员的信任，同时也有机会展示自己的才能。同时，带来的回报是得到了开发人员对我们的帮助。在整个项目过程中，我们获得了很好的回报，比如：开发人员讲解设计思路、算法流程；和测试人员一起构造测试数据；积极参加每日测试例会，主动解决问题等。这样良好的合作状态与测试人员的主动努力是分不开的，主要体现在：
● 获取程序员信任，及时沟通不要与被测程序的开发人员形成不必要的敌对关系。如果能与打交道的程序员共享信息，比如他们的计划、设计文档的早期草案和早期原型等，测试工作会更加有效。越早与程序员接触，情况就越好。尽早提出你的意见和反馈，了解程序员提交前完成的工作。
● 主动出击，提供服务
○ 在测试前期，直接向开发人员提供服务；这不仅可以建立信任，而且还可以证明测试人员是能够与之合作的人。我们在项目过程中提供给开发人员的服务：
○ 对工作流的运算逻辑?构件进行了测试，方便了后期开发工作流客户端应用的使用。 ○ 对内部版本和原?型进行测试。
○ 对需求文档的可测试性进行评审。开发人员和测试人员一样，对模棱两可的要求很头疼，他们非常希望测试人员的介入。
○ 帮助程序员建立测试环境，方便程序员进行测试。
● 耳目作用
○ 在项目过程中，测试人员有机会能够发现很多存在的问题，比如：需求和设计以及开发的不一致性，项目计划中工作任务的缺失等等。测试人员不要仅局限于测试命令链本身，及时验证和发现项目环节中的问题。总之，测试项目能否成功，与整个项目组的精诚合作是密不可分的。测试人员是一种服务角色，要乐于接受这种角色，只有这样，才能得到被服务的人的帮助和支持，以及认可
关于软件测试项目的那些困惑
最近做项目总是有一种凝滞的感觉，忙忙碌碌一整天，临下班来检验自己的工作成功，不过编写或者执行了小一部分用例、提交了小于10个的bug，这跟以前在做项目时一天能写很多TC，可以执行很多模块、提交二三十个bug的状况，差距真的很大。
多次自问，究竟是什么缘故导致了这种情况，也问了部分同学，居然他们也有类似的感觉。那么究竟是在哪里出了问题?
按道理，现在测试可使用的工具越来越多，有一部分工作已经被测试工具所替代，比如项目日报。那么我们使用工具节省下来的时间又消耗到什么地方去了?
我想了几个不是很成熟的原因，权当抛砖引玉，希望能够让更多的同学加入到这个话题的讨论中来。期待发现问题所在，进而解决问题，提高我们的工作效率。
测试设计方面：
现在的项目，都有N多个应用。一个功能点涉及3-4个应用的比比皆是，按照这个原则，几乎每个功能点都需要产出一个系统时序图，同时还需要一个流程图，内容基本重复，工作量翻倍。这样的系统时序图完全可以在流程图中体现，看起来也会更直观、清晰、准确。建议时序图还是从大局出发，不着眼于具体的功能点。
另外，UC整体框架图还是有必要的。
测试用例方面：
过多的条条框框，反而限制了大家的思维。这不是说规范不重要，相反，规范相当的重要，正是有了规范，我们才能保证用例的质量，但是我们的规范要更多的注重逻辑的东西，而不是流于表面。TC，我们不仅要量，更要保证质。
用例执行方面：
项目伊始，所有的人都在执行基础模块，而导致建立在基础模块上的功能点hold着，让执行者感觉效率不高，重复性非常大，资源在一定程度上是浪费的。
人员众多，功能点的交互，实际上，在同一个时候，大家已经在做部分相同的工作。但是又因为不是自己当前执行的模块，只关注了界面上的，或者逻辑简单的内容，对深度问题不会去挖掘。
几轮测试下来后，就出现了这样一个情况：简单的功能被大家反复的测试了，而复杂的逻辑校验，反而只投入了很少的时间。这一现象与我们测试中要求的复杂功能需要投入更多时间是想违背的。在一定程度上也降低了我们的效率。
现在的事情特别多，很难得有一整天是在安心的做一件事情。思路的打断，在一定程度上也影响了效率。
本文来源：http://www.gbppp.com/sh/449386/
推荐访问:软件测试简历项目经验 软件测试项目实战