创建多个应用程序池虽然好处多多，不过却增大了调试的难度。假如一台服务器上有5个站点，那么正常运行的情况下就会有5个w3wp.exe进程，要找到合适的进程进行调试就是一个问题，以前比较笨，就看哪个进程的ID比较小，或者哪个进程占用的内存较多来“判断”，今天发现其实微软有一个非常靠谱的方法。

1. 打开一个命令行窗口

2. 浏览到“Windows > System32”

3. 运行“cscript iisapp.vbs”

得到如图结果，哪个应用程序池对应哪个W3WP.EXE一目了然，从此告别瞎猜

No related posts.

为什么用Python？一位大师曾经说过，程序员要每6个月就要学习一门新的语言（这个要求还真苛刻），所以决定学习一下Python。

需求：其实这个需求特别简单
1. 发送HTTP请求，Python自带的httplib库就能满足这个需求了
2. 多线程访问不同的站点，现在MySpace常用站点至少有4个
3. 指定服务器的IP，因为测试的服务器也有多台
4. 获取HTTP请求的状态
5. 需要在登录状态下进行预热

这个方法做了大部分的事情，Http请求，带登录状态的，能够指定IP的，指定站点的，指定页面的

1
2
3
4
5
6
7
8
9

def warmwww(inputServer,inputHost,inputPage):
	conn = httplib.HTTPConnection(inputServer)
	headers = {"Host":inputHost,"Cookie": "MYUSERINFO=MIIxxx%3d"}
	conn.request("GET", inputPage,"",headers)
	r1 = conn.getresponse()
	data = r1.read()
	conn.close()
	global results
	results.append((inputHost,r1.status))

主要用到了httplib.HTTPConnection类，获得一个httplib.HTTPConnection的对象；登录就是在Headers里面加一个标志登录的Cookie；由于要支持多个服务器，所以在初始化httplib.HTTPConnection对象的时候，指定的是IP，然后在Headers里面的Host中指定需要预热的站点；最后GET某个站点下的某个页面作为预热；最后获取response的状态码。这里需要import httplib。

接下来要做的就是用多进程来访问需要预热的站点

1
2
3
4
5
6
7
8
9
10
11

def run(server,paras):
	threadcount = 0;
	threadList = []
	for pa in paras:
		rm = threading.Thread(target = warmwww, args=(server,pa[0],pa[1]))
		rm.start()
		threadList.append(rm);
	for rt in threadList:
		rt.join()
		threadcount = threadcount + 1
	print threadcount,"Threads started. Run on server", server

threading.Thread()可以实例化一个Thread对象，参数target就是需要运行的方法，在Python里面，方法也是一个对象；如果target是带有参数的，那么就要通过args把参数传递进去。这里需要import threading。

1
2
3
4
5
6
7
8
9
10
11
12

if __name__ == "__main__":
	successFlag = True;
	begintime = time.time()
	run(server,paras)
	endtime = time.time()
	print "Finish the task in", endtime-begintime, "seconds"
	for sr in results:
		if(sr[1]!=200):
			print "Warm up",sr[0], "failed.", "status code:",sr[1]
			successFlag = False
	if successFlag:
		print "all warm up script run successfully."

paras是一个预先定义好的列表。results是一个全局变量，每个预热的结果都会存到results中，等预热程序执行完毕以后，检查其返回的状态码，如果等于200，就算通过；否则，就认为预热失败，并且打印出返回状态码。

经常会看有有人在论坛上提问，例如如何在XXX工具中发送带有cookie的请求，如果在YYY工具中模拟已经登录的用户做操作。其实这当中最根本的问题应该是，登录的原理是什么，知道这个原理以后，就很容易找到实现的方法，不管用的是C#还是Python。工具是手段，原理是根本。

Related posts:

1. 在C#单元测试中使用HttpContext的简单解决办法

设想如下场景，测试人员介入到项目的需求，分析，设计的阶段，得到了很多有用的文档和信息。接下来就到了编码的阶段，在这个时候测试工程师开始根据前面获得的信息来设计测试用例，做用例评审，力求测试用例覆盖能覆盖系统的每一个角落。不幸的是，系统实在是太大，没有人能确切地知道手上的测试用例对系统的覆盖（这里指定为代码的行覆盖）能达到什么样的程度。对于系统的关键部分，没有人希望在经过几轮测试以后，还有相当部分的代码是没有被执行过的。

