7 软件实现

实现:编码和测试。

编码:把软件设计结果翻译成程序。

测试:检测程序并改正错误的过程。

7.1 编码

7.1.1 选择程序设计语言

计算机程序设计语言基本上可以分为两大类:

  1. 汇编语言;
  2. 高级语言。

从应用特点看,高级语言可分为:

  • 1)基础语言:如BASIC、FORTRAN、COBOL等
  • 2)结构化语言:如ALGOL、PL/1、PASCAL、C、ADA等
  • 3)专用语言:如APL、BLISS、FORTH、LISP、PROLOG等
  • 4) 面向对象:如JAVA、C++等

选择一种编程语言的理论标准:

  • 1)有理想的模块化机制;
  • 2)可读性好的控制结构和数据结构;
  • 3)便于调试和提高软件可靠性;
  • 4)编译程序发现程序错误的能力强;
  • 5)有良好的独立编译机制。

选择语言时除了考虑理论上的标准,还必须同时考虑主要的实用标准:

  • (1)系统用户要求
  • (2)可以使用的编译程序
  • (3)可以得到的软件工具
  • (4)工程规模
  • (5)程序员知识
  • (6)软件可移植性要求
  • (7)软件的应用领域

7.1.2 写程序的风格

1. 程序内部的文档

选取含义鲜明的名字,如果使用缩写,缩写规则要一致,并给每个名字加注释;

通常在每个模块开始处要有一段注释,描述模块功能、算法、接口特点等;

程序清单布局应利用适当的阶梯形式,使程序的层次结构清晰明显。

2. 数据说明

数据说明的次序应该标准化,如按数据类型确定说明的次序;

多个变量名在一个语句中说明时,应该按字母顺序排列这些变量;

如果设计时使用了复杂的数据结构,应该用注释说明实现该数据结构的方法和特点。

3. 语句构造

不要为了节省空间而把多个语句写在同一行;

尽量避免复杂的条件测试;

尽量减少对“非”条件的测试;

1609308769488

避免大量使用循环嵌套和条件嵌套;

利用括号使逻辑表达式或算术表达式的运算次序清晰直观。

4. 输入输出

对所有输入数据都进行检验;(如:某省某市谋县)

检查输入项重要组合的合法性;

保持输入步骤和操作应尽可能简单;

明确提示交互式输入的请求,详细说明可用的选择或边界数值;

应允许缺省值;

设计良好的输出报表;

5.效率

A.程序运行时间

B.存储器效率

C.输入/输出效率

7.2 软件测试基础

7.2.1 软件测试的目标

测试是为了发现程序中的错误而执行程序的过程;

测试不能证明软件是正确的,也不能证明错误不存在;

测试人员设计出的一系列测试方案,是为了"破坏"已经建造好的软件系统一竭力证明程序中有错误!

7.2.2 软件测试准则

1)所有测试都应该能追溯到用户需求;

2)应该远在测试前就制定出测试计划;

3)把Pareto原理(20/80)应用到软件测试中;

4)应该从“小规模”测试开始,并逐步进行“大规模”测试;

5)穷举测试是不可能的;

穷尽测试:包含所有可能情况的测试称为穷尽测试。

1609308842694

6)为了达到最佳测试效果,应该由独立的第三方从事测试工作。

7.2.3 测试方法

黑盒测试:也称功能测试。如果已经知道软件应该具有的功能,可以通过测试来检验是否每个功能都能正常使用,这种测试称黑盒测试。

1609308861778

1609308866790

白盒测试:也称结构测试。如果知道软件内部工作过程,可以通过测试来检验软件内部动作是否按照规格说明书的规定正常进行,这种测试称为白盒测试。

1609308874282

1609308876269

7.2.4 软件测试的步骤

1.模块测试(单元测试)

模块测试又称单元测试,它把每个模块作为单独的实体来测试。

2.子系统测试(集成测试)

子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。

3.系统测试

系统测试是把经过测试的子系统装配成一个完整的系统来测试。

4.验收测试(确认测试)

验收测试把软件系统作为单一的实体进行测试(利用用户的实际数据测试)。

5.平行运行

平行运行是同时运行新开发出来的系统和将被它取代的旧系统,以便比较新旧两个系统的处理结果。

软件测试的V模型

1609308904788

7.2.5 测试阶段的信息流

1609308928316

7.3 单元测试

单元测试的一般方法是:

  • 首先通过编译系统检查并改正程序中所有的语法错误;
  • 然后用详细设计模块说明为指南,对重要的控制路径进行测试,以便发现模块内部的错误。
  • 通常,单元测试使用白盒测试方法。

