软件测试面试题集合（一）

1.软件的生命周期（prdctrm）

计划阶段（planning）-〉需求分析（requirement）-〉设计阶段（design）-〉编码

（coding）->测试（testing）->运行与维护（running maintrnacne）

二、问：你在测试中发现了一个bug，可是开发经理认为这不是一个bug，你应该怎样解决？

首先，将问题提交到缺陷管理库里面进行备案。

而后，要获取判断的依据和标准：根据需求说明书、产品说明、原型图、设计文档等，确认实际结果
是否与计划有不一致的地方，提供缺陷是否确认的直接依据；

若是没有文档依据，
1）能够根据同行或相似软件的通常特性来讲明是否存在不一致的地方，来确认是不是缺陷；
2）根据用户的通常使用习惯，来确认是不是缺陷；
3）与设计人员、开发人员和客户表明等相关人员探讨，确认是不是缺陷；
合理的论述，向测试经理说明本身的判断的理由，等待测试经理作出最终决定，若是仍然存在争议，能够经过公司政策所提供的渠道，向上级反映，并有上级作出决定。

三、给你一个网站，你如何测试？

首先，查找需求说明、网站设计等相关文档，分析测试需求。

制定测试计划，肯定测试范围和测试策略，通常包括如下几个部分：功能性测试；界面测试；性
能测试；数据库测试；安全性测试；兼容性测试

设计测试用例：
功能性测试能够包括，但不限于如下几个方面：
连接测试。连接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。
提交功能的测试。
多媒体元素是否能够正确加载和显示。
多语言支持是否可以正确显示选择的语言等。
界面测试能够包括但不限于一下几个方面：

页面是否风格统一，美观
页面布局是否合理，重点内容和热点内容是否突出
控件是否正常使用
对于必须但未安装的控件，是否提供自动下载并安装的功能
文字检查
性能测试通常从如下两个方面考虑：

压力测试；负载测试；强度测试

数据库测试要具体决定是否须要开展。数据库通常须要考虑连结性，对数据的存取操做，数据内

容的验证等方面。

安全性测试：

基本的登陆功能的检查
是否存在溢出错误，致使系统崩溃或者权限泄露
相关开发语言的常见安全性问题检查，例如SQL注入等
若是须要高级的安全性测试，肯定得到专业安全公司的帮助，外包测试，或者获取支持
兼容性测试，根据需求说明的内容，肯定支持的平台组合：

浏览器的兼容性；
操做系统的兼容性；
软件平台的兼容性；
数据库的兼容性
开展测试，并记录缺陷。合理的安排调整测试进度，提早获取测试所需的资源，创建管理体系（

例如，需求变动、风险、配置、测试文档、缺陷报告、人力资源等内容）。

按期评审，对测试进行评估和总结，调整测试的内容。

四、问：一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别?

300个用户在一个客户端上，会占用客户机更多的资源，而影响测试的结果。
线程之间可能发生干扰，而产生一些异常。
300个用户在一个客户端上，须要更大的带宽。
IP地址的问题，可能须要使用IP Spoof来绕过服务器对于单一IP地址最大链接数的限制。
全部用户在一个客户端上，没必要考虑分布式管理的问题；

而用户分布在不一样的客户端上，须要考虑使用控制器来总体调配不一样客户机上的用户。同时，还须要给予相应的权限配置和防火墙设置。

五、软件生存周期及其模型是什么？

软件生存周期（Software life cycle）又称为软件生命期，生存期。是指从造成开发软件概念起

，所开发的软件使用之后，直到失去使用价值消亡为止的整个过程。通常来讲，整个生存周期包

括 ：问题的定义及规划、需求分析/评审、软件设计、软件编码、测试阶段、运行维护 六个时期，每一个时期又划分为若干个阶段。每一个阶段有明确的任务。

周期模型（典型的几种）：

瀑布模型

快速原型模型：快速原型模型容许在需求分析阶段对软件的需求进行初步而非彻底的分析和定义
，快速设计开发出软件系统的原型，该原型向用户展现待开发软件的所有或部分功能和性能；用
户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修
改完善，直至用户满意承认以后，进行软件的完整实现及测试、维护。

