软件测试技术笔记之一

1. 选择
2. 填空
3. 解答
4. 案例分析

绪论

软件测试技术——测试任务

白盒测试和黑盒测试的区别包括以下几点：

定义不同

黑盒测试：顾名思义就是把测试对象看作一个不能打开的黑盒子。测试时，测试人员完全不用考虑盒子里面的逻辑结构和具体运作，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明，检验输出结果对不对。

白盒测试：与黑盒恰恰相反，这种方法是把测试对象看作一个打开的透明盒子。测试时，测试人员会利用程序内部的逻辑结构及有关信息，通过在不同点检查程序状态，检验程序中的每条通路是否都能按预定要求进行正确工作。

测试对象不同

黑盒测试：主要针对的是程序所展现给用户的功能。

白盒测试：主要针对的是程序代码逻辑，简单的说，就是前者测试最终展示功能，后者测试后台程序。

测试方式不同

黑盒测试：功能测试，是通过测试来检测每个功能是否都能正常使用。

白盒测试：称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。

测试目的不同

黑盒测试：把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。

白盒测试：通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试。在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。

测试原则不同

黑盒测试：以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。

白盒测试：一个模块中的所有独立路径至少被测试一次。所有逻辑值均需测试 true 和 false 两种情况。

静态测试与动态测试

静态测试是指测试不运行的部分：只是检查和审阅,如规范测试、软件模型测试、文档测试等。动态测试是通常意义上的测试，也就是运行和使用软件。

静态测试包括：

1. 代码测试
2. 界面测试
3. 文档测试

单元测试、集成测试以及系统测试

方式不同

• 单元测试一般由开发小组采用白盒方式来测试。

• 集成测试一般由开发小组采用白盒加黑盒的方式来测试。

• 系统测试一般由独立测试小组采用黑盒方式来测试。

粒度不同

• 单元测试的粒度最小。

• 系统测试的粒度最大。

• 集成测试界于单元测试和系统测试之间，起到“桥梁作用”。

内容不同

• 单元测试主要测试单元是否符合“设计”。

• 集成测试既验证“设计”，又验证“需求”。

• 系统测试主要测试系统是否符合“需求规格说明书”

$\alpha$测试与$\beta$测试

测试时间不同：

Beta测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段。

alpha测试简称“α测试”，可以从软件产品编码结束之时开始，或在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。

测试的目的不同：

α测试的目的是评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能和支持）。尤其注重产品的界面和特色。α测试即为非正式验收测试。

Beta测试是一种验收测试，通过了验收测试，产品就会进入发布阶段。

测试人员及场所不同：

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，α测试不能由程序员或测试员完成。α测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。

Beta测试由软件的最终用户们在一个或多个客户场所进行。开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。

回归测试、冒烟测试和随机测试

回归测试：

对软件的新版本测试时，重复执行上一个版本测试时的用例。回归测试可以在任何测试阶段进行，既有黑盒测试的回归，也有白盒测试的回归。

冒烟测试：

对新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性

随机测试：

随机测试是指所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性错误。

软件测试过程模型

• V模型

• W模型

• X模型

• H模型

软件的生命周期

V模型

先开发，后测试

软件开发与软件测试的关系？（用V模型回答即可）

W模型

边开发，边测试$\longrightarrow$测试与开发同步进行

W模型：两个V字型模型

软件开发与软件测试的关系？（用W模型回答即可）

X模型

H模型

作业：

对矿泉水瓶这个产品进行相应的测试？从哪些方面考虑。

1. 外观方面：水瓶的高度、底座，水瓶上的字体颜色大小是否合适等等；
2. 功能方面：水瓶是否能够装水不漏、能不能够让人喝到水、瓶盖拧紧不漏的时候能不能让人拧开；
3. 性能方面：抗压、抗摔、抗高温、抗低温；
4. 安全方面：物理方面：瓶子是否有凸起刺手的地方，瓶口是否光滑；化学方面就是会不会产生有毒物质；
5. 易用性方面：水瓶的信息是否全面（保质期、生产日期、厂商等等），方不方便携带（手拿、放包里）；
6. 兼容性方面：装其他液体会不会产生有毒物质、能不能装固体。

