下载文档原格式
软件测试Bug之“缺陷分析“篇提到Bug，软件缺陷，除了记录一个问题出现的现象和原因以外，对于一个或者多个Bug的分析也非常重要，本文讲述了Bug分析的目的，介绍了IBM的ODC缺陷分析法，已提供给需要进行缺陷分析的测试小伙伴们参考。
Bug记录平台介绍Bug记录平台，用比较文绉绉的话说是软件缺陷跟踪系统（DefectTrackingSystem，DTS）是软件测试管理系统的核心部分。
这里拿华为的缺陷管理系统来举例，网易以及其他互联网公司大部分会使用比较轻量级的开源平台比如Jira平台等。
共同之处是对软件缺陷处理过程有一些最基本的要求，大概包括以下几个方面：1）整个处理过程应该是闭合的，即确保每一个被发现的问题在过程中都能得到解决，在整个过程中追踪缺陷的状态，问题记录在整个周期内都得到维护简单来说可以理解为Bug的状态流转，例如创建、进行中、已解决、关闭等2）每一个被发现的软件缺陷都应该按类别和优先级进行分类3）对软件缺陷的改正应该进行验证，以确保问题确实被解决、不利的影响已经被消除，并且解决该问题所引起的变化不会带来新的问题软件项目团队的全体成员就以软件缺陷跟踪系统（DTS）为工作的参照物，形成良好的工作流程和运行机制，构建如下所示的软件测试管理体系：1）测试人员向缺陷跟踪系统报告新bug，在新版本上执行回归测试验证bug 是否正确修改2）开发人员每天浏览属于自己需要修改的bug，修正bug后及时更新bug 的状态3）项目经理及部门经理根据缺陷跟踪系统的bug分布信息，跟踪和控制软件开发过程4）技术支持人员根据缺陷跟踪系统的bug状况，估计软件的发布期限BUG生命周期全流程：测试人员提交BUG->开发人员处理->测试回归->关闭问题单提交必填属性有：Bug主题、描述、重要性、测试类型、是否线上bug、影响的版本、经办人、回归人等Bug分析目的一、对测试执行过程进行度量和评估，给出版本质量评估及开发测试改进建议。
(完整word版)软件缺陷跟踪复习题一、选择：1．导致软件缺陷的最主要原因是（）。
A．软件系统越来越复杂，开发人员不可能精通所有的技术B．软件的需求说明书不规范C．硬件配置不对、缺乏，或处理器缺陷导致算术精度丢D．软件设置不对、缺乏，或操作系统错误导致无法释放资源、工具软件的错误，编译器的错误等2．软件的质量根本上由( ）决定。
A．编程技术B．测试技术C．过程质量D．开发工具3．下面关于软件缺陷的定义正确的是( ）：A．软件缺陷是计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷B．软件缺陷指软件产品（包括文档、数据、程序等）中存在的所有不希望或不可接受的偏差，这些偏差会导致软件的运行与预期不同，从而在某种程度上不能满足用户的需求C．从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背D．以上都对4．( )指软件缺陷对软件质量的破坏程度，即此缺陷的存在将对软件的功能和性能产生怎样的影响.A。
缺陷优先级 B. 缺陷严重程度C. 缺陷发生频率D. 缺陷类别5．下面关于软件缺陷管理的说法错误的是（）：A. 软件缺陷管理（Defect Management)是指对软件开发过程中的缺陷发现、确认、定位、修复、评审、关闭等一系列行为进行跟踪管理的过程，也就是在软件生命周期中获取、管理、沟通任何变更请求的过程，是软件研发过程中的一项过程管理B. 软件缺陷跟踪管理在现代软件开发中已经占据了很重要的位置，和软件开发的项目管理、需求、设计、开发、测试均严密相关C. 软件缺陷管理是在软件生命周期中为确保缺陷被跟踪和管理所进行的活动D。
软件开发过程中，只需要在测试阶段进行缺陷管理6．（ )是软件缺陷管理的核心,也是软件缺陷预防的核心任务。
A. 缺陷报告B。
缺陷分析 C. 缺陷库 D. 缺陷修复7．软件缺陷发现手段有多种。
软件缺陷描述规*一、缺陷基本定义软件缺陷（Software Defect）：软件缺陷是对软件产品预期属性的偏离现象。
它包括检测缺陷和残留缺陷。
缺陷的优先性，分为5级，参考下面的方法确定：1)最高优先级(Blocker)，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷，或用户重点关注的问题,缺陷导致系统几乎不能使用或者测试不能继续，需立即修复。
2)较高优先级(Critical)，例如，影响软件功能和性能的一般缺陷, 严重影响测试，需要优先考虑；3)一般优先级(Major)，例如，本地化软件的*些字符没有翻译或者翻译不准确的缺陷,需要正常排队等待修复；4)低优先级(Minor)，例如，对软件的质量影响非常轻微或出现几率很低的缺陷,可以在开发人员有时间的时候再被纠正；5)最低优先级(Trival),例如，属于优化，可以不做修改的问题或暂时无法修复但影响不大的问题。
二、缺陷描述软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发工程师交流的最好机会。
一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。
否则，它就会使信息含糊不清，可能会误导开发人员,因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。
缺陷描述的原则：有效的缺陷描述有以下几个原则：➢可以重现：在缺陷的详细描述中提供精确的操作步骤，可以让发人员容易看懂；➢定位准确：缺陷描述准确，不会引起误解和歧义；➢描述清晰：对操作步骤的描述清晰，易于理解，应用客观的书面语，避免使用口语；➢完整统一：提供完整、前后统一的软件缺陷的步骤和信息，按照一致的格式书写全部缺陷报告，有关缺陷的格式参见"缺陷的格式”；➢短小简练：通过使用关键词，可以使问题摘要的描述短小简练，又能准确解释产生缺陷的现象。
如"在新建任务窗口中，选择直接下达，负责人收不到即时消息”中"新建任务窗口”、"直接下达”、"即时消息”等是关键词；➢特定条件：许多软件功能在通常情况下没有问题，而是在*种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或*种设置等），能够提供帮助开发人员找到原因的线索。
软件测试缺陷报告模板篇一：软件测试缺陷报告模板缺陷报告1、概述2、测试策略2.1 界面测试2.2 功能测试篇二：软件测试缺陷报告1 简介1.1编写目的本测试报告为信息管理09-1科技项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合ATKJ-用户需求说明书。
预期参考人员包括用户、测试人员、开发人员、项目管理者、质量管理人员和需要阅读本报告的高层经理。
T estAge 中国软件测试时代!T/d5s??P??Al 1.2项目背景本产品是为信息管理09-1科技有限公司开发的外贸企业管理系统。
本产品依据EasyTrade基础模型研发，形成一个完善的以业务管理系统为核心，以基础信息、系统维护支持的外贸企业管理系统。
主要功能是对该公司生产销售过程，财务过程实现信息化管理。
1.3系统简介1.4术语和缩写词无1.5参考资料1、信息管理09-1科技项目需求与设计、2、信息管理09-1科技项目测试计划、3、信息管理09-1科技项目测试用例、4、信息管理09-1科技项目缺陷报告单、系统测试报告5、公司CMMI体系文件《TS002_测试报告》2 测试概要2.1测试用例设计本次测试用例设计主要采用黑盒测试方法，功能模块及集成测试采用的具体方法有等价类划分、边界值划分、正交分解、因果图分析和错误猜测。
在系统测试时依据业务流程采用回归测试。
2.2测试环境与配置测试服务器配置：服务器地址：10.0.0.39操作系统：Windows XP Professional SP2CPU: Intel(R) Pentium(R)4 CPU 3.00HZ硬盘可用空间：74GB 数据库：Microsoft SQL Server 8.00.2039 应用服务器：EasyTrade服务器测试对象：EasyTradeS3.exe缺陷工具：Mercury Interactive TD8.0 SP2 2.3测试方法(和工具)主要是黑盒测试，测试的重点集中在业务流程、数据提取和各功能模块间的接口。
软件缺陷分类标准修订历史记录（A-添加，M-修改，D-删除）目录1. 引言 (4)1.1 编写目的 (4)1.2 定义与缩写 (4)1.3 参考资料 (4)2. 软件缺陷分类标准 (4)2.1 问题类型 (4)2.2 缺陷属性 (5)2.3 缺陷类型 (5)2.4 缺陷严重程度 (7)2.5 缺陷优先级 (8)2.6 缺陷状态 (8)2.7 缺陷来源、起源 (9)2.8 缺陷根源 (10)2.9 缺陷产生可能性 (10)1.引言1.1编写目的制定本标准的目的是为软件测试提供确信分类的标准。
本文档说明了问题类型、缺陷属性、确缺陷类型、缺陷严重级别、缺陷优先级、缺陷状态、缺陷修改次数、缺陷原因。
其预期的读者是测试人员、开发人员、开发经理。
1.2定义与缩写1.3参考资料表格1-2 参考资料列表2.软件缺陷分类标准2.1问题类型表格2-1 问题类型表格2.2缺陷属性软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因、缺陷产生可能性。
表格2-2 缺陷属性列表2.3缺陷类型缺陷种类：根据缺陷的自然属性来划分。
表格2-3缺陷类型列表2.4缺陷严重程度缺陷严重程度:指因缺陷引起的鼓掌对软件产品的影响程度。
表格2-4 缺陷严重程度2.5缺陷优先级表格2-5 缺陷优先级2.6缺陷状态缺陷状态：是指缺陷通过一个跟踪修复过程的进展情况。
表格2-6 缺陷状态2.7缺陷来源、起源缺陷来源：缺陷引起的故障或事件第一次被检测的阶段，有需求说明书、设计文档、系统集成接口、数据流（库）、程序代码。
缺陷起源：在团建生命周期中软件缺陷占的比例：需求和构架设计阶段占54%、设计阶2.8缺陷根源缺陷根源：测试策略，过程、工具和方法，团队\人，缺乏组织和通讯，硬件，软件，工作环境等造成上述错误的根本因素，以寻求开发、测试人员可改进的地方。
表格2-8 缺陷原因2.9缺陷产生可能性友情提示：本资料代表个人观点，如有帮助请下载，谢谢您的浏览！。
需求
缺陷发现缺陷测试编号描述阶段类型日期
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
表A.1 缺陷记录
1、需求编号：《软件需求说明书》中对应的章节编号。
序号
测试用例编号修复 优先级缺陷 严重程度填表说明：
8、状态：New 、Open 、Reopen 、Fixed 、rejected 、Closed 。
9、“测试日期”栏之前的内容由测试人员完成。
10、修改人填写和“修改人”、“修改日期”、“原因分析描述”、“缺陷起源”、“缺陷来源”、“状态”。
11、由测试人、修改人和验证人按状态设置“缺陷状态”；“测试次数”一栏是回归测试的人员填写。
2、测试用例编号：命名规则是项目编码_测试类型_序号。
3、发现阶段：XQ-需求、SJ-设计、DYCS-单元测试、JCCS-集成测试、XTCS-系统测试、YHCS-用户测试等。
4、缺陷类型：功能(F)、赋值(A)、接口(I)、容错(C)、打包(B)、文档(D)、算法/语法(G)、界面(U)、性能(P)、标准(N)、环境(E)、建议
5、修复优先级：5-Urgent、4-Very High、3-High、2-Medium、1-Low。
6、缺陷严重程度： A-致命错误、B-严重错误、C-一般性错误、D-较小错误、E-测试建议。
7、缺陷起源、缺陷来源：需求、架构、设计、编码、测试。
修改
缺陷缺陷日期起源来源s 陷记录和跟踪表
修改人原因分析描述状态验证人验证 日期测试次数。
)、性能(P)、标准(N)、环境(E)、建议(S)。
1.过程检查要素表2.过程打分2.1.过程打分原则：1)过程打分占整个项目得分的30％，以30分为满分，最低分不低于9分。
2)不同的项目可以从标准软件过程中剪裁得到项目定义过程，因此各项目包含的软件过程是不同的，为了使软件过程数目不同的项目，仍以合理的方式进行过程打分，需对剪裁后的软件过程数目进行换算，从而不因剪裁而失分。
3)SQA人员对经剪裁的软件过程的检查内容和实施情况进行剪裁。
4)项目级的软件过程剪裁必须得到高级经理，质量管理部经理和项目SQA人员的检查和认可；检查内容和实施情况剪裁必须得到项目经理和受审计人员的认可。
5)软件过程检查打分的依据是“过程检查表”。
2.2.打分步骤：1)依据标准过程定义项目过程，得出项目过程数N。
2)每个项目过程的得分M＝30 / N。
3)采用“过程检查表”，对各个过程进行检查和打分。
4)定义“过程检查表”中的实际检查内容项个数为X，每项标准得分10分，因此每个“过程检查表”的最高得分A = 10X。
5)实际检查时，对“实施情况”一栏中每个条款进行打勾“✓”,因此实际每项得分Bj=（打勾条款数/ 该项实际检查总条款数）×10。
6)每个过程的实际得分Bi=∑1x Bj。
7)每个过程的换算得分B=Bi /A ×M。
8)若某个过程发生多次z，则该过程得分B=(∑1zB)/z 。
9)项目的过程得分C=∑1NB 。
10)为确保项目组的基本得分不低于9分，因此各过程打分不得低于9/N分，低于此分，以9/N分计算。
2.3.例子：某项目计划进行5个阶段的审计：计划过程，需求过程，设计过程，测试过程，计划跟踪和监督过程，其中计划跟踪和监督过程执行两次，其他各一次则每阶段得分M=30/5=6;第一次计划跟踪和监督过程检查项共15项，实际由于变更未发生检查了13项, 标准分为A=13×10＝130，实际检查得分Bi=123则该阶段得分B1=123/130 * 6=5.67第二次计划跟踪和监督过程，实际检查了15项，标准分为15×10＝150；实际检查得分140。
软件缺陷上报处理流程
软件缺陷上报处理流程大致如下：
1. 缺陷发现：测试人员在测试过程中发现软件功能不符、性能问题或错误行为等，记录详细复现步骤和现象。
2. 缺陷报告：使用缺陷跟踪系统提交缺陷报告，内容包括缺陷描述、严重程度、重现步骤、期望结果与实际结果对比等信息。
3. 缺陷确认：开发团队负责人或项目经理收到缺陷后，确认其是否为有效缺陷，并分配给相应的开发人员进行处理。
4. 缺陷分析：开发人员对缺陷进行分析，找出问题根源，并制定解决方案。
5. 缺陷修复：开发人员修改代码以修复缺陷，同时编写相应单元测试用例验证修复效果。
6. 回归测试：测试人员对已修复的缺陷进行重新测试，确保问题已被解决且未引入新的缺陷。
7. 关闭缺陷：若回归测试通过，则在缺陷跟踪系统中将该缺陷
状态更新为“已解决”或“已关闭”。
8. 持续监控：在整个周期内，项目管理团队需持续关注缺陷处理进度，并根据实际情况调整开发计划。
1.1转测质量1.1.1交付要求1.产品开发或修改准备提交测试版本在做转测试前需要开发设计工程师完成必要的自检并输出自测报告或调试报告2.产品开发版本必须满足各阶段测试输入质量要求，并在对其自检并输出自测报告或调试报告审核后给出结果;3.对于产品设计开发验证各阶段各类型缺陷Bug要求开发设计工程师必须给出明确清晰的问题分析原因和改善解决对策,并在Buglist和缺陷回馈体现！并自检其有效性！4.对于满足提交标准的测试版本必须在提交测试申请同时配备软/硬件程序版本配置清单说明！5.交付件必须完成过程审查与归档；1.1.2测试标准1.1.2.1测试开始准入标准1.首次测试准入标准:硬件环境可用并要求标准,软件正确安装且可执行；核心和关键业务功能100%实现;提供产品功能调试报告或自检报告;并配备软硬件程序配置清单；2.里程碑版本要满足阶段的质量要求。
里程碑版本必须提交调试报告；3.版本测试前需提交完整的产品软件包（不能是单个软件）4.版本软/硬件测试申请、程序配套表和系统配套表（配置清单）5.版本回归测试标准:致命缺陷修复率必须为100％，重要缺陷修复率不低于85％，缺陷总修复率必须不低于80％的情况下，才能提交新版本测试申请。
6.版本回归测试标准:对于提交的版本缺陷报告中的CRI、MAJ、MIN缺陷问题分析原因和改善解决对策描述不清晰或无描述;7.对于设计变更或缺陷修复后的验证版本需要提供必要的测试申请说明和操作步骤指导说明,包括:环境、条件、配置、步骤、方法、达成目标等.1.1.2.2测试中断标准1.测试环境无法达到标准或无法满足测试的一致性，安装无法正确完成;2.产品关键业务功能、性能、可靠性发现致命缺陷导致后续测试活动无法继续开展或测试结果不可靠；3.已修复致命缺陷重现和新发现的致命缺陷导致后续功能无法连续实现或后续测试用例无法实施或测试结果不可靠；4.对于提交的版本缺陷报告中的CRI、MAJ、MIN缺陷问题分析原因和改善解决对策描述不清晰或无描述；5.基本用例有缺陷，中断测试打回.1.1.2.3测试完成标准1.除因缺陷导致无法实施的测试用例之外，测试覆盖率达到95%；2.除因缺陷导致无法实施的测试用例之外，测试有效性和准确性评审达到95％；3.达到各阶段测试质量目标。
软件项目开发各阶段文档模板目录一、项目启动阶段 (3)1.1 项目立项报告模板 (4)1.2 项目计划书模板 (4)1.3 项目需求分析文档模板 (5)1.4 项目组织架构及人员分工模板 (6)1.5 项目风险评估与应对措施模板 (7)二、需求分析阶段 (8)2.1 需求分析报告模板 (8)2.2 需求规格说明书模板 (9)2.3 需求跟踪矩阵模板 (11)三、设计阶段 (12)3.1 概要设计文档模板 (13)3.2 详细设计文档模板 (16)3.3 接口设计文档模板 (17)3.4 数据库设计文档模板 (18)3.5 系统架构设计文档模板 (19)四、开发阶段 (20)4.1 编码规范与注释规范模板 (21)4.2 代码审查记录表单模板 (22)4.3 单元测试用例模板 (23)4.4 集成测试用例模板 (24)4.5 系统测试用例模板 (25)4.6 用户验收测试用例模板 (26)4.7 缺陷管理表格模板 (26)4.8 版本控制记录表单模板 (26)4.9 项目进度报告模板 (28)五、部署与上线阶段 (29)5.1 部署计划书模板 (30)5.2 系统安装部署脚本模板 (31)5.3 系统配置文件模板 (32)5.4 系统数据备份与恢复方案模板 (33)5.5 系统上线申请表单模板 (34)5.6 系统上线验收报告模板 (35)六、维护与升级阶段 (36)6.1 问题反馈与处理记录表单模板 (38)6.2 功能优化建议收集表单模板 (39)6.3 性能优化建议收集表单模板 (40)6.4 安全漏洞修复记录表单模板 (41)6.5 新功能需求调研报告模板 (42)6.6 系统升级计划书模板 (43)6.7 系统升级测试报告模板 (45)一、项目启动阶段在这一阶段，项目经理和团队需明确项目的目标、范围、预期成果以及关键利益相关方。
还需对项目的可行性进行评估，包括技术可行性、经济可行性和操作可行性。
