初探异常测试副本

1、目录异常测试21异常测试简述22为什么要做异常测试23异常测试场景34异常测试场景抽象和设计方案44.1业务异常4业务流程4交互规范44.2外部异常64.1.1 独立的服务不可用异常64.1.2 组合的服务部分不可用异常84.3网络异常104.3.1 网络超时104.3.2 网络丢包114.3.3 网络抖动134.3系统异常135异常测试在手机账号项目中的实践135.1 系统架构135.2 用例设计145.3 测试方法156. 总结16异常测试1异常测试简述软件交付最终用户使用之前，需要进行各种类型的测试，其中就包括异常测试。异常测试，是检测系统对异常情况的处理。异常测试覆盖硬件或软件异常时的

2、处理。测试方应通过人为制造错误情况测试系统对错误操作、错误报文的反应，检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束；一旦出现错误情况，系统是否能正常报告，并检查系统的错误提示是否清晰且充分；测试系统是否处理了用户的异常操作，还是造成死机或处理错误。2为什么要做异常测试只有通过异常测试的软件产品，才可以保证软件在正式上线后长时间的保持良好的运营状态，给最终用户以信心。异常测试的结果也有助于为我们进一步的系统优化设计积累经验。3异常测试场景根据URS组内的实践，将之前调研的异常测试需求进行一个分类并抽象成不同的场景，主要分为如下类1.业务异常，主要从业务操作或业务流程方面考虑，一般会涵盖

3、在功能测试中的逆向测试；2.外部异常，一套完善的系统往往都有一些外部调用的服务，如依赖的DB，缓存，MQ，其他系统的接口等，在系统运行时，如果调用的这些服务出现异常，系统会如何处理这种异常情况，也是需要关注的重点。3.网络异常，非常常见的一种异常场景，测试过程中基本上不会发现，并且线上很容易出现此类有关的问题。4.系统异常，主要体现在系统健壮方面的能力，包含如内存、磁盘、cpu、集群负载均衡等业务异常，基本上在URS项目中已经在功能用例中做了体现，在此不多赘述。系统级异常，与部署在机器上的业务无关，也就是我们常说的体现在应用性能上面的可靠性，这又包含两方面内容系统的高可用和高恢复，：（1） 当

4、存在系统级的异常时，系统应当有其他的负载机器继续接管服务，保证可用；（2） 负载机出现问题后的快速发现并恢复，无论是监控系统，或是人为处理，这也是需要系统上线后应有的保障体系URS系统主系统工程整套的集群体系以及监控系统均已比较完备，所以针对这一块的异常测试，在之前做过的情况下，后续便缩减了此处的测试。4异常测试场景抽象和设计方案4.1业务异常4.1.1业务流程业务需求是开发之源，也是测试之源。测试人员对业务需求的了解是非常非常重要的，针对于异常测试更是如此。异常测试就必须要熟悉所测软件的业务流程、相关业务领域知识等信息，只有这样才可以知道系统在什么情况下会发生异常，什么情况下容易发生人为错误

5、。这需要测试人员和开发人员或者系统分析员甚至真正的业务人员一起讨论，根据软件的类型与特点设计测试案例，不能凭空猜想。只有这样设计出的案例才能够真正的测试到，由于关键业务需要或者变化发生了异常，在此时软件的处理能力。这一类的测试案例可以包括：特殊业务工作流程测试：测试软件不按照正规的流程，而是按照可能的但非正规的业务流程运行，是否会生成错误数据，或者造成原有数据的错误，甚至造成系统的瘫痪；删除或修改系统的重要数据或配置文件测试：测试情况发生时系统是否能够正确的提示，指明系统的错误。在进行相应修补后，系统是否能够正常运行；违规操作：这类测试可以包括，对现有重要业务数据的违规操作、用户越权业务操作等