参考：(77条消息) 软件测试笔记——如何测试一个矿泉水瓶？_努力小c的博客-CSDN博客_如何测试一个水瓶

测试的四个阶段：

1. 单元测试

2. 集成测试

3. 系统测试

4. 验收测试

测试考虑的方面：

• 界面友好性测试$\longrightarrow$矿泉水瓶是否有好看的样式

• 功能测试$\longrightarrow$矿泉水瓶是否能够分装矿泉水不漏、矿泉水瓶是否耐用（一般指水瓶塑料质量）、矿泉水瓶瓶盖和瓶身是否匹配

• 易用性测试$\longrightarrow$水瓶是否设计合理，符合人体工学方便手拿

• 常规性测试

• 兼容性测试$\longrightarrow$高温下能不能保持、装其它液体并较好地保存

测试需求分析

1. 测试需求是什么？

   1. 测试需求主要解决“测什么”的问题

   2. 测试需求应全部覆盖已定义的业务流程

   3. 测试目标不等于质量目标，质量水平测试目标体现测试价值该项目的测试边界哪些东西要测试

2. 为什么需要软件测试需求？

   1. 软件测试需求是设计测试用例的依据
   2. 有助于保证测试的质量和进度
   3. 软件测试需求是衡量测试覆盖率的重要指标

3. 如何进行软件测试需求？

   测试需求分析的主要目的：依据需求文档提取测试点，根据测试点来编写测试用例

   • $\textcolor{red}{测试点分析}$：

     1. 通过分析需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容（功能测试）
     2. 通过分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在功能交互的功能项，给出对应的验证内容；（功能交互测试）
     3. 考虑到需求的完整性，要充分覆盖软件需求的各种特征，包含隐形需求的验证，比如界面的验证，注册账号的唯一性验证（界面、易用性、安全性、性能压力）

测试需求分析过程

1. 了解项目的背景、产品价值，解决什么业务问题→分析业务需求，确定测试目标

2. 了解用户是谁，用户所关心的问题→分析用户需求

3. 确定待测软件的功能特性，可以从整体到局部，从上到下，逐层分解，形成待测试的功能列表

4. 确定待测软件的非功能特性，基于本系统的特点而需特别关注的质量属性

5. 确定测试项的优先级

作业：软件测试计划书在第一次实验之前完成（小组）

软件测试计划

测试用例

定义：测试用例=输入（测试步骤和操作步骤）+输出（期望结果）+ 测试环境（系统环境设置）

黑盒测试

基本概念：黑盒测试是从用户观点出发的测试，其目的是尽可能发现软件的外部行为错误。⭐️

黑盒测试用例设计方法

1. 等价类划分法

2. 边界值分析法

3. 因果图法

4. 判定表法

5. 正交分解法

6. 基本路径分析法

7. 场景设计法

8. 错误推测法

等价类划分法

把所有可能的输入数据，即程序输入域划分为若干个 互不相交的子集，称为等价类，然后从每个等价类中 选取少数具有代表性的数据作为测试用例，进行测试。

• 在分析需求规格说明的基础上划分等价类，列出等价类表。

• 等价类是某个输入域的子集，在该子集中每个输入数据的作用是等效的。

• 分为有效等价类和无效等价类。

确定等价类的原则

• 输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类(在范围内)和两个无效等价类(不在范围内)。

• 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类。

• 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。

• $\textcolor{red}{多输入的或关系}$：在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。

• $\textcolor{red}{多输入的且关系}$：在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。

• $\textcolor{red}{细分等价类}$：在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。

确定测试用例

(a) 建立等价类表，列出所有划分出的等价类：

(b) 为每个等价类规定一个唯一的编号；

© 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类；⭐️

(d) 重复©，最后使得所有有效等价类均被测试用例所覆盖；

(e) 设计一个新的测试用例，使其只覆盖一个无效等价类；⭐️

(f) 重复e)使所有无效等价类均被覆盖。

例如：

是否是等腰三角形的无效等价类？怎么写？

首先写满足三角形的基本条件，然后是三条边都不相等。$\longrightarrow$a$\neq$b$\neq$c

等边三角形的无效等价类？

