不得不关注的【异常测试】

2021-07-20   出处:软件测试君  作/译者:软件测试君  

        测试过程中,有些异常场景,需特别关注,下面是我整理的一些容易碰到有很容易引起重大问题的异常点,需从代码设计阶段需考虑进去的问题。

一、幂等性测试

        幂等性在软件中是指调用接口或服务时,多次相同的输入会有相同的结果反馈和等同一次的处理结果。

1、常见幂等性场景

        但不是所有业务都需要保证幂等性,常用的那些场景需要保证幂等性呢?

2、幂等性导致问题的常见原因

        1) 电商网站涉及订单提交;

        2) 涉及金额方面:如:付款、转账、额度扣减;

        3) 一些消息类发送等:如短信、邮件等;

        4) 根据具体业务分析。如我所测试系统中:

        ● 保证金追加

        ● 同一张票业务唯一性

        ● 发送外围系统的一些重要通知等;

        日常测试过程中,我们需要根据具体的业务场景,在设计评审和案例设计过程中需确定哪些场景要保证幂等性,这样测试过程中才能快速发现问题。

3、常见场景

3.1、用户重复提交

        测试方法:

        前端、后端进行重复提交(目前很多系统已经做了小白级别的控制,即前端重复提交,但实际情况中,重点场景一定要做到前、后端均进行控制

3.2、网络或消息重发

        目前很多提交都是异步提交,如短信发送,一般点击发送过去就会提示发送成功。但实际是否发生成功,后续会有系列处理机制,根据消息的一些本身机制,后续处理过程中会进行重发机制。(MQ中可设置重复发送机制)。

        测试方法:

        可在终端最后一步,或中间环节人为触发多次发生。如:在消息队列中重发,多次补收同一内容的报文等。

3.3、业务间的重试

        有些业务特意设置在链接超时或者失败时需重试,这时候就需要验证幂等性处理。

        测试方法:

        ● 设计评审期间多关注

        ● 模拟网络连接超时等触发重发机制。

二、缓存机制测试

        为提升效率,很多系统应用了缓存机制,尤其一些电商网站或时效性要求高的系统,需要关注:

        ● 如何保持与DB同步性(即数据的实时性)

        ● 缓存设置的失效性

        ● 缓存异常时处理机制

        ● 缓存数据的存储结构等就是测试时需关注的重点。

2.1、DB同步性(测试重点)

        如对商品重要属性进行了:新增、编辑(价格、库存等重要信息)、删除时,如应用了缓存机制,那测试过程中就需要关注:DB的修改要同步缓存中。

        数据库的字段进行更新,缓存中的存储结构未进行更新。

        测试方法:

        ● 了解缓存内容,对数据进行操作;操作后缓存相应展示页面查看(一般前台页面查询时会体现。

        ● 如数据库结构发生变化,需测试缓存中数据的存储

2.2、缓存失效性

        有些关键数据放缓存中是有失效性的,需根据具体业务去了解相关失效性,还是永远存储。

        测试方法:

        根据业务关键性数据的设置缓存的时间来测试业务的失效性。

2.3、缓存异常时系统处理(异常测试重点)

        缓存溢出或丢失时,系统的业务是否能正常处理。

        一般的处理逻辑:

        ● 重试机制

        ● 数据获取切换的DB。总之,不能因缓存异常,影响业务。

        总之:

        缓存类测试,需设计阶段时就需要考虑:逻辑性、容错性、一致性等问题,测试人员也需了解相关方面的知识及机制。

三、事物测试

        事物测试的目的:

3.1、确保事物原子性:

        即在一个事物在某个节点发生故障,所有数据库状态的更新或一些操作(如给外围发了通知)能正确回滚到事物开始之前。(测试重点,日常类似问题会很多)

        测试方法:

        ● 测试时模拟事务正常返回失败时的系统处理机制;

        ● 测试时,对数据库:做手脚,如事物中要进行数据库更新,则可对该数据进行行锁、或删除数据、或试数据状态无效,导致事务某一操作失败,进行了事物回滚。

        ● 大事物测试:如一个大事物中,包含了多个事物,需考虑事物之前逻辑顺序,以及模拟各个事物失败时,整个大事物的处理逻辑。

3.2、确保事物隔离性:

        多个事物并发处理数据时,能互不干扰,保证数据的正确性。

        测试方法:并发测试,大的方面主要包括:

        ● 同时新增(主要看唯一性验证);

        ● 对同一数据同时修改保存;对同一数据一方删除,一方修改;对同一数据两方同时删除;

        具体举例如下(可忽略举例,比较啰嗦)

        购买某一商品的活动序列:

        ● 客户在前端选择了商品,此时该商品的价格、数量等都已经确定,系统也对其做了相应的计算,单未提交;

        ● 系统管理员在管理端对该商品进行操作,如:删除、修改数量、修改金额、商品下架等

        ● 此时回到步骤1的页面,点击【提交】看系统如何处理?

        电子商务网站中用户积分使用的一个活动序列:

        ● 某一客户在机器A上读取自己账户的积分为100元;

        ● 在机器B上读取自己账户的积分同样为100元;

        ● 在A机器上使用该客户80元积分;

        ● 在B机器上使用该客户70元积分;

        ● 此时在A.B两个机器上的操作员对使用积分的购物同时点击【提交】

        正确的结果是:应该只有一方成功,另一方给出合理提示信息;

        但处理不当就会导致:两个都成功,用户积分为负值

        飞机订票系统中的一个活动序列:

        ● 甲售票点(甲事务)读出某航班的机票余额A,设A=16.

        ● 乙售票点(乙事务)读出同一航班的机票余额A,也为16.

        ● 甲售票点卖出一张机票,修改余额A←A-1.所以A为15,把A写回数据库.

        ● 乙售票点也卖出一张机票,修改余额A←A-1.所以A为15,把A写回数据库.

        结果明明卖出两张机票,数据库中机票余额只减少1。

四、并发测试

        什么是并发

        多线程对同一段代码同时执行,叫并发;但单个cpu的硬件环境是不坑内个有多个线程,一般多个cpu才能实现多并发。

        目前实现并发控制的方式:数据库行级锁:悲观锁、乐观锁;全局分布式锁;使用代码级别的同步(synchronized)和锁机制(Locks、atomic).代码级别的锁对于多机或分布式部署,不生效。

        测试预防:

        1)业务场景分析:那些功能会出现并发。

        2)静态代码分析的一些工具可以检测出来。

        3)设计评审阶段关注类似问题,从设计阶段规避。

