CN101751248A - 为Web应用设计时间敏感的性能测试用例的方法和系统 - Google Patents

Abstract

提供了一种用于为Web应用设计时间敏感的性能测试用例的方法和系统。所述方法包括：生成所述Web应用的多个会话的会话信息以及时间信息；基于所述会话信息，获取每个会话的有价值的用户访问模式；以及根据所述有价值的用户访问模式并结合所述会话信息和时间信息，设计新的测试用例。根据本发明的方法和系统可以在基于用户会话设计性能测试用例的同时，完全保持时间信息。并且，所述方法和系统还可以找到在新的测试用例生成期间可以被终端用户高度重复使用的用户模式。

Description

为Web应用设计时间敏感的性能测试用例的方法和系统

技术领域

本发明一般地涉及为Web应用设计测试用例，并且具体而言涉及一种用于为Web应用设计时间敏感(time-sensitive)的性能测试用例的方法和系统。

背景技术

对于Web应用的测试而言，性能测试是一种用于检验Web应用的健壮性和有效性的非常重要的阶段，在此阶段中，性能测试的设计扮演了关键的角色。对于不良的设计测试用例来说，性能测试将变得作用很小，或者甚至不起作用。

已经建立了用于性能测试的许多标准，例如TPC基准(benchmark)。这些标准要么定义了用于评估指定产品的性能的准则，要么提供了用于帮助测试者设计测试用例的某些代码或方法或指导。然而，对于一种单独的标准而言，它无法涵盖所有的应用。它所能提供的仅是某些公共点，并且在某些情形中，这些公共点可能是不适合的。

另外一类方案是基于系统设计来设计性能测试用例。测试用例的设计者设计出一些场景，他们设想终端用户将在所述场景中使用Web应用。但是，该方案具有若干局限性。首先，对于终端用户的操作是基于想象的。所设计的场景可能不是由实际的终端用户执行的，从而实际用户可能以超出设计者的想象之外的方式来使用Web应用。并且，应用中的某些特征可能不像设计者所想象的那样被频繁使用，或者甚至被终端用户完全忽略。其次，对于Web应用的峰值时间的工作负荷以及工作负荷分布，设计者将尝试从开发小组或者客户获得适当的输入，以便更为准确地模拟终端用户对应用的使用情况。如果设计者无法得到这样的输入，则他们不得不通过已有经验或预期来“设计”该应用的工作负荷以及工作负荷分布。显而易见，这样的测试用例具有局限性，其无法代表该应用的实际工作情况。

为了改进测试用例的质量，还存在一类基于用户会话数据的方案，其试图通过模拟终端用户实际行动来生成测试用例。然而，在所述方案中，尽管已经采取了很多努力来跟踪每个用户的动作，但是这些方案并没有考虑时间因素，所述时间因素事实上是性能的关键必需方面之一，因此所述方案没有完全模拟实际的终端用户可能对Web应用进行的操作。当测试用例被生成时，它们被随机地应用到Web应用，或者仅遵循某些简单的规则，这远远脱离了Web应用在实际环境中可能面对的真实场景。例如，实际的峰值时间工作负荷可能大于设计者所设计的工作负荷值，以及实际的系统工作负荷分布可能完全不同于设计者所设计的那样。

此外，从测试者的视角看来，基于所有的用户会话来编写测试脚本是繁重的工作负荷，因为存在太多种不同的会话。测试者期望一些用于减少脚本编写任务的解决方案，并且尽可能多地合理地重复使用它们。

发明内容

为了解决上述缺陷，提出了本发明。本发明提供了一种为Web应用设计时间敏感的性能测试用例的可重复使用的方案，从而能够更好地模拟该应用相对于时间帧的真实环境。根据本发明的方案可以在基于用户会话设计性能测试用例的同时，完全保持时间信息。并且，所述方案还可以找到在新的测试用例生成期间可以被终端用户高度重复使用的用户模式。

在本发明的第一方面中，提出了一种用于为Web应用设计时间敏感的性能测试用例的方法，所述方法包括：生成所述Web应用的多个会话的会话信息以及时间信息；基于所述会话信息，获取每个会话的有价值的用户访问模式；以及根据所述有价值的用户访问模式并结合所述会话信息和时间信息，设计新的测试用例。

在本发明的第二方面中，提出了一种用于为Web应用设计时间敏感的性能测试用例的系统，所述系统包括：数据准备装置，用于生成所述Web应用的多个会话的会话信息以及时间信息；用户访问模式分析装置，用于基于所述会话信息，获取每个会话的有价值的用户访问模式；以及测试用例生成装置，用于根据所述有价值的用户访问模式并结合所述会话信息和时间信息，设计新的测试用例。

在本发明的第三方面中，提出了一种计算机程序产品，其可被加载到计算机上并包括程序代码工具，当所述计算机程序产品在计算机上运行时，所述程序代码工具适于执行所述的用于为Web应用设计时间敏感的性能测试用例的方法的所有步骤。

附图说明

在附带的权利要求中阐明了被认为是本发明新颖特性的特征。然而，通过参考以下结合附图的说明性实施例的详细描述，将最好地理解本发明本身以及其优选使用模式、另外的目的和优点，在附图中：