解决这个问题的其中一个方法，就是对关键部分的代码进行代码覆盖率的统计。平时我做单元测试和接口测试的时候，得益于IDE的帮助，代码覆盖率信息很容易就能得到，但是对于部署在IIS上的ASP.NET代码，又如何去收集代码覆盖率信息呢？曾经找过好多.NET的代码覆盖率工具，没有合适的。不过就在最近，让我发现了VSPerfMon，VSTS自带的性能数据收集工具。真是众里寻他千百度，蓦然回首，那工具却在灯火阑珊处。

1. 首先要对需要进行代码覆盖率信息收集的二进制文件(DLL, EXE)用VSInstr进行处理，记得带上/COVERAGE参数

VSInstr “D:\Websites\somewhere\bin\MySpace.Web.UserHome.dll” /COVERAGE

2. 停掉IIS

iisreset /stop

3. 用VSPerfClrEnv 设置相关的环境变量

VSPerfClrEnv /globaltraceon

4. 启动VSPerfMon；参数/COVERAGE代表本次监控收集的数据是代码覆盖率；/user:”NETWORK SERVICE”，指定用户名;/CS 启用跨域会话分析；/output:”d:\magus\0422.coverage”，指定输出文件的名字和路径，记得用.coverage作为扩展名。

VSPerfMon /COVERAGE /user:”NETWORK SERVICE” /CS /output:”d:\magus\0422.coverage”

在运行完上面这条命令以后，CMD窗口就提示：

Started in Stand Alone Mode
Filename: d:\magus\0422.coverage

这时候需要打开一个新的CMD进行余下的操作(原来的CMD就叫CMD_A，新开的就叫CMD_B吧)

5. 停止收集代码覆盖率信息数据，因为不想让代码覆盖率信息受到影响。

VSPerfCmd /globaloff

6. 启动IIS

iisreset /start

7. 对ASP.NET程序进行预热

8. 重新开启代码覆盖率信息的收集

VSPerfCmd /globalon

9. 运行测试用例，手工OR自动都可以

10. 停止代码覆盖率信息的收集

VSPerfCmd /globaloff

11. 停止IIS

iisreset /stop

这时候在CMD_A中会提示“UnRegistering process (7784)”，还是保持CMD_A不动，继续操作CMD_B

12. 结束代码覆盖率的收集，并且生成.coverage文件

VSPerfCmd /shutdown

这时候在原来的CMD_A中就会出现如下信息：

Shutting Down Named Pipe Server
Shutting Down Buffer Writer
Shutting Down Process Deamon

如果没有看到错误提示信息，那么本次代码覆盖率收集就应该成功了。

13. 在VSTS IDE中打开刚才生成的.coverage查看代码覆盖率。

如图：

正如以前讨论过的，100%的代码覆盖率是不够的，那么我们在拿到代码覆盖率数据以后，应该看一下在运行完测试用例以后以后，系统的哪些代码还没有被执行过，然后回头设计一些新的测试用例来测试那些未被测试的代码。这就要求测试工程师要能看懂代码了。

本文思路得益于大半年前看到这篇博客“如何引入代码覆盖率度量提高测试质量”，一直惦记于心，终于找到了适用于.NET程序的解决方法了，呵呵。

Related posts:

1. VSTS性能分析工具Profiler的介绍
2. 用VSTS Profiler发现性能问题并且进行优化实例
3. 调试部署在IIS上的ASP.NET程序实用小技巧

由于ASP.NET程序运行在一个硕大的框架上，所以一般用Sample模式收集到的数据，对发现性能问题帮助不大，以下是一个用Sample模式收集的结果：

从这个报告中我们可以看到，前5个工作量最大的函数和执行单独工作最多的函数都是系统函数。

下面看一下有针对性地用检测模式收集的数据：

本文就采用“检测”模式收集性能数据来进行分析和处理。

首先，把本次测试的目标DLL用VSInstr工具进行处理，使得Profiler能够收集相关的性能数据，这一个步骤非常关键，通常来说不需要设置额外的参数，就是默认的方式就可以了，例如：VSInstr “D:\Websites\xxxx\bin\xxxx.dll”，在处理的过程中可能会提示一些错误，具体错误的信息可以在这里查找。把相应的DLL处理完毕以后，就在命令行输入以下指令（命令行的指令用斜体加下划线表示；说明文字加黑）

