一、最基本的要求：

         1、Bug内所有的文字表述要通顺，无错别字

         2、对各个模块的描述必须使用专有名词（比如搜索结果页、搜索监听页）

         3、Bug中的各项描述符合以下要求：

二、Bug标题

         1、标题头遵循“【版本号--模块】--标题内容"的格式来写（每次测试开始之前会强调一遍）

                   比如：

                   【YK4.5--登录】--xxxxxxxx

                   【YK4.5--适配测试--Pico】--xxxxxxxx

        【后台4.5--节目搜索接口】--xxxxxx

                   注意：版本号后面一定要写双横杠，否则PMS中搜索不出来

         2、标题内容

                   1）简明扼要的概括发现的问题（需要写明在哪个页面执行什么操作出现什么问题）

                   2）具体的测试步骤不应出现在标题里（学会归纳总结！）

三、复现步骤

         1、每一步按照操作顺序，用阿拉伯数字编排

         2、每一步需要详细写明进入操作页面的详细路径（从选片大厅开始描述，比如起播功能，步骤里需要说明，从哪个频道的哪个card下，起播的哪个视频，需要附奇谱id）

四、描述

         1、测试设备

                   小米、PICO G1、PICO G2、PICO G2 4k、大朋.....

                   如果是通用型的问题也需要注明

         2、测试环境

                   网络状态良好or弱网or断网

                   注意：

                            1）如果是测试过程中发生网络变化，还需要在步骤里说明，是在哪一步进行了网络的变化

                            2）弱网需要说明上下行的速率是多少

         3、复现率

                   需要说明该bug是必现的还是偶现

                   如果偶现必须说明偶现的百分比

五、期望结果

         按照测试步骤应当得到的正确结果，结果必须明确，无二意性。

         具体的需求文档截图可附在附件中

六、实际结果

         按照测试步骤实际出现的错误结果，避免使用“不正常”，“有误”，“不对”、“有问题”等模糊词汇，需要直接描述实际现象。

七、附件

         1、纯UI展示（比如字体颜色、大小、文案错误等），需要附截图，如果操作复杂，需要附视频

         2、功能类bug或功能导致的UI问题（比如做了某些操作后导致的UI重叠），需要附Log,截图/视频

         3、如果通过接口调用，确认接口数据无误的情况下，需要将接口的返回数据附截图说明

八、备注

         1、所有bug状态的改变都需要备注原因

         2、尽可能的多备注信息，便于后续跟踪

九、Bug定级（优先级）

         P0: 致命错误 （遇到这一级别的bug，可以暂停测试，待bug修复后再进行测试）

                   1、APP无法启动

                   2、该BUG引起主流程阻塞（比如视频无法起播，用户无法登录）

         P1:非常严重的错误        

                   1、常规操作造成的APP崩溃、闪退、卡死等等（90%用户使用过程中都会遇到）

                   2、需求明确定义的主要功能未完成（比如：离线功能未完成，下载视频无网情况下无法起播）

                   3、该bug引起大量测试用例无法进行测试（影响测试进度）

                   4、数据错误（和后台数据不一致，比如选片大厅加载数据错误、搜索结果和接口预期不符等）

                   5、安全问题（牵扯到付费的功能，比如4.7版本的收银台功能）

         P2:严重错误

                   1、非常规操作造成的APP崩溃、闪退、卡死等等（复杂操作才会引起）

                   2、非主要功能未实现（比如蓝光标识未显示），或者和需求设计严重不符（比如默认首次以最高清晰度起播，但是实际以最低清晰度起播）

                   3、UI显示有问题，用户明显可以看出（比如页面之间重叠、花屏、文案被截断等）

                   4、性能指标的严重回退（比如启动、起播时间不如上一个版本快，FPS没有上一个版本高）

                   5、常规操作之后，投递值缺失或者投递值错误、重复投递

                   6、版本升级后，导致的数据错误，或者不能起播

         P3:一般错误

                   1、功能完成，但是和需求设计有出入

                   2、功能和需求设计略微不符，用户在不了解需求的前提下发现不了

                   3、UI显示和产品/美术的设计不符（比如：控件大小，准星状态，文字的位置排列，错别字、不该显示的需要隐藏、提示文案错误或者丢失、手柄提示错误）

                   4、输入框未做校验/校验规则和需求不符（长度、格式、边界值等）

                   5、可以优化的性能指标

                   6、非常规操作之后，投递值缺失或者投递值错误、重复投递

                   7、版本升级后，导致的数据展示错误

         P4: 建议性bug （可以进行评估，不修改或者下个版本修复）

                   1、UI显示不美观、交互设计不合理

                   2、使用不符合用户操作习惯，用户体验不好

                   3、需求未明确定义，建议性的bug

                   4、站在用户角度的建议性bug

