Open mylamour opened 6 years ago
最近在反作弊过程中,涉及到前端后端测试。以及运维安全(我自己)的沟通。在开始这篇随笔之前,让我们先思考三个问题。ps:当然以下思考受限于个人工作环境,实非我之所愿。面临诸多问题,也不得不反思一二。尤其是公司当前面临着的诸多问题。
注意:心态一定要好,心态一定要好,心态一定要好。另外,这种合作是以实现功能为目的而临时的组合,所以大家都是平级关系。好好相处最好。不配合的话,再找他们leader。团队合作或者跨团队合作过程中很重要的一环应该有项目激励,但是在当前的情景下,并不具有该条件,谁让我只是个搞技术的呢......
需求调研,安全研究,技术点demo,协调后端,协调前端,协调测试,效果分析。 判断涉及人员: Me, 后端一个,前端2个,测试一个 职责划分:
流程: 需求调研->安全研究->技术点demo
前期进行调研,阅读了下网易云盾运行方式。不知道为什么自己的脑袋特别清晰,就设计了下人机验证的流程。前端js逻辑计算和反调试,然后上传数据,比对计算值是否一致。当然这种方式阻挡不了模拟登陆。但同时上传行为数据,踢出登录缓存队列的token用来防止作弊。然后把这些方式设计出来,按阶段分出实现的先后。 设计完成之后,本人通过撰写前期的demo进行测试并向主要开发人员讲解思路,互相探讨是否有其他方案。然后对每个技术点进行测试。之后将原型代码交由前后端实行。
流程: 协调后端->协调前端->协调测试
根据技术点的落地难度(时间,准确度等)。技术点的实现交给后端测试完成,通过构建的单元测试后,交由前端对接。于此同时,前端将技术点的功能实现,等待后端进行接口对接。前端和后端联合测试,测试人员测试。
流程: 效果分析
对比之前之后效果,通过对NGINX访问,api调用日志,邮件请求,验证码请求数据,waf拦截日志。并对比前后数月和当前异常访问日期前后,进行分析。测试改技术是否能解决这个问题。当前来看,通过恶意注册的用户下降。
本地沟通其实没什么成本,和三位开发,两位沟通起来较好。另一位没有什么交集,但是水平一般,结果她copy代码的时候,出现了问题。然后配合后端进行了下调试,理清了问题之后,发现其在获取fingerprint的时候,代码出错。随后解决。
other: 自从后端leader走了之后,现在和后端的沟通容易了许多。整个过程基本没有出现什么异常,两天半就完成了该技术点的实施。目前正在测试环境收集用户行为信息,上传后台以备后期分析。针对前后端leader来讲,喜欢否定别人不是一件好事。最好能在讨论前经过自己的反思。例如,一次与其讨论,缓存是选择redis还是memcache呢?直接上来一句,现在谁用memcache谁是傻逼。那么问题来了,让你说说不出来的时候,不经讨论就下结论,不仅让人难以信服,还会让人觉得人品有问题。尤其是在不懂的领域。与其沟通的过程中,实在让人难以忍受。
敏捷开发的特点是快,准。跨团队沟通的开发过程中敏捷开发是一个较好的选择。而此时,敏捷开发面临的另一个问题就是跨团队沟通,当团队以职能为目的,聚集并非相熟的开发时,问题将更加有问题。所以还是有很多的问题。
下面是面临到的其他问题:
前言
最近在反作弊过程中,涉及到前端后端测试。以及运维安全(我自己)的沟通。在开始这篇随笔之前,让我们先思考三个问题。ps:当然以下思考受限于个人工作环境,实非我之所愿。面临诸多问题,也不得不反思一二。尤其是公司当前面临着的诸多问题。
注意:心态一定要好,心态一定要好,心态一定要好。另外,这种合作是以实现功能为目的而临时的组合,所以大家都是平级关系。好好相处最好。不配合的话,再找他们leader。团队合作或者跨团队合作过程中很重要的一环应该有项目激励,但是在当前的情景下,并不具有该条件,谁让我只是个搞技术的呢......
需求调研,安全研究,技术点demo,协调后端,协调前端,协调测试,效果分析。 判断涉及人员: Me, 后端一个,前端2个,测试一个 职责划分:
step 1: 第一阶段
流程: 需求调研->安全研究->技术点demo
前期进行调研,阅读了下网易云盾运行方式。不知道为什么自己的脑袋特别清晰,就设计了下人机验证的流程。前端js逻辑计算和反调试,然后上传数据,比对计算值是否一致。当然这种方式阻挡不了模拟登陆。但同时上传行为数据,踢出登录缓存队列的token用来防止作弊。然后把这些方式设计出来,按阶段分出实现的先后。 设计完成之后,本人通过撰写前期的demo进行测试并向主要开发人员讲解思路,互相探讨是否有其他方案。然后对每个技术点进行测试。之后将原型代码交由前后端实行。
step 2: 第二阶段
流程: 协调后端->协调前端->协调测试
根据技术点的落地难度(时间,准确度等)。技术点的实现交给后端测试完成,通过构建的单元测试后,交由前端对接。于此同时,前端将技术点的功能实现,等待后端进行接口对接。前端和后端联合测试,测试人员测试。
step 3: 第三阶段
流程: 效果分析
对比之前之后效果,通过对NGINX访问,api调用日志,邮件请求,验证码请求数据,waf拦截日志。并对比前后数月和当前异常访问日期前后,进行分析。测试改技术是否能解决这个问题。当前来看,通过恶意注册的用户下降。
沟通
本地沟通其实没什么成本,和三位开发,两位沟通起来较好。另一位没有什么交集,但是水平一般,结果她copy代码的时候,出现了问题。然后配合后端进行了下调试,理清了问题之后,发现其在获取fingerprint的时候,代码出错。随后解决。
other: 自从后端leader走了之后,现在和后端的沟通容易了许多。整个过程基本没有出现什么异常,两天半就完成了该技术点的实施。目前正在测试环境收集用户行为信息,上传后台以备后期分析。针对前后端leader来讲,喜欢否定别人不是一件好事。最好能在讨论前经过自己的反思。例如,一次与其讨论,缓存是选择redis还是memcache呢?直接上来一句,现在谁用memcache谁是傻逼。那么问题来了,让你说说不出来的时候,不经讨论就下结论,不仅让人难以信服,还会让人觉得人品有问题。尤其是在不懂的领域。与其沟通的过程中,实在让人难以忍受。
敏捷开发的特点是快,准。跨团队沟通的开发过程中敏捷开发是一个较好的选择。而此时,敏捷开发面临的另一个问题就是跨团队沟通,当团队以职能为目的,聚集并非相熟的开发时,问题将更加有问题。所以还是有很多的问题。
下面是面临到的其他问题: