测试过程中，有些异常场景，需特别关注，下面是我整理的一些容易碰到有很容易引起重大问题的异常点，需从代码设计阶段需考虑进去的问题。
一、幂等性测试
幂等性在软件中是指调用接口或服务时，多次相同的输入会有相同的结果反馈和等同一次的处理结果。
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） 金额极值测试，尤其和外围第三方交互过程中，对于大额度传输的测试。（传输类型不一致，会导致大金额成科学技术，会让千万以上数据按各位处理）
测试方法：
常规边界值，了解一些不同数据类型的处理格式。
２）金额中浮点问题：
１）是否进行了合理的四舍五入；
２）同一批次下，单条数据进行了四舍五入后，总合计是否正确，多一分或少一分
３）不同数据库下进度处理的测试（支持多数据库时，如有些数据库存储时会自动四舍五入，有些会做直接截取）
5.2、流水号、业务编号（如订单号）等唯一性及最大值测试。
很多系统的一些关键字段值，都是按照一定的规则自动生成的。如时间戳+随机数；日期+数据库sequence numbe序列号或者时间戳+数据库自增长ID等，那测试过程中就要确保其唯一性，以及最大值时的处理机制。
测试方法：
● 通过并发测试，检测其唯一性。
● 通过修改一些序列号或自增长ID到最大值后，检查系统处理机制。如用sequence序列号数据库修改到最大，检查是否能合理生产唯一编号）
先写到这里吧。
