软件测试理论

软件测试视频篇第三阶段-测试基础

本阶段软件测试课程共计6个知识点，共计n个免费配套视频涵盖

1、学习目标：

学完后目标：熟练掌握测试用例的设计方法及缺陷的编写方法，熟练掌握缺陷管理工具禅道或jira。

2、知识点：

1）软件测试理论

2）软件生命周期

3）测试方法和分类

4）测试用例设计

黑盒测试用例设计方法、白盒测试用例设计方法

5)缺陷及缺陷管理工具

缺陷属性、缺陷生命周期管理、禅道和jira

6)测试其他

测试流程、测试计划编写、测试报告模版、测试报告分析

 

一, 软件测试理论

软件测试的目的

软件测试的定义

软件测试的原则

产品质量模型

测试基本流程

 

 

一、软件的测试意义

所谓的软件测试指的就是通过手工或者工具对被测对象进行测试操作，从而验证实际结果与预期之间是否存在差异

二、软件测试的作用和目的

1. 测试工作可以发现并修复软件中存在的缺陷，从而提高用户对软件的使用信心

2. 测试操作可以记录软件使用过程中产生的一些数据，从而为决策者提供依据

3. 测试操作可以降低同类型软件的开发风险

4. 总结：测试工作的目的就是通过尽可能少的人力、财力、物力来查找并解决软件中存在的缺陷从而降低商业风险等。

三、测试原则

1. 测试证明软件存在缺陷:我们的测试工作只能证明当前软件是有缺陷而不能证明它没有缺陷。

2. 不能执行穷尽测试

3. 测试应当尽早介入

4. 缺陷存在群集现象

5. 某些测试操作依赖于特定的测试环境

6. 杀虫剂现象：不要过多使用同一条测试案例来对软件j进行问题查找，软件会产生”抗体“

7. 不存在缺陷的谬论：任何的软件不可能是完美的。

测试基础

一、开发模型-瀑布模型

需求分析>设计>编码>实现>软件测试>完成>维护

1.是先行模型的一种,在所有模型中占有重要地位,是所有其他模型的基础

2.每一个阶段执行一次,按线性顺序进行软件开发.

测试的切入点:

测试阶段处于软件实现后,必须在代码完成后留出足够的时间给测试活动,否则将导致测试不充分,很多问题到项目后期才暴露.

优点:

• 开发的各个阶段比较清晰

• 强调早期计划及需求调查

• 适合需求稳定的产品开发

缺点:

• 依赖于早期的需求调查,不适应需求的变化

• 单一流程不可逆

• 风险往往延后至后期才显露,失去及早纠正的机会.

• 问题在项目后期才开始暴露

• 前面未发现的错误会传递并扩散到后面的阶段,可能导致项目失败

改良:

沿用瀑布模型的线性思想,细化了各个阶段,在某些重要关注的阶段之间渗入迭代的思想.

 

 

优点：开发阶段，各个阶段比较清晰；强调早期计划及许求调查；适合稳定许求的产品开发；

改良：每个阶段都可以融入小的迭代工作

二、开发快速原型模型

快速分析>需求说明>构造原型>原型>运行原型>评价原型>修改意见

实现一个基本原型，让用户对原型进行评价，逐步调整，使其满足用户最终许求；

优点：克服了瀑布模型的缺点,更好的满足用户的需求并减少由于软件需求不明确带来的项目开发风险.适合预先不能确定需求的软件系统开发.

缺点：不适合开发大型系统的开发.适合开发小型的,灵活性高的系统.前提要有一个展示性的产品原型,因此在一定程度上可能会限制开发人员的创新.

螺旋模型

分为几个螺旋周期,每个螺旋周期大致

优点:

螺旋模型很大程度上是一种风险驱动的方法体系,因为在每个阶段之前经常发生的循环之前,都必须首先进行风险评估

缺点

采用螺旋模型需要具有相当丰富的风险评估经验和专门知识,在风险较大的项目开发中,如果未能够及时标识风险,势必造成重大损失.过多的迭代次数会增加开发成本,延迟提交时间.

 

V 模型

需求分析>概要设计>详细设计>编码>

单元测试 :又称模块测试,针对单一的程序模块进行的测试

集成测试:又叫组装测试,在单元测试的基础上,对所有模块进行测试.

系统测试:将整个软件看作一个整体来进行测试,包括功能,性能,兼容性

验收测试:

