工作两年了，我一直希望让自己每年对测试的理解更深入一层。工作一年的时候我写了《谈软件测试---一年工作总结》 ，谈轮了自己对各种测试的理解，这一年来，虽然对那些理概念的有所加强，自我感觉没有什么质的变化。前些天听我们公司的一位测试经理讲《敏捷测试》豁然开朗。他在学造飞机，而我一直在学造飞机里的一个发动机。我从来没想过，一个完整飞机的架构应该是怎样的。

　　如果想让测试在公司的项目中发挥出它最大的价值，并不是招两个测试技术高手，或引入几个测试技术，而是测试技术对项目流程的渗透，以及测试流程的改进与完善。虽然，当然测试行业前景乐观，许多中小企业也都在引入测试，但一百个公司就有一百种测试，每个公司对测试的看法不同，公司对测试的定位也不完全一样。本人前后经历两个公司，以自己的拙见浅谈一下对测试流程的看法。

 这几天整理思路，回顾了前两份测试工作的流程与架构。

简陋的测试流程                                                                                     

　　先说笔者入职的第一个家公司，笔者是第一个入职的专职测试人员，相信一两个测试的公司还是不少的，入职后各种项目都在进行当中，上面给我的定位是并没完全融入到项目中去。而通过指派任务的方式。

下面是简陋的流程图：

需求分析与架构设计：

　　我们做的是某一移动公司内部使用的项目，需求分析与架构全部由项目经理完成，之后由项目经理给具体某个开发人员分配任务，具体对某个功能模块的实现。这个对项目经理的经验与技术要求很高，他既然担任了需求分析师，又担任架构师的角色。

程序员编码：

　　因为我们开发语言用的是JAVA 语言，IDE用myeclipse 中自带的CVS版本管理工具，开发人员完成代码后，提交到版本库中。

测试：

　　笔者入职后的第一个任务是搭建缺陷管理工具，禅道项目管理，通过推广对发现的问题进行跟踪。后来正明效果并不好，因为对于一个六七人的开发团队项目，开发人员更喜欢测试人员能当面反馈，这样更能提高效率。对一个小bug 通过当面交流的方式就可以将问题修复。

　　对于当时的环境，并没有测试线。开发人员在本机上将项目进行部署运行。测试人员通过局域网访问开发人员的机子进行访问。或在测试人员本机上进行部署测试。这也是一个致命的缺点。因为开发人员测试人员使用的电脑存在太多不稳定性，这些都会造成问题的出现，有时候难以判定是系统问题还是环境问题。

上线：

　　经过测试人员测试通过后，开发人员部署上线。

A程序员流程

　　你会发现在流程图中，A程序员是先发上线之后，再进行测试。这是我们一个面向大众用户的网站，上面给于测试人员的定位是测试员兼用户体验员，测试员将发现的bug和体验问题提交到缺陷管理系统，由经理对问题进行分析，指派开发人员解决。定期对系统进行更新。

流程分析：

　　这个流程唯一的优点，就是能快速的发现并修复问题。

　　缺点就非常多了，相信许多小软件公司也有类似的流程。

　　这个流程中，项目经理是核心，项目经理也确实是有多年开发与项目经验的牛人，他喜欢不定期分享上些前沿的技术。我很崇拜他。

　　对于测试来说，需求很不明确，测试文档与用例也是可有可无的产物，没有需求文档，或非常简陋，根据需求文档根本无法编写用例。笔者只能收集一些通用的测试用例，如登录、文件上传下载、列表翻页、日期选择、输入框验证、搜索等有一些“通用型”用例，以便在测试过程中做参考。功能测试的多了，拿到一个功能，测试思路也就出来了。

规范的测试流程                                                                                      　

　

　　放弃上份悠闲的工作，感谢那个带我入行公司，我想了解真正的测试在公作中如何进行的。所以，来到了现在这家公司。我很欣喜的是这测试有自己的团队，专业（对当时的我来说）的流程，以及与开发等同的地位。

现在的测试流程：

需求分析：

　　需求分析由产品人员制定，他们要做的不是一份简单的文档，而是细化每一个功能的细节，每一个按钮的位置，对于稍大或复杂一点的需求都进行建模。

需求评审：

　　这里会叫上所有参与项目人员进行，开发人员、测试人员、QA人员。测试人员提出需求，开发人员考虑功能实现的方案与可行性、当然开发负责也是要参与的。测试人员主要是对需求的理解提出疑问，以便才能根据需求写用例。QA人员是最终对软件质量进行验证的人，所以也需求了解需求

