测试BUG记录表模板

XXX项目系统测试报告
变更履历
说明：“变更原因”主要是分为：
1.建立初稿
2.内容修订
3.正式发布
目录
1. 概述 (4)
1.1. 项目简介 (4)
1.2. 测试概要 (4)
1.3. 测试对象 (4)
1.4. 测试总体执行情况 (4)
2. 测试分析 (4)
2.1. BUG趋势分析 (4)
2.2. 本版本各模块BUG严重级别分布图 (5)
2.3. 本次测试中发现HIGH级别以上的BUG (5)
2.4. 测试进度分析 (5)
2.5. 测试过程中遇到的问题及解决方案 (5)
3. 度量数据收集 (5)
4. 附件 (6)
1.概述
1.1.项目简介
项目简介内容
1.2.测试概要
1.3.测试对象
1.4.测试总体执行情况
2.测试分析
2.1.BUG趋势分析
图1 BUG状态趋势分析图2.2.本版本各模块BUG严重级别分布图
BUG各模块统计截图
图2 各模块BUG严重级别对应分析图2.3.本次测试中发现HIGH级别以上的BUG
2.4.测试进度分析
2.5.测试过程中遇到的问题及解决方案
表2 问题及解决方案
3.度量数据收集
表3 系统测试度量
注2：缺陷清除率--修改的缺陷数/总缺陷数4.附件。

bug分析报告模板在99年的Quality week上的一次演讲中，微软的一个测试经理，Roger Sherman指出了由于“不可重现”导致bug关闭的主要原因。

这是一个非常可惜的情况，因为这样的bug report浪费了紧张的开发计划中的宝贵时间，增加了对产品质量完全是无关紧要的事情，同时导致了在开发人员和测试之间的挫败感和差的感觉。

有时， bug report是由于短暂的或随机的事件，测试和开发之间不一致的工具和配置，或者在测试的环境下对正确的行为的模糊定义而产生的，但是许多的由于不可重现而被关闭的测试报告是因为描述不清晰，被误解，或者只是文字的错误。

幸运的是，我学习到一些能够引起管理层注意，更清楚的和开发人员沟通并得到修复的编写优秀bug report的诀窍。

这些技巧不仅仅提供了是在被修复的问题的比例方面得到了可靠的回报，而且在同开发人员和管理层的通过中也得到了回报。

在我管理的项目中使用这种方法编写bug report，8份bug report中大约只有一个没有被修复。

这篇文章的思想只有当你的报告针对的测试执行过程是专业的质量工作才可以发挥作用。

聪明地执行完整的测试包是产生可靠的测试状况信息的基础的其中一个因素。

在许多的测试文献中广泛地介绍了多种多样的关于如何构建这样的测试包的方法。

选择和你质量风险管理需求相一致的技术并且使之适应你的具体情况，敏捷地监督已计划的测试的执行过程，这样你就可以拥有可靠的测试执行过程。

另外一个关键的因素－bug report，却没有得到太多的关注。

这是非常令人遗憾的，因为优秀的bug report对反映测试小组真实的和可理解的工作质量同测试本身一样都是非常重要的。

试想一下：如果你不能用开发人员能够理解的术语和能够用于调试的方法给开发人员解释一个错误，他怎么能够修复问题呢？如果你不能够在bug report中提出象“保险杆标签”（bumper sticker）一样的错误总结来引起管理层的注意，你又如何让他们关心你们发现的问题呢？Bug report的核心是对错误的描述。

bug记录表No模块名称BUG描述1综合管理/权限管理前台收银时的开单、点菜、退菜、换菜等功能无法在此处实现，应添加相关按钮2前台收银/开单开单时，一名服务员可以服务的客人数量没有限制3前台收银/开单开单时，一名服务员可以服务的包间或桌子数量没有限制4前台收银/开单同一个包间或桌子可以开单的数量应该有限制5前台收银/菜品调价菜品调价应该不能调为零6前台收银/提示开关提示开关无效7前台收银/打印点菜单没有连接打印机时，打印功能仍能运行，但没有给出任何提示。

8前台收银用鼠标拖动滚动条时，对话框不能实时滚动9前台收银/屏保点开屏保后，所弹出的对话框无法关闭10前台收银/结账最低消费无法更改，一直为零11前台收银/结账服务费无法更改，一直为零12前台收银/结账结账时，菜品打折应该有所限制13前台收银结帐时，如果顾客被选为VIP成员（中行－金卡），并且采用非打折方式时，VIP成员的打折算法会出错。