迭代模型：迭代包括产生产品发布（稳定、可执行的产品版本）的所有开发活动和要使用该发布
必需的全部其余外围元素。在某种程度上，开发迭代是一次 完整地通过全部工做流程的过程：需
求分析、设计、实施和测试工做流程。实质上，它相似小型的瀑布式项目。RUP认为，全部的阶段
均可以细分为迭代。每一次 的迭代都会产生一个能够发布的产品，这个产品是最终产品的一个子集。

生命周期阶段：
软件计划与可行性分析
需求分析
软件设计
编码
软件测试
运行与维护

六、什么是软件测试？软件测试的目的与原则

定义：
在规定的条件下对程序进行操做，以发现程序错误，衡量软件质量，并对其是否能知足设计要求进行评估的过程。

目的：
测试是程序的执行过程，目的在于发现错误
软件测试为了发现程序中存在的代码或业务逻辑错误
软件测试为了检验产品是否符合用户的需求
软件测试为了提升用户体验

软件测试的原则：

测试应尽早启动、介入（需求分析阶段）
全部的测试应追溯到用户需求
测试证实软件存在缺陷
不可能执行穷尽测试，彻底测试是不可能的，测试须要终止。
二八原则，测试发现的错误中80%极可能的起源于20%的模块中。（缺陷存在群集现象）
对错误结果要进行一个确认的过程（测试的详细数据，截图，前置条件等）
制定严格的测试计划
妥善保管测试过程当中的全部文档
程序员尽可能避免本身的检查程序
设计测试用例是应该考虑到合法的输入和不合法的输入

七、什么是软件质量？

归纳地说，软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。具体地说，软件

质量是软件符合明确叙述的功能和性能需求、文档中明确描述 的开发标准、以及全部专业开发的
软件都应具备的隐含特征的程度。 影响软件质量的主要因素，这些因素是从管理角度对软件质量
的度量。可划分为三组，分别反应用户在使用软件产品时的三种观点。正确性、健壮性、效率、
完整性、可用性、风险（产品运行）；可理解性、可维修性、灵活性、可测试性（产品修改）；
可移植性、可再用性、互运行性（产品转移）。

八、目前主要的测试用例设计方法是什么？

白盒测试：逻辑覆盖、循环覆盖、基本路径覆盖
黑盒测试：边界值分析法、等价类划分、错误猜想法、因果图法、状态图法、测试大纲法、随机
测试、场景法

九、软件的安全性应从哪几个方面去测试？

软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不一样测试策略也不一样。
用户认证安全的测试要考虑问题：
1）明确区分系统中不一样用户权限 、系统中会不会出现用户冲突 、系统会不会因用户的权限的改变形成混乱 、
2）用户登录密码是不是可见、可复制 、是否能够经过绝对途径登录系统（拷贝用户登录后的连接直接进入系统）、
3）用户退出系统后是否删除了全部鉴权标记，是否可使用后退键而不经过输入口令进入 系统 、

系统网络安全的测试要考虑问题 ：
1）测试采起的防御措施是否正确装配好，
2）有关系统的补丁是否打上 、
3）模拟非受权***，
4）看防御系统是否坚固 、
5）采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的******工具***试一下，如今最经常使用的是 NBSI 系列和 IPhacker IP ）
6)采用各类***检查工具检查系统***状况
7)采用各类防外挂工具检查系统各组程序的外挂漏洞

数据库安全考虑问题：
1）系统数据是否机密（好比对银行系统，这一点就特别重要，通常的网站就没有过高要求）
2）系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据 的不
3）完整，对于这个系统的功能实现有了障碍） 、系
4）统数据可管理性 、
5）系统数据的独立性 、
6）系统数据可备份和恢复能力（数据备份是否完整，能否恢复，恢复是否能够完整）

十、什么是测试用例 什么是测试脚本 二者的关系是什么？

用例：
未实施测试而编制的一组测试输入、执行条件、各类环境设置以及预期结果以及指望结果的一个特定的集合。

脚本：
测试脚本是为了进行自动化测试而编写的脚本。

测试脚本的编写必须对应相应的测试用例

十一、简述什么是静态测试、动态测试、黑盒测试、白盒测试、α测试 β测试

