测试多线程软件并发冲突的方法

技术领域

本发明涉及软件测试领域，尤其涉及一种测试多线程软件并发冲突的方 法。

背景技术

目前大量的应用软件采用多线程技术，这样的应用程序可以更好地利用 系统资源。多线程技术的主要优势在于充分利用了CPU(Central Process Unit， 中央处理器)的空闲时间片，可以用尽可能少的时间来对用户的要求做出响 应，使得软件的整体运行效率得到较大提高，同时增强了应用软件的灵活性。

但是，多线程技术在增强软件功能的同时也带来了设计和测试上的复杂 性。由于多线程软件中API(Application Program Interface，应用程序接口) 函数的实现体会对共享数据进行互斥保护，当彼此的互斥保护逻辑出现错误 时就会产生并发冲突。因此，应用多线程技术的软件通常总是当程序同时调 用API接口时，发生并发冲突。在测试中，因为多线程并发冲突造成的错误， 从表象上看，基本上都是无规律的重现，而且难以定位。

现有技术中，对应用软件进行测试的常用方法是长时间的压力测试，以 促使多线程并发冲突出现。而针对API接口进行的测试，主要是通过启动多 个测试线程频繁调用可能出现并发冲突的API接口，来发现并发冲突问题。

现有的测试方法无法主动制造最有可能出现多线程并发冲突的环境，可 能出现并发冲突的API接口在各个线程中的调用时机是不可预测的，只能在 操作系统对多线程进行调度时恰巧出现同时调用API接口时才有可能对并发 冲突问题进行测试，而何时出现这种机会是测试人员和测试工具无法控制的。 这样的测试方法相当的盲目，测试效率很低，测试质量无法保证。

发明内容

本发明要解决的技术问题是现有技术无法控制对API接口地同时调用。

本发明所述测试多线程软件并发冲突的方法包括以下步骤：

a)在测试逻辑中调用待测试的应用程序接口前插入同步申请点；

b)开始运行至少两个测试线程，所述测试线程中执行所述测试逻辑；

c)所述测试线程运行到同步申请点时，发出同步申请；

d)判断是否接受所述测试线程的同步申请，如果否，继续执行所述发出 同步申请的测试线程；如果是，执行步骤e)；

e)判断是否当前运行的除所述发出同步申请的测试线程外的其他测试线 程都处于等待状态，如果否，将所述发出同步申请的测试线程置于等待状态； 如果是，则所有的所述测试线程继续执行；

f)进行所述测试线程的并发冲突测试。

优选地，所述步骤e)与步骤f)之间包括：所述发出同步申请的线程提 示操作系统进行线程切换。

优选地，所述步骤a)与步骤b)之间包括：设置运行线程记录，在运行 线程记录中存储当前正在运行的测试线程的线程标识；

所述步骤b)与步骤c)之间包括：

bc1)在运行线程记录中增加所述测试线程。

优选地，所述步骤bc1)之后包括：

bc2)所述测试线程准备测试环境；

bc3)所述测试线程开始执行其测试逻辑；

所述步骤f)之后还包括：

g)当所述测试线程执行完其测试逻辑后，恢复测试环境。

优选地，所述步骤g)之后还包括：

h)判断是否接到该测试线程的退出指令，如果是，执行步骤i)；如果 否，转步骤bc2)；

i)从运行线程记录中删除该测试线程；判断是否当前运行中的其他所述 测试线程都处于等待状态，如果是，令其他所述测试线程继续执行，该测试 线程退出；如果否，则该测试线程退出。

优选地，在所述测试线程第一次执行所述测试逻辑时统计所述测试逻辑 中同步申请点的数量。

优选地，所述步骤a)与步骤b)之间还包括：建立所调用的应用程序接 口与所述同步申请之间的对应关系。

优选地，所述测试线程执行相同的测试逻辑，所述测试逻辑中调用所有 待测试的应用程序接口。

优选地，步骤d)所述判断是否接受同步申请的条件为：相同同步申请 的数量不超过(m-1)除以n所得的整数部分时，接受所述同步申请；其中 m为正在运行的所述测试线程的总数，n为当前统计所得的所有所述测试逻 辑中同步申请点数量的最大值。

优选地，不同的所述测试逻辑中调用不同的待测试应用程序接口；步骤 d)所述判断是否接受同步申请的条件为：接受所有的同步申请。

本发明通过在测试逻辑中调用API接口前进行同步申请，使各个线程中 的API接口被同时调用，从而对有针对性地对多线程并发冲突进行测试，有 效缩短了并发测试的周期，对提高并发测试效率和测试质量有显著的效果。

附图说明

图1所示为应用本发明所述方法的两个测试线程的测试逻辑示意图；

图2所示为本发明所述测试方法的流程图；

图3所示为本发明中测试线程的运行流程图；

图4所示为本发明第一个实施例的测试线程及测试逻辑示意图；

图5所示为本发明第二个实施例的测试线程及测试逻辑示意图；

图6所示为应用本发明的测试程序的结构图；

图7所示为图6中测试程序中线程类Thread中Svc()函数的流程图。

具体实施方式

以下以启动两个测试线程的测试程序为例，说明本发明的测试逻辑。

图1所示为应用本发明所述方法的两个测试线程的测试逻辑。第1个测 试线程中要对第1个API接口、第2个API接口进行调用，第2个测试线程 中要对第3个API接口、第4个API接口进行调用。假设需要对每一个API 接口调用进行并发冲突测试，则在上述4个对API接口的调用前插入同步申 请点。

当各个测试线程执行到同步申请点时，会向测试程序发出同步申请。例 如，测试程序在接受第1个测试线程的同步申请后，令第1个测试线程处于 等待状态，直到接受第2个测试线程发出的同步申请后，再同时唤醒两个测 试线程，令其继续执行。由于同步申请点后每个测试线程都调用对应的API 接口，这样通过同步申请点，测试程序即可实现两个测试线程对两个API接 口的同时调用，在本文中称之为一次同步。从理论上讲，每个测试线程在被 唤醒之后的API接口调用是最有可能同步执行的，特别是在多CPU的机器 上。这样每次同步都可以制造并发冲突的机会。

在测试程序中，可以启动更多的测试线程，每个测试线程中执行的测试 逻辑可以相同，也可以不同。

同时，测试程序接受测试线程同步申请的条件可以根据测试的具体内容 设置。在最简单的实施例中，可以设置为接受所有的同步申请。还可以建立 所调用的API接口与发出同步申请的对应关系，例如令图1中的第1个测试 线程在调用第2个API接口前发出的同步申请中包括此同步申请为第2个同 步申请的信息，则测试程序可以区分出每个同步申请后调用的是哪个API接 口，这样如果只想对不同API接口的并发冲突进行测试，可设置接受同步申 请的条件为该同步申请与本次同步过程中其他测试线程已被接受的同步申请 不同，换言之，该测试线程同步申请后所调用的API接口，与其他处于等待 状态的测试线程即将调用的API接口不同；若只希望测试相同API接口的并 发冲突，则可设置接受同步申请的条件为该同步申请与本次同步过程中其他 测试线程已被接受的同步申请相同。

图2所示为本发明所述测试方法的流程图。

在步骤S210，在测试逻辑中待测试的API接口前插入同步申请点；

在步骤S220，测试程序启动至少两个执行所述测试逻辑的测试线程；

在步骤S230，测试线程执行到同步申请点时，向测试程序发出同步申请；

在步骤S240，测试程序根据设定的条件判断是否接受该测试线程的同步 申请；如果接受，执行步骤S250；如果不接受，执行步骤S260，该发出同 步申请的测试线程继续执行；

在步骤S260，测试程序判断是否当前运行中的除所述发出同步申请的线 程外的其他测试线程都处于等待状态，如果否，则执行步骤S270，将该发出 同步申请的测试线程置于等待状态；如果是，则执行步骤S280；

在步骤S280，唤醒所有处于等待状态的测试线程继续执行，同时令该发 出同步申请的线程也继续执行；

在步骤S290，该发出同步申请的线程提示操作系统进行线程切换。

在操作系统中，由线程调度器给每个线程分配CPU时间片，只有获取到 CPU时间片的线程才处于运行状态，否则处于挂起状态。

在步骤S280中唤醒所有处于等待状态的测试线程时，该发出同步申请 的测试线程正处于运行状态，此时在大多数情况下当前正在运行的测试线程 比其他被唤醒的测试线程更有可能占用CPU。而由于不同操作系统对线程切 换的实现方式有所不同，在一些操作系统中如果当前正在运行的线程不主动 提示操作系统进行线程切换，则当前正在运行的线程会一直占用较多的CPU 时间片，导致其他线程获得运行的机会减少。

在本发明中每次同步后，理想的情况是所有测试线程处于平等的并发竞 争状态。因此，执行步骤S290，由发出同步申请的测试线程提示操作系统， 该发出同步申请的测试线程不需要继续占用CPU，这样线程调度器可以选择 另一个线程来运行，但线程调度器也有可能会忽略这一提示，继续运行发出 同步申请的测试线程。当将测试线程从同步等待状态被唤醒后，执行这个操 作，能够确保在此时间点出现线程切换操作，从而更好地让所有的测试线程 处于一个并发竞争的状态。

可以令每个测试线程在启动后循环执行测试逻辑，直到接到测试人员或 测试程序发出的退出指令。同时，为了方便测试人员对测试程序中正在运行 中的测试线程随时进行调整，本发明允许测试人员在测试进行中启动新的测 试线程、删除已启动的测试线程。这需要测试程序维护一个运行线程记录， 用来记录当前运行中的所有测试线程的线程标识，还可以记录运行中的测试 线程的总数，运行线程记录应在测试线程启动前设置。测试程序可以根据运 行线程记录进行步骤S260和步骤S370。

图3所示为每个测试线程的运行流程图。测试线程启动后，进入步骤 S310，在运行线程记录中增加本测试线程。

在步骤S320，准备测试线程运行的测试环境。

在步骤S330，执行测试线程的测试逻辑。测试线程的同步申请、进入等 待状态、从等待状态被唤醒都是在测试逻辑的执行过程中完成。

在步骤S340，在本轮测试逻辑执行完毕后，将测试环境恢复到步骤S320 之前的状态。

步骤S320与步骤S340中准备测试环境和恢复测试环境的实现方法与现 有技术相同，此处不再赘述。

在步骤S350，判断是否接到本测试线程的退出指令，如果否，转步骤 S320，开始下一轮测试逻辑的执行过程；如果是，继续步骤S360。

在步骤S360，从运行线程记录中删除本测试线程。同时，如果运行线程 记录中包括运行中测试线程的总数，测试程序会将该总数减一。

在步骤S370，判断是否当前运行中的其他测试线程都处于等待状态，如 果是，执行步骤S380，令其他测试线程继续执行，而本测试线程退出；如果 否，则本测试线程退出。在一个测试线程退出时，有可能出现当时其他测试 线程已经在等待着本测试线程的同步申请成功，而本测试线程不再执行下一 轮测试逻辑，也不会再发出同步申请，这样由于测试程序认为尚未达到所有 测试线程的同步，其他测试线程将始终处于等待状态。步骤S370就是为了 防止这种情况的发生。

在一个应用软件中，具体有哪些API接口可能存在并发冲突错误，很难 通过事先分析得出结论。因此，在实践中比较可行的方法是假定尽量多的API 接口存在并发冲突错误。如果能够对应用软件中提供的所有API接口都进行 同步调用测试，那么就可以保证测试的覆盖率。

在实践中通常采用两种不同的测试设计，第一种是在一个测试逻辑中完 成对所有API接口的调用，启动多个这样的测试线程执行同一个测试逻辑； 第二种是不同的API接口在不同的测试逻辑中调用，每个测试逻辑都在不同 的测试线程中执行。以下以这两种测试设计作为本发明的第一个和第二个实 施例，详细进行说明。

图4所示为本发明第一个实施例的测试线程及测试逻辑的示意图。启动 的测试线程数量为m(应满足m≥2)，每个测试线程执行相同的测试逻辑， 在测试逻辑中依次调用第1个至第n个API接口，即测试逻辑中的同步申请 点的数量为n。

启动的测试线程数量决定了每次同步后会同时调用的API接口的数量。 本实施例中，启动的测试线程数量为m，则每次同步后对m个API接口的并 发冲突进行测试。在本实施例中优先测试不同API接口之间的并发冲突，具 体而言是以下述方式进行测试：

当m＜n时，对部分不同的API接口之间的并发冲突进行测试，这种测试 是不完整的；

当m＝n时，测试所有API接口同时调用时是否会出现并发冲突。这种情 况下，对相同API接口同时调用的并发冲突没有进行测试；

当n＜m＜2n时，每次同步后测试所有不同API接口之间的并发冲突和部 分相同API接口之间的并发冲突，同时要满足相同API接口的数量不超过2 个，换言之，如果将m个API接口中相同的接口作为一组，则每组的数量不 超过2个；

如果m≥2n，每次同步后测试所有不同API接口之间的并发冲突，和所 有API接口与相同接口之间的并发冲突，同时要满足相同API接口的数量不 超过k个，换言之，如果将m个API接口中相同的接口作为一组，则每组的 数量不超过k个；其中k等于(m-1)除以n所得的整数部分加1。在这种 情况下，测试覆盖是最全面的。

要实现上述测试方式，需要在本发明所述测试方法的基础上增加一些工 作：

在测试逻辑设置同步申请点时，应当建立每个同步申请与所调用的API 接口的对应关系，使测试逻辑在执行到该同步申请点发出同步申请时，测试 程序能够区分不同测试线程同步申请后调用的API接口是否相同；

将接受同步申请的条件设置为：本次同步已被接受的同步申请中与该同 步申请相同的个数，不超过(m-1)除以n所得的整数部分，其中m为当前 运行的测试线程的个数；n为当前测试逻辑中测试申请点的数量。

同时，为了便于修改测试逻辑，可以对测试逻辑中的同步申请点进行自 动计数，例如在开始执行一轮测试逻辑时置计数器为0值，每进行一次同步 申请计数器的值加1，到本轮测试逻辑执行完毕时计数器的值即为测试逻辑 中同步申请点的个数。

图5所示为本发明第二个实施例的测试线程及测试逻辑的示意图。第二 个实施例中，不同的API接口在不同的测试逻辑中调用。请参见图5，第1 个测试线程中调用了第11个API接口、第12个API接口至第1x个API接 口，第2个测试线程中调用了第21个API接口、第22个API接口至第2y 个API接口，第m个测试线程中调用了第m1个API接口、第m2个API接 口至第mz个API接口。

在本实施例中，应将接受同步申请的条件设置为：接受所有的同步申请。

当m个不同的测试线程执行m个不同的测试逻辑时，只有可能对每个 测试线程中的API接口与其他测试线程中API接口之间的并发冲突进行测 试，而同一个测试逻辑中API接口之间的则不会有同时调用的机会。

由于每个测试逻辑中的API接口都不相同，因此只有当至少两个测试逻 辑运行相同的测试逻辑时，相同的API接口才有可能被同时调用。也就是说， 图5中所示的m个测试逻辑中，要测试每个逻辑中相同的API接口之间的并 发冲突问题，必须至少启动2m个测试线程。

当每个测试逻辑中进行测试的API接口数量超过1个时，本实施例对同 时调用哪些API接口的控制不如第一实施例，因而本实施例的测试覆盖率不 如第一实施例。但是本实施例测试逻辑的实现因为只涉及到较少数量的API 接口，实现相对简单。

当每个测试逻辑中只对一个API接口做测试，而至少启动两个测试线程 执行同一个测试逻辑时，本实施例的测试覆盖率最终可以做到和第一实施例 一样的全面覆盖。这种情况下，所要启动的测试线程数将随着待测试的API 接口数量的增加而线性增长。

以下介绍本发明所述方法以及上述两个实施例的一种具体的程序实现方 式。

如前所述，本发明中测试逻辑是在单独的测试线程中执行的。在实践中， 为了使测试程序能够更方便地应用于不同的测试逻辑和不同的测试线程，最 好能够解耦测试线程对象和测试逻辑。本发明提供的测试程序的结构包括测 试逻辑接口TestInterface、同步接口LockInterface、同步实现接口 LockImplInterface，以及线程类Thread。

请参阅图6，测试逻辑接口TestInterface用来完成测试逻辑的一次完整的 执行过程。其中，包括三个步骤，Setup()函数用来准备测试环境；Test() 函数用来执行测试逻辑，在执行过程中通过调用同步接口LockInterface来进 行同步；TearDown()函数用来恢复测试环境。

同步接口LockInterface用来进行测试逻辑执行过程中的同步，主要由 Lock()函数实现：

void Lock(){

  if(ShouldWait()){       //本测试线程的同步申请是否被接受

     if(AllIsWaiting()){  //如果是，是否其他测试线程都处于等待状态

        UnlockAll()；     //如果是，令所有测试线程继续执行

     }else{

       WaitOthers()；     //如果不是，则本测试线程转入等待状态

     }

    yield()    //提示线程调度器本测试线程不需要运行

   }

}

其中，yield()函数完成提示操作系统进行线程切换的功能。

在测试逻辑的执行过程中，每执行到同步申请点都要调用Lock()函数， 因而可以通过统计调用Lock()函数的次数统计同步申请点的数量。

同步实现接口LockImplInterface是同步接口LockInterface的一个子类， 主要用来在测试逻辑接口TestInterface、测试线程类Thread之间传递信息， 以实现自动计算线程数量和每个测试逻辑的同步申请点的数量。同步实现接 口LockImplInterface主要包括两个函数：Init()函数和Fini()函数；

测试线程在启动后即会调用Init()函数，通知测试程序一个测试线程 已经启动，测试程序可据此在运行线程记录中增加本测试线程；如果需要自 动统计测试逻辑中同步申请点的数量，可以在Init()函数中增加通知测试 程序将开始执行一轮的测试逻辑的功能，这种情况下在每一次开始执行测试 逻辑前，即调用测试逻辑接口TestInterface之前都要调用Init()函数。测试 线程第二次及以后每次调用Init()函数都通知测试程序将开始一轮的测试 逻辑，测试程序可以将测试线程启动后，第一次和第二次调用Init()函数 作为统计测试逻辑中同步申请点数量时的起止点，同步申请点的数量即是在 这一起止点之间该测试线程调用Lock()函数的次数；

测试线程在退出前执行Fini()函数，在Fini()函数中，会判断是否 当前运行中的其他测试线程都处于等待状态，如果是，令其他测试线程继续 执行，以便本测试线程的退出不会妨碍其他测试线程中测试逻辑的实现。同 时，调用Fini()函数将通知测试程序本测试线程退出，测试程序据此在运 行线程记录中删除本测试线程。

线程类Thread的用来控制测试逻辑的重复运行，并根据退出指令终止运 行，其主要功能由以下4个函数实现：

Thread(TestInterface&，LockInterface&)函数是一个构造函数，其含义 为需要利用测试逻辑接口TestInterface和同步实现接口LockImplInterface这 两个类型的参数来生成线程类Thread的一个对象；

测试人员或测试程序通过调用Terminate()函数来指令该测试线程退出。 当Terminate()函数被调用后，IsTerminate()函数即会返回True(逻辑真 值)，表示本测试线程被请求终止运行；Terminate()函数的调用即是向该 测试线程发出图3的步骤S350中所述的退出指令；

测试线程在一轮测试逻辑执行完毕后会调用IsTerminate()函数，看是 否本测试线程被请求终止运行，如果是，则在调用同步实现接口 LockImplInterface的Fini()函数后退出运行；测试线程调用IsTerminate() 函数完成图3中的步骤S350；

Svc()函数通过调用上述的接口和函数实现一个测试线程的运行过程。 假设My-Test为测试程序中定义的测试逻辑接口TestInterface，My_Lock为 测试程序中定义的同步实现接口LockImplInterface，则Svc()函数的流程如 图7所示：

在步骤S710，调用My_Lock.Init()；

在步骤S720，调用My_Test.Setup()；

在步骤S730，调用My_Test.Test()；

在步骤S740，调用My_Test.TearDown()；

在步骤S750，调用IsTerminated()函数，当IsTerminated()函数返回 True时，转步骤S760；当其返回False(非真值)时，转步骤S710，开始下 一轮测试逻辑的执行；

在步骤S760，调用My_Lock.Fini()函数，之后该测试线程退出。

请再参阅图6，在上述各个接口和类的基础上，具体测试逻辑通过继承 测试逻辑接口TestInterface来实现；同步策略主要包括接受同步申请的条件， 即对哪些API接口进行并发冲突测试，将本发明的上述两个实施例看作同步 策略一和同步策略二，这两种同步策略通过继承同步实现接口 LockImplInterface实现，以下分别予以说明。

本发明的第一实施例中，所有测试线程执行相同的测试逻辑。由于允许 测试人员或测试程序在测试过程中随时增加和删除测试线程，因此在第一实 施例中必须对每个测试逻辑中同步申请点的数量进行自动统计，统计方法如 前所述。

实现第一实施例中的同步策略还需要设置接受同步申请的条件：定义一 个一维数组，该数组的变量个数N_Cnt由下式确定：

N_Cnt＝Lock_Cnt+Lock_Cnt*((Thr_Cnt-1)/Lock_Cnt)

上式中，Thr_Cnt为当前运行中的测试线程总数，Lock_Cnt为当前统计 所得的每个测试线程中同步申请点数量的最大值，(Thr_Cnt-1)/Lock_Cnt 为(Thr_Cnt-1)除以Lock_Cnt后所得的整数部分。当Thr_Cnt≤Lock_Cnt 时，N_Cnt＝Thr_Cnt；当k*Lock_Cnt＜Thr_Cnt≤(k+1)*Lock_Cnt时(k 为大于等于1的整数)时，N_Cnt＝(k+1)*Lock_Cnt。

上述数组用来记录已被接受的同步申请。对数组元素的使用以Lock_Cnt 为单位进行，即该数组的第(k*Lock_Cnt+1)至第(k+1)*Lock_Cnt个元 素为第k组。在每次同步后，将数组中的每个元素清零。请参阅图4，当接 收到测试线程在同步申请点3发出的同步申请3时，查询数组中第1组的第 3个元素是否为零，如果是，则接受该同步申请3，并将第1组的第3个元素 置为1，表示本次同步已经有一个测试线程将调用API接口3了。如果第1 组中的第3个元素已经置1了，则查询是否本组其他元素是否都已经置1了， 如果本组中还有元素为零，则拒绝该同步申请3；如果本组中所有元素都已 置1，则再以同样的步骤查询下一组。这样，就可以实现对不同API接口并 发冲突的优先测试。

本发明的第二实施例实现起来更为简单方便。第二实施例中可以不对测 试逻辑中同步申请点的数量进行自动计数，而接受同步申请的条件只要设置 为接受所有的同步申请即可。

实施本发明所述方法后，测试程序不再等待API接口碰巧出现的同时调 用，而是主动控制对API接口的并发调用。理论上，本发明可以实现所有 API接口的并发冲突测试，但是由于线程的调用是由操作系统直接管理的， 实际真正能够并发调用的API接口则受到了硬件条件的限制。如果测试程序 中进行同步的测试线程数量很大，即使在多CPU的计算机上也很难实现同时 调用所有的测试线程。因而即使在事实上，本发明所述方法也为应用程序测 试提供了所有API接口都能够并发调用的机会。

以上所述的本发明实施方式，并不构成对本发明保护范围的限定。任何 在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含 在本发明的权利要求保护范围之内。