停止IIS

iisreset /stop

设置分析.NET应用程序所需要的环境变量，在运行完这个命令以后需要重启。由于使用检测方式进行数据采集，所以这里我用globaltraceon参数。

VSPerfClrEnv /globaltraceon

启动性能数据收集。/start:trace，告诉收集器要收集检测数据；/user:”NETWORK SERVICE” ，由于是要对IIS进行的数据进行采集，所以需要制定用户NETWORK SERVICE；/CS，启用跨进程分析，看了一些文章说是分析ASP.NET程序一般都把这个选项打开，原因不详；/output:”d:\magus\0422.vsp”，指定输出文件的路径和名称；/wincounter:”\Processor(_Total)\% Processor Time”，收集处理器的参数，这里需要注意的是，wincouter后面的性能计数器名字一定要是全名，有一个方法可以查询系统的性能计数器的全称，就是用VSTS的Server Explorer，然后找到相应的服务器(一般是本机)，下面有一个“Performance Counters”；如果要收集多个性能计数器的数据，只需要多加几个 /wincounter 参数即可，例如我在收集处理器时间的同时，还想知道Context Switcher每秒的数据。

VSPerfCmd /start:trace /user:”NETWORK SERVICE” /CS /output:”d:\magus\0422.vsp” /wincounter:”\Processor(_Total)\% Processor Time” /wincounter:”\System\Context Switches/sec”

在IIS起来之前先停止性能数据的收集

VSPerfCmd /globaloff

启动IIS

iisreset /start

对程序进行预热，这一步也是很关键，因为IIS启动以后，程序需要预热才能达到稳定的状态，因为程序首次被访问的时候有些代码会被编译，所以为了降低对性能测试的影响，应该现对被测的程序进行预热。在预热完毕以后重新启动性能数据的收集。

VSPerfCmd /globalon

– 运行性能测试场景 –

测试运行完毕以后，停止性能数据的收集

VSPerfCmd /globaloff

停掉IIS

iisreset /stop

关闭性能数据收集器，这一步完成以后就能生成包含数据的文件了

VSPerfCmd /shutdown

首先来看看收集到的报告

在这个方法里面有一段不知名方法（其实是因为没有相应的Symbol，⊙﹏⊙b汗）占用了大量的计算时间，然后就找到相应的代码，原来该不知名方法是一个动态生成的代码，该段代码大概就是会创建一个新的Client对象，然后向另外一台服务器发起一个请求。其实不用每次调用该方法都创建一个新的Client对象。然后我尝试着把这个Client改为静态变量，经过优化以后的报告对比如下：

效果还是挺明显的，但是当我重新测试一下性能的时候，被打击了一下，改动前后的性能对比相差很小，小的都可以认为是误差：P，因为在一个颇为庞大的项目中，这点小小的改动的确不可能影响大局。不过这次试验让我学会了用Profiler来找到ASP.NET运行中执行较慢的语句，并且看看这些语句有什么问题（可能是一个调用存储过程的方法很慢，而真正的原因是数据库有问题），定位问题所在，然后解决问题，最后回测一下对比改动前后的结果。看是否达到预期的优化效果。

Related posts:

1. VSTS性能分析工具Profiler的介绍
2. 用VSPerfMon在测试ASP.NET程序的过程中收集代码覆盖率信息
3. Linux下的snmpd.conf配置说明

在VSTS的Profiler中，有两种(VSTS2010好像有5种了)Profiling的方法，第一种是采样(Sampling)，第二种是检测(Instrumentation)。对于采样模式，它的工作原理是Profiler定期中断CPU并且收集函数的调用堆栈信息。在网上找到一个图，对于采样工作方式的描述非常清晰：

对于检测模式，他的工作原理是用VSInstr程序在原始的代码中插入一些用于计算时间的代码，例如A函数调用B函数，那么在调用B函数的前后都会被插入用于计算时间的代码，具体可以看下图：

下面我自己写了一个小的Sample类，然后把编译好的代码用Reflector来查看，很容易地就能看出区别。第一个图是没有经过VSInstr处理的原始代码：

下图就是经过VSInstr处理后，反编译后的代码：