静态测试：
是不运行程序自己而寻找程序代码中可能存在的错误或评估程序代码的过程。
动态测试：
是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差别，断定执行结果是
否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能。

黑盒测试：
通常用来确认软件功能的正确性和可操做性,目的是检测软件的各个功能是否能得以实现,把被测试
的程序看成一个黑盒,不考虑其内部结构,在知道该程序的输入和输出之间的关系或程序功能的状况
下,依靠软件规格说明书来肯定测试用例和推断测试结果的正确性。

白盒测试：
根据软件内部的逻辑结构分析来进行测试,是基于代码的测试，测试人员经过阅读程序代码或者通
过使用开发工具中的单步调试来判断软件的质量，通常黑盒测试由项目经理在程序员开发中来实现。

α测试：
是由用户在开发环境下进行的测试，也能够是公司内部的用户在模拟实际操做环境下进行的受控测
试，Alpha测试不能由程序员或测试员完成。

β测试
由软件的一个或多个用户在实际使用环境下进行的测试， 开发者一般不在测试现场，Beta测试
不能由程序员或测试员完成。

十二、软件产品质量特性是什么?

功能性：适应性、准确性、互操做性、依从性、安全性。
可靠性：成熟性、容错性、易恢复性。
可以使用性：易理解性、易学习性、易操做性。
效率：时间特性、资源特性。
可维护性：易分析性、易变动性、稳定性、易测试性。
可移植性： 适应性、易安装性、遵循性、易替换性

1三、软件测试的策略是什么?

软件测试策略：在必定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规
定的软件测试的原则、方式、方法的集合。

1四、软件测试分为几个阶段 各阶段的测试策略和要求是什么?

测试过程会依次经历单元测试、集成测试、系统测试、验收测试四个主要阶段

单元测试：
单元测试是针对软件设计的最小单位––程序模块甚至代码段进行正确性检验的测试工做，一般由开发人员进行。

集成测试：
集成测试是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。因为在
产品提交到测试部门前，产品开发小组都要进行联合调试，所以在大部分企业中集成测试是由开
发人员来完成的。

系统测试：
系统测试是在集成测试经过后进行的，目的是充分运行系统，验证各子系统是否都能正常工做并
完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有
重大的影响。

验收测试：
验收测试以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境。
对于实际项目能够和客户共同进行，对于产品来讲就是最后一次的系统测试。测试内容为对功
能模块的全面测试，尤为要进行文档测试。

单元测试测试策略：
自顶向下的单元测试策略：比孤立单元测试的成本高不少，不是单元测试的一个好的选择。
自底向上的单元测试策略：比较合理的单元测试策略，但测试周期较长。
孤立单元测试策略：最好的单元测试策略。

集成测试的测试策略：
大爆炸集成：适应于一个维护型项目或被测试系统较小
自顶向下集成：适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经
常可能被修改；产口控制组件具备较大的技术风险，须要尽早被验证；但愿尽早能看到产品的系
统功能行为。
自底向上集成：适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。
基于进度的集成
优势：具备较高的并行度；可以有效缩短项目的开发进度。
缺点：桩和驱动工做量较大；有些接口测试不充分；有些测试重复和浪费。

系统测试的测试策略：

数据和数据库完整性测试；功能测试；用户界面测试；性能评测；负载测试；强度测试；容量测
试；安全性和访问控制测试；故障转移和恢复测试；配置测试；安装测试；加密测试；可用性测
试；版本验证测试；文档测试

1五、软件测试各个阶段一般完成什么工做？各个阶段的结果文件是什么？包括什么内容？

单元测试阶段：
各独立单元模块在与系统地其余部分相隔离的状况下进行测试，单元测试针对每个程序模块进
行正确性校验，检查各个程序模块是否正确地实现了规定的功能。生成单元测试报告，提交缺陷
报告。

集成测试阶段：
集成测试是在单元测试的基础上，测试在将全部的软件单元按照概要设计规格说明的要求组装成
模块、子系统或系统的过程当中各部分工做是否达到或实现相应技术指标及要求的活动。该阶段生
成集成测试报告，提交缺陷报告。

