软件测试整理三：测试方法、bug

一.黑盒测试

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。

在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，因此不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

包括等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。

1.等价类划分

等价类划分是将系统的输入域划分为若干部分，然后从每个部分选取少量代表性数据进行测试。

等价类可以划分为有效等价类和无效等价类，设计测试用例的时候要考虑这两种等价类。

2.边界值分析法

边界值分析法是对等价类划分的一种补充，因为大多数错误都在输入输出的边界上。

边界值分析就是假定大多数错误出现在输入条件的边界上，如果边界附件取值不会导致程序出错，那么其他取值出错的可能性也就很小。

边界值分析法是通过优先选择不同等价类间的边界值覆盖有效等价类和无效等价类来更有效的进行测试，因此该方法要和等价类划分法结合使用。

常见的边界值

1）对16-bit 的整数而言 32767 和 -32768 是边界

2）屏幕上光标在最左上、最右下位置

3）报表的第一行和最后一行

4）数组元素的第一个和最后一个

5）循环的第 0 次、第 1 次和倒数第 2 次、最后一次

6）6 =< x =< 18时，边界值取 5、6、7、17、18、19，其中5、19为无效边界值，6、7、17、18为有效边界值。

7）若文本框输入字符的个数要求是不大于150字时，测试时边界值为151、150、149、0、1，不选-1因为不存在这种情况。

为什么边界值处容易出错：

软件测试 用例设计方法中的边界值，为什么说程序的边界容易出错呢

白盒测试项目实践经验总结（二）—边界值问题

• for循环，起始条件和终止条件是最重要的。一定要考虑是从0还是1开始，终止条件是<还是<=

• if语句也是常见的错误。if语句中的 <和 <=

• 上下文逻辑错误时，边界值处也可能会出错

举例：

• 当程序的边界是用循环变量去约束的，最简单的for (var a=0; a<=100;a++)这个语句，a的值为100时还可以执行循环体，但是for (var a=0; a<100;a++)这个语句，当a的值为100时，就跳出循环了，不执行循环体了，这两种情况边界就不一样，如果处理不好就会出错。

3.正交试验法

正交是从大量的试验点中挑选出适量的、有代表性的点。正交试验设计是研究多因素多水平的一种设计方法，他是一种基于正交表的高效率、快速、经济的试验设计方法。

正交表：

• 大量的实验组合中，挑选出一部分具有代表性的点进行实验，分析数据。
• 影响实验结果的量称为实验因素（因子），简称因素
• 因素所处的状态或者状况（取值），称为水平
• 在正交表中，每列中不同数字出现的次数相等
• 在任意两列其横向组成的数字对中，每种数字对出现的次数相等
• 正交表Ln(m^k)：m为水平数，n为试验次数，k为因素的数量，这三个数字之间无任何数学关系。仅适用于每一个因素的水平数都相同的正交表

步骤：

• 分析所有对结果有影响的因素（从多角度和方式分析）
• 分析每个因素的水平数量，采用等价类、边界值等方式（需求中说明和未说明的都要分析）
• 选择正交表，只有特定的因素数和水平数才有对应的正交表（在实际中，找最贴近的正交表，正交表的因素数和水平数一般要大于实际的因素数和水平数）

4.状态迁移法（功能图法）

状态迁移法是对一个状态在给定的条件内能够产生需要的状态变化，有没有出现不可达的状态和非法的状态，

使用场合：

• 软件的状态会根据某些内容、条件、操作的变化而变化。

目标：

• 设计足够的用例覆盖系统状态、以及状态–条件组合、状态迁移路径。

步骤：

• 1）识别和列举所有的输入（操作）事件以及IPn（input）（n=1，2，3）
• 2）定义空闲状态（初始状态）：一般以软件刚启动时打开的界面状态为空闲状态
• 3）为空闲状态加操作（只加一次）
• 4）为第三步所产生的的新状态加操作（只加一次，并且曾经加过的操作不再重复添加）
• 5）循环为所有的新增状态加操作，直到没有新状态产生为止
• 6）组合任意的状态，以列表的形式展现，设计和缩写测试用例

