前一阵子需要测试一个搜索在线会员的功能，如果一个用户是在线的，那么他所能够被搜索到的信息都会作为一条记录，保存在一个表中，主要的字段有5个，也就是根据这5个字段的信息可以查询出用户想要的在线会员。一个简单的方案就是写一个比较复杂的存储过程，然后根据5个输入来查询出不同的结果，不过DBA说在SQL SERVER中进行逻辑运算的性能不是很好，所以开发人员写了12条存储过程，分别对应不同的组合，那么对于我做集成测试来说，我起码要有12个测试方法对应这12条存储过程。同时我还要设计一定数量的测试数据，供我查询测试，而比较要命的是，这些测试数据随着我对这个功能的理解的深入，在不断地增加，结果就是如果我写第一个测试的时候，我准备的数据是30条，OK，测试通过；等我写到第五个测试的时候，测试数据可能有40条了，当我用这40条测试数据重新指向第一个测试的时候，FAILED!!!这让人非常郁闷。所以我想到了能不能用round trip的方法来进行测试。做一个比喻，假如说我想证明WIN7的计算器程序是正确的，那么可以把相同的计算在WIN XP的计算器中跑一遍，如果两者结果一样，那么我可以认为WIN7的计算器程序也是正确的（如果XP的计算器有错怎么办？先别较真，有风险，但很小）。

我的做法就是，准备一些数据，首先用SUT进行查询，然后用LINQ进行查询，如果两者查询结果一致，那么可以认为程序是正确的，否则就是两者之一存在问题。

首先准备一些测试数据，保存为XML文件，第一方便对测试数据进行CRUD，第二可以用XmlSerializer把这些数据转换为对象，方便用LINQ查询。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

< ?xml version="1.0" encoding="utf-8" ?>
<onlinefriends>
    <friends>
        <onlinefrienddata>
            <friendid>1300010000</friendid>
            <province>北京市</province>
            <city>北京市</city>
            <age>18</age>
            <gender>2</gender>
            <hasphoto>true</hasphoto>
        </onlinefrienddata>
        <onlinefrienddata>
            <friendid>1300010002</friendid>
            <province>北京市</province>
            <city>北京市</city>
            <age>27</age>
            <gender>2</gender>
            <hasphoto>false</hasphoto>
        </onlinefrienddata>
        <onlinefrienddata>
            <friendid>1300010004</friendid>
            <province>广东省</province>
            <city>广州市</city>
            <age>45</age>
            <gender>1</gender>
            <hasphoto>true</hasphoto>
        </onlinefrienddata>
    </friends>
</onlinefriends>

然后需要有一个类，利用XmlSerializer来反序列化这些测试数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

[XmlRoot("OnlineFriends")]
public class OnlineFriends
{
	private bool IsEmpty = true;
 
	private static OnlineFriends fs = new OnlineFriends();
 
	private OnlineFriends()
	{ }
 
	public static OnlineFriends Instance
	{
		get
		{
			if (fs.IsEmpty)
			{
				fs.Deserialize();
			}
			return fs;
		}
	}
 
	private void Deserialize()
	{
		var serialzer = new XmlSerializer(typeof(OnlineFriends));
		using (XmlReader xmlreader = XmlReader.Create("OnlineFriends.xml"))
		{
			fs = serialzer.Deserialize(xmlreader) as OnlineFriends;
			fs.IsEmpty = false;
		}
	}
 
	public class OnlineFriendData
	{
		[XmlElement("FriendId")]
		public int FriendId { get; set; }
 
		[XmlElement("Province")]
		public string Province { get; set; }
 
		[XmlElement("City")]
		public string City { get; set; }
 
		[XmlElement("Age")]
		public int Age { get; set; }
 
		[XmlElement("Gender")]
		public byte Gender { get; set; }
 
		[XmlElement("HasPhoto")]
		public bool HasPhoto { get; set; }
	}
 
	[XmlArray("Friends")]
	[XmlArrayItem("OnlineFriendData")]
	public OnlineFriendData[] Friends { get; set; }
}

数据的准备工作就差不多了，看一个简单的测试。首先这个测试方法会重新初始化测试数据，然后查询27岁的在线会员，查询出来的结果保存在ids的INT列表中。OnlineFriends.Instance.Friends对象中保存了所有在线好友的数据，它是一个实现了IEnumerable接口的类，所以可以使用LINQ相关的扩展方法。

在OnlineFriends.Instance.Friends.Where(x => x.Age == age)语句中，“x => x.Age == age”是一个应用了Lambda表达式的匿名委托，整个语句的意思就是在OnlineFriends.Instance.Friends这个集合中，找到年龄==age的元素。

