软件测试面试理论基础（上篇）

测试团队中都有哪些角色？各负责什么任务？各有多少人？

测试负责人：制定测试计划，监督安排任务，进行测试总结

测试工程师：进行测试需求分析、设计用例、搭建环境、执行用例、提交并跟踪缺陷

技术支持：负责环境维护，1 配置管理员：维护版本架构，维护版本库，文档配置

质量保证人员：负责软件质量方面的工作

什么是软件开发生命周期？

从软件最初构思到公开发行的过程。

瀑布模型的过程是计划、需求、设计、编码、测试、运行、维护循环。瀑布模型有严格的开发步骤，每个阶段是按顺序进行的，每个阶段都必须编写完整的文档，每个阶段完成后必须经过审查才能进入下一步。瀑布模型不能迭代、不能反复；测试在编码之后，测试太晚；测试的只是程序。

软件开发有什么模型？软件测试主要有哪些模型？

软件开发模型：大爆炸模型、边写边改模型、瀑布模型、螺旋模型、敏捷开发模型 软件测试模型：V 模型、W 模型、H 模型、X 模型、前置测试模型、敏捷测试模型

简述 V 模型。

V 模型的过程：用户需求 → 需求分析 → 概要设计 → 详细设计 → 编码 → 单元测试 → 集成测 试 → 系统测试 → 验收测试。

优点：

V 的左端表示传统的瀑布开发模型，V 的右端明确地将测试分为不同的级别或阶 段，测试过程更为具体；

测试各个阶段和开发的各个阶段相对应；

V 模型的测试策略包括低层测试和高层测试，低层测试是为了源代码的正确性， 高层测试是为了整个系统满足用户的需求。

缺点：

测试的对象就是程序本身。忽视了测试活动对需求分析，系统设计等活动的验证 和确认的功能，直到后期的验收测试才被发现。

测试是开发之后的一个阶段。实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。

简述 W 模型。

W 模型的过程：左边 V 是需求分析 → 概要设计 → 详细设计 → 编码实现 → 模块集成 → 系 统构建 → 系统安装；右边 V 是需求测试 → 概要设计测试 → 详细设计测试 → 单元测试 → 集成 测试 → 系统测试 → 验收测试。

优点：

W 模型体现了尽早和不断测试的原则，既强调测试方案设计，也强调测试执行。

左侧 V 是开发，右侧 V 是与开发并行的测试，相对于 V 模型，W 模型增加了软件 各开发阶段中应同步进行的验证和确认活动，W 明确表示出了测试与开发的并行关系。测 试与开发是同步进行的，有利于尽早地全面地发现问题。测试伴随整个软件开发周期，且测试的对象不仅仅是程序，需求、设计等同样要 测试。

缺点：

在 W 模型中，需求、设计、编码等活动被视为串行的，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代 开发模型，不利于当前软件开发复杂多变的情况。

简述 H 模型。

H 模型将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

H 模型的测试流程是只要测试准备工作完成，达到测试就绪点，测试就可以执行了。

优点：

软件测试不仅仅指测试的执行，还包括很多其他的活动。- 软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。

H 模型反映出软件测试要尽早准备，尽早执行。

软件测试可以进行迭代、反复进行。

敏捷开发

敏捷开发的核心思想是：以人为本，适应变化。具体讲：

认为个体和交互重于过程和工具，强调通过过程和工具理解个人和交流的作用；

认为可用软件重于完备文档，强调通过全面的文档理解运行的软件；

认为客户协作重于合同谈判，强调通过合同和谈判得到客户的协作；

认为响应变化重于遵循计划，强调在计划的执行中做出对变更的响应。

特点：

敏捷开发提倡迭代式和增量式的开发模式，并强调测试在其中的重要作用。

敏捷开发是以用户为中心、以客户需求为导向的开发过程，在此过程中随时做好 “迎接变化”的准备，客户是敏捷的关键环节。

敏捷开发没有单一固定的开发方法或过程，敏捷开发有三个共同点：依赖客户的 参与、测试驱动以及紧凑的迭代开发周期。

敏捷测试

1. 敏捷测试是协同测试的一种形式，程序员结对编程，程序员分饰测试员角色，敏 捷测试是连续测试。
2. 敏捷测试侧重单元测试和验收测试。单元测试的过程是先设计单元测试用例，然 后进行编码，之后执行测试。
3. 敏捷测试强调客户参与，单元测试通过之后代码集成到代码库中，再由客户进行 验收测试，验收测试的结论反馈给开发人员，缺陷得以迅速修复。

软件质量要求有哪些？

功能要求和非功能要求。

软件非功能要求有哪些？

性能要求（负载测试、压力测试、容量测试、可靠性测试）、界面测试、兼容性测试、易用性测试、文档测试、可用性测试、安装测试、安全测试、灾难恢复测试等。

简述测试的基本过程

1. 测试人员进行测试需求分析。
2. 测试负责人编写测试计划。
3. 测试人员根据测试需求分析设计和编写测试用例。
4. 测试人员搭建测试环境、创建测试数据、执行测试用例、提交缺陷 告并进行跟 踪、记录测试事件。
5. 进行测试评估和总结。每一分步工作完成后都进行评审。

拿到一个软件后，应该怎样开始工作？

编写需求分析并评审

编写测试计划并评审

设计测试用例并评审

搭建测试环境、执行测试用例、提交缺陷 告

进行评估和总结

怎么做测试？

编写需求分析并评审

编写测试计划并评审

设计测试用例并评审

搭建测试环境、执 行测试用例、提交缺陷 告

进行评估和总结

简介测试流程

编写需求分析并评审

编写测试计划并评审