14前台收银/换桌如果将客人换至另一个已有其他客人的包间，仍可以操作，造成混乱15前台收银/菜品评议此模块中，如果不能查出账单，系统不能自动给出提示。

16前台收银/屏保没有屏保17前台收银/当日消费单据没有连接打印机时，打印功能仍能运行，但没有给出任何提示。

18前台收银/当日消费单据如果查不出账单或查询条件选择错误，系统不能给出任何提示。

19综合管理/大堂管理/客户管理新增功能中的姓名项应该设置为能重复20综合管理/大堂管理/客户管理新增功能中的客户姓名数据类型不正确21综合管理/大堂管理/客户管理新增功能中的电话号码数据类型不正确22综合管理/大堂管理/客户管理新增功能中的手机号码数据类型不正确23综合管理/大堂管理/客户管理新增功能中的身份证号码数据类型不正确24综合管理/大堂管理/客户管理新增功能中的卡凸号数据类型不正确25综合管理/大堂管理/客户管理新增功能中的卡号数据类型不正确26综合管理/大堂管理/客户管理新增功能中的身份证号码长度不正确27综合管理/大堂管理/客户管理新增功能中的身份证号码应该禁止输入特殊字符28综合管理/大堂管理/客户管理新增功能中的电话号码应该禁止输入特殊字符29综合管理/大堂管理/客户管理新增功能中的邮政编码应该禁止输入特殊字符30综合管理/大堂管理/客户管理新增功能中的卡号应该禁止输入特殊字符31综合管理/大堂管理/客户管理用鼠标拖动滚动条时，对话框不能实时滚动32综合管理/大堂管理/客户管理新增功能中的荣誉度没有大小限制33综合管理/大堂管理/客户管理新增功能中的卡凸号应该禁止输入特殊字符34综合管理/大堂管理/客户管理没有连接打印机时，打印功能仍能运行，但没有给出任何提示。

1．建议的格式――――――――――――――――――――――――――――――――Summary××××××DescriptionActions1. ××××××2. ××××××3. ××××××Actual Result××××××Expected Result（可选）××××××2．注意点：――――――――――――――――――――――――――――――――1. 缺陷摘要（Summary）简单明了，便于理解长度一般不超过30个单词尽可能讲明：什么情况，导致了什么问题以便于他人定位Bug，杜绝不重复报相同的Bug2. 缺陷描述（Description）重现步骤（Action）详细描述重现该问题的关键步骤省略无关的操作，力求做到：所有重现步骤是充分的和必要的容易理解的常规步骤，可以一句话带过，比如“以管理员身份登录，进入后台用户管理页面”和环境有关的问题，给出特定的条件，比如某某操作系统，某某浏览器实际结果（Actual Result）描述实际出现的错误结果可借助截屏来表达不是总能重现的Bug，给出发生频率或规律预期结果（Expected Result）可选，Spec上没有做详细要求，用于测试人员表达自己的看法3. 截屏/附件（Attachment）针对文字难以表达的或UI方面的问题图片格式使用JPG格式；BMP图片太大，不建议使用在图片上用醒目的颜色，标出问题所在区域也可考虑配上简短的文字4. 其它对于多人同时测试同一模块的情况，报Bug前先检查是否已有类似的Bug (TD 提供了Find Similar Defects的功能)Bug严重程度(Severity)必须准确Bug优先级(Priority) 必须准确（具体请参考公司标准文档）填写Module字段，便于Dev Manager 分配给相应的开发人员项目中共性的问题，纳入Common Module多个相同的问题，如是一个Dev负责完成的，撰写一个缺陷报告就可以，但须列出问题所在的多个位置对于Reject的有争议的Bug，尽可能和Dev当面沟通Windows截图快捷键:截图类型截图快捷键说明全屏幕PrintScreen 键当前活动窗口ALT + PrintScreen 键按住Alt 键，然后按下PrintScreen 键局部窗口系统不支持可借助截屏软件，如HyperSnap。

Bug跟踪规程目的This document describes how to file and track bugs for a project from early development stage to maintenance.This document describes the process from the following aspects: Who, When, Where, What, How.Intended readers: Bugzilla administrator, and project's tester, developer, maintainer, partner.1适用范围描述系统测试阶段对bug的跟踪管理。

2制定Bug跟踪计划参考“Bug跟踪计划模版”编写项目Bug跟踪计划。

2.1指定Bug报告系统使用公司的bugzilla报告系统报告Bug。