可以看到VSInstr程序修改了原来的DLL。在检测模式下，只有经过修改后的DLL才能收集到数据。

在VSTS中，一般可以通过Analyze菜单下的Launch Performance Wizard来新建一个性能会话，然后进行性能数据的采集。

对于ASP.NET程序，可以通过以下步骤来进行“采样”

iisreset /stop
VSPerfClrEnv /globalsampleon
VSPerfCmd /start:sample /user:”NETWORK SERVICE” /output:”d:\somewhere\xxxx.vsp”
VSPerfCmd /globaloff
iisreset /start
VSPerfCmd /attach:xxxx
VSPerfCmd /globalon

–run the test scenario–

VSPerfCmd /globaloff
VSPerfCmd /detach
iisreset /stop
VSPerfCmd /shutdown

1. 第一步是停掉IIS
2. 然后通过VSPerfClrEnv对环境变量进行设置，具体可以查文档，做完这一步以后通常需要重启一下电脑
3. 第三步就是通过VSPerfCmd启动性能数据收集
4. 接下来的VSPerfCmd /globaloff就是暂停性能数据的收集
5. 然后重启IIS，并且访问一下这个服务器上的页面，使得W3WP进程启动
6. 查看W3WP.EXE的进程ID，然后通过VSPerfCmd /attach:xxxx把Profiler attach到IIS中
7. 通过VSPerfCmd /globalon重新让Profiler进行性能数据的采集
8. 然后就可以运行性能测试的场景
9. 运行测试完毕以后就用VSPerfCmd /globaloff停止性能数据的采集
10. 接着用VSPerfCmd /detach让Profiler不要附着在IIS上
11. 停掉IIS — iisreset /stop
12. 执行VSPerfCmd /shutdown，这一步执行完毕以后，在d:\somewhere\下就有一个xxxx.vsp的性能报告。

对于ASP.NET程序，可以通过以下步骤来进行“检测”

检测和采样其实是大同小异的，但是有一个关键的步骤就是在进行检测之前，一定要记得用VSInstr命令对需要进行检测的DLL或者EXE文件进行处理，建议一次不要检测太多文件，检测时间不要太长，因为检测所产生的数量是非常大的，产生的文件大小都是按G级别计算了。

iisreset /stop
VSPerfClrEnv /globaltraceon
VSPerfCmd /start:trace /user:”NETWORK SERVICE” /CS /output:”d:\xxx\0422.vsp”
VSPerfCmd /globaloff
iisreset /start
– 预热 –
VSPerfCmd /globalon

–run code–

VSPerfCmd /globaloff
iisreset /stop
VSPerfCmd /shutdown

重复一次，在做以上的步骤之前必须要用VSInstr对目标二进制文件进行处理。这里详细步骤就不做解释了，命令的主要区别就是在做检测的时候，就免去了Attach到IIS这个步骤了。

采样和检测，前者是宏观的性能数据采集，后者是微观的性能数据采集。对于CPU负载较高的程序，用采样会得到比较好的效果；但是如果程序运行过程中并没有消耗很多的CPU资源，那么用采样可能就不能收集到太多有用的信息。所以在不同的场景下需要应用不同的性能数据收集方法。

Related posts:

1. 用VSTS Profiler发现性能问题并且进行优化实例
2. 用VSPerfMon在测试ASP.NET程序的过程中收集代码覆盖率信息
3. VSTS 2010 Test Edition文章收集

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

[Serializable]
public class Person
{
    public int Height { get; set; }
    public string FirstName { get; set; }
}
 
class Program {
    static void Main(string[] args) {
        //实例化一个对象
        Person PersonOne = new Person();
        PersonOne.FirstName = "John";
        PersonOne.Height = 1;
        //深拷贝
        Person DeepCopyPerson = new Person();
        DeepCopyPerson.FirstName = PersonOne.FirstName;
        DeepCopyPerson.Height = PersonOne.Height;
    }
}

代码中的DeepCopyPerson对象就是对PersonOne对象的一个深拷贝。其实还可以用序列化和反序列化的方法来实现对对象的深拷贝。Person类的[Serializable]属性是为了下面介绍序列化反序列化方法做深拷贝而做的准备，在这里没什么特别含义。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public static T DeepCopy<t>(T obj)
{
    object retval;
    using (MemoryStream ms = new MemoryStream())
    {
        BinaryFormatter bf = new BinaryFormatter();
        //序列化成流
        bf.Serialize(ms, obj);
        ms.Seek(0, SeekOrigin.Begin);
        //反序列化成对象
        retval = bf.Deserialize(ms);
        ms.Close();
    }
    return (T)retval;
}
</t>

