早上来看到一篇文章，大概讲的是在单元测试中容易用到了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. 单元测试中的异常处理

所谓的测试的坏味道，有三种：

1. 项目（Project）
2. 行为（Behavior）
3. 代码（Code）

按照《重构》书中提出的坏味道的概念来看，如果说是有坏味道（Smell），那么大多数都是指代码级别的。什么的坏味道？就是程序有可能会有大问题的一种征兆（symptom）。个人理解就是不能被直接观察到的现象，可以称之为坏味道。

对于自动化测试代码来说，如果有了项目级的坏味道，通常变现就是生产环境出现了BUG。如果出现这样的情况，那么自动化测试代码就不是有味道那么简单了，而是有问题了，自动化测试的安全网没有能够抓住这个BUG。

而行为的坏味道，其中一个表现形式就是我以前写过的在自动化测试中需要避免“诡异”的测试脚本提到的现象。还有诸如编译错误、不能被重复运行的测试等。其实如果我们碰到行为级别的坏味道，那么可以肯定，我们必须要修改它。如果不修复好这些问题，自动化测试根本无法进行。

代码的坏味道，这个才是我们需要注意的问题，因为代码有了坏味道，并不代表着自动化测试代码会运行出错，通常人们是不会去修改没有出错的代码，人之常情。发现测试代码的味道，并且去修复它，会让我们的自动化测试更加健壮。《XUnit Test Patterns》这本书的前言部分给出一个典型的例子来说明单元测试代码中有哪些坏味道，如何去修改。例子中的一些对单元测试的重构方法，我在平时的工作中也应用到了，不过看完了以后真是觉得裨益良多，虽然做了快一年的单元测试，集成测试，但是却没有停下来总结一年中学到了什么，真的要借着读这本书的机会，好好总结。

最近在接回以前的一些测试项目，个人觉得如果测试代码里面不写注释，这样也是一种坏味道。对于一堆测试代码，半年后可能都忘记了当初为什么这样写，尤其是对于没有注释的测试代码。就像我在译言翻译的第一篇文章里面说的那样，“很多时候，你就是注释的第一位受益者，或者受害者”。对于有坏味道的自动化测试代码，你可以让他继续发酵，腐烂，总有一天，你自己要收拾这个残局。

No related posts.

while (days > 365)
{
	if (DateTime.IsLeapYear(year))
	{
		if (days > 366)
		{
			days -= 366;
			year += 1;
		}
	}
	else
	{
		days -= 365;
		year += 1;
	}
}

这是ZUNE处理时间的一段代码，每年的最后一天（days=365）向第二年的第一天（days要加1）过度的时候会做一个处理。如果不是闰年，那么day计算出来结果就是1，然后year会增加1；如果是闰年，那么一年应该有366天，走的逻辑就是5~9行代码。2008年31号ZUNE死机的原因就是，days=366，years=2008，会出现死循环。下面来写一个单元测试，来测试一下这一段代码块。

[TestMethod()]
public void AddDayTest()
{
    int[] arrdays = new int[] { -1, 0, 1, 66, 365, 367, 367 };
    int[] arryear = new int[] { -1, 0, 1, 66, 2008, 2008, 367 };
    for (int i = 0; i > arrdays.Length; i++)
    {
        int days = arrdays[i];
        int year = arryear[i];
        Class1.AddDay(days, year);
    }
}

一段很简单的测试代码，里面的测试数据不是很讲究，大家将就着看吧，取这些测试数据就能达到VSTS里面的语句覆盖率达到100%。如图：AddDay方法语句覆盖率已经达到100%

下图是具体代码，整个方法体的代码都是浅蓝色，代码都被覆盖到了

回头看看测试数据，虽然达到了100%语句覆盖，但是依然遗漏了“闰年，366天”这样一条数据，只要我们用这条测试数据来测试，就能发现错误了。

下面来说说用VSTS做单元测试，通过一些设置来帮助我们发现类似这个死循环的BUG。在VSTS里面，可以设置每个单元测试的超时时间，默认是30分钟，这样对于发现一些出现死循环的BUG不太有利。很多人都说过，单元测试的一个特点就是–快！因为测试只是检查一小个单元是否能正常工作。如果一个“单元测试”需要几分钟，那么几乎可以很肯定地说，这不是一个单元测试，这个测试肯定跟外界有很多交互，例如读取一个外部文件？读取数据库？请求一个web service等等。在Test run config里面，把超时时间设置为10秒，如果一个测试会导致死循环，那么10秒后，就会提示我们该单元测试出现超时，如图：

设置好了以后运行一下单元测试：

[TestMethod()]
public void AddDayTest1()
{
    int days = 366;
    int year = 2008;
    Class1.AddDay(days, year);
}

出现结果：

很好，我们可以在比较短的时间内发现问题，而不是观察CPU占用率长期达到100%。

总结：现在的代码覆盖率工具，大部分都只有语句覆盖的功能，而语句覆盖 又是众多代码覆盖标准里面最弱的一种。有时候做白盒的测试（单元，集成……），会很容易掉进一个陷阱，就是看着代码覆盖率工具给出的结果，来提高自己测试代码覆盖率。这样代码的覆盖率上去了，但是代码的质量却不见的能有提高。以后做测试的时候，也应该把精力放在关键部分的代码逻辑的验证上，不要老盯着覆盖率往上涨。

Related posts:

1. 自动化白盒测试工具PEX应用实例 – 发现ZUNE死机的BUG
2. 单元测试中的常用测试模式
3. 测试代码重构实例

