缺陷记录模板
软件产品缺陷报告 模板
软件产品缺陷报告一.简介1.1目的本文档作为《XXX系统》之< XX系统>的“缺陷报告”，有助于实现以下目标：A、列出测试活动的主要内容。
B、列出测试活动的测试统计结果。
C、列出系统的主要缺陷。
D、对于缺陷提出的修改建议。
E、由于本系统的某些需求尚未最后确定，目前只能对系统进行部分的功能测试及完全的用户界面测试。
F、本报告为针对测试活动的首次缺陷报告，以后的测试活动还会提交迭代的缺陷报告。
G、本文档提交给项目组的管理者及开发人员审阅。
二.测试内容下面的列表列出了本次测试活动的主要测试内容。
2.1数据库测试核实系统是否能访问数据库。
2.2功能测试核实..2.3用户界面测试浏览所有的用例，核实是否每个 UI 面板都易于理解。
核实界面操作是否简单易行，图形显示是否清晰。
三.测试统计结果及缺陷总结3.1数据库测试3.1.1核实系统是否能访问数据库。
3.2功能测试3.2.1核实是否能够浏览数据库中保存的电子化文档；3.2.2核实是否能够查找和检索资料；3.2.3核实是否能够实现资料文件的管理；3.2.4核实是否能够实现资料文件图片的导入；3.2.5核实是否能够实现资料文件图片的导出；3.2.6核实是否能够实现资料的打印输出；3.2.7核实是否具有灵活的显示模式，如放大、缩小等。
3.3用户界面测试3.3.1窗口3.3.2下拉式菜单和鼠标操作3.3.3数据项四.针对缺陷提出的建议4.1功能方面 4.2用户界面方面。
软件测试的缺陷报告模板
软件测试的缺陷报告模板在软件开发过程中，测试是一个至关重要的环节。
而缺陷报告则是测试过程中必不可少的一环。
本文将介绍一种常用的软件测试的缺陷报告模板，以帮助测试人员有效地记录和跟踪软件缺陷。
1. 缺陷报告的目的和重要性缺陷报告是测试过程中记录和追踪软件缺陷的文件。
它的目的是帮助开发人员和相关团队了解和修复软件中的问题，以提高软件的质量和稳定性。
缺陷报告的重要性在于它可以帮助团队更好地进行沟通和协作，准确地描述和定位缺陷，并有效地跟踪缺陷的修复进度。
2. 缺陷报告模板的结构和要求一个好的缺陷报告模板应该具备清晰的结构和明确的要求。
以下是一个常用的缺陷报告模板的结构和要求：2.1 缺陷基本信息•缺陷ID：每个缺陷需要有一个唯一的标识符，方便后续跟踪和引用。
•缺陷标题：简洁明了地描述缺陷的概要。
•缺陷严重程度：根据软件的功能和影响程度，对缺陷进行分类，例如高、中、低等级。
•缺陷优先级：根据缺陷的紧急程度和影响范围，对缺陷进行分类，例如高、中、低等级。
•缺陷状态：描述缺陷当前所处的状态，例如新建、已分配、已修复、已验证等。
•缺陷提交者：记录缺陷报告的提交人信息。
2.2 缺陷描述•重现步骤：详细描述如何重现缺陷的步骤，包括输入数据、操作流程等。
•期望结果：说明在没有缺陷的情况下，期望得到的结果。
•实际结果：描述在重现步骤后，实际得到的结果。
•屏幕截图：如果可能的话，提供缺陷发生时的屏幕截图，以便更好地理解和定位问题。
2.3 缺陷分析和定位•影响范围：描述缺陷对软件功能和用户体验的影响范围。
•复现频率：记录缺陷发生的频率，以便评估其对软件稳定性的影响。
•缺陷原因：分析和定位缺陷的根本原因，例如代码逻辑错误、界面设计问题等。
•相关附件：如果有相关的日志文件、配置文件等附件，可以附加在缺陷报告中。
2.4 缺陷跟踪和修复•缺陷分配：将缺陷分配给相应的开发人员或团队，以便后续的修复工作。
•缺陷修复时间：记录缺陷被分配后的修复时间，以便对团队的工作效率进行评估。
内部控制制度缺陷模版（3篇）
内部控制制度缺陷模版一、概述：内部控制制度是组织或机构为实现管理目标而制定的一系列规章制度和程序。
然而，由于各种原因，内部控制制度可能存在缺陷，这可能导致组织无法有效地管理和控制风险。
本文将介绍一些常见的内部控制制度缺陷模板。
二、缺陷模板：1. 目标设定不明确：- 缺陷描述：组织的管理目标不明确，缺乏明确的方向和指导，导致内部控制制度无法对风险和问题做出适当的响应。
- 可能的原因：领导层对目标设定缺乏关注，组织规划不清晰，缺乏有效的战略和目标管理。
2. 控制措施不完善：- 缺陷描述：组织的内部控制措施不完善，无法覆盖全部风险，存在重要的控制盲区。
- 可能的原因：控制措施设计不合理，缺乏全面的风险评估，对风险可能产生的影响没有充分考虑。
3. 职责分工不清晰：- 缺陷描述：组织的职责分工不清晰，各部门之间存在职权冲突或责任模糊，无法有效地协调和合作。
- 可能的原因：组织结构不合理，职责和权限划分不明确，缺乏有效的沟通和协调机制。
4. 信息系统不可靠：- 缺陷描述：组织的信息系统存在漏洞和薄弱环节，可能会导致数据错误、丢失或泄露，从而使内部控制失效。
- 可能的原因：信息系统建设不完善，网络安全措施不到位，对信息系统的维护和监控不够重视。
5. 人员素质不高：- 缺陷描述：组织的员工素质不高，缺乏必要的专业知识和技能，无法有效地执行内部控制制度。
- 可能的原因：招聘和培训机制不完善，员工对内部控制的重要性缺乏认识，缺乏监督和评估机制。
6. 监督机制不健全：- 缺陷描述：组织的内部监督机制不健全，无法对内部控制制度的执行情况进行有效监督和评估。
- 可能的原因：监督机制不完善，缺乏有效的内部审计和风险评估机制，组织领导对监督机制缺乏重视。
7. 奖惩机制不合理：- 缺陷描述：组织的奖惩机制不合理，无法对违规行为进行及时和适当的处罚，导致内部控制制度失效。
- 可能的原因：奖惩机制设计不合理，缺乏明确的奖励和惩罚措施，无法根据风险和问题的严重程度进行适当的处罚。
船舶大修缺陷报告模板
船舶大修缺陷报告模板1. 前言本文档旨在提供一个船舶大修缺陷报告的模板，以便于船舶维修公司或船东按照统一格式快速准确地填写缺陷报告，并供船级社、海事局或其他有关部门审核使用。
2. 简介船舶大修缺陷报告是针对船舶大修期间出现的问题，由船东或船舶维修公司向相关部门或机构报告的一种文书。
缺陷报告必须详细记录出现的问题，以及解决方案和预防措施。
缺陷报告可以帮助船舶维修公司改进工作，使船舶维护更加完善，同时也是对船舶安全的保障。
3. 缺陷报告内容缺陷报告应包括以下内容：3.1 船舶基本信息•船舶名称：[填写船名]•船舶IMO号：[填写IMO号]•船舶类型：[填写船型]3.2 缺陷信息•缺陷描述：[详细描述缺陷情况，包括发生时间、位置、原因等信息]•缺陷等级：[按照缺陷等级分类，如A、B、C级]•解决方案：[说明如何解决缺陷问题，包括所需要的时间、修理方式、所需材料等信息]•预防措施：[对于相同或相似的缺陷，提出预防措施，以防再次发生]3.3 缺陷修复情况•修复情况：[说明缺陷已经修复的情况，包括修复时间、修复方式、使用的材料等信息]•修复结果：[说明修复后的结果如何，是否符合要求]4. 缺陷等级针对缺陷问题，可以按照以下等级分类：•A级：严重缺陷，可能导致船舶进入不安全状态•B级：中等缺陷，可能影响船舶的效能•C级：一般缺陷，对船舶的技术状态没有直接影响5. 缺陷报告流程船舶维修公司或船东在发现船舶大修期间出现的问题后，应该尽快向船级社或海事局报告。
缺陷报告要经过审核才能得到批准。
缺陷报告流程如下：•船舶维修公司或船东填写缺陷报告•对缺陷报告进行审核，包括现场审核和文件审核•如果审核通过，船级社或海事局将对缺陷报告进行批准•缺陷报告批准后，船舶维修公司或船东需要按照报告中所述的方案进行修复•修复完成后，需要向船级社或海事局提交修复报告6. 结论船舶大修缺陷报告是船舶维修公司或船东对于维修缺陷的一种主动报告方式，尤其在保障船舶安全方面具有十分重要的作用。
缺陷报告书-模板
待测软件名称XX测试缺陷报告书目录1引言 (3)1.1编写目的 (3)1.2背景 (3)1.3定义 (3)1.4参考资料 (3)2测试环境 (4)2.1硬件环境 (4)2.2软件环境 (4)3冒烟测试 (4)3.1被测软件 (4)3.2测试策略 (4)3.3执行步骤 (4)3.4测试用例执行情况 (4)3.4.1 管理员 (4)3.4.2 匿名用户 ................................................................... 错误！未定义书签。
3.4.3 教师用户 ................................................................... 错误！未定义书签。
3.4.4 学生用户（待补充）.................................................. 错误！未定义书签。
3.4.5 交叉功能测试 ............................................................ 错误！未定义书签。
3.5结果分析和结论 (9)4功能测试......................................................................................... 错误！未定义书签。
4.1被测软件 ............................................................................... 错误！未定义书签。
4.2测试策略 ............................................................................... 错误！未定义书签。
软件测试缺陷报告模板
软件测试缺陷报告模板1. 引言软件测试缺陷报告是软件测试过程中的重要文档之一，用于记录和跟踪在软件开发过程中发现的缺陷信息。
本报告旨在提供一个模板，以便测试团队能够按照统一的格式和标准来编写缺陷报告，从而方便开发人员进行问题解决和跟踪。
2. 缺陷报告信息在编写缺陷报告之前，需要收集以下基本信息：•缺陷编号：每个缺陷需要一个唯一的编号，以便于跟踪和引用。
•缺陷标题：简明扼要地描述缺陷的问题。
•缺陷严重程度：根据影响范围和严重性进行评估，如轻微、一般、严重等。
•缺陷优先级：根据缺陷的重要性和紧急程度进行评估，如高、中、低等。
•缺陷状态：缺陷的当前状态，如新建、已分配、已修复、已验证等。
•缺陷报告人：填写报告人的姓名或者工号，以便后续联系和沟通。
3. 缺陷描述在这一部分，需要详细描述缺陷的问题。
描述时应包括以下内容：•环境说明：描述缺陷出现的软硬件环境，如操作系统、浏览器、设备等。
•复现步骤：提供详细的操作步骤，以便开发人员能够重现缺陷。
•预期结果：描述在执行步骤的过程中希望看到的正确结果。
•实际结果：描述实际出现的问题或错误信息。
4. 缺陷重现为了帮助开发人员更好地理解和定位缺陷，测试人员可以尝试多次重现缺陷，并记录重现步骤和结果。
当开发人员需要进行问题排查和修复时，这些信息将非常有用。
5. 缺陷截图/日志如果缺陷涉及到界面显示或者错误信息的输出，测试人员可以通过截图或者记录相关日志来进一步说明问题。
在报告中插入截图或者简要描述日志内容，但不要涉及敏感信息。
6. 缺陷影响范围在这一部分，可以描述缺陷对软件系统的影响范围和程度。
例如，缺陷是否会影响核心功能，是否会导致系统崩溃或数据丢失等。
7. 缺陷修复建议根据对缺陷的分析和理解，测试人员可以提供一些修复建议，以便开发人员进行问题解决。
建议应该具体、明确，尽量提供解决问题的思路或者方法。
8. 缺陷验证在缺陷修复后，测试人员需要重新验证缺陷是否得到解决。
BUG清单模板
BUG编号 发现日期 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
发现版本
对映功能点
3：严重 2：一般 1：轻微
BUG统计
0 0 0Leabharlann 合计0日期
BUG描述
BUG级别
BUG状态
备注
New Open Fixed Abandoned Reopen By Design Waiting Closed 合计
轻微bug状态定义缺陷状态newopenfixedabandonedreopendesignwaitingclosed级别定义影响正常业务运营的缺陷功能存在缺陷未满足业务需求但是不影响业务运营操作不方便界面或提示错误但是不影响业务操作状态定义新提交缺陷开发人员确认看到缺陷并分析处理开发人员已修复缺陷测试人员重复提交或者无效的缺陷开发人员修改后验证未通过的缺陷设计问题暂不处理等待发布新版本缺陷经验证并通过bug级别定义bug状态定义
状态定义 新提交缺陷 开发人员确认看到缺陷并分析处理 开发人员已修复缺陷 测试人员重复提交或者无效的缺陷 开发人员修改后验证未通过的缺陷 设计问题 暂不处理，等待发布新版本 缺陷经验证并通过
0 0 0 0 0 0 0 0 0
BUG级别定义
级别 3：严重 2：一般 1：轻微
BUG状态定义
级别定义 影响正常业务运营的缺陷 功能存在缺陷，未满足业务需求，但是不影 响业务运营 操作不方便，界面或提示错误，但是不影响 业务操作
缺陷状态 New Open Fixed Abandoned Reopen By Design Waiting Closed
质量缺陷处理记录表格模板
精心整理质量缺陷处理记录表编号：001工程名称形象进度主体施工单位项目经理监理单位项目总监序号记录内容1 质量缺陷名称蜂窝、麻面2 质量缺陷部位（轴线、标高、楼层）1#楼三层2-Q轴～2-R轴/2-26轴3 质量缺陷描述剪力墙根部局部漏浆产生麻面4 质量缺陷定性一般缺陷5 一般缺陷，施工单位按技术处理方案处理的记录松散砼凿除干净，1：3水泥砂浆修补。
6 严重缺陷施工单位提出的技术处理方案无监理（建设）单位对技术处理方案的审批情况无7 严重影响结构安全和使用功能的缺陷经有资质检测单位检测鉴定达不到设计要求但经原设计单位核算并确认仍可满足结构安全和使用功能的处理情况无8 其他处理情况的记录（返工、更换）无9 缺陷部位经监理（建设）单位检查验收情况前后工序按方案进行修补检查结论处理过程均按方案要求进行，符合要求施工单位项目技术负责人：2014年6月2 日验收结论合格监理工程师（建设单位项目技术负责人）：2014年6月2 日修补前修补后质量缺陷处理记录表编号：004工程名称形象进度主体施工单位项目经理监理单位项目总监序号记录内容1 质量缺陷名称吊脚2 质量缺陷部位（轴线、标高、楼层）5#楼八层7-M轴～7-S轴/7-16轴剪力墙3 质量缺陷描述楼梯剪力墙根部局部产生吊脚4 质量缺陷定性一般缺陷5 一般缺陷，施工单位按技术处理方案处理的记录凿除涨出部份砼，采用水泥砂浆补平6 严重缺陷施工单位提出的技术处理方案无监理（建设）单位对技术处理方案的审批情况无7 严重影响结构安全和使用功能的缺陷经有资质检测单位检测鉴定达不到设计要求但经原设计单位核算并确认仍可满足结构安全和使用功能的处理情况无8 其他处理情况的记录（返工、更换）无9 缺陷部位经监理（建设）单位检查验收情况前后工序按方案进行修补检查结论处理过程均按方案要求进行，符合要求施工单位项目技术负责人：2014年7月2 日验收结论合格监理工程师（建设单位项目技术负责人）：2014年7月2 日修补前修补后质量缺陷处理记录表编号：008工程名称形象进度主体施工单位项目经理监理单位项目总监序号记录内容1 质量缺陷名称蜂窝2 质量缺陷部位（轴线、标高、楼层）3#楼十八层5-A轴～5-C轴/5-6轴剪力墙3 质量缺陷描述剪力墙根部局部蜂窝4 质量缺陷定性一般缺陷5 一般缺陷，施工单位按技术处理方案处理的记录凿除松散部份砼，采用水泥砂浆修补6 严重缺陷施工单位提出的技术处理方案无监理（建设）单位对技术处理方案的审批情况无7 严重影响结构安全和使用功能的缺陷经有资质检测单位检测鉴定达不到设计要求但经原设计单位核算并确认仍可满足结构安全和使用功能的处理情况无8 其他处理情况的记录（返工、更换）无9 缺陷部位经监理（建设）单位检查验收情况前后工序按方案进行修补检查结论处理过程均按方案要求进行，符合要求施工单位项目技术负责人：2014年11月10 日验收结论合格监理工程师（建设单位项目技术负责人）：2014年11月10 日处理前处理后质量缺陷处理记录表编号：009工程名称形象进度主体施工单位项目经理监理单位项目总监序号记录内容1 质量缺陷名称涨模2 质量缺陷部位（轴线、标高、楼层）5#楼二十层7-A轴～7-C轴/7-6轴剪力墙3 质量缺陷描述剪力墙局部涨模4 质量缺陷定性一般缺陷5 一般缺陷，施工单位按技术处理方案处理的记录凿除涨出部份砼6 严重缺陷施工单位提出的技术处理方案无监理（建设）单位对技术处理方案的审批情况无7 严重影响结构安全和使用功能的缺陷经有资质检测单位检测鉴定达不到设计要求但经原设计单位核算并确认仍可满足结构安全和使用功能的处理情况无8 其他处理情况的记录（返工、更换）无9 缺陷部位经监理（建设）单位检查验收情况前后工序按方案进行修补检查结论处理过程均按方案要求进行，符合要求施工单位项目技术负责人：2014年11月15日验收结论合格监理工程师（建设单位项目技术负责人）：2014年11月15 日处理前处理后。
混凝土外观质量缺陷(麻面)处理记录-填写范例-附前后照片
HQD-
修
补
前
图
片修Βιβλιοθήκη 补好前图
片
混凝土外观质量缺陷(麻面)处理记录
工程名称
百色市第一建筑公司住宅楼工程(3#、4#楼)
编号
HQ J-
工程部位
验收日期
年月日
缺陷情况：
混凝土表面局部出现缺浆粗糙或有小凹坑、麻点、气泡等，形成粗糙面，但混凝土表面无钢筋外露现象。
原因分析：
□(1)模板表面粗糙或粘附硬水泥浆垢等杂物未清理于净，拆模时混凝土表面被粘坏；
□(2)模板未浇水湿润或湿润不够，构件表面混凝土的水分被吸去，使混凝土失水过多出现麻面；
□(3)模板拼缝不严，局部漏浆；
□(4)模板隔离刑涂刷不均匀，局部漏刷或失效，混凝土表面与模粘结造成麻面；
□(5)混凝土振捣不实，气泡未排出，停在模板表面形成麻点。
处理的技术措施：
先将麻面处凿除到密实处，用清水清理干净，再用喷壶向混凝土表面喷水直至吸水饱和，将配置好的水泥干灰均匀涂抹在表面，此过程应反复进行，直至有缺陷的地方全部被水泥灰覆盖。待24 h凝固后用镘刀将凸出于衬砌面的水泥灰清除，然后按照涂抹水泥灰方法进行细部的修复，保证混凝土表面平顺、密实。
处理结果：
1、表面平整，与原混凝土接触密实，无开裂现象。
2、附件：修补前后照片：；
验收意见：
1、表面平整、密实，达到规范要求。
监理（建设）单位
施工单位
监理工程师（员）
项目技术负责人
质检员
施工员
签字：
年月日
签字：
年月日
签字：
年月日
签字：
年月日
混凝土外观质量缺陷(麻面)处理记录附图
工程名称
设备缺陷记录填写说明及记录本模板(专)
设备缺陷记录填写说明1.变电设备包括：110kV变电站内设备以及35kV（10kV）电缆、集电线路、箱变、逆变器、汇流箱、光伏板、组窜至汇流箱电缆。
2.变电设备缺陷的分类及上报1)变电一类设备缺陷（重大缺陷）包括以下方面：造成升压站部分或全部停运的缺陷；造成集电线路停运的缺陷；因线路故障造成升压站停运的缺陷和光伏电站内其他严重威胁人身、设备安全，必须立即处理的缺陷。
发现此类缺陷应立即报告当班值长。
2)变电二类设备缺陷（较大缺陷）包括以下方面：集电线路发生的缺陷需停电处理但可以安排在光伏较弱或计划检修处理的缺陷；升压站发生的缺陷需停电处理但可以安排在升压站计划检修处理的缺陷；送出线路发生的缺陷需停电处理但可以安排在线路计划检修处理的缺陷和光伏电站内其他威胁人身、设备安全，必须立即处理，但不影响发电出力的缺陷。
发现此类缺陷应立即报告当班值长。
3)变电三类设备缺陷（一般缺陷）：是指变电站内的设备出现异常，对安全、经济、稳定运行产生影响，但未构成一、二类设备缺陷的缺陷。
发现此类缺陷应立即报告当班值长。
3.光伏电站得到变电设备各类缺陷报告后，应记入“设备缺陷记录本”，写明部位、程度及有关数据。
4.维护单位在试验中发现的缺陷，也应通知运维人员，由运维人员登记缺陷。
5.设备缺陷的主要来源1)运维人员在巡视、检查过程中所发现的缺陷，或设备运行中自动装置报出的缺陷。
2)维护人员在定期检查、大修、小修或临修过程中发现的缺陷及异常。
3)电气预防性试验、交接试验中所发现的缺陷及异常。
4)其他监督人员、专业专职人员等在检查和维修工作中发现的缺陷及异常。
6.处理后的缺陷，应经当班值长验收并签名。
确认缺陷消除后，工作负责人在“设备缺陷记录”•缺陷处理情况栏内注明处理意见并签名，运维人员在缺陷处理情况及消除时间栏加盖“已消除”章。
设备缺陷记录光伏电站年月。
缺陷描述模板
缺陷描述模板缺陷描述是在软件开发和测试过程中非常重要的一部分。
它是开发人员或测试人员向负责修复缺陷的人员准确描述缺陷的方式。
一个好的缺陷描述能够帮助开发人员或测试人员更快地定位和修复缺陷，提高开发效率。
为了准确描述缺陷并且让人容易理解，下面是一个缺陷描述模板的例子：标题：缺陷标题应该简明扼要地描述缺陷的问题，让读者一目了然。
标题通常包括缺陷的关键字和问题所在的位置。
严重程度：根据缺陷的影响程度，将其分类为严重、中等或轻微。
这可以帮助开发人员或测试人员优先处理重要的缺陷。
复现步骤：明确描述如何复现缺陷。
包括具体的操作步骤、输入数据、预期结果以及实际结果。
这可以帮助开发人员或测试人员重现缺陷，并对其进行调试和修复。
环境：描述缺陷出现的环境，包括操作系统、浏览器版本、硬件或软件配置等。
环境信息有助于开发人员或测试人员在相同环境中复现缺陷。
缺陷描述：详细描述缺陷的现象和问题。
包括具体的错误提示、异常行为、功能失败等。
详细的描述有助于开发人员或测试人员理解缺陷的本质，并采取正确的修复方法。
期望结果：明确描述缺陷应该产生的预期结果。
这有助于开发人员或测试人员确认缺陷是否真实存在，并指导修复的方向。
实际结果：描述缺陷实际产生的结果。
实际结果是与期望结果相对比的，可以更好地帮助开发人员或测试人员定位和解决问题。
附件：如果有相关的附件，如日志文件、截屏、录屏等，应提供相应的附件。
附件可以为开发人员或测试人员提供更多的信息和上下文，提高修复缺陷的效率。
备注：如果有其他补充信息或备注，可以在此处添加。
例如，缺陷相关的其他条件、复现率、复现频率等。
以上是一个常见的缺陷描述模板。
根据具体的项目和需求，可以根据需要进行相应的调整。
重要的是，准确地描述缺陷的问题，提供足够的信息以便开发人员或测试人员可以理解并复现缺陷。
一个好的缺陷描述可以提高开发效率，加快缺陷修复的速度，提升软件质量。
缺陷报告模板
缺陷报告模版主题：所属模块：附近餐厅页面中按餐厅类型筛选无效（在什么模块，什么情况下，发生怎样的问题what, when, where）（平台/接口）（如果软件端无法修改，需要平台修改或者由于接口不稳定发生的bug，需要将其标注为平台/接口问题）描述：预置条件：如什么网络环境下，手机内存容量，电量情况等（必要条件，无特定条件可不写）操作步骤：复现缺陷的步骤，及操作，一般情况下都已首页为初始界面例：1. 首页->附近餐厅2. 点击餐厅类型3. 选择火锅类型并点击确认预期结果：火锅类型的餐厅被筛选出来（需求中要求的结果）实际结果：筛选功能失效或筛选功能不准确，需指明具体具体错误点出现几率：100%（如通过操作步骤不是每次都出现，表明复现几率，测10次，如3/10) 改进建议：如无明确的需求，或者易用性缺陷，给出适当的改进意见；有明确需求可不写。
另外可以备注其他类似模块是否有同样的问题，最好一起修复<注意：主题和描述中对选项，按钮及输入框等的文字描述最好使用原文，方便搜索>状态：所有新报缺陷都是新建状态优先级：低：易用性缺陷或者UI显示以及刷新问题，现象不严重的；普通：较小的UI问题或者异常操作导致的功能问题，如果不会使程序崩溃等情况发生；高：普通操作导致的功能性问题（不太常用的模块），如果不导致程序崩溃只是没实现功能；立刻或紧急：常用模块功能未实现或导致软件崩溃甚至系统卡死的问题。
指派：新建时将问题指派给模块相应的开发人员，修复或者反馈状态的bug如果还需要反馈则将其指给改变bug状态的开发人员目标版本：选择当前问题发现的目标版本号，如果没有就新建一个版本号（bug建立后只能由测试人员改变目标版本）修复版本：该项有开发人员填写，测试人员根据修复版本号对软件进行验证测试设备：客户端产品：测试设备：小米1（系统版本 4.1.2 JZO54K）客户端版本：xxxx 基于第三方软件的产品（如微官网）：测试设备：小米1（系统版本4.1.2 JZO54K）微信版本：5.0.1多个测试设备都出现用逗号分隔文件：添加相应的错误截图责任人：在报bug时选择相应的开发人员，如果修改该bug的开发不是原来指派的人员，则验证关闭或者反馈bug时，责任人改为修复bug的开发人员。