用的时候就是：

1
2
3
4
5
6
7
8
9
10
11

class Program {
    static void Main(string[] args) {
        //实例化一个对象
        Person PersonOne = new Person();
        PersonOne.FirstName = "John";
        PersonOne.Height = 1;
        //深拷贝
        Person DeepCopyPerson = DeepCopy<person>(PersonOne);
    }
}
</person>

只要一个类被声明为可序列化的（就是带有[Serializable]标签），就可以用这个方法来进行深拷贝。记下来，免得以后自己忘记了。

Related posts:

1. PEX-.NET自动化白盒测试工具的介绍(1)
2. LINQ查询操作中的类型关系
3. 用XSD自动生成XML对应的.NET实体类

The test fixture is everything we need to have in place to exercise the SUT

我觉得这是一个对Test Fixture的一个很清晰明了的定义，就是运行被测软件所需要的一切东西，这个“东西”不单只是数据，同时还包括对被测软件的准备，例如实例化某个被测方法所在的类，准备数据库的ConnectionString等。通常来说，有三种方法来准备Test Fixture。

1. 内联方式：这种方式就是直接在测试方法中编写准备Test Fixture的代码。用这种方法的缺点是很容易造成代码的重复，出现很多复制粘贴的代码。同时，如果这个SETUP的过程比较复杂，也会降低测试代码的可读性，可维护性。另外的一个问题就是，这种方法很容易会带来测试数据Hard code的隐患。既然有那么多缺点，这种方法还有什么生命力呢？首先，可能对于初学者来说，这种方法是最简单的；其次，在一些只需要准备简单的Test Fixture的场合中，这种方法还是给编写测试的人提供了便利。

2. 委托方式：简单来说就是把Test Fixture的准备抽取为一个外部的方法，然后在需要的时候进行调用。这种方式的好处就是使得测试代码可读性更强，并且这部分的SETUP代码可以重用。而且这种做法可以屏蔽对SETUP过程的认知，使得测试人员的关注点落在真正的测试代码上面，而不是如何SETUP。

3. 隐式方式：很多xUnit框架的实现都提供了不同的隐式SETUP和TEARDOWN。例如MSTEST里面的[TestInitialize]和[TestCleanup]标签，就提供了一种隐式准备Test Fixture的支持。就是在每一个测试方法运行前，都会执行一次标有[TestInitialize]标签的方法。使用这种方法的好处就是写一次就能在各个测试中都实现了Test Fixture的准备，不用每次都显示地调用一个外部方法，不过缺点也不少：

• 可能会令测试比较难懂，因为这些隐式调用不是必须的，有可能会被遗漏掉。
• 不能使用哦本地变量来保存对象，只能用test class 里面的filed或者property
• 变相地使用了全局变量

在做单元测试的过程中，需要灵活地运用这三种Test Fixture的准备方法。例如在我的工作当中，我在以下情况使用到了隐式准备方式：

在某一个测试项目中，由于测试的数据不多，所以我使用了XmlSerializer，把测试的数据都放在一个XML文件中，然后利用XmlSerializer把XML中的数据映射到相应的配置类中。对于这样的情况，这些测试数据在测试运行的全过程中都需要用到，所以我选择了在测试类初始化的时候，只运行1次，来准备这些测试数据（Test Fixture的一部分）。

1
2
3
4
5
6
7

[ClassInitialize()]
public static void MyClassInitialize(TestContext testContext)
{
    XmlSerializer xmlSerializer = new XmlSerializer(typeof(Config));
    FileStream fs = new FileStream("Config.xml", FileMode.Open);
    config = (Config)xmlSerializer.Deserialize(fs);
}

还是在同一个项目中，我想让每一个测试之间互相不要受到影响，所以我在[TestInitialize()]方法中对于一个Web Service的客户端进行初始化，保证每一次运行测试前，这个客户端都是“新”的

1
2
3
4
5
6

