软件项目缺陷跟踪和持续改进

1、1.1 转测质量1.1.1 交付要求1 .产品开发或修改准备提交测试版本在做转测试前需要开发设计工程师完 成必要的自检并输出自测报告或调试报告2 .产品开发版本必须满足各阶段测试输入质量要求，并在对其自检并输出自测报告或调试报告审核后给出结果；3 .对于产品设计开发验证各阶段各类型缺陷Bug要求开发设计工程师必须给出明确清晰的问题分析原因和改善解决对策，并在Buglist和缺陷回馈体现！并自检其有效性！4 .对于满足提交标准的测试版本必须在提交测试申请同时配备软/硬件程序版本配置清单说明！5 .交付件必须完成过程审查与归档；1.1.2测试标准1.1.2.1 测试开始准入标准1 .首次测试准入标

2、准：硬件环境可用并要求标准，软件正确安装且可执行； 核心和关键业务功能100%?现；提供产品功能调试报告或自检报告；并 配备软硬件程序配置清单；2 .里程碑版本要满足阶段的质量要求。里程碑版本必须提交调试报告；3 .版本测试前需提交完整的产品软件包（不能是单个软件）4 .版本软/硬件测试申请、程序配套表和系统配套表（配置清单）5 .版本回归测试标准：致命缺陷修复率必须为 100%重要缺陷修复率不低 于85%缺陷总修复率必须不低于80%勺情况下，才能提交新版本测试中 请。6 .版本回归测试标准：对于提交的版本缺陷报告中的 CRI、MAJ MIN缺陷问 题分析原因和改善解决对策描述不清晰或无描述；

3、7 .对于设计变更或缺陷修复后的验证版本需要提供必要的测试申请说明和 操作步骤指导说明，包括：环境、条件、配置、步骤、方法、达成目标等。1.1.2.2测试中断标准1 .测试环境无法达到标准或无法满足测试的一致性，安装无法正确完成；2 .产品关键业务功能、性能、可靠性发现致命缺陷导致后续测试活动无法继 续开展或测试结果不可靠；3 .已修复致命缺陷重现和新发现的致命缺陷导致后续功能无法连续实现或 后续测试用例无法实施或测试结果不可靠；4 .对于提交的版本缺陷报告中的 CRI、MAJ MIN缺陷问题分析原因和改善解 决对策描述不清晰或无描述；5 .基本用例有缺陷，中断测试打回。1.1.2.3测试完成

4、标准1 .除因缺陷导致无法实施的测试用例之外，测试覆盖率达到95%2 .除因缺陷导致无法实施的测试用例之外，测试有效性和准确性评审达到 95%3 .达到各阶段测试质量目标。1.2 缺陷修复质量和及时性软件的缺陷是软件开发过程中的重要属性，它提供了许多信息。不同成熟度 的软件组织采用不同的方式管理缺陷。低成熟度的软件组织会记录缺陷，并跟踪 缺陷纠正过程。高成熟度的软件组织，还会充分利用缺陷提供的信息，建立组织 过程能力基线，实现量化过程管理，并可以此为基础，通过缺陷预防实现过程的 持续性优化。1.2.1 缺陷定义1 .软件未达到需求规格说明书的功能。2 .软件出现了需求规格说明书指明不会出现的错

5、误。3 .软件功能超出需求规格说明书的范围。4 .软件未达到需求规格说明书未指出但应达到的目标5 .测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认 为不好。1.2.2 缺陷生命周期1.2.2.1 缺陷生命周期图Ti出一重新激活 T不逋E拓而1.2.2.2缺陷状态说明缺陷状态状态说明激活状态缺陷的初始状态，或者重新被激活的状态。激活状态的缺陷可以通过编辑来修改缺陷内容，并指派给合适的工程 师处理。解决状态缺陷被解决之后的状态。激活状态的缺陷经过成功修复以后，由开发工程师操作为解决状态， 系统将自动指派回创建者。关闭状态解决状态的缺陷在验证通过后关闭，缺陷状态变为关闭，生命周期结