图1示出了多个用户会话相对于时间的会话-时间分布示意图；

图2示出了根据本发明的一个实施例的一种为Web应用设计时间敏感的性能测试用例的方法的流程图；

图3示出了步骤210的数据准备阶段的详细流程图；

图4示出了步骤220的模式分析阶段的详细流程图；

图5示出了步骤230的生成测试用例阶段的详细流程图；

图6示出了根据本发明的一个实施例的所述方法的实现流程；以及

图7描述了根据本发明一个实施例的一种为Web应用设计时间敏感的性能测试用例的系统的示意性框图。

需要注意，在全体附图中，相同或相似的标号指代的是相同或相似的单元或组件。

具体实施方式

在下文中将结合附图对本发明的示范性实施例进行描述。为了清楚和简明起见，在说明书中并未描述实际实现方式的所有特征。然而，应该了解，在开发任何这种实际实施例的过程中必须做出很多实现方式所特定的决定，以便实现开发人员的具体目标，例如符合与系统及业务相关的那些限制条件，其中，这些限制条件会随着实施方式的不同而改变。此外，还应该了解，虽然开发工作有可能是非常复杂和费时的，但对得益于这个公开内容的本领域技术人员来说，这种开发工作仅仅是例行的任务。

此外，还需要说明的一点是，为了避免因不必要的细节而混淆了本发明，在附图中仅仅示出了与根据本发明的方案密切相关的装置结构和/或处理步骤，而省略了与本发明关系不大的其它细节。

根据本发明的方案一般地适用于Web应用，并且特别地适用于演进型(evolution)的Web应用，其原因在于演进型的Web应用具有以下关键特征：

·在Web应用的之前的版本中，存在一些日志文件，其详细记录了用户的实践行为。

·在Web应用的之前的版本中，终端用户已经形成了某些惯例，并且其中大部分惯例不会改变。

·从Web应用的旧版本到新版本，所做出的改变(不论是新添加的功能还是更新的功能)一般而言只是一小部分。从策略角度而言，该Web应用在某种程度上是稳定的。

应该指出，尽管演进型的Web应用在某种程度上是稳定的，但是仅仅重复已有的日志进行性能测试仍然是不切实际的。存在许多妨碍这样的行为的局限性，诸如紧密的时间调度、已改变的Web链接、以及复杂的测试用例准备。

因此，在本领域中，提出一种能够更好地适应上述情形的方案是有必要的。本发明主要是一种时间敏感的解决方案，其用于基于用户场景(会话)生成性能测试用例，同时保持它们的时间信息。为了更好地理解本发明的实施方式，首先参见图1，图1示出了多个用户会话相对于时间的会话-时间分布示意图。如图1所示，图1中示出了真实应用中的8个会话，其分别被会话标识符(ID)S1-S8所标识，每个会话由一条实线表示。每个会话具有其自己的时间信息。以会话S8为例，S8的时间信息包括“会话开始时间戳”110以及“会话持续时间”120。从时间轴上看，标识出给定时间点的会话是很容易的。例如，在时间点T’，存在三个有效会话S2、S4和S7，它们通过向Web服务器发送请求而对Web应用施加压力。换句话说，在该时间点T’，系统工作负荷是由这三个会话所造成的。如此，可以很容易地在时间轴上定位出峰值时间的工作负荷。例如，从图1中可以容易地得出，在时间点T’同时存在三个会话，因此该时间点是峰值时间。此外，当纵览整个示意图时，可以直观地得到Web应用在真实环境中相对于时间帧的会话分布的完整视图。

参考图1中所示的会话-时间图，可以清楚地知道每个会话何时开始以及它在多久时间内有效，从而可以获得各个会话在整个时间轴上的分布。并且，可以容易地识别出Web应用在每个时间点的工作负荷。这些信息对于最终的测试用例设计是十分有用的。

根据本发明的方法，可以在基于用户会话设计测试用例的同时，完全保持这些时间信息。当经由数据挖掘(data mining)技术并通过必要转换从用户会话信息中导出测试用例的时候，这些测试用例可以迅速地与初始时间信息联系在一起。这样，从时间轴上看，除了用新的测试用例替换初始用户会话之外，用户会话的时间分布(或者换句话说，初始的会话-时间分布图)几乎是不变的。与此同时，数据挖掘技术还可以有助于找到终端用户最常用的模式，所述模式在新的测试用例生成期间是高度可重复使用的。由此，这些常用模式将成为新的用户测试用例的主要部分，并且初始的用户会话中的许多差异将被移除，从而对于测试者来说大大减少了不同测试用例的数量，提高了工作效率。

下面参考图2示出了根据本发明的一个实施例的一种为Web应用设计时间敏感的性能测试用例的方法的流程图。如图2所示，首先在步骤210，执行数据准备阶段。即，对Web日志进行处理，以生成所述Web应用的多个会话的有效的会话信息和时间信息。Web日志用于记录用户动作，其可以位于客户端浏览器或者Web服务器上，并且有时也可以在第三方设备上实现，所述第三方设备例如网关、代理或者防火墙。为了避免隐私问题，在本发明的一实施例中，将Web日志保存在Web服务器上是更为安全的。在本发明的可替代实施例中，Web日志可以被保存在第三方设备上。