[TestInitialize()]
public void MyTestInitialize()
{
   USi18nService = new InteropWebSerivce();
   USi18nService.Url = config.USi18nAddress;
}

在另外的一个项目中，需要对一个方法进行测试，该方法的功能是根据Email地址从PreSignup表里面获取相关的资料，那么首先要做的就是完成一个PreSignup的操作，才能检查这个方法。而完成PreSignup操作并不是所有的测试都需要的，所以我不选择隐式调用，而是选择委托调用，调用一个外部的帮助方法，来帮助我完成PreSignup操作；同时这个PreSignup的操作在其他一些测试中也是需要的，所以也达到了重用的效果。

那么在什么时候会用到内联方法来准备Test Fixture呢？其实我自己经常用这种方法，有以下一个场景，我需要对一个方法进行测试，这个方法要做的事情就是检查一个电话号码是否符合规范，那么我就会先创建一个List，然后在List里面填充了各种不同的电话号码，然后在后面用一个foreach语句把List里面的数据遍历一遍，可能这些电话号码的数据只在这一个方法里面才有用，所以我没有选择把它抽取成一个方法。

其实不同的单元测试框架有不同的思想，例如在NUnit里面，一个测试类的标签就是叫[Test Fixture]，其实作者的设计思想就是一个测试类，就是一套Test Fixture；如果不是一套Test Fixture，那么不要把测试方法写到一起。其实这三种方法各有所长，在我刚开始学习和尝试做单元测试的时候，我刚接触到类似[Setup][TearDown]这样的隐式调用的时候，我觉得这就是银弹，我要充分使用它。但是随着工作的深入，发现这个隐式调用会带来一些问题，然后就慢慢转用了调外部方法，或者直接内联到测试方法中。只有结合实际情况，结合的上下文来运用这些方法，才能真正提高单元测试代码的质量，减少我们的工作量。

Related posts:

1. 用XSD自动生成XML对应的.NET实体类
2. 实现数据驱动的CodedUI Test
3. ASP.NET中配置文件web.config的优先级

Memcached Providers的配置很方便，首先就是在.NET项目中引用上述提到的3个DLL文件，然后就需要修改项目的配置文件，如果是桌面程序，就修改APP.CONFIG，如果是WEB程序，就修改WEB.CONFIG。

首先在configSections节点下增加如下配置

1
2
3
4
5
6

<section name="cacheProvider" type="MemcachedProviders.Cache.CacheProviderSection, MemcachedProviders"
        allowDefinition="MachineToApplication" restartOnExternalChanges="true"/>
<sectionGroup name="enyim.com">
    <section name="memcached" type="Enyim.Caching.Configuration.MemcachedClientSection, Enyim.Caching" />
</sectionGroup>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,log4net"/>

接着在configuration节点下增加Enyim的配置节点

1
2
3
4
5
6
7
8
9

<enyim.com>
    <memcached>
        <servers>
            <!-- put your own server(s) here-->
            <add address="10.60.0.105" port="19191" />
        </servers>
        <socketPool minPoolSize="10" maxPoolSize="100" connectionTimeout="00:00:10" deadTimeout="00:02:00" />
    </memcached>
</enyim.com>

在configuration节点下增加Memcached Providers的配置节点

1
2
3
4
5
6

<cacheProvider defaultProvider="MemcachedCacheProvider">
    <providers>
        <add name="MemcachedCacheProvider" type="MemcachedProviders.Cache.MemcachedCacheProvider, MemcachedProviders"
                keySuffix="_MySuffix_" defaultExpireTime="2000"/>
    </providers>
</cacheProvider>

最后就是在configuration节点下增加Log4net的配置节点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/cacheProvider>
<log4net>
    <appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender">
        <layout type="log4net.Layout.PatternLayout">
            <conversionPattern value="%date [%thread] %-5level %logger [%property{NDC}]- %message%newline" />
        </layout>
    </appender>
    <root>
        <priority value="WARN"/>
        <appender-ref ref="ConsoleAppender">
            <filter type="log4net.Filter.LevelRangeFilter">
                <levelMin value="WARN"/>
                <levelMax value="FATAL"/>
            </filter>
        </appender-ref>
    </root>
</log4net>

最后做一个简单的测试

1
2
3
4
5
6
7
8
9
10

