单元测试中遇到异常的处理   软件测试

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

　　● 如果无法处理某个异常，那么不要捕获它

　　● 如果捕获到一个异常，那么不要胡乱处理它

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

　　● 作为测试代码，如果捕获到一个异常，其实是无法处理它的。从某种角度来看，测试代码和被测代码是不在一个系统中，AUT所抛出的异常，测试代码无法处理，其实也无需处理。

　　● 假如测试代码捕获了一个异常，那么能做的事情是把这个异常重新包装一下，或者直接重新抛出给单元测试框架，然后由单元测试框架打印到界面上或者是执行结果中。但是其实我们什么都不做(不用Try…Catch)也能达到这样的效果。

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

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

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

　　结论：在单元测试中，尽量不要使用Try…Catch代码块，个人经验，以供参考