软件测试面试问题

测试工程师面试宝典-牛客

测试校招面试-牛客

常见问题

B/S架构和C/S架构区别

• B/S 只需要有操作系统和浏览器就行，可以实现跨平台
  • 客户端零维护
  • 维护成本低
  • 但是个性化能力低
  • 响应速度较慢
• C/S响应速度快，安全性强，一般应用于局域网中，因为要针对不同的操作系统,需要针对性的开发,并且维护成本高

HTTP协议

http协议又叫做超文本传输协议，在做网络请求的时候，我们基本上是使用http协议

http协议包括 请求 和 响应

• 请求中包括:请求地址，请求方式
  • 请求方式包括get请求和post请求
• 响应，主要包含
  • 响应的状态码，像200，304，307，404，500
  • 各种响应头信息，比如设置缓存的响应头，Content-Type内容类型，设置cookie头信息。

常见响应状态码

• 2XX 成功
  • 200 OK，表示从客户端发来的请求在服务器端被正确处理
  • 204 No content，表示请求成功，但响应报文不含实体的主体部分
  • 205 Reset Content，表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容
  • 206 Partial Content，进行范围请求
• 3XX 重定向
  • 301 moved permanently，永久性重定向，表示资源已被分配了新的 URL
  • 302 found，临时性重定向，表示资源临时被分配了新的 URL
  • 303 see other，表示资源存在着另一个 URL，应使用 GET 方法获取资源
  • 304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况
  • 307 temporary redirect，临时重定向，和302含义类似，但是期望客户端保持请求方法不变向新的地址发出请求
• 4XX 客户端错误
  • 400 bad request，请求报文存在语法错误
  • 401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息
  • 403 forbidden，表示对请求资源的访问被服务器拒绝
  • 404 not found，表示在服务器上没有找到请求的资源
• 5XX 服务器错误
  • 500 internal sever error，表示服务器端在执行请求时发生了错误
  • 501 Not Implemented，表示服务器不支持当前请求所需要的某个功能
  • 503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求

POST与GET区别

• Get请求一般是去取获取数据（其实也可以提交，但常见的是获取数据）；Post请求一般是去提交数据。
• Get是不安全的，因为在传输过程，数据被放在请求的URL中；Post的所有操作对用户来说都是不可见的，请求数据是放在body体中（最常用场景，用户登录密码提交，一定是使用post请求的）
• Get传送的数据量较小，这主要是因为受url长度限制；Post传送的数据量较大，一般被默认为不受限制。
• Get请求可以被缓存，Post请求不会被缓存
• Get请求是在地址栏后边跟随请求参数，但是请求参数大小是有限制，不同浏览器是不同的。一般是4KB。
• Post请求主要用于向服务器提交请求参数，请求中会有各种请求头信息，比如支持的数据类型，请求的来源位置，以及Cookie头等相关头信息。

Cookie和Session的区别与联系

• Cookie和Session都是会话技术，Cookie是运行在客户端，Session是运行在服务器端。
• Cookie有大小限制以及浏览器在存cookie的个数也有限制，Session是没有大小限制和服务器的内存大小有关。
• Cookie有安全隐患，通过拦截或本地文件找得到你的cookie后可以进行攻击。
• Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力。

测试的目的

简单地说，就是替用户受过，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求，把尽可能多的问题在产品交给用户之前发现并改正

软件测试分为哪几个阶段？

单元测试、集成测试、系统测试、验收测试。

• 单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试
  • 测试重点是系统的模块，包括子程序的正确性验证等
• 集成测试(组装测试/联合测试)
  • 在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。
  • 一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。
  • 测试重点是模块间的衔接以及参数的传递等
• 系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。
  • 测试重点是整个系统的运行以及与其他软件的兼容性。
  • 系统测试范围功能测试、ui测试、性能测试、容错测试、可用性测试、异常问题测试、稳定性测试、系统稳定性测试、兼容性测试、接口测试、安全性测试、登录权限测试
• 验收测试是软件产品检验的最后一个环节。按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。

其它的几个阶段划分