(alpha)α测试:内测版 内部交流版本,可能存在很多 bug ,不建议用户安装.

(beta)β测试:公测版(beta)面向所有用户,通过用户的反馈再去修改细节

(gamma)γ测试:候选版 与正式软件相差无几

优点：

包含了底层测试（单元测试）和 高层测试（系统测试）

缺点

自上而下的顺序导致了测试工作在编码之后，就导致错误不能及时的进行修改；实际工作中许求经常变化，导致V模型步骤反复执行，反工量很大，灵活度较低。

W模型

W模型由Evolutif公司提出：开发一个V,测试一个V,组合的W模型

测试伴随着整个软件开发周期，并且测试的对象不仅仅是程序，需求和测试同样要测试。

 

内测版alpha、公测版beta、候选版gamma

W 模型的优点

开发强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求和概要设计同样要测试

更早地接入测试，可以发现开发初期的缺陷，那么可以用更加低的成本进行缺陷修复。

同样是分阶段的工作，便于控制项目过程

缺点：

软件开发和软件测试依然保持一前一后的先行关系，依然无法支持迭代、自发性和需求等变更调整；

对于当前很多项目，在执行的过程中根本不产生文档，那么W模型基本无法试用

使用起来技术复杂度很高，对于需求和设计的测试要求很高，实践起来困难。

H模型

实际软件开发中、需求、设计、编码等活动被分阶段执行、但是实践中，它们并不是完全串行的，它们之间更多时候是交叉进行的，更多的是迭代执行。

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

测试准备：

• 测试就绪点：测试准入准则，即是否可以开始执行测试的条件。

• 测试执行：具体的执行测试的程序。

• 其他流程：如设计流程

H模型的优点：

开发的

软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行。

软件测试活动可以今早准备、今早执行，具有很强的灵活性；

软件测试可以根据被测物的不同而分层次、阶段、次序的执行，同时也是可以被迭代的。

缺点：

管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将很难以管理和控制；

技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；

测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大的困难

对于整个项目组的人员要求非常高：在很好的规则制度下，大家都能高效的工作，否则容易混乱。例如：你分了一个小的迭代，但是因为人员技能不择，使得无法有效完成，那么整个项目就会受到很大的干扰。

 

软件测试分类

 

黑盒测试

又称数据驱动测试,完全不考虑程序内部结构和内部特性,注重于测试软件的功能需求,只关心软件的输入数据和输出数据.

一,功能测试

1. 逻辑功能测试

2. 界面测试

3. 易用性测试

4. 安装升级测试

5. 兼容性测试

二,性能测试

1. 时间性能

2. 空间性能

3. 一般性能测试

4. 稳定性测试

5. 负载测试

6. 压力测试

白盒测试

指的是把盒子打开,去研究里面的源代码和程序结构

灰盒测试

 

静态测试

指不实际运行被测软件,而知识静态的检查程序代码,界面或文档中可能存在的错误过程.

参与人员:

技术专业人员,主持人,内审员,作者,列席人员,记录员,用户代表

就像技术 leader 在功能完成初期有个 review,通过后才正式邮件通知提交测试部门提测.

动态测试

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

随机测试

针对重要功能,新增加的功能,特殊情况,以前发现过重大 bug 的模块进行二次测试;也叫探索测试,它可以解和回归测试使用.

验收测试

α测试:内测版 内部交流版本,可能存在很多 bug ,不建议用户安装.

β测试:公测版(beta)面向所有用户,通过用户的反馈再去修改细节

γ测试:候选版 与正式软件相差无几

 

测试用例

测什么,怎么测 形成的文档

等价类划分法

计算器:到底输入机组数据才算测试完毕?

1.证书

2.小数

3.符号

4.汉字

5.空格

6.不输入

通过上面的面熟,我们发现我们用户所有可能

等价类划分是一种重要的,常用的黑盒测试方法,不需要考虑程序的内部结构,只需要考虑程序的输入规格即可,它将不能穷举的测试过程进行合理分类,从而保证设计出来的测试用例具有完整性和代表性.

等价类的分类

有效等价类

指符合<需求规格说明书>,输入合理的数据集合

无效等价类

指不符合<需求规格说明书>,输入不合理的数据集合

思考步骤

1. 先确定有效和无效

2. 有效等价类就是题目条件(边界值,两端的极值要判断,中间随意一个值也要判断)

3. 无效等价类先划分于条件相反的情况,再找到特殊情况(中文,英文,符号,空格,空)

