软件测试工程师笔试题含答案.docx

软件测试工程师笔试题含答案.docx

《软件测试工程师笔试题含答案.docx》由会员分享，可在线阅读，更多相关《软件测试工程师笔试题含答案.docx（14页珍藏版）》请在冰豆网上搜索。

软件测试工程师笔试题含答案

软件测试笔试题（含答案）

1.请写出一个你工作经历中的一个功能点测试用例，例如：

用户页面登陆

2.请在以下两个项目当中，选择一个，考虑如何进行用例设计：

a.杯子b.有弹簧的圆珠笔

杯子：

需求测试:

查看杯子使用说明书

界面测试:

查看杯子外观

功能度：

用水杯装水看漏不漏；水能不能被喝到

安全性：

杯子有没有毒或细菌

可靠性：

杯子从不同高度落下的损坏程度

可移植性：

杯子再不同的地方、温度等环境下是否都可以正常使用软件开发网兼容性：

杯子是否能够容纳果汁、白水、酒精、汽油等

易用性：

杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：

使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试：

将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等

压力测试：

用根针并在针上面不断加重量，看压强多大时会穿透

强度测试:

杯子加包装（有填充物）,在多高的情况摔下不破损

有弹簧的圆珠笔：

功能测试：

圆珠笔按下是否能正常写字，写字太重会不回缩回去，继续按会不会弹回去

性能测试：

圆珠心弹出弹回的快慢

负载测试：

一直按，弹簧能接受多少次的升缩

兼容性测试：

换其他的笔芯能不能行

强度测试：

用力过度会怎样

可恢复性测试：

如果弹簧压久了，是否可恢复等等

GUI测试：

笔的外观，拿笔的舒适性

安全性：

考虑对笔芯的保护，是否对使用者造成危害等等

3.白箱测试和黑箱测试是什么?

什么是回归测试?

白箱测试是在看懂程序代码和设计方案的前提下，进行软件的测试。

这种测试注重于源代码

的覆盖率，同时需要测试者具备较高的技术水平。

白箱测试的优点是可以对代码有详细的审

查，能找出隐藏在代码中的错误，从而确保高质量的代码；缺点是很多时候不能看完所有的

代码，不能找出欠缺的代码，同时白箱测试和用户如何使用软件无关。

黑箱测试的优点是测试者无需熟悉软件内部结构，并且根据蓝图在早期就可以制定测试方

案，并不依赖于开发者的工作进展，而且黑箱测试简单易行，对测试者的技术要求不高；但

是，黑箱测试主要是功能上的测试，只能覆盖只有一小部分的输入，不能保证程序的所有部

分都被测试到。

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码

产生错误。

自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

回归测试包括两部分：

函数本身的测试、其他代码的测试。

在对被修改的函数重新测试。

如果函数的设计功能没有变化，直接运行函数测试就可以了。

如果修改了设计功能，则要根据增减的功能点，增加或删除测试用例。

另外，还要完成白盒

覆盖。

函数代码的修改可能导致调用该函数的代码产生错误，所以需要测试其他代码。

如果函数是

私有函数并且未涉及到全局变量，应运行类测试，否则应运行工程测试。

在函数列表中选择

类测试或工程测试，编译运行测试工程，即可执行对其他代码的回归测试。

4.单元测试、集成测试、系统测试的侧重点是什么？

单元测试：

以代码检查、逻辑覆盖

集成测试：

增加静态结构分析、静态质量度量

系统测试：

根据黑盒测试结果，采用白盒测试

单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独

立单元将在与程序的其他部分相隔离的情况下进行测试。

集成测试，也叫组装测试或联合测试。

在单元测试的基础上，将所有模块按照设计要求，组

装成为子系统或系统，进行集成测试。

实践表明，一些模块虽然能够单独地工作，但并不能

保证连接起来也能正常的工作。

程序在某些局部反映不出来的问题，在全局上很可能暴露出

来，影响功能的实现。

系统测试是将经过测试的子系统装配成一个完整系统来测试。