6、 束。如果验证未修复或者新版本又发生，则重新激活，缺陷状态重新变为 激活。1.2.3 缺陷处理过程1.2.3.1 正常处理过程(1)创建问题在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷 等。创建问题时，需要描述清楚，并选择正确的选项。(2)指派问题创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或 直接指派给相应模块的开发工程师。 如果指派人是错误的，或者需要他人确认或 帮助，则可以重新指派给合适的工程师，写上相关备注。(3)确认问题通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug,则选择“确认状态”；如果认为非Bug,则注明原因

7、并指派回创建者。当创建者收到确认指派时，需要进行及时确认。如果同意为非bug,则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。(4)解决问题此为开发工程师的主要职责，包括 Bug的复现、修改和修改验证。开发工程 师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状 态，解决方案规则请参考5,4中解决方案定义部分，在缺陷管理系统中解决方案 选择相应的选项，解决后系统将自动指派回给创建者。如果Bug无法解决或修改 影响比较大，可申请进入“延期解决”流程，请参考 5,2中延期处理部分。(5) 验证问题创建者需要及时对解决状态的Bug在对应版本上面进行验证。如果验证通过

8、， 则可关闭Bug；如果验证不通过，则激活此 Bug,系统将自动指派回给解决者。 验证通过准则：相同的操作步骤，进行一定次数的验证测试都没有发生。 验证不 通过准则：相同的操作步骤，全部或部分实际结果还会发生， 验证不通过则激活 Bug。(6)关闭问题通过验证的Bug,验证者需要注明验证结果并进行关闭操作，系统将指派给 Closedo如果关闭状态的Bug在之后版本又会发生，则激活此 Bug,系统将自动 指派回给解决者。1.2.3.2 特别处理过程(1)客户问题客户反馈的问题可以由客户直接反馈或项目经理、市场部等了解到的客户问题，经确认后的Bug提交到测试管理系统，按照以上处理流程进行处理，由创

9、建 者或测试组进行跟踪验证关闭。创建客户问题时，创建者需要在Bug标题开头标 记为客户问题,测试组负责检查和更正。(2)争议处理当开发和测试工程师对某问题有争议并且多次沟通无果时，可以注明双方的理由，并指派给项目经理进行处理。项目经理可以召开评审会议，或者直接与双方沟通了解，并根据项目情况给 出专业意见和最终决定。开发和测试工程师根据项目经理的最终决定执行。(3)延期解决当开发工程师对确认Bug进行解决时，发现或评估其解决时间紧或风险比较 大等，可以说明原因或理由并指派给项目经理来确认。项目经理可以召开评审会议，或者直接沟通了解，并根据项目情况给出最终 决定。如果不同意，项目经理将此Bug指派

10、开发工程师，开发工程师继续分析和 解决。如果同意，项目经理需要在Bug标题开头标记为延期解决和在处理状态 选择“延期解决”，然后注明解决时间计划并指派回开发工程师，开发工程师根 据解决时间计划来规划和解决此 Bug。1.2.3.3 缺陷管理工具软件测试过程中所有缺陷要提交到测试管理系统进行跟踪管理。1.2.4 缺陷处理及时性缺陷问题处理及时性，是指要求缺陷发现后，项目经理、测试人员、开发工 程师在短时间内做出快速反应和处理。处理的及时性要求：1、测试人员在测试出问题缺陷时，要第一时间将问题按照要求规范整理并 录入问题管理平台；根据问题所属模块，将问题指派给对应的开发人员； 并根据问题的等级将问

11、题抄送给对应的关注人。2、开发工程师在收到问题平台所分配的问题，要第一时间根据问题的优先 级安排问题修改计划。如果问题优先级高，需要立即处理。3、项目经理或问题关注人要及时关注问题平台，遇到优先级高的问题需要及时关注问题。如果问题在处理过程中遇到困难要第一时间进行资源协调、问题讨论，拒绝问题搁置。4、质量专员要定期分析问题平台的问题，将常见问题归纳终结别面再次出 现。1.3 上线后代码质量验证和持续改进1.3.1 版本代码控制规范软件产品的开发、测试、发布流程，提高开发人员的代码开发质量，通 过加强对编码过程的监控，细化工作流程，达到提升软件开发效率，并逐步推进 敏捷开发过程，实现代码管理的自