等价类细节

1. 考虑输入长度

2. 考虑输入类型

3. 组成规则

4. 是否为空

5. 是否区分大小写

6. 是否重复

7. 是否去除空格

8. 特殊字符

9. 被和谐词

DAY2

一, 边界值

有效数据和无效数据的分界点,是容易犯错误的地方,也是测试人员重点测试的内容.具体测试用例书写思路:找到边界值和它两端的值,分别进行测试;

边界值的方法小结

1. 如果输入条件规定了值的范围,则应取到刚刚到这个范围的边界值,以及刚刚超越这个范围边界的值作为输入数据.

   如:两位证书加法器数的范围是:-99~99,则应测试-99,-100,和99,100

2. 输入条件规定了值得个数

   姓名要求1-20个字符,需要测试0,1,2个字符和19,20,21个字符

   某商品信息查询系统,每页最多显示10条商品信息,我们就应该准备商品信息,是能够查询处10,11,1,0条商品记录

   边界值和等价类区别:边界值分析不是从某等价类中随便挑一个作为代表,而是这个等价类的每个边界都要作为测试条件.

 

二, 因果图法

因果图法是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况.

特点:

考虑输入条件的相互制约及组合关系

考虑输出条件对输入条件的依赖关系

 

因果图法基本步骤

利用因果图导出测试用例需要经过以下几个步骤:

1. 找出所有的原因,原因即输入条件或输入条件的等价类

2. 找出所有的结果,结果即输出条件

3. 明确所有输入条件之间的制约关系以及组合关系.(由哪些条件不能组合到一起,哪些条件可以组合到一起)

4. 明确所有输出条件之间的制约关系以及组合关系(哪些输出结果不能同时输出,哪些输出结果可以同时输出)

5. 找出什么样的输入条件组合会产生哪种输出结果

6. 把因果图转换成判定表/决策表

7. 为判定表/决策表中的每一列表示的情况设计测试用例.

因果图中的符号

1. 恒等

2. 非-有因无果,无因有果

3. 或,条件有一个真,结果为真.全假,结果才假

4. 且,都真,结果为真.一个条件假,则都为假

5.  

三, 判定表法

因果图知识一种辅助工具,通过分析最终得到判定表,再通过判定表编写测试用例.但有时画因果图非常麻烦,印象测试效率,可以直接写判定表,进而编写测试用例.

判定表的组成

• 条件装:问题的所有条件

• 动作桩:问题的所有输出

• 条件项:针对条件桩的取值

• 动作项:条件项的各种取值情况下的输出结果

 

四, 场景法

场景法就是模拟用户操作软件时的场景,主要用于测试系统的业务流程.

• 当拿到一个测试任务时,我们并不是先关注某个控件的边界值,等价类是否满足要求,而是先要关注它的主要功能和业务流程是否正确实现,这就需要使用场景法来完成测试

• 当业务流程测试没有问题,也就是该软件的主要功能没有问题时,我们再重点从边界值,等价类等方面对控件进行测试.

在冒烟测试时也主要采用场景法进行测试.

场景法中的两个重要的概念

• 基本流

  • 按照正确的业务流程来实现的一条操作路径(模拟正确的流程)

• 备选流

  • 导致程序出现错误的操作流程(模拟错误的操作流程)

用例场景时用来描述流经用例路径的过程,这个过程从开始到结束遍历用例中所有基本流和备选流.

用例场景产生的背景

在使用场景法测试用例时,需要覆盖系统用例中的主成功场景和扩展场景

当使用场景法测试程序没有问题时,可以再使用边界值,等价类方法对账号,密码进行更急细致,完整的测试.

测试用例矩阵:

用例编号, 场景/条件,账号,密码,预期结果

五, 流程分析法

流程分析法主要时针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计,是从白盒测试设计方法中的路径覆盖分析法借鉴过来的一种方法

• 在白盒测试中,路径就是指函数代码的某个分支组合,路径覆盖法需要构造足够的用例覆盖函数的所有代码路径

• 在黑盒测试中若将软件系统的某个流程堪称路径的话,则可以针对该路径使用路径分析的方法设计测试用例

优点:

降低了测试用例设计难度,只要搞清楚各种流程,就可以设计出高质量的测试用例来,而不需要太多测试方面的经验

在测试时间比较紧迫的情况下,可以有的放矢的选择测试用例,而不完全根据经验来取舍.