它是检验系统是否确实能提供

系统方案说明书中指定功能的有效方法。

5.设计用例的方法、依据有那些？

白盒测试用例设计有如下方法:

基本路径测试\等价类划分\边界值分析\覆盖测试\循环测试\

数据流测试\程序插桩测试\变异测试.这时候依据就是详细设计说明书及其代码结构吧,恩,这

个真不确定

黑盒测试用例设计方法:

基于用户需求的测试\功能图分析方法\等价类划分方法\边界值分析

方法\错误推测方法\因果图方法\判定表驱动分析方法\正交实验设计方法.依据是用户需求规格说明书,详细设计说明书

6.一个测试工程师应具备那些素质和技能？

掌握基本的测试基础理论

本着找出软件存在的问题的态度进行测试,即客观吧,不要以挑刺形象出现

可熟练阅读需求规格说明书等文档

以用户的观点看待问题

有着强烈的质量意识

细心和责任心

良好的有效的沟通方式（与开发人员及客户）

具有以往的测试经验

能够及时准确地判断出高危险区在何处

①沟通能力

一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力。

既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。

和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。

而和开发者谈相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户和开发者沟通。

②移情能力

和系统开发有关的所有人员都处在一种既关心又担心的状态之中。

用户担心将来使用一个不符合自己要求的系统，开发者则担心由于系统要求不正确而使他不得不重新开发整个系统，管理部门则担心这个系统突然崩溃而使它的声誉受损。

测试者必须和每一类人打交道，

因此需要测试小组的成员对他们每个人都具有足够的理解和同情，具备了这种能力可以将测

试人员与相关人员之间的冲突和对抗减少到最低程度。

③技术能力

就总体言，开发人员对那些不懂技术的人持一种轻视的态度。

一旦测试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。

一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。

要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线。

④自信心

开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。

如果容许别人对自己指东指西，就不能完成什么更多的事情了。

⑤外交能力

当你告诉某人他出了错时，就必须使用一些外交方法。

机智老练和外交手法有助于维护

与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手

腕。

如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于“赢

了战争却输了战役”。

⑥幽默感

在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。

⑦很强的记忆力

一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。

因为许多新出现的问题和我们已经发现的问题相差无几。

⑧耐心

一些质量保证工作需要难以置信的耐心。

有时你需要花费惊人的时间去分离、识别和分派一个错误。

这个工作是那些坐不住的人无法完成的。

⑨怀疑精神

可以预料，开发者会尽他们最大的努力将所有的错误解释过去。

测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。

⑩自我督促

干测试工作很容易使你变得懒散。

只有那些具有自我督促能力的人才能够使自己每天正常地工作。

⑾洞察力

一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。

应用的高风险区的判断能力以便将有限的测试针对重点环节。

7.集成测试通常都有那些策略？

1、在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；

2、各个子功能组合起来，能否达到预期要求的父功能；

3、一个模块的功能是否会对另一个模块的功能产生不利的影响；

4、全局数据结构是否有问题；

5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。

8.你用过的测试工具的主要功能、性能及其他？

WinRunner（WR）是一个基于Windows的企业级功能测试工具，它在业务应用正式部署之

前，通过自动捕获、检测和重放用户对应用系统的交互操作，来发现系统缺陷，确保那些跨

越多个应用程序和数据库的业务流程在初次发布就能避免故障的出现，保证系统对所有关键

业务处理功能、处理流程的正确，保障应用的质量和准备工作的最优化

主要功能:

1）轻松创建测试：

用WinRunner创建一个测试，只需在应用软件中操作记录下一个标准的业务流程，例如下一张订单或建立一个新的商家账户，WinRunner将直观地记录该流程。

即使技术知识有限的用户，也能通过在GUI上单击鼠标而生成完整的测试。

用户还可以直接编辑测试指令来满足各种复杂测试的需求

2）插入检查点：

在建立一个测试的过程中可以插入检查点，以在查找潜在错误的同时，将预

想的结果和实际测试结果进行比较。

