软件测试面试题及解析（四）

文思创新软件测试面试题收藏

1.14个心理测试题；

2.推断题：有一个说谎岛，上面居住者人还有吸血鬼，有一年岛上流行瘟疫，有一半的人和吸血鬼疯了，于是岛上有神志清醒的人和精神错乱的人，还有神志清醒的吸血鬼和精神错乱的吸血鬼，其中神志清醒的人和精神错乱的吸血鬼只说真话，而精神错乱的人和神志清醒的吸血鬼只说假话，并且他们回答问题只说“是”或“不是”；

有一天岛上来了一位“逻辑博士”在岛上遇见了P，博士问了一个问题就分出他是人还是吸血鬼，博士又问了一个问题就分辨出他是神志清醒的还是精神错乱的。

请写出博士问得两个问题；

写出你的思路。

3.一篇关于人文方面的英语文章翻译成汉语；

Answer the following questions in English:

4.what kind of phone do you use?

Why do you choose this kind of phone? List errors you find when you use it.

5. Now you work in team A but you want to change your work, that is to say you will join in Team B, how do you tell your Leader and the Project Manager this?

Key point:

1.       what kind of work have you done in Team A?

2.       why do you want to change your work?

口答：

1.       Please introduce yourself briefly in English;

2．你为什么选择软件测试行业？

3.你的职业规划；

4.手机中通讯录的功能测试；

5.英文问题（在测试时代学到了什么-----英文题目）

6.你认为测试人员需要具备哪些素质？

单元测试

 单元测试

　　也称模块测试，这是针对软件设计的最小单位-模块进行正确性检验的测试工作，其目的在于发现各模块内部可能存在的各种差错。单元测试的依据是详细设计描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用结构测试（白盒测试）技术，系统内多个模块可以并行地进行测试。

    软件测试阶段可以分为若干个小的阶段，阶段的划分有多种，我现在按流程顺序将其分为四个阶段：

     · 单元测试：由项目小组完成

· 集成测试：由项目小组完成

· 系统测试：由专业测试小组完成

· 用户测试（验收测试）：用户和开发商共同完成。

测试的四个阶段完全逆向检测了软件开发的各个阶段。单元测试主要是测试程序代码，集成测试主要是对设计的检测，系统测试主要测试了软件的功能，交接测试主要是对用户需求的一种检测。但是每个测试阶段仍要对其它测试阶段的测试内容加以测试，只是测试重点不同。

在单元测试前，先让我们明白以下几个问题，这可以使我们对单元测试更加清晰。

· 单元测试的目标：　确保模块是正确地编码

· 由谁去做：　　　　通常由程序人员测试

· 怎样去测试：　　　功能测试可以用黑匣测试方法，代码测试可用白匣测试方法　

· 什么时候可以停止：当程序员感到代码没有缺陷时

· 记录：　　　　　　通常没有记录

我们在清楚以上问题后就可以编写测试用例了。测试用例是输入、执行条件和一个特殊目标所开发的预期结果集合。它按测试目的不同可分为以下几种类型：

· 需求测试用例：测试是否符合需求规范

· 设计测试用例：测试是否符合系统逻辑结构

· 代码测试用例：测试代码的逻辑结构和使用的数据

需求测试用例通常是按照需求执行的功能逐条地编写输入数据和期望输出。一个好的需求用例是可以用少量的测试用例就能够覆盖所有的程序功能。

设计测试用例检测的是代码和设计是否完全相符。是对底层设计和基本结构上的测试。设计测试用例可以涉及到需求测试用例没有覆盖到的代码空间（例如界面的设计）。

代码测试用例是基于运行软件和数据结构上的。它要保证可以覆盖所有的程序分支、最小的语句和输出。

以上三种用例所用的数据又可分为正常数据、边缘数据和错误数据。

· 正常数据：在测试中所用的正常数据的量是最大的，而且也是最关键的。少量的测试数据不能完全覆盖需求，但我们要从中提取出一些具有高度代表性的数据作为测试数据，以减少测试时间。　