同样是必须先满足三角形的基本条件，然后是三条边两两互不相等，总共可以写出三条无效等价类。$\longrightarrow$a$\neq$b或b$\neq$c或a$\neq$c

边界值分析法

在等价类划分基础上进行边界值分析测试的基本思想是， 选取正好等于、刚刚大于或刚刚小于等价类边界的值作 为测试数据，而不是选取等价类中的典型值或任意值做 为测试数据。

• 边界值分析法是一种很实用的黑盒测试用例方法，它具有很强的发现故障的能力。

• 很多错误发生在输入或输出范围的边界上，因此针对各种边界情况设置测试用例， 可以更有效地发现缺陷。

• 边界条件就是软件计划的操作界限所在的边缘条件。

-实例：

答题规范：

$\textcolor{red}{边界}$是指相当于输入等价类和输出等价类而言，稍高于边界值及稍低于其边界值的一些特定情况。

对于一个n变量的程序，边界值分析测试会产生4n+1个测试用例。（不考虑区域外的无效等价类）

健壮性边界测试

• 健壮性测试是边界值分析的一种扩展

• 变量除了取min，min＋，nom， max－，max五个边界值外， 还要考虑采用一个略超过最大值（max+）以及一个略小于最 小值 (min-) 的取值

对于一个n变量的程序，健壮性边界值测试将产生6n+1个测试用例（考虑区域外的无效等价类）

健壮性测试最有意义的部分不是输入，而是预期的输出，观察例外情况如何处理。

确定边界值的原则

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

   • 

2. 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少、比最大个数多 1的数作为测试数据。

   • 

3. 很多如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。

4. 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。

$\textcolor{red}{题目}$：等价类划分

条件规定了取值范围或值的个数的情况下（1个有效，2个无效）

等价类划分题目的正确回答形式：

1. 等价类划分——格式：

   

2. 测试用例设计——格式：

   

16组边界测试

基于组合技术和组合优化的方法

• 判定表/决策表方法

• 因果图

• 两两组合方法

• 正交实验法

判定表

在所有的黑盒测试方法中，基于判定表的测试是最严格，最具有逻辑性的测试方法。

定义：判定表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。

1. 条件桩

2. 条件项

3. 动作桩

4. 动作项

判定表的特点：

• 条件的顺序无关

• 操作/活动的顺序无关

• 规则间的无关联

判定表方法步骤

1. 列出条件桩

2. 列出动作桩

3. 填入条件项及其组合

4. 填入动作项，制定初始判定表

5. 简化、合并相似规则或者相同动作

判定表实例

因果图

多种输入条件的组合，输入之间有关系，例如，约束关系、组合关系，需要进行因果分析，不可直接采用判定表方法。

因果图基本符号

• 互斥 E：a、b、c 只能有一个成立，但是可以都不成立。

• 包含 I：a、b、c 中至少有一个成立。可以多选但不能不选。

• 唯一 O：a、b、c 有且仅有一个为 1。也就是说多个原因中有且只有一个成立。

• 要求 R：如果 a 成立，则要求 b 必须也成立，其他的不做约束。一个出现，另一个也一定出现

• 强制屏蔽 M：对于结果的约束。当 a = 1 时，要求 b 必须为0，其他的不约束。a 不成立时，b 的值不一定。唯一和互斥的区别是：唯一必须选一个；互斥可以不选，如果选只能选一个，几个原因中有且只有一个成立。

因果图的基本流程：

1.分析软件规格说明文档描述的哪些是原因（输入条件），哪些是结果（输出条件）。原因常是输入条件或输入条件的等价类，结果是输出条件；
2.分析程序规格说明的描述中的语义内容，将其表示成连接各个原因与各个结果的“因果图”；
3.标明约束条件。在因果图上标上哪些不可能发生的因果关系，表明约束或限制条件；
5.把判定表的每一列作为依据设计测试用例。（因果图导出判定表）

$\textcolor{red}{题目之一}$：

因果图：帮助生成决策表

决策表

中间结点：一般用于抽离多个输入的共性

$\textcolor{red}{题目之二}$：

首先找出输入条件（原因）和输出条件（结果）：

得到因果图：

原因：1	1	1
2	0	1
3	0	1
4	0	0
11：不属于1~4	0	1
21：不移动	1	0

