博客园_Carrie's Test Career

配置Jmeter的自定义参数

2011-04-07T02:29:00Z

User Defined Variables

在这个控件中，定义你所需要的参数，如

在对应的需要使用参数的位置，使用${host}替代。

应用场景：

当测试环境变化时，我们只需要修改一处的IP就可以让脚本马上应用于另外一个环境的测试，而不需要逐个脚本进行修改。

本文链接

报表系列之UI设计

2011-03-06T13:47:00Z

之前的文章讲述的都是如何测试报表的正确性。其实，除了报表的正确性，我们还需要关注报表的UI测试。所谓UI测试，并不单指根据UI标准对报表进行检查，还需要我们站在用户的角度去考量报表的易用性。

除了保证计算的正确性，我们还需要让报表变得更专业。变得专业，指报表应符合行业的标准，且考虑用户的使用，报表应变得更易懂，重点更突出。UI设计是变专业的关键。试想一下，如果一份报表字体不统一，大小不一致，颜色使用混乱，即使报表的计算值再具有参考价值，也无法让用户满意。因此，在设计和测试中，我们应该多重视UI。

1． 善用颜色

我在写平时的email或者交付测试报告的时候，经常被老板提醒颜色的使用。在同一个页面中，最好不要出现多于3种颜色。因为本来颜色的使用是为了突出重点，然而如果过多地使用颜色，就等于到处都是重点，最后的结果就是没有重点。因此善于使用颜色也是UI设计的关键。

¨ 使用颜色区分报表的类别

这样做是为了方便用户区分报表。例如，把红色加粗字体应用于销售类报表名，把蓝色加粗字体应用于出勤类报表。那么用户以后看见红色标题的页面就知道是销售类；蓝色标题的页面就知道是出勤类了。

¨ 应用颜色区分阈值数据

如，对于销售类报表，Manager们关心的是没有达到销售指标的区域。如果报表中对没有达到指标的数据均以红色字体呈现，那么Manager一打开页面一眼就可以从众多的数据中看到他最关心的部分，大大提高了阅读报表效率。

2． 统一格式

一般报表分为两大部分，表头(Head)和表体(Body)。表头，一般放置报表名称以及查询条件；表体，由表格形式的报表组成，可以为一个也可以为多个(子报表)。在统一格式方面，我们需要注意的地方有：

¨ 字体

不同的地方应使用不同的标准，如，表头中的报表名称，表体中的统计值的字体和大小应该不一样；然而不同的报表的报表名称应使用一种字体和大小。

¨ 表格

定义最小单元格，而报表中只能使用最小单元格的整数倍作为表格的大小。例如，UI标准定义最小单元格为(长X宽)=1cm X 0.5cm；如果遇到某单元格中需要填写的值长度为1.3cm时，此时对应单元格应该为2 cm X 0.5cm。这个有利于导出格式的一致性。

¨ 单位

不同的统计值使用的单位是不一样的。不管单位是什么，我们都应该放置于一个统一的地方。例如，可以统一标注在报表的某个地方，写着(Unit：￥)；或者是直接填入统计值中，如￥ 3.00。

¨ 术语

使用行业术语，增加报表的专业性。

3． 导出和打印格式

一般报表的使用者，会更多地应用导出功能导出成别的格式，或者是直接打印出来查看。此时，我们就需要检查报表导出后格式有没有变形。打印时，报表会不会因为分页打印而造成报表内容缺失，或者不易被查看。

本文链接

报表系列之权限控制

2011-03-06T13:35:00Z

报表系统的权限控制包含功能点和数据两方面的权限控制。功能点权限控制，是指登录用户对某一功能点有无访问权限的控制；数据权限控制，是指登录用户对数据的访问范围的控制。本文将对数据权限控制的测试进行详细的介绍。

首先，我们假设有销售业绩报表系统中预设有5个权限控制点：

n All ---- 可以查看所有数据

n Product Manager ---- 可以查看所管理产品的所有数据

n Center Manager ---- 可以查看所管辖区域的所有数据

n Team Lead ---- 可以查看所管理营业点的所有数据

n Sales ---- 可以查看自身的所有数据

其次，我们需要测试的其中一份报表是