· 边缘数据：边缘测试是界于正常数据和错误数据之间的一种数据。它可以针对某一种编程语言、编程环境或特定的数据库而专门设定。例如若使用SQL Server数据库，则可把SQL Server关键字（如：';AS;Join等）设为边缘数据。其它边缘数据还有：HTML的HTML;<>等关键字以及空格、@、负数、超长字符等。边缘数据要靠测试人员的丰富经验来制定。

· 错误数据：显而易见，错误数据就是编写与程序输入规范不符的数据从而检测输入筛选、错误处理等程序的分支。

由于执行测试用例的数据量巨大以及还要进行回归测试，所以可以考虑使用自动测试工具，但提取测试数据仍要依靠编写测试用例人员的经验。并且，我们还要注意到自动测试也许不能找到程序中所有错误，手动测试所找到的错误会比自动测试所找到的要多。

有了测试用例，我们就可以进行测试了吧？许多公司也是这样做的，但建议大家最好要先进行代码的审议。通过代码审议找到的错误可以比测试用例测试所能找到的错误更加深入，并且发现错误的时间也比测试用例要早。代码审议要以代码标准（根公司具体情况自行制定）为依据，一般情况下要检查以下几点：

· 代码风格和规则审核

· 程序设计和结构的审核

· 业务逻辑的审核

代码风格和规则的审核是在每个程序员完成一个模块或类的时候要进行编码规范的检查。要召开审核会议让所有的项目组人员都参加。在会前项目经理要做一个检查表，以表的内容为检查依据，检查表的内容主要是检查的要点。在审核会上项目组的每一个人员都能看到自己和其他人员的编码问题，从而起到预防的作用。这些问题都要被解决，并且解决的结果要在审议会上被确认。

进行程序设计和结构的审议是因为开发工具的不同和项目时间的限制而造成设计不详细。比较深入的设计通常是在编码阶段完成的，但由于程序人员和设计人员的经验是不同的，所以会出现很大的问题。我们引入了程序设计和结构审核来保证质量。审核人员要有先进的技术开发经验。在审核之前也要一个审核列表，列出主要几项，如：程序的概要、详细设计。但仅局限于列表是不够的，审议人员还要审议程序的精巧度和具有创造力的方面，这只能靠经验而不能只靠列表中的内容来审议。对于不同的程序员所检测代码的宽度和深度也是不同的。项目经理可以根据程序员经验的不同制定被审议人员的宽度和深度。例如：年轻的程序员要审议所有代码。但有经验的就可适当减少。

业务逻辑性审议必须要在代码完成后审议。业务逻辑审议实际上是审议单元模块的功能。这些功能是以系统说明为依据的。审议人员要有开发的经验并且对系统也要熟悉。审议人员通过执行程序从而了解底层代码的状态。这阶段的审议实际也包含了前两种审议，因为审议者也可以通过最后的结果检测单元模块设计和结构的准确性。

以上三种审议都要耗费一定的时间和资源，但是它却能更早地发现和解决不易显现的错误。

审议通过后，我们终于可以使用用例来进行代码测试和调试了。代码的调试是用来保证程序能按照系统需求正常运行的一种手段。但是我所提到的这种代码调试并不是简单的调试，它要包括以下两部分：

· 特征调试

· 代码覆盖调试

首先我们要先进行特征调试。它是通过运行程序找到代码中的错误，这与我们平时常进行的调试相同。到程序能运行后，我们可使用已编好的三种类型的用例并以正常数据测试用例进行测试，若不能正常运行则要用调试工具调试。在这阶段，我们要用大量正常数据去测试。测试后，该程序应可在绝大多数的正常数据中运行。

其次，我们要进行代码覆盖测试，一直要达到以下目标为至：

· 测试到每一个最小语句的代码

· 测试到所有的输出结果

我们应该通过一步步的调试去运行每个程序的所有语句和分支。如果我们想要百分之百地覆盖就应适当运用边缘数据和错误数据。测试在这个阶段的质量是难以掌握的。它基于程序员的责任心和经验。当这阶段完成后，每个程序员所测的深度也是不同的。因此，在这个测试阶段之前，项目经理（或测试工程师）应制定出测试指导和计划书。它们至少应包括以下内容：