流程分析法的步骤

第一步:详细了解需求

第二步:根据需求说明或界面原型,找出业务流程的各个页面以及各页面之间的流转关系

第三步:画出业务流程(产品经理使用Axure)

第四步:写用例,覆盖所有的路径分支.

流程分析法总结

• 流程分析法适用于有先后顺序的测试.常用于业务流程测试,安装流程测试等等。

• 每个流程就是一条测试用例，它知识在测试整体流程是否正确，细节还需要使用等价类，边界值等方法进行完善；

• 流程分析法重点在于测试流程.因此,一般每个流程用一个测试用例验证

流程测试没有问题并不能说明系统功能没有问题,还需要正对每步功能进行测试.对于包含复杂流程的系统,只有功能点和处理流程都进行测试覆盖,才算是比较充分的测试

 

六, 错误推测法

错误推测法是指利用直觉和经验猜测出出错的可能类型，有针对性列举出程序中所有可能的错误和容易发生错误的情况，它是测试经验丰富的测试人员喜欢使用的一种测试用例设计方法。

基本思想

凭着直觉和经验来设计测试用例，它是根据之前的项目相关的 bug 数据总结来的

基本思想是列举出可能犯的错误或错误易发生的清单，然后根据清单编写测试用例；这种方法很大程度上是凭经验进行的，即凭人们对过去所作测试结果的分析，对所揭示缺陷的规律性作直觉的推测来发现缺陷

采用错误推测法，最重要的是要思考和分析测试对象的各个方面，多参考以前发现的Bug的相关数据，总结的经验，个人多考虑异常的情况，反面的情况，特殊的输入，以一个攻击者的态度对待程序，才能够设计出比较完善的测试用例

DAY3

正交表法测试用例

AT&T 案例 1000 个用例 缩减至 422 个测试用例.发现了 41 个缺陷.

于最初计划相比用正交表设计测试用例执行工作量不到 50% ,但却多发现 28% 的缺陷,而且测试人员个人的效率也增加了.

正交排列法概述

能够使用最小的测试过程集合获得最大的测试覆盖率,当可能的输入数据或者输入数据的组合数量很大时,由于不可能为每个输入组合都创建测试用例,可以采用这种方法.

正交表的概念

一种特制的表,一般的正交表记为:L_n(m^k)

• n 是表的行数,也就是需要测试组合的次数.

• k 是表的列数,标识控件的个数(因素的个数,或因子个数)

• m 是每个控件包含的取值个数(各因素的水平数,即各因素的状态数)

  如:

  • 有四个控件

  • 每个控件有3个取值

  • 9 为需要测试的组合个数

  • 叫 4 因素 3 水平.

使用正交排列法的局限性

目前常见的正交排列表只有前面俘虏文件中给出的几种

即使是已有的正交排列表,基本都要求每个控件中取值的个数要相等,这在实际软件中很少遇到

没有现成的正交排列表怎么办?

通过正交排列法的学习,我们更多的应该学习到一种测试思想,也就是在从所有组合集合中选取测试数据时,应该均匀的选取其中的组合作为测试用例,而不要知识在某个局部选取数据

混合正交表

水平数不同:

因素(变量)的水平数(变量的取值)不相同

体型	年龄段	性别
胖	老人	男
适中	青年	女
瘦	儿童

找不到现成的正交表,就只能使用工具来生成!

正交表生成工具 allpairs

复制取值表的数据,放到文本文档中保存(注意不要更改任何格式,例如文件叫Test2.txt)

把文本文档放在allpairs文件夹中

win+r 进入控制台,进入allpairs文件夹

在控制台中输入 allpairs.exe Test2.txt>Test21.txt (Test21自己起的名字,会自动创建)

 

测试方法的选择

• 根据程序的重要性和一旦发生故障将造成的损失来确定测试等级和测试重点

• 认真选择测试策略,以便尽可能少的使用测试用例,发现尽可能多的程序错误.因为一次完整的软件测试过后,如果程序中遗留的错误过多并且严重,则表明该次测试是不足的,而测试不足则意味着让用户承担隐藏错误带来的危险,但测试过度又会带来资源的浪费.因此测试需要找到一个平衡点.

通常在确定测试方法时,有以下几条参考原则:

1. 拿到一个测试任务时,先关注它的主要功能和业务流程,业务逻辑是否正确实现,考虑使用场景法.