产品	区域	营业点	Jan-11	Feb-11	Mar-11	Apr-11	Total
Iphone	大中华	中国大陆	10	10	10	10	40
		港澳	10	10	10	10	40
		Subtotal	20	20	20	20	80
	美洲	美国	15	15	15	15	60
		加拿大	15	15	15	15	60
		Subtotal	30	30	30	30	120
	Subtotal		50	50	50	50	200
Ipad	欧洲	英国	20	20	20	20	80
		法国	20	20	20	20	80
		Subtotal	40	40	40	40	160
	美洲	美国	25	25	25	25	100
		加拿大	25	25	25	25	100
		Subtotal	50	50	50	50	200
	Subtotal		90	90	90	90	360
Total			140	140	140	140	560

表1

我们在设计测试用例和设计测试数据时，可以考虑从以下切入点设计：

1． 权限控制点与报表筛选信息粒度一致

这种情况适用于测试All、Product Manager、Center Manager、Team Lead权限。在这种情况下，我们可以用筛选信息来检查数据权限的控制。

¨ 对于拥有All权限的用户而言，他所能查看的应该是全部数据组合起来的报表，如，表1

¨ 对于拥有Product Manager权限的用户而言，他的权限点与报表中筛选信息“产品”相重合，因此他能查看的是某一产品的数据组合，如，表1黄色区域

¨ 对于拥有Center Manger权限的用户而言，他的权限点与报表中筛选信息“区域”相重合，因此他能查看到的是某一区域的数据组合，如，表2

产品	区域	营业点	Jan-11	Feb-11	Mar-11	Apr-11	Total
Iphone	美洲	美国	15	15	15	15	60
		加拿大	15	15	15	15	60
		Subtotal	30	30	30	30	120
Ipad	美洲	美国	25	25	25	25	100
		加拿大	25	25	25	25	100
		Subtotal	50	50	50	50	200
Total			80	80	80	80	320

表2

¨ 对于拥有Team Lead权限的用户而言，他的权限点与报表中筛选信息“营业点”相重合，因此他能查看到的是某一营业点的数据组合，如，表2黄色区域

2． 权限控制点与报表筛选信息粒度不一致

这种情况适用于测试Sales权限。Sales权限比报表中最小粒度的“营业点”还要小。因此，在准备这个测试用例的数据时，我们需要为同一个营业点准备不同Sales的源数据，也需要为同一个Sales在不同营业点准备源数据。

对于以上两种情况，拥有Sales权限的不同用户，可能查看到以下几种报表

¨ Sales A，仅服务于一个产品一个营业点

产品	区域	营业点	Jan-11	Feb-11	Mar-11	Apr-11	Total
Iphone	美洲	美国	10	5	2	1	18

¨ Sales B，服务于一个产品的多个营业点

产品	区域	营业点	Jan-11	Feb-11	Mar-11	Apr-11	Total
Iphone	美洲	美国	3	4	0	2	9
		加拿大	0	5	4	3	12
		Total	3	9	4	5	21

¨ Sales C，服务于多个产品多个营业点

产品	区域	营业点	Jan-11	Feb-11	Mar-11	Apr-11	Total
Iphone	美洲	美国	0	1	2	1	4
		加拿大	0	0	6	3	9
		Subtotal	0	1	8	4	13
Ipad	美洲	美国	0	0	0	0	0
		加拿大	0	0.75	2.5	4	7.25
		Subtotal	0	0.75	2.5	4	7.25
Total			0	1.75	10.5	8	20.25

本文链接

报表测试系列之基于OLAP的报表测试

2011-03-05T14:01:00Z

在2月的最后一个星期，经历了半年的设计、开发、测试的报表系统进入了UAT阶段。我是这个基于OLAP技术报表系统的测试人员，从系统需求分析、设计，到后来的IT、ST，还有现在的PT，我都一直参与其中。这个报表测试系列的总结，也是这个项目触发而来的。

OLAP (On-Line Analysis Processing)，联机分析处理，是一种用于组织大型商务数据库和支持商务智能的技术。在参与这个项目之前，OLAP相关的维度(Dimension)、Cube、Measure等概念，我完全没有认识。而现在的我也只是知其皮毛，而这些也是在项目的过程中，一点一点积累和恶补回来的。因此，在本文中，我更多地是站在一个测试人员的角度，去看基于OLAP的报表系统的测试。其中涉及到一些专业技术，可能会有误解，还请各位读者指正。

1． 了解系统架构