Dynamic White-Box Testing（动态白盒测试）-动态，就是软件在运行；白盒，我们能看见里面怎么运行。所以就好像是带了X-光眼镜一样。它还有另外一个名字，就是结构测试(Structural Testing)。动态白盒测试通常包含了四个方面。

1.直接对底层的函数，过程，库~等进行测试。也就是对API的测试
2.站在一个比较高的层次来测试软件，而且是根据你对软件行为的认知的情况下进行，根据code具体的情况设计有针对性的case进行测试
3.验证已经设计好的case是否真的符合了当初设计的初衷。还有就是强行改变一些通过正常途径很难达到的软件的状态。这个例如说，一般软件都有很多错误的提示信息，但是要把全部错误信息通过正常渠道（用这个软件）得到，是比较困难的。不过在白盒测试里面，我们可以直接在debug器里面改相应的flag变量来达到目的
4.根据各种code coverage的结果来对已有test case的增加和修改，以达到更好的测试效果。
个人的一些体会，其实测试就是一个动态的过程，test case需要动态的维护、更新和增加，以达到好的效果。呵呵，动态可不单只是指软件运行~一语双关啊~或者说这个词被重载(Overload)了。

动态白盒测试和调试(Debugging)的区别
可以抓住一个要点，他们的目的分别是什么。白盒测试是一种测试手段，测试的目的是为了找到bug，所以白盒测试的目的是找bug。而Debug的目的是什么？是修复bug。之所会让人分不清，是因为他们有一些重叠。就是在分离并确定(Isolating)发生bug的原因。

单元测试(Unit Testing)和集成测试(Integration Testing)
单元测试通常是由程序员来执行的，集成测试也是。不过有些公司是Tester来完成集成测试的，我比较怀疑这个是否应该由Tester来完成~对于集成测试通常有3种。

1.大爆炸形式。就是一次把所有东西搞到一次然后测，虽然都觉得这个模式比较扯淡，但是实际上很多公司都是这样的方式来工作，呵呵~
2.Bottom-up（自底向上）。就是现在有了底层的模块，然后需要一步一步做集成测试，通常会让测试的人员编写驱动模块(Test Drives)。驱动模块能模拟上层模块对下层模块的调用，从而实现了测试的目的。
3.Top-Down（自上向下）。就是有了上层的模块然后需要编写桩模块(Stub)来模拟对底层的调用。
其实后面的两种方法就跟单元测试里面用的一种技术(mock)是很相似的。都是模拟一个东西出来，不需要实现内部的功能，只需要把接口定义好，然后设计一些输入输出就好了。

一个软件，其实是由数据+程序实现。所以也就有以下两种覆盖。

数据覆盖(Data Coverage)
1.数据流(Data Flow) – 对于黑盒测试，我们只知道输入数据和输出数据，我们对这一对数据的中间处理是一无所知的，但是在运用白盒测试的技术以后，我们可以对中间的变量转换还有变化会有一个清晰的了解。正是基于对这些的了解，所以我们可以修改或者增加一些Test Case来对那些风险比较高的地方进行充分的测试，不要忽略了白盒测试的优势–对内部的了解。
2.次边界值(Sub-Boundaries)
3.公式(Formulars)和等式(Equations)-这里面可以考虑到如果一些公式里面用到除法，那么就应该考虑一下这个如果除数是0的时候程序有没有正确处理。
4.强制错误(Error Forcing)-这个就是刚开始说的需要强制的把一些flag改未错误的标记然后看看结果是否正确。不过这里需要知道做的要合适才行。就例如说前面一个例子，一个除数是N，而且N不是直接用户输入而且结果一些计算得出最后给赋值的，我们可以考虑N=0的时候有没有错。但是如果我们通过这个“强制错误”的方法，把N赋值为0，然后报错，这样子是不合理的。因为在生成N的时候有可能已经是经过检验的不可能出现N=0的情况，如果我们硬要把N赋值为0那么其实这不是一个有效的测试用例。

代码覆盖(Code Coverage)
通常做代码覆盖都需要用工具作为辅助~通过软件的帮助我们可以得到以下的信息：
1.软件的哪些部分我们没有覆盖到，我们需要补充更多的case来覆盖他
2.那些测试用例是冗余的，我们可以把那些冗余的case用等价类来减少case的数量
3.对于覆盖率不高的模块可以增加case来覆盖

语句覆盖(Statement Coverage)行覆盖(Line Coverage)
这个是代码覆盖里面最简单的覆盖，而且要做到100%的语句覆盖是比较容易的，不过意义不大，以为即使做到100%覆盖，还是没法很好的检查软件，因为大部分的错误都是逻辑错误。

分支覆盖(Branch Coverage)判定覆盖(Decision Coverage)
似的程序中的每个判断至少取真分支和假分支一次。做到100%的判定覆盖是有可能的。不过对于符合条件（就是出现 IF A AND B AND C）分支覆盖会在其中一个组合中被测试到。这是分支覆盖的一些弱点。

条件覆盖(Condition Coverage)
条件覆盖要求是每个判断中的每个条件的可能只至少满足一次。例如(IF A AND B)那么需要有1) A=TRUE,B=FALSE，2)A=FALSE,B=TRUE。这样就完成了，这2个测试用例达到了条件覆盖的要求但是可以看看，没有达到分支覆盖。

Related posts:

1. 《Software Testing》第五章 – 黑盒测试
2. 用PDB库调试Python程序
3. 《Software Testing》（软件测试）读书笔记系列 – 第十六章