软件测试黑箱法与白箱法的综合应用

1、第四章 软件测试黑箱法与白箱法的综合应用本章给出综合应用软件测试黑箱和白箱的实例。首先给出综合黑箱测试和白箱测试提出的灰箱测试法；之后给出利用灰箱技术提出的组件事务特征一致性测试的应用。4.1 软件测试灰箱法白箱法和黑箱法有其自身的特点，但也都存在着明显的不足，它们的不足之处主要表现在只考虑了程序某一方面的属性和特征，没有综合考虑。这样要进行较全面的程序测试，不得不把测试工作分成两次进行。用白箱法测试一次；再用黑箱法测试一次。这样作不但浪费时间，而且测试的效果不一定好。灰箱法正是基于这一点提出的。4.1.1 灰箱法灰箱法是在综合考虑白箱法和黑箱法基础上提出的一种程序测试方法。它以程序的主要性能

2、和主要功能为测试依据，根据程序的程序图、功能说明书以及测试者的实践经验来设计测试用例，在测试程序的主要功能的同时也测试程序的主要性能。这里所说的主要性能和主要功能是指功能说明书和规格设计说明书中所规定的主要功能和主要性能指标。这些主要功能和主要性能可凭借测试者的经验来选取。可把容易发生错误的变量域、流程图中的关节路径和结点(程序图)作为测试的内容；而把那些不容易发生错误的变量输入和流程图中的不影响或不改变内部逻辑的细节忽略。这一点也是传统测试方法的思想。如黑箱测试中的等价类法和边界值分析法就是选取一类输入变量中有代表性的数据作为测试用例；而白箱测试中的各种覆盖方法也只是把判断条件作为测试的主要

3、依据。在灰箱法中不强调对程序中各语句处理内容的完全了解。事实上，许多测试工作是在不完成了解或不需完全了解程序的内部逻辑时进行，这也就是“灰色”的由来。(1) 路径/等价法结点/等价覆盖：程序的测试路径至少经过程序图中每个结点一次；并且输入变量至少取不同等价类值一次。边/等价覆盖：程序的测试路径至少经过程序图中的每条边一次；并且输入变量至少取不同等价类值一次。路径/等价覆盖：程序图中每条路径都至少经过一次；并且输入变量至少取不同等价类值一次。(2) 路径/边界值法结点/边界覆盖：程序的测试路径至少经过程序图中每个结点一次；并且输入变量至少取不同等价类边界值一次。边/边界覆盖：程序的测试路径至少经

4、过程序图中的每条边一次；并且输入变量至少取不同等价类边界值一次。路径/边界覆盖：程序图中每条路径都至少经过一次；并且输入变量至少取不同等价类边界值一次。4.1.2 灰箱法举例下面以图2-1为例，给出路径/等价法和路径/边界值法的各种测试用例。在图2-1所示的程序中A、B是两个整型输入变量。其中A的等价类为A<1,1£A£2,A>2；B的等价类为B<0,B=0,B>0。X为内部变量。结点/等价覆盖的最小测试用例为：A=2，B=0，X=3(沿ace执行)；A=3，B=1，X=6(沿abe执行)；(A>1)(B=0)(A=2)(X>1)X=X/

5、AX=X+1aFbFdT eT c5-1 一个被测程序结构图A=-1，B=-1，X=1(沿abd执行)。边/等价覆盖的最小测试用例为：A=3，B=0，X=1(沿acd执行)；A=2，B=1，X=3(沿abe执行)；A=-1，B=-1，X=1(沿abd执行)。路径/等价覆盖的最小测试用例为：A=2，B=0，X=4(沿ace执行)；A=-1，B=1，X=1(沿abd执行)；A=3，B=-1，X=1(沿abe执行)。结点/边界覆盖的最小测试用例为：A=2，B=0，X=3(沿ace执行)；A=3，B=1，X=6(沿abe执行)；A=0，B=-1，X=1(沿abe执行)；A=1，B=1，X=1(沿abd

6、执行)。边/边界覆盖的最小测试用例为：A=3，B=0，X=1(沿acd执行)；A=2，B=1，X=3(沿abe执行)；A=0，B=-1，X=1(沿abe执行)；A=1，B=1，X=1(沿abd执行)。路径/边界覆盖的最小测试用例为：A=2，B=0，X=4(沿ace执行)；A=0，B=1，X=1(沿abd执行)；A=3，B=-1，X=1(沿abe执行)；A=1，B=1，X=1(沿abd执行)。以上是针对单元程序的测试，在综合测试和高级测试中可把灰箱法作为基本方法来使用。灰箱法的最大特点是把程序的功能测试和性能测试统筹考虑，功能测试和性能测试一次完成。实践证明该方法可以减少软件测试的环节，提高软件