通过对Web日志的处理，可以生成会话-时间示意图，例如图1所示的例子。以下结合图3示出了步骤210的数据准备阶段的详细流程图。如图3所示，在步骤305，将Web日志进行转换，接着其可以被提取、分解以及合并为一种特殊的可读数据格式。例如，大多数Web服务器可以提供以通用日志格式(CLF)、扩展通用日志格式(ECLF)、或者其它适当格式来存储日志的选项。不论选择采用何种格式来存储日志，其都可以至少提供必要的信息，如以下表1所示。

客户端主机名/IP	时间戳(日期和时间)	方法/URL/协议	HTTP状态	引用者	会话ID(可选)
						9.123.237.135	07/10/2007:9:23:40	GET/class/course340.htmlHTTP/1.1	200	http://www.mysite.com/index	S3876
9.123.237.195	07/10/2007:9:23:41	GET/test/result/340.htmlHTTP/1.1	200	-	S7313
						9.123.237.135	07/10/2007:9:23:55	GET/test/result/340.htmlHTTP/1.1	200	http://www.mysite.com/class/course340.html	S3876
9.123.237.135	07/10/2007:9:23:56	GET/welcome.htmlHTTP/1.1	200	http://www.mysite.com/test/result/340.html	S3876
						9.123.237.95	07/10/2007:9:24:10	GET/test/result/340.htmlHTTP/1.1	200	-	S6526
9.123.237.195	07/10/2007:9:24:40	GET/class/course340.htmlHTTP/1.1	200	http://www.mysite.com/test/result/340.html	S7313

表1

如表1所示，通过Web日志可以得到：每个会话的客户端主机名/IP、时间戳(日期和时间)、方法/URL/协议、HTTP状态、引用者。并且，通过Web日志可选地可以得到会话ID，例如，会话ID可以由日志记录系统创建。会话指的是，由同一客户端在特定时间间隔内做出的特定一组请求。对会话进行确定的实现方式可以包括：通过根据特定属性(例如客户端IP、客户端浏览器或者操作系统)来分组Web日志中的条目；或者通过根据来自同一IP地址的请求的时间间隙来分离这些请求，例如，来自同一客户端IP的两个条目，如果它们之间的间隙小于15分钟，则认为它们属于同一会话。

当原始的日志数据以特定格式被获取之后，在步骤310，可以从日志数据中提取必要的属性/字段。并且，还可以通过比较同一会话的第一和最后一个条目来获得每个会话的持续时间。

在属性\字段的提取步骤之后，可以将表1的数据组织为以下的形式，如表2所示。

会话ID	开始时间戳	会话持续时间(秒)	访问序列
				S7313	07/10/2007:9:23:41	59	/test/result/340.html，/class/course340.html
S3876	07/10/2007:9:23:40	16	/class/course340.html，/test/result/340.html，/welcome.html
				S6526	07/10/2007:9:24:10	0	/test/result/340.html

表2

表2包含的会话信息包括：会话ID、开始时间戳、会话持续时间(秒)、访问序列。为了进一步便于处理，在步骤315，可以将表2中的开始时间戳转换为相对格式，即，将“开始时间戳”列中的最小值设为零，并且为其它每个会话的时间戳计算偏移量。经过计算后的会话信息如以下表3所示。

会话ID	开始时间戳的相对偏移量(秒)	会话持续时间(秒)	访问序列
				S7313	1	59	/test/result/340.html，/class/course340.html
S3876	0	16	/class/course340.html，/test/result/340.html，/welcome.html
				S6526	30	0	/test/result/340.html

表3

表3中的“开始时间戳的相对偏移量”列中以相对格式示出了时间戳的偏移量。在表3中的“访问序列”列中，清楚地描述了每个会话中的用户场景。例如，在会话S3876中，用户在16秒内依次访问了三个页面，而在会话S6526中，用户仅访问了一个页面，因此可以将该会话的持续时间设为零。由此，在步骤320，通过将“开始时间戳”和“会话持续时间”中的值相结合，可以生成类似于图1所示的会话-时间示意图，其中每条实线表示一个会话中的访问序列。

现在返回图2，在数据准备阶段(步骤210)完成之后，根据本发明的所述方法进行到步骤220，执行模式分析阶段，用于基于所述会话信息，获取每个会话的有价值的用户访问模式。在此阶段中，需要基于对目标Web应用的旧版本的分析而生成用于该应用的当前版本的场景(用户访问模式)。以下结合图4示出了步骤220的模式分析阶段的详细流程图。在此阶段中，必要的会话信息是有用的，例如以上的表3中的会话信息。为了更好地说明本发明的方案并且简化描述，在此阶段中，采用与会话信息有关的更形式化的范例数据作为示例，如以下表4所示。

会话ID	开始时间戳的相对偏移量(秒)	会话持续时间(秒)	访问序列
				S1	TS1	SD1	C，D，A，B，C，A，B，F，A，C，D，F
S2	TS2	SD2	A，B，F，E
				S3	TS3	SD3	A，B，F
S4	TS4	SD4	D，G，H，B，F，A，G，H
				S5	TS5	SD5	M，N

表4