6、，测试系统是否有相关约束。如果发生类似事件，系统是否有补救措施，而不导致系统的瘫痪。4.1.2交互规范用户正确的操作是系统正常运行的前提。所以在测试的时候，一定要进行错误操作来测试软件系统的健壮性。在从操作需求方面设计异常测试的测试用例时，需要从用户或者操作者的每一步的操作中进行提炼，而且这些测试用例一定要可操作性强，输入、输出、操作步骤都应该明确。实际上这部分测试用例也是功能测试用例的一部分，只是他不是正常、按照用户需求说明书的操作而已。这一块的内容包括输入框内容、页面跳转等一些方面，可以使用一些常用的测试用例设计方法来设计4.2外部异常系统的异常除了本身以外往往会出现在调用的外部的异常，通

7、常指的是一些外部依赖服务的异常，如DB、缓存、MQ、外部接口的调用等。 独立的服务不可用异常.1 DB不可用数据库是我们系统经常要使用到的功能对于DB的调用，在系统长时间的运行过程中，总是会有一部分线上问题是由于DB连接的异常导致的。我们常说的DB异常基本上可以总结为DB的不可用异常，DB不可用又可以分为：DB服务不可用，DB挂起，DB不存在， DB锁等，一般不同的情况，代码中会抛出不同的异常，但这些种现象表现在调用上往往都是表现为服务不可用，可做同一情况处理。方案一（1） 通过shell中的Kill -9 pid和kill -19分别可以关闭和挂机服务；（2） DB不存在可以通过sql中的d

8、rop 、truncate、delete函数实现；（3） 数据库锁的概念比较宽泛，本初所指的为排他锁，又称写锁，若事务T对数据对象A加锁，则只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。Sql中的HOLDLOCK函数同样可以实现，也可以通过客户端使用整张table的锁定。数据库不可用时，要根据系统的逻辑去判断是否会继续对系统有影响，以及如果存在关系时，系统的日志和告警能力是否完备。尽量保障系统故障后的尽快通知和恢复，那么除了问题出现后的处理，如何在其他方面尽量避免有系统导致的DB不可用的导致呢？（1） 数据库的容灾备份；（2） DB降级策略，导致D

9、B异常的情况有可能是因为外力也有可能是系统调用的原因，这里就不得不说一个DB降级的概念，DB的降级策略是否完备，也会在很大程度上关系到DB异常时对系统的影响的范围；（3） 系统SQL的优化，测试时SQL语句检查，可以一定程度上避免产生由系统导致的DB异常.2 缓存不可用比较常见的缓存有smemcache,nkv等，这类的异常也是大部分表现为缓存不可用，其中和数据库有些稍微不同的地方：缓存在一些系统中有可能不会是业务流程上的强依赖。而我们针对这类异常，应该要关注的是，业务出现异常时的返回信息，以及异常出现后对应的异常通知是否完善。另外除了缓存不可用以外，缓存的异常还会有缓存数据的过期，这类问题无

10、论定位于业务上还是，外部依赖上都要验证到此部分的内容。方案一 memcache异常（1） 通过shell中的Kill -9 pid和kill -19分别可以关闭和挂机服务，服务有可能包括socketserver或memcache（2） 通过缓存读写的工具或者java源生api对memcache操作，创建和修改缓存中不同的数据情况方案二 nkv异常Nkv系统包含两个端，CS和DS，所以针对nkv的不可用应该包含CS和DS两个方面p CS:config serverp DS:data serverp ns:namespacep client:NKV Client（1） 在Nkv连接异常，查看业务的

11、连续性。（2） Nkv数据修改和删除可以通过开发接口做操作，Tips：测试环境的nkv由于业务较多，测试中不能直接通过关闭服务的方式，可以在网络侧面做nkv的限制；.3 依赖的接口所在系统异常系统间的接口调用一般会出现调用系统升级，服务不可用等各种状况，针对这种我们无法预知情况，我们应该做好我们自身系统的异常测试策略处理。这一块的异常主要体现在系统对于不同的http错误返回码是否有正确处理，如http返回状态404、500、502、504等；这一块的内容尽量以mock的方式构造出对应的返回码，查看系统对于这块返回值的处理。4.1.2 组合的服务部分不可用异常所谓的组合服务，指的是一个流程中关联

