如何用异常测试来快速发现问题

一、异常测试定义

       在编写代码的过程中，程序员编写的业务流程和逻辑通常按设计，设计的业务流程通常不会考虑代码执行过程中异常处理，仅仅是业务流程中的异常处理会写一些，设计比较细的系统设计可能会设计业务异常处理的流程要求，比较粗的基本上只写正常的业务流程，不会设计异常流程，这种情况通常在代码阶段由编写代码的程序员来进行补充实现，所有业界有这样的说法“软件好不好，看异常处理的好不好”就是这个意思。

       上面描述了两种容易遗漏的情况，所有在进行测试的过程中，可以通过了解系统中的业务流程和代码实现过程中易犯的错误，以此为异常测试的出发点来构建测试用例。

 

二、异常测试如何进行操作

        有条件的情况下，可以看一看系统设计的文档，了解业务流程，仔细研究业务流程后可以发现还是有容易导致错误的地方，这些地方恰恰是异常测试的重点，可以将此整合到测试用例中。

        举个数字电视系统中的例子，信号线或网线是进行节目广播和传输的媒介，我们收看节目播放的过程中，有时信号或数据没有，就会有信号提示“无信号”或者是播放器在转圈的提示，短时间内信号回复或者数据又有了，节目会自动恢复播放，大家又可以继续欣赏。这个场景是我们大家很熟悉的场景，在设计中就要考虑信号和数据丢失的情况下，要向使用者予以提示，信号和数据恢复的情况下，销毁提示信息，继续播放。早期的盒子中就有信号丢了，然后信号恢复了，无信号提示框还显示在节目的情况。这个就是容易出错业务流程，在进行设计异常测试用例增加拔插信号线和网线的测试，或者终止视频播放服务器广播码流的测试，然后看反应。

        再比如播放器进行码流播放，对硬件解码器或软件解码器码流容错能力的测试，在网络环境复杂的场景下，会出现可各种各样的误码，解码器对异常的数据是否可以正常的处理，有线电视和卫星电视网络状况有很大的不同，有线电视的干扰就很小，卫星电视的影响就要大些，电离层异常，太阳风，雨衰等等都会影响信号质量，导致误码率的上升，有异常的数据就会进入到解码器来解码，有时会有大片的马赛克出现在屏幕上，如果解码器容错做得不好，就有可能马赛克不恢复，帧率错误，甚至退出死机的严重情况。为了模拟这种场景，可以在信号端人为加些干扰或乱数据到信号数据中来进行测试，相当于注入异常数据来测试解码器的容错能力。

        代码的浏览，在有的公司可能不好接触到，有的话更好，可以直接看代码，检查漏洞。多数情况下，代码看不到，测试只是进行黑盒测试，通过输入和输出来进行判断运行是否正常，这种测试需要构建大量的测试用例才可以完整覆盖，特别输入和输出比较负责的情况下，而异常测试则是薄弱环节的测试，测试工作小的多，但对整个系统的业务流程和大概的程序实现有比较多的经验的人或团队才可以找到这些点，需要的技术能力较高。

       如测试个函数接口 int func(char * string1, char *string2)； 函数的功能是比较string1和string2字符串有多少相同的字符组合，返回值是相同字符组合的个数，异常失败返回-1；从测试异常的角度来进行应该如何处理，首先是指针型的数据要进行空指针检查，另外返回值是否正确也要检查，正常返回应该是大于等于0，而小于int 型极值，这就要求对string1 和string2的比对完的长度进行判断，不要越界。根据这几点在做测试用例就需要针对这几个地方进行边界条件测试，同样是将边界条件作为异常测试。

三、异常测试的好处

第一，快速找到系统和代码中设计薄弱的地方，并加以测试；

第二，弥补程序员思维定式产生的代码编写中对异常处理的疏漏；

第三，降低测试的覆盖的难度；

第四，对于难于进行自动化测试用例的项目，可以减轻发现BUG的难度