表4中的会话信息的形式与表3相同。但是，在表4中，会话ID、开始时间戳、会话持续时间和访问序列分别用形式化的字母数字表示，其中，开始时间戳采用如上所述的相对形式，访问序列中的每个字母A、B...N分别表示会话对Web服务器的不同请求，也即不同的页面。通过表4中的目标Web应用的旧版本的访问序列，可以获得对于用户有价值的访问模式。这些模式随后可以被提炼和修改，并生成表示目标Web应用的当前版本的新的访问序列。

为了产生有价值的用户访问模式，在步骤405，应用数据挖掘技术，通过定义一个阈值来获取有价值的用户访问模式，并且消除不常见的用户访问模式。有价值的用户访问模式指的是，其包括由终端用户执行的频繁访问序列。术语“频繁访问序列”指的是，所述访问序列在所有会话中出现了足够次数，该次数超过所定义的阈值。例如，假定频繁访问序列的阈值可以被设置为“60％的会话包含该访问序列”，即，在本示例中，“该访问序列在至少三个会话中出现”。因此，可以容易地看出，序列A-＞F是频繁访问序列，因为它出现在三个会话(S1、S2、S3)中；而序列F-＞A不是频繁访问序列，因为它只出现在两个会话(S1、S4)中。这样的频繁访问序列是所有用户请求的最主要部分。换句话说，这样的访问序列可以表示大多数的用户场景。

在现有技术中存在许多种方法用于找到这样的频繁访问序列，例如Chen MS，Park JS，Yu PS(1996)，“Data mining for path traversal patternsin a web environment”(Proceeding of the 16th international conference ondistributed computing systems，pp 385-392)。假定将频繁访问序列的阈值设置为“40％的会话包含该访问序列”，即，两个以上的会话包含该访问序列，通过应用数据挖掘算法，可以得到以下结果，如表5所示。

FID	频繁访问序列	出现次数	有关会话
				1	A	4	S1，S2，S3，S4
2	B	4	S1，S2，S3，S4

FID	频繁访问序列	出现次数	有关会话
				3	D	2	S1，S4
4	F	4	S1，S2，S3，S4
				5	A B	3	S1，S2，S3
6	A F	3	S1，S2，S3
				7	B A	2	S1，S4
8	B F	4	S1，S2，S3，S4
				9	D A	2	S1，S4
10	D B	2	S1，S4
				11	D F	2	S1，S4
12	F A	2	S1，S4
				13	A B F	3	S1，S2，S3
14	B F A	2	S1，S4
				15	D B F	2	S1，S4
16	D B A	2	S1，S4
				17	D F A	2	S1，S4
18	D B F A	2	S1，S4

表5

在表5中列举了符合条件的多个频繁访问序列，其中“FID”表示每个频繁访问序列的标识符，“频繁访问序列”表示符合条件的访问序列，“出现次数”表示其中出现该访问序列的会话的数量，“有关会话”表示其中出现该访问序列的会话。

可以看出，存在很多个符合上述条件“40％的会话包含该访问序列”的频繁访问序列。为了减轻之后对访问序列进行的进一步处理，在步骤410，需要对这些频繁访问序列进行进一步提炼。这是因为，测试者需要根据经过调整的所述频繁访问序列来记录并编写测试脚本。因此，如果存在太多的用户访问模式，则对于测试者来说，覆盖所有这些模式是一项繁重的劳动。