12、多个外接系统，比较常见的有DB和缓存组合的情况，如我所接触到的系统中存在DB反写缓存的情况-系统查询数据时，首先查缓存，缓存未查到或有问题，去查数据库，查询完数据库返回信息，并反写数据到缓存中。类似于这种情况是应该要考虑异常场景两两组合分析，DB缓存现象异常正常可以获得数据，正常返回正常异常可以获得数据，正常返回异常异常无法返回数据，系统正常处理错误码Tips:针对于服务组合的情况，对于新的系统建议做debug调试，在代码走到不同的步骤时，加入不同的测试场景，如上图可以考虑增加：代码第一次走到缓存时正常，然后去查库，最后反写缓存时异常，查看代码逻辑处理是否正确。4.3网络异常网络异常也是线上系

13、统最常见，也是最难捕获的异常。每一个用户对应每一种的网络场景，有的可能是网络丢包严重，有的可能是网络抖动频繁，还有一些网络连接超时，在如此多的网络情况下，我们的系统是否仍然能够按照我们产品设计的结果展现，能否在出现网络问题时尽快恢复，是我们QA需要严密检查的重点。4.3.1 网络超时网络连接超时就是在程序默认的等待时间内没有得到服务器的响应。简单的说：就是你向服务端发送数据请求，然尔服务器没返回数据，或返回数据太慢导致未收到返回数据。这块的测试内容一方面要保障系统调用外部服务的网络超时后的恢复能力，业务可以正常延续；另一方面要检查系统之间配置的超时时间是否合理。 超时后的恢复系统

14、出现因为网络原因导致的超时后恢复网络，业务应该可以正常继续，系统应该保证，超时时所发送的请求异常已被处理，而不是网络恢复后，调用的系统仍然会处理之前超时的请求。QA可以使用一些jvm的监控工具或者通过日志的方式，模拟此场景，检查被调用接口响应策略，及时检查风险。 网络超时时间网络超时的原因有多种，而我们也可以在测试中通过一些手段，模拟出网络超时的情况。通过设置不同的超时时间，数据对比出，设置哪个超时时间是最合理的。如何选择最合理的，这主要体现在超时时间配置原则上超时时间配置应该考虑一下因素：用户的最大可以接受时间。站点的页面完成时间一般保证小于超过5秒。接口性能的情况。需要设置比

15、接口实际响应时间长，以容忍接口响应时间的波动。通俗讲，发送的请求在处理中时，尽量不要返回超时。网络环境的现状。根据响应体的长度，计算所需的数据包个数。考虑到超时重传，需要超过一次网络重传的时间，以免因网络临时丢包造成连锁反映。如果是机房网络，则可不关注此种情况这样一套系统调用，其中每个之间都存在超时时间设定，而这些之间的超时时间如何配置便需要我们通过异常测试出的数据予以分析说明。上图中的网络超时时间应该按照如下去配置：（1） 首先配置主系统-DB的超时时间：通过大范围的测试主系统到DB的调用时间；（2） 遵循上面所列的原则再次去配置ngnix到主系统的超时时间，这里同样需要多次的调用数据报告。

16、（3） 其次配置web服务到nginx服务的的超时时间（4） 再次配置nginx服务到web服务的的超时时间（5） 最后配置nginx响应请求的时间。（6） 最后对比开发提供的时间给出说明。4.3.2 网络丢包首先先介绍下网络丢包的概念：数据在internet上是以数据包为单位传输的，这就是说，不管网络线路有多好、网络设备有多强悍，你的数据都不会是以线性传输的，中间总是有空洞的。数据包的传输，不可能百分之百的能够完成，因为种种原因，总会有一定的损失。碰到这种情况，internet会自动的让双方的电脑根据协议来补包和重传该包。如果网络线路好、速度快，包的损失会非常小，补包和重传的工作也相对较易完