在插入检查点后，WinRunner会收集相应的性能指标，

在测试运行时对其一一验证。

WinRunner允许使用几种不同类型的检查点，包括文本、GUI、

位图和数据库等。

例如用一个位图检查点，可以确认一个位图图像是否出现在指定的位置上。

WinRunner的数据库检验功能能够自动标示出被修改的数据

3）检验数据：

除了创建并运行测试，WinRunner还能验证数据库的数值，从而确保交易的

准确性。

例如，在测试创建时，可以设定哪些数据库表格和记录资料需要检测。

在重放时，

测试程序就会核对数据库内的实际数值与预想的数值。

WinRunner能自动显示检测结果，在有更新/修改、删除或插入的记录上会用突出标识引起注意

4）增强测试：

为了彻底全面地测试一个应用程序，用户需要了解对于不同类型的数据它是

如何运行的。

WinRunner的DataDriverWizard使用户只需单击几下鼠标，就能简单地将一个记录下的业务流程转化为一个数据驱动的测试，来反映多个用户各自独特且真实的操作行为

5）运行测试：

在建立测试，并插入检查点和做一些必要的功能添加后，就可以开始运行测

试。

当WinRunner执行测试时，它会自动操作应用程序，正如一个真实用户根据记录流程执行着每一步的操作，而且它的意外处理功能为测试排除干扰，包括消息和警报

6）分析结果：

一旦测试运行后，就需要分析测试结果。

WinRunner的互动式的报告工具通过提供详尽的、易读的报告，其中会列出在测试中发现的差错和出错的位置，来帮助用户解释所得到的结果。

这些报告对在测试运行中发生的重要事件进行描述，如出错内容和检查点等。

单击按钮，还能进一步获取任何未被包括在此测试范围内的错误的详尽资料。

这些结果都可以通过MI的测试管理工具TestDirector来查阅

7）维护测试：

随着时间推移，开发人员会对应用程序做进一步的修改，这时，需要增加额

外的测试。

WinRunner会帮助用户创建可重复使用的测试，以大大节省时间和资源，充分利用测试投资

9.一个缺陷测试报告的组成

缺陷的标题，缺陷的基本信息，复现缺陷的操作步骤，缺陷的实际结果描述，期望的正确结

果描述，注释文字和截取的缺陷图象。

缺陷的标题；

缺陷的基本信息；

测试的软件和硬件环境；

测试的软件版本；

缺陷的类型；

缺陷的严重程度；

缺陷的处理优先级。

复现缺陷的操作步骤；

缺陷的实际结果描述；

期望的正确结果描述；

注释文字和截取的缺陷图像。

10.基于WEB信息管理系统测试时应考虑的因素有哪些？

一、功能测试

1、链接测试

2、表单测试

3、Cookies测试

4、设计语言测试

5、数据库测试

二、性能测试

1、连接速度测试

2、负载测试

3、压力测试

三、可用性测试

1、导航测试

2、图形测试

3、内容测试

4、整体界面测试

四、客户端兼容性测试

1、平台测试

2、浏览器测试

五、安全性测试

11.软件本地化测试比功能测试都有哪些方面需要注意？

软件本地化测试的目的：

软件本地化测试的测试策略：

1.本地化软件要在各种本地化操作系统上安装并测试。

2.源语

言软件安装在另一台相同源语言操作系统上，作为对比测试。

3.重点测试因本地化引起的软

件的功能和软件界面的错误。

4.测试本地化软件的翻译质量。

5.手工测试和自动测试相结合。

12.软件测试项目从什么时候开始，？

为什么？

软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过

程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现的越晚,修复它所花费的

成本就越大.

13.需求测试注意事项有哪些？

一个良好的需求应当具有一下特点：

完整性：

每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些

功能所需的所有必要信息。

正确性：

每一项需求都必须准确地陈述其要开发的功能。

一致性：

一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。

可行性：

每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

无二义性：

对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。

健壮性：

需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。

必要性：

“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。

要使每项需求