设计测试用例并评审

搭建测试环境、执 行测试用例、提交缺陷 告

进行评估和总结。

怎么进行测试需求分析？

收集各类文档，仔细阅读文档，提出问题，分析问题或沟通解决，整理需求信息。

编写测试需求分析说明书：功能分解，编写检查点和测试点。

需求评审。

拿到项目后，需要分析或咨询软件哪些方面的问题？

软件主要的功能、流程、开发环境（开发语言<含数据类型>、数据库、中间件）、运行 环境（硬件、软件、 络、软件架构）、用户群、测试范围、测试优先级。

什么时候提交发现的缺陷？

测试执行发现缺陷时立即提交缺陷。

什么是入口准则、出口准则？

入口准则是进行一项测试工作前需要准备好的前提条件。出口准则是一项测试工作可以结束的前提条件。

需求评审都有哪些人参与？

项目经理、开发经理、测试经理、测试人员、开发人员、市场经理、客户等。

怎么做需求评审或者说需求评审需要评审哪些方面？

编写或设计需求评审检查单，比如可以检查有无错别字、病句，标点符 使用是否正确， 格式是否一致，是否还有多余需求，是否有错误需求，是否有遗漏需求等。

测试资源需求有哪些方面？

人力资源、硬件资源、软件资源。

什么是测试策略？什么是测试范围？

测试策略主要指如何进行某种测试（如功能测试、性能测试、兼容性测试、可用性测试、易用性测试等），用于说明测试方法以及如何使用测试方法。

测试范围有时候等价于测试策略，有时候可以表示要进行测试的某个软件部位。

什么是冒烟测试？版本验证测试？怎么测？

冒烟测试用例是一组，想先运行以确定这个给出的小版本是否可以测试的测试用例。

冒烟测试主要测试软件的基本功能，以判断整个软件值不值得进行大规模测试。通常由一个人进行1-2 小时的测试，一般不测试次要功能和各种错误。

测试计划的内容和目的是什么？

包含了产品概述、测试区域/测试策略/测试范围/测试目标（测试项、被测特征）、测试 配置/测试资源、测试周期、进度安排（测试任务、人员安排）、测试方法/途径、测试交流、 风险分析等内容。

目的是指导测试过程，规定测试活动的范围、方法、资源和进度；明确正 在测试的项目、要测试的特性、要执行的测试任务、每个任务的责任人以及与计划相关的风 险。

怎么判断是不是软件缺陷？

软件未达到产品说明书标明的功能；

软件出现了产品说明书指明不会出现的错误；

软件功能超出产品说明书指明范围；

软件未达到产品说明书虽未指出但应达到的目标；

软件测试员具体问题具体分析，认为软件难以理解、不易使用、运行速度缓慢， 或者最终用户认为不好。

缺陷的产生主要有哪些原因？最主要的原因是什么？

需求频繁变更、沟通不良、不了解客户的需求、实现新功能或很酷的功能、追求新技术、项目期限的压力、需求分析或设计投入的时间和精力不够、产品的复杂度、开发人员疲劳、 压力过大或受到干扰、缺乏足够的知识、技能和经验、缺乏动力等。最主要的原因：需求方面的原因

当你发现一个缺陷时，应该怎么确认的确是一个缺陷？

根据缺陷的判断原则来甄别发现的问题是不是一个缺陷，发现缺陷后，应该做好分离和再现（3 次），记录错误现象或是日志，然后才能提交。

在正式提交一个缺陷前，你应该做些什么？

分离缺陷、再现缺陷（3 次），然后才能提交。

怎么处理无法再现的缺陷？

首先，应当对这样的缺陷进行详细的记录，并尽快提交给开发人员。

其次，对于寻找难以再现的缺陷要合理地安排时间，对一时难以再现的缺陷可以暂时搁置，以保证项目的正常进度。

最后，在测试过程中对未再现缺陷予以关注。

什么是重复缺陷？怎么避免重复缺陷？

提交了一个缺陷库中存在或者开发人员已经知道的缺陷。

如果缺陷是跟同事提交的重复，任务分工解决，也可以在提交之前查询下库缺陷是否存在。

如果缺陷是与自己提交的缺陷重复，则需要提高发现缺陷的能力，通过提高开发能力来理解两个缺陷本质上是一个缺陷。

什么是无效缺陷？怎么避免无效缺陷？

提交的缺陷不是真正的缺陷。

1. 充分了解需求、提高自己识别缺陷的能力、提高缺陷的写作能力
2. 缺陷 告的写作准则是什么？

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

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

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

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

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

缺陷 告的内容有哪些？

缺陷标题（或者说缺陷摘要、缺陷概述、缺陷基本信息）

预处理、复现步骤、预期结果、实际结果、严重程度、优先级

测试环境、测试版本、测试执行人、注释

缺陷 告的写作需要注意什么问题？

使用准确的描述，针对问题进行总结，不上升到个人。

简述缺陷 告的处理流程

软件测试人员提交缺陷 告；

缺陷被修改后由测试人员根据缺陷 告中的修改记录进行返测

返测通过的缺陷 告由负责人关闭；

返测未通过的缺陷 告直接返回开发人员重新修改，然后再由测试人员返测，直到测试和开发达成一致处理意见。

简述重复缺陷的处理流程

提交缺陷、分配缺陷、是重复缺陷、置为无效缺陷。

缺陷按照严重程度可以分为哪些类型？

致命、严重、一般、较小错误、意见建议等

缺陷按照优先级可以分为哪些类型？

缺陷必须立即解决；

缺陷需要正常排队等待修复或列入软件发布清单；

缺陷可以在方便时被纠正；

下一个版本修复；不修复。