单元测试中常用的测试模式

单元测试跟软件设计一样，有一些常用的模式，这篇文章是介绍一些常用的模式，其中的示例是C#代码，都比较简单，我想大家都能看懂。下面进入正题：

　　1、准备，执行，断言(Arrange， Act， Assert)。这种模式是非常常见的，套用这种模式进行单元测试通常的做法如下：

　　1）准备测试环境，测试数据等

　　2）执行被测试方法

　　3）用断言来验证执行结果

　　下面是一段测试代码，被测方法的功能是把字符串中每个单词的首字母转为大写，特殊字符用下划线替代。

[TestMethod()]

public void CapitalizeTest()

{

//准备数据

string input = "hello world!";

string expected = "HelloWorld_";

//执行测试

string actual;

actual = TextHelper.Capitalize(input);

//验证结果

Assert.AreEqual(expected, actual);

}

　　2、构造函数测试。这种模式适合对类中某些特殊的属性进行测试，被测的属性都有一个特点–它们都是不变量；例如数组的初始化以后，其容量是不会变化的，无论这个数组对象被什么样的外部方法调用。一般的做法如下：

　　1）创建一个实例

　　2）对该实例进行外部调用

　　3）用断言来验证执行结果

　　下面是一段代码；首先创建一个数组，然后使用该数组，最后验证该数组的大小有没有变化。

[TestMethod]

public void TestInvariant()

{

//创建一个实例

int capacity = 5;

int[] intArray = new int[capacity];

//进行调用

for (int i = 0; i < intArray.Length; i++)

{

intArray.SetValue(i, i);

}

//验证结果

Assert.AreEqual(capacity, intArray.Length);

}

　　3、反向关联(Roundtrip)。这种模式适合于被测方法有一个可逆方法的情况下使用。它的数学证明是：f-1(f(x)) = x

　　下面是一段示例代码：

[TestMethod]

public void RoundTripTest()

{

string str = "10";

//把字符串转换为整数，然后再转换为字符串

int i = Int32.Parse(str);

string finalString = i.ToString();

//验证结果

Assert.AreEqual(str, finalString);

}

　4、经过处理的反向关联(Sanitized Roundtrip)。上面说的反向关联有一个缺点，就是如果输入的字符串为” 10″，那么就有点问题了，因为整数10转换为字符串是不会转换为” 10″的，这个模式的数学证明是：f-1(f(f-1(x)))=f-1(x)

　　以下示例可以看做是上一段代码的加强版。

[TestMethod]

public void SanitizedRoundTripTest()

{

string str = " 10 ";

//先把字符串转换为整数，然后把整数转换为字符串，最后把字符串转换为整数

int i = Int32.Parse(str);

string intermediate = i.ToString();

int roundtripped = Int32.Parse(intermediate);

//验证结果

Assert.AreEqual(i, roundtripped);

}

　　5、状态关联。这种模式很常见，就是对

于调用某个类的方法，会改变这个类内部的状态，而这个改变可以用其他方法来间接地验证。

　　一段对列表进行简单测试的代码：

[TestMethod]

public void InsertContains()

{

string input = "some string";

List list = new List();

list.Add(input);

Assert.IsTrue(list.Contains(input));

list.Remove(input);

Assert.IsFalse(list.Contains(input));

}

　　6、异常允许。如果需要测试异常是否在适当的时候抛出的时候，应该应用该模式。

[TestMethod,ExpectedException(typeof(IndexOutOfRangeException))]

public void ExpectedException()

{

//创建一个长度为5的数组

int[] array = new int[5];

//尝试给该数组的第六位赋值，应该抛出IndexOutOfRangeException异常

array[6] = 1;

}

　　以上六种模式是单元测试中比较常见的，但并不是单元测试的全部。了解这些模式，对于平时的工作是很有帮助的。

性能测试分析方法1/135

jyqcpu 旺旺在线店铺

发表于 2010-10-28 19:00 jyqcpu 旺旺在线店铺

等级: 初学乍练 积分: 54 威望: 0 TA的帮派>>