软件缺陷定义

  软件缺陷(Defect)：又叫做Bug。即为计算机软件、程序、web应用中存在的某种不符合正常运行的功能问题。也是错误、隐藏，让用户不满意的功能缺陷。

  从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题;

  从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

 缺陷报告定义

  缺陷报告把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件存在的质量问题提供依据，同时为软件验收和交付打下基础。

  协同公司在项目中采用的缺陷处理过程如下

  在软件测试过程中，缺陷报告起到了一个交接单的作用，它帮助开发人员和测试人员之间更有效的交流，提高了缺陷的解决速度和质量。同时也可以通过统计bug数来对被测的软件进行质量评估，比如根据以往项目中每千行bug数的平均值来制定测试计划，同类的产品，尤其是同一个开发流程的产品，这些数值不应该相差太多，如果相差一个数量级以上，我们几乎可以说，要么是QA出问题了，要么是开发出问题了。另外，降级bug的多少对于软件质量评估也是一个重要参考标准，降级bug也就是由于修正一个bug，又产生了一个新bug，降级bug数目过多意味着现在的产品在越修越坏。

  缺陷报告是测试过程中可以提交的最重要的东西。编写缺陷报告的目的是为了方便程序员找到程序出现的问题，从而有利于分析错误产生的原因，定位错误，修改问题。它的重要性丝毫不亚于测试计划，并且比其他的在测试过程中的产出文档对产品的质量的影响更大。因此，缺陷报告编写的基本要求是简洁、准确、完整、规范。有效的缺陷报告将能够：减少开发部门的二次缺陷率、提高开发修改缺陷的速度、提高测试部门的信用度、增强测试和开发部门的协作。那么在提交缺陷报告时，我们需要提交的就是一份简单明了、便于理解和查找问题的缺陷报告。

各个测试阶段中的测试点

 单元测试： 针对每个单元的测试，以确保每个模块能正常工作为目标。

 集成测试： 对已测试过的模块进行组装，进行集成测试。目的在于检验与软件设计相关的程序结构问题。

 系统测试： 检验软件产品能否与系统的其他部分(比如，硬件、数据库及操作人员)协调工作。

 验收测试： 检验软件产品质量的最后一道工序。主要突出用户的作用，同时软件开发人员也应有一定程度的参与，验收测试可以分成Alpha测试和Beta测试。

 Alpha测试： 由用户在开发环境下完成的测试

 Beta测试： 由用户在用户环境下完成的测试。

最近做一些测试新人培训工作，期间经历过几个小项目，项目总结会议上，其中有一个环节是说出项目中每个阶段团队成员在此次项目中的优缺点，大家需要畅所欲言，以为后续的项目提供更优的解决方案。而这次会议暴露出一个很严重的问题却使团队领导有些措手不及，有几个后端开发人员指出，每次看测试人员提交的缺陷报告都要看几遍，因为有时不在同一地方办公，无法面对面沟通，同时有些复现步骤写得要不长篇大论，没有分行；要不没有写前置条件，根据步骤也无法重现出来。同时标题与结果中也经常出现模糊定义，没有可判定性的结果。

上述问题不排除一些有经验的测试人员身上会发生，但更多地见于测试新人及实习生，我们简历上写很多关于找Bug的经历与技能，殊不知测试人员的最终目标是保证产品质量的，而提交有效的缺陷报告就是其中的重要一环。是测试人员向其他团队成员表达自己发现的缺陷描述。需要让其他人一目了然还要能解决当前问题。

以下分享关于缺陷报告编写规范的几点建议（如同开发人员要遵守相应的编码规范，测试工作中也有相应的用例编写规范、缺陷报告书写规范）