根据黑盒测试方法的原则，不管报表系统内部采用的是什么技术，我们只需要定义好Input/Output就能测试出系统是否正确运行。然而，这对于基于OLAP技术开发的系统，远不足够。了解报表系统架构，是指我们需要去了解系统的组件、每个组件的职能、组件之间的联系、数据流的走向。当有了清晰明确的概念后，我们才可以明确测试用例需要涵盖的范围；当遇到Defect时，就更容易追踪问题的根源了。

系统架构一般在FS中有概述，在ADS中有详细描述。对于测试人员而言，除了认真阅读这些文档外，还要在ADS的Review Meeting中仔细地听，并多发问。请不要认为自己的问题对于设计人员而言是简单而没有意义的。相反，你的发问，可以使设计人员反复地去思考设计。他解释的过程，也是理顺思路的过程。经得起推敲的设计，才是合理的设计。

2． 维度缺失测试

基于OLAP技术的系统，一般包含有两大组件Data Ware和Cube。Data Ware就相当于一个数据仓库，用来储存生成报表的源数据；Cube就是那个多维度的数据集，我们可以把它想象成一个魔方，每一条棱都是一个维度，而中间的方格就是维度切片下的各个数据。那么让我们想象一下，如果魔方没有了棱会如何呢？这个就是我们这里所说的维度缺失测试。

维度缺失，指的是事实数据找不到与之对应的维度值。这也属于异常数据的一种。例如，Data Ware中有营业点A的销售数据，然而维度中却没有营业点A的定义，那么这条销售数据应该放置在Cube的哪个地方呢？是暂时不处理，等待维度补全后再重新填入Cube；还是使用推断成员的技术，自动补充缺失维度呢？这是设计时需要确定，也是测试时需要关注的问题。

3． 测试点的选取

产品	区域	营业	Jan-11	Feb-11	Mar-11	Apr-11	Total
Iphone	大中华	中国大陆	10	10	10	10	40
		港澳	10	10	10	10	40
		Subtotal	20	20	20	20	80
	美洲	美国	15	15	15	15	60
		加拿大	15	15	15	15	60
		Subtotal	30	30	30	30	120
	Subtotal		50	50	50	50	200
Ipad	欧洲	英国	20	20	20	20	80
		法国	20	20	20	20	80
		Subtotal	40	40	40	40	160
	美洲	美国	25	25	25	25	100
		加拿大	25	25	25	25	100
		Subtotal	50	50	50	50	200
	Subtotal		90	90	90	90	360
Total			140	140	140	140	560

基于OLAP技术的报表系统中，我们选取数据测试点的原则：

n 维度的统计值

原因在于报表中每一行所应用的Measure都是一样的，所以说只要一行中的一个算对了，整一行都会算对。如上表所示，底色为黄色的统计值我们都需要验证。

n Total值

Total值的测试主要是应用在统计值不是简单的求和的情况下。如，百分比，或者需要应用公式的统计值。这些Total值不是简单的将所有维度值进行相加，而是需要从源数据中重新抽取数据应用公式计算而来的。

本文链接

报表测试系列之测试数据的设计

2011-02-27T10:10:00Z

在报表测试用例设计中，测试数据是关键。正如Jackie在《进销存系统中的报表测试》中所言，如果希望更有效、更高质量地完成报表测试，就要重视并增加对于数据准备的关注。其实，测试数据也是为测试场景服务的，一个或者一组的测试数据往往是为了验证在某个测试场景下报表是否能正确的展现统计值。归根结底，测试场景的设计才是关键的关键。在之前的报表分析后，测试用例的基本框架已经完成。接下来我们需要在这个框架上，细化和补充场景设计，然后通过场景，设计出对应的测试数据。

对于测试数据的设计，我将其粗略地分为3大类：

1． 有效数据

有效数据，顾名思义，是指既符合前台业务规则，又符合统计规则的数据。它们会被统计进报表中，对报表的统计值会产生正面的影响。

2． 无效数据

无效数据，属于统计规则以外的数据。此类数据，符合前台业务规则，但不符合报表统计规则，即对报表的统计值不会产生任何影响。

3． 异常数据

异常数据，主要目的是用于检验报表系统对数据的容错能力。此类数据不符合前台业务规则，对报表的统计值会产生负面影响。最常见的场景是，统计值的分母为零。