7、测试的效率和效能。4.2 组件事务特征一致性测试组件事务服务器（Component Transaction Server简称CTS）是三层Client/Server结构中的核心部件。较著名的CTS有：Microsoft的MTS（Microsoft Transaction Server1：微软事务服务器）、Sybase公司的Jaguar-CTS(Component Transaction Server)、Sun公司的EJB（Enterprise Java Bean：企业Jave Bean）2和OMG（Object Management Group：对象管理集团）的ORBs (Object Req

8、uest Brokers)3。在CTS中，事务管理器（Transaction Manager）用“自动事务”来协调跨越多个组件的数据更新。自动事务类型有1（1）不支持事务（Not Supported），相应的组件将不参与到任何事务中。（2）支持事务（Supports Transaction）。如果调用程序参与到一个事务中，被调用组件将参与到同一个事务中。如果调用程序未参与到一个事务中，则被调用组件将不参与到任何事务中（3）需求事务（Requires Transaction）。如果调用程序参与到一个事务中，则组件将参与到同一个事务中。如果调用程序未参与到一个事务中，则将创建一个新事务，并且该组件

9、将参与到这个新事务中。（4）需求新事务（Requires New Transaction）。总是为组件建立一个新事务。虽然自动事务为组件对象的事务管理提供了必要的手段，但设计者很难确保组件事务特征的一致性，下面是产生组件事务特征不一致性的例子。案例1：学生注册组件 Enroll 激发登记组件Register预定位置和缴费组件Bill填写缴费记录。如果Register和Bill不在同一事务中，就会造成数据更新的不一致性。 所以应该把Register 和Bill的事务特征定义为支持事务或需求事务，而把Enroll组件的事务特征定义为需求事务或需求新事务。在这种情况下，如果把Register和Bil

10、l其中的一个组件事务特征设定为需求新事务，就会因组件事务特征不一致而产生数据不一致。问题的原因之一是设计者粗心或对业务的错误理解；另一原因是在定义组件事务特征时，很难从全局角度考虑。所以在系统设计阶段需要测试组件事务特征的一致性。4.2.1 组件事务管理概念为了方便讨论，我们把组件事务服务器（Components Transaction Service简称CTS）应用系统结构简化为由应用程序（AP）、组件事务管理器（TM）和资源管理器（RM）组成，如图2.1所示。 Application Program(AP)Resource Managers（Ms)Transaction Manager (

11、TM)tx_commit_call()xa_prepare_call(x)xa_prepare_ret(x,xa-ok)xa_commit_call(x)xa_prepare_call(y)xa_prepare_ret(y,xa-ok)xa_commit_call(y) AR TX XA 图5.2.1 CTS结构 图5.2.2一个部分poset模型其中：方框表示组件的接口，线表示接口间的通讯，TX表示应用程序与事务管理器的通讯和协议；XA是事务管理器与资源管理器之间的连接，这一连接确保事务执行为原子活动；AR是应用程序与资源管理器之间的连接。CTS的执行过程满足两段提交（2PC）协议。第一阶段

12、为预提交阶段，由协调者进程向各场地发出了子事务，当各参与场地子事务完成后，向协调进程发出预提交命令，同时在日志文件中记入该子事务提交所需的全部信息及子事务预提交的事实。协调进程从各子事务收到预提交命令，如果所有的子事务均回答了预提交，则全局事务可以提交；如果至少有一个子事务回答了Abort，或超时未回答，则全局事务做出夭折的决定。第二阶段为执行阶段，协调者在日志中记入其决定后，由协调者向各子事务发出其决定（提交或夭折），所有的参与者根据协调者的命令，先记入日志文件，然后执行提交或中止的命令。从此时起，恢复机制可以保证子事务的实施。最后向协调者发出最终回答，协调者根据回答写入“完成”记录到日志文

13、件中。这样，全局事务即是可恢复的，从而保证了分布式事务的原子性。图5.2.1表示CTS应用系统的部分执行情况。其中点表示事件，用活动名表示，边表示事件的依赖关系，xa_prepare_call()、xa_prepare_ret()和tx_commit_call()、xa_commit_call()分别表示事务提交请求、应答以及TX事务和AX事务提交事件。其中，“依赖®”关系（A®B，B在A之前发生）；“并行|”关系（并行的两个组件互不依赖），以及存在量词“?”（与$等价）和全称量词“!”（与等价"）。为此，CTS测试步骤是为：l 首先建立应用系统的结构描述，确定应

14、用系统的执行模型。l 建立应用系统执行模型中被测事件到参考（2PC）结构的映射，得到与应用系统相对应的结果事件集。l 分析结果事件集，检查与参考结构约束的一致性。4.2.2 组件事务特征一致性测试本节对组件事务特征一致性的测试方法进行讨论，讨论中采用的符号与第一节中的符号含义相同。局部与全局组件事务特征一致性定义5.1：若组件Ci在事务中运行，Xa表示CTS中事务服务器与数据库的连接，下同，Xa(?i).commit_call(?x)表示组件Ci所在组件事务提交事件，如果Xa(！j(i<>j).prepare_ret(?y,ok)有：（Xa(！j(i<>j

15、).prepare_ret(?y,ok)|Xa(？i).commit_call(?x)），则称组件Ci是事务独立组件。定义5.2：设Ci和Cj是两个组件，Ci调用组件Cj的方法，A是激发活动。若Cj是事务独立组件，如果对Xa(!j<>i).prepare_ret(?y,ok)，A不会使得Xa(？i).commit_call(?x,ok) ® Xa(！j<>i).prepare_ret(?y,ok)成立，则称组件Ci和Cj为局部组件事务特征一致，记作：Cons(Ci,Cj)。这里的“A使得”或“A不会使得”是一种系统行为。对定义5.1、5.2的一个解释可见例1，

16、如果把注册组件的事务类型设定为需求事务，而缴费组件设定为“需求新事务”则这两个组件事务特征不一致。从业务逻辑上看，把缴费组件设定为“需求新事务”是不正确的，但这种情况在组件属性设计上是允许的，所以直接用定义5.2来检测设计中组件事务特征一致性有一定困难。除此之外，组件一般有4种可选择的组件事务特征，两个组件有16种组合，以及组件是否在事务中运行等情况需要考虑，这使得组件事务特征一致性测试变得很复杂。下面给出通过组件连接器讨论局部组件事务特征一致性测试方法。定义5.3：设A是组件Ci调用组件Cj的一个“激发”活动，若Ci和Cj在事务中运行，如果A使得Xa(!j).prepare_ret(?x,o

17、k) ® Tx(!i).commit_call(?x)，则称A为一个吸入激发，也称吸入事务连接；如果A使得Xa(!j).prepare_ret(?x,ok)|Tx(!i).commit_call(?x)，则称A为一个排它激发，也称排它事务连接。定义5.4：设A是一个组件“激发”活动，C是被激发组件。若A是一个吸入事务连接，而C是非独立事务组件；或者A是一个排它事务连接，而C是独立事务组件，则称连接A与组件C兼容，记作：Comp(A,C)。定理5.1：A是组件Ci调用组件Cj的一个“激发”活动；若Comp(A,Cj)，则Cons(Ci,Cj)。证明：设Cj是独立事务组件，因为Comp(

18、A,Cj)，所以A是一个排它事务连接，即不会有Xa(？i).commit_call(?x) ®Xa(！j).prepare_ret(?x,ok)成立，所以Cons(Ci,Cj)。上面的讨论解决了局部组件事务特征一致性测试问题。下面提出全局组件事务特征一致性测试方法，并讨论局部与全局一致性的关系。定义5.5：在事件执行模型中，如果对同一组件事务满足：never (?x in xid)(?i,?j in 1.NumRMs)Xas(?i).prepare_ret(?x,xa_ok)|Xas(?j).commit_call(?x)，则称该事件执行模型中的相关组件事务满足全局事务一致性，记为：

19、Cons（sys）。其中：xid表示事务标示，i和j分别表示不同的进程。显然，在事件执行模型中，如果同一组件事务满足全局事务一致性，则该执行模型满足数据库事务两段提交协议。定理5.2：设组件C激发组件Ci和Cj的方法，Ai和Aj是激发活动，如果C是非独立事务组件并在事务中运行，Ci或Cj是事务独立组件，则有(?x in xid)(?i,?j in 1.NumRMs)Xas(?i).prepare_ret(?x,xa_ok)| Xas(?j).commit_call(?x)成立。证明：设Ci为事务独立组件，则有(?i,?j in 1.NumRMs)Xas(?i).prepare_ret(?x,x

20、a_ok)| Xas(?j).commit_call(?y)成立；又C是非独立组件，并在事务中运行，则事件Xas（?i）和Xas(?j)应具有相同的事务标示xid，用xid分别置换事件Xas（?i）和Xas(?j)中的事务标示，则有：(?i,?j in 1.NumRMs)Xas(?i).prepare_ret(?xid,xa_ok)| Xas(?j).commit_call(?xid)成立。 证毕。定理5.2表明如果组件Ci和Cj 的连接破坏局部组件事务特征一致性，则包括该局部连接的事件执行模型不满足全局事务一致性。推论5.1：设组件C激发组件Ci和Cj的方法，如果有Cons(C,Ci)不成立

21、或Cons(C,Cj)不成立，则Cons(C)不成立。推论5.1说明定理5.2只是全局组件事务特征一致性的一个充分条件。本章第节的实验2将说明这一点。定理5.2的证明提供了测试全局组件事务特征一致性的一种方法，即对同一组件事务进行置换，使其事务标示相同，为此应建立事件的映射如下：/*归并事务提交请求事件映射，该映射把在同一事务中，但标示不同的事务提交请求归并为同一标示的事务。*/(?x in xid)(?rc in return_code)/* x为事务标示，return_code是返回码。*/Xa.preare_ret(?x,?rc)=>Xa.prepare_ret(A?x,?rc)/

22、*A?x是表示事务标示的数组*/*归并事务提交事件映射，该映射把在同一事务中，但标示不同的事务提交事件归并为同一标示的事务。*/(?x in xid)(?rc in return_code)Xmit_call(?x,?rc)=>Xmit_call(A?x,?rc)。 组件事务特征一致性测试算法事件执行模型是一种偏序模型，这样在选取事件时要考虑事件之间的逻辑关系。文献6提出一种保守（Conservative）算法，即仅当不会产生事件因果错误的情况下，才提取事件；文献7提出一种乐观（Optimistic）算法，即认为预取事件不会产生事件因果错误，而当出现错误时再回撤。实际上事件

23、仿真算法是与仿真对象有关的，任何一种方法都有其特殊性。本文在保守算法的基础上，提出一种基于偏序事件模型的一致性仿真测试算法。Procedure5.1 Transaction_Test_Simulation()order()/*求事件模型的偏序集*/Dim Current_event ,Next_Current,Prefix_Event,Postfix_Event as stringDim Ax,Bx as integer/*用于存放不同事务中提交询问应答事件和提交事件*/Dim Tran_id as integer/*事务标示*/Set Current_event:=First_event()

24、/*取事件集的第一个事件*/Set Tran_id:=Tran_id(Current_event)/*Tran_id()求一事件的事务id*/Set Time(sys):=Timestamp(Current_event)/*设系统时钟为当前事件的时间戳*/while Timestamp(Current_event) <tSys_Time Select case Type(Current_event)Case Type(Current_event)=a/*当前事件是请求事件*/Tran_type:=Type_tran(Current_event)/*求当前事件类型*/if Tran(Cur

25、rent_event) then/*如Current_event在事务中运行，Tran()为真*/Inv_style:=acce/*设置连接类型，acce表示吸入，exce表示排它*/elseInv_style:=exceend ifif Tran_type=exce then/*如果为独立事务组件，建立该事务的归并*/Tran_id:=Tran_id(Current_event)/*取独立事务标记*/ATran_id:=Tran_idend if case Type(Current_Event)=b/*激发事件*/ Next_Event:=Next_event(Current_event)

26、if Inv_style=acce and Tran_Type(Next_Event)=exce thenPrint(“发现局部事务不一致，Next_Event)/*exce表示独立事务组件*/ End if case Type(Current_Event)=f/*提交询问应答事件*/ Temp_event:=Event(Tran_id)/*求事务id对应Xa(!j).prepare_ret(?x,ok)*/ if timestamp(Temp_event)<ttimestamp(Current_Event) and Temp_Event<c Current_Event then/

27、*判断Xa(!j).prepare_ret(?x,ok)与Xa(!i).commit_call(?x)是否有依赖关系;<t表示时间小于；A<cB表示B因A发生，下同。*/ ATran_id(Current_Event):= Tran_id Tran_id(Current_Event):=Tran_id endcase Type(Current_Event)=g /*事务提交请求事件*/ Temp_event:=Event(Tran_id) if timestamp(Temp_event)<ttimestamp(Current_Event) and Temp_Event <

28、;c Current_Event then/*判断Xa(!j).prepare_ret(?x,ok)与Xa(!i).commit_call(?x)是否有依赖关系*/ BTran_id(Current_Event):= Tran_id Tran_id(Current_Event):=Tran_id endEnd select Current_event:=Next_event(Current_event)/*取下一个事件*/ Sys_Time:= Sys_Time+step/*增加一个步长，该步长不会产生因果错误*/Wendfor i=1 to n /*测试全局一致性*/ Prefix_even

29、t:=Event(Ai)for j=1 to n Postfix_event:= Event(Bj)if timestamp(Prefix_event)<ttimestamp(Postfix_event) and Prefix_event<cPostfix_event then if Tran_id(Prefix_event)<>Tran_id(Postfix_event) then Print(“发现一个全局事务不一致，Prefix_event ,Postfix_event) end ifend ifnext inext jend procedure。在上述算法中，事

30、件列表中的最后一个事件为finish，它的时间戳为0，所以finish是一个仿真终止条件。算法5.1的执行时间仍为O（n2），n为事件模型的事件数，这与Rapide算法的执行时间相同，但在只有局部不一致发生时，算法3.1执行时间为 O（n），而且可以定位局部事务冲突。从这一点上，算法5.1比Rapide有很大改进。算法5.1中约定，如果C在事务中运行，则C执行吸入事务连接激发其它组件。这一约定虽然放宽了检测条件，但可以发现所有的不一致事务。算法中事件的形式化描述为：Event(name,id,type,tran_id,tran_type,tran_state,timestamp,postfix_arry state,return)，它们分别表示事件名、标示、类型、事务标示、事务类型、事务状态、事件时间戳、直接后缀、事件所在系统状态和事件执行的返回值。其中类型是事件的种类；事务标示是一个整数类型，它有别于事件的标示；事务类型表示不同的事务类型，对MTS、CTS等事务服务器可设定4种类型，本文从通用性角度仅规定了两种类型的事务，即独立型事务exce和非独立型事务acce，对激发事件表示激发的类型，有排它激发和吸入激发两种，也用exce和acce表示；事务状态表示事件的事务活动的属性，有两种类型，它是一个布尔变量in_tran或out_tran，分别表示在事务中和不在事