五、其它

5.1、金额相关

        金融行业,金额测试由为关键。

        1) 金额极值测试,尤其和外围第三方交互过程中,对于大额度传输的测试。(传输类型不一致,会导致大金额成科学技术,会让千万以上数据按各位处理)

        测试方法:

        常规边界值,了解一些不同数据类型的处理格式。

        2)金额中浮点问题:

        1)是否进行了合理的四舍五入;

        2)同一批次下,单条数据进行了四舍五入后,总合计是否正确,多一分或少一分

        3)不同数据库下进度处理的测试(支持多数据库时,如有些数据库存储时会自动四舍五入,有些会做直接截取)

5.2、流水号、业务编号(如订单号)等唯一性及最大值测试。

        很多系统的一些关键字段值,都是按照一定的规则自动生成的。如时间戳+随机数;日期+数据库sequence numbe序列号或者时间戳+数据库自增长ID等,那测试过程中就要确保其唯一性,以及最大值时的处理机制。

        测试方法:

        ● 通过并发测试,检测其唯一性。

        ● 通过修改一些序列号或自增长ID到最大值后,检查系统处理机制。如用sequence序列号数据库修改到最大,检查是否能合理生产唯一编号)

        先写到这里吧。

        

        


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
127°|1276 人阅读|0 条评论

登录 后发表评论