缺陷标题

之前在《测试人员基本功之一：报告Bug技巧》中提到过，缺陷标题有一个好的模式是：条件-失败。一般标题中的标点符号不超过1个，不能含有测试流程步骤和模块数据，不能有错别字。

前置条件

前置条件需要明确地指出提交的Bug是在何种情况下发生的。如4G网络正常 ；账户正常登录；

复现步骤

复现步骤需要清晰地分步来描述Bug问题，每步要用数字序号。对于特定数据产生的问题，要提供具体的测试数据。步骤之间要用组合连接符->，步骤描述中的模块不用带引号。同时步骤描述不能过长，语言精炼。步骤中不能含有结果。

如下图为正例：

如下几个为反例：

预期结果

按照复现测试步骤及需求文档的要求准确描述预期结果。同时预期结果必须是无歧义的，可以判定的。描述结果时不要含有步骤。

实际结果

实际结果要精确描述按当前步骤产生的结果，不能有歧义 ，不要有模糊不确定的描述，如：有误、不正常、不准确等。直接描述结果值。

另外，预期结果要与实际结果相对应。

测试设备及环境

提交缺陷报告时要表明测试操作中使用的移动设备及型号、操作系统版本、测试环境、网络类型、浏览器等等

附件

一般，常见的缺陷类型可大致分为三类，界面问题、功能问题、崩溃类问题。 界面问题要上传问题截图，用红框标注出；功能问题需要上传操作视频（录制视频时，把当前的问题重现出即可，不要有不相关的操作）；崩溃问题需要上传视频及崩溃日志。同时附件的命名要与缺陷标题一致，不要随意编写，如11111、aaaaaaa 等，或是其他字符冗长的名称。

重现概率

发现问题后，要测试多次来判断是否必现，必现则填写重现频率为100%，非必现时，在执行多次后手动统计概率填写。切不可随意填写未经验证的概率 。

一、项目测试的基本流程（步骤）：

　　1、熟悉需求。

　　2、编写、阅读《测试计划》

　　　　说明：编写《测试计划》一般由测试组长或经理完成

　　　　测试人员要阅读并且执行《测试计划》

　　3、设计测试（编写《测试用例》）

　　4、执行测试（执行测试用例），并且要记录执行结果

　　5、记录缺陷结果（缺陷报告），跟踪、管理缺陷

　　6、测试总结（总结报告）

二、缺陷报告

　　1、什么是缺陷报告

　　　　测试人员发现缺陷，通过缺陷报告记录缺陷将缺陷报告提交给开发方，并跟踪和管理缺陷。缺陷报告是测试人员和开发人员之间重要的沟通工具。

　　2、缺陷报告如何编写

　　　　说明：在企业中为了提高缺陷的管理效率和质量通常会使用管理工具，例如：qc，禅道，bugzilla等，不同企业使用工具不同，缺陷管理可能会有差异，但是大同小异。

　　　　1）缺陷报告的主要组成：

　　　　　　（1）缺陷编号（defect id）

   　　　　　　　　记录发现缺陷的顺序号，可以通过编号唯一标识每条缺陷。

  　　　　　　　　 缺陷的编号是以项目为单位进行的。

  　　　　　　　　 在测试管理中，缺陷编号通常是自动生成的。

　　　　　　（2）缺陷标题（summary）

　　　　　　　　简明扼要的描述该缺陷。（概括）

　　　　　　（3）缺陷发现者（detected by）

　　　　　　　　就是发现缺陷的测试人员自己。

　　　　　　　　通常在测试管理工具中会默认当前系统的登录用户

　　　　　　（4）指派给谁（assigned to）

　　　　　　　　首先测试人员将缺陷报告指派给开发方的负责人（开发经理）

　　　　　　　　然后再由开发经理将缺陷报告指派给相应的开发人员负责解决缺陷。

　　　　　　（5）提交缺陷的日期（detected on date）

　　　　　　　　发现缺陷，确认之后，要及时的将缺陷提交给开发方。

　　　　　　　　在测试管理工具中通常会自动将系统时间默认填入该项。

