初探异常测试-副本讲述.docx

目录 异常测试 2 1．异常测试简述 2 2．为什么要做异常测试 2 3．异常测试场景 3 4．异常测试场景抽象和设计方案 4 4.1业务异常 4 4.1.1业务流程 4 4.1.2交互规范 4 4.2外部异常 6 4.1.1 独立的服务不可用异常 6 4.1.2 组合的服务部分不可用异常 8 4.3网络异常 10 4.3.1 网络超时 10 4.3.2 网络丢包 11 4.3.3 网络抖动 13 4.3系统异常 13 5．异常测试在手机账号项目中的实践 13 5.1 系统架构 13 5.2 用例设计 14 5.3 测试方法 15 6. 总结 16  异常测试 1．异常测试简述 软件交付最终用户使用之前，需要进行各种类型的测试，其中就包括异常测试。异常测试，是检测系统对异常情况的处理。 异常测试覆盖硬件或软件异常时的处理。测试方应通过人为制造错误情况测试系统对错误操作、错误报文的反应，检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束；一旦出现错误情况，系统是否能正常报告，并检查系统的错误提示是否清晰且充分；测试系统是否处理了用户的异常操作，还是造成死机或处理错误。 2．为什么要做异常测试 只有通过异常测试的软件产品，才可以保证软件在正式上线后长时间的保持良好的运营状态，给最终用户以信心。异常测试的结果也有助于为我们进一步的系统优化设计积累经验。  3．异常测试场景 根据URS组内的实践，将之前调研的异常测试需求进行一个分类并抽象成不同的场景，主要分为如下类 1.业务异常，主要从业务操作或业务流程方面考虑，一般会涵盖在功能测试中的逆向测试； 2.外部异常，一套完善的系统往往都有一些外部调用的服务，如依赖的DB，缓存，MQ，其他系统的接口等，在系统运行时，如果调用的这些服务出现异常，系统会如何处理这种异常情况，也是需要关注的重点。 3.网络异常，非常常见的一种异常场景，测试过程中基本上不会发现，并且线上很容易出现此类有关的问题。 4.系统异常，主要体现在系统健壮方面的能力，包含如内存、磁盘、cpu、集群负载均衡等 业务异常，基本上在URS项目中已经在功能用例中做了体现，在此不多赘述。 系统级异常，与部署在机器上的业务无关，也就是我们常说的体现在应用性能上面的可靠性，这又包含两方面内容系统的高可用和高恢复，： （1） 当存在系统级的异常时，系统应当有其他的负载机器继续接管服务，保证可用； （2） 负载机出现问题后的快速发现并恢复，无论是监控系统，或是人为处理，这也是需要系统上线后应有的保障体系 URS系统主系统工程整套的集群体系以及监控系统均已比较完备，所以针对这一块的异常测试，在之前做过的情况下，后续便缩减了此处的测试。 4．异常测试场景抽象和设计方案 4.1业务异常 4.1.1业务流程 业务需求是开发之源，也是测试之源。测试人员对业务需求的了解是非常非常重要的，针对于异常测试更是如此。异常测试就必须要熟悉所测软件的业务流程、相关业务领域知识等信息，只有这样才可以知道系统在什么情况下会发生异常，什么情况下容易发生人为错误。这需要测试人员和开发人员或者系统分析员甚至真正的业务人员一起讨论，根据软件的类型与特点设计测试案例，不能凭空猜想。只有这样设计出的案例才能够真正的测试到，由于关键业务需要或者变化发生了异常，在此时软件的处理能力。 这一类的测试案例可以包括： 特殊业务工作流程测试：测试软件不按照正规的流程，而是按照可能的但非正规的业务流程运行，是否会生成错误数据，或者造成原有数据的错误，甚至造成系统的瘫痪； 删除或修改系统的重要数据或配置文件测试：测试情况发生时系统是否能够正确的提示，指明系统的错误。在进行相应修补后，系统是否能够正常运行； 违规操作：这类测试可以包括，对现有重要业务数据的违规操作、用户越权业务操作等，测试系统是否有相关约束。如果发生类似事件，系统是否有补救措施，而不导致系统的瘫痪。 4.1.2交互规范 用户正确的操作是系统正常运行的前提。所以在测试的时候，一定要进行错误操作来测试软件系统的健壮性。在从操作需求方面设计异常测试的测试用例时，需要从用户或者操作者的每一步的操作中进行提炼，而且这些测试用例一定要可操作性强，输入、输出、操作步骤都应该明确。实际上这部分测试用例也是功能测试用例的一部分，只是他不是正常、按照用户需求说明书的操作而已。 这一块的内容包括输入框内容、页面跳转等一些方面，可以使用一些常用的测试用例设计方法来设计  4.2外部异常 系统的异常除了本身以外往往会出现在调用的外部的异常，通常指的是一些外部依赖服务的异常，如DB、缓存、MQ、外部接口的调用等。 4.1.1 独立的服务不可用异常 DB不可用 数据库是我们系统经常要使用到的功能对于DB的调用，在系统长时间的运行过程中，