系统测试阶段：
将经过确认测试的软件，做为整个给予计算机系统的一个元素，与计算机硬件、外设、某些支持
软件、数据和人员等其余系统元素结合在一块儿，在实际运行环境下，对计算机系统进行全面的功
能覆盖。该阶段须要提交测试总结和缺陷报告。

1六、测试人员在软件开发过程当中的任务是什么？

一、尽量早的找出系统中的Bug；
二、避免软件开发过程当中缺陷的出现；
三、衡量软件的品质，保证系统的质量；
四、关注用户的需求，并保证系统符合用户需求。
总的目标是：确保软件的质量。

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

一条Bug记录最基本应包含：
bug编号；
bug严重级别，优先级；
bug产生的模块；
首先要有bug摘要，阐述bug大致的内容；
bug对应的版本；
bug详细现象描述，包括一些截图、录像....等等；
bug出现时的测试环境，产生的条件即对应操做步骤；

高质量的Bug记录：

1) 通用UI要统1、准确
缺陷报告的UI要与测试的软件UI保持一致，便于查找定位。

2) 尽可能使用业界惯用的表达术语和表达方法
使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。

3) 每条缺陷报告只包括一个缺陷
每条缺陷报告只包括一个缺陷，可使缺陷修正者迅速定位一个缺陷，集中精力每次只修正一个
缺陷。校验者每次只校验一个缺陷是否已经正确修正。

4) 不可重现的缺陷也要报告
首先缺陷报告必须展现重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力以后仍不能重现，
仍然要报告此缺陷，但在报告中要注明没法再现，缺陷出现的频率。

5) 明确指明缺陷类型
根据缺陷的现象，总结判断缺陷的类型。例如，即功能缺陷、界面缺陷、数据缺陷，合理化建议
这是最多见的缺陷或缺陷类型，其余形式的缺陷或缺陷也从属于其中某种形式。

6) 明确指明缺陷严重等级和优先等级时刻明确严重等级和优先等级之间的差异。高严重问题可能

7) 描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置
描述要准确反映缺陷的本质内容，简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试
缺陷，包含缺陷发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮
等控件的名称。

8) 短行之间使用自动数字序号，使用相同的字体、字号、行间距
短行之间使用自动数字序号，使用相同的字体、字号、行间距，能够保证各条记录格式一致，作
到规范专业。

9) 每个步骤尽可能只记录一个操做保证简洁、条理井然，容易重复操做步骤。

10) 确认步骤完整，准确，简短
保证快速准确的重复缺陷，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。

11) 根据缺陷，可选择是否进行图象捕捉
为了直观的观察缺陷或缺陷现象，一般须要附加缺陷或缺陷出现的界面，以图片的形式做为附件
附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或缺陷本质，能够捕捉缺陷或缺
陷产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置，一般要求附加
中文对照图。
 附加必要的特殊文档和我的建议和注解
若是打开某个特殊的文档而产生的缺陷或缺陷，则必须附加该文档，从而能够迅速再现缺陷或缺
陷。有时，为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现，能够附加我的的修改建议或
注解。

12) 检查拼写和语法缺陷
在提交每条缺陷或缺陷以前，检查拼写和语法，确保内容正确，正确的描述缺陷。

13) 尽可能使用短语和短句，避免复杂句型句式
软件缺陷管理数据库的目的是便于定位缺陷，所以，要求客观的描述操做步骤，不须要修饰性的
词汇和复杂的句型，加强可读性。
以上归纳了报告测试缺陷的规范要求，随着软件的测试要求不一样，测试者通过长期测试，积累了
相应的测试经验，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，常常阅读
、学习其余测试工程师的测试缺陷报告，结合本身之前的测试缺陷报告进行对比和思考，能够不
断提升技巧。

14) 缺陷描述内容
缺陷描述的内容能够包含缺陷操做步骤，实际结果和指望结果。操做步骤能够方便开发人员再现
缺陷进行修正，有些开发的再现缺陷能力不好，虽然他明白你所指的缺陷，但就是没法再现特别
是对系统不熟悉的新加入开发人员，介绍步骤能够方便他们再现。实际结果可让开发明白错误
是什么，指望结果可让开发了解正确的结果应该是如何。

1八、黑盒测试和白盒测试是软件测试的两种基本方法，请分别说明各自的优势和缺点！