若经过几轮分析之后得到一个全新的界面（状态），但是和空闲状态发生了‘隔断’，则将其认为空闲状态的结束，可以结束分析过程。

5.流程分析法（场景法）

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

适用于解决业务流程清晰的功能或者系统。

包括：

• 基本流：软件功能按正常的事件流实现的一条正确流程
• 备选流：除了基本流之外的各支流，包含多种不同的情况

步骤：

• 1）根据说明，描述出程序的基本流和备用流
• 2）根据基本流和各项备用流生成不同的场景
• 3）对每一个场景生成相应的测试用例
• 4）复审测试用例
• 5）确定测试数据

6.因果图法

因果图是用于描述系统输入输出之间的因果关系、约束关系。

因果图的绘制过程是对被测系统的外部特征的建模过程，根据输入输出间的因果图可以得到判定表，从而规划出测试用例。

原因之间约束条件：

1表示事件成立，0表示不成立

• 互斥（E，enclusive）：a+b+c =< 1
• 包含（I，include）：1 =< a+b+c =3
• 唯一（O，only）
• 要求（R，request）：a=1，则b必须等于1

结果之间约束：

• 屏蔽（M，mask）

原因与结果之间的关系：

• 恒等、与、或、非

缺点：

• 只能用做局部的小功能的分析（原因和结果不是很多的情况可用）

优点：

• 能够发现设计中的不足
• 根据需求用因果图设计测试用例，可以发现需求的不足

7.判定表分析法

分析和表达多种输入条件下系统执行不同动作的工具，可以把复杂的逻辑关系和多种条件组合的情况表达的即具体又明确。

主要适用于多条件的内容组合与结果分析。

组成：

• 条件桩
• 动作桩
• 条件项
• 动作项

使用条件:

• 所有的条件桩在表中的位置和顺序互相不影响
• 所有的动作桩的顺序不会因为条件顺序的变化而产生不同

实现的步骤：

• 1）识别出操作条件（原因）和对应的动作（结果）
• 2）分析条件的组合数量 （2^n条件项）
• 3）简化和优化结果，摘出一些不可能存在的情况，对其中不合理或者重复的组合进行取舍

注：条件只有0、1两种情况可用。

例子：

假设某程序有三个输入变量year 、month、day（month、day和year均为整数值，并且满足：1≤month≤12、1≤day≤31和1981≤year≤2050），分别作为输入日期的年份、月份、日，通过程序可以输出该输入日期在日历上隔一天的日期。试用判定表法设计该程序正确输入条件下的测试用例。

8.输入域测试法

输入域测试法是针对输入会有各种各样的输入值的一个测试，

主要考虑极端测试、中间范围测试，特殊值测试 。

9.输出域分析法

输出域分析法是对输出域进行等价类和边界值分析，确定是要覆盖的输出域样点，反推得到应该输入的输入值，从而构造出测试用例，

目的是为了达到输出域的等价类和边界值覆盖。

10.错误猜测法

错误猜测法主要是针对系统对于错误操作时对于操作的处理法的猜测法，从而设计测试用例

11.异常分析法

异常分析法是针对系统有可能存在的异常操作，软硬件缺陷引起的故障进行分析，分析发生错误时系统对于错误的处理能力和恢复能力依此设计测试用例。

12.测试大纲法、探索性测试法、猴子测试法

测试大纲法：

• 一种着眼于需求的方法
• 为列出各种测试条件将需求转换为大纲的形式
• 无需用例设计，一般从根节点开始分析，到叶节点为止，这样的一条路径就是一条测试用例
• 一般用于快速的测试和过程记录，用例一般后补

探索性测试法：

• 基于经验和直觉
• 是计划内测试用例的补充
• 执行前也要设计测试用例

猴子测试法

• 没有测试用例，无意识的行为

13.用例设计方法综合选择

1）首先进行等价类划分

2）在任何情况下都必须使用边界值分析

3）如果程序的功能说明中含有输入条件的组合情况，则一开始就可以选用因果图法和判定表驱动法

4）对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果

5）状态迁徙法：可以通过不同时期条件的有效性设计不同的测试数据

6）对于业务流清晰的系统，可以利用场景法贯彻整个测试案例过程

7）可以用错误推测法追加一些测试用例（探索性测试）

8）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如没有达到要求的覆盖标准，则应该在补充测试用例。

在所有的测试用例设计方法中，没有单独使用的，都是融合在一起使用的，往往在一个软件的界面中可以使用好几种测试用例的设计方法。

需求的覆盖程度 = 被测试用例覆盖的需求数/需求总点数

二.白盒测试

白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。

白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。理由是：

• 穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序；

• 穷举路径测试不可能检查出程序因为遗漏路径而出错；

• 穷举路径测试发现不了一些与数据相关的错误

白盒测试需要遵循的原则有：

1. 保证一个模块中的所有独立路径至少被测试一次；
2. 所有逻辑值均需要测试真（true）和假（false）；两种情况；
3. 检查程序的内部数据结构，保证其结构的有效性；
4. 在上下边界及可操作范围内运行所有循环。

白盒测试方法有逻辑覆盖法，程序插桩技术，基本路径法，符号测试，错误驱动测试

常用白盒测试方法：

• 静态测试：不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。

• 动态测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。

• 白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

六种覆盖标准发现错误的能力呈由弱到强的变化：

• 1.语句覆盖每条语句至少执行一次。
• 2.判定覆盖每个判定的每个分支至少执行一次。
• 3.条件覆盖每个判定的每个条件应取到各种可能的值。
• 4.判定/条件覆盖同时满足判定覆盖条件覆盖。
• 5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
• 6.路径覆盖使程序中每一条可能的路径至少执行一次。

三、bug

1.软件缺陷

所有不满足需求或者超出需求的都是缺陷

• 软件未实现产品说明书中要求的功能
• 软件中出现了产品说明书中指明不应该出现的功能
• 软件实现了产品说明书中未提到的功能
• 软件未实现了产品说明书中虽未提及但是应该实现的目标
• 软件难以理解，不易使用，运行缓慢或者（从测试的角度看）最终用户会认为不好。

2、软件缺陷产生的原因

软件缺陷产生的原因

软件缺陷产生的原因有哪些？【软件测试】

在软件开发的过程中，软件缺陷的产生是不可避免的。软件缺陷的产生主要是由软件产品的特点和开发过程决定的。
　
1）需求方面

• 软件本身需求不清晰，

• 做需求分析时对客户的需求理解不清楚，

• 不同阶段的开发人员相互理解不一致。例如，软件设计人员对需求分析的理解有偏差，编程人员对系统设计规格说明书某些内容重视不够，或存在误解。

• 对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。

• 最终都可能导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷。

• 另外在开发过程中,客户频繁变更需求也会影响软件最终的质量

2）软件结构复杂

• 如果软件系统结构比较复杂，很难设计出一个具有很好层次结构或组件结构的框架，这就会导致软件在开发、扩充、系统维护上的困难。
• 即使能够设计出一个很好的架构，复杂的系统在实现时也会隐藏着相互作用的难题,，从而导致隐藏的软件缺陷。

3）编码问题

1. 算法错误：在给定条件下没能给出正确或准确的结果。 　
   比如：对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误。

2. 语法错误：对于编译性语言程序，编译器可以发现这类问题；但对于解释性语言程序，只能在测试运行时发现。

3. 计算和精度问题：计算的结果没有满足所需要的精度。

4. 系统结构不合理、算法选择不科学，造成系统性能低下。

5. 接口参数传递不匹配，导致模块集成出现问题。

• 没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题，从而存在系统安全性、可靠性的隐患。

• 系统运行环境的复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的问题；在系统实际应用中，数据量很大。从而会引起强度或负载问题。

• 新技术的采用，可能涉及技术或系统兼容的问题，事先没有考虑到。

• 项目组成员技术水平参差不齐，新员工较多，或培训不够等原因也容易引起问题。

4）项目期限短

• 开发周期短，需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来进行，工作不够充分，结果也就不完整、不准确，错误较多；周期短，还给各类开发人员造成太大的压力，引起一些人为的错误。

• 开发流程不够完善，存在太多的随机性和缺乏严谨的内审或评审机制，容易产生问题。

2.缺陷的识别

客观依据：

• 需求文档、设计文档
• 产品原型
• 测试用例

主观依据：

• 同行业的类似的成熟软件
• 和开发人员沟通，和有经验的测试人员沟通
• 同行业隐性需求

在识别缺陷时，需灵活对待。

3.bug的类型

需求分析阶段多：

• 文档

集成测试阶段多：

• 系统/模块接口

系统测试阶段多：

• 功能

• 用户界面

验收测试阶段多：

• 性能

• 系统/模块接口

实施过程中多：

• 软件包

接口测试常见的bug有：

• 特殊值处理不当导致程序异常退出或者崩溃

• 类型边界溢出，导致数据读出和写入不一致

• 取值边界外未返回正确的错误信息

• 权限未处理，可以访问其他用户的信息

• 逻辑校验不完善，可以利用漏洞获取非正当利益

• 状态处理不当，导致逻辑出现错误

• 数组类型item个数为0或者item重复时程序异常退出

4.bug的属性

类型、严重程度、优先级、状态、起源、来源、根源

• 正向测试中产生的缺陷修复优先级大于反向测试的缺陷。

• 状态：缺陷跟踪修复过程的进展情况

5.bug的状态（生命周期）

• 1、New:（新的）

当某个“bug”被第一次发现的时候，测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New

• 2、Assigned（已指派的）

当一个bug被指认为New之后，将其反馈给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”

• 3、Open（打开的）

一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”

• 4、Fixed（已修复的）

当开发人员进行处理（并认为已经解决）之后，他就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组

• 5、Pending Reset（待在测试的）

当bug被返还到测试组后，我们将bug的状态设置为Pending Reset”

• 6、Reset(再测试)

测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”

• 7、Closed（已关闭的）

如果测试人员经过再次测试之后确认bug 已经被解决之后，就将bug的状态设置为“Closed”

• 8、Reopen（再次打开的）

如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”

• 9、Pending Reject（拒绝中）

如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为“Pending Reject”

• 10、Rejected(被拒绝的)

测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”

• 11、Postponed（延期）

有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed“

6.bug的评测

Bug的priority（）和severity（）是两个重要属性，

通常人员在提交bug的时候，只定义severity（缺陷严重程度），而将priority（修复优先级）交给leader定义。

通常bug管理中，severity分为四个等级blocker、critical、major、minor/trivial，主要依据缺陷对于软件的影响程度。

priority分为五个等级immediate、urgent、high、normal、low，主要依据缺陷对于测试工作的影响程度。

缺陷的严重程度和优先级无任何直接关系。不要认为严重的缺陷，修复优先级就高。如果碰到优先级和严重程度都高的缺陷也只是偶然。

Severity：

• blocker：即系统无法执行，崩溃，或严重资源不足，应用模块无法启动或异常退出，无法测试，造成系统不稳定。（任何一个主要功能丧失）

常见的有严重花屏、内存泄漏、用户数据丢失或破坏、系统崩溃/死机/冻结、模块无法启动或异常退出、严重的数值计算错误、功能设计与需求严重不符、其它导致无法测试的错误， 如服务器500错误。

• critical：即映像系统功能或操作，主要功能存在严重缺陷，但不会映像到系统稳定性。（主要功能部分丧失或者次要功能部分丧失）

常见的有：功能未实现，功能错误、系统刷新错误、数据通讯错误、轻微的数值计算错误、影响功能及界面的错误字或拼写错误。

• major：即界面、性能缺陷、兼容性。（次要功能未完全实现，但是不影响正常使用）

常见的有：操作界面错误，边界条件错误，提示信息错误，长时间操作无进度提示，系统未优化，兼容性问题。

• minor/trivial：即易用性及建议性问题。

Priority：

• immediate：即马上解决，
• urgent：急需解决
• high：高度重视，有时间要马上解决
• low：在系统发布前解决，或确认可以不用解决

优先级的衡量一般可以根据测试的软件系统的全业务流程分。

• 软件的基本功能的缺陷，优先级高，甚至需要立即解决
• 软件的备选流、基本功能测试中的反向测试的内容，优先级较低，甚至有些可改可不改。