这类数据的设计，更多地应用于报表系统与业务系统分离的情况中。当报表系统与业务系统互相统一时，异常数据会受到前台业务规则的限制，即异常数据连出现的可能也没有；在报表系统和业务系统分离的情况下，异常数据就很有可能由于数据传输的不同步，造成短时间的出现，此时报表系统对于错误的处理机制就显得非常重要了。

除了针对以上3类数据的设计以外，我们在设计报表测试数据时，还需要注意以下几点：

1． 保证场景间测试数据的独立性

这是为了保证数据可控而要注意的。如果同一条或者同一组测试数据被使用到多个报表统计值的检查中时，一旦出现测试结果与预期结果不一致，就会提高查错的难度。况且保证数据的独立，可以更好地阐述defect，保留defect现场，等待开发人员来解决。

2． 数据的多样性

多样性是指为场景而准备的多组测试数据。因为凭借不同数据才能更接近真实，更容易发现问题。此前我就碰到过类似的情况：在测试一份报表中，我发现同一个统计值，一月份的是正确的，三月份的却是错误的。正常情况下，使用同样的程序计算只有两种结果，要不两者都对，要不两者都错。怎么会出现一对一错呢？后来开发人员经过检查，发现还是计算程序中存在的问题。而出现一对一错是因为一月份与三月份的数据使用了不同组的测试数据，而正好一月份的数据，在错误的计算程序中也能计算出正确的值。由此说明，报表的测试是需要多组测试数据支持的，否则defect就会从我们眼皮底下溜走了。

3． 不要忘了空报表

所谓的空报表，就是指在报表查询条件下，没有相符的源数据，从而造成报表中的统计值为空。这样的测试，是为了确保报表的正确性，检查报表统计是否有张冠李戴的现象。

4． 注意数值的设计

这里所说的数值，是指统计值。例如，统计值是百分比时，我们需要覆盖最大值(100.00%)、最小值(0.00%)、中间值(如38.01%)、小数位检查(99.99%)。除了这些，我们还需要考虑负数、百分比超过100%、小数位的四舍五入等情况。

5． 不同报表间的对照

同一组数据在不同报表中的表现应该是一致的。例如，在销售总额报表中，营业点A的一月份总计是1万元；然而在营业点A的销售清单却只能查看到9000元的销售数据。那么，这意味着肯定是其中一份报表出现问题了。

6． 注意历史数据的设计

在基于OLAP技术设计的报表系统中，历史维度也属于测试的一个重点。历史维度的测试，涉及到历史数据的设计。例如，销售员A在2011年1月份，服务于营业点A，那么他的销售业绩就应该计算到营业点A中；然而到了2月份销售员A调到了营业点B，那么他2月份以后的销售业绩就应该计算到营业点B中。报表是否能正确地将销售员A在不同时间的销售业绩计算到对应的营业点中，就需要我们设计一批针对销售员A的销售源数据来检查。

7． 测试数据的备份

与一般的系统测试相同，报表的测试也需要经历多个版本。此外，报表测试数据的量很大，起码是业务测试数据的3倍以上。因此，数据的备份就非常必要了。我使用过数据库备份文件、SQL语句、CSV或excel格式3种方式来备份数据。通过比较，我推荐大家采用CSV或者excel格式来保存数据。因为在不同版本的测试中，我们很难避免数据库结构或者数据表字段的变化。如果采用数据库备份文件，一旦数据库发生了一点变化，就导致这个备份无法使用；SQL语句可以避免这样的问题，但保存在SQL语句中的测试数据不直观，且不方便修改。因此，CSV或excel格式使用起来更简单，而且很多数据库都提供批量导入CSV或者excel文件的功能。

本文链接

报表测试系列之报表分析

2011-02-26T08:46:00Z

正如Jackie在《进销存系统中的报表测试》中所言，在报表中，我们很难直观地通过某个数据项，看到它的算法和数据源。在报表测试用例设计中，第一步就是分析报表的数据源和算法。

不同业务报表之间的区别是很大的，特别是在不同行业之间。在分析报表前，首先，我们要提高对业务的熟悉程度。对于某些系统，如计费系统等统计精度较高的系统，我们甚至需要达到精通的程度。那么，是不是报表的分析就全无规律可循呢？不是的。下面将介绍我在分析报表时惯常使用的几个切入点，希望对大家有一定的启发。

1． 源数据的来源

源数据，即保存在报表数据库中的数据。源数据的来源，大致可分两大类：

