游戏测试中遇到的奇葩bug（不断整理中...）
关于版本号的问题：
1.当时测试模式下更新之后进⼊游戏是正常的，我们就让开发推正式模式，推完正式模式，测试会清理应⽤数据重新更新，发现进⼊游戏也是正常的，但是当玩了⼀段时间后，退出重新进⼊游戏时，发现⽆法进⼊游戏了。
于是就找开发去查问题，结果发现在写版本号⽂件的时候没有考虑两位数的情况，所以当版本号从1.0.0.9更新到1.0.0.10时会出现该问题，最后解决⽅法是把版本号改为1.0.1.0
关于服务器的问题：
1.由于很多活动都跟开服天数有关，当把服务器的开服时间定为第⼆天的10点开服，但是后端在5点之前（活动都是5点刷新）把服务器启动起来了，当到了10点开服时，发现很多活动及玩法都是开服第⼆天的。
其它杂乱问题：
1：跨服组织战中，不同服务器相同组织ID的敌对玩家不能造成伤害。
2：节⽇活动24点开启，⾓⾊不下线⾃然过渡到活动开启，界⾯显⽰异常
3：前端请求数据之后，不管是否接收到后端返回的数据，只要玩家点击仙化，都会再次请求。
4：在已有材料，但是材料不⾜时，点击获取途径跳转商城购买之后，界⾯数量没有实时刷新
5：杀⼈轮回点数达到每⽇获取上限，然后提升轮回等级被消耗之后，被杀会扣除⾯板显⽰的杀⼈轮回点，之后再杀⼈就可以继续获取轮回点数，反复消耗被杀，杀⼈，可以⽆限刷点。
BUG书写格式问题1：问题定位：X X 严重级别：X X所属模块：一级菜单》二级菜单问题描述：附图：测试结果：（填写内容包括测试是否通过，测试日期，测试人，未通过的问题描述）------------------------------------------------------------------------------------------------------------- 示例：问题1：问题定位：代码错误严重级别：一般所属模块：申请受理》申请材料录入问题描述：借款人购房情况页面，存盘报错。
附图：测试结果：测试未通过。
2010-03-10 hln问题描述：仍存在上述问题。
附图：同上测试结果：测试通过。
2010-03-10 hln问题定位与严重程序划分标准1．BUG严重等级划分：按照CMM5中定义的规范，BUG严重等级可分为3-5个等级。
现根据我们公司的情况，将BUG等级划分四个等级，分别为致命、严重、一般、轻微。
●致命致命性问题主要为：系统无法执行、崩溃或严重资源不足、异常退出、系统不稳定。
具体基本上可分为：○内存泄漏○由于执行程序引发数据库发生死锁○用户数据丢失或破坏○系统崩溃/死机/冻结○程序无法启动或异常退出○因错误操作导致的程序中断○功能设计与需求严重不符●严重严重性问题主要为：影响系统功能或操作，应用模块错误使业务中止无法进行后续操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
具体基本上可分为：○功能未实现○功能错误○业务中止，无法进行后续操作○数据库的表、业务规则、缺省值未加完整性等约束条件○数据库表结构错误，字段长度不够，缺少表、存储○语音或数据通讯错误○数值计算错误○前台提示存储报错○系统所提供的功能或服务受明显的影响●一般一般性问题主要为：界面、性能缺陷。
具体基本上可分为：○操作界面错误（包括数据窗口内列名定义、含义是否一致）○报表打印内容、格式错误、取值错误○页面查询结果错误，自动读值项取值错误○边界条件下错误○提示信息错误（包括未给出信息、信息提示错误等）○简单的输入限制未放在前台进行控制○长时间操作无进度提示○光标跳转设置不好，鼠标（光标）定位错误○系统未优化（性能问题）●轻微提示性问题主要为：易用性及建议性问题具体基本上可分为：○界面格式等不规范○辅助说明描述不清楚○操作时未给用户提示○可输入区域和只读区域没有明显的区分标志○个别不影响产品理解的错别字○文字排列不整齐等一些小问题○提示窗口文字未采用行业术语○建议2．问题定位：后台存储：指缺少存储，存储代码错误，前台提示的执行存储失败代码问题：指前台反馈出null值,空白对话框，IE浏览器提示错误，找不到页面等脚本错误的问题功能问题：指按钮功能未实现包括查询，存盘，增加，修改，删除，另存为等按钮以及查询条件未起作用界面优化：指界面文字描述，布局问题报表打印：指打印预览显示出的报表样式，文字，取值等错误其他：指提示语不准确，增加或减少菜单项，需求功能遗漏等不能明确分类的问题。
BUG统计与质量控制一、引言在软件开发过程中，出现BUG是不可避免的。
为了确保软件的质量和稳定性，BUG统计与质量控制是非常重要的环节。
本文将详细介绍BUG统计与质量控制的标准格式。
二、BUG统计1. BUG统计表格BUG统计表格是记录和跟踪BUG的重要工具。
表格包括以下字段：- BUG编号：每个BUG都有一个唯一的编号，方便跟踪和管理。
- 问题描述：对BUG的具体描述，包括出现的现象、影响和可能的原因。
- 严重程度：根据BUG的影响程度，分为严重、一般和轻微。
- 优先级：根据BUG的紧急程度，分为高、中和低。
- 提交人：报告BUG的人员姓名或ID。
- 提交时间：报告BUG的具体时间。
- 状态：BUG的处理状态，包括新建、待解决、已解决和已关闭等。
- 负责人：负责解决BUG的人员姓名或ID。
- 解决时间：解决BUG的具体时间。
- 备注：其他需要记录的信息。
2. BUG统计流程BUG统计流程是指从BUG发现到解决的整个过程。
一般包括以下几个步骤：- 报告BUG：任何人员在发现BUG后，需要及时报告给负责人或相关人员。
- 记录BUG：负责人将收到的BUG进行记录，填写相应的BUG统计表格。
- 分析BUG：负责人对收到的BUG进行分析，确定严重程度和优先级。
- 分配BUG：根据BUG的优先级，负责人将BUG分配给相应的开发人员。
- 解决BUG：开发人员根据BUG的描述和分配信息，解决BUG并填写解决时间。
- 验证BUG：负责人对解决后的BUG进行验证，确认BUG是否已经解决。
- 关闭BUG：负责人将已验证的BUG标记为已关闭，并记录相关信息。
- 统计BUG：定期统计已解决和已关闭的BUG数量和趋势，以及未解决的BUG情况。
三、质量控制1. 质量控制指标为了确保软件的质量，需要制定一些质量控制指标，用于衡量软件的稳定性和可靠性。
常见的质量控制指标包括：- 缺陷密度：单位代码中的缺陷数量，用于评估代码的质量。