开发人员编写排期：

　　开发人员需求根据需求功能点进行排期。然后将开计划转交给测试人员。

测试计划排期：

　　测试人员根据开发计划，对测试具体测试时间，也就是开发功能完成后的时间，进行几轮测试等。然后，把项目的开发与测试计划发送给各部门负责人及参与项目的所有人员。

编写测试用例：

     根据详细的需求分档，开始进行用例的编写。

用例评审：

      在用例进行评审之间，先以邮件形式将用例发送给相关人员，以便他们事先了解用例对哪些功能进行验证以及验证的细节。

　　然后，测试人员组进行用例评审，开发人员对用例与实际功能不符合有哪些，产品人员对会通过用例对功能的具体实现进行把握等等。

提交基线：

    开发人员完成所有功能后，会对自己的功能进行一个自测。自测完成后提交测试人员进行基线。

具体测试流程：

      开发人员对于基到测试线的功能进行测式，发现的问题通过缺陷管理工具进行反馈，开发人员对问题进行修复，然后，准备第二轮基。

　　测试人员完成第一轮测试后，需要写测试结论，发到相关人员。然后对基线后的第二轮进行测试，第二轮会对第一轮中发现的问题进行重点回归。

测试通过：

　　经过两到三轮或四轮的测试后，直到没发现新的问题，或暂时无法解决，或不紧急的问题。通过上级确认，可以通过。编写测试报告与验收方案。

　　验收方案是交由QA进行验证的。在现公司的流程中是将测试与QA分开的，测试人员重点关注的是功能是否可以正常运行。QA关注的是整个流程的质量以及最终用户的质量。有些公司QA与测试是不区分的，但这对测试的要求会更高，除了关心功能，还需要关心整体流程与质量。

流程分析：

　　对于刚接触这个流程的我来说，这个流程是规范的，测试真正融入了整个流程，而且还担任了很重的角色，从而也有效的保证了软件产品的整体质量。

　　那么这个流程是不是完美的呢？不，这个项目流程太强化各种文档。我们来看测试的工作内容，测试计划、测试用例、测试结论、测试报告、验收方案、问题的提交跟踪。其实，我们真用于测试的时间是非常少的，在一周的时间，也许只有一天或不到一天的时间是在进行测试的。测试人员只有在测试的时候才会体现出他的价值。而大部分工作却不能体现他的价值。

　　当然，我这里会省略与测试主流程无关的东西，真正的测试工作中琐事很多。

敏捷测试流程                                                                                       

　　

　　下面来看敏捷测试，本人并没有接触过敏捷，对敏捷也没花时间学习与研究。唯一接触就是听我们测试经理对测度流程讲了两个半小时，听讲的人很多，我站着听的。受益匪浅，凭着记忆也简单谈谈。 

　　前面讲的第一种流程，还是第二种流程都是瀑布式的，严格来说第一种简陋的都不能称为瀑布式，对于一个三个月的项目说，产品把需求分析完了给开发，然后产品就没事儿了；开发开发完成之后给测试，然后开发人员也不忙了。测试完成之后上线。那么在产品分析的阶段，开发和测试都是没事干的（这里只对单一项目）。开发阶段，产品和测试也基本没事儿。同样在测试阶段，产品与开发也是没什么事儿的。

　　敏捷测试的一个核心是迭代，在每个时间点上，所有项目人员都是有事可做的。

1、下面是我理解中的敏捷测试流程图：

第一阶段：

　　通过上面的流程图，对于一个月的需求分析，在敏捷中，可能三五天就确定下来。这个需求定得会很模糊，但整体框架确定。产品对其中某一模块功能确认，开发人员开始对确认的功能编码，开发人员编码的过程中，测试进行功能分解，因为根据模糊的需求很难写出具体的用例，所以，只能尽量对功能进行分析得细些，标注需要验证的内容。

第二阶段：

　　开发完成后交给测试人员进行测试，开发人员继续开发新的功能。那么测试人员发现的问题怎么办呢？会从开发团队中抽出一个人员来用于解决测试发现的问题。但开发进度并没有因为测试而停止。

流程分析：

　　在这个流程中弱化了文档，强调了各个人员的沟通，通过这种迭代的方式，三个月的项目，可以能两个月和两个半月就会完成。

但这种流程并非完美，加入一个功能在需求分析阶段就是错误的，因为它是一个迭代渐进的过程。也只能一路错下去。

2、对测试问题的处理

上面的图更能清晰看出对问题的处理过程。

　　第一块面板中是开发人员未实现的功能，第二块面板中是开发完成功能，测试人员对其进行测试，发现不通过的就放回未开发的面板中，测试通过的将放到第三块面板中。

      需要说明的是，敏捷测试在国外很流程，在内容，雷声大雨点小，推行的人很多，真正有公司引入的不多。我们所在公司千差万别，测试流程也可能有很大的不同。对于已经工作两年一个测试员来说，从来没关注过测试流程与结构应该是个悲剧。我希望不被思想局限，所以，努力冲破一个又一个的局限。

 PS:如果需要工具包或想深入了解学习的朋友可以来群QQ: 480834181

软件测试学习交流群 480834181

 

第二篇：软件测试技术问题总结

软件测试技术基础常见问题总结

1 软件测试基础

1） 什么是软件测试？

软件测试是通过手工或自动化的手段运行或测定被测对象是否满足所对应的需求；被测对象包括需求分析、设计规格说明书，系统编码等；在测试过程中，要根据相应的规格说明书设计一组测试用例，通过对测试用例的执行来发现系统中相应的错误保证软件质量的一项活动。

2） 软件生命周期是什么？

①. 项目规划

②. 需求定义分析

③. 软件设计

④. 程序编码

⑤. 软件测试

⑥. 运行维护

3） 软件测试目的是什么？

①. 发现系统的错误

②. 验证系统是否满足需求

③. 保障产品质量

④. 改进开发进程

4） 软件缺陷（bug）与软件错误（error）的区别和联系？

区别：软件缺陷是存在于软件之中的不希望或者不可接受的偏差，而软件错误是由于人为的原因产生的错误。缺陷是在软件中抽象存在的，而错误是人的行为问题。

联系：由于人的错误行为，在设计或者编码过程中的失误，导致了软件内部的缺陷。人为错误是引发软件缺陷的直接原因。一个软件错误必定引发一个或多个软件缺陷。

5） 软件测试如何改进软件开发过程？

软件测试和软件开发是不同的两个过程，但是通过软件测试发现软件的缺陷，然后通过缺陷的分析确定错误产生的原因从而发现软件开发过程中存在的缺陷。同时通过对测试结果

的分析整理，还可以修正软件开发规则。因此，软件测试在一定程度上可以改进软件开发流程。

6） 分析“软件测试没有什么技术含量，不就是点击按钮，对系统进行操作吗？”。

分析：在上述问题中只所以出现这样的言论，是对软件测试理解的片面性和对软件测试理解的偏激造成的。对于一个规范的软件测试过程包括了软件测试的计划、系统分析、测试设计、开发等技术。软件测试是一个发现软件缺陷的过程，要想发现软件缺陷必须对被测对象有足够的了解，而不是简单的对被测对象的执行，更不是只是点击“按钮”。这里边包括了如何设计测试场景、测试数据、测试执行等过程。同样的通过软件测试发现系统的问题，通过问题的改进可以提高软件产品的质量，赢得用户的口碑，从而提高产品的市场竞争力，提高公司的利益。因此软件测试是一项非常有意义的关系公司存亡的活动。

7） 软件测试对象包括什么？

①. 需求规格说明

②. 概要设计规格说明

③. 详细设计规格说明

④. 源程序

⑤. 系统

⑥. 用户手册

⑦. 帮助文档

8） 主要的软件测试手段分别是什么，如何理解？

软件的测试手段包括验证和确认；验证是对前一个阶段的验证；确认是对原始开发需求的确认，任何一个阶段的确认都应追溯到需求。

9） 软件测试的原则包括那些方面？

①. 尽早的不断的测试

②. 测试过程中要设计测试用例

③. 程序员避免检查自己的程序

④. 彻底测试是不可能的

⑤. 测试应追溯到需求

⑥. 从“小规模”到“大规模”

⑦. 注意群集现象

⑧. 严格执行测试计划

⑨. 测试结果进行全面检查

⑩. 测试维护

10） 软件测试的局限性包含哪些？

不能全面测试程序

不可能测试到程序对任何可能输入的响应

不可能测试到程序每一条可能执行的路径

无法找出说有的设计错误

11） 为什么说软件测试不能保证软件质量 高质量的软件不是测试出来的，而是开发出来的；软件测试是保证软件质量的手段之一，不能够保证软件的质量 不是唯一手段。要想提高软件质量必须提高开发质量。

12） 常见的软件测试模型有哪些，分别具有什么样的特点？

测试中常见的模型有V、W、H、X等模型；

其特点如下：

①. V模型适用于产品，描述的是开发和测试的对应过程

②. W模型是V模型，强调的是针对需求，设计的测试

③. V、W模型不支持迭代

④. x模型增加了探索性测试

13） 什么是V（或者W模型），它的特点是什么？

V模型是软件测试的一个基础应用模型，包括了软件开发和软件测试的两个阶段，并且两个阶段是串行的，V模型的左边是：需求分析、概要设计、详细设计、编码；右边包括：“单元测试”、“集成测试”、“系统测试”、“确认测试”和“验收测试”。

V模型的特点：

①. 测试对象是程序本身

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

③. 测试深度高

④. 评审深度低

14） 什么是敏捷开发和敏捷测试？他们的特点是什么？

敏捷开发：敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此

过程中软件一直处于可使用状态。

2 软件测试过程概述

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

软件的开发生命周期包括：需求分析?系统设计?软件编码?运营维护

2） 软件测试的生命周期（过程、流程）是什么？

软件测试生命周期包括：测试计划、测试设计、测试开发、测试评估、测试报告、缺陷跟踪。

3） 软件测试流程中的里程碑分别是什么？

①. 测试计划通过评审

②. 测试设计完成

③. 测试脚本开发完成

④. 测试用例执行完成

⑤. 测试报告通过评审

4） 测试计划的主要内容包括那些？

①. 测试的目的与范围

②. 测试的策略和方法

③. 人力物力资源的安排（角色及职责）

④. 测试进度的安排（什么样的事情应该在那个时间点完成，由谁来做，产物等） ⑤. 测试风险分析

⑥. 停测标准

⑦. 完成标准

5） 测试计划应该完成那些目标？

①. 合理的管理和组织测试资源

②. 指导测试工作的正常进行

③. 配合研发部门调整相关资源

6） 测试设计阶段设计的是什么？

测试设计阶段的设计包括测试方案的设计和测试用例的设计，主要是做测试用例的设计。

7） 什么是测试开发，测试开发过程中开发的是什么？

测试开发指的是在测试用例设计完成后，对测试用例中需要进行自动化测试的测试用例进

行的脚本开发过程。

测试开发过程中开发的主要是测试脚本。

8） 什么是测试执行？测试执行过程中应该具备那些基础技能？

测试执行指依据测试用例运行测试脚本（自动化测试）或者运行被测对象，发现被测系统中的缺陷的过程。

在测试执行过程中一个合格的测试人员需要具有以下这些技能：

①. 被测对象的操作能力，保证可以正确的运行和操作你的被测对象；

②. 敏锐的观察能力，可以快速有效的识别BUG；

③. BUG确认能力

④. 系统背景知识和相关业务知识

9） 软件测试的两种方法是什么？

软件测试的两种方法是：黑盒测试和白盒测试。

10） BUG确认的一般方法？

①. 确认不是因为操作问题；

②. 确认不是因为系统环境问题

③. 确认不是配置问题

11） 测试评估的主要内容是什么？

①. 对软件需求评估

②. 需求覆盖评估

③. 基于代码的测试覆盖评估

④. 软件性能评估

12） 软件测试阶段分为那些？

①. 需求审查

②. 设计审查

③. 程序审查

④. 单元测试

⑤. 集成测试

⑥. 确认测试

⑦. 系统测试

⑧. 验收测试

13） 如何确定单元测试中的“单元”？

①. 采用面向过程开发的语言的系统单元可以是一个函数或者过程来组成；

②. 采用面向对象技术开发的软件，单元可以是一个类或者一个类的示例等。

③. 对于网页和用户窗口界面，单元可以是一个文字输入窗口或一个按钮

14） 什么是回归测试？回归测试的策略是什么？

回归测试就是验证发现的缺陷是否真正的被开发人员修复，同时测试是否由于代码的修改而引入新的缺陷。

回归测试的策略包括：

①. 完全回归测试

②. 基于风险评估的回归测试

③. 基于缺陷修改的回归测试

3 单元测试与集成测试

1） 什么是白盒测试？

白盒测试是对软件的过程性细节多细致性的检查，是把测试对象看做是一个打开的盒子它允许测试人员利用程序内部的逻辑结构和相关信息设计或选择测试用例，对程序的所有逻辑进行测试，通过在不同点检查程序状态，确定程序的实际状态是否与预期状态相一致 注：白盒测试又称为结构测试和逻辑驱动测试

2） 白盒测试用例设计的方法有哪些？

①. 语句覆盖

②. 判定覆盖

③. 条件覆盖

④. 判定/条件覆盖

⑤. 条件组合覆盖

⑥. 路径覆盖

3） 白盒测试的主要技术有哪些？

①. 静态分析

②. 动态分析

③. 逻辑覆盖

④. 基本路径测试

4） 什么是静态测试，静态测试的主要方法？

静态测试是指在不运行被测对象情况下的测试；静态测试的方法主要有，以及编码规范和

标准，对代码进行走查、审查和评审。

5） 什么是动态测试，动态测试的主要方法？

动态测试指在运行被测对象情况下的一种测试方式。动态测试的方法包括：黑盒测试和白盒测试。

6） 常见的白盒测试工具有哪些？

比如商业白盒测试工具IBM的PureCoverage、Purify、Quantify，开源工具:JUnit、CppUnit、HttpUnit、NUnit等。

7） 什么是集成测试，集成测试的关注点是什么？

集成测试是将通过单元测试的单元按照设计要求组合起来进行测试

集成测试关注的是模块与模块之间的接口问题

4 系统测试测试过程

1） 什么是系统测试，系统测试中常见的测试类型有哪些？

系统测试是将已经通过集成测试后的软件作为计算机系统的一部分与计算机硬件、某些支持的软件、数据、人员等元素结合起来在实际运行环境中对计算机系统进行严格有效，来发现软件潜在的缺陷，保障系统运行

系统测试的类型有：功能测试、性能测试、裸机测试、BVT测试、安装卸载测试、安全性测试、兼容性测试、易用性测试、容错测试、配置测试

2） 什么是功能测试，功能测试的测试要点是什么？

功能测试是指验证系统的功能是否满足用户需求的测试，功能测试的主要关注点是功能点和功能逻辑。功能点是指某一个功能的具体实现的点包括页面上的设置输入设置等。功能逻辑指需要完成的功能在系统执行过程中如何去实现，实现的是否正确符合需求。

3） 功能测试和性能测试有哪些不同？

①. 功能测试和性能测试关注的要点不一样，

功能测试主要关注系统在功能模块上的实现或者功能逻辑上的实现是否正确，是否存在问题。性能测试关注系统执行的效率、响应速度、能够承受的负载等。

②. 在测试方法上不一样

功能测试一般应用手工测试，也可以根据具体的情况应用自动化测试，功能自动化测试的主要技术要点是实现目标对象的识别，仿真用户的真实的鼠标和键盘的操作。

性能测试一般应用自动化测试手段，主要是通过协议的仿真来模拟多用户情况下，测试被测系统的响应情况。

4） 什么是兼容性测试？兼容性测试的测试要点是什么？

兼容性测试又叫做配置测试，是指测试软件在特别的硬件、软件、操作系统、网络等环境中是否能很好的运行。

测试的要点是 1）软件之间兼容性 2）数据之间兼容性 3）硬件兼容性等

5） 什么是UI？一个优秀的UI通常包含哪些要素？

UI（User Interface）用户界面

优秀的UI包括以下几个要素： 界面标准和规范、直观、一致、灵活、舒适、正确、实用等

6） 什么是验收测试？什么是α测试？什么是β测试？

验收测试是验证系统能否达到用户需求说明书中的要求；

a测试是软件开发公司组织内部人员，模拟各类用户，对即将上市的软件产品进行测试，试图发现错误并修复的过程。

β测试是由软件的多个用户在实际使用环境中进行的测试，这些用户返回有关错误信息给开发者。

5 测试用例设计

1） 什么是测试用例？

测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果；测试用例是执行的最小实体；体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，测试用例的目的是为测试某个程序路径或核实是否满足某个特定需求的一份指导测试有效执行的文档。

2） 什么是黑盒测试？黑盒测试用例设计方法一般有哪些？这些测试方法如何综合应用？

是把测试对象看做一个打开的黑盒子程序员完全不考虑程序内部的逻辑结构和内部特 征，只依据程序的需求规格说明书，检查程序的功能是否符合功能说明 （黑盒测试又叫做功能测试或者数据驱动测试，所谓数据驱动是指它需要一组数据来验证功能的完善）

用例设计方法有：等价类划分、边界值、因果图、功能图、场景分析、错误推测法

黑盒测试用例设计方法如何综合应用

1） 一般情况下需要根据需求划分等价类进行分析；

2） 然后根据等价类应用边界值方法设计测试用例；

3） 应用错误推断法补充测试用例

4） 如果输入和输出之间存在着很强的逻辑关系，一般应用因果图方法设计测试用例。

