测试体系建设与软件测试流程
测试体系的建立
对bug进行处理的人员有测试人员和开发人员，职 责简要说明如下：
测试人员：新增bug，并对修复的bug进行验证， 关闭已修复的bug；
开发人员：确认bug，并对bug进行修复。
h
19
测试体系介绍——缺陷管理
测试人员
开始
缺
陷
新增bug
管
理
激活bug
流
N
程
验证
图
bug
Y
关闭bug
开发人员
确认 bug
Y
实例演示
h
自动化测试
22
测试体系建立的可行性
这样执行的必要性 大家有什么意见或建议？
h
23
存在的不足及展望
自动化
测试内 部存在 的不足
安全性
性能
h
24
一
二 项目流 程存在 三 的不足
四
五
存在的不足及展望
h
25
存在的不足及展望
实现功能自动化测试
测试流程规范化，促进项目流程的规范化
展
使用安全性测试工具进行安全性测试
h
11
测试体系介绍——测试流程
（接上页）
执行测试用
不 通
回归例测试
过
新 系不
通
统过 不
（功能、安 全性测试） 性能测试
测通 过
试 流
回归测试（性能 测试）
程
出厂测试
图
系统测试
报告
版本发
布
h
根据测试计划，来分配测试小组的成员 执行测试用例
在功能、安全性测试完成之后，则需要 进行回归测试，直到通过该项目测试指
说明书
根据最终的需求规格说明书以及项目开 发计划书编写测试计划，由测试小组编
软件测试过程流程
软件测试过程流程⼀、软件测试的系统流程 软件⼯程模型基本就是业务建模-〉系统分析-〉概要设计-〉详细设计-〉编码-〉测试-〉部署。
其中测试过程按4个步骤进⾏，即单元测试、集成测试、系统及发版测试和回归测试。
(1)单元测试，集中对每⼀个程序单元进⾏测试，检查各个程序模块是否正确地实现了预定的功能，属于⽩盒测试，测试范围为单元内部的源代码和程序结构(如数据结构，逻辑控制，异常处理等)。
(2)集成测试把已测试过的模块组装起来，检查模块间接⼝是否正确，检查各个模块之间的通信和相互调⽤是否符合需求。
属于灰盒测试，测试范围为模块接⼝之间的数据传递，以及模块组合后的功能。
(3)系统测试把被测软件系统和计算机硬件、数据库、外设、前端和后端以及其它软件结合在⼀起，在实际运⾏环境下对软件系统进⾏⼀系列的组装测试和运⾏测试。
⽬的在于检测软件对《需求规格说明书》的符合程度。
属于⿊盒测试，只关⼼输⼊和输出结果，测试范围为整个系统。
(4)回归测试：是软件上线后的维护阶段或者是研发修复Bug之后进⾏确认测试。
⽬的在于验证缺陷已经得到修复，并检测是否引⼊新的缺陷。
⼆、测试⽤例及编写⽅法 测试⽤例是⼀份描述具体测试步骤的⽂档，包括测试的输⼊参数、条件及配置、预期的输出结果等，⽤以判断被测软件的⼯作是否正常。
2.1、测试⽤例设计的三⼤原则 (1)设计测试⽤例要⼒求最⼤的覆盖率，参考《需求规格说明书》对每个功能点进⾏操作上的细化，尽可能趋向最⼤需求覆盖率。
(2)⽤例要对测试功能点、测试条件、测试步骤、输⼊值和预期结果准确描述。
(3)在设计测试⽤例的时候，除了满⾜系统基本功能需求外，还应该考虑各种异常情况、边界情况和承受压⼒的能⼒等。
2.2、设计测试⽤例设计⽅法 设计测试⽤例时要根据具体的产品和需求所明书，⽐如NetSignC接⼝普遍得就是根据输⼊和输出参数的不同情况设计⽤例，但也有通⽤的情况。
(1)等价类划分。
把程序的输⼊域划分成若⼲部分⼦集，然后从每个部分中选取少数代表性数据作为测试⽤例。
软件测试的5个基本流程
软件测试的5个基本流程
软件测试工作流程：
1、需求分析、需求评审
需求分析和评审就是分析客户的需求是否可行，如何测试。
2、编写测试计划
写测试计划，通俗地说就是人在什么时候做什么，最后产生什么东西。
也就是说测试人员要测试哪些模块，在什么时限内，提交哪些文档。
3、编写测试用例、用例评审
测试用例是指导测试的文档。
比如我们需要测试商城登录和购物的功能，通过测试方法和策略设计测试用例。
复习就是评价性复习，怎么衡量都不能想当然。
你不能只输入正确的用户名和密码，只要登录就结束了。
做一个软测试工程师需要有破坏性，比如密码输入错误怎么办，会不会出现相应的错误等等。
4、执行测试、提交bug、回归测试
Bug就是缺陷，发现bug之后，要提交给开发人员让他们去修改，然后进行回归测试，验证开发人员有没有改好。
5、编写测试总结报告
Bug都改好了之后，要编写测试总结报告，这款软件的质量如何。
软件测试基本流程与规范
软件测试基本流程与规范1目标制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。
最终目标是实现软件测试规范化，标准化。
2测试流程说明3测试需求分析测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。
用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。
而且被确定的测试需求项必须是可核实的。
即，它们必须有一个可观察、可评测的结果。
无法核实的需求不是测试需求。
所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他.·测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据；·测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例；·测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖；3.1测试方法与规范3.1.1测试方法随着软件技术发展，项目类型越来越多样化。
根据项目类型应选用针对性强的测试方法，合适的测试方法可以让我们事半功倍。
以下是针对目前项目工程可以参考的测试方法：•β测试（beta测试）--非程序员、测试人员β测试，英文是Beta testing。
又称Beta测试，用户验收测试（UAT）。
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。
开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。
当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。
这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。
•α测试（Alpha测试）--非程序员、测试人员α测试，英文是Alpha testing。
又称Alpha测试.Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。
软件测试的流程是什么
软件测试的流程是什么软件测试是一种系统性和科学性的活动，主要用于检查和评估软件的质量和可靠性。
测试过程包括以下几个主要步骤：需求分析，测试计划制定，测试用例设计，测试执行和测试结果评估。
下面将详细介绍测试的流程。
1. 需求分析需求分析是软件测试过程的第一步，因为它决定了接下来测试工作的方向和重点。
在这个阶段，测试人员需要仔细的分析客户需求和功能规范，并与开发人员沟通以确保应用程序设计的准确性和完整性。
在需求分析阶段，测试人员需要识别潜在问题和矛盾，并对测试计划进行必要的修改和调整。
2. 测试计划制定测试计划是软件测试的第二步，目的是为了规划未来所有测试工作的步骤和方法。
制定测试计划的过程中，测试团队需要考虑预算、人员、设备和测试时间等因素，然后确定测试的范围和测试级别。
测试团队还需要开始编写测试文档，包括测试用例、测试报告，以及其他相关的测试文档。
3. 测试用例设计测试用例设计是测试过程的一个重要步骤，在这个阶段中，测试团队需要设计不同的测试用例，用以评估应用程序的不同方面。
测试用例的设计过程中，测试人员需要确定应用程序的所有功能并识别它们的界限。
通过设计测试用例，测试人员能够确保对应用程序的全部覆盖。
4. 测试执行在测试执行阶段中，测试团队按照测试计划开始对软件进行测试。
测试执行阶段是测试过程中最复杂和最重要的一个阶段。
测试团队必须严格按照制定的测试计划进行测试，并验证软件是否具有所需的性能和功能。
测试人员将执行测试用例，并记录测试结果以供进一步评估。
5. 测试结果评估测试结果评估是软件测试过程中的最后一步，目的是针对测试过程中发现的缺陷和问题进行分析和评估。
在这个阶段，测试人员必须检查测试结果并根据不同情况编写测试报告。
在完成测试之后，测试人员将与开发人员沟通交流所有问题，并等待问题解决的反馈。
总之，软件测试流程是一个迭代性的过程，需要不断地重复执行，并及时重新评估各种工作。
如果需要发现更多问题和缺陷，测试过程就必须合理且不断更新和改善，以确保软件质量和安全性。
软件测试的流程与规范
软件测试的流程与规范软件测试是确保软件质量的关键环节，它通过检查和验证软件系统的各个方面，以确保软件满足用户需求并具备高度稳定性和可靠性。
为了有效地执行软件测试工作，有必要遵循一定的流程和规范。
本文将探讨软件测试的基本流程与相关规范。
一、需求分析与测试计划在进行软件测试之前，首先需要进行需求分析。
测试团队与业务团队密切合作，详细了解用户需求，明确软件系统的功能和性能要求。
在此基础上，制定详细的测试计划，包括测试范围、测试目标、测试环境、测试资源等。
二、测试用例设计测试用例是软件测试的核心，用于描述测试的输入、预期输出和预期行为。
测试团队需要根据需求分析，设计一组全面且有效的测试用例，以覆盖各个功能模块和不同的测试场景。
合适的测试用例能够最大程度地发现潜在的缺陷和问题。
三、测试环境搭建与配置为了进行测试工作，需要搭建适当的测试环境。
测试环境应该模拟真实的生产环境，包括硬件设备、操作系统、数据库等。
此外，根据测试需求，还需要安装和配置相关的测试工具和测试框架，确保能够有效地进行测试执行和结果分析。
四、执行测试用例在测试环境搭建完成后，测试团队可以开始执行测试用例。
测试人员需要按照测试计划和测试用例的要求，逐一执行测试用例，记录测试过程中的输入、输出和日志等信息。
在执行测试用例的过程中，应注意记录和整理发现的问题，形成缺陷报告并及时反馈给开发团队。
五、缺陷管理与追踪测试过程中会发现一些缺陷和问题，这些问题需要及时记录、管理和追踪。
测试团队应建立完善的缺陷管理系统，对发现的缺陷进行分类、分级和跟踪。
同时，测试人员需要与开发团队密切合作，确保及时修复和验证缺陷，并更新缺陷状态和测试进度。
六、测试报告与评估测试结束后，测试团队需要撰写测试报告，对测试过程和结果进行总结和评估。
测试报告应包括测试目标的实现情况、测试执行的覆盖率和通过率、发现的缺陷数量和严重程度等。
根据测试报告，可以评估软件的质量和稳定性，并提出改进和优化措施。
软件测试的基本流程和方法
软件测试的基本流程和方法软件测试是指在软件开发中，对软件系统进行验证和评估的过程，旨在保证软件产品的质量，增强软件的可靠性和稳定性，同时降低软件出现问题的可能性。
软件测试是软件开发过程中不可或缺的一环，其基本流程和方法对于软件开发人员来说是必须掌握的。
一、软件测试基本流程软件测试的基本流程包括：计划测试、设计测试用例、执行测试、评估测试结果、修改缺陷和最终报告。
具体如下：1.计划测试：首先需制定测试计划，主要包括确定测试目标和测试策略，确定测试用例设计方法和评估测试结果的标准等。
这一步对于测试的执行非常重要，测试计划应该非常清晰明确。
2.建立测试环境：在具备测试资料和测试场所的情况下，需要为测试建立测试环境，如测试服务器，虚拟机等。
测试环境应该与生产环境尽量相同，尤其是对于系统硬件、操作系统、数据库等基础组件需要尽量相同。
3.测试用例设计：设计测试用例，以验证系统的不同功能点和模块。
测试用例应该覆盖到所有功能点。
更进一步的，测试用例应该包括正常流程、异常处理和边缘情况等。
4.执行测试：根据设计的测试用例逐一执行测试，并在测试过程中记录测试结果。
在测试执行过程中，需要提供足够的信息让开发人员能够定位、并修复缺陷，这是测试执行过程的最终目标。
5.测试结果评估：测试结果需要一一评估。
测试评估基于事先定义的测试标准，以及软件系统的业务规则。
测试结果有必要进行分类处理，统计已发现的缺陷总量、严重性、频率等，并与预期结果进行比较并进行归类。
6.修改缺陷：测试结果的评估后，需将已发现的缺陷陈述清楚，把测试者从测试报告中提供的具体的问题记录下来。
开发人员严格按照这些记录，修复缺陷。
7.最终报告：在软件缺陷修复完毕后，需要就测试结果进行整理，形成测试报告。
测试报告需要包括测试计划、测试用例、测试结果、缺陷清单等内容，便于工作记录。
二、软件测试的基本方法软件测试的基本方法包括：手工测试、自动化测试等。
1.手工测试：在软件测试过程中，手工测试是最常用的测试方法。
软件测试的基本流程
软件测试的基本流程软件测试的基本流程软件测试和软件开发⼀样，是⼀个⽐较复杂的⼯作过程，如果⽆章法可循，随意进⾏测试势必会造成测试⼯作的混乱。
为了使测试⼯作标准化、规范化，并且快速、⾼效、⾼质量的完成测试⼯作，需要制订完整且具体的测试流程。
软件测试的流程不同类型的软件产品测试的⽅式和重点不⼀样，测试流程也会不⼀样。
同样类型的软件产品，不同公司所指定的测试流程也会不⼀样。
虽然不同软件的详细测试步骤不同，但它们所遵循的最基本的测试流程是⼀样的：分析测试需求-制定测试计划-设计测试⽤例-执⾏测试-编写测试报告。
下⾯对软件测试基本流程进⾏简单介绍。
（1）分析测试需求测试⼈员在制订测试计划之前需要先对软件需求进⾏分析，以便对要开发的软件产品有个清晰的⼈认识，从⽽明确测试对象及测试⼯作的范围和测试重点。
在分析测试需求时还可以获取⼀些测试数据，作为测试计划的基本依据，为后续的测试打好基础。
测试需求分析其实也就是对软件需求进⾏测试，测试⼈员可以发现软件需求中不合理的地⽅，如需求描述是否完整，准确⽆歧义，需求优先级安排是否合理等。
测试⼈员⼀般会根据软件开发需求⽂档制作⼀个软件需求规格说明书检查列表，按照各个检查项对软件需求进⾏分析校验如图所⽰上表列出了需要对软件需求进⾏什么样的检查，测试⼈员按照检查项逐条检查和判断，如果满⾜要求则选择【是】，如果不满⾜要求则选择【否】，如果某个检查项不适⽤则选择【NA】。
表1-3只是⼀个通⽤的软件需求规格说明检查列表，在实际测试中，要根据具体的测试项⽬进⾏适当的增减或修改。
在分析测试需求时要注意，被确定的测试需求必须是可核实的，测试需求必须有⼀个可观察，可评测的结果。
⽆法核实的需求就不是测试需求。
测试需求分析还要和客户进⾏交流，以澄清某些混淆，确保测试⼈员与客户尽早地对项⽬达成共识。
（2）指定测试计划测试⼯作贯穿于整个软件开发⽣命周期，是⼀项庞⼤⽽复杂地⼯作，需要制定⼀个完整且详细地测试计划作为指导。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
测试体系建设与软件测试流程（初稿）江苏物合智联科技有限公司修改历史正式批准目录1.目的 (4)2.范围 (5)3.测试过程描述 (6)3.1 测试流程图 (6)3.2 活动说明 (7)3.2.1 需求评审 (7)3.2.2 测试计划 (8)3.2.3 测试设计 (9)3.2.4 功能测试执行 (11)3.2.5集成/性能测试设计 (12)3.2.6集成测试/性能测试 (14)3.2.7 文档测试 (16)3.2.8 测试报告 (17)4.缺陷管理 (19)4.1 概述 (19)4.1.1 编写目的 (19)4.1.2 适用范围 (19)4.1.3 角色和职责 (19)4.1.4 名词解释 (19)4.2 缺陷状态关系示意图 (20)4.3 缺陷流转的过程及处理 (20)4.4 缺陷页面部分字段详解 (21)5.配置管理 (23)6.人员培养 (24)1.目的本文是对项目软件测试的指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程及测试过程中涉及到的角色职责进行总体规范，以有效保证软件质量。
2.范围本文适用于所有软件测试人员。
3.测试过程描述3.1 测试流程图3.2 活动说明3.2.1 需求评审3.2.1.1目的从源头把握软件质量，并确保开发结果与实际需求相一致3.2.1.2角色与职责需求人员：《需求规格说明书》的编写，以及软件开发过程中《需求规格说明书》的修正；评审人员：评审《需求规格说明书》，从全面性、完整性、正确性、一致性、可靠性方面检、查《需求规格说明书》，将需求缺陷提交给需求人员，并跟踪需求缺陷直至需求缺陷验证关闭。
3.2.1.3启动标准《软件需求规格说明书SRS》编写完成3.2.1.4工作流程图3.2.1.5输入/输出输入：《需求规格说明书》输出：需求缺陷3.2.2 测试计划3.2.2.1目的明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制；保持测试过程的顺畅，有效控制和跟踪测试进度，应对测试过程中的各种变更。
3.2.2.2角色与职责测试负责人：根据《软件开发计划》、《需求规格说明书》编制《测试计划》，明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制，以便测试工作正常开展，测试计划实际编写内容参见《项目测试计划模版》。
3.2.2.3启动标准需求评审完成，《项目整体计划》编制完成。
3.2.2.4工作流程图3.2.2.5输入/输出输入：《软件需求规格说明书》、《软件开发计划》输出：《测试计划》、《测试方案》3.2.3测试设计3.2.3.1目的通过多种测试方法编写测试用例，以使最少的测试用例，实现最大的测试覆盖，保证软件功能的正确性，从而提升软件质量。
3.2.3.2角色和职责测试人员：采用多种测试方法编写有效的测试用例，并对遗漏/错误的测试用例进行修正。
评审人员：对测试人员编写的测试用例进行评审，提出遗漏/错误的用例缺陷，并跟踪直至用例缺陷的验证关闭。
3.2.3.3启动标准需求文档评审完成且测试计划制定完成3.2.3.4工作流程图3.2.3.5输入输出输入：《软件需求规格说明书》、《测试计划》、《测试方案》输出：《测试用例》、测试用例评审缺陷3.2.4 功能测试执行3.2.4.1目的依据测试计划，按照测试用例对软件进行测试，验证软件功能与需求的实际匹配程度。
3.2.4.2角色与职责测试人员：依据测试计划，按照测试用例对软件功能进行测试。
对于发现的缺陷必须记录，并且跟踪缺陷的状态，直至缺陷的验证关闭。
在测试执行过程中发现的遗漏测试用例必须补充至测试用例，保证测试用例与实际测试的一致性。
开发人员：对于测试人员提交的缺陷进行确认、修复。
开发经理：对测试人员与实际开发人员意见不一的问题进行裁决。
3.2.4.3启动标准测试用例编写完成且用例评审完成3.2.4.4工作流程图3.2.4.5输入输出输入：功能测试用例输出：功能测试报告，缺陷报告单3.2.5集成/性能测试设计3.2.5.1目的为集成测试提供测试依据，记录并保证集成测试覆盖度；依据《测试计划》及性能指标制定性能测试计划、性能测试用例设计、性能测试脚本开发，保证性能测试有序进行。
3.2.5.2角色和职责测试人员：以整个软件为对象，确保新功能、老功能、新老功能接口正确进行用例设计；依据性能指标及测试计划对性能测试进行计划、以及性能测试用例/脚本的开发。
3.2.5.3启动标准功能测试完成且软件功能无中断3.2.5.4工作流程图3.2.5.5输入输出输入：《功能测试用例》、功能测试缺陷、《测试计划》、性能指标输出：《集成测试用例》、《性能测试计划》、《性能测试用例》、性能测试脚本3.2.6集成测试/性能测试3.2.6.1目的以整个软件为对象，以测试计划为指导，按照集成测试测试用例对新功能、老功能、新老功能接口进行测试和性能测试，保证测试的全面性和完整性。
3.2.6.2角色和职责测试人员：以整个软件为对象，以测试计划为指导，按照集成测试测试用例对新功能、老功能、新老功能接口进行测试，并依据性能测试计划对软件性能进行测试。
3.2.6.3启动标准集成/性能测试设计完成3.2.6.4工作流程图3.2.6.5输入输出输入：《集成测试用例》、《测试计划》之集成测试事项、《性能测试计划》、《性能测试用例》输出：集成测试缺陷3.2.7 文档测试3.2.7.1目的保证对客户的指导与实际系统的使用状况相一致。
3.2.7.2角色和职责测试人员：对《用户操作手册》及在线帮助进行测试，记录文档描述缺陷，并跟踪直至缺陷的验证关闭。
需求人员：对测试人员提出的文档描述缺陷进行修正。
3.2.7.3启动标准《用户操作手册》或在线帮助编写完成3.2.7.4工作流程图3.2.7.5输入输出输入：《用户操作手册》、在线帮助输出：文档缺陷3.2.8 测试报告3.2.8.1目的真实、客观反映测试过程中各测试阶段、测试项的情况，并将结果进行数字化/图像化进行分析，真实反映软件质量实际情况。
3.2.8.2角色与职责测试负责人：真实、客观地对测试过程中各测试阶段、测试项的情况，并以数字/图像的形式对实际情况进行分析，真实反映软件实际测试状况。
3.2.8.3启动标准集成测试完成3.2.8.4工作流程图3.2.8.5输入输出输入：各测试阶段、测试项实际测试情况输出：《项目测试报告》4.缺陷管理4.1 概述4.1.1 编写目的为规范QC的合理使用，方便各项目组管理测试过程，测试管理人员正确使用QC而编写。
4.1.2 适用范围适用于功能测试有关工作，功能测试中的缺陷要求全部采用QC进行管理。
4.1.3 角色和职责4.1.4 名词解释QC：QC（Quality Center），也被称为MQC（Mercury Quality Center）。
不仅可以在一个项目组内进行质量控制和管理，也可以在跨地域的不同项目组内部进行质量控制和管理，从而可以保证应用系统的质量。
通过在整个应用系统中提供并集成了测试的需求管理、案例管理、缺陷管理等，QC可以地加速测试过程执行。
4.2 缺陷状态关系示意图4.3 缺陷流转的过程及处理参与缺陷流转的角色有三个：测试经理、测试人员和开发人员。
测试人员开发人员测试人员提出拒绝处理待验证关闭重现缺陷的处理步骤如下：4.3.1 新建缺陷测试人员负责在QC 中新建缺陷，并对缺陷的基本情况进行描述。
缺陷的基本信息主要包括：缺陷描述、紧急程度、严重程度、处理子系统等。
测试人员在登记缺陷时，必须确定所输入的缺陷内容要描述清楚，产生缺陷的步骤描述要完整，使缺陷能够被重现出来。
在描述缺陷产生的步骤上，务必简易清楚。
测试人员可以利用错误抓图等方式进行补充描述。
4.3.2 修复缺陷当有多个缺陷同时打开时，开发人员应首先修复紧急程度更高的缺陷。
开发人员首先分析缺陷，并将缺陷状态更改为“处理”中。
当该缺陷不是有效的缺陷时，则将“缺陷状态”更改为“拒绝”，并在“缺陷详细信息”模块中的“分析和修改内容”中使用“添加注释”按钮详细填写拒绝的原因。
当确认该缺陷有效时，开发人员应按照要求修复缺陷。
缺陷修复后，开发人员需在“缺陷详细信息”模块中的“分析和修改内容”中使用“添加注释”按钮详细填写修复的内容，并填写缺陷起源、缺陷归属子系统，更改“缺陷状态”为“待验证”。
当确认该缺陷不是本系统引起，需要其它项目组协同进行分析解决，开发人员应保持缺陷状态为“处理”，并将该缺陷的“处理子系统”改为相应的项目组或系统，以便缺陷能及时流转。
4.3.3 验证缺陷测试人员负责验证缺陷是否已解决，如已解决则由缺陷原提出人关闭缺陷，否则将“缺陷状态”更改为“重现”，以便开发人员重新对此缺陷进行处理。
4.4 缺陷页面部分字段详解◆缺陷状态：指缺陷通过一个跟踪修复过程的进展情况。
包括：新建、打开、已修改、重新打开、关闭、拒绝、延迟◆缺陷严重程度：是指因缺陷引起的故障对系统的影响程度。
由提出人初步指定，开发人员负责确认。
包括：致命、严重、一般、轻微◆缺陷紧急程度：指缺陷必须被修复的紧急程度。
由提出人指定。
各测试小组可以项目组具体协商约定紧急程度的具体含义。
包括：高、中、低提出、处理、拒绝、待验证、重现、关闭缺陷起源：指引起缺陷的起因。
包括：需求、架构、设计、编码、测试、环境、数据、拒绝5.配置管理软件测试过程是一个复杂性的劳动，测试过程中会产生大量测试文档，主要通过相关管理工具的方式实行对文档的管理。
在文档的管理方面，按照公共类、项目类、软件缺陷类、开发人员类、测试工具类等：1）公共类主要放置测试模板及测试规程说明，测试经验共享文档，开发技术规范等。
2）项目类主要包括项目各阶段文档，如需求分析、测试计划、测试用例设计、分析报告等。
3）开发人员类是针对每个开发人员易犯错误的总结。
4）测试工具类主要放置常用的测试工具svn。
6.人员培养一个优秀的测试团队的形成并非一朝一夕能形成。
软件测试和软件开发一样，是一项高智力的活动。
在对测试人员的选择上我们通常从技术能力、沟通能力、记忆力、自信心、耐心、怀疑精神、洞察力、有条理和注意细节八方面进行考虑。
对于新进入的测试人员，无论是否有测试经验或编程经验，都应进行测试的技术和管理规范培训，同时根据他们以往知识和个人特点给他们定位合适的测试方向。