· 测试的主要对象

· 主要调试点

· 怎样测试

· 什么时候可以完成

至今为至，我们已完成了代码的审议和调试。如果我们是严格按照以上步骤做的，那就可以保证代码没有太多的错误，至少没有使程序运行中断的错误了。如果我们不能很好地执行代码审议和正确的调试，那我们就不能顺利地通过测试，有时我们还要不得不返回来做这些事。

单元测试的基本方法

　  单元测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。

单元测试任务

　　单元测试任务包括：1 模块接口测试；2 模块局部数据结构测试；3 模块边界条件测试；4 模块中所有独立执行通路测试；5 模块的各条错误处理通路测试。

　　模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。测试接口正确与否应该考虑下列因素：

　　1 输入的实际参数与形式参数的个数是否相同；

　　2 输入的实际参数与形式参数的属性是否匹配；

　　3 输入的实际参数与形式参数的量纲是否一致；

　　4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；

　　5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；

　　6调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；

　　7 调用预定义函数时所用参数的个数、属性和次序是否正确；

　　8 是否存在与当前入口点无关的参数引用；

　　9 是否修改了只读型参数；

　　10 对全程变量的定义各模块是否一致；

　　11是否把某些约束作为参数传递。

　　如果模块内包括外部输入输出，还应该考虑下列因素：

　　1 文件属性是否正确；

　　2 OPEN/CLOSE语句是否正确；

　　3 格式说明与输入输出语句是否匹配；

　　4缓冲区大小与记录长度是否匹配；

　　5文件使用前是否已经打开；

　　6是否处理了文件尾；

　　7是否处理了输入/输出错误；

　　8输出信息中是否有文字性错误；

　　检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：

　　1 不合适或不相容的类型说明；

　　2变量无初值；

　　3变量初始化或缺省值有错；

　　4不正确的变量名（拼错或不正确地截断）；

　　5出现上溢、下溢和地址异常。

　　除了局部数据结构外，如果可能，单元测试时还应该查清全局数据对模块的影响。

　　在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括：

　　1 误解或用错了算符优先级；

　　2混合类型运算；

　　3变量初值错；

　　4精度不够；

　　5表达式符号错。

　　比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误：

　　1不同数据类型的对象之间进行比较；

　　2错误地使用逻辑运算符或优先级；

　　3因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；

　　4比较运算或变量出错；

　　5循环终止条件或不可能出现；

　　6迭代发散时不能退出；

　　7错误地修改了循环变量。

　　一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题：

　　1输出的出错信息难以理解；

　　2记录的错误与实际遇到的错误不相符；

　　3在程序自定义的出错处理段运行之前，系统已介入；

　　4异常处理不当；

　　5错误陈述中未能提供足够的定位出错信息。

　　边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。

单元测试过程

　　一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。

应为测试模块开发一个驱动模块（driver）和若干个桩模块（stub）,下页图显示了一般单元测试的环境。驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入-退出”消息。

驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用综合测试方法。

　　提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。

考虑进行何种测试 收藏

黑盒测试(Black box testing)  ____不考虑内部设计和代码,根据需求和功能进行测试

白盒测试 (White box testing) ──根据应用软件的代码的内部逻辑，按照代码的语句、分支、路径和条件进行测试。

部件测试 (Unit testing) --最小范围的测试,针对特定的函数和代码模块进行测试。因为需要了解程序的设计和代码的细节才能进行，所以部件测试一般是程序员。而不是由测试人员来做。除非应用软件的结构设计良好，而且代码也写得清楚，否则部件测试并非易事。也许需要开发测试驱动模块或测试工具。

递增的综合测试（incremental integration testing）--不断进行的测试过程，每增加一个新的功能模块，都进行测试。这要求一个应用软件在最终完成之前，各功能模块要相对独立，或者已根据需要开发出测试驱动软件。这种测试可由程序员或测试人员进行。

