其实就是老老实实玩，对于一些专门找bug的玩家就是找系统漏洞。如果在枪战FPS游戏里也就是，一些高难度的动作，基本上想象力丰富的人最容易发现bug对这些我也有点无语。。。唉我的想象力可能还不够吧！bug没有偶然，他只是系统的漏洞，也就是设计师和编程工作人员，的疏忽大意而已！所以大部分游戏（网游），就是在一开始组织内测，为的就是找到漏洞！只是看你有没有心思去找！所以如果你是个老实的玩家不想找bug话。就老老实实玩吧！碰着的几率是10%，看你的运气了！但是如果你是一个爱找bug的玩家的话，就多做一些意想不到的事情！比如狼队吧！对着墙把包往头上安，就能和包飞起来哦！！！好了，如果还有问题找我吧！
破坏领主中现版本存在着许多BUG,虽然很多BUG会导致玩家的游戏体验变得十分差,但是依然存在着许多良性BUG，下面就为大家分享破坏领主BUG汇总及已知良性BUG使用方法,一起来看看吧
已知BUG汇总
正面BUG
1天赋-暴政天灾 忘记加百分号 盾牌每点格挡05%增伤变成了50%增伤
2大秘境掉宝BUFF每次切换地图会叠加，无限进出地图可以无限叠加掉宝率[已修复]
3两个同样宝石堆在一起 按住SHIFT 拆分 堆叠 再分开 再堆叠 钱数无限往上叠加
4天赋-稳固招架 +10%生命回复 不是按照自己生命回复计算 而是按照自己最大生命上限计算
5血斧符文-暴虐耐心 数值设置过高-未测试具体数值 貌似还有法系技能里也有类似的天赋
6天赋-维特斯姿态 寻隙姿态并不会牺牲全抗 相反忠贞姿态会额外获得全抗
7格挡天赋在人物吃完所有词缀加成后再计算加成，就是说盾牌如果在词缀加成下格挡几率和格挡效果很高，
天赋点满加上衣服格挡可以堆出来几乎无敌的状态
负面BUG
1使用改变物品属性的相关道具和生产行为 有几率导致无法读取人物数据 玩不了游戏!!
2尽量不要沿着墙边使用位移技能，大几率卡进去出不来。
3天赋-信仰吮吸 护盾满的时候吸一口 护盾立刻爆表清零
1 拿到一个新 bug, 首先要重现问题 这对 code 问题是必须的, 对客户的 data 问题, 几乎也是必须的 如果是 code 问题, 不重现就没办法修改代码, 改好了也无法验证是不是改对了 客户的 data 出问题, 多数情况也是能够重现的 毕竟客户是用我们的系统操作的
1 拿到一个新 bug, 首先要重现问题 这对 code 问题是必须的, 对客户的 data 问题, 几乎也是必须的 如果是 code 问题, 不重现就没办法修改代码, 改好了也无法验证是不是改对了 客户的 data 出问题, 多数情况也是能够重现的 毕竟客户是用我们的系统操作的, 只要拿到客户的历史数据, 对照着是可以自己做出同样的数据 以前我遇到 data fix 的时候不喜欢重现, 都是凭感觉给出脚本 但这样常常忽略一些重要的数据, 容易出错 如果确定是 data fix, 我们就默认 code 是没有问题的, 给出的脚本就应该和在系统上正确操作得到的结果保持一致
2 重现了 bug, 熟悉了整个流程, 就知道问题出在哪儿, 正确的行为应该是怎样的 这时不是急急忙忙的去分析, 而是去查找 找什么呢 就是找以前的人是不是遇到过同样的问题 查找主要是在 Bug 系统里面, 和 Support 网站上 Bug 系统里面有所有 bug 的历史数据, 根据关键词可以找到类似甚至相同的 bug 可以看看之前是怎样解决的 这对 data fix 尤其好用, 因为同一个问题出现 data 问题的几率相对比较高, 参考之前给出的脚本能减少很多劳动 Support 网站上有很多开发和 support 写的 Note, 查找关键字可以找到类似的问题 这个对 code fix 非常好用 如果之前已经解决这个 code 问题的话, 直接根据 note 打补丁就好了
3 如果 code fix 是不能重现的, 那么多数情况下, 这个问题已经被改过了 客户由于文件版本较低, 还存在这个问题 去上面两个网站去找相应的补丁
4 如果在这两个网站都没有找到相似的 bug, 那么恭喜你, 遇到了一个新的问题, 你要从头开始自己分析了
5 分析的工具无非就是 log 看 log, 可以跟踪代码走到了哪里 对我们 INV team 来说, 几个常用的 log 是:
a) INV log
INV log 记录了服务器端代码的流程, 就是 pls 文件的 log 如果在文件开头的地方有读取 FND_PROFILEVALUE('INV_DEBUG_TRACE') 的话, 那么这个文件的日志就是记录在 INV log 里面的 拿到这个日志, 对于分析代码走到了哪一步非常有用
b) RTP log
RTP log 是记录系统跑 concurrent request: receiving transaction processor 所记录下的日志 如果打过 9184617:R12POA 这个patch, 也就是 rvtptlpc的版本要高于这个版本120191200000025 , 那么就可以在 INV log 里面看到RTP 的 log 了 如果没有打过这个patch, 那么就只能用老办法去收集了 收集的办法是记录下 RTP id, 然后用下面的 SQL:
select module, to_char(timestamp,'DD-MON-YYYY HH24:MI:SS'), message_text
from fnd_log_messages
where timestamp > sysdate - 2/24
and process_id = ( select os_process_id from fnd_concurrent_requests where request_id = &request_id)
and module like 'po%'
c) FRD log
FRD 的全称是 forms runtime diagnostics, 就是记录 form 运行时候所有触发器的日志 这个里面可以清楚的看到触发器触发的顺序, 以及在里面做了什么事情 如果客户的 bug 是属于 form runtime 进程报错的话, 里面就会显示在那个触发器里面报的错, 然后要做的事情就是看代码了
d) SQL trace
SQL trace 记录的是数据库所有的操作的日志 包括所有的操作语句, 绑定值, 性能问题, 还有 SQL 报错 只要看报什么错, 找到那句 SQL, 差不多就解决了一半问题了
e) fnd_new_messages
这是数据库的一个表, 记录了所有的错误信息 如果客户报了一个错, 可以通过下面的 SQL 去找到对应的错误记录
select from fnd_new_messages where message_text like 'Quantity entered should be less than or equal to available quantity%'
然后到代码里面去找到报错的地方就好了 通常一个错误信息只在一个地方报出来, 所有很容易找到对应的代码
通过上面的几个日志, 差不多能够定位到 bug 发生的代码了 接下来的事情就是去 code fix 或者给客户提供脚本
最后重要的一点就是, 无论 code fix 还是提供 data fix script, 都要让其他开发 review 一下, 以免出现问题
可以在bug管理平台，比如禅道进行提单。
你发现bug了后在平台开始提单，提bug的几个要素：标题，一目了然知道bug到底是啥；重现步骤，写明你出现bug的步骤，尽量详细；严重程度，此bug对整个系统的影响有多大；重现程度，写明bug的重现程度，比如必现，高几率复现，偶现；问题原因，提单前与开发沟通，并确定原因，如果能够很快确定原因，那么写上原因，如果不能就写定位中；修复建议，给开发写上自己的修复建议，建议怎么修改，达到某种效果；其他，根据实际情况写。
欢迎分享，转载请注明来源：品搜搜测评网
微信扫一扫
支付宝扫一扫