（11）=（1）（2）（3）（~4）

（21）=（~ 1）+（~ 2）+（~ 3）+（4）

最后得到决策表：

因果图回溯

建立有限项的判定表

• 选择一个结果作为当前状态

• 对因果图进行回溯，查找导致该果为1的所有因的组合

• 在判定表中为每个因的组合生成一列

• 对于每种“因”的组合，判断所有其他“果”的状态，并放置在每一列中。

回溯一个or 结点（x=a + b + c，并关系）

个人理解：

x=a+b：

• x=1时，不考虑a=b=1的情况，其它情况都考虑(10,01)；

• x=0时，考虑导致结果为0的所有组合：

  • 考虑a=b=0的所有情况；

回溯一个and 结点，（x=a * b * c, 交关系）

个人理解：

x=a*b*c：

• x=1时，考虑a=b=c=1的所有情况；

• x=0时，考虑导致结果为0的所有组合：

  • 对a=b=c=0只考虑1种；
  • abc(001,010,011…)取值中存在至少一个1时：
    • 为1的只考虑1种
    • 取0的考虑所有组合：
      • 根据交或并运算循环套用规则

因果突发示例：

1️⃣

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

回溯：
(1+2)*(3*4)=x=0
输出：
-7=1时，除了1、2外全为1，且12可取11、10、01
因此输出为x=1的情况就只有三种，因此最后x=0的结果就只有13组
13组
(x)=(5)*(6)=0
set x=0,
so 5=0,6=1 or 5=1,6=0 or 5=0,6=0
5=0,6=1:(5=0考虑所有情况,6=1只考虑一种)
	1=0,2=0;
	3=1,4=1
    1种
5=1,6=0:(5=1只考虑一种,6=0考虑所有情况)
	3=4=0 or 3=0,4=1 or 3=1,4=0
    3种
5=0,6=0:(5=6=0只考虑一种)
    1=0,2=0;
    3=4=0
    1种
最后保留5种

2️⃣找出(91) = 1的输入？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

(91)=~(36)
    =~(32*35)
    =~((~1+31)*(5+8+33+34))
    =~((~1+2*3)*(5+8+(6*9*10)+(7*13*14)))
    =1
36=0 set 32=0 or 35=0
    32=0,35=0时：
    1=1,31=0;5=8=33=34=0
    1种
    32=0,35=1时：
    1=1,31=0;5=1 or 8=1 or 33=1 or 34=1
    。。。直接算很难求，需要结合下面的约束关系图进行问题的简化
        
    存在约束：
    （aRb:a=1,则b=1；a=0，则b不定）(E(6,7)表示6和7至多出现一个1)
    9R6
    10R6
    13R7
    14R7
    E(6,7)
    由以上条件可以知道
    must 36=0(consider all):
		32=0,35=1 or 32=1,35=0 or 32=0,35=0
            
        32=0(all),35=1(only one):
			//32=0(all)
			1=1(one),31=0(all):
				2,3出现一个0既满足:3 kinds      
            
        32=1(one),35=0(all):
			//35=0(all)
            5=0,8=0,33=0(all),34=0(all):(根据并规则，考虑满足的所有情况)
				//33=0(all)-注意约束条件
        		6=1,9=1,10=0;
                6=1,9=0,10=1;
				6=1,9=0,10=0;
				6=0,9=0,10=0;
        		//34=0(all)-注意约束条件
				7=1,13=1,14=0;
                7=1,13=0,14=1;
				7=1,13=0,14=0;
				7=0,13=0,14=0;
				//注意E(5,6,7,8)：5,6,7,8至多有一个1
				so:7 kinds
                    6=1,7=0 3 kinds
                    7=1,6=0 3 kinds
                    6=0,7=0 1 kinds
        32=0,35=0:(只考虑一种)
			so:1 kinds

为什么需要组合覆盖和正交试验法？

新需求

• 多因素组合

• 传统测试方法的大工作量

决策表存在不足

两两组合测试

所有测试数据两两配对，每一对数据至少出现一次，两两组合测试也称结对测试(Pairwise Testing)。大部分缺陷是在进行两个变量取值冲突的测试时被发现的，不仅仅是在所有的组合情况下才会被发现，所以不用测试所有的组合，在一定的时间、一定的人力条件下测试所有的两两组合即可。

