初探异常测试.docx

《初探异常测试.docx》由会员分享，可在线阅读，更多相关《初探异常测试.docx（14页珍藏版）》请在第壹文秘上搜索。

1、初探异样测试书目异样测试21.异样测试简述22.为什么要做异样测试23异样测试场景31.异样测试场景抽象和设计方案44.1业务异样44.1.1业务流程4范41.1.1 外部异样64.1.1独立的服务不行用异样64.1.2组合的服务部分不行用异样84.3网络异样104.3.1网络超时101.1.2 网络丢包111.1.3 网络抖动134.3样135.异样测试在手机账号项目中的实践135.1系统架构13 5.2用例设计14 5.3测试方法15 6.总结15异样测试1.异样测试简述软件交付最终用户运用之前，须要进行各种类型的测试，其中就包括异样测试。异样测试，是检测系统对异样状况的处理。异样测试覆盖

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

3、务流程方面考虑，一般会涵盖在功能测试中的逆向测试；2.外部异样，一套完善的系统往往都有一些外部调用的服务，如依靠的DB,缓存，MQ,其他系统的接口等，在系统运行时，假如调用的这些服务出现异样，系统会如何处理这种异样状况，也是须要关注的重点。3 .网络异样，特别常见的一种异样场景，测试过程中基本上不会发觉，并且线上很简洁出现此类有关的问题。4 .系统异样，主要体现在系统健壮方面的实力，包含如内存、磁盘、cpu、集群负载均衡等业务异样，基本上在URS项目中已经在功能用例中做了体现，在此不多赘述。系统级异样，与部署在机器上的业务无关，也就是我们常说的体现在应用性能上面的牢靠性，这又包含两方面内容系统

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

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

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

7、往往会出现在调用的外部的异样，通常指的是一些外部依靠服务的异样，如DB、缓存、MQ,外部接口的调用等。4.1.1独立的服务不行用异样4.1.1JDB不行用4.1.1独立的服务不行用异样4.1.1.IDB不行用数据库是我们系统常常要运用到的功能对于DB的调用，在系统长时间的运行过程中，总是会有一部分线上问题是由于DB连接的异样导致的。我们常说的DB异样基本上可以总结为DB的不行用异样，DB不行用又可以分为：DB服务不行用，DB挂起，DB不存在，DB锁等，一般不同的状况，代码中会抛出不同的异样，但这些种现象表现在调用上往往都是表现为服务不行用，可做同一状况处理。方案一（1）通过she1.1.中的K

8、i1.1.-9pid和ki1.1.-19分别可以关闭和挂机服务；（2）DB不存在可以通过sq1.中的drop、truncate,de1.ete函数实现：（3）数据库锁的概念比较宽泛，本初所指的为排他锁，乂称写锁，若事务T对数据对象A加锁，则只允许T读取和修改A,其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。Sq1.中的HO1.D1.OCK函数同样可以实现，也可以通过客户端运用整张tab1.e的锁定。数据库不行用时，要依据系统的逻辑去推断是否会接着对系统有影响，以及假如存在关系时，系统的日志和告警实力是否完备。尽量保障系统故障后的尽快通知和复原，那么除了问题出现后的处理，如何在其他

9、方面尽量避开有系统导致的DR不行用的导致呢？（1）数据库的容灾备份：（2）DB降级策略，导致DB异样的状况有可能是因为外力也有可能是系统调用的缘由，这里就不得不说一个DB降级的概念，DB的降级策略是否完备，也会在很大程度上关系到DB异样时对系统的影响的范围；（3）系统SQ1.的优化，测试时SQ1.语句检查，可以肯定程度上避开产生由系统导致的DB异样.4.1.1.2缓存不行用比较常见的缓存有SnIemCaChe,nkv等，这类的异样也是大部分表现为缓存不行用，其中和数据库有些略微不同的地方：缓存在一些系统中有可能不会是业务流程上的强依靠。而我们针对这类异样，应当要关注的是，业务出现异样时的返回信

10、息，以及异样出现后对应的异样通知足否完善。另外除了缓存不行用以外，缓存的异样还会有缓存数据的过期,这类问题无论定位于业务上还是，外部依靠上都要验证到此部分的内容。方案-memcache异样（1）通过she1.1.中的Ki1.1.-9pid和ki1.1.-19分别可以关闭和挂机服务，服务有可能包括socketserver或memcache（2）通过缓存读写的工具或者java源生api对memcache操作，创建和修改缓存中不同的数据状况方案二nkv异样Nkv系统包含两个端,CS和DS,所以针对nkv的不行用应当包含CS和DS两个方面（1）在Nkv连接异样，查看业务的连续性。（2）Nkv数据修改和

