QC缺陷管理使用手册(修正版)
Quality_Center使用指南
BUG严重程度划分：
4—建议 此优先级别的Bug，如果不进行修改，不影响主要功能，属于页面 美观和易用性的问题，页面上的文字错误或者需要改进的建议，包括以 下各种错误： 界面不规范 辅助说明描述不清楚 输入输出不规范 长操作未给用户提示 提示窗口文字未采用行业术语 可输入区域和只读区域没有明显的区分标志 处理原则：原则上处理周期控制在BUG发布后的三天内；
流程描述
• 其他阶段发现的BUG，由发现人将BUG录入QC。 • BUG提交后状态默认为“新建”，由技术经理判 断是否是BUG，如果不是则将BUG状态改为“已否 决”，如果是BUG则将状态修改为“打开”，并 指定解决人、优先级等； • BUG修复后，解决人将BUG状态改为“已修复”； • 由提交人验证、确定该BUG已解决时修改BUG状态 为“关闭”，若未解决则改为“重新打开”。
BUG严重程度划分：
2—严重 此优先级别的Bug，如果不进行修改，会影响到其他主要功能的使用；次要 功能未实现，优先级别较高，包括以下各种错误： 程序错误 程序接口错误 数据库的表、业务规则、缺省值未加完整性等约束条件 处理原则：原则上处理周期控制在BUG发布后的一天内；
3—一般 此优先级别的Bug，如果不进行修改，说明系统定义的次要功能没有实现有 错误，优先级别一般，包括以下各种错误： 操作界面错误（包括数据窗口内列名定义、含义是否一致） 打印内容、格式错误 简单的输入限制未放在前台进行控制 删除操作未给出提示 数据库表中有过多的空字段 处理原则：原则上处理周期控制在BUG发布后的两天内；
2、解决人处理指派给自己的状态为“打开”或“重新打开”的BUG后， 将状态置于“已修复”，并跟踪该bug回测情况，如果项目经理或者测 试人员回测后，确认该问题已解决，则会将改为状态改为“已关闭”， 如果回测时发现该问题仍然存在，则会重新打开该问题，状态为“重新 打开”,需要继续修改.
QC工具运用说明
QC使用说明●相关名词解释缺陷ID：唯一标识Bug的ID，由系统自动生成检测日期：缺陷被发现的日期，系统存在默认值，当天一级模块：系统一级模块内容，可进行选择二级模块：系统二级模块内容，需要手动输入缺陷描述：缺陷的发生条件，操作步骤，错误现象，期待结果等详细描述信息，此处需要尽可能详细的描述对于一目了然的bug可以用简明的语句描述即可，对于情况比较复杂的bug需要按照bug模板进行提严重程度：缺陷的发生对软件的影响程度5-紧急：死机，系统退出，页面崩溃4-非常高：功能没有实现，流程无法下行3-高：数据处理错误，流程错误，功能实现与预期结果不一致2-中：格式/日期校验，系统可以使用但有待改进的问题1-低：字体，错别字，布局等测试人员：发现缺陷的人员优先级：由开发人员确定修正bug的优先顺序，建议填写：5-紧急：立即修改4-非常高：两天之内修改3-高：五天之内修改2-中：十天之内修改1-低：上线之前缺陷状态:缺陷在生命周期中所处的状态新建：测试人员发现缺陷，向开发人员提交错误时的初始状态已解决：开发人员确认错误后，通过一定手段或改进方法后确认问题已经不再发生，对于已解决的bug，针对修复bug时对其他功能的影响程度，开发人员要给出修正确认意见已否决：开发人员确认不是bug，或想延期修改，或无法修正等问题，该问题处理办法需要开发内部讨论后决定对于已否决的bug，开发人员一定要加上注释，写明处理方法和原因延期修改：开发人员确认后需要修改的问题，但目前由于人员或时间等制约因素无法在短期内修复的不修正：硬件或其他因素导致的问题，非本公司负责范围内的业务，开发人员无法修改非错：不是缺陷，正是客户需求的表现重新打开：开发人员已经修复的Bug，测试人员确认后仍然有问题存在的已关闭：经测试人员确认后已经不存在该问题时 关闭该缺陷测试人员在关闭bug时要注明，在关闭版本上的确认次数，如在XX版本上确认了3回没有发生该现象每次都发生的bug至少确认3次，不是每次都发生的至少确认5次作废：由于需求变更，在新的需求中已经不可能出现的问题☆缺陷状态变化图测试人员：新建，重新打开，已关闭，不修正，非错开发人员：已解决，延期修改，已否决错误类型：提交的bug是属于哪种类型的问题，bug产生的原因，由测试人员先填写，开发人员确认如果填写有误的加以改正编写代码错误：由于系统详细设计或者开发人员疏忽等原因产生的错误并非软件问题：由于ie或者硬件等原因产生的错误界面问题：页面的编写设计时的错误框架问题：框架编写时的问题数据库问题：数据库设计或是调用时的错误修正不彻底：修正一个bug，由于没有考虑完全，没有对问题根本解决需求变更：从客户方得知的需求变更需求理解错误：开发人员对需求理解的错误重复：测试人员重复提交的bug测试版本：新建bug产生的版本，该版本由开发人员依据测试需求提供计划关闭版本：开发人员对于已解决的bug，选择的已解决的版本关闭版本：测试人员最终关闭bug的版本※QC中的版本由开发测试人员共同维护，每个人均有添加版本的权限（手动录入）版本命名规则：八位日期+SVN版本号，如：20111128-1200☆开发测试人员版本控制可能详细的描述进行提交出修正确认意见法需要开发内部讨论后决定在短期内修复的认了3回没有发生该现象员确认如果填写有误的加以改正。
缺陷管理用户手册
缺陷管理1、登录管理信息系统后，点击一级功能栏中的【缺陷管理】按钮2、在功能列表中则显示缺陷管理中的各个子功能，如下图所示：1.新建缺陷单缺陷单为缺陷的流程传递单，贯彻缺陷处理的各个环节，使缺陷的处理得到监控，也为缺陷的传递提供方便。
1.1缺陷单填写及提交用户在“功能列表”中点击“新建缺陷单”：缺陷详细单界面如下：该单中浅蓝颜色为可填写区域，灰色部分为不可写部分。
1、机组、缺陷等级、是否渗漏、设备类型、设备类别，为下拉框元件，单击输入框可显示下拉框如下图所示：2、发现人：为黄色区域的签名元件：1）、签名：用户名处自动填充当前登录的用户名，如果选择其他的用户名，可双击“用户名”输入框弹出人员选择树：选中人员名后点确定，然后输入其登录密码，点击签名按钮。
2）、清除签名：若想清除签名，输入对应的用户密码后点击“清除签名”按钮即可。
3、发现部门，是根据签名后系统自动填充的用户所在的部门4、发现时间，根据签名后系统自动填充的当前服务器的时间。
时间修改，可点击时间输入框，选择相应的日期及时间即可。
5、各项输入完毕后，点击“保存”按钮。
6、发现人可点击“提交”按钮将缺陷提交至值班值长处，由值长进行缺陷定性及下步处理工作。
1.2缺陷流程图点击“流程跟踪”按钮即可查看缺陷单的流程图：缺陷流程，由“缺陷等级”及缺陷“处理方式”来确定其流程经过的审核节点。
流程图接收人查看：将光标放在图标为“”的节点上后，可看到接收人（该节点有权限的处理人）。
将光标放在图标为“”的节点上，可以查看其处理人。
1.2.1 零类缺陷新建缺陷检修鉴定工作分配到专业消缺处理检修部门确认生技部认定总工确认消缺处理缺陷验收消缺完毕。
1.2.2 一类缺陷新建缺陷检修部门鉴定工作分配到专业消缺处理检修部门确认生技部认定消缺处理缺陷验收消缺完毕。
1.2.2 二类缺陷正常消缺流程： 新建缺陷检修部门鉴定工作分配到专业消缺处理运行验收消缺完毕。
无法消缺流程： 新建缺陷检修部门鉴定工作分配到专业消缺处理检修部门确认生技部认定消缺处理缺陷验收 消缺完毕。
QC管理规范
规范QualityCenter (以下简称QC)平台的缺陷状态及相关字段的流程，统一标准，提高效率。
产品缺陷是指在产品测试过程中发现的错误、故障及建议的统称(普通也可以称为bug)。
QC 平台中缺陷字段列表以及相关描述，如表1：*缺陷标识(ID) 缺陷惟一的标识， QC 自动生成*缺陷状态(Status) 详见表 2 缺陷状态定义*概要(Summary) 缺陷内容的概要描述缺陷的详细描述，描述浮现该缺陷的步骤，原因*详细描述(Description)初步分析等等*缺陷发现者(Detected by) 发现该缺陷的人员缺陷严重等级是指因缺陷引起的故障对产品的*缺陷严重等级(Severity)影响程度，详见表 3。
缺陷的优先级指缺陷必须被修复的紧急程度，详*缺陷优先级(Priority)见表 4。
*可重现性(Reproducible) 是否可重现此缺陷，详见表 8。
*实际修复版本实际修复缺陷的版本(Closed in Version)*缺陷发现阶段缺陷发现时所处的阶段，详见表 7*项目(Project) 缺陷所在的项目名称和项目编号*模块(Subject) 缺陷所在的功能模块名称评论(Comments) 研发人员、测试人员等相关人员对缺陷进行的评/有有///有///有有有/有有//有//有有有有有/有有///////有有有/有有有有有有有有有有有有指派给(Assigned to)缺陷发现日期(Detected on Date)版本(Detected in Version)估计修复时间(Estimated Fix Time)最近更改时间(Modified)计划修复时间(Planned Closing Date) 计划修复版本(Planned Closing Version)实际修复时间(Actual Fix Time)修复日期(Closing Date) 缺陷起源(Source)注意事项(Notice)质量因素过程活动(Action)缺陷引入者(Bug Owner) 论或者注释修改此缺陷的人，普通由研发负责人指定。
一,QC说明
QC使用说明一、QC访问地址：http://10.86.7.205:8080/qcbin/start_a.htm二、初次登陆会下载一些插件。
三、登陆账号及更改密码登陆账号根据具体项目组成员分配（姓名拼音的第一个字母），初始密码为空,登陆后请修改初始密码，在右上角工具->自定义->更改用户属性->更改密码四、QC bug流程图，请参照如下：说明：开发人员所有有疑问的bug，均标示成“挂起”，并在注释中阐明自己的疑问。
测试人员根据此注释，将bug置为相应的结束状态。
如果开发和测试的意见存在分歧，测试人员发起组织项目经理和产品经理，开发一起讨论此bug。
根据讨论的结果，测试人员将bug置成相应的结束状态。
主要分为四个角色：QC管理员(TDAdmin）：维护QC正常运行，可以管理项目，项目组成员，BUG的字段维护。
项目经理(Project Manager)：管理和监督项目组缺陷流程与趋势，随时查看各个状态的BUG以及流程状态。
开发工程师(Developer)：修改缺陷，把缺陷置为相应的状态。
描述缺陷修改方案。
测试工程师(QATester)：提交缺陷，验证缺陷的修复结果，把缺陷置为相应的状态。
BUG状态说明✧新建：新提交BUG✧已修复：由开发人员处理完成后的BUG状态✧挂起:开发人员有疑问，不确定是否需要修改或者跟测试人员有争议时，bug暂时挂起。
✧延迟：此bug不在本版本的工作范围，在后续版本或者后续项目中修复✧不可重现：不能在开发环境或版本上重现✧重复：和其它BUG重复✧无效：测试人员对需求的理解不正确（需求问题和环境配置等问题不属于此类）✧重新打开：处于“挂起”的bug，经过大家讨论确认需要修改的BUG；“已修复”状态的BUG，在测试人员的确认测试时不能通过；或是回归测试确认Closed状态的BUG重新出现，则把此BUG重新打开的一种状态✧已关闭：处于已修复状态的BUG，通过了测试人员的确认测试，则此BUG关闭BUG严重程度说明✓建议: 建议性的bug，主要是测试人员认为产品需求不合理或者有好的想法记录，产品经理需关注此字段✓低：很细小的bug，例如文案错误，界面不美观，生僻的逻辑错误等问题记录✓中：一般性的bug，不太重要的功能出问题并且没有影响整个系统运行。
QC测试管理工具使用手册
HP Quality Cen ter 测试管理工具使用手册修订记录目录1 概述 (1)1.1 背景 (1)1.2 目的 (1)1.3 预期读者 (1)2 用户组及权限 (1)2.1 用户组 (1)2.2 组权限 (2)3 使用指南 (2)3.1 “需求” (2)3.1.1 需求编写 (2)3.1.2 常用操作 (3)3.2 “测试计划” (11)3.2.1 案例编写 (11)3.2.2 常用操作 (12)3.3 “测试实验室” (16)3.3.1 测试执行 (16)3.3.2 常用操作 (17)3.4 “缺陷” (19)3.4.1 提交缺陷 (19)3.4.2 常用操作 (20)1概述目前的使用的testli nk 在编写用例时候比较麻烦，不能够迅速的编写用例，只有使用xml '格式才可以导入到testlink 中，或者使用excel格式，但是其中excel也必须加入编码才能够导入进入，客观上增加了软件测试工程师编写用例的难度。
其次testlink 只能对用例进行管理，产生的bug必须再一次通过bug管理系统提交，一定程度上，浪费了时间。
使用的测试管理工具是HP Quality Center 10.0 （以下简称QC，QC是Mercury In teractive 公司推出的基于WEB勺测试管理工具。
QC能够帮助你组织和管理软件测试过程的每个阶段，包括测试需求管理、测试计划、测试案例测试、测试执行和缺陷跟踪。
1.2 目的为了指导QC用户更好的使用QC进行日常工作，特编写本文档。
1.3预期读者本文档预期读者为：QC普通用户。
2用户组及权限2.1用户组QC中的用户包括项目管理员及普通用户，普通用户分为开发人员、测试人员、业务人员和其它人员，各种人员职责如下表所示：注：一个用户可以拥有多个角色，例如，项目开发者做软件编码时属于开发人员范畴，做技术测试时属于测试人员范畴。
2.2 组权限3使用指南3.1 “需求”3.1.1需求编写在“技术测试、系统测试、业务测试“目录下，按照《测试资产库管理》中“需求结构树”建立需求树型结构。
缺陷管理手册
目录1.进入主界面 (2)2.运行人员填写缺陷单，并提交缺陷 (4)3.维护、检修部专工签收处于“提交”状态的缺陷 (16)4.检修责任人处理缺陷 (27)4.1．生成工单 (36)4.2．直接处理 (38)4.3．请求保留 (45)4.4．回退 (49)4.5．缺陷升级 (51)4.6．错票 (55)5.运行人员注销缺陷 (58)6.生技部专工保留确认缺陷 (62)7．缺陷综合查询 (66)8．缺陷汇总 (71)9．设备缺陷汇总 (73)（说明：按住CTRL键并单击鼠标以跟踪链接）1.进入主界面1.双击桌面上的“LIEMS2.0”图标，进入鸭溪信息管理系统。
2.显示系统登陆界面。
3.输入正确的“用户名”和“口令”，按“确定”键。
4.进入操作主界面。
2.运行人员填写缺陷单，并提交缺陷1.运行人员一旦发现缺陷，依次点开、、，后双击。
2.进入缺陷管理界面。
3.填入缺陷基本信息：缺陷代码、缺陷描述、缺陷类型、发现人、发现时间、设备位置、危急程度，详细操作步骤如下；缺陷号在填写好缺陷基本信息并保存后自动生成。
①．填写缺陷代码：ⅰ.双击缺陷代码所在空格处：ⅱ.进入缺陷代码查询界面：ⅲ.选择缺陷对应的缺陷代码，如汽机：ⅳ.缺陷代码选择完成，双击“缺陷”、“自定义1”、“自定义2”所在的任意一个空格进行返回缺陷管理界面：ⅴ.改动后的缺陷管理界面：②．填写缺陷描述：ⅰ.填写缺陷描述，如“阀门开关不到位”：③．填写缺陷类型，通过（下拉）按钮选定：④.填写缺陷发现人：ⅰ.双击发现人所在空格处：ⅱ.进入职员选择界面：ⅲ.选择缺陷发现人，如“运行部集控室—娄方霞”，双击职工号所在空格处进行选定并自动返回缺陷管理界面：ⅳ.改动后的缺陷管理界面：⑤.填写缺陷发现时间： ⅰ.双击发现时间所在空格处：ⅱ.进入日历显示界面：ⅲ.双击光标所在处进行时间的选定，并自动返回缺陷管理界面：⑥.设备位置选择：ⅰ.双击设备位置所在空格处：ⅱ.进入设备位置一览界面：ⅲ.点击设备位置后面的键：ⅳ.显示设备位置选择界面，进行设备位置选择：ⅴ.逐步点击，选择缺陷所在的设备位置，按“确认”键结束：ⅵ.点击工具栏中（查询）按钮，可得到缺陷设备位置所对应得信息：ⅶ.双击设备位置所在的空格处，返回缺陷管理界面：ⅷ.改动后的缺陷管理界面：⑦.填写危急程度，通过 （下拉）按钮选定：3.填写好缺陷基本信息，点击工具栏中（保存）按钮，此时，系统自动生成一个缺陷号，同时缺陷状态为“新建”状态。
QC提交bug使用说明书
QC bug提交使用说明第一步：点击http://192.168.8.24/qcbin/打开QC 界面如下图所示。
注意：第一次打开的时候，需要在本机安装插件。
第二步：点击【Quality Center】链接第三步：输入用户名和密码这里的用户名为自己的中文名字，密码默认为空，可以进去后再修改。
第四步：点击【身份验证】按钮验证通过，进入下一步，验证不通过，请与管理员核实密码第五步：选择域和对应的项目这里域统一选择【芯码测试】，如下图所示这里项目选择当前测试的项目，例如【商贸中心】，如下图所示第六步：点击【登录】按钮登录到QC【芯码测试】域名下的对应项目中来。
第七步：在打开的QC对应项目管理页面中，点击【缺陷】项目第八步：在打开的QC对应项目的缺陷页面中，点击【新建缺陷】新建缺陷页面，如图下所示第九步：填写新缺陷摘要：主要写缺陷的基本重现步骤检测日期和检测者QC会自动默认为当前日期和登陆用户严重程度：我们有一个bug严重程度标准，见附件《bug严重级别文档》分配给：这里如果是客服人员，直接提交到我们测试部或者直接发送给章琳，如果是芯码内部人员，则按照自己手上的项目开发及程序员对应表来提交bug。
检测于版本：选择离目前时间最近的版本，例如：V4.4 2009-6-12pm。
可重现：默认为Y，即可重现。
（有些bug比较隐蔽很难再次重现）。
项目：这里主要更具所在项目的模块来选择，例如：绿色元素四期优先级：这里根据，修改的期限来定，如果比较棘手，就为高优先级。
主题：这里就是该缺陷，所在的模块，例如：产品管理，还是商铺管理模块，如果是客服的人员来提交，可以不选择，如果是芯码内部的成员来提交，比较选择，这样程序员好定位缺陷。
状态：新建一个bug为【新建】状态，如果是回归测试，bug验证以解决，就关闭，没解决，就重新打开，开发人员也可以根据实际情况将bug定位为，否定，挂起等状态。
描述：主要输入bug重现的步骤，即bug环境等因素，书写格式如下：浏览器：ie6URL：前置条件：如：成功登陆LSYS操作步骤:1.2.3.预期结果:实际结果：备注：实例见附件建议：第十步：点击【提交】按钮Bug提交。
QC操作流程规范
目录信息科技缺陷管理细则................................................................................. 错误！未定义书签。
修订记录................................................................................................. 错误！未定义书签。
第一节总则........................................................................................... 错误！未定义书签。
第二节组织与职责 (2)第三节缺陷管理工作流程 (3)第四节缺陷管理活动时间要求 (18)第五节缺陷判定方法 (18)第六节缺陷记录原则........................................................................... 错误！未定义书签。
第七节附则........................................................................................... 错误！未定义书签。
第一节组织与职责第二节缺陷管理工作流程第一条应用软件生命周期内的各类缺陷将按照以下管理流程进行管理。
第二条测试缺陷管理流程（一）功能测试缺陷管理流程图1 功能测试缺陷管理主流程图图2外系统缺陷管理流程图表3 功能测试缺陷管理主流程描述（二）性能测试缺陷管理流程【说明】无论性能测试需求是谁提出的，性能测试缺陷统一分配给项目经理（或项目经理授权人员），缺陷修复后由项目经理（或项目经理授权人员）修改状态并填写注释。
（三）技术测试缺陷管理流程图4技术测试缺陷管理流程图表6技术测试缺陷管理流程描述第三条泄露至运维环节缺陷管理流程图5泄露至运维环节缺陷管理流程图表7泄露至运维环节缺陷管理流程描述第四条评审缺陷管理流程（一）评审缺陷管理流程图图6 评审缺陷管理流程图【说明】：评审环节众多，虚线边框活动的责任角色和开展情况略有不同，详情参见流程描述。
缺陷管理规范
缺陷管理规程文档标识：修订记录目录1简介 (1)2角色与职责 (1)3进入准则 (1)4缺陷分类 (1)5缺陷处理过程 (3)5.1缺陷状态 (3)5.2评审缺陷处理流程 (3)5.2.1流程图 (4)5.2.2活动描述 (4)5.3测试缺陷处理流程 (5)5.3.1流程图 (6)5.3.2活动描述 (7)6缺陷分析 (8)6.1缺陷统计 (8)6.2缺陷分析 (8)7缺陷预防 (8)8退出准则 (9)9裁剪指南 (9)10附件 (9)10.1附件一缺陷填写规范 (9)10.2附件二缺陷等级描述 (10)10.2.1High (10)10.2.2Medium (12)10.2.3Low (14)10.3附件三缺陷标杆的设定 (14)10.4附件四相关文档与模板 (15)1 简介本规程规定了测试和评审的缺陷管理流程，规范缺陷填报和等级划分，保证评审、测试中发现的缺陷被记录、跟踪直到关闭，规范缺陷整个生命周期的管理。
2 角色与职责3 进入准则评审或测试发现缺陷。
4 缺陷分类缺陷引入阶段：指在项目哪个阶段（过程）引入的缺陷。
选项：策划阶段、需求阶段、设计阶段、实现阶段、测试阶段、发布阶段、投入运行阶段填写角色：程序经理、缺陷修改人。
说明：不是项目当前所处阶段，该阶段可理解为过程。
缺陷严重等级：指该缺陷造成影响的严重等级。
填写角色：缺陷记录人缺陷根源：导致缺陷发生的深层次的根源。
选项：（需求不明确、人力资源不足、人员技能不足、重要评审员没有参与、评审投入时间不够、评审没有进行）输入：需求不明确、重要评审员没有参与（？？？）人：人员技能不足、人力资源不足过程、工具、方法：评审投入时间不够、评审没有进行沟通：环境：填写角色：程序经理、缺陷修改人。
说明：产生缺陷的根源所在，比如该缺陷是由设计错误造成的，追溯其根源就可能是：人员技能不足或评审没有进行等根本性原因。
缺陷来源：最早引入缺陷的工作制品――（先不加）选项：需求规格说明书、领域模型、需求跟踪矩阵、概要设计说明书、数据设计文件、详细设计说明书、代码填写角色：程序经理、缺陷修改人缺陷类型：选项：界面、功能、兼容性、性能、数据、接口、其它填写角色：缺陷记录人、程序经理、缺陷修改人员发现手段：选项：评审、代码走查、系统测试、单元测试、系统演示。
QC手册
第一章公司品质管理理念品质是一个公司赖以生存的基础，没有品质，就没有客户，就没有公司的美好明天；1、下工序就是客户客户是公司的衣食父母，是公司求得发展的合作伙伴；在公司内部，为了得到更好的品质保障，应树立“下工序就是客户”的理念，把下工序当作自己的客户对待，以满足客户需求为品质追求目标。
2、三不政策不接受不良品：对上工序零件进行检查，不良品不予接受；不制造不良品：自主检查，不生产不良品；不传递不良品：及时发现不良品，不传递到下工序；3、团结、进取、尽职、诚信，是公司对每位员工的最基本要求，是公司的企业精神；4、持续不断地改善，追求完美、不断完善，是品质的追求目标；第二章 QC管理规定第一节不合格品处理流程2第二节 不良品返修流程第三节 品质管理条例1.0目的使所有员工自觉遵守作业规范，严格贯彻执行公司“三不政策”，杜绝和预防不良品的生产及交付，以“零缺陷”为追求目标，最终达成公司质量方针及质量目标。
2.0适用范围适用于公司所有员工。
3.0定义3.1产品缺陷分类3.1.1致命缺陷：安全件关键重要部位出现虚焊、脱焊现象，严重影响乘客安全，易造成车毁人亡事故发生；3.1.2严重缺陷：因产品不良，虽不影响乘客安全，但严重影响产品性能、功能；如：严重缩颈、破裂、缺件、漏加工、错位加工、少打点等；3.1.3一般缺陷：因产品不良，不影响乘客安全，也不影响产品性能，但严重影响产品外观及用户组装；如：轻微缩颈、毛刺过大、零件锈斑/油斑、打磨不良、清丝不良、焊接击穿、焊渣、焊接飞溅等。
3.2批量：致命缺陷和严重缺陷3件（含3件）以上为批量，一般缺陷发生数量在20件(含20件)以上为批量。
3.3人为：由于操作者操作方式不当或违章操作，导致产品不良。
3.4质量事故发生范围：分为公司内部发生和顾客处发生。
3.5明显不良：产品的缺陷十分明显，通过目视就能发现。
4.0质量目标4.1公司内部质量目标：4.1.1冲压FTT：≥98%；返修率：≤1.92%；废品率：≤0.08%；4.1.2焊接FTT：≥99.8%；返修率：≤0.199%；废品率：≤0.001%；4.1.3出库检查合格率：≥99%；4.2公司对外质量目标：4.2.1进货不良PPM：≤350；4.2.2交付不良PPM：CAF：≤60；5.0质量改善提案奖励：个人质量改善提案，参照公司“提案改善”相关办法执行，QCC改善参照“QC管理办法”执行；5.1自主检查或巡检发现不良奖励：操作者或品检员在生产过程中，主动检查上工程/工序的零件，并发现不良品，由所在班组申报（申报时间必须在3日内书面提出），经品保部确认后报公司领导批准，给予奖励；5.2质量奖金的颁发时间及方式：经公司主管领导批准生效所产生的奖金，于生效月之次月颁发；以文件形式通报全公司表彰。
QC操作手册V_1.5
Q C操作手册版本-V_1.5目录目录 (1)一、概括 (2)二、访问QC (2)1、在XP系统 (2)2、在VISTA系统 (4)三、状态图 (9)四、角色 (10)1、测试人员 (10)2、开发人员 (12)3、测试组长 (13)4、子工作流业务组长 (15)5、子工作流技术组长 (15)6、导入缺陷的人员 (17)五、※注意事项 (21)一、概括缺陷的管理工作是以角色的划分为基础，每个角色成员拥有该角色的权限，比如拥有测试人员角色的成员有提交缺陷的权限，而开发人员角色下的成员并没有。
目前角色共有6类：1.测试人员2.开发人员3.测试组长4.子工作流业务组长5.子工作流技术组长6.导入缺陷的人员本手册主要按角色所拥有的权限，所能做的工作进行说明，以及部分注意事项。
二、访问QC请使用IE浏览器访问QC工具，目前访问地址为：http://197.1.5.33:8080/qcbin/start_a.htm，1、在XP系统XP系统下,首次打开的时候会有下载控件的提示：<安装ActiveX控件><点击安装><自动下载插件><若机器中无.net2.0，那么会出现net2.0的安装提示，点击下一步，同意守则，安装即可><下载完毕后，IE自动跳转到登陆界面>输入登录名和密码，选择相应的域和项目，即可进入系统，对缺陷进行管理。
2、在vista系统vista系统中需要先将“用户帐户控制”关闭，具体操作如下通过“设置”进入“控制面板”进入“控制面板”→“用户帐户”打开“用户帐户”点击“用户帐户控制”，将“使用用户帐户控制（UAC）帮助保护您的计算机”前面的勾去掉。
后面的操作同XP系统，打开IE进行插件下载，即可正常使用QC工具。
3、首次进入的界面设置无论哪种角色，第一次进入系统时的界面为下图关闭提示框后,首先要点击”选择列”按钮将需要显示的列按顺序放在可见列中:<1> 缺陷流程的字段顺序为:缺陷ID, 所属业务模块, 测试日期, 测试人, 缺陷分类, 可重现, 严重程度, 解决优先级, 期望解决日期, 实际解决日期, 案例编号, 测试点, 交易代码, 交易名称, 交易提交日期, 交易开发者, 缺陷原因, 重测次数, 缺陷状态, 分配给, 缺陷审阅人, 缺陷描述, 注释, 调整好内容如下图:<2> 测试提交流程的字段顺序以下图片只参考其中标注红色框区域的变化，实际工作中，字段的顺序可能与图片不符。
QC使用说明
QC使用说明qc是目前social game组使用的缺陷管理工具。
在部门内程序，策划和测试（日后可包括客服）都可能使用到。
以下是使用说明。
一．登录目前QC的地址为http://服务器IP/qcbin/start_a.htm，访问以上地址即可打开QC登录界面。
如图1.图1提示：第一次使用QC会安装一些插件，非IE浏览器的默认设置可能会影响插件的安装，第一次使用请尽量用IE6，7登录，并将安全级别暂时调低，插件安装之后可以用其他浏览器登录(或者安装QC客户端插件)登录具体步骤：（请参照图1）：1.输入Login Name为自己的中文名2.输入Password即可登陆（默认密码为空，请登录后修改密码，修改方法见下文）3.一般选中图中的复选框并按“Authenticate”按钮二．具体使用方法1.进入QC的BUG管理界面如图2，登录后在界面上方有绿色的导航栏，默认显示为REQUIREMENTS。
点击第六项DEFECTS，进入BUG管理界面，即可开始相关BUG查看和管理工作。
图2（附：修改密码方法：见图2，点击TOOLS下的Customize选项（在屏幕右上方），在弹出图3界面，选择Change Password（屏幕右下角）即可打开密码修改窗口。
）图32.QC使用主要功能介绍图4如图4，粉色框住部分是一个过滤器，你可以设置需要浏览哪些BUG。
另外，还可以通过粉色椭圆泉起来的漏斗按钮来选择过滤条件。
例如，想浏览所有提交给你的BUG，方法为：点击Assigned to下面的白色方框，在User 中选择你的名字，点击OK，即可浏览提交给你的BUG。
如果要浏览提交给你的处于new状态的BUG，则需要同时在Assigned to中和Status中设置。
如上所述，可设置更多的选项来限制浏览的条件，从而达到更精确的浏览。
提醒：1)点击图4中红色中按钮（Select Columns），即可修改过滤器的设置。
点击此按钮，将左侧的项目加入右侧，即可加入过滤器中。
QC测试管理工具使用手册精品文档12页
HP Quality Center 测试管理工具使用手册修订记录目录1概述 (1)1.1背景 (1)1.2目的 (1)1.3预期读者 (1)2用户组及权限 (1)2.1用户组 (1)2.2组权限 (2)3使用指南 (3)3.1“需求” (3)3.1.1需求编写 (3)3.1.2常用操作 (3)3.2“测试计划” (4)3.2.1案例编写 (4)3.2.2常用操作 (5)3.3“测试实验室” (6)3.3.1测试执行 (6)3.3.2常用操作 (6)3.4“缺陷” (6)3.4.1提交缺陷 (6)3.4.2常用操作 (7)1 概述1.1 背景目前的使用的testlink在编写用例时候比较麻烦，不能够迅速的编写用例，只有使用xml’格式才可以导入到testlink中，或者使用excel 格式，但是其中excel也必须加入编码才能够导入进入，客观上增加了软件测试工程师编写用例的难度。
其次testlink 只能对用例进行管理，产生的bug 必须再一次通过bug管理系统提交，一定程度上，浪费了时间。
使用的测试管理工具是HP Quality Center 10.0（以下简称QC），QC是Mercury Interactive公司推出的基于WEB的测试管理工具。
QC能够帮助你组织和管理软件测试过程的每个阶段，包括测试需求管理、测试计划、测试案例测试、测试执行和缺陷跟踪。
1.2 目的为了指导QC用户更好的使用QC进行日常工作，特编写本文档。
1.3 预期读者本文档预期读者为：QC普通用户。
2 用户组及权限2.1 用户组QC中的用户包括项目管理员及普通用户，普通用户分为开发人员、测试人员、业务人员和其它人员，各种人员职责如下表所示：注：一个用户可以拥有多个角色，例如，项目开发者做软件编码时属于开发人员范畴，做技术测试时属于测试人员范畴。
2.2 组权限注：“删除”权限，只有项目管理员具有，需要删除操作时可找项目管理员进行。
QC操作手册
QC操作手册2010年1月目录1.编写目的 (2)2.QC状态流程 (2)3.QC状态的说明 (2)4.操作流程 (3)4.1．提出问题 (3)4.2．处理问题 (3)4.3．回归问题 (4)1.编写目的运用QC可以集中管理缺陷，对BUG进行实时的跟踪，测试出的BUG可以快速传递给开发，并提高开发与测试对BUG的互动。
2.QC状态流程状态流程图如下图：蓝色表示开发可做的动作，其它为测试可做的动作所有人都具有分配权限，其它权限如下：测试人员：新建固定->重新打开固定->关闭已否决->关闭测试负责人：新建->确认新建->无效已否决->重新打开开发人员：确认->延期确认->已否决确认->打开打开->修复打开->延期修复->固定延期->打开重新打开->修复重新打开->延期3.QC状态的说明开发人员处理状态：固定：bug已经被解决,并且通过经过测试。
已否决：被描述的问题不是一个bug（测试人员提出这个bug,但是开发人员认为不是bug）。
延期：被描述的问题是一个bug,但是不准备进行修改。
打开：被描述的问题是一个bug,正在进行修改。
修复：被描述的bug已经修改完成，还没有进行打包。
测试人员处理状态：新建：测试人员录入一个新bug时，这个就是第一个默认初始状态，而开发人员看到这个状态时bug,就知道这是一个新引入的bug。
确认：当一个bug被指认为新建之后，由测试负责人确认这是不是个bug，当确认后，开发人员才能对bug进行修改。
无效：当一个bug被指认为新建之后，由测试负责人确认这是不是个bug，如果不是 bug，把状态变为无效重新打开：开发人员固定之后，但是经过测试他的这个bug仍然没有被解决。
关闭：bug已经被解决,解决方案是被认为是正确的。
4.操作流程4.1．提出问题1、测试发现BUG，在QC上新建一个BUG， BUG的状态为“新建”状态。
QC应用缺陷处理流程
QC应用缺陷处理流程规范1. 软件缺陷的记录项目每个成员都可以通过工具，记录发现的错误，对错误的描述内容可能包括测试软件名称，测试版本号，测试人名称，测试功能点，测试的软件和硬件配置环境，发现软件错误的类型，错误的严重等级，在BUG描述中说明问题出现的详细步骤，必要的附图，测试注释。
2. 软件缺陷的状态9新缺陷(New)：测试中新报告的软件缺陷；9打开 (Open)：错误被确认并分配给相关开发人员处理；9固定，修正(Fixed)：开发人员已完成修正，等待测试人员验证；9否决，拒绝(Dejected):拒绝修改缺陷；9挂起，延期(Deferred):不在当前版本修复的错误，下一版修复9关闭(Closed)：错误已被修复；9重新打开（reopen）:将状态不是‘open’的错误，重新打开分配给相关开发人员处理。
3.软件缺陷处理过程记录缺陷在流程中流转时，在每一阶段被处理后，处理人要做好相应的记录，说明。
处理信息内容如下：9处理者姓名9处理时间9处理步骤9处理情况最后注意更改缺陷记录的当前状态。
★ QC中对缺陷处理可进行如下操作：一描述信息：对原来的描述信息进行补充，修改。
二注释：在每一个阶段对缺陷处理的总结说明，各阶段对应的内容分别是： 编码完成：对缺陷修复后，添加编码实现的设计思路，提供复杂的操作步骤提示。
测试完成：对修复的缺陷，如果有复杂的操作说明，或必要的设置进行操作说明注释。
挂起：对被“挂起”的缺陷，增加注释说明挂起原因。
否决：对被“否决”的缺陷，增加注释说明否决原因。
三附件：添加必要的附件。
四历史记录：当‘被指派人’和‘状态’属性任一被修改后，系统自动添加一条编辑记录，包含信息：字段，修改时间，修改人，修改值。
4. 缺陷数据库操作管理权限正确的数据库权限管理是缺陷管理系统的数据安全，完整的保证。
一般要保证对于添加的错误不能从数据库中删除。
5. Bug状态管理的流程1. 测试人员提交新的Bug入库，错误状态为‘新建’。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
3.数据流错误
4.轻微数据计算错误等
4-非常高
1快捷方式不正确，如能够回车直接进入下一步的设计成了空格直接进入下一步
2严重的逻辑错误
3常用操作平台不能正常使用功能(WIN XP/WIN 2000/WIN VISTA)
4常用浏览器不能正常使用（IE6.0/IE7.0/FireFox）
5超时限制的时间设置不合理
分配给
记录该缺陷分配给谁去修改。一般来说，登记时都是统一分配给项目经理，再由项目经理确认并分配给相关开发人员(或者直接分配给相应的开发人员)。
人员
开发组长：PM developer
开发组员：P developer
测试组长：TM Tester
测试组员：Tester
当前缺陷状态
可修改缺陷状态
当前缺陷状态
3数据问题：录入的数据错误。
4易用性问题：用户操作使用过程中存在的不符合使用习惯或操作复杂等方面的缺陷。
5兼容性问题：系统在不同的测试环境中产生的缺陷。
6性能问题：系统性能未达到性能需求所要求的各项指标。
7安全性问题：系统存在安全方面的隐患一类的缺陷。
可重现
记录缺陷是否可重现。根据缺陷描述操作，是否可以发现缺陷所描述的问题，Y表示可以重现，N表示无法重现。例如有些问题是在特定条件下才出现的，当条件改变后问题随之消失，根据所描述的步骤操作，不会再出现缺陷所描述的问题，这类就是属于无法重现的缺陷。
：刷新，刷新在需求模块中的数据。
单击 按钮，去刷新当前所选择的需求。所有子需求也会被同时刷新。
单击 箭头并选择全部刷新去刷新所有的需求。
：选择列，打开选择列对话框，你可以决定哪些字段显示在需求树中，并决定它们的显示顺序。
：展开，改变需求树的细节等级。
单击 按钮去展开需求树的指定分支。
单击 箭头并选择缩小一级去取消预先展开的命令。
描述
详细描述重现该缺陷的步骤，错误现象和期待结果。必要时可以上传附件辅助说明。
状态
缺陷状态描述如下表：
序号
缺陷状态英文名称
缺陷状态中文名称
缺陷状态描述
备注
1
New
新建
测试中提出报告缺陷，普通开发人员无权修改状态为“新建”的缺陷，只能修改状态为“打开”或者“重新打开”的缺陷。“新建”的缺陷需要项目经理确认并将状态置为“打开”
可修改缺陷状态
当前缺陷状态
可修改缺陷状态
当前缺陷状态
可修改缺陷状态
打开
否决
分配
无法解决
新建
打开
修复
已关闭
打开
分配
分配
修复
新建
丢弃
修复
重新打开
打开
丢弃
重新打开
修复
新建
重复
修复
测试同意
延期
分配
分配
延期
修复
已关闭
分配
修复
分配
进行
修复
重新打开
分配
无法解决
进行
修复
修复
测试同意
分配
延期
重新打开
修复
分配
进行
进行
修复
3-高
1提示信息不明确，并且非常容易误导用户做出错误操作或判断。
2软件功能的实现过程中弹出未控制的系统错误提示，导致流程中断
3Cookies没有正常保存
4服务器和客户端的脚本修改未被记录和
5非法操作等Urgent程度的bug，如果不具有普遍性而是在极端环境下出现，例如特定的操作环境。建议级别定义为High。
需求管理状态流程图
人员需求权限表单
需求分析
开发组长
开发组员
当前缺陷状态
可修改缺陷状态
当前缺陷状态
可修改缺陷状态
当前缺陷状态
可修改缺陷状态
新建
打开
打开
分配
分配
进行
新建
否决
打开
否决
进行
完成
分配
进行
分配
完成
分配
完成
分配
延期
进行
完成
延期
完成
分配
延期
延期
完成
实施人员：新建
QC
缺陷
摘要
对缺陷的简单描述。摘要包括该缺陷所属的模块名称-子模块名称，以及简单说明缺陷情况。
IMPLEMENT实施：新建
Analysis需求分析：无
缺陷严重程度和优先级
缺陷严重级程度与优先级别原则上是有一一对应的关系，在填写缺陷选择这两项时，可先参照该对照表：
缺陷严重程度中文名称
缺陷严重程度描述
对应的缺陷优先级选项
缺陷优先级描述
5-紧急
阻碍流程、系统崩溃导致重大任务不能正常进行的缺陷,例如:
单击 箭头并选择缩小为根去收缩，并显示整个需求树的根结点。
：查找，打开查找需求对话框，能够让你在需求树中查找你想要的需求。
：Mail需求，打开发送邮件对话框，你可以从邮件列表中选择收件人，或输入其它的邮件地址，发送需求邮件。
：附件，打开附件对话框，能够让你为所选择的需求添加附件。对于更多信息，请看第4章“增加附件”。
（外网的同事请访问：http://114.251.7.24:8088/qcbin）
图1
2、如果之前没有安装过相关插件，浏览器会提示是否安装插件，点击确定安装，开始安装插件，如图2所示。
图2
3、安装完插件后会自动跳转到登录页面，如图3所示。在“用户名”输入框输入您的中文姓名（如：张三），密码为空，点击【身份验证】按钮。
9
Tester Agree
测试同意
测试人员同意开发对缺陷做出的处理(这种处理可能是一种折衷的方法)
10
丢弃
丢弃
被确认为无效缺陷
11
分配
分配
分配给相关人员处理
12
进行
进行
开发人员正在开发中；用于开发周期长，为了让关注该功能的人员知道目前的进程
13
Duplicate
重复
由于测试重叠工作或者不同测试人员重复提交等原因,出现相同描述的缺陷重复报告.
项目
记录缺陷所属的项目。
缺陷管理
图11
开发人员修改缺陷填写规范
1、不论是简单还是复杂的缺陷，开发人员都要在修改了代码并确保代码提交到服务器后，再将缺陷状态由“打开”置为“修复”。
2、对于非常简单明了的缺陷（例如界面上的一个错别字），可以在注释中加简单的注释说明：（如：已修改）但对于复杂的缺陷，必须要注明以下几点：
图3
4、通过验证后“项目”下拉列表会列出您有权访问的项目，如图4所示。选择你要登录的页面，点击【登录】按钮。
说明：
域：选择您要的相应的域；
项目：项目列表只列出你有权访问的项目。
图4
5、登录后的初始页面。登录成功后，出现如图5所示页面。
图5
6、进入缺陷列表。点击图5所示页面左边列表中的 项，将看到如图6所示的缺陷列表界面，目前该项目还未录入任何缺陷，所以列表是空的。
1缺陷产生的原因：
2缺陷解决的方法：（该项描述主要是方便以后遇到同类问题的同事，可以查看当时的解决办法，如果该缺陷的修改引发了其他的缺陷产生，则开发人员可以查看一下当时的修改情况）
3这个改动引起了哪些变动：（方便测试人员在进行回归测试时，测试的深度和广度的把握）
3、如果缺陷是由于测试人员理解错误导致，或者开发人员认为不需要修改的，开发人员可以将缺陷状态设置为“否决”，但是必须在【注释】栏中填写拒绝修改的原因。
编辑菜单，包括命令：剪切、复制、粘贴、重命名、删除需求，和查找、替换搜索需求。
视图菜单，包括命令：设置需求树的显示、查找一个需求、浏览测试覆盖、关联缺陷、附件。
收藏夹菜单，包括命增加、组织个人使用喜好的命令（不开放）。
分析菜单，包括命令：产生需求报告和图表。关于需求报告的更详细信息，请看“产生报告”。关于需求图表的更详细信息，请看“产生图表”。
2
Open
打开
被确认
3
Fixed
修复
开发人员已完成修正,等待测试人员验证
4
Closed
关闭
缺陷已被修复
5
Reopen
重新打开
缺陷未被修复
6
Rejected
否决
拒绝修改缺陷，该缺陷可能由于测试人员理解错误，或者项目经理认为不需要修改
7
延期
延期
不在当前版本修复的错误,下一版本修复
8
无法解决
无法解决
以目前的技术水平、经济因素或修改此缺陷的代价过大等原因而不能解决的缺陷
图6
7、修改密码。如图7所示，点击页面右上角的【工具】，选择【自定义…】，进入如图8所示页面，点击 ，右边显示如图9所示页面，再点击右下角的【更改密码…】按钮，进行修改密码，原密码为空。
图7
图8
图9
8、更改项目。如果你同时拥有多个项目的权限，那么登录到其中一个项目后可以不需要退出而直接更改到另一个项目。如图10所示，点击页面右上角的【工具】，选择【更改项目】，再点击你所想要的项目即可。
检测于版本
记录发现该缺陷软件版本号，测试负责人员在每次获取到新的测试程序包时，按照程序包上的版本标签号，在QC的自定义管理中版本号一栏增加对应的版本号（注：程序包的版本号与QC中增加的版本号一致）。
缺陷
记录缺陷的类型，暂时分为7类。
1功能问题：软件功能未实现或实现不完整、不正确等情况下的缺陷。
2界面问题：用户操作界面中存在的不合理、不正确、不美观等方面的缺陷。
2-中
错别字、罕见故障等不影响执行工作或功能实现,例如:
1.辅助说明描述不清楚
2.系统处理未优化
3.提示窗口文字未采用行业术语