[TestMethod]
public void TestMethod1()
{
  string key = "mykey";
  string value = "Success!!!";
  DistCache.Add(key, value);                             //存数据
  Thread.Sleep(500);
  string ret = (string)DistCache.Get(key);            //读数据
  Assert.AreEqual(value, ret);                             //验证
}

整个过程下来比较顺利，基本没有遇到问题，这一切准备完毕以后就可以进入测试了。PHP，JAVA，Python等程序语言的Memcached客户端是比较多的，而.NET平台的客户端却只有2、3个，如果打算在.NET程序中使用Memcached，Memcached Providers也是一个不错的选择。

Related posts:

1. 用XSD自动生成XML对应的.NET实体类
2. 单元测试中三种准备Test Fixture的方法比较
3. ASP.NET中配置文件web.config的优先级

Related posts:

1. 单元测试中三种准备Test Fixture的方法比较
2. 用XSD自动生成XML对应的.NET实体类

首先有一段LINQ查询表达式的代码

1
2
3
4
5
6
7
8

List<onlineUser> ret = AccountGateway.AccountLiteProvider.GetOnlineUsers(1, 10000);
var query = from onlineUser in ret
			where (onlineUser.UserId > 1301000200)
			select onlineUser.UserId;
foreach(int iUser in query)
{
	Console.WriteLine(iUser.ToString());
}

这段代码首先查询出10000个在线用户，然后在这10000个在线用户中筛选出ID大于1301000200的用户ID。其中各个变量的类型如下：

• onlineUser — OnlineUser类
• query — IEnumerable<int>
• iUser — int

下面可以看一下MSDN的详细说明：

1. 数据源的类型参数决定范围变量的类型。
2. 选择的对象的类型决定查询变量的类型。此处的 name 为一个字符串。因此，查询变量是一个 IEnumerable<string>。
3. 在 foreach 语句中循环访问查询变量。因为查询变量是一个字符串序列，所以迭代变量也是一个字符串。

下面这个例子跟本文刚开始的代码例子相似

1. 数据源的类型参数决定范围变量的类型。
2. select 语句返回 Name 属性，而非完整的 Customer 对象。因为 Name 是一个字符串，所以 custNameQuery 的类型参数是 string，而非 Customer。
3. 因为 custNameQuery 是一个字符串序列，所以 foreach 循环的迭代变量也必须是 string。

像上面这样做，有点不爽的就是每个变量类型都要编程的人来指定，C# 3.0还有一个新特性，就是隐式类型本地变量，也就是var关键字

1. 数据源的类型参数始终为查询中的范围变量的类型。
2. 因为 select 语句生成匿名类型，所以必须使用 var 隐式类型化查询变量。
3. 因为查询变量的类型是隐式的，所以 foreach 循环中的迭代变量也必须是隐式的。

到此，对LINQ查询操作中的类型关系也比较明白了吧。

一个变量被var关键字声明为隐式类型本地变量后，它并不是一个动态变量，C#动态变量要等4.0的dynamic关键字。那么这个var是什么呢？其实var也是一个强类型变量，它的类型是在编译时就已经确定下来了，并不是运行时才确定下来的。例如：

var s = “I am a string”; //s的类型是string

var i = 88; //i的类型是int

s = 99; //编译出错，不能把一个int赋值给string类型变量

用Reflector看编译后的代码就是这样子：

1
2
3
4
5
6
7
8

List<onlineUser> ret = AccountGateway.AccountLiteProvider.GetOnlineUsers(1, 10000);
IEnumerable<int> query = from onlineUser in ret
			where onlineUser.UserId > 1301000200
			select onlineUser.UserId;
foreach (int iUser in query)
{
	Console.WriteLine(iUser.ToString());
}

稍微总结一下var

• var还是强类型变量，不是弱类型变量
• 使用var不会带来性能损失，因为编译为IL以后，变量的类型已经是确定，不是在运行时通过反射获取类型。

再最后，C#3.0, 3.5的很多新特性感觉都是为LINQ而出现的，例如：隐式类型化本地变量，匿名函数，匿名类，lambda表达式，扩展方法……

本文参考MSDN：http://msdn.microsoft.com/zh-cn/library/bb397924.aspx

Related posts:

1. 在C#单元测试中使用HttpContext的简单解决办法
2. Linq to Object在测试中的应用
3. 在单元测试中应用数据驱动