12、动化。1.3.1.1 版本管理工具通过GIT、SVMIM弋码管理工具进行版本管理，实现每个本都有单独的代 码分支。实现代码分支管理和版本的追溯、回退操作。1.3.1.2 版本管理流程1.3.1.2.1 岗位划分1、代码管理员(Source Code Manager)负责管理版本管理系统使用者的权限。根据项目新建请求，创建新开发分支并划分权限。负责监督生产用分支代码的集成/编译/部署。2、项目开发负责人(Project Leader )全面负责管理项目所涉及到所有相关资源，包括文档、代码等。审核本项目中所有提交到测试和生产分支上的代码，对其质量和可靠性负有责任。对项目开发进度负责。负责项目开发分

13、支的管理工作。3、项目开发组成员(Project Developer )承担具体代码开发工作。负责个人开发分支上代码管理工作。负责个人开发内容的自测工作。对提交到项目分支上的代码质量控制，负有主要责任。4、测试组人员(Project Tester )负责项目的全面测试工作，对测试报告的可靠性承担主要责任1.3.1.2.2 版本树划分1、生产分支最新节点应与生产环境中的运行软件保持一致，此分支上的所有节点均满足 生产上线要求，并根据实际生产环境代码状态进行演进。完成测试准备上线的项 目代码，必须提交到该分支上，进行独立编译生成部署文件。2、版本分支收集开发人员的开发成果，由项目开发负责人统一管理

14、。此分支为打版分支。 由代码管理员建立此分支，在对应版本中，所有开发人员的开发成果需要汇总到 此分支，版本结束后关闭该分支的提交功能，只允许进行查询。3、个人开发分支由开发组成员自主创建和管理，承担日常开发过程中代码归集，记录详细开 发过程。要求每日工作完成必须在该分支上产生节点， 每一个功能点均有独立的 节点存在。1.3.1.2.3 流程分析1、流程图代码管理员SCM项目组负责人项目开发人员测试组单个功能点测试项目测试2、流程介绍成立代码管理员收到项目成立申请，根据项目归属，从指定的生产分支节点拉出 项目分支，将项目组相关人员添加到项目分支下， 设定相应权限，提供分支地址 等信息给项目负责人

15、。项目负责人在项目分支上做初始化设定，做基本修改，建立初始版本后，将 项目分支信息提供给开发组成员0开发项目组开发成员以项目分支为父分支，建立包含个人姓名的开发子分支（可 多个），并在该分支上进行代码修改。在完成修改后，提交代码，在开发环境中 获取修改后的代码，进行编译调试和自测，根据调试结果进行后续的代码开发工作。在完成一个功能点的代码开发并自测通过后， 将个人开发分支及集成节点信 息，提交给测试组成员，进行单个功能点测试。测试组完成单个功能点测试后，开发成员将个人修改代码和项目分支最新点 进行对比，并将对比结果提交给项目负责人进行代码评审。 项目负责人根据评审 结果，决定是否将该代码合并到

16、项目分支。测试在完成所有的项目开发工作和代码评审后，项目负责人将最终的代码节点信息提交项目测试组，由测试组根据节点内容进行编译、部署、测试后，根据测试 结果，提交测试报告。部署代码管理员在项目满足进行生产部署的所有必备条件后，将项目分支的最终测试通过节点，合并到生产分支，并启动生产环境的编译、部署工作。1.3.2上线版本控制系统上线后，需要明确版本提交/测试/发布/上线的流程与要求，明确各流 程中的人员职责和配合关系等，以便所有版本的工作得到有效跟踪， 保证工作顺 利有序地进行。1.3.2.1 版本发布流程版本上线:包括新系统初始版本上线及升级版本升级上线两类。项目负责人：项目负责人一般为项目