综合测试（integration testing）--对应用软件的各个部分进行组合测试，来检查各功能模块在一起工作是否正常，“部件“可以是代码模块、独立的应用程序、也可以是网络中的客户/服务器应用软件。这种测试特别使用客户/服务器环境和分布式系统

功能测试（functional testing）--对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。（这一原则适用于所有的测试阶段。）

系统测试 -- 针对全部需求说明进行黑盒测试，包括系统中所有的部件

端到端测试 (end-to-end testing)──类似于系统测试，但测试范围更“宏观”一些。模仿实际应用环境，对整个应用软件进行使用测试。例如与数据库进行交互作业、使用网络通信、与其他硬件、应用程序和系统之间的相互作用是否满足要求。

健全测试 (sanity testing) ──是一种典型的初始测试。判断一个新的软件版本的运行是否正常，是否值得对它作进一步的测试。例如，如果一个新的软件每 5 分钟就破坏系统、大大降低系统的运行速度、或者破坏数据库，那么这样的软件就算不上是“健全”的，不值得在目前状态下进行进一步的测试。

回归测试 (regression testing) ──每当软件经过了整理、修改、或者其环境发生变化，都重复进行测试。很难说需要进行多少次回归测试，特别是是到了开发周期的最后阶段。进行此种测试，特别适于使用自动测试工具。

认同测试 (acceptance testing) ──基于说明书的、由最终用户或顾客来进行的测试。或者由最终用户/顾客来进行一段有限时间的使用。

负荷试验 (load testing) ──在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况，以确定在什么情况下系统响应速度下降或是出现故障。

压力测试 (stress testing)──经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况：在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询，等等。

性能测试 (performance testing) ──经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试) 都应在质量保障和测试计划的文档终予以规定。

可用性测试 (usability testing)──是专为“对用户友好”的特性进行测试。这是一种主观的感觉，取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。

安装/卸载测试 (install/uninstall testing)──对安装/卸载进行测试 (包括全部、部分、升级操作)。

恢复测试 (recovery testing) ──在系统崩溃、硬件故障、或者其他灾难发生之后，重新恢复系统的情况。

安全测试 (security testing)──测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。 

兼容性测试 (compatability testing) ──测试在特殊的硬件/软件/操作系统/网络环境下的软件表现。

认同测试 (acceptance testing) ──看顾客是否对软件满意。

比较测试 (comparison testing) ──与竞争产品进行比较，以找出弱点和优势。

 α 测试 (alpha testing) ──在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修改。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。

 β 测试 (beta testing) ──当开发和测试已基本完成，需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。

软件测试工具集

1 、从测试功能上分

（ 1 ）单元测试 : 针对不同语言，如 JUNIT

（ 2 ）功级测试

E—Test ：功能强大，由于不是采用 POST URL 的方式回放脚本，所以可以支持多内码的测试数据（当然要程序支持），基本上可以应付大部分的 WEB SITE 。

MI 公司的 WINRUNNER

COMPUWARE的 QARUN

RATIONAL 的 SQA ROBOT

（ 3 ）压力测试

MI 公司的 WINLOAD

COMPUWARE 的 QALOAD

RATIONAL的 SQA LOAD

（ 4 ）负载测试

LOADRUNNER

RATIONAL VISUAL QUANTIFY

（ 5 ） WEB 测试工具

MI公司的 ASTRA 系列

RSW公司的 E—TEST SUITE 等

（ 6 ） WEB 系统测试工具

WORKBENCH

WEB APPLICATION STRESS TOOL （ WAS ）

（ 7 ）数据库测试工具

TESTBYTES

（ 8 ）回归测试工具

RATIONAL TEAM TEST

WINRUNNER

（ 9 ）嵌入式测试工具

ATTOLTESTWARE 。是ATTOLTESTWARE公司的自动生成测试代码的软件测试工具，特别适用于嵌入式实时应用软件单元和通信系统测试。

CODETEST 是 AppliedMicrosystemsCorp. 公司的产品 , 是广泛应用的嵌入式软件在线测试工具。

GammaRay 。 GammaRay 系列产品主要包括软件逻辑分析仪 GammaProfiler 、可靠性评测工具 GammaRET 等。