主帖数: 1 精华数: 0 TA的主帖>>

同一场景

1.小用户量的情况下测试

2.大用户量情况下的测试

分析的方法：

整个系统架构分析，系统响应时间消耗，利用图表分析

查看事务响应时间，通过事务摘要图分析事务响应时间，那个消耗最大（通过小用户量和大用户量的响应时间分析，查看那个事务响应时间最高），确定哪部分功能是性能的瓶颈，分析window resource图表，查看cpu

使用下列计数器标识cpu瓶颈

Processor\\ Interrupts/sec

Processor\\ % Processor Time

Process(process)\\ % Processor Time

System\\ Processor Queue Length

通过它来确定是否硬件本身出现瓶颈，或者进一步确定应该怎么去判断性能产生瓶颈的地方！

下一步去判断进程，那个进程消耗cpu最高

下边就有很多种情况需要你自己去判断，有可能是进程调用了的函数消耗了系统资源形成上边的问题，也有可能是后台数据库出现的问题（这个就要看你的系统配置是什么样的，比如你的db服务器和应用服务器都配置在一台机器上）

性能产生瓶颈有很多地方，所以需要进一判断，是否是后台数据库的问题还有待分析，是那条语句导致的问题需要进一步分析判断。

分析原则：

? 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

? 查找瓶颈时按以下顺序，由易到难。

服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

注：以上过程并不是每个分析

中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

? 分段排除法 很有效

分析的信息来源：

?1 根据场景运行过程中的错误提示信息

?2 根据测试结果收集到的监控指标数据

一．错误提示分析

分析实例：

1 ?Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection

?Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely

分析：

?A、应用服务死掉。

（小用户时：程序上的问题。程序上处理数据库的问题）

?B、应用服务没有死

（应用服务参数设置问题）

例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的 AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％

?C、数据库的连接

(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)

2 Error: Page download timeout (120 seconds) has expired

分析：可能是以下原因造成

?A、应用服务参数设置太大导致服务器的瓶颈

?B、页面中图片太多

?C、在程序处理表的时候检查字段太大多

二．监控指标数据分析

1．最大并发用户数：

应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。

在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。

如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2．业务操作响应时间：

? 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。

? 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？

? 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

3．服务器资源监控指标：

内存：

1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值

偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

2 Windows资源监控中，如果Process\\Private Bytes计数器和Process\\Working Set计数器的值在长时间内持续升高，同时Memory\\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆:

很高的换页率(high pageout rate);

进程进入不活动状态;

交换区所有磁盘的活动次数可高;

可高的全局系统CPU利用率;

内存不够出错(out of memory errors)

处理器：

1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%

合理使用的范围在60%至70%。

2 Windows资源监控中，如果System\\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆:

很慢的响应时间(slow response time)

CPU空闲时间为零(zero percent idle CPU)

过高的用户占用CPU时间(high percent user CPU)

过高的系统占用CPU时间(high percent system CPU)

长时间的有很长的运行进程队列(large run queue size sustained over time)

磁盘I/O：

1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。

2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O 资源成为系统性能的瓶颈的征兆 :

过高的磁盘利用率(high disk utilization)

太长的磁盘等待队列(large disk queue length)

等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)

太高的物理I/O速率:large physical I/O rate(not sufficient in itself)

过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))

太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

4．数据库服务器：

SQL Server数据库：

1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。

2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。

3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。

4 Lock Requests/sec(锁请求/秒)，通过优化

查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：

1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。

快存（共享SQL区）和数据字典快存的命中率：

select(sum(pins-reloads))/sum(pins) from v$librarycache;

select(sum(gets-getmisses))/sum(gets) from v$rowcache;

自由内存： select * from v$sgastat where name=’free memory’;

2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。

缓冲区高速缓存命中率：

select name,value from v$sysstat where name in ('db block gets’,

'consistent gets','physical reads') ;

Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))

3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。

日志缓冲区的申请情况 ：

select name,value from v$sysstat where name = 'redo log space requests' ;

4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。

内存排序命中率 ：

select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)'