17、经理或项目经理指定的项目负责人员1.3.2.2流程图版本上线和系统割接流程图提交阶段项目负责人测试人员用服人员项目相关人员用服部经理举起版N提交撰写提交信息/根据实际情况反复多次执行版本测试/撰写测试结果测试阶段实施阶段是否发布版木?确定执彳f时间/ 制定实施方案.审核执行另案/安 排配合/提|出要求上线&升级支撑执行at划/完成-上线&升级/撰写报告上线&社类支撑一确认阶段收到上线&升 级结果通知收到上线&升级 结果通知/确认 是否二次归档收到上线&升级结果通知确认结束'流程1.3.2.3流程说明流程主要包括打版、测试、发布、上线、确认

18、 5大流程，对于存在多次的打 版/测试过程不在流程中体现，同时针对过程中需要进行配合的事项，如人员配 合安排、上线&升级方案审核确认等事宜需线下确认。1.3.2.3.1 项目负责人首次打版项目负责人进行版本提交时，在 OA工作流中发起版本提交申请，填写完整 流程单后主送给下一阶段的测试人员处理； 同时将流程单抄送给项目组相关人员 及质量部经理、用服人员。1 .项目负责人发起版本提交申请时，需完整填写提交地址、模块信息、版本 特性；同时检查好版本库中对应的提交文件是否存在、提交内容是否正确 无误。2 .对于明确不需要发布的版本，则不需要抄送给用服人员。3 .用服人员根据流程单信息，可提前

19、做好版本提交相关准备，准备上线耐级方案；并注意跟进版本的发布情况。1.3.2.3.2 测试人员测试版本测试人员在收到版本提交的流程单后， 根据版本的时间要求安排完成测试工 作，并发布测试结果，将填写完整的流程表单提交给项目经理。1 .测试人员在收到提交的版本时，需确认工作流中版本提交信息是否完整无 误，如果存在问题需退回给提交者重新填写。2 .测试人员在收到版本后及时完成版本的测试工作；测试完成后，测试人员在表单中填写版本测试的结果信息，提交流程单给项目经理。1.3.2.3.3 项目负责人提交回归版本项目负责人在收到测试完成邮件后；安排进行版本的回归修改，在针对问题单进行了相应的修复或应有处理

20、后，则可以进行回归版本的提交。1 .项目负责人发起版本回归提交前，需检查是否完成了相应BUG的彳复，不进行修改的BUGS否进行了应有的确认，将有效信息传递到下一个环节 处理人员。2 .项目负责人需合理控制回归的次数， 对BUB否修改作好风险评估，以避 免回归次数过多现象。1.3.2.3.4 确认结束流程项目负责人、测试人员收到版本上线 耐级结束通知后，依次根据自身职责 进行确认并结束流程。1 .项目负责人和测试人员对版本升级报告进行审核， 对升级过程是否存在遗 漏和遗留问题隐患等方面确认，并对存在的遗留问题和遗漏等进行相应的 处理安排，并跟踪执行。2 .测试人员确认是否在版本上线过程中产生临时

21、版本，并对临时版本进行补测和归档。3 .用服部经理对用服人员涉及的版本上线初级执行情况和工作质量等进行 必要的检查。1.3.3"PDCA管理模式PDCA1环又叫戴明环，是美国质量管理专家戴明博士首先提出的，它是企业全面质量管理所应遵循的科学程序。 质量管理活动的全部过程，就是质量计划的 制订和组织实现的过程，这个过程就是按照 PDCA1环，不停顿地周而复始地运 转的。ISO9001:2000标准指出，PDCAT法可适用于所有过程。其模式可简述如下：P-策划：根据顾客的要求和组织的方针，为提供结果建立必要的目标和过 程；D-实施：实施过程；C-检查：根据方针、目标和产品要求，对过程和产品进行监视和测量，并 报告结果；A-处置：采取措施，以持续改进过程业绩PDCA1环可通过以下八个主要步骤实现：分析和评价现状，以识别改进的 区域； 确定改进的目标；寻找可能的解决办法，以实现这些目标；评价 这些解决办法并作出选择；实施选定的解决办法：测量、验证