2万字软件测试面试题干货带答案，反手我就一个收藏

一、 测试流程

1.软件测试的基本流程有哪些？

需求分析、编写测试用例、评审测试用例、搭建环境、等待程序开发包、部署程序开发包、冒烟测试、执行具体的测试用例细节、Bug 跟踪处理回归测试、N 轮之后满足需求，测试结束

2.测试结束的标准是什么？

第一类标准：测试超过了预定时间，则停止测试。

第二类标准：执行了所有的测试用例，但并没有发现故障，则停止测试。

第三类标准：使用特定的测试用例设计方案作为判断测试停止的基础

第四类标准：正面指出停止测试的具体要求，即停止测试的标准可定义为查出某一预订数目的故障。

第五类标准：根据单位时间内查出故障的数量决定是否停止测试

3.软件测试的原则是什么？

1) 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。

2) 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。

3) 程序员应避免检查自己的程序。

4) 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。

5) 软件测试的原则

6) 充分注意测试中的群集现象。 经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。

7) 严格执行测试计划，排除测试的随意性。

8) 应当对每一个测试结果做全面检查。

9) 妥善保存测试计划，测试用例，出错统计和最终分析 告，为维护提供方便。

二、 用例设计

1.什么是测试用例，测试用例的基本要素？

测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

测试用例的基本元素： 测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。

2.描述测试用例设计的完整过程？

首先根据需求文档、概要设计、测试计划、测试方案细分出各功能模块的测试项

再根据各测试项，按照概要设计、详细设计以及测试方案中测试的覆盖率细分出测试子项

最后按照测试子项、根据测试用例的设计方法（因果图、边界值、等价类等的设计方法）书写测试用例。

注意

选用适合的用例管理工具（如 word，excel）

用例一定要及时更新（补充新的想法，删除过时的需求）

做好用例分级

做好用例评审，写用例之前可以征询相关人员的意见，如果评审通过可以参考其执行测试，如果未通过， 需要继续修改直到通过为止。

可以考虑结对编写，这个是不错的主意

要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等

注意把握适当的颗粒度

3.好的测试用例有哪些特点？

质量属性：

正确性：确保测试标题描述部分的内容正确性。

经济性：只为确定需要的目的设计相应的测试步骤。

可重复性：自我一致性，即不管谁执行此用例，结果一样。

适应性：既能适应短期需要，又能考虑长远需要。

可追踪性：用例能追踪到一个具体的需求。

自我清理性：单个用例不会影响整个测试环境，即用例执行完了可以恢复原有的测试环境。

结构化和可测试性

含有规范的测试标题和编 。

含有一个确定的测试某一个特定需求的目的。

含有关于测试方法的描述。

指定条件信息-环境、数据、预置的条件测试、安全入口等。

含有操作步骤和预期结果。

陈述任何辅助证据，例如截图 告并确保这些东西妥善保存。

确保测试环境的干净（即用例不会影响整个环境）。

描述时使用主动语气结构。

操作步骤不要超过 15 步。

确保单个用例测试执行时用时不超过 20 分钟。

自动化脚本用例添加必要的注释，比如目的、输入和期望结果。

如果可能，建议提供可选择性的预置条件测试。

用例之间的先后顺序是否跟业务流程一致，即用例在业务流程中的彼此顺序关系是否合理。

配置管理：

采用命名和编 规范归档。

保存为特定的格式，文件类型。

用例版本是否与当前被测试软件版本一致（对应）。

包含用例需要的相应测试对象，如特定数据库。

存档阅读。

存档时按角色控制访问方式

当 络备份时存档。

离线归档

4.写测试用例时要注意什么问题

1、复用率：如果随着产品不停得升级，需要设计的详细些，追求一劳永逸；仅使用一两次，则没有必要设计的过于详细；

2、项目进展：项目时间如果允许可以设计的详细些，反之则能执行即可；

3、使用对象：测试用例如果供多人使用，尤其让后参加测试的工程师来执行，则需要设计的详细些。

4、用例的冗余

5、操作步骤要细分简明，可执行

5.如何在有限的情况下提高测试效率，保证产品的上线质量？

1、一个详细合理的详细的测试计划