都能回溯至某项客户的输入，如UseCase或别的来源。

可测试性：

每项需求都能通过设计测试用例或其它的验证方法来进行测试。

可修改性：

每项需求只应在SRS中出现一次。

这样更改时易于保持一致性。

另外，使用目

录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。

可跟踪性：

应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接

链，这种可跟踪性要求每项需求以一种结构化的，粒度好（fine-grained）的方式编

写并单独标明，而不是大段大段的叙述。

14.简述一下缺陷的生命周期

软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后

关闭的完整过程。

简单的软件缺陷生命周期：

1、发现——打开：

测试人员找到软件缺陷并将软件缺陷提交给开发人员；

2、打开——修复：

开发人员再现、修复缺陷，然后提交测试人员去验证；

3、修复——关闭：

测试人员验证修复过的软件，关闭已不存在的缺陷。

但是这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑的各种情况都

还是非常多的。

复杂的软件缺陷生命周期：

1、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，不是代码问题，就

是设计需要修改；

2、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，以后修改的，就可

以延期；

3、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，实际没有这个bug，

可以将其关闭；

4、新建一个软件缺陷，这个软件缺陷是（open）状态，看是否清楚可重现，如果不能重现，

就是缺少信息，需要返回到（open）状态；如果能够重现，就进行修正，修正后关闭，进行

回归测试。

15.测试分析测试用例注意（事项）？

1.为什么要写用例：

我们编写测试用例，有如下的好处：

便于团队交流：

假如说一个测试团队有10个成员，大家测试的时候都各自为政，没有统一

的标准，测试的效率无疑会大打折扣；如果大家都遵循统一的用例规范去写，就会解决这一

问题。

便于重复测试：

大家知道，软件在实际开发过程中是会有不同版本的，比如会从1.0升级

到10.0，那么如果不写测试用例的话，在测试10.0版本的时候，你能完全记得1.0版本时你

做过哪些测试吗？

测试用例就像一个备忘录一样，便于重复测试。

便于跟踪统计：

这一点是针对测试经理或是项目经理来说的，项目负责人通过看测试用例的

执行情况，就能了解到项目目前的概况，比如已经执行了哪些测试，还有哪些测试没有执行，

测试没有通过的地方主要集中在哪些模块等。

便于用户自测：

尤其是项目软件，有的时候用户希望自己测试一下软件产品，但是用户大都

是非专业人士，他需要根据你写好的用例来更好的检验产品的质量

说了这么多编写测试用例的优点，那它有没有缺点呢？

有一个明显的缺点就是需要花费大量

的时间，通常编写测试用例的时间比实际执行测试的时间还要长，这一点大家会在实际工作

中有深刻的体会

2.什么时候写用例：

什么时候写用例？

这个问题没有统一的标准答案，但有一点可以肯定，就是测试用例要尽早

编写。

大家认为在哪个阶段开始写用例比较好呢？

通常，我们都会在测试设计阶段来写用例，即《需求规格说明书》和《测试计划》都已完成

之后

3.由谁来写测试用例

有的读者会说，当然是测试人员来写用例了！

可是测试人员又会有不同的角色，一般分为测试经理，测试设计人员，测试执行人员和测试

工具开发人员等，一般测试用例是由测试设计人员来编写，由测试执行人员来执行，这就要

求测试设计人员有一定的用例设计经验，并对被测试的系统有深入的了解。

但是在很多小公司里面，区分的不是这么明显，一个测试人员往往会身兼数职，既是测试组

长，又是测试设计人员，又是测试执行人员。

项目组里就你一个测试工程师，你不写用例谁

写啊！

4.根据什么写测试用例

我们编写测试用例的唯一标准就是用户需求，具体的参考资料就是《系统需求规格说明书》

和软件原型，其中软件原型指的是没有嵌入全部源代码的软件界面，比如我做一个电子商务

网站，为了尽快能给用户演示，我只是用html语言作一些静态页面，并没有编写动态的程序，这就是一个软件原型，它也看作是需求的一部分。