一些有价值bug产生的思考

一、异步处理时防止重复点击的逻辑校验

场景 打款请求时，进入异步处理的队列，生成一个任务号，存在如数据库，且状态为未完成。此时，若是并发操做，如重复点击或者重复调用接口，则发出的两条请求可能被分配到不一样服务器处理，此时数据库产生两条数据，同一任务id对应不一样进程id，属于异常场景。程序逻辑判断数据>2，不处理，则异步任务终止。

其中，重复点击致使产生两条数据的缘由仅为猜想，实际排查过程当中发现，前端已经作了防重复点击，多是后端的前置逻辑致使对同一批数据作两次请求

总结    不只在同步业务处理时须要注意并发问题，异步任务时也须要根据实现逻辑关注中间状态

解决  一、数据库加联合惟一索引，第二条数据写不进去，直接将数据库报错抛出

         二、忽略两天数据的场景，当作正常业务处理，两条都进行更新

         三、 排查产生两条数据的缘由，源头上杜绝

最终方案选择了2   当时我选择的是1和3,1做为当即解决的方案，在不动业务逻辑的场景下，解决问题，风险较小。3做为后续的溯源颇有必要。可是最后没争过开发

二、临时小需求对系统功能的影响，须要思考后再作回归

eg.列表新增字段的需求，须要新增一个时间标签。当作一个简单的回归时正常。可是这个列表中有三个写入的业务类型，其中一个写入类型与其余写入的函数不一样。此时，因为未对第三个业务类型进行回归，致使漏测。这也是为何测试须要参与设计评审的缘由。

分析：正常的业务场景和实现方式来讲，基于复用原则，和通用的代码实现方式，这种写入应该都是在同一个函数完成。可是防不胜防啊。需求急测试不能急，任何小的修改均可能对你以前的测试结果造成覆盖

三、客户端测试时，须要注意系统与原生兼容和交互，如获取权限，打开文件等

四、先后端交互问题，前端页面展现错误、请求参数错误、交互错误这种类型的bug咱就不提了。主要说一种，请求的同步和异步，也就是时间对请求结果的影响，和前端在处理请求结果时，是否会基于时间的考虑来展现返回结果。

先来个简单的例子，在某修改功能中，要求前端请求后进行查询，以便在列表展现上获取刚才的修改提交。此时，先发出修改请求，再发出查询请求，若是修改请求仍在处理，尚未成功，便返回查询结果，而后返回修改结果，修改为功。此时就形成了展现内容与实际结果不一致。因此查询接口应该等待修改接口返回结果后再发出

先后端交互中也存在同步异步问题。同步就是上面的例子。下面是先后端交互的两种异步场景。

a、轮询（polling） 间隔必定时间不断向后端发送请求，如导出功能，第一次请求导出时，后端给到一个任务id，而后前端拿着这个id每隔1秒请求一次。肯定就是消耗大，有延迟。延迟问题能够经过长轮询方式解决，具体自行扩展

b、websocket是跟http同样性质的传输协议。详细区别本身找找，这里就谈一个，http是单向的，websocket是双向的协议。因此很明了，websocket 协议中，服务器端会主动向浏览器端发送结果，进而能够下降延迟。缺点就是资源消耗大。因此在生命周期结束时，应该关闭链接