2、测试尽早的介入项目，连接项目的业务需求，做好测试的前期准备

3、对测试项目前景充满信心，调整最佳心态，保持愉悦的工作心情

4、提高测试接受的标准，减少测试版本的送测次数

6.如何降低漏测率

1、需求评审

2、梳理需求，尽早与开发人员、需求人员进行需求确认，统一不同角色对需求的认识

3、用例设计及评审

4、测试执行

5、bug 回归

6、发布前的功能回归

7.测试用例的基本设计方法

1、等价类划分法

2、边界值分析法

3、错误推断法

4、因果图判定表法

5、正交实验法

6、流程法

7、场景法

8.测试为什么要写测试用例

1、深入了解需求的过程

2、测试执行的指导

3、规划测试数据的准备

4、反应测试进度

5、举一反三发现隐藏缺陷

6、分析缺陷标准

三、 缺陷 bug

1.什么是缺陷 告，缺陷 告的作用，缺陷 告的要点

(1)缺陷 告是描述软件缺陷现象和重现步骤的集合。软件缺陷 告 Software Bug Report(SBR)或软件问题 告 software Problem Report(SPR)。

(2)缺陷 告是软件测试人员的工作成果之一，体现软件测试的价值缺陷 告可以把软件存在的缺陷准确的描述

出来，便于开发人员修正缺陷 告可以反映项目/产品当前的质量状态，便于项目整体进度和质量控制软件测试缺陷

告是软件测试的输出成果之一，可以衡量测试人员的工作能力。

(3)标题(Title)简洁、准确、完整、反映缺陷本质、方便查询前缀+标题正文，标题正文采用结果和动作，或者现象和位置的方式表达；步骤(Steps)可复现、完整、简洁、准确按数字编 ；实际结果(Actual results)准确、详细描述软件的现象和特征；期望结果(Expected results)准确、丰富、有理有据；平台(Platforms)准确；截图 (Sereenshots)准确反映缺陷特征；注释(Notes)关于缺陷的辅助说明

2.软件测试缺陷 告的 5C 原则

Correct（准确）：每个组成部分的描述准确，不会引起误解；

Clear（清晰）：每个组成部分的描述清晰，易于理解；

Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；

Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；

Consistent（一致）：按照一致的格式书写全部缺陷 告。

3.测试为什么要写测试用例

1、深入了解需求的过程

2、测试执行的指导

3、规划测试数据的准备

4、反应测试进度

5、举一反三发现隐藏缺陷

6、分析缺陷标准

四、 缺陷 bug

1.什么是缺陷 告，缺陷 告的作用，缺陷 告的要点

(1)缺陷 告是描述软件缺陷现象和重现步骤的集合。软件缺陷 告 Software Bug Report(SBR)或软件问题

告 software Problem Report(SPR)。

(2)缺陷 告是软件测试人员的工作成果之一，体现软件测试的价值缺陷 告可以把软件存在的缺陷准确的描述

出来，便于开发人员修正缺陷 告可以反映项目/产品当前的质量状态，便于项目整体进度和质量控制软件测试缺陷

告是软件测试的输出成果之一，可以衡量测试人员的工作能力。

(3)标题(Title)简洁、准确、完整、反映缺陷本质、方便查询前缀+标题正文，标题正文采用结果和动作，或者

现象和位置的方式表达；步骤(Steps)可复现、完整、简洁、准确按数字编 ；实际结果(Actual results)准确、详

细描述软件的现象和特征；期望结果(Expected results)准确、丰富、有理有据；平台(Platforms)准确；截图

(Sereenshots)准确反映缺陷特征；注释(Notes)关于缺陷的辅助说明

2.软件测试缺陷 告的 5C 原则

Correct（准确）：每个组成部分的描述准确，不会引起误解；

Clear（清晰）：每个组成部分的描述清晰，易于理解；

Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；

Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；

Consistent（一致）：按照一致的格式书写全部缺陷 告。

3.软件缺陷的生命周期？

测试人员提交新的 Bug 入库，错误状态为 New。

高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为 Open。如果不是错误，则拒绝，设置为 Declined(拒绝)状态。

