无论测试什么系统,对于数据表的容量测试都是一个比较重要的环节,这里有两个需重点关注的点:
1、当单表的数据达到一定程度时,页面的加载时间是否能接受
2、当单表的数据达到一定程度时,涉及该表的相关功能是否正常
自己最近在做该方面测试的时候,发现了一个问题,问题如下:
问题描述:当班级表的记录数不小于6554条时,学生管理界面加载失败
提交该问题后,开发花了很久的时间,仍找不出代码里有任何问题后,回复“测试环境问题”,为了证实该问题不是测试环境所导致,自己就仔细的分析,设计相应的分析方案,如下:
1、由于该系统较简单,BS架构,因此初步判断问题可能出在以下两个方面,即IIS或数据库
2、分布排查
第一步:先检查是否是IIS问题:从问题环境中隔离出IIS(使之连接正常环境的数据库)进行测试一切正常,可以断定IIS并无问题
第二步:于是可以确定问题出在数据库部分了。数据库问题先从数据结构开始分析,与正常环境的数据库进行对比,正常
第三步:分析问题库与正常数据库差别,发现问题库存在大背景数据。应该是由此产生的问题。
第四步:锁定具体问题表。通过分析以及与开发人员讨论的方式,了解登录系统后页面马上加载两张数据库表。
第五步:尝试减少目标数据库表中数据,最终测试出班级表存在问题,并确定出异常数据量边界值。
问题原因:WCF的配置参数maxItemsInObjectGraph超过默认值65535导致
在用WebService序列化的过程中,序列化的对象个数超出了65535个,也就是maxItemsInObjectGraph的默认这,造成这用情况是因为客户端与WebService之间传递的是对象,而WebService每次都要序列化对象,所以对序列化的对象的个数是有限制的,默认的就是65535,这个对象的个数是怎么计算出来的呢?
例如:现在在WebService端有一个对象Student
Public class Student
{
Public int ID{get;set;}
public Name{get;set;}
}
在传递的过程中,对象的个数就是这个对象的本身加上本身所包含的对象的个数,就这个来说那么就是3个对象,要想使这三个对象能够序列化 maxItemsInObjectGraph=对象个数+2(假设maxItemsInObjectGraph默认值为0),只有在maxitemslnObjectGraph 比对象个数+2大的情况下,编译器才不会报错,要不然,就会出现上面的错误,其实还不止于此,这个的前提是只有一条记录的情况下,如果是两条记录呢,MaxItemSlnObjectGraph的最小值=对象个数*记录的条数(传递的可能是这个对象的一个集合)+2,也就是传递的数据越多,MaxItemSlnObjectGraph的值就会越大,当超过他的默认值(65535)的时候就会出现上面的错误
讲到这,解决方法也就简单了,修改MaxItemSlnObjectGraph的值