不过找到了以后还不行啊，SUT返回的是INT列表，而刚才查到的是OnlineFriendData对象的集合，接下来可以用Select(y => y.FriendId).ToList()对集合做一个投影，只取出FriendId属性，并且转换为INT列表。

最后用CollectionAssert.AreEquivalent()方法对两个INT列表进行比较，看列表是否相等。

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

[TestMethod]
public void GetOnlineFriendsIdList_Query_Age_LowerUpperDiffOne()
{
	//重新初始化测试数据
	TestHelp.InitForSearch();
	int age = 27;
	OnlineFriendQuery query = new OnlineFriendQuery();
	query.AgeLowerBound = age;
	query.AgeUpperBound = age;
             //根据条件查询在线会员，在这里就是要查询27岁的会员
	List<int> ids = FriendListGateway.FriendListProvider.GetOnlineFriendsIdList(query, MyAllPc);
 
	//Two collects are equivalent
	CollectionAssert.AreEquivalent(OnlineFriends.Instance.Friends.Where(x => x.Age == age).Select(y => y.FriendId).ToList</int><int>(), ids);
}
</int>

假如使用我最开始的测试方法（就是先准备测试数据，然后人工统计一下里面有多少个27岁的数据，最后进行比较），我在完成了这一条测试以后，接下来还要小心翼翼地添加测试数据，不能再添加年龄是27岁的数据，要不然就会影响到测试结果。但是应用了LINQ以后，我在后续的测试数据设计中就无需要担心新设计的测试数据会对老的测试造成影响。甚至我还可以用程序生成各种不同的数据，填入数据库，供我测试用。

Related posts:

1. 用XSD自动生成XML对应的.NET实体类
2. 在单元测试中应用数据驱动
3. 在C#单元测试中使用HttpContext的简单解决办法

早上来看到一篇文章，大概讲的是在单元测试中容易用到了Try…Catch语句而容易出现的一个错误，这里想说一下我对单元测试中异常处理的。记得一个牛人曾经说过（实在想不起来谁也搜不到），大概的意思就是“处理一个问题的最好的办法就是不去处理它”。我不知道当时他讲这句话的具体场景是什么，不过我觉得这句话用在单元测试的异常处理中还是比较合适的。

首先来看看两条关于异常处理的原则

• 如果无法处理某个异常，那么就不要捕获它
• 如果捕获到一个异常，那么不要胡乱处理它

单元测试的代码和开发的生产代码，虽然同是程序代码，但是他们存在的意义是不一样的。前者是验证程序的正确性，属于为程序服务的；后者是实现某种功能，属于为客户服务的。然后在看上面的两条异常处理的原则。

• 作为测试代码，如果捕获到一个异常，其实是无法处理它的。从某种角度来看，测试代码和被测代码是不在一个系统中，AUT所抛出的异常，测试代码无法处理，其实也无需处理。
• 假如测试代码捕获了一个异常，那么唯一能做的事情就是把这个异常重新包装一下，或者直接重新抛出给单元测试框架，然后由单元测试框架打印到界面上或者是执行结果中。但是其实我们什么都不做（不用Try…Catch）也能达到这样的效果。

可能会有这样的一些测试用例：在输入某些数据的情况下，该函数会抛出某异常。测试工程师就是要验证有异常的抛出。如果是这样的情况，可以用ExpectedException的Attribute（.NET）来标识出该测试代码必须要抛出该异常，如果没有抛出，该测试就是失败。

所以在单元测试的代码中出现Try…Catch其实是没有必要的，如果是真的觉得要使用Try…Catch才能完成某些用例，那么我觉得可以重新设计测试用例，或者测试用例的实现。Try…Catch增加了测试代码的不确定性，而这样的不确定性会导致诡异的自动化测试脚本的出现。在回归测试的过程中就有可能出现运行10次测试，有2次失败8次成功的情况。

不过在单元测试（集成测试）中Try…Finally语句的使用还是很有必要的，例如我们会把数据库链接释放的代码放在Finally语句块中，保证测试运行无论成功还是失败，都能释放数据库链接，或者其他昂贵的系统资源。

总结：在单元测试（集成测试等……）中，尽量不要使用Try…Catch代码块；如果需要释放昂贵或者有限的系统资源、做清理工作，可以把相关的代码放在Finally代码块中。

参考资料：

异常处理 – MSDN

异常处理原则

理解.NET中的异常

单元测试之新手最容易犯的错误

Related posts:

1. 自动化单元测试要点

单元测试，集成测试有什么用？

1. 改进产品质量

软件测试，很多时候围绕着两个问题：

Verification和Validation，常说的双V。前面的Verification就是Is the software built correctly?。后面的Validation就是Have we built the right software?