开发人员查询状态为 Open 的 Bug， 如果不是错误，则置状态为 Declined；如果是 Bug 则修复并置状态为 Fixed。不能解决的 Bug，要留下文字说明及保持 Bug 为 Open 状态。对于不能解决和延期解决的 Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。 测试人员查询状态为 Fixed 的 Bug，然后验证 Bug 是否已解决，如解决置 Bug 的状态为 Closed，如没有解决置状态为 Reopen。

4.缺陷描述（ 告单）中应该包括哪些内容？

缺陷的标题，简要描述。缺陷的类型。缺陷的详细步骤描述。缺陷的实际结果。期望结果。有的缺陷需要上传

截图，日志信息。缺陷的等级。缺陷指派给开发同事。（开发主管）

5.如何提高缺陷的记录质量？

通用 UI 要统一、准确；尽量使用业界惯用的表达术语和表达方法；使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化；每条缺陷 告只包括一个缺陷；不可重现的缺陷也要 告；明确指明缺陷类型；明确指明缺陷严重等级和优先等级；描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置；

短行之间使用自动数字序 ，使用相同的字体、字 、行间距； 每一个步骤尽量只记录一个操作；确认步骤完整，准确，简短；根据缺陷，可选择是否进行图象捕捉； 检查拼写和语法缺陷；尽量使用短语和短句，避免复杂句型句式；缺陷描述内容。

6.如果一个缺陷被提交后，开发人员认为不是问题，怎么处理？

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

b)然后，要获取判断的依据和标准：

v.根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；

vi.如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；

vii.根据用户的一般使用习惯，来确认是否是缺陷；

viii.与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；

c)合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不掺杂个人情绪。

d)等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级 做出决定。

7.缺陷的优先级划分和描述

一般来说按照下面的来分，具体的是由每个公司而定。

软件缺陷有四种级别，分别为：致命的(Fatal)，严重的(Critical)，一般的(Major)，微小的(Minor)。

A 类—致命的软件缺陷(Fatal):造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误， 未考虑异常操作，功能错误等

B 类—严重错误的软件缺陷（critical）：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。

问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、 缺省值未加完整性等约束条件

C 类—一般错误的软件缺陷（major）：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等

D 类—较小错误的软件缺陷（Minor）

E 类- 建议问题的软件缺陷（Enhancemental）：由问题提出人对测试对象的改进意见或测试人员提出的建议、质 疑。

五、 测试实例

1.一个有广告的纸杯子，请设计测试用例？

测试项目：杯子

需求测试：查看杯子使用说明书

界面测试：查看杯子外观

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

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

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

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

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

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

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

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

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

跌落测试: 杯子加包装(有填充物),在多高的情况摔下不破损

震动测试: 杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路公路航空运输

基本功能测试（逻辑功能测试）。

（1）硬度：是否达到设计标准。

装载能力：在杯子内分别装入少量的、半杯的、满杯的，看其装载量是否达到设计标准。

装载种类：开水（是否产生异味）、温水、冷水、冰水、咖啡…

（2）界面测试（UI 测试）。

看其形状、大小设计是否适合人方便拿起。

外观是否吸引人（广告嘛），赏心悦目。

带广告的图案沾水受是否掉色、模糊。

（3）易用性测试。

看其形状、大小设计是否适合人方便拿起。

残疾人士用此杯去喝水的容程度。

杯子设计是否上大下小，在运输过程中可以套在一起有效利用空间，在使用时也容易拿开。

（4）稳定性测试（24 X 7 测试）。装入液体后记录其多少以后漏水。

（5）安全性测试。杯子所用的材料（包括纸基、涂层和广告颜料）是否符合食品卫生标准，在内外温度等环境

因素下是否会与所盛各种饮料相反应，而产生对人体有害的物质。

（6）本地化测试。为国际化和本地化的需要，广告图案和文字是否在政治、宗教和文化方面具有广泛的适用性。

（7）对设计的改进建议。“如果是一次性杯子，能否标示已使用（比如变色）”和“杯子是否有使用者标贴（多 人使用时防止混淆）”。

3.一个身份证 码输入框，怎么设计用例？

校验身份证 规则的有效性（包括地址码、生日期码、顺序码和校验码

校验 15 位身份证 和 18 位身份正好都是可用的

校验末位是 X 的情况

校验不足 15 位、16-17 位和大于 18 位的情况

如果是必输项，校验不输入的时候会不会有正确的提示

如果不是必输项，则要校验不输入的时候流程能否正常进行

校验输入非数字的情况，是否会有正确提示信息（包括大小写字母、汉字、特殊字符和标点符 ）

校验输入全角的数字的时候，系统是否会识别（这个得根据需求确定是否可以使用全角的数字）

3.登录功能怎么设计测试用例？

具体需求：

有一个登录页面，有一个账 和一个密码输入框, 一个提交按钮。

此题的考察目的：

1、了解需求（测什么都是从了解需求开始）；

2、是否有设计 Test Case 的能力

3、是否熟悉各种测试方法；

4、是否有丰富的 Web 测试经验；

5、是否了解 Web 开发；

了解需求：

1、登录界面应该是弹出窗口式的，还是直接在 页里面；

2、账 长度和密码的强度（比如需要多少位、大小写敏感、特殊字符混搭等）；

3、界面美观是否有特殊要求？（即是否要进行 UI 测试）；

4、····

用例设计：

测试需求分析完成后，开始用例设计，主要可以从以下几个方面考虑：

功能测试(Function Test)

1、输入正确的账 和密码，点击提交按钮，验证是否能正确登录。（正常输入）

2、输入错误的账 或者密码, 验证登录会失败，并且提示相应的错误信息。（错误校验）

3、登录成功后能否跳转到正确的页面（低）

4、账 和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示）

5、账 和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤）

6、记住账 的功能

7、登录失败后，不能记录密码的功能

8、账 和密码前后有空格的处理

9、密码是否加密显示（星 圆点等）

10、牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按 钮是否好用

11、登录页面中的注册、忘记密码，登出用另一帐 登录等链接是否正确

12、输入密码的时候，大写键盘开启的时候要有提示信息。

13、什么都不输入，点击提交按钮，看提示信息。（非空检查）

界面测试(UI Test)

1、布局是否合理，2 个 Testbox 和一个按钮是否对齐

2、Testbox 和按钮的长度，高度是否符合要求

3、界面的设计风格是否与 UI 的设计风格统一

4、界面中的文字简洁易懂，没有错别字。

性能测试(Performance Test)

1、打开登录页面，需要几秒

2 、输入正确的账 和密码后，登录成功跳转到新页面，不超过 5 秒

安全性测试(Security Test)

1、登录成功后生成的 Cookie 是否有 HttpOnly(降低脚本盗取风险)

2、账 和密码是否通过加密的方式，发送给 Web 服务器

3、账 和密码的验证，应该是用服务器端验证，而不能单单是在客户端用 javaScript 验证

4、账 和密码的输入框，应该屏蔽 SQL 注入攻击

5、账 和密码的输入框，应该禁止输入脚本（防止 XSS 攻击）

6、错误登录的次数限制（防止暴力破解）

7、考虑是否支持多用户在同一机器上登录；

8、考虑一用户在多台机器上登录

可用性测试(Usability Test)

1、是否可以全用键盘操作，是否有快捷键

2、输入账 ，密码后按回车，是否可以登录

3、输入框是否可以以 Tab 键切换

兼容性测试（Compatibility Test）

1、主流的浏览器下能否显示正常已经功能正常（IE6~11, FireFox, Chrome, Safari 等 ）

2、不同的平台是否能正常工作，比如 Windows, Mac

3、移动设备上是否正常工作，比如 iPhone, Android

4、不同的分辨率

本地化测试 （Localization Test）

1、不同语言环境下，页面的显示是否正确。

软件辅助性测试 （Accessibility Test）

软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能

1、高对比度下能否显示正常（视力不好的人使用）

4.移动端和 web 端测试有什么区别

单纯从功能测试的层面上来讲的话，APP 测试、web 测试 在流程和功能测试上是没有区别的。

根据两者载体不一样，则区别如下：

系统结构方面

web 项目，b/s 架构，基于浏览器的；web 测试只要更新了服务器端，客户端就会同步会更新。

app 项目，c/s 结构的，必须要有客户端；app 修改了服务端，则客户端用户所有核心版本都需要进行回归

测试一遍。

性能方面

web 项目