Bug 的标题
BugFree使用手册
1BugFree介绍1.1关于BugFreeBugFree基于PHP和MySQL开发，是免费且开放源代码的缺陷管理系统.服务器端在Linux和Windows平台上都可以运行；客户端无需安装任何软件,通过IE，FireFox等浏览器就可以自由使用。
1.2主页面登录后，默认主页面如下：1.产品选择框①：可以快速切换当前产品，产品模块框②和查询结果框⑥显示相应的模块结构和记录。
2.产品模块框②：显示当前产品的模块结构。
点击某一模块，查询结果框⑥会显示所选模块的所有记录。
3.个性显示框③：i.我的标记，指派给我，由我创建为系统设定的查询条件；ii.用户可以保存自己的查询条件；4.模式切换标签④：切换Bug, Test Case和Test Result模式。
默认登录为Bug模式。
5.查询框⑤：设置查询条件.6.查询结果框⑥：显示当前查询的结果。
i.自定义显示:设置查询结果的显示字段;ii.统计报表：显示当前查询结果的统计信息;iii.导出：将查询结果显示的自定义字段导出到XML文件.最多可同时导出5000条记录；iv.导入（仅支持Test Case模式）:可以将导出的XML文件在Excel 进行编辑后,再导入到BugFree中，实现Test Case批量编辑。
最大支持2M大小的XML文件；v.批量运行（仅支持Test Case 模式)：可以对查询结果的Test Case 同时创建Test Result。
最多支持100个Test Case。
（未实现）7.导航栏⑦：显示当前登录用户名等信息。
8.导航栏⑧：新建及从模板新建。
1.3Test Case管理页面1.4Test Result管理页面1.5Bug管理页面2BugFree使用BugFree集成了Test Case、Test Result和Bug的管理功能。
具体使用流程：首先创建Test Case（测试用例），（一般是先有设计草稿（Excel）)；然后评审测试用例；修改测试用例；最后将评审后的测试用例导入BugFree；根据测试计划运行Test Case产生Test Result（测试结果)，运行结果为Failed的Case，可以直接创建Bug。
bug级别定义及流转说明
Bug说明文档2015年6月25日修订历史记录（A-添加，M-修改，D-删除）目录1.简介 (4)1.1.编写目的 (4)1.2.文档范围 (4)1.3.预期读者 (4)2.BUG优先级(PRIORITY) (4)2.1.I MMEDIATE（立刻）——P1 (4)2.2.U RGENT（紧要、优先）——P2 (4)2.3.V ERY H IGH(高度重视)——P3 (5)2.4.H IGH（重视）——P4 (5)2.5.N ORMAL（正常）——P5 (5)2.6.L OW（稍缓）——P6 (5)3.BUG严重程度(SEVERITY) (5)4.BUG状态及流转 (6)4.1.B UG状态及说明 (6)4.2.B UG状态流转方式 (7)5.BUG内容 (8)1. 简介1.1. 编写目的本文档主要确定bug优先级、bug严重程度、bug流转方式、bug内容。
1.2. 文档范围Bug优先级和bug严重程度的定义，bug流转方式和bug内容的确定。
1.3. 预期读者本文档阅读人员包括项目经理、开发人员、测试人员以及其他相关人员。
2. Bug优先级(Priority)优先级大致分为6个级别P1~P6，P1~P6分别为： Immediate（立刻）、Urgent （紧要、优先）、Very High（高度重视）、High（高度重视）、Normal（正常）、Low （稍缓）。
2.1. Immediate（立刻）——P1即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。
2.2. Urgent（紧要、优先）——P2即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。
2.3. Very High(高度重视)——P3即“高度重视”，表示有时间就要马上解决，否则系统主要功能偏离需求较大或者不能正常工作。
2.4. High（重视）——P4即“重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
测试理论 - 题目
对于打开的文件，惟一识别的依据是（B ）A、文件名B、文件句柄C、物理位置D、目录位置6、系统产生死锁的原因是（ B ）A、一个进程进入死循环B、多个进程竞争，资源出现了循环等C、进程释放资源D、多个进程竞争共享型设备4、关于汇编语言，以下叙述中正确的是（C ）A、汇编语言源程序可以直接在计算机上运行(不行，只有机器语言才可以)B、将汇编语言源程序转换成目标程序的软件称为解释程序(错)C、在汇编语言程序中，不能定义符号常量D、将汇编语言源程序翻译成机器语言程度的软件称为汇编程序(错，应称为编译程序)5、对高级语言源程序进行编译时，可发现源程序中的（ B ）错误。
A、堆栈溢出B、变量未定义C、指针导常D、数组元素下标越界2、使用什么工具可以查看Window服务器的CPU、内存使用情况（C A）A、任务管理器B、磁盘管理器C、资源管理器D、查询分析器8、目前流行的搜索引擎有 ____IE、谷歌____、百度____、必应____、_百度搜索、谷歌搜索、狗狗搜索、迅雷搜索、雅虎搜索___、____、等B/S 最大的优势为客户端免维护，适用于用户膨大，或客户需求经常发生变化的情况C/S功能强大，可以减轻服务器压力，如果用户的需求特别复杂，用C/S1、简述C\S、B\S的优缺点。
（5分）2、六、打开一个网页，如果宣示一片空白，是何原因，如何解决？IE问题传值均未取到页面本身没有任何代码跳转错误七、典型C/S架构应用程序有和特点，测试上应注意什么？C/S 构架是一种典型的两层构架，其全程是client/server即客户端服务器构架测试上应注意其承受大用户量并发访问的能力，比较好的方法是用测试工具来模拟多个客户端同时访问服务器，并使用能监测工具获得关于服务器、数据库等用户关心的性能指标。
八、典型Web应用程序（B/S多层架构）逻辑上分哪几层？Web应用有何特点，测试上应注意什么，主要性能指标有哪些？1.B/S结构分为客户端browse，web服务器，数据库三个层次2、居于浏览器3、表单测试、链接测试、图形测试、内容测试、cookies测试、性能测试、安全性测试4、AVG rps:平均每秒响应的次数=总请求时间/秒数Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数,有人会把这两者混淆；Successful Rounds：成功的请求；Failed Rounds ：失败的请求；Successful Hits ：成功的点击次数；Failed Hits ：失败的点击次数；Hits Per Second ：每秒点击次数；Successful Hits Per Second ：每秒成功的点击次数；Failed Hits Per Second ：每秒失败的点击次数；Attempted Connections ：尝试链接数；你近3年的职业规划？1. 二进制1011010的十六制值是___5A__2. 计算机系统出现死锁是因为____ABCD__A．系统中有多个阻塞进程B．资源数大大小于系统中的进程数C．系统中多个进程同时申请的资源总数大大超过系统的资源总数D．若干进程互相等待对方已占有的资源5、关于汇编语言，一下叙述中正确的是(D)A、汇编语言源程序可以直接在计算机上运行B、将汇编语言源程序转换成目标程序的软件成为解释程序C、在汇编语言程序中，不能定义符号常量D、将汇编语言源程序翻译成机器语言程序的软件成为汇编程序6、对高级语言源程序进行编译时，可发现源程序中的( B )错误。
优化Bug报告的解决方案建议
优化Bug报告的解决方案建议Bug是软件开发过程中难免会遇到的问题，而有效的Bug报告是解决问题的重要一环。
然而，很多Bug报告常常存在信息不全、描述不清晰等问题，给解决者带来了困扰。
为了提高Bug报告的质量和效率，下面给出以下的解决方案建议。
一、准确的标题Bug报告的标题应该能够快速反映出问题所在。
具体而明确的标题可以帮助开发人员有效地定位和解决问题。
例如，不要简单地写上“无法登录”，而是应该写上“登录页面无法加载”。
二、清晰的描述Bug报告中应包含清晰明了的描述。
报告者应该详细描述出现问题的步骤、所使用的环境以及问题的具体表现等。
例如，描述一个登录问题时，报告者应该提供账号、密码、设备类型、操作系统等相关信息。
三、重现步骤一个好的Bug报告应该能够帮助开发人员重现问题。
而为了实现这一点，报告者应提供详细的重现步骤。
这些步骤应该能够让开发人员在相同的环境中步骤一致地重现这个Bug。
例如，应该描述点击哪个按钮、输入什么内容等。
四、附加信息除了清晰的描述和重现步骤外，Bug报告还可以包含其他附加信息，例如错误日志、截图或者录屏等。
这些附加信息可以帮助开发人员更好地理解问题，并更快地解决Bug。
附加信息应该简洁明了，不含有无关信息。
五、建议解决方案在Bug报告中，可以提供关于解决问题的建议和推测。
将自己对问题的理解和可能的解决方案写入报告，可以为开发人员提供更多的线索和思路。
不过这个建议应该是基于自身的观察和分析，并不能保证一定正确。
六、定期更新和反馈一旦提交了Bug报告，报告者应及时关注并回应开发人员的反馈。
有时候开发人员可能需要进一步的信息或者要求报告者进行一些操作来排除其他可能原因。
与开发人员的有效沟通和反馈可以大大加快问题的解决速度。
七、感谢和认可在提交Bug报告后，如果开发人员顺利解决了问题，并将其纳入下一个版本的修复计划中，那么报告者应该对开发人员的工作表示感谢和认可。
这不仅可以激励开发人员继续努力，而且还可以为建立良好的合作关系奠定基础。
bug报告分析
Bug剖析•所有的Bug报告有以下的基本要求：•标题。
要简略。
•指派。
谁来处理这个问题。
•重现步骤。
问题再次出现的相关步骤。
•优先级别。
问题的紧迫性与重要性。
•严重程度。
问题所产生的后果。
•解决方案。
怎么解决问题。
其他很多方面对修复问题及明白其深层次原因也很有帮助，但以上基本准则简练得多。
下面我们来对每条准则逐一展开讨论，消除这些疑惑。
标题及指派标题应该简明扼要，一句话就详尽说明问题的唯一性，使Bug报告的检索及标识变得简单。
“点击取消按钮，屏幕就清空了”是个差劲的标题。
“关闭编辑框，清空屏幕”就是个很好的标题。
后者简短得多，而且对问题的出处及发生时间提供了具体的信息。
当你要创建一份新的Bug报告时，你必须指定具体人选来解决其中问题。
但是，即使你这个团队的每个人都很了解，你也不应该将一个Bug指定给其中某一位，除非你是开发团队的一员。
相反，你应该将此任务交给这整个团队。
通常的做法是在Bug报告中指定责任方或团队作为默认选择。
默认的选择通常是“主导”或“会诊”团队。
不会再有更好的了。
要相信这些团队，他们会知道问题由谁来解决。
作者注：有些团队希望将所有Bug都指派给团队中的某些个人，这样可保证没有Bug被遗漏。
但是，他们还是必须确认将Bug指派给“主导”或“会诊”团队以确保Bug未被遗漏。
毕竟，团队外部人员并不知道软件还有其他什么功能。
作为惯例，所有Bug必须指派给能对其进行经常性检查的个人或团队。
因为，大多数优先团队会每天开例会，我还是偏好将Bug指定给“主导”或“会诊”团队为默认选择。
重现步骤没什么比一份Bug报告没有清晰的重现步骤更让人郁闷了。
就像你的亲友对你说：“你知道该怎么办！”，没有给你更多解释。
这让我很茫然，不知道怎么办。
悲催了。
Bug重现步骤应是言简意赅——一言中的。
同时要包含软件创建编号（通常是单独列出的），你的工作环境（操作系统版本、所用浏览器及其他相关的细节）以及一些先备条件（像先注册个Xbox com金牌账号等）。
软件缺陷管理流程
软件缺陷管理流程软件缺陷管理办法1.目的本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性，以保证项目研发质量。
2.适用范围适用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规范。
3.定义3.1术语缺陷（Defect）：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。
Bug：缺陷一种表现形态，系统或程序存在的任何一种破坏正常运转能力的问题。
3.2缺陷定义（1）软件未达到需求规格说明书的功能；（2）软件出现了需求规格说明书指明不会出现的错误；（3）软件功能超出需求规格说明书的范围；（4）软件未达到需求规格说明书未指出但应达到的目标；（5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。
4.缺陷生命周期4.1缺陷生命周期图4.2缺陷状态说明缺陷状态激活状态状态说明缺陷的初始状态，或者从头被激活的状态。
激活状态的缺陷可以通过编辑来修改缺陷内容，并指派给合适的工程师处理。
解决状态缺陷被解决之后的状态。
激活状态的缺陷经过成功修复以后，由开发工程师操作为解决状态，体系将自动指派回创建者。
关闭状态解决状态的缺陷在验证通过后关闭，缺陷状态变为关闭，生命周期结束。
如果验证未修复或者新版本又发生，则重新激活，缺陷状态重新变为激活。
5.缺陷处理过程5.1正常处理过程（1）创建问题在测试管理体系中，所有效户都可以创建新问题，包括需求问题和软件缺陷等。
创建问题时，需要描述分明，并挑选正确的选项，详细请参考5.4和5.5。
（2）指派问题创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。
假如指派人是错误的，或者需要别人确认或帮助，则可以从头指派给合适的工程师，写上相关备注。
（3）确认问题通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。
如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。
Bugfree3.0.4使用手册
Bugfree3.0.4 使用手册目录目录 (1)第1章Bugfree介绍 (4)1.1Bugfree首页简介 (4)1.1.1查询结果 (5)1.1.1.1设置查询条件 (5)1.1.1.2快速筛选 (6)1.1.1.3自定义显示字段 (6)1.1.1.4查询结果排序 (7)1.1.2统计报表 (7)1.2Bugfree使用快捷键 (8)第2章管理员部分 (9)2.1登陆 (9)2.1.1登陆 (9)2.1.2登陆成功 (9)2.2编辑我的信息 (10)2.3后台管理 (10)2.3.1用户管理 (11)2.3.1.1新建用户 (11)2.3.1.2修改用户 (12)2.3.1.3禁用用户 (12)2.3.1.4激活用户 (12)2.3.2用户组管理 (13)2.3.2.1添加用户组 (13)2.3.2.2编辑用户组 (13)2.3.2.3禁用用户组 (14)2.3.2.4激活用户组 (14)2.3.3产品管理 (14)2.3.3.1添加产品 (15)2.3.3.2编辑产品 (16)2.3.3.3复制产品 (17)2.3.3.4合并产品 (17)2.3.3.5模块功能 (18)2.3.3.6bug字段管理 (20)2.3.3.7case字段管理 (22)2.3.3.8rusult字段管理 (24)2.3.4系统设置 (26)2.3.5管理日志 (27)2.3.6用户日志 (28)第3章测试人员部分 (29)3.1登陆 (29)3.1.1登陆 (29)3.1.2登陆成功 (29)3.2编辑我的信息 (30)3.3测试用例case (30)3.3.1新建case (31)3.3.2编辑case (32)3.4测试结果result (33)3.4.1新建Result (35)3.4.2编辑Result (36)3.5测试问题Bug (36)3.5.1创建与测试用例无关的问题记录 (36)3.5.2创建与测试用例有关的问题记录 (39)3.5.3修改Bug结果验证 (41)第4章开发人员部分 (44)4.1编辑我的信息 (44)4.2查看并解决分配给自己的bug (44)附录一：系统管理员、产品管理员和用户组管理员三种角色的详细权限 (48)附录二：Bug的三种状态 (49)第1章Bugfree介绍1.1Bugfree首页简介项目选择框：可快速切换当前项目，项目模块框和查询结果框显示相应的模块结构和记录。
禅道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)本文档定义了 bug 管理流程及其 bug 相关信息内容。
本文档合用范围：本文档合用于新产品以及以后新产品的项目。
原有项目的bug 管理仍然用 JIRA 系统进行管理。
本文档合用于新产品以及以后新产品的项目相关的测试人员和开辟人员。
测试人员登录禅道系统，创建 Bug。
Bug创建 Bug 页面截图：页面字段注释：选择发现 Bug 的产品，必填项。
：选择发现 Bug 的对应模块，必填项。
：选择测试所属的项目。
必填项。
bug 的版本。
必填项。
Bug 内容，相当于 BUG 的中心语句。
必填项。
在标题上注明 bug 浮现的频率(稳定浮现/时常浮现/很少浮现/浮现一次)[环境] Bug 的环境，需要在重现步骤里详细描述环境信息，以便于开辟定位和解决问题。
[步骤]：写明浮现 Bug 的操作步骤，要求简单，去掉与 Bug 无关的步骤。
[结果]：写明操作的实际结果。
[期望]：写明操作的期望结果。
：选择与 Bug 相关的需求。
如果 Bug 关联测试用例， 系统会自动关联测试用例的需求。
：选择与 Bug 相关的任务。
这里的任务是在『->『 中创建的任务。
Bug 类型如下：代码错误：功能性错误。
界面优化设计缺陷 配置相关 安装部署 安全相关 性能问题 标准规范 测试脚本 其他Bug 严重程度如下：范例1．系统蓝屏，崩溃2．由于程序所引起的死机,非法退出 3． 死循环4． 数据库发生死锁5． 因错误操作导致的程序中断 6．与数据库连接错误 7． 数据通讯错误 1． 功能不符 2． 程序接口错误3． 数据库的表、业务规则、缺省值未 加完整性等约束条件 4． 主要功能错误1． 操作界面错误(包括数据窗口内列 名定义、含义是否一致) 2． 打印内容、格式错误3． 简单的输入限制未放在前台进行控 制4． 删除操作未给出提示 5． 数据库表中有过多的空字段 1． 界面不规范 2． 辅助说明描述不清晰 3． 输入输出不规范 4． 长期操作未给用户提示 5． 提示窗口文字未采用行业术语 6． 可输入区域和只读区域没有明显的 区描述所产生的问题导致系统崩溃，蓝屏，停 顿；缺少主要功能或者主要功能毫无作用， 导致无法进行下一步测试。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Bug 的标题
Bug的标题在很多情况下是一个有力的和项目组成员之间的沟通工具，在很多情形下，能够做决定的人都不会去仔细的看bug的描述，而只是查看bug的标题，然后就下结论。
通常的产品经理，team leader还有其他的经理们也都是只会关注到bug的标题。
Bug的标题必须简短而且要求描述和传达出准确的信息。
因为有长度的限制，这个概要的描述一般都比较短，使用一些不会引起歧义的简写比好的语法和句子更好。
因为许多使用者习惯于用关键词来搜索，所以在bug的标题中使用一些精练的关键词事很有必要的，象挂起，异常中止，拼写错误等都是比较有效的和有力的搜索关键字。
如果长度允许，在bug的标题中有必要加上诸如环境，影响等5个W（why，when，who，where，what）的问题。
有一些bug跟踪的工具会自动把bug的第一行的bug描述做为bug的标题，永远不要使用这样的默认标题，要尽可能的特殊和精确。
例如：下面的标题就没有提供足够多的信息。
标题：在保存和恢复数据成员时出错。
一个比较好的标题可能是这样：在WINNT环境下，XYZ的保存和恢复数据失败，数据丢失。
通常在bug的标题中你不会得到任何你想得到的信息，下面是一个写bug标题应该注意的几点：
简单，明确的说明问题（不能只是说出现问题）
建议（如果长度允许的话）：
使用有意义的单词
描述环境和影响
回答5W1H的问题
使用简写
相对于描述清楚而言，语法不是很重要不要使用测试工具提供的默认的标题。