　　　　　　（6）发现缺陷的功能模块（subject）

 　　　　　　　　方便开发经理确认该缺陷由哪个开发人员负责

　　　　　　　　可以协助开发人员定位缺陷

　　　　　　（7）缺陷所属的版本（detected in release/version）

　　　　　　　　说明：这里所指的版本不仅是最终发布的版本，也包括在软件开发过程中形成的临时版本。

　　　　　　　　　　　　版本的制定不是由测试人员完成的。（通常公司里是产品部门完成）

　　　　　　　　回归测试：在新版本中对上一个版本中测过的功能重新再测试一遍。

　　　　　　　　为什么要做回归测试：

　　　　　　　　　　1）修改的缺陷有可能会对原有功能带来新的问题

　　　　　　　　　　2）新增加的功能有可能会给原有功能带来新的缺陷

　　　　　　　　　　在企业中，往往会使用自动化工具来完成回归测试，提高测试效率。

　　　　　　（8）缺陷的状态（status）

　　　　　　　　描述缺陷当前的情况。

　　　　　　　　缺陷的处理过程

　　　　　　　　　　步骤1：测试人员填写缺陷报告，提交给开发经理，此时状态为：new（新的缺陷）

　　　　　　　　　　步骤2：开发经理要验证缺陷,

　　　　　　　　　　　　情况1：缺陷验证通过，开发经理会激活缺陷，并将缺陷指派给相应的开发人员。此时状态为：open（打开/激活的缺陷，被开发方承认的缺陷）

　　　　　　　　　　　　情况2：缺陷验证没有通过，开发方会拒绝该缺陷。此时缺陷状态为：rejected（被拒绝的缺陷）

　　　　　　　　　　　　　　扩展：被拒绝后测试人员首先要确认是否是由于操作或配置错误造成的假缺陷，然后如果是由于对于需求理解不同造成的可以跟产品部门沟通确认，最后如果是开发方不能重现该缺陷，要尽量沟通、配合重现。

　　　　　　　　　　　　　　　　如果还不能确定再去跟测试部门领导沟通反馈问题。经过上述过程如果最终确认是假缺陷，那么由测试人员或组长关闭该假缺陷；如果最终确认是缺陷，那么谁拒绝的谁负责激活，继续完成缺陷处理流程。

　　　　　　　　　　步骤3：开发人员负责解决指派给他的缺陷。解决后将缺陷状态设置为：fixed（解决的缺陷，待返测的缺陷）

　　　　　　　　　　步骤4：测试人员返测解决的缺陷，

　　　　　　　　　　　　情况1：如果返测通过，测试人员将缺陷关闭。此时状态为：closed（关闭的缺陷，可归档的缺陷）

　　　　　　　　　　　　情况2：如果返测没有通过，测试人员要将缺陷重新激活，此时设置缺陷状态为：reopen（重新激活的缺陷），开发人员继续修改缺陷，修改后再次将缺陷状态设置为：fixed，测试人员再次返测，直到缺陷解决被关闭为止。

　　　　　　　　问题：缺陷的处理流程

 　　　　　　　　　　用状态来表示

　　　　　　　　　　　　1、缺陷的基本处理过程

　　　　　　　　　　　　　　New-->open-->fixed-->closed

　　　　　　　　　　　　2、带有返测失败（1次）的缺陷处理过程

　　　　　　　　　　　　　　New-->open-->fixed-->reopen-->fixed-->closed

　　　　　　　　　　　　3、被拒绝的缺陷的处理过程

　　　　　　　　　　　　　　1)假缺陷   

　　　　　　　　　　　　　　　　New-->rejected-->closed

　　　　　　　　　　　　　　2)是缺陷

     　　　　　　　　　　　　 　　New-->rejected-->open-->fixed-->closed

　　　　　　(9)缺陷的严重程度（severity）

  　　　　　　　　指明缺陷有多糟糕或对程序的影响有多大

   　　　　　　缺陷的严重级别的分级定义（以qc为例）：

　　　　　　　　Urgent：致命的缺陷，例如造成计算机死机，系统崩溃等

　　　　　　　　Very high：非常严重的缺陷

　　　　　　　　High：严重的缺陷

　　　　　　　　Medium：一般的（中等的）缺陷

　　　　　　　　Low：提示、建议类的缺陷（小问题）

　　　　　　发现问题：缺陷的严重级别的定义是笼统的，在实践中容易造成冲突，所以企业针对每个严重级别制定了详细的说明。工作中要注意参考。（不同公司或者不同项目使用的缺陷严重级别定义文档都会不同）

　　　　（10）缺陷的优先级（priority）

   　　　　　　希望或建议开发方在什么时候或什么版本解决该缺陷

  　　　　　　 优先级的级别定义：

   　　　　　　　　Urgent：需要开发人员放下手头的开发任务立即解决的缺陷（通常是不解决会影响整个开发和测试进度的）

   　　　　　　　　Very high：在当前版本内解决

   　　　　　　　　High：在下一个版本中解决（常用）

  　　　　　　　　 Medium：在软件发布之前解决

 　　　　　　　　 Low：尽量在软件发布之前解决（有可能在软件发布时带有没有解决的bug）

 　　　　　　说明：不同企业，不同项目组对于软件优先级的定义会不同，工作中要注意参考。

　　　　　　关于缺陷的严重程度和优先级问题：

　　　　　　　　1）影响缺陷优先级定义的因素有哪些？

　　　　　　　　　　（1）缺陷的严重程度—一般越严重缺陷的优先级越高（有时也会有严重程度低而优先级高的情况）

　　　　　　　　　　（2）缺陷影响的范围—影响范围越大，优先级越高

　　　　　　　　　　（3）开发人员的开发压力—开发压力越小，解决缺陷的优先级越高

　　　　　　　　　　（4）解决缺陷的成本（时间）--成本越低，解决缺陷的优先级越高

　　　　　　　　2）缺陷的严重程度和优先级是严格的正比关系吗？

　　　　　　　　　　不是严格的成正比关系，例如：界面的错误别字，严重程度低，但是优先级高

　　　　　　　　3）缺陷的严重程度和优先级确定之后可以修改吗？

　　　　　　　　　　 缺陷的严重程度确定好后一般不改

　　　　　　　　　　 缺陷的优先级可以修改，而且常常是拖延处理（delay）

　　　　　　　　4）是否有未解决的缺陷在软件发布版本中存在?

       　　　　　　　　有可能会有发现的但没有解决的缺陷在发布的软件版本中存在。

　　　　　　　　　　这类缺陷需要开bug讨论会，讨论投入和风险，权衡利弊后，才能决定。

　　　　　　　　　　企业可以通过打补丁或者升级版本的方式在后续将此类缺陷解决。

　　　　(11)缺陷描述（description）

　　　　　　说明：将发现缺陷的过程、数据记录下来，让开发人员能够再现该缺陷（就是让开发人员能知道并再现这个缺陷）

　　　　　　扩展：在缺陷报告中要求附带证迹（截图、视频）

软件缺陷定义

  软件缺陷(Defect)：又叫做Bug。即为计算机软件、程序、web应用中存在的某种不符合正常运行的功能问题。也是错误、隐藏，让用户不满意的功能缺陷。

  从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题;

  从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

 缺陷报告定义

  缺陷报告把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件存在的质量问题提供依据，同时为软件验收和交付打下基础。

  协同公司在项目中采用的缺陷处理过程如下

  在软件测试过程中，缺陷报告起到了一个交接单的作用，它帮助开发人员和测试人员之间更有效的交流，提高了缺陷的解决速度和质量。同时也可以通过统计bug数来对被测的软件进行质量评估，比如根据以往项目中每千行bug数的平均值来制定测试计划，同类的产品，尤其是同一个开发流程的产品，这些数值不应该相差太多，如果相差一个数量级以上，我们几乎可以说，要么是QA出问题了，要么是开发出问题了。另外，降级bug的多少对于软件质量评估也是一个重要参考标准，降级bug也就是由于修正一个bug，又产生了一个新bug，降级bug数目过多意味着现在的产品在越修越坏。

  缺陷报告是测试过程中可以提交的最重要的东西。编写缺陷报告的目的是为了方便程序员找到程序出现的问题，从而有利于分析错误产生的原因，定位错误，修改问题。它的重要性丝毫不亚于测试计划，并且比其他的在测试过程中的产出文档对产品的质量的影响更大。因此，缺陷报告编写的基本要求是简洁、准确、完整、规范。有效的缺陷报告将能够：减少开发部门的二次缺陷率、提高开发修改缺陷的速度、提高测试部门的信用度、增强测试和开发部门的协作。那么在提交缺陷报告时，我们需要提交的就是一份简单明了、便于理解和查找问题的缺陷报告。

