《初探异常测试 - 副本》由会员分享，可在线阅读，更多相关《初探异常测试 - 副本（15页珍藏版）》请在金锄头文库上搜索。
1、目录异常测试21异常测试简述22为什么要做异常测试23异常测试场景34异常测试场景抽象和设计方案44.1业务异常44.1.1业务流程44.1.2交互规范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项目中已经在功能用例中做了体现，在此不多赘述。系统级异常，与部署在机器上的业务无关，也就是我们常说的体现在应用性能上面的可靠性，这又包含两方面内容系统的高可用和
4、高恢复，：（1） 当存在系统级的异常时，系统应当有其他的负载机器继续接管服务，保证可用；（2） 负载机出现问题后的快速发现并恢复，无论是监控系统，或是人为处理，这也是需要系统上线后应有的保障体系URS系统主系统工程整套的集群体系以及监控系统均已比较完备，所以针对这一块的异常测试，在之前做过的情况下，后续便缩减了此处的测试。4异常测试场景抽象和设计方案4.1业务异常4.1.1业务流程业务需求是开发之源，也是测试之源。测试人员对业务需求的了解是非常非常重要的，针对于异常测试更是如此。异常测试就必须要熟悉所测软件的业务流程、相关业务领域知识等信息，只有这样才可以知道系统在什么情况下会发生异常，什么情
5、况下容易发生人为错误。这需要测试人员和开发人员或者系统分析员甚至真正的业务人员一起讨论，根据软件的类型与特点设计测试案例，不能凭空猜想。只有这样设计出的案例才能够真正的测试到，由于关键业务需要或者变化发生了异常，在此时软件的处理能力。这一类的测试案例可以包括：特殊业务工作流程测试：测试软件不按照正规的流程，而是按照可能的但非正规的业务流程运行，是否会生成错误数据，或者造成原有数据的错误，甚至造成系统的瘫痪；删除或修改系统的重要数据或配置文件测试：测试情况发生时系统是否能够正确的提示，指明系统的错误。在进行相应修补后，系统是否能够正常运行；违规操作：这类测试可以包括，对现有重要业务数据的违规操作
6、、用户越权业务操作等，测试系统是否有相关约束。如果发生类似事件，系统是否有补救措施，而不导致系统的瘫痪。4.1.2交互规范用户正确的操作是系统正常运行的前提。所以在测试的时候，一定要进行错误操作来测试软件系统的健壮性。在从操作需求方面设计异常测试的测试用例时，需要从用户或者操作者的每一步的操作中进行提炼，而且这些测试用例一定要可操作性强，输入、输出、操作步骤都应该明确。实际上这部分测试用例也是功能测试用例的一部分，只是他不是正常、按照用户需求说明书的操作而已。这一块的内容包括输入框内容、页面跳转等一些方面，可以使用一些常用的测试用例设计方法来设计4.2外部异常系统的异常除了本身以外往往会出现在
7、调用的外部的异常，通常指的是一些外部依赖服务的异常，如DB、缓存、MQ、外部接口的调用等。4.1.1 独立的服务不可用异常4.1.1.1 DB不可用数据库是我们系统经常要使用到的功能对于DB的调用，在系统长时间的运行过程中，总是会有一部分线上问题是由于DB连接的异常导致的。我们常说的DB异常基本上可以总结为DB的不可用异常，DB不可用又可以分为：DB服务不可用，DB挂起，DB不存在， DB锁等，一般不同的情况，代码中会抛出不同的异常，但这些种现象表现在调用上往往都是表现为服务不可用，可做同一情况处理。方案一（1） 通过shell中的Kill -9 pid和kill -19分别可以关闭和挂机服务
8、；（2） DB不存在可以通过sql中的drop、truncate、delete函数实现；（3） 数据库锁的概念比较宽泛，本初所指的为排他锁，又称写锁，若事务T对数据对象A加锁，则只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。Sql中的HOLDLOCK函数同样可以实现，也可以通过客户端使用整张table的锁定。数据库不可用时，要根据系统的逻辑去判断是否会继续对系统有影响，以及如果存在关系时，系统的日志和告警能力是否完备。尽量保障系统故障后的尽快通知和恢复，那么除了问题出现后的处理，如何在其他方面尽量避免有系统导致的DB不可用的导致呢？（1） 数据库的容灾备份；
9、（2） DB降级策略，导致DB异常的情况有可能是因为外力也有可能是系统调用的原因，这里就不得不说一个DB降级的概念，DB的降级策略是否完备，也会在很大程度上关系到DB异常时对系统的影响的范围；（3） 系统SQL的优化，测试时SQL语句检查，可以一定程度上避免产生由系统导致的DB异常.4.1.1.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 Clie
11、nt（1） 在Nkv连接异常，查看业务的连续性。（2） Nkv数据修改和删除可以通过开发接口做操作，Tips：测试环境的nkv由于业务较多，测试中不能直接通过关闭服务的方式，可以在网络侧面做nkv的限制；4.1.1.3 依赖的接口所在系统异常系统间的接口调用一般会出现调用系统升级，服务不可用等各种状况，针对这种我们无法预知情况，我们应该做好我们自身系统的异常测试策略处理。这一块的异常主要体现在系统对于不同的http错误返回码是否有正确处理，如http返回状态404、500、502、504等；这一块的内容尽量以mock的方式构造出对应的返回码，查看系统对于这块返回值的处理。4.1.2 组合的服务
12、部分不可用异常所谓的组合服务，指的是一个流程中关联多个外接系统，比较常见的有DB和缓存组合的情况，如我所接触到的系统中存在DB反写缓存的情况-系统查询数据时，首先查缓存，缓存未查到或有问题，去查数据库，查询完数据库返回信息，并反写数据到缓存中。类似于这种情况是应该要考虑异常场景两两组合分析，DB缓存现象异常正常可以获得数据，正常返回正常异常可以获得数据，正常返回异常异常无法返回数据，系统正常处理错误码Tips:针对于服务组合的情况，对于新的系统建议做debug调试，在代码走到不同的步骤时，加入不同的测试场景，如上图可以考虑增加：代码第一次走到缓存时正常，然后去查库，最后反写缓存时异常，查看代码
13、逻辑处理是否正确。4.3网络异常网络异常也是线上系统最常见，也是最难捕获的异常。每一个用户对应每一种的网络场景，有的可能是网络丢包严重，有的可能是网络抖动频繁，还有一些网络连接超时，在如此多的网络情况下，我们的系统是否仍然能够按照我们产品设计的结果展现，能否在出现网络问题时尽快恢复，是我们QA需要严密检查的重点。4.3.1 网络超时网络连接超时就是在程序默认的等待时间内没有得到服务器的响应。简单的说：就是你向服务端发送数据请求，然尔服务器没返回数据，或返回数据太慢导致未收到返回数据。这块的测试内容一方面要保障系统调用外部服务的网络超时后的恢复能力，业务可以正常延续；另一方面要检查系统之间配置的
14、超时时间是否合理。4.3.1.1 超时后的恢复系统出现因为网络原因导致的超时后恢复网络，业务应该可以正常继续，系统应该保证，超时时所发送的请求异常已被处理，而不是网络恢复后，调用的系统仍然会处理之前超时的请求。QA可以使用一些jvm的监控工具或者通过日志的方式，模拟此场景，检查被调用接口响应策略，及时检查风险。4.3.1.2 网络超时时间网络超时的原因有多种，而我们也可以在测试中通过一些手段，模拟出网络超时的情况。通过设置不同的超时时间，数据对比出，设置哪个超时时间是最合理的。如何选择最合理的，这主要体现在超时时间配置原则上超时时间配置应该考虑一下因素：用户的最大可以接受时间。站点的页面完成时
15、间一般保证小于超过5秒。接口性能的情况。需要设置比接口实际响应时间长，以容忍接口响应时间的波动。通俗讲，发送的请求在处理中时，尽量不要返回超时。网络环境的现状。根据响应体的长度，计算所需的数据包个数。考虑到超时重传，需要超过一次网络重传的时间，以免因网络临时丢包造成连锁反映。如果是机房网络，则可不关注此种情况这样一套系统调用，其中每个之间都存在超时时间设定，而这些之间的超时时间如何配置便需要我们通过异常测试出的数据予以分析说明。上图中的网络超时时间应该按照如下去配置：（1） 首先配置主系统-DB的超时时间：通过大范围的测试主系统到DB的调用时间；（2） 遵循上面所列的原则再次去配置ngnix到主系统的超时时间，这里同样需要多次的调用数据报告。（3） 其次配置web服务到nginx服务的的超时时间（4） 再次配置nginx服务到web服务的的超时时间（5） 最后配置nginx响应请求的时间。（6） 最后对比开发提供的时间给出说明。4.3.2 网络丢包首先先介绍下网络丢包的概念：数据在internet上是以数据包为单位传输的，这就是说，不管网络线路有多
