软件缺陷管理流程图
Bug状态流程
-Yang
Bug状态流程图 Bug状态流程图
Bug 处理流程
开发组长/ 开发组长/经理 每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产 每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产 品共同确定）。问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是 留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出 留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出 错的模块，进行代码审查。 开发人员 分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B Major类或紧急程度 分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B-Major类或紧急程度 3-High类以上（包含）bug5个或5个以上，停止新功能的开发。 High类以上（包含）bug5个或5 需求人员 解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计 解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计 划 测试人员 不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解 不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解 测试组长/ 测试组长/经理 审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测 审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测 趋势。在测试总结报告中给出意见 产品人员 可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺
新Bug 复测时新出现的Bug 偶发性 原来修改过的问题又重新出现 需求要求但没有做的功能 需求需要完善 与需求不一致 设计要求但没有做的功能
bug跟踪管理系统bug跟踪流程
bug跟踪管理系统 bug跟踪流程Bug跟踪流程1. 目的本文档主要是为了规范产品缺陷的跟踪解决、保证每个发现的缺陷都能有效跟踪，直到缺陷解决关闭。
2. 适用范围本文档适用于公司所有产品的缺陷跟踪。
需要测试、软件开发人员、硬件开发人员协调执行。
3. 角色和职责 3.1 测试工程师测试工程师负责问题提交、问题验证。
测试工程师不能把new状态、reopen状态的bug更改为fixed等其他状态。
测试工程师不能把没有修改的问题直接关闭。
测试工程师要及时验证问题，确保问题的及时关闭；如果验证不通过的问题要及时reopen，以便软件工程师能尽快了解情况，尽快解决问题。
3.2 开发工程师软、硬件工程师负责修改问题，在问题修改完把问题状态修改为fixed状态。
如果软、硬件工程师认为是非问题的，要及时和测试工程师讨论决定，如果不能形成一致意见的，可以上报上一级主管讨论。
如果经过讨论后一致认为不是问题的可以置为Invalid，或者确认是问题、讨论后决定不修改的问题可以置为wontfix, 然后由问题提交人关闭问题。
如果软、硬件工程师自己发现问题，原则上要求软、硬件工程师自己提交问题，把问题纳入跟踪。
软、硬件工程师不能关闭不是自己提交的问题。
3.3 缺陷库管理员缺陷库管理员一般由测试主管兼任，负责缺陷库的日常管理、维护。
在特殊情况下可以直接关闭部分问题（例如软件或硬件、测试一致同意关闭的问题）。
4. Bug跟踪流程流程图：过程说明：A．New bug：测试人员、市场反馈的问题由测试人员填写bug。
开发人员发现的问题由开发人员填写。
Bug填写完成后提交给相应的软、硬件开发人员。
Bug填写要求见“bug填写规范”。
B．Fix bug：开发人员修改自己负责的bug；修改完成并合入版本后把bug的状态修改成fixed。
C．Close bug：问题验证通过后，由问题提交人关闭bug。
D．Reopen：问题验证没有通过，发现问题还存在，或者问题只修改了一部分，则重新打开这个bug。
软件测试的5个基本流程图
软件测试的5个基本流程图软件测试是软件开发过程中至关重要的一环，可以帮助开发人员发现和解决潜在的问题和错误。
在进行软件测试时，遵循一定的流程和方法可以确保测试的有效性和可重复性。
本文将介绍软件测试的五个基本流程，并提供相应的流程图。
1. 需求分析和测试计划软件测试的第一个基本流程是需求分析和测试计划阶段。
在这个阶段中，测试团队与产品负责人合作，了解软件的需求和功能。
测试团队根据需求文档或者其他相关文档编写测试计划。
测试计划包括测试的范围、测试目标、测试策略、测试资源等内容。
流程图如下：graph TDA[需求分析和测试计划阶段]A --> B[了解软件的需求和功能]A --> C[编写测试计划]2. 测试设计和测试用例在需求分析和测试计划阶段完成后，测试团队开始进行测试设计和编写测试用例。
测试设计阶段包括根据需求和功能设计测试方案，确定测试的覆盖范围和测试的方法。
测试用例是测试工作的核心，它描述了不同场景下的输入、操作和预期的输出结果。
流程图如下：graph TDA[测试设计和测试用例阶段]A --> B[根据需求和功能设计测试方案]A --> C[编写测试用例]3. 环境准备和测试执行测试设计和测试用例阶段完成后，测试团队开始进行环境准备和测试执行。
环境准备阶段包括搭建测试环境、准备测试数据和测试工具等。
在测试执行阶段，测试团队根据测试计划和测试用例执行测试，记录测试结果，并将测试结果进行整理和分析。
流程图如下：graph TDA[环境准备和测试执行阶段]A --> B[搭建测试环境]A --> C[准备测试数据和测试工具]A --> D[执行测试]A --> E[记录测试结果]A --> F[整理和分析测试结果]4. 缺陷管理和缺陷修复在测试执行阶段，测试团队可能会发现软件中的缺陷或问题。
在这个阶段，测试团队需要进行缺陷管理和缺陷修复。
缺陷管理包括缺陷的提交、缺陷的跟踪和缺陷的验证。
(完整版)Bug(缺陷管理)需求规格说明书
需求规格说明书1. 引言1.1编写目的软件缺陷跟踪管理系统在现代软件开发中已经占据了很重要的位置。
每一个软件组织都知道必须妥善处理软件中的缺陷，这是关系到软件组织生存、发展的质量根本。
所以我们要熟悉了解软件跟踪管理系统的基本流程。
1.2项目背景软件名称：软件缺陷跟踪管理系统软件。
1.3定义软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误，将直接影响到测试的效果。
只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。
在实际软件测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。
为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录输入制定的错误跟踪管理系统。
作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的处理信息的全部内容。
字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附图，测试注释。
处理信息包括处理者姓名，处理时间，处理步骤，处理意见，错误记录的当前状态。
缺陷就是：不满足用户确定的需求；软件使用当中出现的问题；不符合设计要求。
2．任务概述2.1缺陷管理的目标（1）确保被发现的缺陷能够被解决；这里解决的意思不一定是被修正，也可能是其他处理方式（例如，在下一个版本中修正或是不修正），总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致；（2）收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段；决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式；（3）收集缺陷数据并在其上进行数据分析，作为组织的过程财富。
2.2 缺陷管理的一般流程缺陷信息提交后，会进行分配，进入待修正状态。
通常情况下，被分配的开发人员会负责对它进行修复。
软件质量管理流程
软件质量管理流程一、需求分析需求分析是软件质量管理的起始点。
在这个阶段，我们需要明确软件的目标和用户需求，通过与用户沟通和专家评估，对系统的功能、性能、安全性、易用性等方面进行需求分析和定义。
需求分析的质量直接影响到整个软件项目的质量和成功。
二、设计阶段在设计阶段，根据需求分析的结果，对系统进行整体架构设计和模块设计。
设计阶段的任务包括选择合适的设计方法、设计原则和设计模式，确定系统的结构、模块的划分、功能的实现等。
设计阶段的输出是详细的设计文档和数据流程图等。
三、编码阶段编码阶段是根据设计文档和数据流程图，将系统实现为代码的过程。
在这个阶段，我们需要注意代码的编写规范、代码的可读性、代码的注释、代码的性能和安全性等方面。
编码阶段的输出是源代码和相关的文档。
四、测试阶段测试阶段是对编码完成的系统进行各种测试的过程。
包括单元测试、集成测试、系统测试、验收测试等。
测试阶段的任务是发现和排除系统中的错误和缺陷，确保系统的质量达到预期的要求。
测试阶段的输出是测试报告和缺陷报告。
五、发布阶段发布阶段是将测试通过的系统发布给用户的过程。
在这个阶段，我们需要对系统进行部署、安装、配置，并进行用户培训和文档编写等工作。
发布阶段的输出是安装包、用户手册、操作指南等。
六、维护阶段维护阶段是对已经发布的系统进行维护和更新的过程。
包括系统升级、故障修复、安全维护等工作。
维护阶段的输出是维护记录和升级计划等。
七、配置管理配置管理是对软件产品的版本、文档、数据等进行管理和控制的过程。
配置管理的主要目的是确保软件产品的完整性和一致性，同时方便开发人员和管理人员对软件产品的状态进行跟踪和控制。
配置管理的输出是配置管理计划、配置管理记录等。
八、质量保证质量保证是确保软件质量符合预期要求的过程。
这个过程包括对各个阶段的输出进行审查和评估，以及对各个阶段的工作流程进行监督和管理。
质量保证的目的是尽早发现和解决潜在的质量问题，从而避免在项目后期出现严重的问题。
缺陷处理流程
缺陷处理流程1缺陷处理流程1.缺陷处理流程图如下：2.缺陷处理流程图中判定说明：1)是否打开缺陷：开发组长/经理查阅缺陷，确认为缺陷后，指定优先级、估计修复日期再指派给相关开发人员；如果确认为不是缺陷的，注释中说明理由，予以否决。
2)处理缺陷：开发处理缺陷；如果缺陷短期内进行修复存在困难，且该缺陷对于功能实现影响不大的，应该给开发组长/经理说明情况，让开发组长/经理与缺陷相关人员协调后延期处理该缺陷，并在注释中说明理由，估计修复日期和指明计划关闭版本。
3)是否关闭：测试人员对回归通过的缺陷进行关闭；否则重新打开缺陷。
并在注释中说明重新打开理由。
3.缺陷处理流程图中流程说明：1)新建缺陷：测试人员（其他人员）根据缺陷填写说明，新建缺陷。
2)已否决：对已否决的缺陷，最后由测试发起会议（形式可以根据情况而定），找到缺陷相关人员进行确认。
如果确认为是无效的缺陷，保持“已否决”状态，否则重新打开缺陷，并指派给相关处理人员。
3)（重新）打开：开发人员应该处理自己手上“打开”和“重新打开”的缺陷。
4)延期处理：开发组长/经理根据情况，对缺陷进行延期处理。
5)已经修复：开发人员处理完缺陷后，把缺陷状态改为“已修复”状态。
并通知测试人员进行回归。
6)回归测试：测试人员对已经修复的缺陷进行回归。
7)关闭缺陷：测试人员回归测试通过后，对缺陷进行关闭。
4.为了说明各个角色在缺陷处理流程中的职责，据测试流程所画泳道图如下：如果上面判定和流程中，某一方存在异议的，应及时反馈上级。
然后上级根据缺陷优先级、实际情况等，找恰当的时间发起会议（或其他）的方式找到缺陷相关人员进行沟通、协调和处理。
2缺陷填写说明1.BUG全部提交到QC中（指定域名的指定项目下）。
2.“摘要”，用简单明了的语句说明白你这个BUG，相当于BUG的中心语句。
3.详细信息填写规范：1)“分配给”，选择这个BUG所属模块是属于那个研发人员，并把问题指派给他（如果不知道，就直接提交给该负责人）。
软件项目缺陷跟踪和持续改进
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.达到各阶段测试质量目标。
缺陷管理工具JIRA基本使用培训手册
JIRA 培训手册（缺陷跟踪管理流程）引言：为了提高软件开发日常中的工作效率，增进开发人员与项目经理、测试人员等的沟通频率，引入JIRA项目管理与缺陷跟踪管理工具。
本篇意在阐述JIRA在缺陷跟踪管理中的运用。
目录第一章何为JIRA？ (3)1.1JIRA的简介 (3)1.2JIRA的特性 (3)第二章JIRA的应用配置 (6)2.1用户组及人员的创建 (6)2.2权限配置 (8)2.2.1全局权限 (8)2.2.2权限方案 (8)2.2.3工作流中执行固定操作的权限 (9)2.3工作流配置 (10)第三章具体操作 (12)3.1工作流程图 (12)3.2详细操作流程 (13)3.3批量操作及查找 (21)第四章结束语 (25)第一章何为JIRA ?1.1 JIRA的简介JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。
JIRA中配置灵活、功能全面、部署简单、扩展丰富，其超过150项特性得到了全球115个国家超过19,000家客户的认可。
L.. Atlassian&JIRA1.2 JIRA的特性工作流*开箱即用，提供用于缺陷管理的默认工作流工作流可以自定义，工作流数量不限•每个工作流可以配置多个自定义动作和自定义状态*每一个问题类型都可以单独设置或共用工作流*可视化工作流设计器，使工作流配置更加直观*自定义工作流动作的触发条件*工作流动作执行后，自动执行指定的操作项目•每个项目都有自己的概览页面包括：项目详细信息、最新更新情况以及一些报告的快捷方式•在项目界面中查看按照状态、是否解决等条件设置的分类统计报告•查看项目最新的活动情况•查看项目的热门问题•可以设置项目类别，将项目分组管理・可以为每个项目设置单独的邮件通知发件地址・自定义安全级别，指定用户对问题的访问•指定组件/模块负责人问题管理•自定义问题类型，适应组织管理的需要•自定义字段，可选择字段类型超过20种，在此基础上还支持插件进一步扩展*自定义问题安全级别，可以限制指定用户访问指定的问题*如果多个问题需要同时修改同一字段值或执行同一工作流动作，你可以使用批量操作功能一次性完成•登记问题预计完成时间、实际工作时间，就可以了解该问题预计还剩多长时间才能解决。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件缺陷管理办法
1.目的
本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性，以保证项目研发质量。
2.适用范围
适用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规范。
3.定义
3.1 术语
缺陷（Defect）：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。
Bug：缺陷一种表现形态，系统或程序存在的任何一种破坏正常运转能力的问题。
3.2 缺陷定义
（1）软件未达到需求规格说明书的功能；
（2）软件出现了需求规格说明书指明不会出现的错误；
（3）软件功能超出需求规格说明书的范围；
（4）软件未达到需求规格说明书未指出但应达到的目标；
（5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。
4.缺陷生命周期
4.1 缺陷生命周期图
4.2 缺陷状态说明
5. 缺陷处理过程
5.1 正常处理过程
（1）创建问题
在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。
创建问题时，需要描述清楚，并选择正确的选项，详细请参考5.4和5.5。
（2）指派问题
创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。
如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。
（3）确认问题
通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。
如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。
当创建者收到确认指派时，需要进行及时确认。
如果同意为非bug，则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。
如果问题确认指派次数大于6次时，需要进入“争议处理”流程，详细请参考5.2。
（4）解决问题
此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。
开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，解决方案规则请参考5.4中解决方案定义部分，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。
如果Bug无法解决或修改影响比较大，可申请进入“延期解决”流程，请参考5.2中延期处理部分。
（5）验证问题
创建者需要及时对解决状态的Bug在对应版本上面进行验证。
如果验证通过，则可关闭Bug；如果验证不通过，则激活此Bug，系统将自动指派回给解决者。
验证通过准则：相同的操作步骤，进行一定次数的验证测试都没有发生。
验证不通过准则：相同的操作步骤，全部或部分实际结果还会发生，验证不通过则激活Bug。
(6) 关闭问题
通过验证的Bug，验证者需要注明验证结果并进行关闭操作，系统将指派给Closed。
如果关闭状态的Bug在之后版本又会发生，则激活此Bug，系统将自动指派回给解决者。
5.2 特别处理过程
(1) 客户问题
客户反馈的问题可以由客户直接反馈或项目经理、市场部等了解到的客户问题，经确认后的Bug提交到测试管理系统，按照以上处理流程进行处理，由创建者或测试组进行跟踪验证关闭。
创建客户问题时，创建者需要在Bug标题开头标记为[客户问题]，测试组负责检查和更正。
(2) 争议处理
当开发和测试工程师对某问题有争议并且多次沟通无果时（暂定为6次），可以注明双方的理由，并指派给项目经理进行处理。
项目经理可以召开评审会议，或者直接与双方沟通了解，并根据项目情况给出专业意见和最终决定。
开发和测试工程师根据项目经理的最终决定执行。
(3) 延期解决
当开发工程师对确认Bug进行解决时，发现或评估其解决时间紧或风险比
较大等，可以说明原因或理由并指派给项目经理来确认。
项目经理可以召开评审会议，或者直接沟通了解，并根据项目情况给出最终决定。
如果不同意，项目经理将此Bug指派回开发工程师，开发工程师继续分析和解决。
如果同意，项目经理需要在Bug标题开头标记为[延期解决]和在处理状态选择“延期解决”，然后注明解决时间计划并指派回开发工程师，开发工程师根据解决时间计划来规划和解决此Bug。
5.3 缺陷管理工具
软件测试过程中所有缺陷要提交到公司测试管理系统进行跟踪管理。
(1)管理工具的作用
a.确保每个被发现的缺陷都能够被跟踪与处理。
b.收集缺陷数据并根据缺陷趋势曲线识别或报告测试状态。
c.收集缺陷数据并在其上进行数据分析，作为测试评估的依据。
（2）缺陷驱动原则
缺陷管理系统主要通过指派状态来驱动相关开发工程师、测试工程师和项目经理尽快地处理问题，以提高研发效率，所以会特别关注缺陷指派给谁和停留时间，并反馈在定期报告。
所以，缺陷驱动原则：尽量不要让缺陷挂在你身上。
5.4. 缺陷属性定义
(1) 缺陷相关属性
(2)缺陷类型说明
(3) 严重程度定义
注：严重等级由创建者在创建缺陷时根据此定义来选择，之后都不能随意更
改。
(5) 优先级的定义
注：立刻、紧急、尽快的问题都要求在系统上线前解决。
(6)发生概率定义
(7)处理状态说明
(8) 解决方案定义与规则
注：无法复现问题将作为风险评估点。
5.5 缺陷描述规范
（1）缺陷标题
缺陷标题是对所提交缺陷的概述，需要简短而准确的描述出缺陷概要信息，并使用一些精炼的关键词，主要内容包括：位置+对象+动作+现象。
a.环境关键词：包括数据环境，时间环境，地点环境条件环境，描述缺
陷发生时所处的背景环境，或正在执行的操作或所处的界面环境，如
“在…”页面，“当…时…”，“在…过程中…”等；
b.动作关键词：引发缺陷所执行的操作，如“点…键”“选…选项”等；
c.对象的关键词：描述缺陷出现的对象，“页面”，“显示框”，“图表”等；
d.现象的关键词：描述缺陷出现的现象，如“显示为负数”，“卡死”等。
根据上述关键词的组合来描写缺陷标题。
（2）重现步骤
在描述缺陷重现步骤的过程中，通常需要通过描述前提条件，测试步骤，实际结果，期望结果这四个方面清楚详细的描述缺陷。
a.前提条件
外部环境，这里包括网络环境，硬件环境和软件环境的状态。
默认情况下，无需特殊说明，前提条件均为“系统正常运行”，其含义为网络正常，电脑硬件
环境能支撑软件运行，系统软件配置情况正常。
需要注意，软件环境有可能引
发缺陷的功能模块所处的状态，以及重现该缺陷需要的模块相关状态或者特殊
设置情况应该前在前提条件中做说明。
数据环境，对缺陷产生的所在案件或引发bug现象的数据输入和数据设计
等应该在前提条件中做相应说明。
总之，这里对缺陷现象重现紧密相关的预先设置，或与缺陷模块相关联的
预先设置都应该在前提条件中说明。
b.测试步骤
这里需要详细描述出重现缺陷的操作步骤，以便于重现缺陷，修复和验证
缺陷。
在描写测试步骤时应该注意以下几点：
精简：只描述缺陷必须的细节；
单一：每个缺陷单只报告一个缺陷；
步骤清晰：详细的、有序的描述出每一个步骤，包括输入的数据情况，执
行的操作以及执行操作的界面。
操作量化：对操作次数的描述需要量化，如“连续3次点确认键”等，尽量避
免出现“多次”等模糊的词。
c.实际结果
实际结果是指按照测试步骤操作后实际反映的情况，这里指的是缺陷的表现现象。
这里应该详细描述出错误的现象，包括页面错误，连接错误，字符错误，业务流程错误，数据错误等。
d.期望结果
期望结果是指按照测试步骤操作，正常情况下正确执行测试步骤后应该满足设计要求的结果。
对于不确定的期望结果就需要用到如建议，提示等关键字。
（3）附件
为了方便开发工程师分析和解决，创建缺陷时需要添加必要的附件，包括缺陷现象图、测试的数据文档，测试时用到的其他特殊文件，测试脚本，操作步骤的录像等。
所以，测试人员在测试的过程中，要求每个缺陷有现象截图，以便协助开发人员快速定位问题。