单元测试，更多的是Verification。所以有时候经过我单元测试和集成测试以后的功能模块，在交给其他同事做功能测试的时候，依然会有一些BUG，这时候开发可能会埋怨我测试得不够完全，诸如此类。但是其实很多时候，我的关注点是单个方法的功能、行为，没有站到更高的位置来测试这个模块。对于这样的问题，开发和测试应该互相体谅，我本人也会提高自身的水平。希望在单元测试和集成测试中也加入更多关于Validation的思考。

有一个提法叫Tests as Specification，单元测试本身其实就是模拟某个模块的使用者（其他的程序）来进行测试。很多时候我写的测试代码也是其他开发人员的参考，尤其在一些事实上或者只是号称自己是敏捷开发的组织里面，测试代码有可能成为详细设计的替代品，因为有可能根本没有详细设计文档。

单元测试的另一个工作就是发现并且定位BUG。对于BUG的定位和重现，在单元测试代码的编写过程中，每个Assert语句后面都要加上尽可能详细的信息，例如导致这个Assert语句失败的每个参数值，期望结果，实际结果等，这些信息可以帮助开发和测试快速定位问题，减少不必要的DEBUG时间。

2. 降低项目的风险

软件测试，其实是用有限来验证无限的一个过程，很多时候做什么样的测试，做到什么样的程度，很多时候都跟风险有关系。

作为产品的安全网，各种测试在项目中都扮演着重要的角色。例如，中美交互的几十个Web Service接口的回归测试，现在有若干个测试，每天定时做回归测试，因为没人知道在美国的服务器会发生什么事情；对于中国的Web Service，在上线前都会通过回归测试，才部署上线。还有全站的Platform Service接口，每次上线前都需要在做回归测试。软件测试的另一个有趣的结论就是：测试只能证明软件有BUG，但是无论什么样的测试，都不能证明被测软件是没有BUG的。问题出来了，我做完回归测试，都通过了，但是我却不能证明这个软件是没有BUG的。其实每次上线，团队都承担着风险，只不过这样的风险在完成回归测试之后，大家上线的信心增加，风险明显地减小。

什么样的测试才是好的测试？

1. 容易运行

什么样的单元测试是容易运行？答案很简单，自动化的单元测试就是容易运行的测试。如果一批测试在运行之前每次都需要重装系统然后还要找一大堆需要依赖的软件来装上，最后还要输入奇怪的命令才能运行，那么就不是一个好的测试（本人真的见过这样的测试，囧）。个人认为，配置好的持续集成系统，可以实现很好的自动化测试；如果没有一个完善的CI，那么一个one click的自动化测试运行也是一个较好的选择。

2. 自动检查结果

一句话：没有自动检查结果，再好的自动化也是白搭。

3. 可重复

一句话：只能运行一次的单元测试也是白搭。

4. 独立

其实测试的独立，也有利于实现可重复。刚做单元测试的时候，曾经犯过这样的错误，我在写A测试的时候，给数据库插入了一条记录，然后我在写B测试的时候，就觉得我为什么要在两个测试中分别创建两条数据？直接用上一个测试的数据就可以了。不过结果还好，我很快就发现这样做是有问题。单元测试的独立，就是运行测试的人可以先运行A测试，也可以先运行B测试，也可以单独运行A或者B测试，甚至可以A和B测试同时运行。

5. 简单

有时候，测试的代码写的有点复杂，嵌套的语句有点多，可能有些人会觉得写出复杂的单元测试代码才能体现自己的水平，但是，我觉得对于单元测试代码来说，应该越简单越好。最好就是顺序执行下来了，不要有什么分支。因为测试代码本身就是也是代码，那么怎么去验证测试代码写的正确呢？答案可能是再写一个测试代码去验证第一个测试代码。这样就会有死循环了。一个简单的假设就是，如果测试代码足够简单，那么就可以认为测试代码是正确的，无需其他代码对之进行测试。

6. 专注

一个测试应该只测试一个点。如果在一个测试里面验证多个测试点，看起来是比较高效的一种做法，但是当测试中有Assert语句抛出异常的时候，很有可能需要花大量的时间才能找到真正错误的代码，这样不利于实现前面提及到的“定位BUG”。

7. 注释

注释其实就是把代码抽取成可阅读的测试用例，如果别人看自己的程序，可以快速理解测试代码；同时注释还能唤醒自己沉睡的记忆和当时的测试思路。

国内做单元测试的测试工程师少，做集成测试、接口测试的也不多，埋头做事,别忘抬头看路。时常总结，提高自我。

Related posts:

1. 《Software Testing》第三章 – 软件测试
2. 单元测试中的异常处理