17、成，因此可以近似的将所传输的数据看做是无损的。但是，如果网络线路较差，数据的损失量就会非常大，补包工作又不是百分之百完成的。这种情况下，数据的传输就会出现空洞，造成丢包。所以说网络丢包在网络条件不理想的情况时，也是比较容易出现的一种场景，不同的网络丢包情况下系统的调用也会出现不同的情况，以及当网络丢包情况逐渐恢复时，系统业务处理能否正常统计系统间不同网络丢包，业务的成功率严格上来说当系统有比较多的外部系统调用，针对每个系统都要有网络丢包验证，针对网络丢包的测试需要不同数据的分析，尽量在设计网络丢包用例时，能覆盖不同丢包范围的数据测试。首先创建网络丢包的环境，可以在服务器环境上通过

18、shell语言模拟出系统间调用的丢包率（我们组内有工具可以使用）其次制定范围，引流或者创建较多的请求来统计当前丢包率，系统正常及失败的情况，这里不得不提一点的是做此测试需要大量数据的支持最后统计出不同网络丢包时的业务表现，总结出系统的能力网络丢包恢复时，业务恢复能力我们都知道了网络丢包是会有网络重发的机制，那么如果我们在网络丢包严重情况下有大量的数据请求过来，当前任务堆积重发，待网络正常是否会影响后续任务的处理呢。这其实也是我们需要关注的内容。我们可以模拟出大量请求并发过来的情况，如果网络正常后，新的请求排队，系统日志仍然在打印处理网络抖动时请求的任务的话。对于服务器的性能，以及

19、正常业务的使用都会产生很大的影响。所以我们在做网络丢包的测试时，除了关心不同情境下系统的表现，还要测试到网络丢包从严重到轻微到正常时的系统处理是否有问题。4.3.3 网络抖动网络抖动也是通信传输中另一种常见的现象，它所代表的是端和端之间传输的分组延迟变化的程度，网络超时和连接断开都属于抖动的情况，测试方式基本上和超时和丢包相似，所观察的指标包括JVM的线程池情况，以及服务器的性能指标，一般来说之前的网络超时和丢包已经测试详尽，这块内容可以忽略。4.3系统异常系统上线需要考虑到多用户和数据的压力，我们所说的系统问题，包括cpu、内存、磁盘等服务器监控指标。系统的稳定，除了做好服务器性能评估，还需

20、要验证系统的负载均衡是否正常，负载均衡正常主要体现在两个方面：一、 单个节点异常，其他节点会接管任务二、 节点有异常到恢复，流量恢复正常。对于系统异常的内容，更多的依赖于项目的部署架构，如果已经稳定的架构体系，这一块的内容可以筛减来做。5异常测试在项目中的实践5.1 系统架构我所在的项目系统架构基本如图所示：根据系统的结构，最终制定了如下的异常测试策略5.2 用例设计一、总体分成两大部分，应用层和系统层，在这里我把网络传输的异常具体到了具体系统中；二、应用层异常细化分了主系统的异常，外部依赖的服务异常，内部业务异常；三、主系统本次新增部分接口对数据库和缓存有依赖，所以在主系统异常中，我把缓存异常和数据库异常都列举出来，并且分别在不同的网络超时和不同的网络丢包率的环境设计用例。由于主系统中缓存和DB存在着反写以及流程串的关系，所以也拎出缓存和DB的联合做另外一条用例；四、手机账号系统对主系统存在接口调用关系，读写数据于nkv，设计用例时，主要针对调用nkv和调用主系统时，不同的网络条件下查看两端间的超时时间是否设置合理，以及通过查看log日志，统计出不同场景时的手机账号系统的响应和调用系统处理异常场景的能力。五、手机账号业务是一个web项目，针对web服务的一些特点，我这边对cookie和静态资源这块设计了cookie替换、静态资源找不到等做了一定的用例设计，对于