2. 需要输入数据的地方,考虑采用等价类划分法,包括输入条件和输出条件的等价划分,将无限测试变成有限测试

3. 在任何情况下都必须采用边界值分析法.这种方法设计出的测试用例发现程序错误的能力最强.

4. 如果程序的功能说明中含有输入条件的组合情况,则一开始就应该考虑选用因果图和判定表法

5. 对于参数配置类的软件,需要考虑参数之间的组合情况,考虑使用正交排列法选择较少的组合方式(最少的测试用例获得最大的测试覆盖率)

6. 对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度.如果没有达到要求的覆盖标准,则应当再补充更多的测试用例

7. 采用错误推断发再追加测试用例--依靠测试工程师的经验和智慧

 

测试用例的力度

最简单的测试用例时测试的纲要,仅仅指出要测试的内容

测试用例写的过于简单,则可能失去了测试用例的意义.过于简单的测试用例设计其实并没有进行"设计",知识需要把测试的功能模块记录下来而已,它的作用仅仅是在测试过程中作为一个简单的测试计划,提醒测试人员测试的主要功能包括哪些而已.

最复杂的测试用例则会指定输入的每项数据,期待的结果即检验方法,具体到界面元素的操作步骤,指定测试的方法和工具等.

测试用例写的过于复杂或详细,会带来两个问题:一个时效率问题,另一个时维护成本问题.另外,测试用例设计的过于详细,留给测试执行人员的思考控件就比较少,荣誉限制测试人员的思维.

大多数的测试团队编写的测试用例的力度介于两者之间.

测试用例的本质

测试用例设计的本质应该是再设计的过程中理解需求,检验需求,并把对软件系统的测试方法的思路记录下来,以便指导将来的测试

• 基于需求的测试用例设计

  • 验证对需求的覆盖是软件测试的根本目的

  • 要把测试用例当成活得文档,因为需求是活得,变化得.因此再设计测试用例方面应该要把敏捷方法的:及时响应变更比遵循计划更有价值

不要认为测试用例设计师一个阶段,测试用例的设计也需要迭代,再软件开发的不同阶段都要回来重新评审和完善测试用例.

测试用例评审

1, 同行评审

• 测试用例的检查方式有很多,同行评审时其中最敏捷的一种

• "个体和交互比过程和工具更有价值",这强调了测试用例设计者之间的思想碰撞,通过探讨,写作来完成测试用例的设计.

2.用户评审

• 顾客的写作比合同谈判更有价值

如果测试时对产品的批判,则顾客应该指最终用户或顾客代表(再内部可以是市场调查人员或相关领域专家);

如果测试被定义为对开发提供版主和支持;那么顾客就是程序员

 

软件缺陷的定义

IEEE 1983 of IEEE Standard 729 中对软件缺陷作了一个标准的定义:

从产品内部看,软件缺陷时软件产品开发或维护过程中存在的错误,毛病等各种问题;从外部看,软件缺陷时系统所需要实现的,某种功能的失效或违背.

因此软件缺陷就是软件产品中所存在的问题,最终表现为用户所需要的功能没有完全实现,没有满足用户的需求.

 

软件缺陷时指存在于软件(程序,数据,文档)中的那些不符合用户需求的问题

• 软件未达到需求规格说明书表明的功能

• 软件出现了需求规格说明书指明不会出现的错误

• 软件的功能超出了需求规格说明书指明的范围

• 软件未达到需求规格说明书虽未指明而应该达到的目标

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

计算器示例

计算器说明书一般声称该计算器将准确无误地进行加减乘除运算.如果测试人员或用户选定两个数值,按下"+"号,结果没有反应.

软件未达到软件需求规格说明书表明的功能

若在进行测试时,发现除了规定的加减乘除功能外,还能够进行平方根的运算,而这一功能并没有在说明书的功能中规定

软件的功能超出了需求规格说明书指明的范围

若在测试过程中发现,因为电池没电而导致了计算不正确,但软件需求规格说明书未能指出在此情况下应如何进行处理.

软件未达到软件需求规格说明书未指明而应该达到的目标

假如计算器说明书指明计算器不会出现崩溃,死锁或者停止反应,而在用户随意按,敲键盘后,计算器停止或没有了反应

软件出现了需求规格说明书指明不会出现的错误

测试人员或最终用户发现计算器某些地方不好用,比如,案件太小,显示屏在亮光下无法看清等.

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

软件缺陷的表现形式