• 回归测试：是指对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例目的：
  1. 验证之前版本产生的所有缺陷已全部被修复；
  2. 确认修复这些缺陷没有引发新的缺陷
• 冒烟测试：是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。也叫可测性测试。

a测试与ß测试的区别

• а测试 是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试
• ß测试 是一种验收测试。beta测试是指在一个或多个用户的场所进行的测试。

验收测试怎么做？

1. 界面测试；指软件产品所有的页面浏览时功能按钮或者界面是否能正常显示
2. 功能测试；产品的功能是否都能正常实现
3. 性能测试；发现性能瓶颈的过程，包括对CPU、内存、网络环境、版本等多项测试内容
4. 安全测试；产品的信息保密，密码保护等功能的测试

白盒、黑盒和灰盒测试区别

• 黑盒和灰盒的区别

如果某软件包含多个模块，当使用黑盒测试时，你只要关心整个软件系统的边界，无需关心软件系统内部各个模块之间如何协作。而如果使用灰盒测试，则需要关心模块与模块之间的交互

• 白盒和灰盒的区别

在灰盒测试中，你无需关心模块内部的实现细节，对于软件系统的内部模块，灰盒测试依然把它当成一个黑盒来看待。而白盒测试还需要再深入地了解内部模块的实现细节和各个分支

冒烟测试的目的

正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug。

回归测试怎么做？

1. 在测试策略制定阶段，制定回归测试策略
2. 确定需要回归测试的版本
3. 回归测试版本发布，按照回归测试策略执行回归测试
4. 回归测试通过，关闭缺陷跟踪单（问题单）
5. 回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

需求分析的目的

• 把用户需求转化为功能需求：
  1. 对测试范围进度量
  2. 对处理分支进行度量
  3. 对需求业务的场景进行度量
  4. 明确其功能对应的输入、处理和输出
  5. 把隐式需求转变为明确。
• 明确测试活动的五个要素:
  1. 测试需求是什么
  2. 决定怎么测试
  3. 明确测试时间
  4. 确定测试人员
  5. 确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解

测试计划的目的

1. 尽早地明确测试工作内容（范围）、测试工作的方法以及测试工作所需要的各种资源。
2. 所有涉及到测试工作的人员，尽快将下一步测试工作需要考虑的问题和准备的条件落实。
3. 测试计划工作的重点在于：对当前工作任务的准备和规划以及信息的交流。

测试计划的内容

1. 测试目标：对测试目标进行简要的描述。
2. 测试概要：摘要说明所需测试的软件、名词解释、以及提及所参考的相关文档。
3. 测试范围：测试计划所包含的测试软件需测试的范围和优先级，哪些需要重点测试、哪些无需测试或无法测试或推迟测试。
4. 重点事项：列出需要测试的软件的所有的主要功能和测试重点，这部分应该能和测试案例设计相对应和互相检查。
5. 质量目标：制定测试软件的产品质量目标和软件测试目标。
6. 资源需求：进行测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等。
7. 人员组织：需要多少人进行测试，各自的角色和责任，他们是否需要进行相关的学习和培训，什么时候他们需要开始，并将持续多长时间。
8. 测试策略：制定测试整体策略、所使用的测试技术和方法。
9. 发布提交：在按照测试计划进行测试发布后需要交付的软件产品、测试案例、测试数据及相关文档。
10. 测试进度和任务人员安排：将测试的计划合理的分配到不同的测试人员，并注意先后顺序.如果开发的Release不确定，可以给出测试的时间段.对于长期大型的测试计划，可以使用里程碑来表示进度的变化
11. 测试开始/完成/延迟/继续的标准：制定测试开始和完成的标准；某些时候，测试计划会因某种原因(过多阻塞性的Bug)而导致延迟，问题解决后测试继续
12. 风险分析：需要考虑测试计划中可能的风险和解决方法。

结束条件(项目上线的条件)

