TrackRecord使用规范.doc

安徽中科大讯飞信息科技有限公司Anhui USTC iFlyTek CO., LTD.TrackRecord使用规范版本 TrackRecord使用规范版本: 日期:2008/8/6 17:19:00 版本历史日期版本描叙作者2002-9-91.0初稿陈逊2002-9-171.1补充部分Status的内容QMOffice2003-12-171.2修正了No Longer Issue的描述等错误QMoffice2007-8-231.3对Priority、Summary、Depth等内容进行了修订和添加QMoffice关键字: TrackRecord 规范摘要:本文介绍了TrackRecord系统的使用规范和约定。目录TrackRecord使用规范1版本历史21文档简介52参考文档53术语54工具和规范65缺陷跟踪76缺陷跟踪工作流程86.1缺陷跟踪工作流程86.2角色96.3状态详细解释96.3.1No State116.3.2Unreviewed126.3.3Open136.3.4Assigned146.3.5Pending Validation156.3.6Pending Documentation166.3.7Closed177TrackRecord中数据域填写规范187.1Project187.2Team Member197.3Defect207.3.1Identifier207.3.2Priority217.3.3Entered by227.3.4Date Entered237.3.5Summary237.3.6Project247.3.7Assigned to247.3.8Fix by Milestone257.3.9Description257.3.10Status277.3.11Severity277.3.12Depth287.3.13Configuration297.3.14Operating System307.3.15Build/Release Found307.3.16Resolution307.3.17Root Cause317.3.18Build/Release Fixed327.3.19Resolution Details327.3.20Functional Areas347.3.21Keywords347.3.22Attachments347.3.23Reported by357.3.24Source Files357.3.25Duplicate Defects357.3.26Notes367.3.27Related Requirements368角色及其任务388.1PM388.2TM408.3QC418.4DM428.5DEV438.6Documentation448.7Release Engineering459如何提高缺陷跟踪工作效率469.1Project Manager 应当起到协调469.2只有缺陷数据库是不够的469.3TrackRecord不是BBS469.4缺陷应当流动才会高效469.5严格控制关闭479.6时刻关注所有缺陷，而不只是Assigned to me4710典型案例分析4810.1案例14810.1.1概述4810.1.2项目背景4810.1.3关键控制点4810.1.4解决方法4810.1.5总结4810.2案例24910.2.1概述4910.2.2项目背景4910.2.3关键控制点4910.2.4解决方法4910.2.5总结50TrackRecord使用规范 1 文档简介本文的目标:u 本文详细描述了在项目开发过程中如何正确使用TrackRecord,描述了一些TrackRecord的使用规范与约定.最终的目标是规范缺陷跟踪工作,提高开发和测试的效率.谁阅读本文:u TrackRecord的每一位使用者u 本文假设读者已经熟悉TrackRecord的概念以及使用方法本文的内容包括:u TrackRecord中缺陷的处理流程u TrackRecord中缺陷各数据域的含义及填写规范u TrackRecord中项目组各角色的职责和操作规范u 分析使用TrackRecord时遇到的典型问题本文不包括的内容:u Track Record中缺陷跟踪的各种概念，使用方法，关于这部分内容请参考Track Record使用手册本文的组织方式:Track Record的用户在使用该系统过程中，如果遇到对操作规范不了解的问题，可以按照问题的分类或自己的身份在本文档中查找答案。2 参考文档Track Record部署方案针对管理人员,介绍TrackRecord的部署方法,数据库原理Track Record使用手册TrackRecord的操作和原理3 术语4 工具和规范在开始之前，首先介绍一下工具和规范的关系。一件工作或者说流程，例如缺陷跟踪，如果要做好，更重要的是遵守规范,并且有正确的意识，工具永远是辅助性的。我们虽然可以在TrackReco0rd中加入非常多的数据合法性的检查，但是也不可能检查到缺陷的Description的描述是否符合规范。我们虽然可以设置TrackRecord的邮件提醒功能自动提醒新的缺陷，但是我们不能只依赖邮件提醒，而应该时刻主动去关注缺陷的变化，才能保证缺陷快速被解决。所以，TrackRecord的规范更多的是结合TrackRecord工具，主要介绍缺陷跟踪工作规范。TrackRecord只是辅助我们完成缺陷跟踪任务的一个工具，它本身并不能代替缺陷跟踪工作的规范。某些规范即使使用其他工具也仍然是需要遵守的。5 缺陷跟踪缺陷跟踪是软件测试工作的基石，也是提高软件质量的基石。有效的缺陷跟踪应当保证： 所有发现的缺陷都记录进入缺陷跟踪系统 所有缺陷的状态转变都得到控制 只有真正解决的缺陷才能够被关闭 能够有效的对缺陷进行数据统计为了更好的描述缺陷，更快的解决缺陷，我们应当 尽可能清楚的描述缺陷信息 尽可能详细的记录缺陷的解决过程在本文中将详细的介绍如何使用TrackRecord做好缺陷跟踪工作。6 缺陷跟踪工作流程TrackRecord使用工作流(Workflow)控制缺陷生命周期的流转，所以对于规范使用TrackRecord进行缺陷跟踪，了解TrackRecord的工作流程至关重要。工作流规定了一组缺陷的状态（Status），以及在这些状态之间转变所需要的动作（Action），并且为每一个动作按照组(Group)规定了权限。我们将分别详细的讨论这些角色、状态和动作。6.1 缺陷跟踪工作流程TrackRecord使用基于状态转换的工作流控制缺陷跟踪的流程，缺陷的状态，和各个状态之间的转换规则定义了完整的工作流程。TrackRecord中的缺陷共有7种状态，缺陷根据不同的动作在这些状态之中流转，图表 1是TrackRecord中的状态和动作之间的关系示意图。图表 1TrackRecord流程示意图图中圆圈表示一个Defect的状态，带有箭头的连线表示状态之间转换的动作，线上的矩形框中描述了此动作的名称和可以执行的角色，具体角色参见6.2。6.2 角色TrackRecord Group控制缺陷工作流程中的权限，在TrackRecord中存在如下Group：u Project Admin项目经理、程序经理、测试经理u Development开发组u Documentations产品组u QA测试组成员u Support技术支持u Release Engineering构建组u Guest客人其中Project Admin在TrackRecord的Work Flow中拥有最多的权利，实际上上Project Admin不一定是指通常意义上的程序经理，就职责而言应当包括测试经理和开发经理。在后面介绍工作流程中将会涉及到权限和职责问题。在介绍职责时，我们将使用角色而不是Group描述。角色基本上与组是重合的，只是多了QA Admin，属于Project Admin组。DEV Admin,属于Development组我们将Group和角色与他们的缩写列在这里，以防歧义。u Project AdminPM（Project Manager、Program Manager） TM（Test Manager，也称为QM）u DevelopmentDM（Develop Manager开发组长）DEV（开发人员）u DocumentationsDOCu QAQC（Quality Control测试人员）u SupportSPu Release EngineeringREu GuestGST6.3 状态详细解释我们将介绍每一种状态的含义。以下每一个小节为一个状态，将从如下方面描述状态：l 中文名称说明此状态的规范中文名称l 含义说明此状态的含义l 负责角色说明谁处理在此状态下的缺陷，以及该做什么l 可执行的动作说明由什么样的状态执行什么动作可以转到此状态6.3.1 No Statel 中文名称初始状态l 含义为了逻辑的完备性，定义Defect的初始状态，实际上是没有状态。l 负责角色N/Al 可执行的动作动作后继状态权限说明SaveUnreviewedEveryone在输入进行保存时自动执行Save动作EnterUnreviewedEveryone同上SubmitOpenDEVDEV可以使用TrackRecord的一些集成工具，例如Visual Studio IDE Addin直接提交缺陷，变为Open状态。6.3.2 Unreviewedl 中文名称未复审的l 含义缺陷被输入之后，没有被TM或PM确认是否为真正的Defect之前处于Unreviewed状态。有时存在着一些暂时不准备提交的缺陷，例如某些还没有确信是缺陷的问题，有待观察。这是可以将这些缺陷停留在Unreview状态。但是不应当停留长时间，应当尽快转变为Closed或者是Open。处在Unreviewed状态下的缺陷时不需要考虑对其进行修复，也就是说处在Unreviewed状态下的缺陷可以认为不是正式的缺陷。l 负责角色角色职责TM负责处理Unreviewed状态下的缺陷，复审缺陷的描述是否合适，并将标记缺陷通过复审或者不通过PMPM只有在TM无法判断的情况下辅助TM进行复审l 可执行的动作动作后继状态权限说明ReviewOpenTMPM测试经理或项目经理复审缺陷合格后，将缺陷转为OpenCloseClosedTM缺陷不合格，并且没有再次修改的必要，TM可以直接将其关闭6.3.3 Openl 中文名称打开l 含义缺陷是有效的，缺陷没有被解决。处在Open状态下的缺陷是正式有效的缺陷，需要开发组进行修复。如果TrackRecord中停留在Open的缺陷很多，说明积累了很多缺陷没有解决。l 负责角色角色职责PM DM项目组长负责分析状态为Open的缺陷，并将缺陷分配给适当的人员解决DEV开发人员负责解决缺陷，或者使用Need More Info将缺陷送回到QCl 可执行的动作动作后继状态权限说明AssignAssignedPMDMDOC根据缺陷的情况将缺陷指派给某个DEV处理。ResolvePending ValidationPMDEVDOC如果不需要指派，则可以直接在Open状态下使用Resolve解决缺陷。Need More Info UnreviewedDEVDOC如果缺陷描述或者缺陷本身存在问题，执行Need More Info将缺陷返回到Unreviewed6.3.4 Assignedl 中文名称已指派l 含义Assigned表示一个有效的缺陷已经分配给某个开发人员进行解决。虽然缺陷在Open状态下可以直接Resolve，但是实际上使用Assigned可以更好的了解Open的缺陷中有哪些是已经分配解决的，有哪些是未决的，有效的分清缺陷解决的状态。所以我们推荐缺陷先转入Assigned再进行Resolve。如果TrackRecord中积累了很多Assigned状态的缺陷，说明分配解决的缺陷一直没有被修复，或者一次性分配太多。l 负责角色角色职责DEV解决缺陷l 可执行的动作动作后继状态权限说明ResolvePending ValidationPMDEVDOC缺陷已经解决Need More InfoUnreviewedDEVDOC如果缺陷描述或者缺陷本身存在问题，执行Need More Info将缺陷返回到Unreviewed6.3.5 Pending Validationl 中文名称等待验证l 含义任何缺陷经过开发人员解决之后，需要QC人员验证缺陷是否真的被解决了，处在Pending Validation状态下的缺陷表示需要QC人员验证的缺陷。如果再Pending Validation状态下的缺陷数目过多，说明测试人员没有及时验证已经解决的缺陷。l 负责角色角色职责TM QC负责验证缺陷修复情况，并且根据验证情况将缺陷转到对应的状态l 可执行的动作动作后继状态权限说明Impacts DocPending DocumentationQCDOC当DEV和QC之间存在对文档或者缺陷理解的分歧时，执行Impacts Doc，表示需要产品组做出仲裁，并在文档中表示清楚。ValidateClosedQC验证通过，缺陷被关闭RejectOpenQC验证不通过，缺陷修复被驳回，回到Open状态。6.3.6 Pending Documentationl 中文名称等待文档验证l 含义当QC人员与开发人员就某缺陷存在歧义时(例如某缺陷开发人员认为符合需求,QC人员认为不符合),需要产品组对此做出仲裁.在此状态下的缺陷表示需要产品组作出仲裁.如果TrackRecord中积累很多Pending Documentation状态的缺陷，说明产品组一直没有进行仲裁。l 负责角色角色职责DOC根据缺陷的描述和开发人员的解决,以及考虑客户对需求的处理方法做出仲裁.l 可执行的动作动作后继状态权限说明ValidateClosedQCQC可以直接使需要仲裁的缺陷通过验证,缺陷将被关闭DocumentPending ValidationDOC产品组对缺陷做出了仲裁,缺陷变成Pending Validation,等待验证6.3.7 Closedl 中文名称已关闭l 含义缺陷已经得到解决对项目来说，这是缺陷最好的状态。l 负责角色角色职责QC如果在回归测试过程中发现缺陷,应当将Close的缺陷重新OpenEvery One如果发现已经解决的缺陷需要重新考虑,可以将Close的缺陷重新Openl 可执行的动作动作后继状态权限说明Re-OpenUnreviewedEvery One任何人都可以将缺陷重新打开7 TrackRecord中数据域填写规范在TrackRecord的使用过程中，对于各种数据类型的各个数据域的填写是非常重要的规范，在本章中将详细介绍TrackRecord中缺陷,以及其他几种重要类型的各个数据域的填写规范和一些约定。7.1 Project域名称中文规范名称说明Name项目名称项目的名称。Description项目描述项目描述。VCS Project Name与SCM集成时使用的项目名称，目前不使用。Current Version当前版本当前版本。Current Build Number当前Build号当前Build号。这里版本和Build号并没有什么意义，应当使用Builds/Releases。Builds/Releases项目Build列表这里列举了项目所有的Build/Release。Milestones里程碑列表这里列举了项目所有的里程碑。Team Members项目组成员列表列举所有项目组成员。注意：缺陷分配时只能分配给缺陷所属的项目组成员。Documents项目相关文档项目相关文档列表，可以加入多个Document类型对象。Functional Areas功能模块列表项目所有的功能模块列表。功能模块应当根据项目的功能类别分类进行划分。注意：模块并不是指代码的模块，而是功能的分类。它的用途是可以按照功能模块将缺陷分类。Requirements需求列表项目所有需求列表，应当使用Reconcile与TrackRecord数据库中项目需求同步。Keywords关键字用于检索的关键字，这在进行缺陷分析时很有用。Sub-projects子项目可以包含其他Project类型数据作为子项目。7.2 Team Member域名称中文规范名称说明LastFirstMiddle名称组员名称，命名的规则应当是：Last填写中文名称；First填写组缩写，例如PM,DEV,QC等；Middle空。Company公司填写人员所属公司，基准数据库中已经输入了讯飞公司的条目。Address地址Phone Numbers电话可写多项。Email Address邮件地址Notes备注Department部门增加一个记录缺陷发生频率的域。7.3 DefectDefect(缺陷)是TrackRecord中最重要的数据类型,所以本章将使用大章节详细介绍缺陷的数据域填写规范.在介绍缺陷的数据域填写规范之前，我们将首先虚拟一个软件产品和一个缺陷，在下面的章节中，我们将使用这个缺陷作为范例来说明TrackRecord中各域的填写规范。缺陷的数据域众多，但是并不是每个角色都需要关注所有的数据域，在角色及其任务中会由每一个角色应当特别关注的数据域，可以从那里链接到本章节。 虚拟缺陷这是一个文字处理软件，类似与Microsoft Word。在测试中发现一个缺陷如下：在文本处理软件中输入一些文字，之后改变其字体为Arial，文本变成了乱码，并且这个问题只在Windows98出现。从下面开始我们将约定TrackRecord中缺陷各数据域针对此缺陷的书写方法。 描述方法每一个数据域的规范，我们将使用统一的方法描述，在每一个数据域小节中将包含如下信息：l 中文名称说明域的中文名称l 说明描述域的含义l 谁、何时填写描述由谁在什么时候填写l 填写规范描述填写的规范7.3.1 Identifierl 中文名称缺陷标识,或者缺陷IDl 说明Identifier是系统自动生成的整数，唯一标识一个缺陷l 谁、何时填写系统在创建缺陷时自动生成，并且之后一直不能修改l 填写规范N/A7.3.2 Priorityl 中文名称优先级l 说明优先级不同于严重性(Severity)。优先级指缺陷急待解决的紧迫程度，也就是考虑修复的优先次序、即先后关系，并不代表严重性。一个很严重的缺陷优先级不一定很高（例如出现几率很小，或者并不是常用功能）；同样，一个并不是很严重的缺陷可能具有很高的优先级（例如主界面显眼处的错字）。优先级和当前项目状况及目标是相关的，一个可判断为“3-Normal”的Bug，在面临发布时也可以判断为“2-High”或“1-Critical”；面向普通用户的桌面产品可能对易用性比较关注，那么易用性方面的bug的优先级就比较高。l 谁、何时填写角色何时填写QC在创建缺陷时填写PM TM在复审时进行修改l 填写规范优先级可选项包括： 1-Critical致命错误，例如主程序不能正常运行；基本业务功能未实现，从而使得后续流程无法正常进行： 操作系统崩溃、死机 频繁造成数据库死锁或数据丢失 用户无法注册或登陆，从而无法进行后续操作 在时效性要求很高的系统上（例如评测引擎）反应时间过长 2-High严重错误，严重影响系统正常运行或基本功能的实现，且没有办法更正（重新安装或重新启动不属于更正办法）；使系统不稳定，产生错误结果；影响重大的错误： 首页出现明显错字 重要需求或功能没有实现，但是不影响其他模块 程序非法退出，无法继续操作（正在运行过程中忽然关闭） 无故引起其他软件、系统出错（如删除数据时没有考虑对其它模块造成的影响） 重要流程或场景下，数据出错、操作无效或操作结果错误 3-Normal一般性错误： 界面提示错误或界面不友好 一般性需求没有实现 非重要功能或流程不正确，无法正确执行 对数据库的操作不能正确实现 正确性不受影响，但系统性能或响应时间受到影响 4-Low轻微错误，这类问题给用户的操作带来不便或麻烦，但不影响功能的实现，或者对最终结果影响有限，以及出现的可能性较小： 系统处理需要优化，从而提高运行效率 没有进行输入校验，或控制错误 界面风格不一致，显示格式不规范 重要操作没有给出提示信息或提示信息不明确 可编辑区与不可编辑区、必填项与非必填项没有明显区别 单元格宽度无法调整，从而无法看到所有内容 5-Suggestion建议性错误： 流程优化的建议 键盘支持不好（如在可输入多行的字段中，不支持回车换行） 光标跳转设置不友好或定位错误 界面不能及时刷新，影响视觉效果 滚动条无效或随意跳转7.3.3 Entered byl 中文名称输入者l 说明记录缺陷是由谁提交的l 谁、何时填写系统在创建缺陷时自动填写，并且不能修改l 填写规范N/A7.3.4 Date Enteredl 中文名称输入时间l 说明记录缺陷是在什么时候输入的l 谁、何时填写系统在创建缺陷时自动填写，并且不能修改l 填写规范N/A7.3.5 Summaryl 中文名称概述l 说明缺陷的概述简要说明缺陷的大体内容。l 谁、何时填写角色何时填写QC在创建缺陷时填写l 填写规范在缺陷的概述中应该用一句尽量简洁的话将缺陷概括，要求包含关键字，能够将缺陷的主要问题和重点说清楚。注意这句话不能过于简单。例如上面的缺陷如果将概述填写成为“字体显示问题”是不够清楚的。比较好的描述是：_文字处理系统在98下选择Arial字体文字时出现乱码_下面再分别列举一些描述。不清楚的描述：1. 采样率和Bits率接口设置无效2. 信噪比配置项不生效3. 出现对象引用出错4. ResetInstance接口行为异常5. 安装包问题6. 考生调整功能无效较清楚的描述：1. 引擎不能对试卷不合法的错误立即做出反应2. 引擎对无读音文件评测获不应该是满分3. 监考程序登陆界面不能完全显示默认测试任务名4. 监考机登陆时回车键按得过快，导致考试机异常退出5. 考试管理不应该允许重复打开同一个测试任务6. 评分工具在给第四题打分时没有实现时间刻度的细分7.3.6 Projectl 中文名称项目l 说明缺陷所属的项目，也可以是一个大系统中的子系统l 谁、何时填写角色何时填写QC在创建缺陷时填写l 填写规范只能选择在数据库中已经创建的项目。如一个缺陷跨两个以上的子系统，则应该选择最关键的子系统，然后在“Description”中加以说明。7.3.7 Assigned tol 中文名称指派给l 说明指明缺陷指派给谁。此域不同于“Assign”的操作（Action），而是为了方便缺陷在项目组内的流转，这里的变化不会影响缺陷的状态。当Assigned to设定成为某人之后，唯一的影响是被指派人的Defects Assigned to me报表中能够看到这个缺陷。当然其他任何人在All Defects Status Report报表中依然能够看见。所以Assigned to只能作为方便用户使用的域，而不能作为工作流流转的关键。l 谁、何时填写角色何时填写QC在创建时将其填写为负责复审的人员PM TM在Review或者Reject后填写为负责该缺陷的开发人员DEV在解决缺陷之后将其填写为该缺陷的提交者（一般是某个QC）l 填写规范Assigned to只能选择Project中指定的项目所属的项目组员。所以必须首先填写Project才能填写Assigned to。Assigned to在权限流转过程中会多次改变。我们并不以来Assigned to控制流程流转，而是依赖于Project/QA Admin对所有的缺陷进行全局的控制。7.3.8 Fix by Milestonel 中文名称计划修复里程碑l 说明表明缺陷计划在哪个里程碑修复。l 谁、何时填写角色何时填写PM在复审或者解决缺陷时如果需要将缺陷延期，填写此项。l 填写规范可以选择一个属于缺陷项目的里程碑。如果使用TrackRecord中的里程碑，而缺陷将会被延期修复时，在这个域中填写计划修复的里程碑。一般情况下，这一域会在Resolution为Deferred时使用。7.3.9 Descriptionl 中文名称描述l 说明描述是缺陷中最重要的一个数据域。此数据域详细的描述缺陷的表现，重现步骤，以及可能原因的分析。l 谁、何时填写角色何时填写TM在创建缺陷时填写，缺陷通过复审之后，不得修改。l 填写规范缺陷描述应当使用较多的文本进行描述，一般包含如下几个部分： 重现步骤描述重现步骤必须以“重现步骤:”为标题，然后另起一行以数字标题“1. 2. ”的格式将此缺陷的重现步骤说明清楚。每一步骤单独一行。最后还应当描述缺陷重现的概率，例如：重复三次，三次都出现一个较好的重现步骤应当是使用尽量少的文字描述清楚一个操作过程。，例如：1. 在主界面选择菜单 文件-新建2. 在编辑窗口中任意输入一些文字3. 在菜单中选择 格式-字体 选择Arial字体4. 文字变成乱码5. 重复了三次，三次出现同样问题 隔离状态隔离是将缺陷产生的环境或者条件控制在一个范围内，以方便开发组花费更少的成本来解决缺陷。描述隔离状态必须以“隔离状态:”为标题，按照“重现步骤”中类似的使用数字标题的格式。如果隔离状态比较简单，并且与步骤相关，可以在步骤之后使用()进行补充说明。例如在上面的缺陷中应当描述如下的隔离状态：1. 缺陷只在Windows 98下发生2. 只有选择Arial字体才发生3. 猜测可能只是格式问题，因为保存文件之后在打开还是乱码，重新选择其他字体之后恢复正常 错误重点如果在重现步骤很复杂，还不能将缺陷错误说明清楚，即可以另起一个标题“错误重点”，把缺陷的多个错误一一列举出来。 建议如果提交缺陷者对这个缺陷的解决方法有较好的建议，可以以“建议”为标题，说明自己的观点，以供开发组参考。在文本无法清楚说明问题的时候，可以在Attachments中添加附件，并说明附件的含义。就以上规则，下面是一个优秀的缺陷报告记录：_重现步骤:1. 在主界面选择菜单 文件-新建2. 在编辑窗口中任意输入一些文字3. 在菜单中选择 格式-字体 选择Arial字体4. 文字变成乱码5. 重复了三次，三次出现同样问题隔离状态:1. 缺陷只在Windows 98下发生2. 只有选择Arial字体才发生3. 猜测可能只是格式问题，因为保存文件之后再打开还是乱码，重新选择其他字体之后恢复正常错误重点:1. 对Arial字体处理存在问题_有时若通过重现步骤还不能很好地将结果描述清楚，那么可以考虑加入“期望结果”与“实际结果”，通过两者的对比，从而更容易看出问题所在，例如下面的例子：Summary：考生管理里导出选中考生的功能会导出所有考生Description：重现步骤：1.在考务里新建一个测试任务，并导入考生数据2.进入考生管理页面，选中某些考生（将相应考生左边的框勾中）3.点击“导出考生”，检查导出的Excel文档期待结果：只导出选中考生的信息实际结果：导出了所有考生的信息而一份含糊而不完整的缺陷报告（缺少重现步骤，并且没有期望结果、实际结果和必要的图片）和散漫的缺陷报告（无关的重建步骤，以及对开发人员理解这个错误毫无帮助的结果信息）都是不可取的。写软件缺陷报告的关键是遵循软件缺陷的有效描述规则及分离和再现软件缺陷的步骤，仔细做笔记，这样才能写出简明、清晰的缺陷报告。测试人员还需注意，应该在完成测试之后就写缺陷报告，写完报告后，花一点额外的时间仔细检查一遍。7.3.10 Statusl 中文名称状态l 说明表明缺陷当前的状态l 谁、何时填写不可编辑，由系统通过工作流定义，在执行动作(Action)时自动转换l 填写规范N/A7.3.11 Severityl 中文名称严重性l 说明严重性是指缺陷对于程序或者用户造成的影响，与优先级不同。l 谁、何时填写角色何时填写QC在创建缺陷时填写PM TM在复审时进行修改l 填写规范严重性的选择范围包括： Cosmetic Issue修饰性错误，例如界面的美观、字体等 Data Loss/Corruption数据丢失或者错误 Incorrect Functionality设计功能实现错误 Memory Loss内存和资源泄漏等 Missing Functionality设计功能没有实现 Other其它注意：如果Other的缺陷过多，则说明要么分类不全，需要完善；要么没有仔细分析原因，需要讨论后重新确定分类。 Performance性能问题，例如等待时间过长等 System Crash系统崩溃 Unexpected Behavior异常行为，例如出现异常的警告或者错误 Usability易用性问题，例如界面安排不方便用户使用7.3.12 Depthl 中文名称深度l 说明缺陷发现的难易程度。l 谁、何时填写角色何时填写QC在创建缺陷时填写PM TM在复审时进行修改l 填写规范深度的选择范围包括： 非常容易发现常用的地方（包括首页、主界面等）出现的显而易见的问题，例如： 首页字体、颜色、布局等明显不妥 首页链接有问题 主界面有明显错别字 主界面登陆或注册失败 安装、卸载出错 比较容易发现按照测试用例跑正常流程时出现的问题，一般仅需很少的几步操作就可以发现，例如： 测试用例或功能规格说明书里明确提到的功能没有实现 初始化、实例化等常用接口在正常调用时出错 开始、暂停，前进、后退等常用按钮的功能没有实现 删除重要数据或退出系统时没有给出提示信息 正常发现主流程之外的正常操作或者稍加思考就可以想到的异常操作所发现的问题，例如： 登陆时对非法数据的校验有误 执行操作后相应的结果或数据没有生成 边界值、临界点出现的问题 磁盘空间不足时或者数据库连接失败时，没有给出提示或者提示不明确 资源文件缺失或者配置文件有误时，没有给出提示或者提示不明确 较难发现在对系统有了比较深刻了解的基础上，通过自己的逻辑分析找出的问题，以及一些较难重现的问题，例如： 分别在不同客户端进行相同操作，在将数据导入服务端时出现数据冲突 保存后数据库信息并没有更新 系统运行时，删除一些数据后出现了一些非预期结果 极难发现非常难以想到的异常情况；另外，在较难发现的基础上，如果重现环境难以搭建，或者说为了准备这样的测试环境，需要做大量前期准备工作，那么也可以称为极难发现，例如： 用户进行一些操作后将相关数据、记录删除，之后再进行同样的操作，在数据一致性上存在问题 在性能测试中，通过仔细分析觉得某处可能存在问题或瓶颈，但是为了验证它，必须做大量准备工作，包括缜密的分析、精确的计算和长时间的压力测试7.3.13 Configurationl 中文名称配置l 说明测试环境的硬件和软件配置。l 谁、何时填写角色何时填写QC在创建缺陷时填写l 填写规范此项内容可以选择预先输入数据库的配置种类，也可以展开之后输入详细信息。7.3.14 Operating Systeml 中文名称操作系统l 说明测试环境所使用的操作系统l 谁、何时填写角色何时填写QV在创建缺陷时填写l 填写规范只能选择数据库中已经创建好的操作系统。如果在多个（但并不是所有）操作系统中存在问题，请选择NONE，在缺陷描述的隔离状态中描述。7.3.15 Build/Release Foundl 中文名称发现缺陷的Buildl 说明QC在测试时发现缺陷所在的Build，这一数据域极为重要，用于版本的控制。l 谁、何时填写角色何时填写QC在创建缺陷时填写l 填写规范只能选择数据库中预先创建的，并且属于缺陷所属项目的Build号。所以必须首先填写Project才能填写Build号。这里应当填写首次发现问题的Build号，并且以后不能修改。如果缺陷经过多次修复验证，再修复再验证，其他发现错误的缺陷应当记录在Resolution Details。7.3.16 Resolutionl 中文名称解决方案l 说明描述缺陷是如何被解决的。解决并不等同于修复，即使在解决方案中选择了不准备修复（No Plan To Fix），这仍然是一种解决方案。l 谁、何时填写角色何时填写DEV解决问题之后填写l 填写规范解决方案是多选项，可以选择的内容和含义如下： Deferred(这个状态的决定需要得到项目经理或更高级的人员的认可，尤其当此缺陷存在的版本要交付给用户时)由于某种原因，缺陷在这个Build不会被修复。但是这个缺陷会在此项目的后继里程碑中被修复。如果选择此项，必须同时填写Fix by Milestone域。 Duplicate此缺陷与另外一个缺陷重复。如果选择此项，必须填写Duplicate Defects。 Enhancement Request这个缺陷作为一个功能改进在以后的版本考虑。 Fixed缺陷已经修复。 Functions As Designed测试结果的描述与设计相符，这并不是缺陷。 Indirectly Fixed通过修正其他问题，此缺陷得到了间接的修复，应当在Resolution Detail中填写具体问题。 Need More Info缺陷的描述不清晰，需要更加详细的描述。如果选择此项，应当执行Need More Information动作。 No Longer Issue由于环境、部署等原因，此缺陷在之后的版本中不再出现，所以缺陷可以关闭。 No Plan To Fix从优先级、严重性或客户的角度考虑，没有必要修复此缺陷。 Not Reproducible缺陷无法重现。 Other如果其他解决方案都不恰当，应当在Resolution Detail中填写具体情况。注意：如果Other的缺陷过多，则说明要么分类不全，需要完善；要么没有仔细分析原因，需要讨论后重新确定分类。 Software Limitation因为软件、硬件、环境的限制无法修复此缺陷。 User Misunderstanding用户或者测试人员错误的理解了功能，实际上这不是一个缺陷。7.3.17 Root Causel 中文名称缺陷原因l 说明描述产生缺陷的根本原因，这个数据域有利于在项目结束之后分析造成缺陷的主要原因，从而在今后的工作中改进。l 谁、何时填写角色何时填写DEV解决问题之后填写l 填写规范缺陷原因中预定义了一些数据，项目组长可以根据需要，添加额外的原因。7.3.18 Build/Release Fixedl 中文名称缺陷修复Build号l 说明当缺陷的解决方案为Fixed时，在验证过后确认问题解决之后记录问题是在哪一个Build中解决的。l 谁、何时填写角色何时填写QC在验证缺陷确实被解决之后l 填写规范只能选择数据库中预先创建的，并且属于缺陷所属项目的Build号。7.3.19 Resolution Detailsl 中文名称详细解决方案l 说明这是一个很大的文本域，具体详细的描述缺陷的解决过程，解决方法。l 谁、何时填写角色何时填写DEV解决缺陷之后在详细解决方案中追加内容QC验证之后如果发生错误，在详细解决方案中追加内容l 填写规范 追加格式因为此数据域是多次多人在不同时间填写完成的，为使缺陷有完整的历