软件测试面试五

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

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

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

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

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

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

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

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

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

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

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

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

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

数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内

容的验证等方面。

安全性测试：

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

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

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

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

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

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

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

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

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

，所开发的软件使用以后，直到失去使用价值消亡为止的整个过程。一般来说，整个生存周期包

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

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

瀑布模型

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

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

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

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

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

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

软件测试的原则：

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

7、什么是软件质量？

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

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

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

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

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

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

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

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

10、什么是测试用例 什么是测试脚本 两者的关系是什么？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

系统测试的测试策略：

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

15、软件测试各个阶段通常完成什么工作？各个阶段的结果文件是什么？包括什么内容？

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

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

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

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

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

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

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

高质量的Bug记录：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19、如何测试一个纸杯？

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

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

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

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

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

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

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

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

时检查泄漏时间和情况等

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

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

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

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

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

可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类

和无效等价类.

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

或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可

以查出更多的错误.

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

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

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

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

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

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

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

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

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

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

要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合

情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式

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

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

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

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

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

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

的深度和可行性更好。

7）状态图法：
通过输入条件和系统需求说明得到被测系统的所有状态，通过输入条件和状态得出

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

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

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

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

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