【7级分类】
Blocker级别【中断缺陷】
客户端程序无响应，无法执行下一步操作；
Critical级别【临界缺陷】
功能点缺失，客户端爆页；
Major级别【较严重缺陷】
功能点没有满足需求；
Normal级别【普通缺陷】
1、数值计算错误；
2、JavaScript错误；
Minor级别【一次要缺陷】
界面错误与UI需求不符；
打印内容、格式错误；
程序不健壮，操作未给出明确提示；
Trivial级别【轻微缺陷】
辅助说明描述不清楚；
显示格式不规范，数字，日期等格式；
长时间操作未给用户进度提示；
提示窗口文字未采用行业术语；
可输入区域和只读区域没有明显的区分标志；
必输项无提示，或者提示不规范；
Enhancement级别【测试建议】（非缺陷）
以客户角度的易用性测试建议；
通过测试挖掘出来的潜在需求；
【5级分类法】
【A类】导致系统崩溃、死机；出现不可挽救的数据丢失或损坏、内存泄露；
【B类】导致程序模块丢失或未实现；软件错误导致数据丢失；用户需求未实现；
【C类】发现影响被测功能正确实现的问题；
【D类】一般性错误或者功能实现不完善等；
【E类】一些建议性的错误；
1.1【A级】
◆系统崩溃，如应用程序死掉或异常退出、通讯意外中断或系统进入死循环；
◆基本功能无法实现或遗漏，如某一应用程序启动不了或关键功能无法运行，关键数
据错失较多；
◆性能问题，如操作实时失败、数据库读写效率低；
◆无法正常安装；
◆升级脚本错误，使升级失败；
◆内存使用错误，如内存泄漏、内存溢出、数组越界等；
◆进程资源不能释放；
1.2【B级】
◆基本功能存在部分问题或次要功能无法实现或遗漏；
◆程序抛出异常信息没有处理，如空指针、通讯异常等；
◆安装后文件不全、文件错误造成基本功能无法实现；
◆不符合面向对象的设计思想，程序结构紊乱，模块内聚性差，模块间耦合程度高；
◆前后台版本不兼容；
1.3【C级】
◆次要功能存在部分问题；
◆界面存在明显缺陷，设计不友好、不完善；
◆安装时的小问题，或者安装后文件不全、文件错误造成次要功能无法实现；
◆不符合软件编程规范；
1.1【A级描述】
◆系统崩溃，如应用程序死掉、应用程序异常退出、通讯意外中断或系统进入死循环；
◆基本功能无法实现或遗漏，如某一应用程序启动不了或关键功能无法运行，关键数
据错失较多；
◆性能问题，如操作实时失败、数据库读写效率低；
◆无法正常安装；
◆升级脚本错误，使升级失败；
◆内存使用错误，如内存泄漏、内存溢出、数组越界等；
◆进程资源不能释放；
1.2【B级描述】
◆基本功能存在部分问题或次要功能无法实现或遗漏；
◆程序抛出异常信息没有处理，如空指针、通讯异常等；
◆安装后文件不全、文件错误造成基本功能无法实现；
◆不符合面向对象设计思想，程序结构紊乱，模块内聚性差，模块间耦合程度高；
◆前后台版本不兼容；
1.3【C级描述】
◆次要功能存在部分问题；
◆界面存在明显缺陷，设计不友好、不完善；
◆安装时的小问题，或者安装后文件不全、文件错误造成次要功能无法实现；
◆不符合软件编程规范；
【A类】严重错误
◆由于程序所引起的死机,非法退出
◆死循环
◆导致数据库发生死锁
◆数据通讯错误
◆严重的数值计算错误
◆需求未实现
◆文档与软件不符、文档严重不足、系统文档关键错误
【B类】较严重错误
◆功能不符
◆数据流错误
◆程序接口错误
◆轻微的数值计算错误
【C类】中等错误
◆程序非正常终止但可通过其它输入来避免
◆系统边界错误
◆显示报表错误
◆数据处理、需求理解错误
◆系统文档一般错误
【D类】一般性错误
◆界面错误(详细文档)
◆打印内容、格式错误
◆简单的输入限制未放在前台进行控制
◆删除操作未给出提示
◆系统操作不方便
【E类】较小错误
◆辅助说明描述不清楚
◆显示格式不规范、查询报告格式错误
◆长时间操作未给用户进度提示
◆提示窗口文字未采用行业术语
◆可输入区域和只读区域没有明显的区分标志
◆系统处理未优化
【F类】测试建议
BUG提交模板和注意事项 一、BUG提交模板 1.现象描述 <详细描述BUG现象> 2.组网环境 <组网图及简要说明：机箱、板卡（型号、序列号和槽位）、测试仪、连接线缆等描述> 注：简单组网环境或一般性BUG情况下，可只简要描述组网环境，无需组网图。 3.版本信息 <被测设备所有组件版本信息> 软件版本： 硬件版本： 芯片版本： CPLD版本： MCU版本： uboot版本： 4.操作步骤 <详细描述发现BUG的操作步骤> 注：说明发现BUG对应用例名称编号或为非用例发现BUG。 5.期望结果 <预期正确的结果> 6.实际结果 <实际不正确的结果> 7.BUG严重性等级 <初步判定BUG的严重性等级>
8.开发确认情况 <开发确认BUG情况描述及确认人> 注：严重等级以上BUG必须要有开发人员确认 9.附件 <包括：组网图、BUG现象截图、操作产生的系统日志等> 注：严重等级以上BUG必须带有附件，一般性BUG则附件可选。 10.备注
常见问题与回答 一、注册问题： 1.问：手机注册和普通注册有什么区别？ 答：您好！手机注册系统会自动为您的帐号与该手机进行绑定，免去了您绑定手机的麻烦；使用手机进行密码找回和资金保护相对于其他保护方式更方便快捷；手机更是保护您账号安全的有力屏障，绑定手机可以提高您帐号安全等级。 2.问：快速注册与普通注册的区别？ 答：您好！快速注册将不进行身份证与手机的验证和绑定，不利于您账号的保护，建议您多花点时间进行普通注册并绑定您真实有用的身份证和手机信息。 3.问：如何推荐朋友玩博弈游戏？推荐后有什么好处？ 答：每个玩家注册成功后在官网推广页面有推广链接，您可以复制您的推广链接给您的朋友或者发布到网上，您的朋友或者其他玩家通过您的链接注册成功您将获得推广值；作为推荐人，您每推荐一个玩家，都可以获得相应丰厚奖励，您推荐的玩家在游戏中进行充值您将可以获得佣金提成。 4.问：注册时游戏帐号一栏如何填写？（此问题还有些歧义） 答：游戏帐号可以是字母开头且为字母与数字的组合(不能少于5位或多于15位)，您可以直接填写方便您记忆的帐号名称，系统不区分大小写，会自动默认为小写字母注册。 5.问：注册时提示游戏昵称不合法怎么办？ 答：您好！请仔细查看您所输入的昵称是否为2-5个汉字。 6.问：注册时点击确定没有反应怎么办？ 答：你好！这一般是由于浏览器版本过低或自身系统存在病毒与网络状况不良所导致。您可以使用最新的IE浏览器版本，尝试查杀病毒，并且临时允许弹出窗口，您还可以试试清除IE缓存，还原IE高级设置，恢复默认级别。 7.问：注册时提示验证码错误怎么办？ 答：您好！“验证码”是由系统随机的数字号码，如果提示您输入错误，建议您可以先查看一下电脑上的输入法是否有切换为半角输入，然后点击验证码旁边的“看不清楚，换一张”按钮更新下，再根据提示进行输入即可！或者点击刷新一下页面试试看。 8.注册时每一栏都需要填写吗？ 答：您好！在注册时带“*”号的内容都是需要填写的，为了保证您的账户安全请您填写真实信息并牢记您的注册资料。
TERA游戏中弹出错误代码解决?案?览 T E R A游戏弹出错误代码解决?案?览 1.C o d e1：275问题状况：此异常状况為?法正常连接T E R A游戏主程式 排除?式：?T E R A官?右上?「珍奇名品馆>游戏程式」内，下载「《T E R A》登?设定档」，下载后再安装?T E R A主程式资料夹中，安装完毕后再重新执?游戏便可排除。 2.C o d e1：257 问题状况：在游戏中閒置过久?跳回伺服器列表，重新点选登?伺服器时会跳出。 排除?式：连线逾时，请玩家重新执?游戏主程式 3.C o d e1：65535 问题状况：游戏执?所需的电脑资源不?，可能為游戏档案加载记忆体时间过长、N V I D I A O P T I M U S未正确切换?效能显卡、游戏执?档被强制关闭。 排除?式- (1)採?N V I D I A O P T I M U S?动切换显卡技术的笔记型电话，请参考「FA Q:笔记型电脑不能正常执?T E R A、游戏效能不佳、错误讯息65535」 (2)若玩家的游戏主程式為复製他?已安装版本，请玩家将资料夹：『T E R A S1G a m e C o n?g』内的所有S1开头档案全数删除再进?游戏，减少记忆体加载量。 (3)若电脑萤幕解析度?正常?例(4:3、16:9)，例如：1366*768 (16:10)，请将预设资料夹『C:M a c r o w e l l T E R A S1G a m e C o n?g』，底下的档案『S1O p t i o n.i n i』，搜寻下列『=』前?的英?项?，并将后?英?/数字调整如下列相同： I S_F U L L S C R E E N=F a l s e R E S O L U T I O N_X=1024 R E S O L U T I O N_Y=768 S C R E E N M O D E=2 如果有缺少任何?项请??增加在[V I D E O]下?。 (4)為了确保您的电脑有确实执?游戏主程式，请玩家先配合调低桌?解析度，?论解析度為多少，请先降1~2阶级，如：1920*1080调降成1440*900，接著请玩家啟动游戏，并确认?下是不是有很?的画?出现，然后请玩家先不要有任何动作，等待约5鐘后再看游戏是否确实开出。
Bug提交管理规范 修订历史
目录 1. BUG管理工具介绍 (3) 2. BUG定义 (3) 1. BUG分类 (3) 2. Bug等级 (3) 3. Bug状态 (4) 4. Bug优先级 (4) 3. BUG的生命周期 (4) 4. BUG管理规范 (5) 1) 项目的创建 (5) 项目名称及代号规范 (5) 项目的模块及版本划分规范 (5) 用户角色权限分配规范 (6) 2) BUG提交规范 (6) BUG的报告内容 (6) 主题，即BUG简要描述 (7) 严重程度选择 (7) 优先级选择 (8) 模块及版本选择 (8) 环境 (9) BUG详细描述 (9) 其他规范 (9) 3) BUG分配及处理 (10) BUG的分配 (10) BUG处理 (10) 4) BUG验证及关闭 (10)
1.BUG管理工具介绍 常用的BUG管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb等。我们公司采用的是JIAR，JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。 2.BUG定义 1.BUG分类 BUG 就是指系统存的各种缺陷，可以从很多角度对BUG进行分类。 1、从功能方面分，产生BUG的原因大体可以归结为以下四种： A.重复的功能； B.多余的功能； C.功能没有达到设计的要求； D.功能实现与设计要求不相符。 2、从易用性方面分，可以归结为三点： A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面； B.缺少帮助信息，或者帮助信息不完全； C.功能操作复杂，提示信息不合理，易产生歧义。 3、从安全性方面分，BUG可以划分为以下几类： A.数据有效性检测不合理； B.重要数据在传输中没有加密； C.缺少身份认证机制或认证不合理； D.数据产生缺乏随机性； E．网络安全性：开放端口、服务； F．系统日志、审计。 4、从可靠性方面分，BUG可划分为以下几类： A.数据存贮的可靠性； B.业务处理的可靠性； C．硬件可靠性：如打印机；D.应急处理措施； E．数据备份、恢复。 5、从性能方面考虑，BUG可划分为三种： A．并发量； B．吞吐量； C．响应时间。 6、从兼容性方面考虑，BUG有两种： A．硬件兼容性； B．软件兼容性。 7、从可维护性方面考虑，可划分为两种原因： A．可扩展性； B．方便升级。 2.Bug等级 BUG等级是根据BUG出现在系统中的严重程度来分的，主要定义如下5级： 1级——致命：系统重要功能无法正常使用，系统崩溃；系统设计存在重大隐患；导致用户利益受到重大损失。该级别需要程序员修改。 2级——严重：系统主要功能无法正常实现，系统业务受到严重影响；导致用户利益受到损失。该级别需要程序员修改。 3级——一般：系统次要功能无法实现；主要功能部分失效；系统业务受到影响；导致用户利益受到一定损失。该级别需求程序员修改。
游戏公司面试常见问题 在游戏行业，有一些问题常常出现，这里列举了一些，并且加上一些提示，告诉你如何应对。下面为大家了游戏公司面试常见问题，希望能帮到大家！ 如果目前你还没有离职的话，这个问题还涉及到另外一个意思，“为什么你要离开你原来工作的地方。” 这是一个开放式的问题，它给你一个展示你对该公司了解程度的机会。当应聘者清楚地了解该公司是一家什么公司，有什么游戏是这家公司做的，那么所有的面试官都会觉得受到了尊重而心生好感。因此，去面试之前应该认真做好功课，并好好地表现出来。对于应届毕业生来说，也许你之前并没有在游戏公司工作过。那你就更需要全面了解公司的情况，充分显示你对公司的热情和极度的向往，因为很可能这是你最大的可以胜过其他有的应聘者的优势。 千万不要说“我需要一个工作”或者“我需要换一个城市”。应该列举一些与该公司相关的原因来回答这个问题。一些与你个人相关的更特别的理由会是更好的答案：“我想为 FPS 射击游戏工作。”这样的回答就不如说，“我想为《 FranchiseX 》游戏工作，因为我玩过这个系列最早的两个版本游戏，并且我觉得这一系列的产品有进一步发展的潜力。”这么说确实有点阿谀奉承之嫌，
不过面试的技巧之一就是应该尽可能称赞其他人。当然了，别说这是唯一的原因。 当解释你为什么要离开现在的工作岗位时，理由千万不要是消极的。应该举一堆积极的理由，例如“在这里没有职业发展前景”或者“在这里做的游戏类型不是我感兴趣的”。千万不要说“这家公司的管理混乱，就快倒闭了”。游戏行业是一个很小的圈子，你有可能不小心就正好说了你面试官朋友的坏话。 假如你是被解雇的，最好这么说：“我们决定分道扬镳。”或者说“到了我该离开的时候了。”尽量说的含糊一些，不要去说过多的细节，除非对方直接问你。在这种情况下，面试官可能已经发现了什么，他只是想看看你怎么回答。回答这样的问题应该尽量快，而且不要带有消极情绪，尽量一笔带过。你需要给对方留下一个积极的印象。 如果你想到游戏公司工作，你最好是玩游戏的，而且最好能够让面试官知道这一点。 提到一些与该公司制作风格相同的游戏是一种比较好的回答方式。如果你可以谈谈玩这些游戏感受就更好了。当然，记得适可而止，别说的太多。
自主游戏活动的开展及 观察记录 Company number：【WTUT-WT88Y-W8BBGB-BWYTT-19998】
自主游戏活动的开展及观察记录 一、自主游戏的开展 幼儿园活动区是根据活动内容的类别对空间进行划分后形成的区域，区域活动使幼儿有更多的机会进行自主选择、自主操作和自主游戏活动，将获得更多的按照自己的节律和兴趣爱好发展的机会。华东师范大学华爱华教授把活动区分成四大类型，即表现性活动区、探索性活动区、运动性活动区、欣赏性活动区。 室内的活动区都是通过各种开放性材料的投放，为幼儿提供自我表现与表达的机会。幼儿在这些活动区中会综合运用已有知识，在表达意愿、展示能力、充分体现自己天性和潜力的过程中进行各种创造性活动。比如：装扮区（娃娃家、小医院、超市、美食区等）、表演区、建构区、美工区。 1.装扮区 装扮区是幼儿开展角色游戏的主要场所。我们知道，角色游戏是幼儿创造性地反映个人生活印象的一种活动，其主题和情节源于幼儿的生活经验。所以，这个区域我们依据幼儿的生活经验创设环境和投放材料。创设的环境和投放的材料与幼儿的生活经验越接近，幼儿越能充分表现他们对生活的印象，巩固对生活事件的理解，游戏情节的展开水平也就越高。 为了吸引孩子到装扮区进行角色游戏，我们预设了幼儿熟悉的情景比如所有投放了与主题相应的模拟物，如餐具、听诊器、收银机等，这些都能唤起幼儿的生活经验。我们以小医院为例，一起来看看孩子的活动录像。（观看录像）
我们看到，幼儿的游戏水平不能称之为很高，但已经能模拟出医院的情景，这是他们生活经验的体现，幼儿对这些替代物的自发使用频率和使用质量是衡量幼儿角色游戏水平高低的标志，因为它预示着幼儿表征思维的发展和行为目的性的增强以及创造力的发挥。 我们再来看一看另一个装扮区游戏——美发屋（观看录像） 可见，装扮区是幼儿最能自由表达意愿以及发挥想象力和创造力的活动区域，由此，他们对生活常规的认识、对人际关系的理解、对情感的宣泄和补偿以及叙事能力的发展，都将得到实现。 2.表演区 在表演区可以开展两类幼儿十分喜爱的活动：一类是表现故事情节的，另一类是表现已经学会的歌舞的。 “表演”和“表演游戏”的区别在于“表演”是幼儿按照导演(教师)的要求，严格按照剧本的台词展开剧情的，每次再现时，台词和动作基本一样：而“表演游戏”是幼儿根据自己的意愿和理解，通过想象自由、创造性地即兴再现作品。作为活动区活动出现的幼儿表演主要还是属于表演游戏。 以故事情节展开的表演游戏虽然也是以扮演角色的形式表现出来的，但它与角色游戏是有区别的，它创造性地反映文艺作品中的故事情节，而不是现实生活经验。幼儿熟悉而有趣的作品容易引发幼儿对故事表演游戏的兴趣。（金鸡冠的公鸡） 以歌舞形式展开的表演游戏与舞台上的正式表演不同，它是幼儿对音乐活动中已经学会的歌曲和舞蹈的自发性再现。幼儿可以根据歌曲的节奏即兴创编
禅道Bug提交管理规范 修订历史
目录 目录 (2) 1. 目的 (3) 2. 禅道系统Bug流程图 (4) 3. Bug流程操作及其Bug相关信息解释 (5) 3.1.测试人员发现bug (5) 3.2.测试人员创建Bug (5) 3.3.开发人员设定Bug优先级别并确认Bug (7) 3.4.开发人员解决Bug (8) 3.5.测试人员验证Bug (9)
1.目的 本文档定义了bug管理流程及其bug相关信息内容。 本文档适用范围： ●本文档适用于新产品以及以后新产品的项目。原有项目的bug管理仍然用JIRA系 统进行管理。 ●本文档适用于新产品以及以后新产品的项目相关的测试人员和开发人员。
2. 禅道系统Bug流程图
3. Bug流程操作及其Bug相关信息解释 3.1.测试人员发现bug 3.2.测试人员创建Bug 测试人员登录禅道系统，创建Bug。Bug状态为激活（未确认） 创建Bug页面截图： 页面字段注释： 所属产品：选择发现Bug的产品，必填项。 所属模块：选择发现Bug的对应模块，必填项。 所属项目：选择测试所属的项目。必填项。 影响版本：选择发现bug的版本。必填项。 当前指派：选择指派的开发人员。必填项。 Bug标题：用简单明了的语句说明Bug内容，相当于BUG的中心语句。必填项。 在标题上注明bug出现的频率（稳定出现/经常出现/很少出现/出现一次）重新步骤：重现步骤格式如下。必填项。 [环境]：如果系统/浏览器信息不能够全部说明发现Bug的环境，需要在 重现步骤里详细描述环境信息，以便于开发定位和解决问题。 [步骤]：写明出现Bug的操作步骤，要求简单，去掉与Bug无关的步骤。 [结果]：写明操作的实际结果。
?一、摘要 ?二、名词解释 ?三、目的 ?四、范围 ?五、Bug编写规范 o 1. 主题 o 2. 描述 o 3. 环境 o 4. 截图 o 5. 其他 ?六、注意事项 一、摘要 本文档主要描述了技术产品部测试人员提交Bug时需要遵守的规范。 二、名词解释
?JIRA JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。 三、目的 规范Bug编写，一方面，可以方便开发人员根据Bug描述快速进行定位问题原因，减少沟通成本，另一方面，可以帮助测试经理、非技术人员、产品经理、开发经理及其他测试人员等了解Bug，第三，可以体现测试团队的专业性、严谨性。 四、范围 该文档适合技术产品部测试人员使用，适合于任何产品和项目。 五、Bug编写规范 1. 主题 为了节约开发阅读Bug时间，同时考虑到开发人员容易通过Bug标题来猜想Bug，所以，Bug标题显得尤为重要。以下为Bug标题编写时需要遵守的规范。1）用简短的语句描述问题，主题文字过多，增加开发阅读Bug时间。2）格式：在什么位置，在什么条件下，做什么操作，操作的结果。 ?在什么位置：问题所在的路径，格式为“XX-页面：”
?在什么条件下：如果问题为兼容性Bug，比如浏览器兼容或者分辨率兼容。格式为“在IE11浏览器下，”，如果Bug不属于兼容性问题，不用加此描述。 ?做什么操作：问题触发的动作，比如：“执行审批通过”。 ?操作的结果：即问题的表象，比如：字段“报送时间”取值不对、报404错误。格式举例：采购中心-招标计划详情：在IE11浏览器下，展开“查看参与人员”，内容错乱。 3）除了第二点描述的格式，对于Bug描述，除了描述实际的结果外，有时候我们会直接描述期望结果，比如，集采销售-招标计划列表：列表字段“填报时间”应该修改为“报送时间”。 4）描述无歧义。Bug描述如果有歧义，开发容易因为改错Bug，导致增加Bug修复成本。 5）涉及界面UI的文字，用双引号标注，比如：集采销售-招标计划列表：列表字段“报送时间”取值错误。 2. 描述
游戏安装注意事项：1.Cities XL2011的破解补丁、汉化补丁都位于本区引 索里。自行选择！ 2.安装时要断网、关闭杀毒软件（特别是360）、防火墙以及任何可能使安装失败的程序。 3.报错时请首先重装破解补丁，可能是安装路径不对，或者是解压不全。 4.安装目录不要有中文字符，安装程序不要放在系统临时文件夹里。 5.本游戏安装运行的成功率不是特别高，特别是64位系统和低配置电脑。如果一下方法都不能解决，那就暂时没办法。建议将报错信息输入百度或谷歌搜索，寻找答案。 具体案例解决方法参考： 出现问题请首先尝试直接运行游戏主目录的exe文件进入游戏，而不是用桌面快捷方式 1.Method verify Access failed,You do not have sufficient access pri vileges to install the game.Please contact your administrator 解决方法： 1.进入安装目录， 2.右击CitiesXL.exe，设置成xp兼容模式（或者可以试试98模式），并勾选Run As Administrator（以管理员身份运行）， 3.运行CitiesXL.exe，应该可以解决。 2.Unable to launch cities xl process make sure citiesxl_game.exe fil e intact （引用程序配置不正确） 解决方案：由于citys xl的vc2005库安装与win7不兼容，一般情况下在装完破解补丁后都会提示unable to launch cities xl process make sure citie sxl_game.exe file intact，未安装破解补丁会提示程序配置错误一类的话。下面附上本人经过一下午时间找的的解决方法！本方法经测试对目前版本完全有效！一定要把本文顶上去！够低调了吧~~~发帖时刚解决有点激动。
xxxxxxxxxxxxxxxxxxxxxxxxxx 测试组BUG管理规范
版本历史
目录 1BUG管理工具介绍 (3) 2BUG定义 (3) 2.1BUG分类 (3) 2.2Bug 等级 (4) 2.3Bug 状态 (4) 2.4Bug优先级 (5) 3BUG的生命周期 (5) 4BUG管理规范 (6) 4.1项目的创建 (6) 4.1.1项目名称及代号规范 (7) 4.1.2项目的模块及版本划分规范 (7) 4.1.3用户角色权限分配规范 (7) 4.2BUG提交规范 (7) 4.2.1BUG 的报告内容 (8) 4.2.2问题类型选择 (9) 4.2.3BUG 简要描述 (11) 4.2.4优先级选择 (11) 4.2.5模块及版本选择 (11) 4.2.6BUG 详细描述 (11) 4.2.7其他规范 (12) 4.3BUG分配及处理 (12) 4.3.1BUG 的分配 (12) 4.3.2BUG 处理 (13) 4.4BUG验证及关闭 (13)
1 BUG管理工具介绍 常用的BUG 管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb 等。我们公司采用的是 JIAR ，JIRA 是Atlassian 公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。 2 BUG定义 2.1BUG分类 BUG 就是指系统存的各种缺陷，可以从很多角度对BUG 进行分类。 1、从功能方面分，产生BUG 的原因大体可以归结为以下四种： A.重复的功能； B.多余的功能； C.功能没有达到设计的要求； D.功能实现与设计要求不相符。 2、从易用性方面分，可以归结为三点： A. 界面不美观，控件排列、格式不统一，焦点控制不合理或不全面； B .缺少帮助信息，或者帮助信息不完全； C.功能操作复杂，提示信息不合理，易产生歧义。 3、从安全性方面分，BUG 可以划分为以下几类： A.数据有效性检测不合理； B.重要数据在传输中没有加密； C.缺少身份认证机制或认证不合理； D.数据产生缺乏随机性； E.网络安全性：开放端口、服务； F.系统日志、审计。 4、从可靠性方面分，BUG 可划分为以下几类： A.数据存贮的可靠性； B.业务处理的可靠性； C.硬件可靠性：如打印机； D.应急处理措施； E.数据备份、恢复。 5、从性能方面考虑，BUG 可划分为三种： A .并发量； B .吞吐量； C .响应时间。
BUG定义规范Revision History
1.目的 对BUG概念、BUG提交和验证、BUG状态、BUG严重程度等内容进行定义和规范，以便进一步指导我们的测试工作 2.概念 BUG:软件中存在的瑕疵，可能会导致软件失效。简单的说就是软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷 3.BUG管理工具 以Quality Center 9.0为提交、跟踪等工具 4.BUG提交和验证要求 以QC中的字段为准 提交时必选字段有：摘要，跟踪类型，检测者，检查日期，计划关闭版本，可重现，分 派给，严重程度，状态，描述 验证后，需要修改字段：关闭于版本，关闭日期，状态BUG描述模板如下： [问题概要]: [重现步骤]: 步骤1. 步骤2. [隔离分析]: [期望结果]: [重现概率]: [Test Case No.]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称） [Test Case]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称） QC中优先级和严重程度的区别：优先级由软件开发人员填写，严重程度由测试人员填写 计划关闭版本定义： 有2重含义：1.由测试人员填写当前发现bug的版本号；2.开发人员必须在此版本上修改 5.BUG验证 开发人员必须提供修改此bug会涉及到的功能点列表，并将此信息填写到bug描述中。 测试人员除验证此bug外，还需要将开发列出的功能点逐一验证，同时写入自己考虑到的功能点验证情况 来自需求和测试自己提交的问题，测试人员都需要验证，并填写测试结果，其中来自自己的bug，若验证通过，则修改状态为“关闭”；来自需求人员的bug，则修改状态为“验证完毕”，由需求人员来关闭（适用于胜算组）。 6.BUG状态流程 在正在BUG生命周期中，可能会经历很多状态，如：新建、提交验证、已关闭、重新打开、已挂起、重复提交等。 新建：新发现的问题 提交验证：开发修改bug后，会将状态变为提交验证，让测试工程师来执行验证操作已关闭：测试工程师经过验证后，发现此问题已经被修复，则修改状态为已关闭
Bug定义规范 1、bug类型的划分 功能类： 1、重复的功能 2、多余的功能 3、功能实现与设计要求不符合 4、功能使用性、方便性、易用性不够 5、功能未实现 界面类： 1、界面不美观 2、控件排列、格式不统一 3、焦点控制不合理或不全面 数据处理类： 1、数据有效性检测不合理 2、数据来源不正确 3、数据处理过程不正确 4、数据处理结果不正确 流程类： 1、流程控制不符合要求 2、流程实现不完整 提示信息类： 1、提示信息重复或出现时间不合理 2、提示信息格式不符合要求 3、提示框返回后焦点停留位置不合理 建议类： 1、功能性建议 2、操作建议 3、检校建议 4、说明建议 2、bug等级定义 Level 1-致命的bug：100%程序崩溃、重启、死机，自动退出，用户数据丢失，缺少主要功能。 1、程序无法正常使用，在正常操作流程中（特别是操作步骤不复杂，用户很容 易就用到）出现崩溃、死机现象 2、100%导致用户数据丢失的问题 3、被测试数据系统频繁崩溃，程序出错，使功能不能继续使用 4、性能与需求不一致 5、系统资源引发性能问题 6、系统配置引发错误 7、安全性问题
Level 2-严重的bug：所产生的问题导致系统瘫痪，重要功能未实现，严重影响用户使用的问题，关键用户需求未实现或软件功能与需求严重不符。 1、功能与需求不一致，或功能未实现 2、功能有错误 3、数据传输有错误 4、安装与卸载有问题 Level 3-一般的bug：所产生的问题会导致系统部分功能不正常，虽然产生的问题严重，但不影响下一步的测试，严重的界面提示问题。 1、功能有错误，但不影响使用 2、重要界面的显示问题 3、内存泄露导致某些功能无法正常使用，释放内存重启后系统恢复正常 4、复现率较低的死机、重启问题，步骤多用户不易操作到 5、边界条件出错 Level 4-轻微的bug：轻微界面显示问题，对用户使用无影响的问题。 1、微小功能问题，如闪烁中间界面、界面刷新慢 2、轻微的界面显示错误，界面设计不规范，交互不友好 3、消息、提示信息不准确 4、用户可以接受，对功能不影响 5、某些次要功能，在进行某些很特殊的操作后某些功能不能正常响应 Level 5-建议性bug：功能运作正常，可是有改进的空间，建议性问题所产生的问题不会导致系统任何问题。 1、可以忽略不计的问题，对用户使用没有任何影响，但有改进空间 2、软件设计有问题 3、文档不完整或不准确 4、其他建议性问题 3、BUG状态 （初始状态） 1、已提交：测试人员员发现BUG后提交到BUG管理系统中的状态。 2、已修改：开发人员在修改了BUG后提交到BUG管理系统中的状态。 3、不修改：程序员或产品人员根据需求分析、概要设计、详细设计说明书等经过考虑后决定对BUG不进行修改。其BUG的状态为不修改，需要说明理由。 4、延迟：根据目前项目进程或计划等情况，暂时延期的状态 5、待讨论：需要进行讨论后才能决定是否需要修改的BUG的状态。 6、已验证：已经解决的并经过测试员复测的BUG的状态。 7、关闭：完全解决了，只供以后备查的状态 8、重新打开：重新出现在新的版本中，重新打开以前关闭的BUG的状态
大户外自主游戏活动观察记录 记录人：朱春霞观察区域：挑战岛 观察时间：2016.3.3 观察对象：敏敏 观察目的：敏敏，你害怕吗？ 一、现象描述 在我们小9班，有这么一个特殊的孩子――敏敏。特殊是因为上学期由于体质原因，她有2/3的时间都在家休息。这不本学期开学初她们一直处于适应阶段，有点胆小的她对于开放的大户外活动不太适应，不太敢“登高”。 今天我们又来到了“挑战岛”，敏敏跟着大伙一起排队准备走木桩、过绳索桥，踩轮胎秋千。看到前面的木桩她表现地很紧张，后面的孩子不断催着“快点，快点”。迈开一只脚的她赶紧弯腰双手扶住另一根木桩，嘴里说着土话“宝宝怕，宝宝怕”，就这样手脚并用地走完了木桩。方块绳索从容走过，接着就是长型绳索桥，她小心翼翼地走着，大伙都自觉跟在后面等她，但由于她真的太慢了，催促声再次响起“快点，快点”，紧张如她再次从绳索上滑下来，不玩了，迈开步子走出来离开了。 二、《指南》对照 健康领域：在帮助下能较快适应集体生活；具有一定的平衡能力，动作协调、灵敏。
社会领域：为自己的好行为或活动成果感到高兴。 三、分析反思 1.孩子由于长期在家，对于群体生活不是很适应，加上胆小的心理，就表现出不太愿意与同伴交往，交流甚少。 2.对同伴而言，爱玩好玩使得他们不愿等待。 3.面对胆怯的孩子老师、同伴应该主动给与鼓励。 三、调整策略 在敏敏没走远时我及时走过去，主动寻问“敏敏，刚才你玩了什么？”她手指着低低地用土话说：“那个。宝宝，有点怕。”我牵起她的手：“老师也想玩，你陪我一起再玩一次好吗？”“好”。走木桩时，我们两互相支撑，我不断说着：“哇塞，敏敏你好厉害，都不摔跤，我都有点怕怕”，“敏敏，拉一下我吧”。看着她越发自信的笑容走完木桩，我就意识到她变“胆大些”了。接着在走长型铁索桥时，我试着放手，“敏敏，刚才你帮助我过木桩，现在我来保护你过独木桥吧！”于是她在前面，我在后面，有了我这个“保护伞”就没有了催促声，她可以放开心“慢点”过。真的，不催促，给她足够的时间就行的。当她顺利走过时我便和后面的孩子喊“敏敏真厉害，我们送个大拇哥给她。” 在我的带动下，外向能干的妞妞组长主动接过我的“角色”，因为是敏敏这组的小组长，她也就不排斥和妞妞玩。在不断地鼓励练习中，在同伴的陪伴中敏敏来回走了好几次，虽然途中经历害怕、摔倒，她都坚持走完。真的大胆了。
BUG\需求提交规范 1．客户名称：广州方泰电子（需求） A、问题描述：客户为防止业务飞单，想设置权限隐藏邮件模块客户的发件地址，不让业务员直接接触客户。（客户已设置所有业务必须先建客户资料才允许发邮件） B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片： D、解决方案： 2. 客户名称：广州方泰电子（需求） A、问题描述：客户想在客户自定义模块设置一栏，可以统计客户其他自定义几项之和或乘积。 B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片：
D、解决方案： 3. 客户名称：茂名腾云电子（需求） A、问题描述：邮箱模块搜索功能太繁琐，需要搜索框默认根据主题、附件名、正文、邮箱账号任一条件搜索！ B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片： D、解决方案： 4. 客户名称：茂名腾云电子（需求） A、问题描述：邮箱模块无置顶功能 B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片：
D、解决方案： 5. 客户名称：茂名腾云电子（需求） A、问题描述：写邮件时设置提醒功能，到时间能自动提醒，根据提醒链接能查看提醒内容。 B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片： D、解决方案： 6. 客户名称：茂名腾云电子（需求） A、问题描述：左侧选择对应客户，选择编辑客户资料时，右侧不能立刻同步客户资料信息。 B、问题出现操作步骤(问题出现操作步骤里面要包含客户目前版本号)： 4.6版本 C、问题图片：
BUG提出和处理流程规范 1引言 1. 1目的 提高测试以及产品缺陷修改效率，避免出现搁置和遗漏的缺陷，从而提高产品的质量，降低质量检查和缺陷修改成本 1. 2适用范围 适用于研发部门（Confernece、Flash、监控），质量保证部门 1.3 定义 bug：通过测试检查出的产品缺陷； 新建、打回、已确认、已指派、已解决、已关闭：测试中bug的不同状态，详细信息见本规范第3部分； 1. 4参考资料 无 2 BUG提交和处理规范说明 1、在测试人员提交bug的时候，必须对bug信息进的描述必须详细全面、清晰明确，如果有条 件，需要描述使用的环境，在BUG出现前的具体操作，如果抓图，必须抓取jpg全屏图象，但不能使用BMP格式上传到BUG库中，有抓包文件需要上传BUG库，空间不够需要放到\\192.168.0.254\qa\测试\bug日志目录中，标题以BUG号区分； 2、在测试人员提交bug的时候，必须按具体情况，填写重要级别、出现频率、优先级别三个栏 目，而非测试人员不得对上述信息进行直接改变，如觉得这三个信息填写不恰当，可以在该bug下的注解中提出意见，并“打回”给bug提交人员或质量部经理处，经过确认后修改；
3、开发人员对bug进行处理后的变更状态成“打回”时，或“指派”给产品部门时以及变更成 “已确认”时必须进行必要的描述和说明,在状态变更时，必须要指定具体接收人； 4、开发人员在注解中描述该BUG计划什么时候解决或做其他阐述的时候，要明确写清承诺的 具体版本号，禁止使用“上一版本”、“本版本”、“下一版本”等字样，以免造成误会或混淆； 修改完成的BUG注释中加入相关的确认信息，如“XXX Review并通过。 5、如果已经是“关闭”状态的BUG，测试人员在后期测试中又出现了需要重新打开，重开后 的BUG状态为“打回”，测试人员需要再多一个操作，即“指派”给具体的研发人员。 6、一直处于“打回”状态的BUG，测试人员需要经过两轮（即两个版本）测试后仍然没有重 现的，可以关闭。但是此两轮测试在该BUG中必须有注释，比如：“XX版本（要求有具体版本号）测试没有重现”，当第二轮测试仍没出现时也需要注释一次，即可进行关闭。 3 Mantis Mantis是PHP/MySQL/Web-based缺陷跟踪系统。 其特点： 个人可定制的Email通知功能，每个用户可根据自身的工作特点只订阅相关缺陷状态邮件； 支持多项目、多语言； 权限设置灵活，不同角色有不同权限，每个项目可设为公开或私有状态，每个缺陷可设为公开或私有状态，每个缺陷可以在不同项目间移动； 主页可发布项目相关新闻，方便信息传播； 支持上传文件，提供进一步的bug信息； 支持上传项目文档； 方便的缺陷关联功能，除重复缺陷外，每个缺陷都可以链接到其他相关缺陷； 缺陷报告可打印或输出为CSV格式。支持可定制的报表输出，可定制用户输入域； 有各种缺陷趋势图和柱状图，为项目状态分析提供依据，如果不能满足要求，可以把数据输出到Excel 中进一步分析； 流程定制不方便，但该流程可满足一般的缺陷跟踪。 在提交bug时需要填写相关信息，还可以上传相关文件（如出错的log或者截图等），对于bug添加注释（允许再次更新）。下面是基本信息的介绍 [出现频率] 可重现-- 稳定地能重现 经常-- 比较经常出现 偶尔-- 偶尔出现 不可重现-- 无法重现 N/A -- 其他情况 [严重性] 不合理或别扭-- 使用不方便，吹毛求疵的标准 文本错误-- 文本错误 崩溃死锁-- 导致死机的bug 严重错误-- 导致功能无法正常运行下去
关于幼儿园游戏的十二个常见问题 问题1：如何吸引小班孩子投入游戏分享 可以用游戏或者儿歌把整个过程串起来，让孩子都讲讲自己的游戏。需要教师想各种办法吸引孩子的注意力。 问题2：孩子不能说出游戏的闪光点怎么办 孩子说不出是正常的，因为孩子眼中的闪光点与教师眼中的闪光点是不一样的。所以孩子没有办法说出老师所认为的闪光点。（案例：游戏中一个孩子扮演记者，要采访娃娃家的妈妈。到娃娃家去了三次，妈妈都没有答应他的要求。终于，第四次，记者采访到了妈妈。老师把这一内容放到交流活动中，想要表扬一下记者锲而不舍的精神，谁知记者不让老师讲，自己自豪的说：最后一次，我跑到娃娃家，一脚踹开门，把妈妈一把拽出来，一定要她让我采访！）可见，孩子眼中的情节跟教师所认为的情节有多大的差别。 教师在分享交流时可以选择悄悄渗透的方法，把自己认为有价值的东西教给大家。 教师面对孩子时可以更宽容、更放松、更低位一些。 问题3：游戏中不能顾及到每个孩子怎么办 游戏中无法顾及到每个孩子是正常的。 并不是每个孩子都需要教师去顾及。当孩子有事情做的时候，是不希望被人打扰的。当幼儿需要老师去顾及的时候再去顾及孩子。 哪些时候需要顾及孩子？一是游戏中产生争执的时候；二是孩子主动寻求帮助的时候；三是游戏中有危险动作的时候；四是有消极不健康的游戏内容的时候。 顾及孩子的方法也有很多：如淡化情景、直接指导和间接指导。 补充问题：游戏讲评时无法顾及到每个孩子怎么办？ 有时候很多孩子都有迫切需要的，这时候老师就要想办法怎样满足孩子的需要。（案例：在教室里放5个玩具话筒。游戏后，想要发言的孩子就去拿话筒，这样就有机会发言了。而没有拿到话筒的孩子不能发言。）这种有规则的满足孩子需求的做法，更适合大班。小班就最好让大家都讲讲；中班可以设置的话筒多一点，让很多幼儿都能上来说说。 问题4：“阅兵式”应该定位益智区还是建构区 所谓“定位”，就是老师对游戏价值的预先设定，是把游戏作为一种手段。这样的话，“阅兵式”到底属于哪个区域，由老师预设的价值来定。如果把“阅兵式”看做孩子的游戏，就要从游戏的角度来思考问题。孩子的游戏最初是模仿，逐渐走向替代、建构等。从游戏发展的过程来看，每一阶段的侧重点是不一样的。教师要明确，游戏区是孩子的游戏还是教师预设的；游戏区是主张游戏的还是主张学习的。益智区和建构区都是以学习为主的区角。 看一场游戏，不要去追究到底是什么区，而要看孩子的主要行为，看游戏对他发展的主要作用是什么。“定位”的标准是要看幼儿的大多数行为。 问题5：幼儿水平有限，教师如何推进游戏 教师认为孩子游戏水平有限，源于对儿童原有水平的预估不足。教师预设了孩子游戏的模式，而孩子却没有按照老师预设的情况去玩。要注意，游戏不像上课一样有预设的目标，游戏是幼儿已有经验的反映。游戏水平是在原有经验上一步一步慢慢推进的。教师要学会在孩子有限的水平上帮孩子梳理问题、提升水平、扩展经验。 补充问题：游戏中出现了消极的内容怎么办？（一个孩子满足于扮演小偷） 对孩子采取不关注的态度，弱化他的行为。另外要想办法转移孩子的兴趣点。 问题6：中大班游戏对情趣性上的要求 （什么是“情趣上的”？） 在游戏材料投放时，小班应该更多的投放逼真形象的材料。中班主要投放替代性材料，
1 测试用例规范
此规范定义了测试用例的属性、级别、撰写以及执行等规范。
1.1 用例级别属性（Keywords）
此字段主要是用来标识用例的级别， 通过对用例的级别定义， 可以使整个测试过程分级 式管理，从而指导测试流程的顺序、突出重点问题、选择性测试，节约了测试成本，同时也 便于更好的表述和分析测试结果。 也是我们定义开始测试标准、 停止测试标准以及回归测试 标准的一个依据。所有的用例将被定义的状态如下： 1、Base（基础，可测用例） 此级别为基础型， 表述了能保证系统可以运行的基本条件， 同时也定义了此安装包可以 进行下一步测试的标准。
如：是否有遗漏功能、安装测试、基本功能点是否没有问题、各项服务是否都是正常运 行、提交制品是否相符等等。
2、Important （重要，可测用例） 此级别为重要型，在完全通过了 Base 类型用例的测试后，首先要测试的用例，这些用 例表述了系统能正常运行的条件和此版本发布必需要满足的条件。 此类型的用例将符合以下 标准之一：
涉及整个功能模块的用例，如果此用例不通过，将导致功能模块不可使用或功能不正常的用例。如： 注册用户、注册服务等等。 能表明某项功能基本满足需求的用例。 涉及到共性问题的用例，如： 发送消息等。 在 release Note 声明解决的 bug。 用户在正常使用中，出现频繁情况的用例。
3、Normal（普通用例） 此级别为普通型， 测试用例的主体。 该类型的用例主要针对在保证系统正常运行的前提
下，对功能行用例进行完善，对功能性用例进行扩展。另外还有测试系统对特殊情况、异常 情况、异常操作情况的处理能力，从细微找出系统漏洞，从而更加完善系统的抗压性和稳定 性。 4、Extend（扩展用例） 此级别为建议型， 该类型用例针对不影响系统正常运行的建议， 力图完善系统现有功能 或提出对系统功能的展望。如：界面显示信息明 确、系统退信的语言规范等
1.2 用例书写规范
1、Test Case Title 命名规则 用例命名时用例应该能够描述出用例的测试目的。 2、Summary 详细信息
Summary 标签，概述了用例的基本情况，应包含以下信息：
测试目的。概述此用例的测试重点和容易出现问题的地方（必写项） 。 前提条件。描述此用例能够执行的基本条件（必写项） 。 测试数据。描述此用例使用的测试素材，包括：输入字符串、大小等数据。 备注。选择填写，可在此项描述用例的测试历史，曾经出现的 bug 等需要表述给测试人员的信息。
3、Steps 设计步骤 此标签为执行用例的主要步骤标签，详细的描述了用例执行的方法步骤和应有的结果。 对此标签的撰写做以下规范：
每一步操作都对应唯一的功能点。避免没有对应功能点的无用步骤，同时也避免一个步骤对应多个功 能点的情况 每一操作步骤的 Expected Result 必须填写。且只能出现描述结果的语言，不能出现描述操作的语言
4、Attachments 附件 此标签为已有的用户添加附件。通过附件可以更加清楚或方便的表述用例内容，如：通 过 Excel 文件批量添加用户、上传本地数据库文件等。