1. 软件经过充分的测试开发人员测试—〉交叉测试—〉测试人员测试—〉用户的业务专家测试—〉一定数量的用户业务专家集中测试—〉上线前试运行----〉上线。
2. 用户培训管理员，一定厂或地区必须有一个人经过了培训。
3. 基础数据导入完成用户、组织机构、业务数据等基础必须数据导入完成。
4. 授权必须完成
5. 新老系统的切换必须提前演练过，各种老数据的导入工作完成。
6. 应急方案必须有。

常见的测试风险

1. 需求风险
2. 测试用例风险
3. 缺陷风险
4. 代码质量风险
5. 测试环境风险
6. 测试技术风险
7. 回归测试风险
8. 沟通协调风险
9. 研发流程风险
10. 其他不可预计风险

怎样保证覆盖用户需求？

1. 确认需求
2. 梳理需求，确认测试范围
3. 制定测试计划
4. 根据测试计划编写测试用例
5. 执行测试步骤

什么时候用到场景法

场景法适用于解决业务流程清晰和业务比较复杂的系统或功能，场景法是一种基于软件业务的测试方法。使用场景法，目的是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。例：语音通话典型业务流程就把语音通话、同振顺振、语音留言、呼叫保持、呼叫转移这些功能都串到一起来。基本上每个软件都会用到场景法，因为每个软件背后都有业务的支撑。场景法主要用来测试软件的业务逻辑和业务流程。当拿到一个测试任务时，我们并不是先关注某个控件的细节测试（等价类+边界值+判定表等），而是要先关注主要业务流程和主要功能是否正确实现，这就需要使用场景法。当业务流程和主要功能没有问题，我们再从等价类、边界值、判定表等方面对控件细节进行测试（先整体后细节）。Note：场景法测试用例设计的重点是测试业务流程是否正确，测试时需要注意的是，业务流程测试没有问题并不代表系统的功能都正确，还必须对单个功能进行详细的测试，这样才能保证测试的充分性。

产品在上线后用户发现bug，这时测试人员应做哪些工作？

1. 测试人员复现问题后，提交问题单进行跟踪
2. 评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能
3. 问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试
4. 总结经验，分析问题发生的原因，避免下次出现同样问题。

二八定理

缺陷往往喜欢扎堆，一个模块已经发现的缺陷比别的模块多，通常不是代表这个模块已经把缺陷暴露完了，而是意味着这个模块还存在有同样多的缺陷尚未被发现

这就是著名的二八定理：80%的缺陷出现在 20%的模块。

如何跟踪缺陷

当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试。

缺陷的状态

1. 初始化：缺陷的初始状态
2. 待分配：缺陷等待分配给相关开发人员处理
3. 待修正：缺陷等待开发人员修正
4. 待验证：开发人员已完成修正，等待测试人员验证
5. 待评审：开发人员拒绝修改缺陷，需要评审委员会评审
6. 关闭：缺陷已被处理完成。

缺陷的等级

轻微缺陷、一般缺陷、严重缺陷、致命缺陷

缺陷单应该包含这些要素

缺陷标题、缺陷类型、重现步骤、预期结果、实际结果、缺陷优先级、附件备注

测试报告的主要内容

测试报告包括哪些内容:

• 测试模块（每个模块里需要记录测试的开始时间、结束时间、设计多少用例、通过多少、失败多少、有多少BUG、遗留多少BUG、解决多少BUG、追后对这个模块总结一下）
• BUG的统计，根据时间轴来统计BUG的数量，例如：XXXX年X月X日，发现BUG多少，关闭BUG多少，剩余BUG多少，高级的BUG有多少，中级的BUG有多少，低级和建议的BUG有多少，一直罗列到项目完结项目总结，汇报一下测试的大致结果。
• 遗留和风险，该软件还有什么遗留问题，还有什么风险，都要一一说明最后评判该软件是否符合上线标准，日期，签字，加盖章等

软件测试流程

• 了解用户需求
• 参考需求规格说明书
• 测试计划（人力物力时间进度的安排）
• 编写测试用例
• 评审用例
• 搭建环境
• 测试包安排预测（冒烟测试）-正式测试-bug-测试结束出报告
• 版本上线
• 面向用户