11、删除可以通过开发接口做操作，Tips：测试环境的nkv由于业务较多，测试中不能干脆通过关闭服务的方式，可以在网络侧面做nkv的限制：4.1.1.3依靠的接口所在系统异样系统间的接口调用一般会出现调用系统升级，服务不行用等各种状况，针对这种我们无法预知状况，我们应当做好我们自身系统的异样测试策略处理。这一块的异样主要体现在系统对于不同的错误返回码是否有正确处理，如返回状态404、500、502、504等：这一块的内容尽量以mock的方式构造出对应的返回码，查看系统对于这块返回值的处理。4.1.2组合的服务部分不行用异样所谓的组合服务，指的是一个流程中关联多个外接系统，比较常见的有DB和缓存组合的

12、状况,如我所接触到的系统中存在DB反写缓存的状况-系统杳询数据时，首先查缓存，缓存未查到或有问题，去查数据库，查询完数据库返回信息，CSzconfigserverDS:dataserverns:namespacec1.ient:NKVC1.ient并反写数据到缓存中。类似于这种状况是应当要考虑异样场景两两组合分析，DB缓存现象异样正常可以获得数据，正常返回正常异样可以获得数据，正常返回异样异样无法返回数据，系统正常处理错误码TiPS:针对于服务组合的状况，对于新的系统建议做debug调试，在代码走到不同的步骤时，加入不同的测试场景，如上图可以考虑增加：代码第一次走到缓存时正常，然后去查库，最终

13、反写缓存时异样，杏看代码逻辑处理是否正确。34.3网络异样网络异样也是线上系统最常见，也是最难捕获的异样。每一个用户对应每一种的网络场景，有的可能是网络丢包严峻,有的可能是网络抖动频繁，还有一些网络连接超时，在如此多的网络状况下，我们的系统是否仍旧能够依据我们产品设计的结果呈现，能否在出现网络问题时尽快复原，是我们QA须要严密检查的重点。4.3.1网络超时网络连接超时就是在程序默认的等待时间内没有得到服务器的响应。简洁的说：就是你向服务端发送数据恳求，然尔服务器没返回数据，或返回数据太慢导致未收到返回数据。这块的测试内容一方面要保障系统调用外部服务的网络超时后的复原实力，业务可以正常持续；另一

14、方面要检查系统之间配置的超时时间是否合理。4.3.1.1超时后的复原系统出现因为网络缘由导致的超时后红原网络，业务应当可以正常接着，系统应当保证，超时时所发送的恳求异样已被处理，而不是网络复原后，调用的系统仍旧会处理之前超时的恳求。QA可以运用一些jvm的监控工具或者通过日志的方式，模拟此场景，检查被调用接口响应策略，刚好检杳风险。4.3.1.2网络超时时间网络超时的缘由有多种，而我们也可以在测试中通过一些手段，模拟出网络超时的状况。通过设置不同的超时时间，数据对比出，设置哪个超时时间是电合理的。如何选择最合理的，这主要体现在超时时间配置原则上超时时间配置应当考虑一下因素:用户的最大可以接受时

15、间。站点的页面完成时间一般保证小于超过5秒。接口性能的状况。须要设置比接I-I实际响应时间长，以容忍接口响应时间的波动。通俗讲，发送的恳求在处理中时，尽量不要返回超时。网络环境的现状。依据响应体的长度，计算所需的数据包个数。考虑到超时重传，须要超过一次网络重传的时间，以免因网络临时丢包造成连锁反映。假如是机房网络，则可不关注此种状况这样一套系统调用，其中每个之间都存在超时时间设定，而这些之间的超时时间如何配置便须要我们通过异样测试出的数据予以分析说明。上图中的网络超时时间应当依据如下去配置：(1)首先配置主系统一-DB的超时时间：通过大范围的测试主系统到DB的调用时间：(2)遵循上面所列的原则再次去配置ngnix到主系统的超时时间，这里同样须要多次的调用数据报告。(3)其次配置Web服务到nginx服务的的超时时间(4)再次配置nginx服务到Web服务的的超时时间(5)最终配置nginx响应恳求的时间。(6)最终对比开发供应的时间给出说明。4.3.2 网络丢包首先先介绍下网络丢包的概念：数据在internet上是以数据包为单位传输的，这就是说，不管网络线路有多好、网络设备有多强悍，你