• 大部分缺陷是在两个变量取值冲突的测试时被发现的

• 构造测试用例需要涵盖每个因素的所有状态，并且涵盖每2个因素之间的所有交互。

• 不仅仅是在所有的组合情况下才会发现所有的测试缺陷

• 没有必要构造覆盖所有因素的所有组合的测试用例集合，只需要构造覆盖每个因素的所有状态，覆盖任意2个因素所有状态的测试用例集合。

组合覆盖法

成对覆盖：

• 要求任意两个因素的所有水平组合要被覆盖一次

作业：

正交试验法（Orthogonal Test Design Method, OTDM）

正交测试源于正交试验设计方法。从大量的（实验）数据（测试例）中挑选适量的、有代表性的点（条件组合），从而合理地安排实验（测试）的一种科学实验设计方法。

• 正交测试法使用已经构造好了的正交表格来安排试验并进行数据分析。

• 简单易行并且计算表格化，应用性较好。

• 是一种有效减少测试用例个数的设计方法。

正交试验法示例：

简单对比法：

由以上简单对比法可以得到：

m=3，n=3（A、B、C）

第一次：实验n次

第二次：实验(m-1)次

第三次：实验(m-1)次

最后总共实验了：n+2*(m-1)次

正交表法（OrthogonalArrayTesting Strategy,OATS ）

正交表的两大优越性，即“均匀分散，整齐可比”。特性中有任意一条不满足，就不是正交表。

正交表

• 每一列中各数字出现的次数都一样多；

• 任何两列所构成的有序数对出现次数一样多。

正交表法练习：

补充：

$\textcolor{red}{10月17日作业：}$

功能图法

• 每个程序的功能通常由静态说明和动态说明组成

• 静态说明描述了输入条件和输出条件之间的对应关系

• 动态说明描述了输入数据的次序或者转移的次序

• 功能图法就是为了解决动态说明问题的一种测试用例的设计方法

构成：

• 状态迁移图（statetransitiondiagram，STD）：适用于动态说明，输入数据和当前状态决定输出数据和后续状态

• 逻辑功能模型（logicfunctionmodel，LFM）：适合于描述静态说明，输出数据仅由输入数据决定

逻辑功能表：

• 从逻辑功能表中，可以根据所有的输入输出以及状态来生成所需要的节点和路径，形成实现功能图的基本路径组合——>基本路径覆盖法设计测试用例

• 功能图法实际是一种黑盒、白盒混合用例设计方法

测试用例生成规则：

• 节点代替状态，弧线代替迁移。

• 状态迁移图转化为一个程序的控制流程图形式，问题也转换为程序的路径测试问题。

• 从功能图生成实用的测试用例。一个结构化的状态迁移中，定义3种形式的循环：

  • 顺序
  • 选择
  • 重复

功能图生成测试用例的过程：

• 生成局部测试用例：在每个状态中，从因果图生成局部测试用例。局部测试库由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成

• 测试路径生成：利用上面的规则生成从初始状态到最后状态的测试路径；

• 测试用例合成：合成测试路径与功能图中每个状态的局部测试用例。结果是初状态到最后一个状态的一个状态序列，以及每个状态中输入数据与对应输出数据组合。

场景设计法

• 黑盒测试中重要的测试用例设计方法

• 事件触发时的情景便形成了场景，场景的不同触发顺序构成了用例

• 基本流（基本流程）

• 备选流（分支流程）

用例场景：描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流

• 同一事件的不同触发顺序和处理结果就形成事件流

V：表示有效（valid）

I：表示无效

n/a：表示不适用

直黑线表示基本流、备选流用不同的彩色表示

• 场景1：基本流

• 场景2：基本流、备选流1；

• 场景3：基本流、备选流3；

• 场景4：基本流、备选流3、备选流1；

• 场景5：基本流、备选流1、备选流2；

• 场景6：基本流、备选流4

• 场景7：基本流、备选流3、备选流4

• 场景8：基本流、备选流3、备选流1、备选流2

错误推测法

流程：

黑盒测试方法的比较与选择

选择：

• 如果变量引用的是物理量，可采用等价类测试和边界值测试。