在项目中发现哪些经典bug？什么原因导致的？

编码的问题接口限流防刷的时候，通过计数器限流，如果超过某个阈值，向前端返回一个codeMsg对象用于显示的时候，显示的是String是乱码的问题，之前由于一直返回都是json 格式，都是封装好在data里。这次返回是直接通过输出流直接写到response直接返回字节数组的，而不是spring controller 返回数据（springboot 默认utf-8），出现乱码问题，用utf-8编码，解决。 比较难解决的bug无非就两种，一种就是程序的逻辑出现问题，导致得不到正确的结果，第二种就是一些中间件，开发环境的问题。 （1）如果是逻辑出现了问题，你项目比较大的话，那只能是通过单步调试，或者用System.out.println()打印出来想要得到的数据看看是哪步出了问题。 （2）如果是开发环境或者是中间件的问题，那只能是通过网上查阅资料来解决问题。如果你英语阅读能力还可以的话，我推荐使用Stack Overflow来查阅资料。

软件测试的目的是什么？

1. 为了发现程序中的缺陷，保证软件质量
2. 满足用户需要

软件测试的一般流程是怎么样的？

1. 项目立项后，参加需求评审
2. 根据需求文档制定测试用例，然后进行用例评审
3. 项目提测后，执行用例，问题记录cp4，及时有效的跟进问题的解决情况
4. 测试环境测试通过后，产品进行验收测试

常见的测试类型有哪些？分别说明一下？

1. 黑盒测试，即常说的功能测试
2. 白盒测试，即单元测试，通常由开发来完成，对程序类和方法的测试
3. 兼容性测试，主要是浏览器的兼容测试
4. 集成测试，即各个模块的测试
5. 系统测试，各模块测试完成后，对整个系统的完整性测试
6. 回归测试
7. 验收测试

测试用例设计常用的方法有哪些?详细说明一下?

最常用的3种 等价类划分、边界值、场景法 1.等价类划分 分为有效等价类和无效等价类，将测试的范围划分成几个互不相交的子集，从每个子集选出若干个有代表性的值作为测试用例 2.边界值：选取正好等于、刚刚大于、刚刚小于边界的 3.场景法：划分不同的场景，然后逐一进行验证

解释下单元测试,集成测试,系统测试以及验收测试?

1. 单元测试，通常由开发来完成，对程序类和方法的测试
2. 集成测试，即各个模块的测试
3. 系统测试，各模块测试完成后，对整个系统的完整性测试
4. 验收测试，测试环境测试通过后，由产品或者用户进行验收测试，看看产品的实现，是不是满足了他们当初设计的需求

探索性测试是什么？应该怎么做？

在需求文档不完善或者压根没有需求文档的情况下，根据经验进行摸索尝试性进行的测试，是测试过程中形成的基本的思维性测试

什么是冒烟测试,如何有效的开展冒烟测试?

1. 软件最基本的功能测试，通常由开发完成，只有冒烟点都通过的产品，交由测试，才会比较有意义
2. 冒烟测试贯穿于测试的各个阶段，比如集成测试，系统测试等

一条高质量的缺陷记录(Bug)应该具有哪些内容？

1. 记录bug产生的前提条件
2. 产生bug的详细操作步骤
3. 截图，直观的展示问题，有效帮助开发快速定位问题

缺陷的生命周期是怎样的？

新建--提交--分配--修复--验证--验证通过关闭--验证不通过reopen

Alpha测试与Beta测试的区别？

1. Alpha测试：把用户请到开发方的场所来测试，用户在模拟实际操作环境下进行的测试，由开发记录下用户反馈的问题
2. beta测试：当开发和测试根本完成时所做的测试，很多不同的用户，在不同的环境下操作，然后用户把产生的问题，定期发给开发者，进行修复（开发不在现场
3. 通常现有alpha测试，后有bata测试

测试用例设计问题

测试用例是什么？如何设计有效的测试用例？

为了测试某个产品，编制的一组测试输入、执行条件以及预期结果

设计有效的测试用例：

1. 明确需求，清晰的知道需求要实现哪些功能
2. 根据需求文档，拆分出功能点和测试测试要点
3. 详细的梳理业务需求，设计不同的业务场景，尽可能多的覆盖，尤其重要的逻辑，颗粒度要精细
4. 具体逻辑的设计方法，遵循边界分析法，出问题最多的就在边界值，然后用等价类划分方法补充一些测试用例
5. UI测试，界面元素测试+样式+操作控件设计+浏览器兼容性相关的用例
6. 时间充足的情况下，设计接口的测试用例，从而保证接口数据的用等价类划分方法补充一些测试用例完整性和正确性--目前携程提倡测试先行的概念，接口要在项目提测前，完成api自动化测试

测试用例的要素

1. 用例编号
2. 测试模块
3. 用例的标题
4. 测试级别
5. 测试目的和条件
6. 测试输入
7. 操作步骤
8. 预期结果

写好测试用例的关键 /写好用例要关注的维度

• 测试前：
  1. 对测试目的有一个清晰的认知
  2. 熟悉产品的功能测试点
  3. 熟悉模块原理，避免“互相影响”问题的产生
  4. 关注用户场景问题和上网问题
  5. 不可马虎的关键测试用例设计
• 编写测试用例时:
  1. 构建测试用例框架
  2. 测试步骤的设计（一是如果步骤过于粗糙很容易出现漏测问题；二是写的过于细致，可能耗时耗力，并且会限制执行人员的思维。）
  3. 测试用例设计方法及思考1.切记产品测试的主要目标 2. 注意用词精准问题

常见的测试用例设计方法

• 等价类划分
• 边界值分析
• 错误推断法
• 判定法表
• 正交实验法

测试用例级别的划分

• 测试用例优先级的目的：测试用例优先级可以用来方便地基于测试策略来筛选用例。
  • 比如某块功能改动小，就只用测高或中高优先级的用例。
  • 比如冒烟测试的时候我们只需要筛选优先级最高的用例执行即可。
• 根据我们测试用例优先级目的：那么优先级越高的测试用例覆盖的测试点应该是用户最关心的
  • 比如一个注册功能， 能够注册成功这个用例的优先级就是最高的（但是不是所有的注册成功的case都是优先级最高，只需要挑选一个即可）
  • 其他各种异常校验都是次要优先级的， 还有一些场景覆盖的测试点很难出现，或者叫就算有问题影响也不大， 可以放到低优先级

输入三个整数,判断是否构成有效的三角形,针对这个设计测试用例

首先要设计满足三角形的条件，输入的三个数必须大于0，且同时满足任意两边之和大于第三边。

• 假设三条边是A/B/C，则要满足的条件为A>0，B>0，C>0，A+B>C,A+C>B,B+C>A。以此为例来进行设计即可 有效等价类：A>0，B>0，C>0

针对文件上传功能，设计下测试用例

针对网上购物中订单提交的过程，设计测试用例

操作系统问题

列出超过10个Linux常用的命令以及其作用?

进程和线程是什么?它们有什么区别和联系?

软件测试基本概念

github

软件测试分类

• 黑盒测试：指的是把被测试的软件看做是一个黑盒子，我们不关心里面的结构是什么样的，只关心软件输入数据和输出结果

  • 黑盒测试技术：等价类划分、边界值、因果图、流程图

• 白盒测试：指的是把盒子盖打开，去研究里面的源代码和程序结构。

• 静态测试：是指不实际运行被测软件，而只是静态的检查程序代码、界面或文档中可能存在的错误的过程

• 动态测试：是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程

👆 我们判断一个测试属于动态测试还是静态测试的唯一标准就是看是否运行程序

注意：同一个测试既有可能属于黑盒测试，也有可能属于动态测试；既有可能属于静态测试，也有可能属于白盒测试。它们之间也有可能交叉

---

1. 单元测试：指的是对软件中最小可测试单元进行检查和验证

2. 集成测试：是单元测试的下一个阶段，是指将通过测试的单元模块组成系统或子系统，再进行测试，重点测试不同模块的接口部分

3. 系统测试：指的是将整个软件系统看作1个整体进行测试，包括功能、性能，以及软件所有运行的硬件环境进行测试。

4. 验收测试：指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试它也是软件正式交付给用户使用的最后一道工序

• 验收测试又分为α测试和β测试，

• α测试指的是由用户、测试人员、开发人员等共同参与的内部测试

• β测试指的是内测后的公测，即完全交给最终的用户测试。

• 功能测试：是黑盒测试的一方面，它检测实际软件的功能是否符合用户的需求。功能测试又能细分为很多种：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试等。

• 性能测试：软件的性能包括很多方面，主要有时间性能和空间性能两种

  • 时间性能：主要指软件的一个具体事务的响应时间。
  • 空间性能：主要指软件运行时所消耗的系统资源
  • 软件性能测试一般分为一般性能测试、稳定性能测试、负载测试和压力测试

  1. 一般性能测试：让系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试

  2. 稳定性能测试（又称可靠性测试）：连续运行内测系统，检查系统运行的时间稳定程度。通常用MTBF（错误发生的平均时间间隔）来衡量系统的稳定性，越大稳定性越强

  3. 负载测试：让被测系统在其能忍受的极限范围之内连续运行，来测试系统的稳定性

  4. 压力测试：连续不断的给被测系统增加压力，直到被测系统压垮为止，用来测试系统所能承受的最大压力

关于性能测试，可以用一个通俗的例子来理解：
假设一个人很轻松就能背一袋米，背两袋米很吃力，最多就能背三袋米，那么

一般性能测试————我就让他背一袋米。
稳定性测试—————我让他背一袋米，让他去操场上跑圈，看多久累倒。
负载测试————让他背两袋米去操场去跑圈，看多久累倒。
压力测试————让他背两袋米，三袋米，四袋米·····发现他最多只能背三袋米。

• 回归测试：是指对软件的新的版本测试时，重复执行上一个版本测试时的用例
• 冒烟测试：指对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否可以实现，是否具备可测性。
• 随机测试（又称猴子测试）：指测试中所有的输入数据都是随机生产的，其目的是模拟用户的真实操作，并发现边缘错误
  • 随机测试的缺点：测试不系统，无法统计代码覆盖率和需求覆盖率，很难回归测试等

软件失效

软件失效机制可以描述为：软件错误->软件缺陷->软件故障->软件失效

• 软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可 见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。
• 软件缺陷存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差。其结果是软件运 行于某一特定条件时出现软件故障，这时称软件缺陷阶段。
• 软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。
• 软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。

错误的定义是：不正确的事务和行为。错误是在系统运行时，引起或可能潜在地引起失效的缺陷，是一种面向开发概念。

软件缺陷：

• 软件未达到产品说明书中标明的功能；
• 软件出现了产品说明书中指明的不会出现的错误；
• 软件功能超出了产品说明书指明的范围；
• 软件未达到产品说明书虽未指出应达到的目标；
• 软件测试人员认为软件难以理解、不易使用、运行速度慢，或最终用户认为不好使用。

产品说明书是软件缺陷的第一来源，也就出自于软件需求说明书本身的问题。

设计方案（软件设计说明书）是软件缺陷第二来源

缺陷与错误严重性和优先级

软件缺陷和错误会带来软件失效的风险，重要软件故障与失效会导致重大的经济损失与灾难。给软件缺陷与错误划分严重性和优先级的通用原则是：

• 表示软件缺陷所造成的危害的恶劣程度；
• 优先级表示修复缺陷的重要程度和次序；

严重级：

• 严重：系统崩溃、数据丢失、数据毁坏
• 较严重：操作性错误、错误结果、遗漏功能
• 一般：小问题、错别字、UI 布局、罕见故障
• 建议：不影响使用的瑕疵或更好的实现

优先级：

• 最高优先级：立即修复，停止进一步测试
• 次高优先级：在产品发布之前必须修复
• 中等优先级：如果时间允许应该修复
• 最低等优先级：可能会修复，但是也能发布