• 功能,特性没有实现或部分实现

• 设计不合理,功能特性不明确,逻辑不清楚或存在矛盾

• 产品实际结果和所期望的结果不一致

• 没有达到需求规格说明书所规定的性能指标等

• 运行出错,包括运行中断,系统崩溃,界面混乱等

• 数据不正确,精度不够,不完整或格式不统一

• 用户不能接受的其他问题,如存取时间过长,界面不美观

• 硬件或系统软件上存在的其他问题.

软件缺陷产生的原因

软件缺陷的根源

交流不充分

客户与开发人员,开发人员与测试人员等

软件的复杂性

功能复杂,开发复杂,测试复杂

开发人员的错误

对需求的理解,开发压力,能力与经验

需求的变化

需求说明书,设计文档,程序的变更

进度压力

项目后期比较紧

 

软件缺陷分类-缺陷状态

缺陷状态	描述
提交	已提交的缺陷
打开	确认"提交的缺陷",等待处理
拒绝	拒绝"提交的缺陷",不需要修复或不是缺陷,重复缺陷,无法重现
修复	程序员修复缺陷后提交的一个状态
关闭	经测试人员经过回归测试后,确认修复的缺陷,将其关闭
推迟	可在后续版本解决,但要确定修复日期或版本

 

软件缺陷的信息

属性名称	描述
缺陷ID	唯一的缺陷 ID ,可以根据该 ID 追踪缺陷
缺陷状态	缺陷状态跟踪修复过程的进展情况
缺陷标题	缺陷标题
缺陷严重程度	对软件的影响程度,分致命,较严重,严重,一般,低
缺陷的优先级	缺陷修复的先后顺序,即哪些缺陷优先修正,哪些稍后修正
缺陷所属模块	缺陷所属的项目和模块,要能较精确的定位至模块
缺陷记录者	提交缺陷的人员姓名
缺陷提交时间	缺陷提交时间
缺陷处理人	处理缺陷的处理人
处理结果描述	对处理结果的描述
缺陷处理时间	缺陷处理时间
缺陷验证人	缺陷验证人
验证结果描述	对验证结果的描述(通过,不通过)
缺陷详细描述	缺陷的重复步骤
缺陷环境说明	测试环境描述
必要的附件	如涉及到附件的或错误现象的图片等

软件缺陷的严重程度划分

严重等级	描述
5-Critical	系统瘫痪,异常退出,死循环,严重的计算错误
4-VeryHigh	频繁的死机,系统大部分功能不可用
3-High	a.功能点没有实现,或不符合用户需求 b.数据丢失
2-Medium	a.影响一个相对独立的功能 b.仅仅在特定条件上发生 c.与产品需求定义不一致 d.断断续续的出现问题
1-Low	表面性错误(如错别字)

 

软件缺陷分类-BUG类型

缺陷类型	内容说明	备注
系统缺陷	1.由于程序所引起的司机,异常退出 2.程序死循环 3.程序错误	不能执行正常工作或重要功能,使系统崩溃或资源不足
数据缺陷	1.数据计算错误 2.数据约束错误 3.数据输入,输出错误	严重地影响系统要求或基本功能地的实现,且没有办法更正(重新安装或重新启动不属于更正方法
数据库缺陷	1.数据库发生死锁 2.数据库的表,缺省值未加约束条件 3.数据库连接错误 4.数据库中的表有过多的空字段
接口缺陷	数据通信错误,程序接口错误
功能缺陷	功能无法实现,.功能实现错误	严重的影响系统要求或基本功能的实现,但有合理的办法更正(重新安装或重新启动不属于更正方法)
安全性缺陷	用户权限无法实现 超时限制错误 访问控制错误 加密错误
兼容性缺陷	与需求规定配置兼容性不符合
性能缺陷	未能达到预期的性能目标 性能测试中出错,导致无法继续进行测试
界面缺陷	操作界面错误 打印内容,格式错误 删除操作未给出提示 长时间操作未给出提示 界面不规范	操作者不方便或遇到麻烦,但不影响执行工作功能的实现
建议	功能建议 操作建议	建议性的改进要求

开发人员拒绝修改的缺陷

• 程序员无法重现h或者现象难以捕捉

• 没有明确的报告以说明重现缺陷的步骤

• 程序员无法读懂的缺陷报告

• 用户很少使用或者不符合用户使用习惯的操作出错

• 由不受新人的测试人员提出

•