各个测试阶段中的测试点

 单元测试： 针对每个单元的测试，以确保每个模块能正常工作为目标。

 集成测试： 对已测试过的模块进行组装，进行集成测试。目的在于检验与软件设计相关的程序结构问题。

 系统测试： 检验软件产品能否与系统的其他部分(比如，硬件、数据库及操作人员)协调工作。

 验收测试： 检验软件产品质量的最后一道工序。主要突出用户的作用，同时软件开发人员也应有一定程度的参与，验收测试可以分成Alpha测试和Beta测试。

 Alpha测试： 由用户在开发环境下完成的测试

 Beta测试： 由用户在用户环境下完成的测试。

1、在提交一条缺陷前，需检查缺陷库中是否已经存在此缺陷。力求避免重复提交。

2、对于一些难以理解的、自己还有些模糊的和对缺陷的正确性难以肯定的问题，在记录你的缺陷以前，就需要和有经验的测试人员或开发人员进行讨论。

1、标题

应保持简短、准确，提供缺陷的本质信息，尽量按缺陷发生的原因与结果的方式书写;避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状;为了便于他人理解，避免使用俚语或过分具体的测试细节。

2、复现步骤

应包含如何使别人能够很容易的复现该缺陷的完整步骤。

为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。

常见问题：

·包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解;

·包含的信息过少，丢失了操作的必要步骤。

复现步骤的正确书写方式：

·提供测试的环境信息;

·简单地一步步引导复现该缺陷，一个步骤包含的操作不要多;

·每个步骤前使用数字对步骤编号;

·尽量使用短语或短句，避免复杂句型句式;

·复现的步骤要完整、准确、简短;将常见步骤合并为较少步骤;按实际需要决定是否包含步骤执行后的结果。

3、实际结果

实际结果是执行复现步骤后软件的现象和产生的行为。实际结果的描述应像标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。

4、期望结果

描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。

附件：

对缺陷描述的补充说明，可以是以下一些类型：

缺陷症状的截图;测试使用的数据文件;166 199 188。

5、其它：

选择合适的缺陷严重性属性;按相应的规定，填写相应的字段信息。

标题：应保持简短、准确，提供缺陷的本质信息

尽量按缺陷发生的原因与结果的方式书写；

避免使用模糊不bai清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状；

为了便于他人理解，避免使用俚语或过分具体的测试细节。

复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤。

　　为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。常见问题：

包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解；

包含的信息过少，丢失了操作的必要步骤；

复现步骤的正确书写方式：

提供测试的环境信息；

简单地一步步引导复现该缺陷，一个步骤包含的操作不要多；

每个步骤前使用数字对步骤编号；

尽量使用短语或短句，避免复杂句型句式；

复现的步骤要完整、准确、简短；

将常见步骤合并为较少步骤；

按实际需要决定是否包含步骤执行后的结果。

实际结果：是执行复现步骤后软件的现象和产生的行为。

实际结果的描述应像标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。

期望结果：描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。

附件：对缺陷描述的补充说明，可以是以下一些类型：

缺陷症状的截图；

测试使用的数据文件；

其它：

选择合适的缺陷严重性属性；

按相应的规定，填写相应的字段信息

单元测试： 针对每个单元的测试，以确保每个模块能正常工作为目标。
集成测试： 对已测试过的模块进行组装，进行集成测试。目的在于检验与软件设计相关的程序结构问题。
系统测试： 检验软件产品能否与系统的其他部分（比如，硬件、数据库及操作人员）协调工作。
验收测试： 检验软件产品质量的最后一道工序。主要突出用户的作用，同时软件开发人员也应有一定程度的参与，验收测试可以分成Alpha测试和Beta测试。
Alpha测试： 由用户在开发环境下完成的测试
Beta测试： 由用户在用户环境下完成的测试。