LogiScope 是 TeleLogic 公司的工具套件，用于代码分析、软件测试、覆盖测试。

LynxInsure++ 是 LynxREAL-TIMESYSTEMS 公司的产品，基于 LynxOS 的应用代码检测与分析测试工具。

MessageMaster 是 ElviorLtd. 公司的产品，测试嵌入式软件系统工具，向环境提供基于消息的接口。

VectorCast 是 VectorSoftware.Inc 公司的产品。由 6 个集成的部件组成，自动生成测试代码，为主机和嵌入式环境构造可执行的测试架构。

（ 10 ）系统性能测试工具

Rational Performance

（ 11 ）页面链接测试

Link Sleuth

（ 12 ）测试流程管理工具

Test Plan Control

（ 13 ）测试管理工具

TestDirector 　　　　　　　　微创 tcm

Rational公司的 Test Manager

Compuware 公司的 QADirector

TestExpert ：是Silicon Valley Networks公司产品的测试管理工具，能管理整个测试过程，从测试计划、测试例程、测试执行到测试报告。

（ 14 ）缺陷跟踪工具

TrackRecord 等

（ 15 ）其他测试工具包

TestVectorGenerationSystem 是T—VECTechnologies 公司的产品。提供自动模型分析、测试生成、测试覆盖分析和测试执行的完整工具包，具有方便的用户接口和完备的文档支持。

TestQuestPro 是TestQuest公司的非插入码式的自动操纵测试工具，提供一种高效的自动检测目标系统，获取其输出性能的测试方法。

TestWorks 是SoftwareResearch.Inc公司的一整套软件测试工具，既可单独使用，也可捆绑销售使用。

常见的软件测试面试题

文章关键字：软件工程师

时间：2008-12-10

　　常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

　　1. 等价类划分

　　常见的软件测试划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

　　2. 边界值分析法

　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

　　3. 错误推测法

　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.

　　4. 因果图方法

　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

　　5. 正交表分析法

　　有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。

　　6. 场景分析方法

　　指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。

　　您认为做好测试用例设计工作的关键是什么？

　　白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

　　黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

　　详细的描述一个测试活动完整的过程。

　　1. 项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪

　　2. 开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

　　3. 测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

　　4. 测试用例完成后，测试和开发需要进行评审。

　　5. 测试人员搭建环境

　　6. 开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给Bug Zilla。

　　7. 开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。

　　8. 重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。

　　9. 如果有客户反馈的问题，需要测试人员协助重现以及回归测试。

　　以往是否曾经从事过性能测试工作？请尽可能的详细描述您以往的性能测试工作的完整过程。

　　曾经做过一套网管系统的性能测试，主要测试该软件在同时管理大量终端的情况下，在响应时间，CPU/磁盘/内存等参数是否满足要求。

　　也曾经做过软交换系统的呼叫性能测试，主要是测试软交换系统在有大量呼叫的情况下，响应时间，呼叫成功率，CPU/磁盘/内存等参数是否满足设计要求。

　　您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

　　测试网管系统中，使用的Mimic来模拟终端，能够大量的节省成本。

　　测试软交换系统的时候，使用的Prolab来模拟终端并发送呼叫软交换，他完成了同时数百人才能完成的摘机拨号工作，主要工作原理是产生一些符合要求的IP包并发送给软交换系统，同时对软交换系统的回应进行处理，决定下一步动作。

　　您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

　　主要是保障在大量用户的情况下，服务能正常使用。

　　在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

　　1. 在传统的BugZilla中，BUG描述应该包括以下的信息

　　2. 和BUG产生对应的软件版本

　　3. 开发的接口人员

　　4. BUG的优先级

　　5. BUG的严重程度

　　6. BUG可能属于的模块，如果不能确认，可以用开发人员来判断

　　7. BUG标题，需要清晰的描述现象

　　8. BUG描述，需要尽量给出重新Bug的步骤

　　9. BUG附件中能给出相关的日志和截图。

　　高质量的BUG记录就是指很容易理解的BUG记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。