软件测试面试题：缺陷状态的生命周期?

1 缺陷的基本概述 1.1 缺陷的定义 软件未实现产品说明书要求的功能 软件出现了产品说明书指明不应该出现的功能 软件实现了产品说明书未提到的功能 软件未实现产品说明书虽未明确提及但应该实现的功能 软件难以理解、不易使用、运行缓慢或最终用户认为不好 1.2 缺陷的属性 属性名称 描述 缺陷类型（Type） 根据缺陷的自然属性划分的缺陷种类 缺陷严重程度（Severity） 指因缺陷引起的故障对软件产品的影响程度 缺陷优先级（Priority） 指缺陷必须被修复的紧急程度

         在项目开发过程中，我发觉很多人在解决测试人员提出的bug之后，应该将这个bug修改成什么状态不太了解，导致了最后统计bug解决数量，以及遗留bug等等数据不准确。作为开发人员，我觉得了解bug的解决状态是一门基础课程。这里我将开发人员用到的bug解决状态列举出来，希望对大家有所帮助（这些都是开发人员在解决相应bug时应该在测试库中修改的状态）：     FIXED（已解决）：bu

1、Fixed（已修复） 2、Nvalid（无效的） 3、Wontfix（不修复） 4、Later（后面修） 5、Remind（保留） 6、Duplicate（重复的） 7、Worksforme（无法复现） 8、Not Reproducible（无法复现）「其中7和8，觉得8更准确」 ...

一、软件生命周期 软件开发全部过程、活动和任务的结构框架，是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程 软件测试的生命周期图 软件开发过程中，软件测试所做的全部工作可称为软件测试的生命周期 单元测试、集成测试、系统测试都可以再进行四个阶段的划分 测试计划阶段—测试计划 测试设计阶段—测试方案 测试实现阶段—测试用例、测试规程、自动化脚本 测试执行阶段—测试报告 二、缺陷和缺陷报告单 1、缺陷分类 分为5种：BUG，错误（Error），缺陷(De

一个有名的案例研究 1992年AT&T发表了一篇讲述在测试过程中使用正交表一个案例研究。 ​ -它描述了对PC（IBM格式）和StarMail(基于局域网的电子邮件软件) 1、做回归测试： ​ 1、最初制定的测试计划是18周的时间执行1500个测试用例。但是，开发推迟了，测试时间被压缩到仅仅8周时间。 ​ 2、测试负责人采取另外一个测试方案和计划，即2个人8周的时间测试1000个测试用例，但是他不敢保证测试的质量，对这些用例测试缺陷的能力不放心。 ​ 3、为了减轻这种不确定性的问题，他用正交表重新设

填表注意: 1.fixed:描述的问题已经修改; 2.invalid:描述的问题不是一个bug(输入错误后,通过此项来取消) 3.WONTFIX:描述的问题将永远不会被修复 4.LATER:描述的问题将不会在产品的这个版本中解决 5.DUPLICATE:描述的bug是一个存在的bug的附件 6.WORKSFROME:所有要重新产生这个bug的企图是无效的.如果有更多的信息出现,请重新分配

软件的缺陷是软件开发过程中的重要属性，它提供了许多信息。不同成熟度的软件组织采用不同的方式管理缺陷。低成熟度的软件组织会记录缺陷，并跟踪缺陷纠正过程。高成熟度的软件组织，还会充分利用缺陷提供的信息，建立组织过程能力基线，实现量化过程管理，并可以此为基础，通过缺陷预防实现过程的持续性优化。

1.What is Regression Testing and what is its mian purpose? 2.Please describe the major processes defined in the software testing lifecycle. 3.Please describle the Testing phases after Unit testing,and...

8.2软件缺陷的生命周期与生物学的昆虫不同，软件的缺陷要经历一组非常严格的状态（参见图8-2）。在VSTS中，缺陷所允许的缺省的状态和转换依赖于你为项目所选择的过程模板。所选过程的那组规则决定了：选择可允许的状态；定时、授权哪些用户组可以将缺陷推进到下一个状态；允许转换的原因。如果有权限的话，你可以进一步定制这些规则，从而使它们与团队的工作流相匹配。图8-2此状态图是用于CMMI过程改

缺陷管理：缺陷管理包括记录、分类、分析、分配、修复和关闭缺陷的全过程。良好的缺陷报告能提高修复效率，避免重复沟通。系统化的缺陷跟踪工具可以记录缺陷状态的变化，并支持查询、报告等功能，便于管理和分析。定期检查：测试团队应定期检查缺陷状态，确保高优先级的缺陷得到及时处理，同时发现并标记重复缺陷，避免资源浪费。缺陷分类：按照缺陷的来源（需求、设计、编码等）、类型（逻辑错误、界面问题、性能问题等）分类，便于统计和分析。明确流程：明确缺陷管理的流程和职责，确保每个人都清楚缺陷报告、分配、修复和验证的步骤。

功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等。造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错 误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等。1.6、其他：故障的分类（如功能故障、页面故障、兼容性故障）、优先级的分类等。

一个最优化、最简单的软件缺陷生命周期的例子 1.发现缺陷-- （测试员发现缺陷并记录缺陷报告/缺陷报告交给程序员） --》打开-- （程序员修改缺陷/缺陷报告交给测试员） --》解决-- （测试员确认缺陷已修改/测试员关闭缺陷报告） --》关闭 大多数项目小组都制定规定由谁来改变软件缺陷的状态，或者交给其他人来处理软件缺陷。 例如，只有项目经理可以决定推迟软件缺陷修复，或者只有测

 软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。简单的软件缺陷生命周期：1、发现——打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员；2、打开——修复：开发人员再现、修复缺陷，然后提交测试人员去验证；3、修复——关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。但是这是一种理想的状态，在实

软件工程生命周期模型

一、bug管理 目前管理bug工具众多， 只要符合方便公司的工作流， 就可以采用。比如有：Bugzilla，B/S架构的mantis TestCenter 工具各异，但是bug管理流程具有共通性，一般有如下流程： 处理状态: 未确认 新建 已分派 再开启 已确认 已关闭 解决状态: 已解决 无效的 wontfix不被修改 保留 重复 worksforme暂时不重现...

1、未实现需求规格说明书指明要实现的需求（显现需求）2、未实现需求规格说明书未指明但应该要实现的需求（隐性需求）3、超过需求规格说明书规定的范围4、出现了指明不会出现的缺陷（bug）5、用户体验不好，使用不佳的，不易操作的，运行缓慢的问题。

一、缺陷概述  软件缺陷(software defect)是对软件产品预期属性的偏离现象。它包括检测缺陷和残留缺陷。每一个软件组织都知道必须妥善处理软件中的缺陷，我们一般成缺陷为”bug” 。 二、缺陷属性  跟踪类型：缺陷跟踪类型，可选值：产品测试、性能测试、RBT测试、WorkItem、意见反馈；  状态：缺陷的状态，用于标识缺陷的生命周期，可选值：New, Fixed, Won'

新信息（New）：测试中新报告的软件缺陷； 打开 （Open）：被确认并分配给相关开发人员处理； 修正（Fixed）：开发人员已完成修正，等待测试人员验证； 无法修改（Wontfix）： 稍后修改（later）： 无法重现（works forme）： 重复的（duplicate）： 无效的（invalid）： 外部的（external）： 原本的设计（ByDesign）； ...

Introduction:引言 Bug can be defined as the abnormal behavīor of the software. No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing don