收藏本站 收藏本站
积木网首页 - 技术学院 - 软件测试 - 网站黄页 - 常用手册 - 站长工具 - 技术社区
软件测试 > 单元测试 > 正文

首页 | 领域细分: 游戏测试 安全测试 手机测试 Web测试 | 技术研究: 单元测试 入门教程 用例设计 性能测试 功能测试 | 测试职场: 面试精选 职场发展 面试试题

测试管理: 配置及流程 - 需求管理 - 质量验收 - 缺陷管理 - 其它管理相关 | 开发语言: PHP技巧 - PHP基础 - PHP实例 - PHP错误代码

测试工具: LoadRunner JiRa QuickTestPro RoBot WinRunner TestDirector 其它测试工具 | 数据库: Mysql数据库 Oracle数据库 CSS/DIV基础 HTML基础

并行运行单元测试的启示

来源:互联网 日期:2014-05-15 11:30

  我们希望采用并行的方式在本地运行单元测试,从而减少测试时间,提高开发人员的工作效率。我们使用了线程池来提供多线程的并行任务。通过配置启动多个线程,并以程序集为单位,启动TestRunner:

var executorWrapper=newExcetorWrapper(assemblyName,null,false);
var testRunner=newTestRunner(executorWrapper,newRunnerLoggerWrapper());
testRunner.RunAssembly();

  其中的RunnerLoggerWrapper是一个自定义的类,实现了Xunit的IRunnerLogger。XUnit的使用并非本文描述的内容,在此略过。

  因为是以程序集为单位,所以我们在启动多线程之前,会事先将需要运行的程序集放到一个队列中,然后在启动多线程之后,执行出队列操作。多线程的运行代码如下所示:

privatestaticManualResetEvent[] resetEvents;
privatestaticQueue<String>assemblyQue;
privatestaticreadonlyObject LockAssembly2Queue=newObject();

publicvoidRun()
{
for(var index=0; index<numThreads; index++)
{
resetEvents[index]=newManualResetEvent(false);
ThreadPool.QueueUserWorkItem(DoWork, index);
}
WaitForAllManualEvent();
}
privatevoidWaitForAllManualEvent()
{
if(Thread.CurrentThread.ApartmentState=ApartmentState.STA)
{
foreach(var manualResetEventinresetEvents)
{
WaitHandle.WaitAny(newWaitHandle[]{manualResetEvent});
}
}
else
{
WaitHandle.WaitAll(resetEvents);
}
}
privatestaticvoidDoWork(Object index)
{
Thread.CurrentThread.ApartmentState=ApartmentState.STA;
while(true)
{
stringcurrentAssemblyName=null;
lock(LockAssembly2Queue)
{
if(assemblyQue.Count!=0)
{
currentAssemblyName=assemblyQue.Dequeue();
}
else
{
resetEvents[(int)index].Set();
Console.WriteLine("Exited current thread:{0}", Thread.CurrentThread.Name);
break;
}
}
if(currentAssemblyName!=null)
{
newTestRunnerWrapperWithAssembly(currentAssemblyName).Runner();
}
}
}

  由于要测试的程序集比较多,采用这种并行方式可以极大地提高运行效率。由于单元测试彼此是独立的,在并行运行时,互相没有干扰。这是我们实现判断的结果。一切看起来很美好,但在真正运行时,却出现了大量的死锁。异常信息为:

  Transaction (Process ID) was deadlocked on resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

  在我们的单元测试中,大多数测试需要访问的资源都是在内存中进行,但有一部分单元测试必须与数据库通信,对数据表进行读写。除了极少数特殊的测试用例外,对数据表的操作都放在事务中进行,并在执行完毕后,通过回滚事务,避免对真实数据的提交,保证单元测试不会影响数据库。

  注:单元测试应该访问数据库吗?这其实还有待确认。在《修改代码的艺术》一书中,Feathers这样写道:

  单元测试运行得快。运行得不快的不是单元测试。

  有些测试容易跟单元测试混淆起来。譬如下面这些测试就不是单元测试:

  (1)跟数据库有交互;

  (2)进行了网络间通信;

  (3)调用了文件系统;

  (4)需要你对环境作特定的准备(如编辑配置文件)才能运行的。

  以上可以看到Feathers的态度是单元测试不应与外部资源进行交互。显然,如果出现了这些交互,就应该采用Mock的方式来模拟对外部资源的访问。然而,某些实现功能却是与外部资源息息相关,又或者我们测试的目的本身就是验证对外部资源的访问是否正确。从测试的范围来看,它们仍然算是单元测试,但因其特殊性,而应该将这些测试放到系统测试的范畴。在持续集成中,我们常常用金字塔来表示单元测试、系统测试和集成测试的数量。如下图所示:

  单元测试的数量最多,如果还需要访问外部资源,就会严重影响运行单元测试的速度。关于单元测试、Mock等内容,我希望在以后的文章里详细论述。

  在我们的项目中,是通过注入Fixture的形式生成测试数据。例如,我们可能希望注入Client、Associate等对象,从而完成对某些行为的测试。例如:

[Fixture(typeof(client_hastings))]
public Client client;

[Fixture(typeof(Samuel))]
public Associate Samuel;

  通过Fixture准备数据时,如果采用了持久化方式,则意味着需要对数据表进行操作。如上代码就可能操作多张表,例如对Client表和Associate表进行写操作。由于单元测试采用并行方式进行。假设存在两个单元测试均需要对Client和Associate注入Fixture,生成测试数据;并且不幸的是,这两个测试用例准备数据的顺序刚好相反,即A测试用例的顺序为Client->Associate,B测试用例的顺序为Associate->Client,就可能发生死锁。

  为什么?让我们分析数据库发生死锁的情况。它必然是多个进程(或线程)对两个或两个以上的资源形成了交叉访问。例如进程A在占有了资源1的同时,还需要访问资源2;与此同时,进程B在占有了资源2的同时,需要访问资源1。由于资源1已经被进程A占用,无法释放,进程B就会等待;而进程A希望访问的资源2又被等待中的进程B持有;二者互不相让,最终产生死锁。这正是并行运行单元测试导致死锁的根本原因。我们可以运行SQL Server Profiler来监视数据库的执行。注意,倘若需要跟踪死锁的情况,需要在Trace Properties中勾选“Deadlock Graph”和“Lock: Deallock”选项,如下图所示:

  创建Trace后,利用并行方式运行单元测试,可能得到这样的Deadlock graph:

  图中,椭圆代表进程(线程),矩形代表资源。左边的椭圆打了一把叉,说明是竞争失败的进程(线程)。从椭圆出发,箭头所指的资源,代表进程请求的资源;而发出箭头的资源,则代表箭头指向的进程持有该资源。可以发现,两个进程与两个资源之间的箭头,事实上形成了一个封闭的环。这正是死锁的典型表现。

  当我们将单元测试的Fixture注入顺序保持一致时,这样的死锁就能够避免了。这是一种限制,它很难被编写单元测试的开发人员所接受,即使勉强接受,仍然很容易疏漏。因此,我们的结论仍然是“不到迫不得已,单元测试不要访问外部资源”。或者说,我们可以将访问外部资源的单元测试,看成是特殊的单元测试,如果确实需要并行运行测试,以提高测试效率,可以通过引入多个Agent,以物理方式隔离资源,避免出现资源的争用导致死锁。

  那么,这是否意味着我们的产品代码不够严谨,没有充分考虑并发的情况呢?不完全对。因为这里产生死锁的时机发生在准备测试数据的阶段,实际操作时,一般不会出现这种频繁对多张表进行操作的情况。然而,即使几率很低,始终存在死锁的隐患,这就为我们的开发敲响了警钟。因此在开发过程中,有必要通过对业务的分析,制订一些指导原则,通过规范写数据表操作的顺序,避免出现死锁。这是这次并行运行单元测试给我们带来的启示。

本周排行

别人正在浏览

强悍的草根IT技术社区,这里应该有您想要的! 友情链接:b2b电子商务
Copyright © 2010 Gimoo.Net. All Rights Rreserved  京ICP备05050695号