幂等性在软件中是指调用接口或服务时,多次相同的输入会有相同的结果反馈和等同一次的处理结果。
但不是所有业务都需要保证幂等性,常用的那些场景需要保证幂等性呢?
1) 电商网站涉及订单提交;
2) 涉及金额方面:如:付款、转账、额度扣减;
3) 一些消息类发送等:如短信、邮件等;
4) 根据具体业务分析。如我所测试系统中:
日常测试过程中,我们需要根据具体的业务场景,在设计评审和案例设计过程中需确定哪些场景要保证幂等性,这样测试过程中才能快速发现问题。
测试方法:
前端、后端进行重复提交(目前很多系统已经做了小白级别的控制,即前端重复提交,但实际情况中,重点场景一定要做到前、后端均进行控制
目前很多提交都是异步提交,如短信发送,一般点击发送过去就会提示发送成功。但实际是否发生成功,后续会有系列处理机制,根据消息的一些本身机制,后续处理过程中会进行重发机制。(MQ中可设置重复发送机制)。
测试方法:
可在终端最后一步,或中间环节人为触发多次发生。如:在消息队列中重发,多次补收同一内容的报文等。
有些业务特意设置在链接超时或者失败时需重试,这时候就需要验证幂等性处理。
测试方法:
为提升效率,很多系统应用了缓存机制,尤其一些电商网站或时效性要求高的系统,需要关注:
如对商品重要属性进行了:新增、编辑(价格、库存等重要信息)、删除时,如应用了缓存机制,那测试过程中就需要关注:DB的修改要同步缓存中。
数据库的字段进行更新,缓存中的存储结构未进行更新。
测试方法:
有些关键数据放缓存中是有失效性的,需根据具体业务去了解相关失效性,还是永远存储。
测试方法:
根据业务关键性数据的设置缓存的时间来测试业务的失效性。
缓存溢出或丢失时,系统的业务是否能正常处理。
一般的处理逻辑:
总之:
缓存类测试,需设计阶段时就需要考虑:逻辑性、容错性、一致性等问题,测试人员也需了解相关方面的知识及机制。
事物测试的目的:
即在一个事物在某个节点发生故障,所有数据库状态的更新或一些操作(如给外围发了通知)能正确回滚到事物开始之前。(测试重点,日常类似问题会很多)
测试方法:
多个事物并发处理数据时,能互不干扰,保证数据的正确性。
测试方法:并发测试,大的方面主要包括:
具体举例如下(可忽略举例,比较啰嗦)
购买某一商品的活动序列:
电子商务网站中用户积分使用的一个活动序列:
正确的结果是:应该只有一方成功,另一方给出合理提示信息;
但处理不当就会导致:两个都成功,用户积分为负值
飞机订票系统中的一个活动序列:
结果明明卖出两张机票,数据库中机票余额只减少1。
什么是并发
多线程对同一段代码同时执行,叫并发;但单个cpu的硬件环境是不坑内个有多个线程,一般多个cpu才能实现多并发。
目前实现并发控制的方式:数据库行级锁:悲观锁、乐观锁;全局分布式锁;使用代码级别的同步(synchronized)和锁机制(Locks、atomic).代码级别的锁对于多机或分布式部署,不生效。
测试预防:
1)业务场景分析:那些功能会出现并发。
2)静态代码分析的一些工具可以检测出来。
3)设计评审阶段关注类似问题,从设计阶段规避。
金融行业,金额测试由为关键。
1) 金额极值测试,尤其和外围第三方交互过程中,对于大额度传输的测试。(传输类型不一致,会导致大金额成科学技术,会让千万以上数据按各位处理)
测试方法:
常规边界值,了解一些不同数据类型的处理格式。
2)金额中浮点问题:
1)是否进行了合理的四舍五入;
2)同一批次下,单条数据进行了四舍五入后,总合计是否正确,多一分或少一分
3)不同数据库下进度处理的测试(支持多数据库时,如有些数据库存储时会自动四舍五入,有些会做直接截取)
很多系统的一些关键字段值,都是按照一定的规则自动生成的。如时间戳+随机数;日期+数据库sequence numbe序列号或者时间戳+数据库自增长ID等,那测试过程中就要确保其唯一性,以及最大值时的处理机制。
测试方法:
先写到这里吧。