A．由业务系统生成

报表数据库中的数据是由前台业务系统插入的。报表系统和业务系统是关联着的，甚至它们根本就在使用同一个数据库。如此一来，前台的操作即直接反应在报表的统计值上。在这种情况下，我们测试用例的设计，重点放在影响报表统计值的前台业务场景的设计上。

例如，某点播系统中的点播率报表，其报表统计值有效点播次数的源数据，就是点播业务所关联的点播数据库表。在测试用例设计中，我们重点考察不同场景的点播对报表统计值的影响。而场景的设计除了考虑前台业务规则外，更重要的是考虑报表的统计规则。如例子中，有效点播次数的统计规则是，视频购买后1分钟内的重复点播不计入有效点播次数中。这样一来，场景的设计就不能只是点播一次和点播多次这么简单。

B．来源于第三方数据库

有些报表系统与业务系统是分隔的，各自独立的。这样的设计，更多地出现在大型系统中。如此设计，既可以确保业务系统和报表系统各自的性能，又可以提高报表系统的扩展能力，即使用一个报表系统对不同业务系统的数据进行整合和分析。当然这个设计也有不足之处，即报表的实时性。

在这种情况下，测试用例设计的重点应该放在报表数据库源数据的设计上，重点考察第三方数据到报表数据库传递的正确性，源数据的完整性，以及不同业务源数据的相互影响。

2． 报表的算法

算法，是指源数据演变成统计值的过程。报表的算法应详细清晰地记录在Functional Specification中。根据算法的复杂程度，我将报表划分为三大类：

A．罗列式

罗列式报表是将源数据根据规则进行罗列，不涉及任何计算，如话费清单、销售清单等。对于此类报表，测试的重点在于：

· 罗列项的完整性，即FS中所规定的源数据的属性项是否列举完整；

· 列举数据的正确性和完整性；

· 数据属性变动对报表的影响，如，修改客户地址后，报表是否能正确地显示客户的最新地址；

B．统计式。

统计式报表是指，统计值是由单个源数据简单的加或平均得来的报表。此类报表，我们可以采用增量的方法来测试。

例如，前面所举的有效点播次数统计值。应用增量测试方法，就是在执行不同的场景后，检查报表的统计值是否在原来的基础上有对应的增减。

使用增量的方法来测试报表，既可以避免复杂的数据设计，又可以提高测试效率。但是增量测试方法的使用范围比较狭窄，对所测试的统计值要求不能太复杂。

C．算法式

算法式报表是指，统计值是由一个或多个源数据根据一定的公式得来的报表。此类报表中的统计值，涉及到多表数据，多业务流程，是报表测试的难点。

在设计此类报表的测试用例时，建议理清以下两点：

· 统计值所关联的源数据；

· 源数据关联的业务规则；特别注意，源数据受多个业务规则共同影响的情况。

在报表分析过程中，大家除了可以参考我上面的几个切入点外，还可以使用小组brainstorm的方式，来列出尽可能多的测试要点。然后再将要点梳理，这样，报表测试用例的基本框架也就形成了。框架形成后，接下来我们就需要基于框架对测试用例进行细化和补充。

本文链接

报表测试系列

2011-02-26T08:37:00Z

序言

报表功能的基本要求，是通过查询/统计/分析，来提供用户所需的准确数据。因此，在报表测试中，统计准确性测试是报表测试的关键。如果报表所呈现的数据是错误的，即使它制作得再精美，也失去了本来的意义。如何对报表的准确性进行测试，是本系列文章的主旨。

在此特别感谢，Jackie陈雷不断督促我做总结分析，并且给予我很多启发；Echo嘉宇帮我润色语句，增加可读性。

正文

6．报表系列之性能测试

Jmeter Debug - "Unrecognized VM option '+HeapDumpOnOutOfMemoryError"

2010-06-04T07:07:00Z

今天，老板在用Jmeter2.3.4的时候，启动Jmeter.bat的程序时，出现以下出错信息：

Unrecognized VM option '+HeapDumpOnOutOfMemoryError'

Could not create the Java virtual machine.

errorlevel=1

请按任意键继续. . .

上网查了一下，可以用以下方法解决：

编辑jmeter.bat文件，将set DUMP=-XX:+HeapDumpOnOutOfMemoryError注释掉。

另外，还查了一下原因。

是因为老板机器用的是1.5的jdk环境，网上的大牛们说：