该系统部署在/bugzilla/。

2.2定义项目基本信息测试人员可以根据项目情况修改Bug严重等级的定义以及响应时间。

默认的bug严重等级的定义以及响应时间如下：●Blocker（1级): Blocks development and/or testing work;●Critical（2级):crashes, loss of data, severe memory leak；●Major（3级）: major loss of function;●Normal（4级）●Minor（5级）: minor loss of function, or other problem where easy workaroundis present.●Trivial（6级）: cosmetic problem like misspelled words or misaligned text.●Enhancement（7级）:Request for enhancement.响应时间：除了5、6、7级以外的所有Bug 都应该在Bug Review Meeting前被检查和置态。

测试BUG记录表外呼前台：图二图三1.通讯录——个人通讯录——添加，图二图三1.知识树不能及时刷新，添加了内容后，需要重新回到此页面才能显示更新内容。

2.知识库——个人知识库——添加，若换行输入知识库内容，添加成功后，再次编1.个人管理——工作日报（每周小结）——添加，换行输入，保存出现如上图1所示，列表内容中包含换行符2.个人管理——工作日报（每周小结）——添加（添加过一次），输入内容单外呼后台：座席信息——座席工作组设置——添加，在弹出窗口中工作组描述文本框中不能座席信息——座席公告信息——添加。

第一次添加公告没有选择收取人，会提示如果勾选了收取人复选框后再勾选掉，也能添加成功。

如上图二。

所以字数多了会出错，且公告内容不能换行输入。

图二图三图四1.企业信息——客户类型——添加，弹出窗口中“客户类型名称”字段没有做字符限制，添加多了会出错，“客户类型描述”字段不能换行输入。

如图一图二图三图四1.企业知识库、共享知识库删除后都需要手动刷新页面才能显示，另外添加内容后，知识树需要手动刷新才能显示2.知识库管理——知识库结构——添加，“菜单名称”输入过多也会出错，如图一3.知识库管理——企业知识库——添加，信息标题、信息内容字数过多都会出先程序错误，且添加企业知识库时，没有选择信息分类，也可以添加成功，如图三4.知识库管理——知识库结构——编辑，若只想修改隶属菜单，单击保存，则电销前台：图二图三1.知识库——企业知识库——查询，无法执行查询2.知识库——个人知识库——添加，输入换行内容再查看时，弹出网页中出现换行符，如图三3.不论是企业知识库、个人知识库还是共享知识，查看时弹出网页的标题都是企业知识库，如图二修改反馈记录（格式：时间 + 修改情况）图二1.个人管理——工作日报——添加，在弹出窗口中换行输入内容后，则列表中出现图一所示2.个人管理——每周小结——添加，在弹出窗口中换行输入内容后，则列表中出现图二所示3.如果每周小结/日报，添加过一次不允许添加弹出提示框后应立即关闭“添加每电销后台图二电销管理——电销号码分配——号码分配，在弹出号码分配窗口中，选择列表中的号码分配，弹出窗口，如图一所示。

竭诚为您提供优质文档/双击可除
bug文档模板
篇一：bug模板
测试人员在提交bug时统一报bug模板，参考如下：
概要：【模板】bug简要描述（包含：现象、动作、概率、场景）预置条件：
1.进入xx网站
2.账号登录情况（或手机wiFi连接情况）
操作步骤：
1.操作a
2.操作b
3.操作c
实际结果：
4.实际结果xxx
预期结果：
5.预期结果xxx
出现概率：例如100%、1/10等
log及图片路径：建议测试人员抓取log及问题pic
版本号：v0.1
log）（概率问题尽量保持
篇二：bug报告模板(经典)
bug管理与改错计划
问题优先级
分五个等级，即p1~p5，p1的优先级别最高，之后逐级递减。

bug严重程度
bug状态
新建状态（new）bug创建后的初始状态。

已分配状态（open）
经过确认有效的问题后分配给开发人员的状态。

拒绝状态（Rejected）验证不是有效的问题解决状态（Fixed）开发人员处理此问题后的状态结束状态（closed）
经测试部门对修改后的软件问题进行验证并确认修改正确后的状态。

重新打开状态（Reopened）对开发部门修改后软件问题，经过验证，如果仍然存在，则将其状态改为“重新打开”状态。

对于“关闭/延迟修改”状态的软件问题，如果时机成熟，需要重新开发，则将
其状态改为“重新打开”状态。

篇三：bug报告模板(经典)
bug管理与改错计划。