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.一个有广告的纸杯子，请设计测试用例？