单元测试:人工测试和机器测试

7.3.1 测试重点

1)模块接口

应该对穿过模块接口的数据流进行检测,以保证正确的输入和输出。

2)局部数据结构

这是错误的主要来源,应该设计相应的测试用例,以便发现数据结构方面的错误。

3)重要的执行路径

由于不可能进行穷尽测试,因此选择测试路径是非常关键的。

4)出错处理通路

5)边界条件

7.3.2 代码审查

审查小组:

  • 1)组长;
  • 2)程序的设计者;
  • 3)程序的编写者;
  • 4)程序的测试者。

7.3.3 计算机测试

由于软件模块不是一个独立的系统,不能独立运行,要依靠其他模块调用,或需要调用其他模块。因此,必须要为测试的单元开发驱动程序或存根程序。

  • 1)驱动程序:相当于一个“主程序”,用来把测试数据传送给被测试的模块,并打印有关结果。
  • 2)存根程序:用来代替被测试模块所调用的模块,相当于“虚拟子程序”。

如,测试B模块,设计了A模块和C模块。由A负责传送测试数据,由C负责模拟被B调用的模块。C模块可能没有,这取决于B有没有调用其他程序。A、C都是一次性程序,只在测试时临时使用,应尽量设计得简单一些,以节省费用和时间。

1609308985476

例:

1609309004184

对“编辑”功能的测试:

1609309015160

1609309019863

1609309024122

7.4 集成测试

集成测试是组装软件的系统化技术,它将经过单元测试的模块联系在一起进行测试。

由模块组装成程序时有两种方法:

  • 1)非渐增式测试方法:先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序。
  • 2)渐增式测试方法:每次增加一个待测试模块,把它同已经测试好的那些模块结合起来进行测试,反复进行直到完成所有模块测试的方法。

使用渐增式测试方法把模块结合到软件系统中去时,有自顶向下和自底向上两种集成方法。

7.4.1 自顶向下集成

自顶向下集成是一种递增的装配软件结构的方法,这种方法应用非常广泛。它需要存根程序,但是不需要驱动程序。

这种方法的思想是:从主控模块(主程序)开始,沿软件的控制层次向下移动,逐渐把各个模块结合起来。

在自顶向下结合方法中,如何将所有模块组装到软件结构中,又有两种方法:

1)深度优先策略

先组装软件结构的一条主控制通路上的所有模块,选择哪条主控制通路,具有较大的任意性。

如图,如果选取左通路,就先把模块M1、M2、M5结合起来测试,然后结合模块M8、M6,再构造中央和右侧的控制通路。

1609309079451

2)宽度优先策略

沿着软件结构水平地移动,把处于同一个层次的所有模块组装起来。

如图,首先结合M2、M3、M4和主控模块M1,然后结合下一个控制层次中的模块M5、M6和M7,最后结合模块M8。

自顶向下集成方法的基本过程如下:

  • 1)对主控模块进行测试,测试时用存根程序代替所有直接被主控模块调用的模块;
  • 2)根据选定的结合策略(深度优先或宽度优先),每次用一个实际模块代替一个存根程序(新结合的模块往往又需要新的存根程序);
  • 3)每结合一个模块,就测试一个;
  • 4)为保证不引入新的错误,需要进行回归测试,即重复以前进行过的部分或全部测试;
  • 5)重复回到第二步,直到构成整个软件结构。

7.4.2 自底向上集成

自底向上集成方法是从软件结构最底层模块开始进行组装和测试,它与自顶向下结合方法相反,需要驱动程序,不需要存根程序。

1609309580321

自底向上集成方法的基本过程如下:

  • 1)把底层模块组合成实现一个特定软件子功能的族,如图族1、2、3。
  • 2)为每个模块设计一个驱动程序,作为测试的控制程序,以协调测试用例的输入和输出。图中D1、D2、D3分别是族1、2、3的驱动程序;
  • 3)对模块进行测试;
  • 4)用实际模块代替驱动程序组装成新的模块族,在新加入的实际模块上面加上新的驱动程序进行测试;
  • 5)重复第二到第四步,逐渐向上加入实际模块,直至构造出整个软件结构。

7.4.3 不同集成测试策略的比较

  1. 改进的自顶向下测试方法;
  2. 混合法。

1609309629303

7.4.4 回归测试

指重新执行已经做过的部分测试。

回归测试用于保证由于调试或其他原因引起的程序变化,不会导致额外错误的测试活动。

7.5 确认测试(验收测试)

7.5.1 确认测试的范围

也称为验收测试,目标是验证软件的有效性。

如果软件的功能和性能符合用户的期待,软件就是有效的。

软件规格说明书是进行确认测试的基础。

确认测试的主要特点及内容有:

  • 1)某些已经测试过的纯粹技术性的测试项可能不需要再次测试,而对用户特别感兴趣的功能或性能,可能需要增加一些测试;
  • 2)通常确认测试主要使用实际生产中的数据来进行测试;
  • 3)确认测试必须有用户的积极参与,甚至以用户为主,可能需要进行一些与用户使用步骤有关的测试。

确认测试主要使用黑盒测试法。

7.5.2 软件配置复查

目的:保证软件配置的所有成分都齐全,质量符合要求,文档与程序完全一致,而且已经编好目录。

7.5.3 Alpha和Beta测试

Alpha测试:用户在开发者的场所进行测试,并且在开发者的指导下进行,测试在受控环境中进行,开发者记录发现的错误和问题;

Beta测试:用户在一个或多个客户场所进行测试,不受开发者控制,测试者记录发现的问题和错误,定期将问题报告发送给开发者。

7.6 白盒测试技术

7.6.1 逻辑覆盖

1. 语句覆盖

语句覆盖是指:设计的测试用例能使程序中每条语句至少执行一次。

例:一个被测试模块的源程序为(PASCAL语言):

 PROCEDURE  EXAMPLE (A , B : REAL ; VAR X : REAL) ;
 BEGIN
       IF (A>1) AND (B=0)
             THEN  X : = X / A;
       IF (A=2) OR (X>1)
             THEN  X : = X + 1
 END

1609310038458

选取测试用例:A = 2 , B = 0 , X = 4 ,程序执行路径为:sacbed。

2. 判定覆盖

判定覆盖是指:选取足够的测试用例,使得程序中每个判断的可能结果都至少执行一次,也就是说使程序的每个判断分支至少通过一次。

3. 条件覆盖

条件覆盖是指:选择足够的测试用例,使得程序中每个判定表达式的每个条件都取到各种可能的结果。

上例中,有两个判定表达式,每个表达式有两个条件,为了做到条件覆盖,应该选取测试数据使得a点出现如下结果:A>1,A≤1,B=0,B≠0

在b点出现如下结果:A=2,A≠2,X>1,X≤1

选取如下测试用例:

I.A=2,B=0,X=4 (满足A>1,B=0,A=2和X>1,执行路径为sacbed)

II.A=1,B=1,X=1 (满足A≤1,B≠0,A≠2和X≤1,执行路径为sabd)

条件覆盖通常比判定覆盖强,但条件覆盖不一定包含判定覆盖。

如:

I.A=2,B=0,X=1 (满足A>1,B=0,A=2和X≤1,执行路径为sacbed)

II.A=1,B=1,X=2 (满足A≤1,B≠0,A≠2和X>1,执行路径为sabed)

只满足条件覆盖,并不满足判定覆盖。

4. 判定/条件覆盖

判定/条件覆盖是指:选取足够的测试用例使得同时满足判定覆盖和条件覆盖的要求。

对于上例,选取如下测试用例:

I.A=2,B=0,X=4 (满足A>1,B=0,A=2和X>1,执行路径为sacbed)

II.A=1,B=1,X=1 (满足A≤1,B≠0,A≠2和X≤1,执行路径为sabd)

5. 条件组合覆盖

条件组合覆盖指:选取足够的测试用例,使得每个判定表达式中条件的各种可能的组合都至少出现一次。

对于上例,共有8种可能的条件组合:

1)A>1,B=0

2)A>1,B≠0

3)A≤1,B=0

4)A≤1,B≠0

5)A=2,X>1

6)A=2,X≤1

7)A≠2,X>1

8)A≠2,X≤1

选取如下测试用例:

I.A=2,B=0,X=4(满足1、5组合:A>1,B=0,A=2,X>1,执行路径sacbed)

II.A=2,B=1,X=1(满足2、6组合:A>1,B≠0,A=2,X≤1,执行路径sabed)

III.A=1,B=0,X=2(满足3、7组合:A≤1,B=0,A≠2,X>1,执行路径sabed)

IV.A=1,B=1,X=1(满足4、8组合:A≤1,B≠0,A≠2,X≤1,执行路径sabd)


如果从对程序路径的覆盖程度分析,可以提出下面一些逻辑覆盖标准:

6. 点覆盖

点覆盖是指:选取足够多的测试用例,使得程序执行路径至少经过程序图中每个节点一次。

1609310194342

7. 边覆盖

边覆盖是指:选取足够多的测试用例,使得程序执行路径至少经过程序图中每条边一次。

选取如下测试用例:

I. A=3,B=0,X=3(执行路径1—4—5—3)

II.A=2,B=1,X=1(执行路径1—2—6—7)

8. 路径覆盖

路径覆盖是指:选取足够多的测试用例,使得程序的每条可能路径都至少执行一次。

选取如下测试用例:

I. A=1,B=1,X=1(执行路径1—2—3)

II. A=1,B=1,X=2(执行路径1—2—6—7)

III.A=3,B=0,X=1(执行路径1—4—5—3)

IV.A=2,B=0,X=4(执行路径1—4—5—6—7)

更强的测试数据:满足路径覆盖和条件组合覆盖

1)A=3,B=0,X=1 路径:sacbd

2)A=2,B=0,X=4

3)A=2,B=1,X=1

4)A=1,B=0,X=2

5)A=1,B=1,X=1

2)-5)执行条件组合覆盖,执行路径分别是:sacbed、sabed、sabed、sabd

7.6.2 控制结构测试

(自学)

7.7 黑盒测试技术

黑盒测试与白盒测试比较。

黑盒测试能发现的问题?

如何设计黑盒测试?

如何设计标准的黑盒测试用列?

7.7.1 等价划分(等价类划分)

等价类划分是一种黑盒测试技术。

穷尽的黑盒测试需要使用所有可能的输入数据(有效的和无效的)进行测试,通常是不现实的。因此产生了等价类划分。

等价类划分的思想:如果将所有可能的输入数据(有效的和无效的)划分为若干个等价类,就可以假定用每一个等价类中的代表值作为测试用例来进行测试时,等价于用该类中所有值进行了测试。

用等价类划分设计测试用例时,主要分两步:划分等价类、确定测试用例。

1)等价类划分

划分等价类需要经验,以下给出一些规则:

A.如果某输入条件规定了输入的范围,那么可以划分为一个有效的等价类和两个无效的等价类。

如X的值的输入范围是[1,99],那么测试X时,可以这样划分:有效等价类为[1,99],无效等价类为(-∞,1)和(99,+∞)。

B.如果某个输入条件规定了一组可能的值,且程序可以对不同的值作出不同的处理,那么可以为每种值确定一个有效的等价类,同时还有一个无效等价类。

如,“职称”这个量可能的值是:教授、副教授、讲师、助教。那么可以这样划分:四类有效等价类分别为教授、副教授、讲师、助教,无效等价类为四种职称以外的所有值。

2)确定测试用例

A.给每个等价类规定一个唯一的编号;

B.设计一个新的测试用例,使其尽可能多地覆盖未被覆盖过的有效等价类。重复此步,直至所有有效等价类被覆盖;

C.设计一个新的测试用例,使其覆盖而且只覆盖一个尚未被覆盖的无效等价类。重复此步,直到所有无效等价类被覆盖。

通常程序发现一类错误后,就报出错信息,不再检查其它类错误,所以设计测试用例时,一次只覆盖一个无效等价类。


实例:一个把数字串变成整数的函数。

计算机字长:16 bits ,函数由PASCAL语言编写。

function  strtoint ( dstr: shortstr ): integer
type shortstr = array[1..6] of char; /字符串6位/

(16位字长能表示的整型数范围是[-215, 215-1],即[-32768, 32767] )

有效输入的等价类有:

(1)1-6个数字字符组成的数字串(最高位数字不为零);如:[ 0 , 999999 ]

(2)最高位数字是零的数字串;如:“012345”

(3)最高位数字左邻是负号的数字串;如:“-12345”

无效输入的等价类有:

(4)空字符串(全是空格);如“ ”;

(5)左部填充的字符既不是零,又不是空格;如:“A12345”

(6)最高位数字右面由数字和空格混合而成;如:“123 45”

(7)最高位数字右面由数字和其他字符混合而成;如:“12A345”

(8)负号与最高位数字之间有空格;如:“- 1234”

合法输出的等价类有:

(9)在计算机能表示的最小负整数和零之间的负整数;如:[ -32768 , 0 )

(10)零;

(11)在零和计算机能表示的最大正整数之间的正整数; 如:(0 ,32767 ]

非法输出的等价类有:

(12)比计算机能表示的最小负整数还小的负整数;如:“-32769”

(13)比计算机能表示的最大正整数还大的正整数;如:“123456”

根据划分的等价类,设计出测试方案11个:

(1)1-6个数字组成的字符串;

输入:‘ 1’

预期的输出:1

(2)最高位数字是零的数字串;

输入:‘000001’

预期的输出:1

(3)负号与最高位数字相邻;

输入:‘-00001’

预期的输出:-1

(4)最高位数字是零的特例;

输入:‘000000’

预期的输出:0

(5)太小的负整数;

输入:‘-47561’

预期的输出:错误-无效输入

(6)太大的正整数;

输入:‘132767’

预期的输出:错误-无效输入

(7)空字符串;

输入:‘ ’

预期的输出:错误-没有数字

(8)字符串左部字符既不是零又不是空格;

输入:‘AAAAA1’

预期的输出:错误-非数字

(9)最高位数字后面有空格;

输入:‘1 2’

预期的输出:错误-无效输入

(10)最高位数字后面有其他字符;

输入:‘1AAA23’

预期的输出:错误-无效输入

(11)负号和最高位数字之间有空格;

输入:‘- 12’

预期的输出:错误-负号位置错。

7.7.2 边界值分析

程序通常在处理边缘情况时容易出现错误,如等价类与等价类之间的边界值。

所以在设计测试用例时,使用正好等于、正好大于、正好小于边界值的数据进行测试,发现程序错误的概率较大。

边界值分析测试法属黑盒测试。

在实际设计测试方案时,常常结合使用等价划分和边界值分析两种技术,把一些等价类的边界值作为测试用例进行测试。


上例中设计了11个测试用例,还应该用边界值分析补充测试用例:

(12)使输出刚好等于最小负整数;

输入:‘-32768’

预期的输出:-32768

(13)使输出刚好等于最大的正整数;

输入:‘ 32767’

预期的输出:32767

(14)使输出刚刚小于最小的负整数;

输入:‘-32769’

预期的输出:错误-无效输入

(15)使输出刚刚大于最大正整数;

输入:‘ 32768’

预期的输出:错误-无效输入

7.7.3 错误推测

错误推测法在很大程度上靠直觉和经验进行。

基本思想:列举出程序中可能的错误和容易发生错误的特殊情况,且根据它们选择测试方案。

如:输入、输出为0时容易出错;输出记录为0条时容易出错;等等。

7.7.4 实用测试策略

对软件系统进行实际测试时,应该联合使用各种设计测试方案的方法,形成一种综合策略。具体可以使用如下策略:

1)在任何情况下都应该进行边界值分析;

2)必要时用等价划分法补充测试方案;

3)必要时再用错误推测法补充测试方案;

4)对照程序逻辑,检查已经设计出的测试方案。可以根据对程序可靠性的要求采用不同的逻辑覆盖标准。


实例:程序TRIANGLE读入三个整数值,这三个整数代表同一个三角形三条边的长度,程序根据这三个值判断三角形属于不等边、等腰或是等边三角形。

1609310551629

综合使用边界值分析、等价值划分和错误推测等技术,可以设计出11种应该测试的情况:

(1)正常的不等边三角形;

(2)正常的等边三角形;

(3)正常的等腰三角形,包括两条相等边的三种不同排列方法;

(4)退化的三角形(即两边的和等于第三边),包括三种不同排列方法;

(5)三条边不能构成三角形(即两边之和小于第三边),包括三种不同排列方法;

(6)一条边的长度为零,包括三种不同的排列方法;

(7)两条边的长度为零,包括三种不同的排列方法;

(8)三条边的长度全为零;

(9)输入数据中包含负整数;

(10)输入数据不全(不足三个正整数);

(11)输入数据中包含非整数型的数据。

程序TRIANGLE的测试数据:

1609310685493

1609310703409

最后,检查测试数据的覆盖程度,通常应该做到边覆盖。

1609318491339

测试数据覆盖程度检验表中列出的四种测试数据已经做到了边覆盖(覆盖所有的22条边)。

测试数据覆盖程度检验表:

1609318615536

7.8 调试

调试是在测试发现错误之后排除错误的过程。

7.8.1 调试过程

1609318782103

7.8.2 调试途径

  1. 蛮干法:打印内存的内容,从中寻找错误的线索,是效率最低的程序调试方法。
  2. 回溯法:从发现问题的程序段开始人工地往回追踪分析程序代码,直到找到错误。
  3. 原因排除法: 包括:对分查找法、归纳法、演绎法

7.9 软件可靠性

7.9.1 基本概念

1. 软件可靠性定义

软件可靠性:是程序在给定的时间间隔内,按照规格说明书的规定成功地运行的概率。

2. 软件的可用性

对故障可修复系统,应同时使用可靠性和可用性来衡量。

软件可用性是:程序在给定的时间点,按照规格说明书的规定,成功地运行的概率。

可靠性和可用性的区别是:可靠性是在0到t时间间隔内,系统没有失效的概率。而可用性是在t时刻,系统是正常运行的概率。

如果在t时刻,系统是可用的,则有两种可能:

1)在0到t时刻这段时间内,系统一直没有失效(可靠);

2)在0到t时刻这段时间内失效过,但是系统修复后运行到t时刻时情况良好。

系统稳态可用性计算(了解)

平均维修时间MTTR是修复一个故障平均需要用的时间,取决于维护人员的技术水平和对系统熟悉程度。

平均无故障时间MTTF是系统按照规格说明书规定成功地运行的平均时间,取决于系统中潜伏的错误数量。

7.9.2 估算平均无故障时间MTTF的方法

1. 符号

估算MTTF时使用到下列符号:

  • ET——测试之前程序中故障总数;
  • IT——程序长度(机器指令总数);
  • τ——测试(包括调试)时间;
  • Ed(τ) ——在0至τ期间发现的错误数;
  • Ec(τ) ——在0至τ期间改正的错误数;

2. 基本假定

可作出下列假定:

  • 1)单位长度里的故障数ET/ IT近似为常数。一些统计数字表明,通常有:0.5×10-2≤ET/ IT≤2×10-2。
  • 2)失效率正比于软件中剩余的(潜藏的)故障数,而平均无故障时间MTTF与剩余的故障数成反比。
  • 3)调试过程没有引入新的故障,即Ec(τ)= Ed(τ)。

由于系统剩余的故障数为:Er(τ) = ET- Ec(τ)

所以单位长度程序中剩余的故障数为:εr (τ) = ET / IT - Ec(τ)/ IT

3. 估算平均无故障时间MTTF

因为平均无故障时间与单位长度程序中剩余的故障数εr (τ)成反比,所以:

1609318879649

其中:K为常数,它的值根据经验选取,经典值是200。

由上式变换后得到程序中改正的错误数:

1609318905222

根据对软件平均无故障时间的要求,可以估计需要改正多少个错误后,测试工作就可以结束。

4. 估计故障总数ET的方法

1)植入故障法

假设人为地植入的故障数为Ns,经过一段时间的测试之后发现ns个植入的故障,同时还发现了n个原有的故障,则可以估计出程序中原有的故障总数(P181)

2)分别测试法

分别测试法随机把程序中一部分原有错误加上标记,根据测试发现的有标记和无标记错误的比例,估计程序错误总数。

分别测试法使用两个测试员,独立地测试同一个程序的两个副本,由另一名分析员分析他们的测试结果,把其中一个测试员发现的故障作为有标记的故障。用τ表示测试时间,假设

  • τ= 0时故障总数为B0(即ET);
  • τ=τ1时测试员甲发现的故障数为B1;
  • τ=τ1时测试员乙发现的故障数为B2;
  • τ=τ1时两个测试员发现的相同故障数为bc。

如果认为测试员甲发现的故障是有标记的,即程序中有标记的故障总数为B1,那么测试员乙发现的B2个故障中有bc个是有标记的。所以可以估计出测试前程序中的故障总数为:

1609318931619

其中,这就是故障总数ET的估计值。

每隔一定时间,分析员分析两名测试员的测试结果,来估计错误总数。几次估计结果差不多时,用其平均值作为错误总数的估计值。

小结

◇ 测试计划

为做好集成测试和验收测试,需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。

◇ 测试分析报告

测试工作完成以后,应提交测试计划执行情况的说明,对测试结果加以分析,并提出测试的结论意见。


测试阶段可能用到的软件工具:

  • Bugfree:Bug处理记录工具。
  • Wiki:知识共享工具。
  • LoadRunner:负荷(载)测试软件,预测系统行为和性能的负载测试工具,通过模拟多至上千万用户实施并发负载及实时性能监测的方式来查找和确认问题。

重点

测试过程所涉及的类型

渐增式测试的优先策略

黑盒测试、白盒测试

等价类划分、边界值分析

软件可靠性和可用性的联系区别