Well, this is an unexpected one. Apparently the HeapDumpOnOutOfMemoryError option was added in JDK 1.6, and then back-ported into 1.4.2_12, 1.5.0_07. We'll document this, and discuss what to do to fix it.

所以呢，还有一个方法是可以解决的，就是升级你的jdk环境到1.6罗。

本文链接

浅谈性能测试数据(Data Environment)的设计

2010-05-31T14:21:00Z

在写这篇文章之前，我google了一下“性能测试数据”，发现不同的文章对于性能测试数据的定位是不一样的。所以，我觉得有必要先定位一下我这里讲的性能测试数据。性能测试数据，指的是性能测试场景执行时的基础数据；就是性能测试环境的Data Environment。Data Environment准备的必要性是不言而喻的。就好像，需要你从10颗绿豆和从10万颗绿豆中找出之前放入的一颗红豆一样，哪一种情况更能体现你的聪明才智呢？所以，软件性能测试应该在一定数据量的数据库上进行，这样才能真实地体现软件性能。

那么怎么样的Data Evnironment才算是合理的呢？答案当然是来自生产环境的数据最好，因为这些数据都是真实的。然而，很多的性能测试是很难得到真实生产环境的数据的，因为在做性能测试的时候，系统还没有上线，何来的数据呢？因此，如何能设计出较为接近生产环境的数据就是我们讨论的重点了。

1.确定数据类型

根据不同的系统，测试数据可以大致分为以下3大类：

A.基础数据

这类数据指的是整个被测系统业务的基础数据。例如，计费系统中的customer数据；Call center系统中的Agent数据等。

这一类的数据的特点，是所有数据的基础；且这些数据量相对固定，或者变化不大（当然是在不扩容的前提下，一般扩容都是由于数据量达到一定程度后或者业务量的增长，致使系统也要随之升级）。

B.业务数据

这类数据是根据被测系统的业务，由基础数据衍生出来的。例如，计费系统中，customer的购买记录，账单记录；Call Center系统中的通话记录，生成的合同数；还有数字电视系统中的，节目单数据，点播影片数，以及各种点播记录等。

这类数据的特点是，跟基础数据关联，是被测系统的核心数据，体现业务，且会随着被测系统上线时间线性增长或指数型增长。

C.历史数据

这类数据指的是，过期的业务数据或者是有一些系统对于用户操作需要进行严格的跟踪，因此部分的基础数据或者业务数据的修改历史会保留在数据库中，方便翻查。例如，customer基本信息修改，customer的购买记录，历史订单等。

这类数据的特点是，虽然不会显示在UI上，然而会对查询功能有性能的影响。

2.确定数据量

一般地说，数据量是不会在Functional Spec里面直接给出。在Functional Spec里面只会是客户或者市场人员对整个被测系统业务增长量的一个预测。

例如，我最近计算了Call Center性能测试数据，Functional Spec里面会给出上线时Agent的数量，一般情况下的接call的频率，customer数量的增长率等。这样，我们根据customer的增长率来计算出来未来两年的customer的数据量；利用Agent数量，在平均负载的接call频率，次峰值以1.5倍计算，高峰值以2倍计算，来计算出每日通话记录数量的增长，从而计算出两年后通话记录数的数据量。

另外，并不是所有的Functional Spec都会对被测系统业务量进行一个详细的描述。这个时候就需要Tester具有业务的洞察力，大胆假设，小心求证；建议作为Tester的你，可以先根据自己对业务的了解，确定每项数据的算法，再大胆假设基础数据量，形成了一份完整的设计文档后，提交给Manager，或者直接召集相关人员来一起对你所做的大胆假设进行小心求证。[PS:这些数据量确定后，最好经过Manager，市场人员，甚至是客户的Review，并达成共识。]

3.梳理数据关系

这个是整套数据的关键。我们需要把基础数据与业务数据一一关联起来。

举个例子吧，假设被测系统是一个订购系统，一个customer应该关联多少个历史修改记录，关联多少条通话记录，一个月生成多少张订单。还有多少个customer应该有订单记录，多少个customer没有订单记录等等。这些数据的设计都会牵扯到未来做性能测试场景时，系统是从多少个记录中查询出一个customer，查询某个customer当月账单时返回多少条记录，这个也是对被测系统性能的一个很好的衡量标准。

4.优化数据结构

这个主要是针对查询操作所进行的数据优化。例如，我们需要测试某个客户，查询某一段时间内的订单的性能。此时，我们就必须对订单表中，订单所属客户，订单生成时间进行随机的或者是遵循一定规律的分布，这样可以有效避免有些客户查询结果为空，有些客户查询结果为上万条，从而造成无法很好的衡量被测系统的性能。

以上就是我在做性能测试数据设计时的一些总结。虽然它可能无法涵盖测试数据设计的方方面面，但是我觉得它也能提供一种思考的方向。其实针对不同的被测系统我们需要考虑的数据或者是数据设计的侧重点都是不一样的。例如，在数字电视系统性能测试数据的设计中，基础数据除了客户数据外，还需要考虑一些业务上面的基础数据，例如节目单，电影数据等；在设计数据关系时，重点在于设计客户不同类型订购产品的比例，从而确定当月订单的记录数等。所以，我认为能够设计出好的性能测试数据关键还是对被测系统业务的熟悉。

本文链接

浅谈用于生成performance测试数据的sql脚本的效率问题

2010-05-26T09:13:00Z

场景：

最近正在做一个performance测试，在测试中，我必须准备大量的客户数据，以及与客户数据相关地合同数据，联系记录数据等。

客户数据为90万，合同数据达40万，联系记录数据达千万，还有一些跟踪数据达百万。

面对这样数量级的测试数据，相信大家跟我一样都会不约而同地想到使用sql语句来实现。

于是，在搞清楚数据关系之后，我开始动手写我的sql了。

为了使添加的数据更加接近真实的场景，我以客户作为起点，在添加客户后为此客户添加与之相关的合同数据，以及联系记录数据等。终于，经过连日的奋战（呵呵，可能开发人员只需要连小时地奋战），我终于把我的sql脚本写完了，并在上周五下班前kick start了脚本，大安旨意（翻译：本以为）可以在本周一看到数据生成完毕的我，却发现脚本居然还没有运行完，而且也才完成了目标的20%不到。

于是，开发人员就一同过来会诊我的脚本，发现症结如下：

1.使用太多的循环，且循环中嵌套循环；这样可以使数据关系非常清晰，但是其中使用的游标太多会严重减低数据插入的效率的。

建议，如果游标>1000的话，就不要使用循环的方式了。

2.每insert一句就commit一次，降低了运行的效率

得到了症结，当然是出解决方案啦。

1.去掉循环，使用插入数据集(dataset)的方法。

例如，有基础表TableA，其中有字段AA,AB,AC

待插入数据的表TableB，需要插入字段BA,BB,BC，且BA是可以使用表A的字段AA作为数据集的。

此时我们可以使用一下语句：

***************************

insert into TableB （BA,BB,BC）

select AA,'1','0' from TableA

***************************

如果TableA数据是，

AA,AB,AC

1,A,A

2,B,B

3,C,C

那么执行完语句后，TableB的数据是

BA,BB,CC

1,1,0

2,1,0

3,1,0

2.在使用where语句时，进行使用自增长位作为查询条件

例如：在TableA中AA项为自增长项，这样数据库本身已经对它建有index。使用它作为查询条件就会比使用AB,AC项更加快。

还有，在为AA项限制条件时，不要使用like ‘%1’这些后匹配方式；尽量使用between ... and ...或者< >的匹配方式

3.如果无法去掉的循环，都要尽量减少循环中的游标，不要循环中嵌套循环

例如，对于一些基础表，如TableA，需要添加90万的数据量。就只是使用一个游标进行循环插入，且循环中执行的语句也只是insert数据的语句，不要掺杂其他复杂的运算或者再嵌套循环

根据开发人员的建议，我重新修改了sql，将中间的循环去掉，尽量多地使用数据集的方式来插入数据。

sql生成数据的效率得到了飞速地提高，原先2天无法加完的数据，一个晚上就搞掂了。

效率是提高了，但是数据中的内容就会变得相对集中，例如有10几万的数据都是同一时刻，同一个操作用户生成的。这样的话，对于一些查询就非常不利了。因为有可能一次需要查询出几十万的数据，这样是也不符合现实情况。

于是，对于这种情况，我们需要针对不同的场景，对数据进行微调。例如使用循环，将数据的udpatetime，或者updateguy进行随机更新。

这样就又保证了数据量，也保证了数据的真实性。

本文链接