• 如果变量引用的是逻辑量，可采用等价类测试用例和决策表测试。

• 如果变量是独立的，可采用边界值分析测试和等价类测试。

• 如果变量不是独立的，可采用决策表测试。

• 如果可保证是单缺陷假设，可采用边界值分析。

• 如果可保证是多缺陷假设，可采用边界值分析测试和决策表测试。

• 如果程序包含大量例外处理，可采用健壮性测试和决策表测试。

小结：

1. 进行等价类划分，包括输入条件和输出条件的等价类划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法；

2. 在任何情况下都必须使用边界值分析方法，经验表明，用这种方法设计出的测试用例发现错误的能力最强；

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

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

5. 功能图法也是很好的测试用例设计方法，可以通过不同时期条件的有效性设计不同的测试数据；

6. 对于业务清晰的系统，可以利用场景法贯穿整个测试案例过程在案例中综合使用各种测试方法；

7. 可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。

场景法实例：

A

AB

AC

AD

AE

答题格式：

软件缺陷的生命周期

定义：

• 软件缺陷生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程

• 缺陷生命周期是各类开发人员一起参与、协同测试的过程

• 软件缺陷一旦发现便进入严密监控之中，直至软件缺陷生命周期终结，这样即可保证在较短的时间内高效率地关闭所有的缺陷，缩短软件测试的进程，提高软件质量，同时减少开发、测试和维护成本。

基本的缺陷生命周期

1. 发现-打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员。

   • 测试人员$\longrightarrow$开发人员

2. 打开-修复：开发人员再现、修复缺陷，然后提交给测试人员去验证。

   • 开发人员$\longrightarrow$测试人员

3. 修复-关闭：测试人员验证修复过的软件，关闭已不存在的缺陷

   • 测试人员

⭐️软件缺陷==（Bug）处理流程==(V)

实际的缺陷生命周期

缺陷处理详细

• 确保每个被发现的缺陷都能够被解决（被解决不一定是将bug完全修复，而是指对该缺陷有一个解决方案，如：延期等）

• 验证：缺陷的修复需要得到测试人员的验证，同时还要进行回归测试，检查这个缺陷的修复是否会引入新的问题；

• 重新打开：重新打开一个缺陷，需要加注释说明、电话沟通等，否则会引起“打开-修复”多个来回，造成测试人员和开发人员不必要的矛盾（背锅侠）

• 关闭：只有测试人员有关闭缺陷的权限，开发人员没有这个权限。

• 暂缓：如果每个人都同意将确实存在的缺陷移到以后处理，应该指定下一个版本号或修改的日期。一旦新的版本开始时，这些暂缓的缺陷应该重新被打开。

• 审阅：可以由测试管理员、项目管理员或其他人来进行，审阅缺陷报告的质量水平；

• 拒绝：如果审阅者决定需要对一份缺陷报告进行重大修改，应该和测试人员一起讨论，由测试人员纠正缺陷报告，然后再次提交；

• 完善：完整地描述了问题的特征并将其分离，那么审查者就会肯定这个报告；

• 分配：分配给适当的开发人员，如果不知道具体开发人员，应分配给项目开发组长，由开发组长再分配给对应的开发人员；

软件缺陷描述|状态

软件缺陷描述|严重性

• 致命的（fatal）、严重的（critical）、一般的（major）、微小的（minor）

软件缺陷描述|优先级

软件缺陷描述|严重性和优先级

• 一般地，严重程度高的软件缺陷具有较高的优先级。

• 严重程度高优先级不一定高，某些严重的软件缺陷只在非常极端的条件下产生

• 严重程度低的优先级不一定低

缺陷报告|缺陷报告的详细信息

软件缺陷报告|缺陷描述的基本要求

• 单一准确

• 可以再现

• 完整统一

• 短小简练

• 特定条件

• 补充完善

• 不做评价

Bug的优先排列：

• 可重复性(Repeatability)

• 可发生性(Visibility)

• 严重性(Severity)

• 优先级=（可重复性+可发生性）X 严重性

软件测试管理|质量成本

软件测试管理|质量成本实例

2、3种情况

实验要求

测试用例撰写要求：

• 用例名：简明扼要

•