黑盒测试的优势有：
比较简单，不须要了解程序内部的代码及实现；
与软件的内部实现无关；
从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；
基于软件开发文档，因此也能知道软件实现了文档中的哪些功能；在作软件自动化测试时较为方便。

黑盒测试的缺点有：
不可能覆盖全部的代码，覆盖率较低，大概只能达到总代码量的30%；
自动化测试的复用性较低。

白盒测试的优势有：
帮助软件测试人员增大代码的覆盖率，提升代码的质量，发现代码中隐 藏的问题。

白盒测试的缺点有：
程序运行会有不少不一样的路径，不可能测试全部的运行路径；
测试基于代码，只能测试开发人员作的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；
系统庞大时，测试开销会很是大。

1九、如何测试一个纸杯？

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

安全性：杯子有没有毒或细菌

可靠性：杯子从不一样高度落下的损坏程度

可移植性：杯子在不一样的地方、温度等环境下是否均可以正常使用

兼容性：杯子是否可以容纳果汁、白水、酒精、汽油等

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

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

疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和状况；盛上汽油（案例二）放24小

时检查泄漏时间和状况等

压力测试：用根针并在针上面不断加剧量，看压强多大时会穿透

20、黑盒测试的测试用例常见设计方法都有哪些？
请分别以具体的例子来讲明这些方法在测试用例设计工做中的应用。

1）等价类划分：
等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中

的错误都是等效的.并合理地假定:测试某等价类的表明值就等于对这一类其它值的测试.所以,可

以把所有输入数据合理划分为若干等价类,在每个等价类中取一个数据做为测试的输入条件,就

能够用少许表明性的测试数据.取得较好的测试结果.等价类划分可有两种不一样的状况:有效等价类

和无效等价类.

2）边界值分析法：
是对等价类划分方法的补充。测试工做经验告诉我,大量的错误是发生在输入

或输出范围的边界上,而不是发生在输入输出范围的内部.所以针对各类边界状况设计测试用例,可

以查出更多的错误.

使用边界值分析方法设计测试用例,首先应肯定边界状况.一般输入和输出等价类的边界,就是应着

重测试的边界状况.应当选取正好等于,刚刚大于或刚刚小于边界的值做为测试数据,而不是选取等

价类中的典型值或任意值做为测试数据.

3）错误猜想法：
基于经验和直觉推测程序中全部可能存在的各类错误, 从而有针对性的设计测试用例的方法.

错误推测方法的基本思想: 列举出程序中全部可能有的错误和容易发生错误的特殊状况,根据他们

选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 之前产品测试中曾经发

现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的状况. 输入表格为空格或输

入表格只有一行. 这些都是容易发生错误的状况. 可选择这些状况下的例子做为测试用例.

4）因果图方法：
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑

输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的状况. 但

要检查输入条件的组合不是一件容易的事情, 即便把全部输入条件划分红等价类,他们之间的组合

状况也至关多. 所以必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动做的形式

来考虑设计测试用例. 这就须要利用因果图（逻辑模型）. 因果图方法最终生成的就是断定表.

它适合于检查程序输入条件的各类组合状况.

5）正交表分析法：可能由于大量的参数的组合而引发测试用例数量上的激增，同时，这些测试用

例并无明显的优先级上的差距，而测试人员又没法完成这么多数量的测试，就能够经过正交表

来进行缩减一些用例，从而达到尽可能少的用例覆盖尽可能大的范围的可能性。

6）场景分析方法：指根据用户场景来模拟用户的操做步骤，这个比较相似因果图，可是可能执行

的深度和可行性更好。

7）状态图法：
经过输入条件和系统需求说明获得被测系统的全部状态，经过输入条件和状态得出

输出条件；经过输入条件、输出条件和状态得出被测系统的测试用例。

8）大纲法：
大纲法是一种着眼于需求的方法，为了列出各类测试条件，就将需求转换为大纲的形

式。大纲表示为树状结构，在根和每一个叶子结点之间存在惟一的路径。大纲中的每条路径定义了

一个特定的输入条件集合，用于定义测试用例。树中叶子的数目或大纲中的路径给出了测试全部

功能所需测试用例的大体数量。