3） 什么是测试方案，测试方案在测试过程中起到的作用是什么？

测试方案是一个对测试计划进行细化的文档，测试方案用来指导测试用例的设计，测试方案的内容包括细化测试目的、细化测试方法、细化测试环境、细化测试工具、细化测试范围。

测试方案在测试过程中的作用是：实现对测试计划的细化，指导测试用例的设计。

4） 测试用例在软件测试过程中起到的作用？使用测试用例的好处？

①. 指导测试的实施

②. 规划测试数据的准备

③. 编写测试脚本的“设计说明书”

④. 评估测试结果的度量基准

⑤. 分析缺陷的标准

好处

①. 在开始实施测试之前设计好用例可以避免盲目测试，提高测试的效率

②. 测试用例的使用令软件测试的实施重点突出，目的明确

③. 在软件版本更新后只需要修改少量的测试用例即可开展测试工作，降低工作强度，

缩短项目周期

5） 测试用例设计的一般过程是什么？

①. 测试需求分析

②. 业务流程分析

③. 测试用例设计

④. 测试用例评审

⑤. 测试用例完善

⑥. 测试用例维护

6） 测试用例的主要要素包含哪些？

软件名称、版本 模块名称、功能特性、预置条件、用例编号、参考信息、用例说明、输入数据、预期结果、测试结果 环境要求、特殊规程要求、缺陷编号。

7） 测试用例设计的原则是什么？

①. 测试用例的代表性

②. 测试结果的可判定性

③. 测试结果的可重现性

8） 没有测试用例是否可以执行测试，如果可以测试工作应该如何展开？

9） 在测试工作中如果没有需求及其相关文档测试工作是否可以进行，如果可以，应该如何进

行？

6 缺陷管理

1） 什么是软件缺陷？

①. 软件未达到产品说明书表明的功能

②. 软件出现产品说明书指明不会出现的错误

③. 软件产品功能超出说明书指明的功能

④. 软件未到达产品说明书未指明但应该达到的目标

⑤. 软件测试人员认为软件难以理解、不易使用、运行速度缓慢、或者最终用户认为不好

2） 软件缺陷一般分为哪些类型？

①. 用户界面错误

②. 程序的错误

③. 计算错误

④. 需求错误

⑤. 外部错误

⑥. 测试错误

3） 缺陷可以划分为哪几种严重等级，分别是什么？

致命级：

造成崩溃、死机，并且不能通过其他方法实现功能；

“杀手锏“功能失效；

导致客户利益巨大损失的失效

严重级：

基本、重要功能无法实现；

操作安全方面存在漏洞；

系统缺少必要的负载限制导致大容量系统失效

一般级：

查询数据时，数据显示错误；

告警信息不全面，不准确；

次要功能失效

提示级：

界面不友好，操作不方便；

缺少必要的缺省信息；

错误提示不直观

4） 缺陷的优先级有哪些？分别简单描述？

缺陷的优先级可以分为高、中、低三个层次，高优先级的缺陷必须及时修改，不修改系统测试就不能进行下去，中优先及可以放在正常的BUG修改队列中进行修改；低有限级的缺陷可以在有时间的时候修改，如果时间紧张可以带在产品中进行发布。

5） 一个缺陷中包含哪些要素？

分配给缺陷的ID号、对缺陷的详细描述、缺陷发生的条件、缺陷发生的次数、缺陷发生的现象、提示缺陷的测试ID号、执行测试的人、测试工作站ID号、发现缺陷的时间和日期、发生缺陷的计算机、硬件平台、发生缺陷的子系统、软件的版本号、缺陷发现的数据库、缺陷是否再现、缺陷的重要性、分配修改这个缺陷的优先级、其他

6） 如何提交一份好的缺陷报告？

书面的、已编号的、易于理解的、可重现、易读、不要带有情绪化

7） 一个缺陷的生命周期是什么？状态如何转换？

New 、Open、close、Fixed、rejected、Reopen等

1） 当测试人员发现Bug时提交到Bug管理库，此时状态为New；

2） 测试管理人员对New状态的缺陷进行评审，如果通过评审则为Open，如果不能通过评

审则为：Close；

3） 研发人员对于Open状态的缺陷进行验证，如果认为确实是一个缺陷，则至为Fixed，

如果认为不是一个缺陷则改变为：Rejected；

4） 测试人员对于置于Fixed的缺陷进行验证，如果缺陷真的被修改则置于：close状态，

如果没有修改则置于Reopen状态。

【全文结束】