从表5中可以看出，会话S1和S4包含了具有不同长度的许多频繁访问序列。在此，长度指的是，在一个序列中出现的项目的数量。而这些序列都是“DBFA”(#18)的子序列。换句话说，“DBFA”是能够覆盖在会话S1和S4中出现的所有频繁访问序列的最大一个。由此，例如“BFA”(#14)、“DBF”(#15)、“DBA”(#16)、“DFA”(#17)都可以由序列“DBFA”所代表，因此可以将表5中FID为#14-#17的行过滤掉。

通过对表5中示出的例子进行提炼，可以减少频繁访问序列的数量。所述提炼也属于数据挖掘技术。通过应用数据挖掘算法，可以得到以下结果，如以下表6所示。

FID	频繁访问序列	出现次数	有关会话
				1	A	4	S1，S2，S3，S4
8	B F	4	S1，S2，S3，S4
				13	A B F	3	S1，S2，S3
18	D B F A	2	S1，S4

表6

在此要注意，提炼步骤410是可选的。在可替换实施例中，如果存在足够的人力资源和系统资源来覆盖所有的用户访问模式，则提炼步骤410可以被忽略。

接着，在步骤415，可以对频繁访问序列进行聚类。如果经过提炼步骤410之后，仍然存在超出期望的过多频繁访问序列，则在步骤415可以根据序列聚类技术来对这些序列进行聚类。序列聚类技术例如可以参见Yang J，WangW(2003)“CLUSEQ：efficient and effective sequenceclustering”(Proceeding of the 2003 international conference on dataengineering(ICDE’03)，Bangalore，India，pp 101-112)。

根据所述序列聚类技术，可以将FID#8和#13的两个序列聚类为同一个，因为它们非常相似。从而，可以选择“ABF”作为“频繁访问序列”列的值，以及选择S1，S2，S3，S4作为“出现次数”列的值。不过，在此要注意，该聚类步骤415是可选的，因为在频繁访问序列的数量不大的时候，可能不需要进行聚类。并且，将这些序列进行聚类存在一定风险，这样做在一定程度上失去了序列的精确性。

接着在步骤420，将这些序列(用户访问模式)从Web应用的旧版本迁移到当前版本，并且在必要的时候修改它们，以更好地反映目标Web应用的当前版本。也就是说，测试者需要针对Web应用的当前版本检查基于旧版本的访问序列，并且进行必要的调整。对于从上述步骤中获得的每个序列而言，在迁移过程中可能存在以下五种情形。

·情形1。如果在当前版本中执行序列遍历成功，则该序列是正确的。所述遍历指的是，在当前版本中按照顺序遍历该序列中的所有页面/项目，以确定是否可以成功地完成所有页面/项目。

·情形2。如果在当前版本中执行序列遍历失败，且其原因是该序列中的所有页面/项目在当前版本中被完全移除，则终止并删除该序列。

·情形3。如果在当前版本中执行序列遍历失败，且其原因是该序列中的某些页面/项目被移动到其它位置，则需要尽可能少地添加新的项目，使得在Web应用的当前版本中形成可用的用于遍历的路径。例如，在例子1中，在针对旧版本的序列中，页面B在页面F之前。但是在当前版本中，假定在B和F之间存在一个新页面Z，那么，需要使用该额外的页面Z更新该序列。即，将序列FID#8、#13、#18分别更新为“BZF”、“ABZF”、以及“DBZFA”。例如，在例子2中，在旧版本和新版本中，在页面D到页面B之间本来不存在直接的链接，但是由于上述的提炼步骤410的原因，需要执行序列DB。由此，根据Web应用的当前版本，找出两个页面之间的最短路径。假定在D和B之间存在两个新页面X、Y，则需要用DXYB将序列FID#18更新为“DXYBFA”。

·情形4。如果序列中的某些项目被合并为一个新的项目，则需要用新项目来更新相应的序列。例如，如果页面B和F被合并为页面P，则需要将序列FID#8、#13、#18分别更新为“P”、“AP”、以及“DPA”。

·情形5。如果序列中的一个项目在当前版本中被若干的新项目所取代，则在该序列中，用每个新项目来更新被取代的项目，从而生成若干个新序列，并且将相关会话划分为一些组，其中每个组可以以时间升序覆盖所有的新序列。例如，如果在当前版本中，页面F被页面F1、F2所取代。则上述表6可以被更新为以下的表7。

FID	频繁访问序列	出现次数	有关会话
				1	A	4	S1，S2，S3，S4
8.1	B F1	2	S1，S3
				8.2	B F2	2	S2，S4
13.1	A B F1	2	S1，S3
				13.2	A B F2	1	S2
18.1	D B F1A	1	S1
				18.2	D B F2A	1	S4

表7

现在返回图2，在模式分析阶段(步骤220)完成之后，根据本发明的所述方法进行到步骤230，执行生成测试用例阶段，用于根据所述有价值的用户访问模式并结合所述的会话信息和时间信息，设计新的测试用例。在此阶段中，需要将上述模式转换为用于访问页面及其链接的脚本。并且会话分布(会话-时间图)将被用于指引测试者于何时、何处、以及怎样运行这些脚本，从而生成最适当的性能测试用例。在具体介绍该阶段之前，假定在模式分析阶段(步骤220)完成之后，生成了针对目标Web应用的当前版本的最终的模式表，如以下表8所示。

FID	已更新的频繁访问序列	出现次数	有关会话
				1	A	4	S1，S2，S3，S4
8	B O F	4	S1，S2，S3，S4
				13	A B O F	3	S1，S2，S3
18.1	D1 B O F A	1	S1
				18.2	D2 B O F A	1	S4

表8

可以容易地看出，在表8中包含了上述的情形3和5。以下结合图5示出了步骤230的生成测试用例阶段的详细流程图。首先在步骤505，将不具有任何频繁访问序列的会话标记为“NOVALUE(无价值)”。在上述示例中，会话S5被标记为“NOVALUE”。接着在步骤510，在不是“NOVALUE”的会话中(在上述示例中为会话S1、S2、S3和S4)，从中移除旧版本中的不频繁项目(在上述示例中为C、E、G、H)，只保留频繁访问的项目，从而使得该序列更加便于重复使用。在步骤510之后，可以得到更新后的模式，如以下表9所示。

会话ID	开始时间戳的相对偏移量(秒)	会话持续时间(秒)	旧版本中的访问序列	已移除不频繁项目的访问序列
					S1	TS1	SD1	C，D，A，B，C，A，B，F，A，C，D，F	D，A，B，A，B，F，A，D，F
S2	TS2	SD2	A，B，F，E	A，B，F
					S3	TS3	SD3	A，B，F	A，B，F
S4	TS4	SD4	D，G，H，B，F，A，G，H	D，B，F，A

表9

接着在步骤515，用最终的模式来替换“已移除不频繁项目的访问序列”。具体而言，首先从具有最大长度的模式开始，将它们放入由“相关会话”所标识的相应会话中，例如，对于会话S1，序列“DBFA”将被替换为“D1 B O F A”，而对于会话S4，序列“DBFA”将被替换为“D2BO F A”；接着移动到具有较短长度的模式，将这些模式附加/插入到相应的会话中，并确保该操作能够使得序列遍历成功，例如将序列“ABF”替换为“ABOF”；以及，继续处理其余的模式，直到所有的模式都被插入到相应的会话中为止。

在此要注意，当序列中的两个页面之间不存在直接链接时，尽可能地在它们之间插入最短的路径。并且还要注意，在本发明的一个实施例中，结果得到的序列的长度应该大于初始序列的某个百分比，例如50％。该百分比可以由用户所定义，用于保证结果得到的序列中不会丢失太多页面/项目。如果经过上述操作所得到的序列少于该百分比，例如低于50％，则可以向结果序列中叠加频繁访问序列。

在步骤520，如果必要，添加用于新版本Web应用中存在的新组件和/或新特征的新的会话。具体而言，首先根据所述新组件和/或新特征的设计文档来设计访问序列。接着选取在步骤505中标记的一个“NOVALUE”会话，并且用所设计的访问序列来替换该“NOVALUE”会话的访问序列。如果不再存在“NOVALUE”会话，则在有效时间范围内以随机的开始时间戳来添加新会话，并且将新会话的会话持续时间的值设定为非“NOVALUE”会话的平均值。这样做是为了确保所生成的测试用例可以继续遵循原有的峰值时间的工作负荷以及工作负荷分布。

在步骤525，移除所有未使用的“NOVALUE”会话(如果存在的话)。在上述示例中，用于当前版本的Web应用的会话信息表可以如以下表10所示。注意，会话S5和S100是被设计用于新特征的新会话。

会话ID	开始时间戳的相对偏移量(秒)	会话持续时间(秒)	用于当前版本的访问序列
				S1	TS1	SD1	D1，B，O，F，A，B，O，F
S2	TS2	SD2	A，B，O，F
				S3	TS3	SD3	A，B，O，F
S4	TS4	SD4	D2，B，O，F，A
				S5	TS5	SD5	A，P，Q
S100	TS5	SD5	A，B，X，Y

表10

与数据准备阶段(步骤210)类似地，在步骤530，可以根据表10的会话信息表画出会话-时间示意图，其示出了针对Web应用的有用场景的整体视图。

这样，在步骤535，根据该会话-时间示意图，可以设计出针对Web应用的当前版本的测试用例。具体而言，对于每个会话，设计用于访问在访问序列中指定的页面的脚本，确保每个会话在其指定的会话持续时间内都是有效的；以及，在性能测试工具中根据会话的开始时间戳来分配会话。如果测试持续时间按比例增减，则根据比例因子重新计算开始时间戳和会话持续时间。例如，假定初始的日志数据是基于24小时的，而测试应该在12小时内完成，那么，测试者应该将开始时间戳和会话持续时间的初始值分别乘以比例因子50％。

参考图6更加清楚地示出了根据本发明的一个实施例的所述方法的实现流程。如图6所示，610是在数据准备阶段生成的针对Web应用的旧版本的会话-时间示意图，其中包含五个会话S1-S5，每个会话具有各自的开始时间戳、会话持续时间、访问序列。通过找到频繁使用序列，即，通过获取并提炼频繁使用序列，得到了620，即以上的表6。继续通过用已更新的特征来修改这些模式，得到了630，即以上的表8。在表8的基础上，通过重写并添加新的功能/特征而生成了针对Web应用的当前版本的新的会话-时间示意图(640)，其中S5和S100是用于新特征的新会话，S5占用了原有的“NOVALUE”会话S5，S100为新添加的会话。

在此还要说明的是，尽管在上述示例中使用了直观的会话-时间示意图，但是本领域技术人员可以容易地想到其它方式来体现会话与时间的对应关系，例如通过表格的形式或者通过对应关系列表的形式。这些或者其它的对应关系表示方式都落入本发明的范围中。

以上参考附图说明了根据本发明的一个实施例的一种为Web应用设计时间敏感的性能测试用例的方法。在同一发明构思下，还提出了根据本发明一个实施例的一种为Web应用设计时间敏感的性能测试用例的系统。

图7描述了根据本发明一个实施例的一种为Web应用设计时间敏感的性能测试用例的系统的示意性框图。如图7所示，所述系统包括数据准备装置710，用于生成所述Web应用的多个会话的会话信息以及时间信息；用户访问模式分析装置720，用于基于所述会话信息，获取每个会话的有价值的用户访问模式；以及测试用例生成装置730，用于根据所述有价值的用户访问模式并结合所述的会话信息和时间信息，设计新的测试用例。

具体而言，所述数据准备装置710包括：Web日志转换装置711，用于将所述Web应用的Web日志转换为特定数据格式；属性/字段提取装置712，用于提取必要的属性/字段，所述属性/字段包括以下：会话标识符、开始时间戳、会话持续时间、会话访问序列；时间戳转换装置713，用于将所述开始时间戳转换为相对格式；以及会话信息和时间信息生成装置714，用于生成每个会话的会话信息以及时间信息。所生成的会话信息以及时间信息可以是所述多个会话相对于时间的示意图。

所述用户访问模式分析装置720包括：频繁访问序列获取装置721，用于应用数据挖掘技术，通过定义一个阈值而从所述会话信息中获取有价值的用户访问模式，其中所述有价值的用户访问模式包括由终端用户执行的频繁访问序列；频繁访问序列提炼装置722，用于提炼所述频繁访问序列，以减少所述频繁访问序列的数量；频繁访问序列聚类装置723，用于对所述频繁访问序列进行聚类，以减少所述频繁访问序列的数量；以及频繁访问序列迁移和修改装置724，用于将所述频繁访问序列应用到所述Web应用的最新版本，根据该最新版本的信息，在所述频繁访问序列中的项目被删除、移动、合并或拆分时，修改所述频繁访问序列。其中频繁访问序列提炼装置722和频繁访问序列聚类装置723是可选组件。

所述测试用例生成装置730包括：现有会话处理装置731，用于将不具有任何频繁访问序列的会话标记为无价值会话，以及移除未使用的无价值会话；新会话处理装置732，用于响应于新版本Web应用中存在新组件和/或新特征，添加新的会话；频繁访问序列处理装置733，用于从所述访问序列中移除不频繁项目，以及用所述用户访问模式替换所述移除了不频繁项目的用户访问序列；会话信息和时间信息生成装置734，用于生成所述Web应用的多个会话的新的会话信息和时间信息；以及测试用例设计装置735，应用根据所述新的会话信息和时间信息，设计测试用例。

所述新会话处理装置732可以进一步包括：用于根据所述新组件和/或新特征来设计访问序列的装置；用于如果存在无价值会话，则用所设计的访问序列来替换所述无价值会话的访问序列的装置；以及用于如果不存在无价值会话，则在有效时间范围内以随机的开始时间添加所述新的会话，并且将所述新会话的会话持续时间的值设定为除了无价值会话之外的会话的平均值的装置。

以上详细描述了根据本发明一个实施例的一种用于为Web应用设计时间敏感的性能测试用例的方法和系统。如本领域普通技术人员可以了解的，本发明可以体现为方法、系统和/或计算机程序产品。因此，本发明可以呈现为完全硬件实施形式、完全软件实施形式或者软件和硬件组合实施形式。此外，本发明可以被呈现为在机器可读媒体上包括的计算机程序产品，机器可读媒体上存储了用于对计算机系统进行编程以执行根据本发明的过程的机器可执行程序指令。这里所使用的术语“机器可读媒体”包括向计算机系统提供用于执行的指令的任意媒体。这种媒体可以采用多种形式，包括但是不局限于：非易失性媒体、易失性媒体和传输媒体。非易失性媒体的常见形式例如包括软盘、软磁盘、硬盘、磁带或者任何其它磁媒体、光盘ROM(CD-ROM)或者任何其它光媒体、打孔卡或者任何其它带有孔图案的物理媒体、可编程ROM(PROM)、可擦写PROM(EPROM)、电EPROM(EEPROM)、闪速存储器、任何其它存储芯片或者盒式磁带(cartridge)、或者计算机系统可以读取并适合存储指令的任何其它媒体。

适于存储和/或执行程序代码的数据处理系统将包括：直接地或通过系统总线间接地耦合于存储器单元的至少一个处理器。存储器单元可以包括在程序代码的实际执行期间使用的局部存储器、海量存储装置、以及高速缓冲存储器，该高速缓冲存储器提供了至少某种程序代码的临时存储以便减少在执行期间必须从海量存储装置检索代码的次数。

此外，可以理解，方框图和/或流程图中的每个方框以及方框图和流程图中的一些方框的组合可以用一些计算机程序指令实现。这些计算机程序指令可以提供给一通用计算机、专用计算机或其它可编程数据处理设备的处理器以产生一机器，使得这些指令通过计算机或其它可编程数据处理设备的处理器的执行创建用于实现在方框图和/或流程图内或者方框内所指定的功能的装置。

尽管已经参考优选实施例具体地示出并描述了本发明，但其不是为了以公开的形式穷举或限制本发明。对于本领域的普通技术人员，可以在形式上和细节上进行各种改变而不会背离本发明的精神和范围。选择并描述了实施例是为了最好地解释本发明的原理和实际的应用，以及为了使本领域的其它普通技术人员能够理解对于各种实施例的本发明，所述实施例具有适合于预期的具体使用的各种修改。

Claims (20)

1.一种用于为Web应用设计时间敏感的性能测试用例的方法，所述方法包括：

生成所述Web应用的多个会话的会话信息以及时间信息；

基于所述会话信息，获取每个会话的有价值的用户访问模式；以及

根据所述有价值的用户访问模式并结合所述会话信息和时间信息，设计新的测试用例。

2.根据权利要求1所述的方法，其中所述生成所述Web应用的多个会话的会话信息以及时间信息的步骤进一步包括：

将所述Web应用的Web日志转换为特定数据格式；

提取必要的属性/字段，所述属性/字段包括以下：会话标识符、开始时间戳、会话持续时间、会话访问序列；

将所述开始时间戳转换为相对格式；以及

生成每个会话的会话信息以及时间信息。

3.根据权利要求1或2所述的方法，其中所生成的会话信息以及时间信息是所述多个会话相对于时间的示意图。

4.根据权利要求1所述的方法，其中所述基于所述会话信息，获取每个会话的有价值的用户访问模式的步骤包括：

应用数据挖掘技术，通过定义一个阈值而从所述会话信息中获取有价值的用户访问模式，其中所述有价值的用户访问模式包括由终端用户执行的频繁访问序列。

5.根据权利要求4所述的方法，进一步包括：

提炼所述频繁访问序列，以减少所述频繁访问序列的数量。

6.根据权利要求4所述的方法，进一步包括：

对所述频繁访问序列进行聚类，以减少所述频繁访问序列的数量。

7.根据权利要求4-6中任一项所述的方法，进一步包括：

将所述频繁访问序列应用到所述Web应用；以及

根据所述Web应用的信息，在所述频繁访问序列中的项目被删除、移动、合并或拆分时，修改所述频繁访问序列。

8.根据权利要求1所述的方法，其中所述根据所述有价值的用户访问模式，设计新的测试用例的步骤进一步包括：

将不具有任何频繁访问序列的会话标记为无价值会话；

从所述频繁访问序列中移除不频繁项目；

用所述用户访问模式替换所述移除了不频繁项目的频繁访问序列；

移除未使用的无价值会话；

生成所述Web应用的多个会话的新的会话信息和时间信息；以及

根据所述新的会话信息和时间信息，设计测试用例。

9.根据权利要求8所述的方法，进一步包括：

响应于所述Web应用中存在新组件和/或新特征，添加新的会话。

10.根据权利要求9所述的方法，其中所述添加新的会话的所述步骤包括：

根据所述新组件和/或新特征来设计访问序列；

如果存在无价值会话，则用所设计的访问序列来替换所述无价值会话的访问序列；以及

如果不存在无价值会话，则在有效时间范围内以随机的开始时间添加所述新的会话，并且将所述新会话的会话持续时间的值设定为除了无价值会话之外的会话的平均值。

11.一种用于为Web应用设计时间敏感的性能测试用例的系统，所述系统包括：

数据准备装置，用于生成所述Web应用的多个会话的会话信息以及时间信息；

用户访问模式分析装置，用于基于所述会话信息，获取每个会话的有价值的用户访问模式；以及

测试用例生成装置，用于根据所述有价值的用户访问模式并结合所述会话信息和时间信息，设计新的测试用例。

12.根据权利要求11所述的系统，其中所述数据准备装置进一步包括：

Web日志转换装置，用于将所述Web应用的Web日志转换为特定数据格式；

属性/字段提取装置，用于提取必要的属性/字段，所述属性/字段包括以下：会话标识符、开始时间戳、会话持续时间、会话访问序列；

时间戳转换装置，用于将所述开始时间戳转换为相对格式；以及

会话信息和时间信息生成装置，用于生成每个会话的会话信息以及时间信息。

13.根据权利要求11或12所述的系统，其中所生成的会话信息以及时间信息是所述多个会话相对于时间的示意图。

14.根据权利要求11所述的系统，其中所述用户访问模式分析装置进一步包括：

频繁访问序列获取装置，用于应用数据挖掘技术，通过定义一个阈值而从所述会话信息中获取有价值的用户访问模式，其中所述有价值的用户访问模式包括由终端用户执行的频繁访问序列。

15.根据权利要求14所述的系统，其中所述用户访问模式分析装置进一步包括：

频繁访问序列提炼装置，用于提炼所述频繁访问序列，以减少所述频繁访问序列的数量。

16.根据权利要求14所述的系统，其中所述用户访问模式分析装置进一步包括：

频繁访问序列聚类装置，用于对所述频繁访问序列进行聚类，以减少所述频繁访问序列的数量。

17.根据权利要求14-16中任一项所述的系统，其中所述用户访问模式分析装置进一步包括：

频繁访问序列迁移和修改装置，用于：

将所述频繁访问序列应用到所述Web应用；以及

根据所述Web应用的信息，在所述频繁访问序列中的项目被删除、移动、合并或拆分时，修改所述频繁访问序列。

18.根据权利要求11所述的系统，其中所述测试用例生成装置进一步包括：

现有会话处理装置，用于将不具有任何频繁访问序列的会话标记为无价值会话，以及移除未使用的无价值会话；

频繁访问序列处理装置，用于从所述频繁访问序列中移除不频繁项目，以及用所述用户访问模式替换所述移除了不频繁项目的频繁访问序列；

会话信息和时间信息生成装置，用于生成所述Web应用的多个会话的新的会话信息和时间信息；以及

测试用例设计装置，用于根据所述新的会话信息和时间信息，设计测试用例。

19.根据权利要求18所述的系统，其中所述测试用例生成装置进一步包括：

新会话处理装置，用于响应于所述Web应用中存在新组件和/或新特征，添加新的会话。

20.根据权利要求19所述的系统，其中所述新会话处理装置进一步包括：

用于根据所述新组件和/或新特征来设计访问序列的装置；

用于如果存在无价值会话，则用所设计的访问序列来替换所述无价值会话的访问序列的装置；以及

用于如果不存在无价值会话，则在有效时间范围内以随机的开始时间添加所述新的会话，并且将所述新会话的会话持续时间的值设定为除了无价值会话之外的会话的平均值的装置。

Images