第六讲测试与缺陷管理
软件测试管理与缺陷追踪
软件测试管理与缺陷追踪在现代软件开发过程中，软件测试管理和缺陷追踪是至关重要的环节。
通过有效的测试管理和缺陷追踪，可以提高软件质量，降低开发成本，并确保软件交付符合用户需求。
本文将介绍软件测试管理的基本原则和方法，以及缺陷追踪的过程和工具。
一、软件测试管理软件测试管理是指在软件开发过程中对测试活动进行规划、组织、指导和控制的过程，旨在确保测试的有效性和高效性。
下面将介绍软件测试管理的基本原则和方法。
1. 测试计划测试计划是软件测试管理的第一步，它定义了测试的目标、范围、资源、进度和风险等方面。
一个好的测试计划应当包括以下内容：- 测试目标：明确测试的目标和预期结果，例如发现软件缺陷、验证系统功能等。
- 测试策略：确定测试的方法、技术和工具，例如黑盒测试、白盒测试、自动化测试等。
- 测试范围：明确测试的覆盖范围，包括测试哪些功能、哪些场景和数据。
- 测试资源：确定测试所需的人员、设备、环境和数据等资源。
- 测试进度：制定测试的时间计划和里程碑，确保测试工作按时完成。
- 测试风险：评估测试过程中可能遇到的风险，并制定相应的风险应对措施。
2. 测试用例测试用例是测试的重要工具，它用于描述测试的输入、操作和预期输出。
一个好的测试用例应当具备以下要素：- 测试标识：唯一标识符，便于管理和统计测试用例。
- 测试目的：明确测试的目的和预期结果。
- 测试步骤：详细描述测试的操作步骤，包括输入数据和操作过程。
- 预期输出：指定测试的预期输出结果，便于判断测试是否通过或失败。
- 前置条件和后置条件：描述测试用例执行前和执行后需要满足的条件。
测试用例的编写应当全面、独立和灵活，能够覆盖系统的各种功能和使用场景。
3. 测试执行测试执行是软件测试管理的核心环节，它包括根据测试计划执行测试用例，记录测试结果，并分析和报告测试缺陷。
以下是测试执行的关键步骤：- 准备测试环境：确保测试所需的硬件、软件和数据等资源准备就绪。
- 执行测试用例：按照测试计划，执行测试用例并记录测试结果。
软件测试与缺陷管理的流程与工具分析
软件测试与缺陷管理的流程与工具分析在软件开发过程中，测试是不可或缺的环节。
通过软件测试可以发现软件中的缺陷并提供改进的机会，确保软件的质量和稳定性。
本文将对软件测试与缺陷管理的流程与工具进行分析。
一、软件测试的流程软件测试的流程通常包括需求分析、测试计划、测试设计、测试执行、缺陷管理和测试报告等环节。
下面将对这些环节逐一进行分析。
1. 需求分析在软件测试的开始阶段，测试团队与开发团队一起进行需求分析，确保测试人员对软件功能和需求的理解一致。
此阶段的关键是明确测试的范围和目标，为后续测试设计提供基础。
2. 测试计划测试计划是测试工作的指导框架，包括测试资源的分配、测试策略和测试方法的确定等内容。
在测试计划中应该明确测试的时间、资源、环境、测试方法和测试指标等，以便测试团队按计划进行工作。
3. 测试设计测试设计是将测试计划转化为具体的测试用例和测试脚本的过程。
测试用例是按照需求和功能划分的单元测试点，通过测试用例可以全面覆盖软件的功能和逻辑。
测试脚本是自动化测试的关键，可以提高测试效率和一致性。
4. 测试执行在测试执行阶段，测试人员根据设计好的测试用例和测试脚本，按照预定的测试流程进行测试。
测试人员需要记录每个测试用例的执行结果，并收集测试过程中的运行日志和异常信息。
5. 缺陷管理在测试执行的过程中，测试人员可能会发现软件中的缺陷。
缺陷管理是指对这些缺陷进行记录、追踪和修复的过程。
测试人员应该将缺陷信息及时上报，并协助开发人员进行问题的定位和修复。
6. 测试报告测试报告是测试工作的总结和评估，对测试结果和产品质量进行汇总和分析。
测试报告应该包括测试的覆盖率、缺陷统计、测试的通过率和失败率等指标，以帮助项目团队评估软件的质量和进度。
二、软件测试的工具为了提高测试的效率和质量，测试团队可以借助一些测试工具来辅助测试工作。
下面介绍几种常见的测试工具。
1. 功能测试工具功能测试工具可以帮助测试人员快速生成测试用例、执行测试脚本并收集测试结果。
软件质量保证测试计划和缺陷管理
软件质量保证测试计划和缺陷管理在软件开发过程中，软件质量保证测试计划和缺陷管理是至关重要的环节。
本文将就软件质量保证测试计划和缺陷管理进行详细介绍，包括其定义、目标、测试计划制定、缺陷管理等内容。
一、软件质量保证测试计划1. 定义软件质量保证测试计划是指为确保软件正常运行以及提高软件质量，在软件开发过程中制定的测试方案。
测试计划需要详细规划测试活动，并确定测试资源、时间和方法。
2. 目标软件质量保证测试计划的主要目标是确保软件的功能、性能和稳定性达到预期标准。
通过提前规划测试活动，可以降低开发过程中出现的缺陷数量，提高软件的可靠性和用户满意度。
3. 测试计划制定步骤（1）需求分析：对软件的需求进行仔细分析，明确测试的重点和覆盖范围，确保测试计划与需求一致。
（2）测试策略确定：根据软件的特点和需求，制定测试的策略，包括测试方法、测试环境、测试数据等。
（3）测试资源分配：确定测试所需的人员、设备和工具，并合理分配资源，确保测试过程的顺利进行。
（4）测试进度安排：根据开发进度和测试资源，制定测试的时间表，合理安排测试活动的顺序和时间节点。
（5）测试风险评估：评估测试中可能出现的风险，制定相应的风险应对措施，降低测试风险带来的影响。
二、缺陷管理1. 定义缺陷管理是指对软件开发过程中发现的缺陷进行有效的记录、跟踪和解决的过程。
通过缺陷管理，可以及时处理软件中的问题，提高软件质量。
2. 缺陷管理流程（1）缺陷发现：通过测试过程中的检查和验证，发现软件中的缺陷。
（2）缺陷记录：将发现的缺陷记录下来，包括缺陷的描述、复现步骤、截图等信息，方便后续跟踪和解决。
（3）缺陷分类和优先级评估：将缺陷按照不同的类型进行分类，并评估其对软件的影响程度，确定缺陷的优先级。
（4）缺陷定位和复现：通过定位缺陷的位置，并复现缺陷，以便修复和验证。
（5）缺陷解决和验证：修复缺陷，并进行验证，确保缺陷的修复有效。
（6）缺陷追踪和闭环：跟踪缺陷的解决过程，并及时反馈给相关人员，确保缺陷的彻底解决。
测试缺陷管理规范
测试缺陷管理规范一、背景介绍在软件开发过程中，测试缺陷是无法避免的。
为了保证软件质量和项目进度，需要建立一套科学合理的测试缺陷管理规范。
本文将详细介绍测试缺陷管理规范的内容和要求。
二、测试缺陷管理规范的目的1. 确保测试缺陷的及时发现和修复，提高软件质量。
2. 优化测试流程，提高测试效率。
3. 提供可追溯的测试缺陷信息，方便测试跟踪和管理。
三、测试缺陷管理规范的内容1. 缺陷分类1.1 功能缺陷：软件功能不符合需求规格说明书的要求。
1.2 界面缺陷：软件界面设计不符合用户体验要求。
1.3 性能缺陷：软件在负载、并发等方面性能不符合要求。
1.4 安全缺陷：软件存在潜在的安全风险。
1.5 其他缺陷：无法归类到上述分类的缺陷。
2. 缺陷等级2.1 严重缺陷：影响软件功能正常使用，严重影响用户体验。
2.2 一般缺陷：影响软件功能的某些细节，但不影响软件整体使用。
2.3 轻微缺陷：对软件功能影响较小，不影响用户体验。
3. 缺陷报告3.1 缺陷报告应包含以下内容：- 缺陷编号：用于唯一标识缺陷。
- 缺陷标题：简明扼要地描述缺陷。
- 缺陷描述：详细描述缺陷的现象和影响。
- 复现步骤：说明如何复现缺陷，方便开发人员定位和修复。
- 附件：可以添加截图、日志等辅助信息。
3.2 缺陷报告应及时提交给开发人员，并在系统中进行记录。
4. 缺陷处理4.1 开发人员应及时处理缺陷，并在缺陷修复后进行验证。
4.2 验证通过后，将缺陷状态更新为已关闭，并通知测试人员进行确认。
4.3 如果缺陷未能在规定时间内修复，测试人员可以提出缺陷延期处理的申请。
5. 缺陷跟踪5.1 缺陷管理系统应提供缺陷跟踪功能，方便测试人员和开发人员对缺陷进行跟踪和管理。
5.2 缺陷跟踪应包括缺陷状态、处理人、处理时间等信息。
5.3 缺陷跟踪信息应定期进行统计和分析，为项目管理提供参考依据。
6. 缺陷评审6.1 定期组织缺陷评审会议，对已解决的缺陷进行评审。
测试缺陷管理规范
测试缺陷管理规范一、引言测试缺陷管理是软件开辟过程中非常重要的一环，它能够匡助团队及时发现和解决软件中的缺陷，提高软件质量。
本文旨在制定一套标准的测试缺陷管理规范，以确保测试缺陷的准确记录、追踪和解决，提高测试效率和软件质量。
二、缺陷管理流程1. 缺陷记录在测试过程中，测试人员应及时记录发现的缺陷。
缺陷记录应包括以下内容：- 缺陷编号：每一个缺陷应有惟一的编号，方便后续追踪和管理。
- 缺陷描述：清晰、准确地描述缺陷的现象和影响。
- 缺陷分类：将缺陷按照类型进行分类，如功能缺陷、界面缺陷、性能缺陷等。
- 严重程度：根据缺陷对系统功能的影响程度，分为致命、严重、普通、轻微等级别。
- 优先级：根据缺陷的紧急程度和重要性，分为高、中、低等级别。
- 复现步骤：详细记录复现缺陷的步骤，方便开辟人员快速定位和解决问题。
- 附件：如截图、日志等辅助信息，有助于更好地理解和复现缺陷。
2. 缺陷分析与评审测试团队应定期进行缺陷分析与评审，以确保缺陷记录的准确性和完整性。
在缺陷评审会议上，应邀请相关人员参预，包括测试人员、开辟人员、产品经理等。
会议的目标是对已记录的缺陷进行讨论、分析和评审，确定缺陷的修复优先级和责任人。
3. 缺陷追踪与解决缺陷追踪是确保缺陷得到及时解决的重要环节。
测试团队应使用缺陷管理工具进行缺陷追踪，将缺陷状态及时更新，并指派责任人进行修复。
修复完成后，测试人员应进行验证和确认，确保缺陷已被解决。
4. 缺陷统计与报告测试团队应定期统计缺陷数据，并生成缺陷报告。
缺陷报告应包括以下内容：- 缺陷总数：统计一段时间内发现的缺陷总数。
- 缺陷趋势：分析缺陷数量的变化趋势，以便及时调整测试策略。
- 缺陷状态分布：统计不同状态的缺陷数量，如新建、已解决、已验证等。
- 缺陷分类分布：统计不同类型的缺陷数量，如功能缺陷、界面缺陷等。
- 缺陷优先级分布：统计不同优先级的缺陷数量，以便优化缺陷解决顺序。
三、缺陷管理工具为了更好地管理测试缺陷，测试团队应选择合适的缺陷管理工具。
自动化测试中的缺陷管理技巧与应用
自动化测试中的缺陷管理技巧与应用在软件开发行业中，自动化测试已经成为了一种普遍的实践。
自动化测试不仅可以提高测试效率，降低测试成本，同时还能够更有效地保证软件的质量。
然而，在实际的自动化测试过程中，缺陷管理仍然是一项非常重要的工作。
如果不能正确地管理和跟踪缺陷，那么自动化测试的作用就会大打折扣。
因此，本文将探讨自动化测试中的缺陷管理技巧与应用。
一、缺陷管理的概念缺陷管理是软件测试过程中非常重要的一个环节。
它包括缺陷的发现、跟踪、修复和验证等一系列工作。
缺陷管理的基本目的是为了确保软件缺陷能够被及时地发现和修复，从而确保软件的质量和稳定性。
在自动化测试中，缺陷管理同样非常重要。
由于自动化测试可以对软件进行全面和高效的测试，因此可以更快地发现缺陷。
然而，由于自动化测试过程中会产生大量的测试数据和测试结果，因此需要一个高效的缺陷管理系统来跟踪和管理测试过程中产生的缺陷。
二、自动化测试中的缺陷管理1. 缺陷管理流程缺陷管理的基本流程包括：缺陷的发现、记录、分析、定位、修复、验证和关闭。
在自动化测试过程中，缺陷管理的流程同样适用。
具体的流程如下：（1）缺陷的发现：自动化测试会产生各种测试结果和测试数据，如果发现其中存在缺陷，则需要将缺陷及时记录下来。
（2）缺陷的记录：对于发现的缺陷，需要在缺陷管理系统中进行记录和管理。
通常情况下，缺陷管理系统会要求填写一些必要的信息，比如缺陷的类型、严重性、所在模块、描述、截图等。
（3）缺陷的分析与定位：在记录缺陷后，需要对缺陷进行分析和定位，找出缺陷的根本原因。
（4）缺陷的修复：对于已经定位的缺陷，需要进行修复。
（5）缺陷的验证：修复完缺陷后，需要对软件进行再次测试以验证修复效果。
（6）缺陷的关闭：经过修复和验证后，如果缺陷已经完全解决，则需要在缺陷管理系统中将其关闭。
2. 缺陷管理系统的选择在实际自动化测试中，选择一个合适的缺陷管理系统非常重要。
通常情况下，缺陷管理系统需要具备以下的特点：（1）易于使用：缺陷管理系统需要易于使用。
测试缺陷管理规范
测试缺陷管理规范一、引言缺陷管理是软件测试过程中至关重要的一环，它涉及到对软件产品中发现的缺陷进行有效的记录、跟踪和解决。
本文档旨在制定一套标准的测试缺陷管理规范，以确保缺陷能够被及时发现、准确记录和有效解决，从而提高软件质量和用户满意度。
二、缺陷管理流程1. 缺陷发现缺陷可以通过各种测试活动发现，包括功能测试、性能测试、安全测试等。
测试人员应该及时记录发现的缺陷，并详细描述缺陷的现象、复现步骤、环境等信息。
2. 缺陷分类和优先级确定根据缺陷的性质和影响程度，将缺陷进行分类，并确定缺陷的优先级。
常见的缺陷分类包括功能缺陷、界面缺陷、性能缺陷等。
优先级可以分为高、中、低三个级别，以指导缺陷解决的优先顺序。
3. 缺陷评审缺陷评审是对已记录的缺陷进行审核和确认，确保缺陷描述准确、完整，并对缺陷的分类和优先级进行确认。
评审人员可以包括测试人员、开发人员和项目经理等。
4. 缺陷分派缺陷分派是将已评审的缺陷分配给相应的开发人员进行解决。
分派时应考虑开发人员的专业领域和工作负荷，以确保缺陷能够及时得到解决。
5. 缺陷跟踪缺陷跟踪是对已分派的缺陷进行监控和追踪，确保缺陷得到及时解决。
在跟踪过程中，应及时更新缺陷的状态、解决进度和解决方案等信息。
6. 缺陷解决开发人员在解决缺陷时应根据缺陷描述和复现步骤进行调试和修复。
解决完成后，应及时更新缺陷的状态，并通知测试人员进行验证。
7. 缺陷验证测试人员在收到开发人员解决完成的通知后，应按照预先定义的验证步骤进行验证。
验证通过后，将缺陷关闭；验证不通过则重新打开缺陷，并通知开发人员重新解决。
8. 缺陷统计和分析缺陷统计和分析是对缺陷管理过程进行总结和分析，以发现潜在的问题和改进措施。
统计和分析的内容可以包括缺陷数量、解决周期、重复缺陷等。
三、缺陷管理工具为了更好地支持缺陷管理流程，可以采用专业的缺陷管理工具。
常见的缺陷管理工具包括JIRA、Bugzilla等。
这些工具提供了缺陷记录、跟踪、统计和分析等功能，能够提高缺陷管理的效率和可靠性。
测试缺陷管理规范
测试缺陷管理规范一、引言测试缺陷管理是软件开发过程中非常重要的一环，它能够帮助团队及时发现和解决软件中的缺陷，提高软件质量。
本文旨在制定一套标准的测试缺陷管理规范，以确保测试缺陷的准确记录、追踪和解决，提高测试效率和软件质量。
二、缺陷管理流程1. 缺陷记录在测试过程中，测试人员应及时记录发现的缺陷。
缺陷记录应包括以下内容：- 缺陷编号：每个缺陷应有唯一的编号，方便后续追踪和管理。
- 缺陷描述：清晰、准确地描述缺陷的现象和影响。
- 缺陷分类：将缺陷按照类型进行分类，如功能缺陷、界面缺陷、性能缺陷等。
- 严重程度：根据缺陷对系统功能的影响程度，分为致命、严重、一般、轻微等级别。
- 优先级：根据缺陷的紧急程度和重要性，分为高、中、低等级别。
- 复现步骤：详细记录复现缺陷的步骤，方便开发人员快速定位和解决问题。
- 附件：如截图、日志等辅助信息，有助于更好地理解和复现缺陷。
2. 缺陷分析与评审测试团队应定期进行缺陷分析与评审，以确保缺陷记录的准确性和完整性。
在缺陷评审会议上，应邀请相关人员参与，包括测试人员、开发人员、产品经理等。
会议的目标是对已记录的缺陷进行讨论、分析和评审，确定缺陷的修复优先级和责任人。
3. 缺陷追踪与解决缺陷追踪是确保缺陷得到及时解决的重要环节。
测试团队应使用缺陷管理工具进行缺陷追踪，将缺陷状态及时更新，并指派责任人进行修复。
修复完成后，测试人员应进行验证和确认，确保缺陷已被解决。
4. 缺陷统计与报告测试团队应定期统计缺陷数据，并生成缺陷报告。
缺陷报告应包括以下内容：- 缺陷总数：统计一段时间内发现的缺陷总数。
- 缺陷趋势：分析缺陷数量的变化趋势，以便及时调整测试策略。
- 缺陷状态分布：统计不同状态的缺陷数量，如新建、已解决、已验证等。
- 缺陷分类分布：统计不同类型的缺陷数量，如功能缺陷、界面缺陷等。
- 缺陷优先级分布：统计不同优先级的缺陷数量，以便优化缺陷解决顺序。
三、缺陷管理工具为了更好地管理测试缺陷，测试团队应选择合适的缺陷管理工具。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
缺陷严重程度
Critical不能执行正常工作功能或重要功能。或者危 及人身安全。 Major严重地影响系统要求或基本功能的实现，且没有 办法更正。（重新安装或重新启动该软件不属于更正 办法） Minor严重地影响系统要求或基本功能的实现，但存在 合理的更正办法。（重新安装或重新启动该软件不属 于更正办法） Cosmetic使操作者不方便或遇到麻烦，但它不影响执 行工作功能或重要功能。 Other其它错误。
缺陷管理工具
工具最基本要求 能记录问题点、能及时传达给相关人员，并监督 他们都作了适当的处理，更高级的工具还涵盖 了与需求、测试方案、代码、自动测试工具等 环境的集成。 文档记录式的Bug管理：Excel，Word 最著名缺陷管理系统： 开源：BugZilla；IBM：ClearQuest
国内开源的BugFree管理工具
By Design - 就是这么设计的，无效的Bug Duplicate - 这个问题别人已经发现了，重复的Bug External - 是个外部因素(比如浏览器、操作系统、其他 第3方软件)造成的问题 Fixed - 问题被修理掉了。Tester要尽可能找到这种Bug Not Repro - 无法复现你这个问题，无效的Bug Postponed - 是个问题，但是目前不必修理了，推迟到以 后再解 Won't Fix - 是个问题，但是不值得修理了，不管它吧
单元测试的主要考虑因素（2）
6调用其他模块时所给实际参数的量纲是否与 被调模块的形参量纲一致； 7 调用预定义函数时所用参数的个数、属性和 次序是否正确； 8 是否存在与当前入口点无关的参数引用； 9 是否修改了只读型参数； 10 对全程变量的定义各模块是否一致； 11是否把某些约束作为参数传递。
-免费且开放源代码、基于Web的精简版Bug管 理系统,由PHP编写，使用MySql数据库。
国内开源的BugFree管理工具(参见截图)
新建Bug 编辑Bug（更新Bug状态等） 查看Bug 解决Bug 激活Bug Bug列表 报表
国内开源的BugFree管理工具
注意，一般系统中一个Bug有7种解决状态：
如何表示缺陷的严重性和优先级
缺陷的严重性和优先级通常按照级别划分，各 个公司和不同项目的具体表示方式有所不同。 为了尽量准确的表示缺陷信息，通常将缺陷的 严重性和优先级分成4级。如果分级超过4级， 则造成分类和判断尺度的复杂程度，而少于4 级，精确性有时不能保证。
软件缺陷管理指南 -收集缺陷
对程序员来说，最贴近的是单元测试。我们有效测试仅仅涉及单 元测试 单元测试是最细粒度的测试，是针对最基本的软件构成单位-功 能块的测试
1 2 3 4 5
单元测试任务包括： 模块接口测试； 模块局部数据结构测试； 模块边界条件测试； 模块中所有独立执行通路测试； 模块的各条错误处理通路测试。
单元测试的主要考虑因素（1）
单元测试概述
程序员在编写实现的任何部分之前就开始编写它们，并继续为功能的 每个新的方面编写更多的单元测试。 覆盖软件项目的一套严格的单元测试提供两个巨大的好处： 1.他们可以是文档化的。 2.它们加速了重构过程。 单元测试与静态类型类似，是文档的 可执行形式。因为单元测试理想 地覆盖了实现的所有方面，也因为它们用简单的方式调用了功能以确 定其是否正常运行，正在加入项目的或开始维护某些代码的程序员只 要通读单元测试，就能够容易地确定各种功能组件的用途。 单元测试加速了重构的过程。当一套单元测试可以在任何时间在代码 上运行以确定是否有功能损坏时，程序员可以比在其它任何情况下更 有信心重构代码。所引入的绝大多数错误可以被立即检测出来。
JUnit安装
/junit/中下载JUnit包 按照安装指南安装
缺陷管理
软件工程的事实
错误消除是软件生命周期中最耗时的阶段； 需求，设计，编码，测试改错占到软件开发过 程时间的比例大概为：20：20：20：40
什么是软件缺陷
第六讲测试与缺陷管理
目录
1.测试 1.1关于测试的几个事实 1.2单元测试 2.缺陷管理
关于测试的事实1
普通程序员认为已经彻底测试过的软件其实只执行了 55 % -60%的逻辑路径。采用覆盖分析器等自动工具， 可以将比例提高到85%-90%，几乎不可能测试软件中 100%的逻辑路径； 思考（通过不同的测试方法来思考上述事实） 需求驱动测试 结构驱动测试 统计驱动测试（随机驱动测试） 风险驱动测试
缺陷来源
Requirement由于需求的问题引起的缺陷 Architecture由于构架的问题引起的缺陷 Design由于设计的问题引起的缺陷 Code由于编码的问题引起的缺陷 Test由于测试的问题引起的缺陷 Integration由于集成的问题引起的缺陷
软件缺陷的严重性和优先级
软件缺陷管理指南-缺陷严重程度分析
严重缺陷（Critical）不能执行正常工作功能或重要 功能。或者危及人身安全 较大缺陷（Major）严重地影响系统要求或基本功能的 实现，且没有办法更正。（重新安装或重新启动该软 件不属于更正办法） 较小缺陷（Minor）严重地影响系统要求或基本功能的 实现，但存在合理的更正办法。（重新安装或重新启 动该软件不属于更正办法） 轻微缺陷（Cosmetic）使操作者不方便或遇到麻烦， 但它不影响执行工作功能或重要功能。 其他缺陷（Other）其它错误
关于测试的事实2
即使测试覆盖有可能达到100%，这种测试也是 不够的。（无法保证软件完美无缺） 说明： 大约35%的错误是源于逻辑路径的缺失，40% 的错误源于执行特定的路径组合。
Байду номын сангаас
测试分类
按照在不同的软件生命期有不同的测试 1.单元测试 2.集成测试 3.系统测试 4.实地测试
单元测试
模块接口测试是单元测试的基础。只有在数据能正确 流入、流出模块的前提下，其他测试才有意义。测试 接口正确与否应该考虑下列因素： 1 输入的实际参数与形式参数的个数是否相同； 2 输入的实际参数与形式参数的属性是否匹配； 3 输入的实际参数与形式参数的量纲是否一致； 4 调用其他模块时所给实际参数的个数是否与被调模 块的形参个数相同； 5 调用其他模块时所给实际参数的属性是否与被调模 块的形参属性匹配；
软件缺陷管理指南-解决优先级
立即解决（Resolve
Immediately） 缺陷必须被立即解决。 正常排队（Normal Queue）缺陷需 要正常排队等待修复或列入软件发 布清单。 不紧急（Not Urgent）缺陷可以在 方便时被纠正。
一般的缺陷管理过程
Tester发现Bug,登记到缺陷管理系统-> 开发team讨论分配bug-> 开发责任人完成修改,到缺陷管理系统登记处 理结果-> tester确认处理结果-> Bug被正确修复/Bug修复不成功，继续上述过 程
缺陷既指程序中存在的错误，例如语法错误、 拼写错误或者是一个正确的程序语句，缺陷也 指可能出现在设计中，甚至在需求、规格说明 或其他的文档中的种种错误。为了对缺陷进行 管理，首先应对缺陷进行分类，通过对缺陷进 行分类，可以迅速找出哪一类缺陷的问题最大， 然后集中精力预防和排除这一类缺陷。
软件缺陷管理指南 –分类记录缺陷
单元测试的主要考虑因素（3）
如果模块内包括外部输入输出，还应该考虑下 列因素： 1 文件属性是否正确； 2 OPEN/CLOSE语句是否正确； 3 格式说明与输入输出语句是否匹配； 4缓冲区大小与记录长度是否匹配； 5文件使用前是否已经打开； 6是否处理了文件尾； 7是否处理了输入/输出错误； 8输出信息中是否有文字性错误；
缺陷状态
Submitted已提交的缺陷 Open确认“提交的缺陷”，等待处理 Rejected拒绝“提交的缺陷”，不需要 修复或不是缺陷 Resolved缺陷被修复 Closed确认被修复的缺陷，将其关闭
缺陷起源
Requirement在需求阶段发现的缺陷 Architecture在构架阶段发现的缺陷 Design在设计阶段发现的缺陷 Code在编码阶段发现的缺陷 Test在测试阶段发现的缺陷
严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程 度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影 响。 在软件测试中，软件缺陷的严重性的判断应该从软件最终用户 的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺 陷对用户使用造成的恶劣后果的严重性。 优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些 缺陷需要优先修正，哪些缺陷可以稍后修正。 确定软件缺陷优先级，更多的是站在软件开发工程师的角度考 虑问题，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹 技术问题，而且开发人员更熟悉软件代码，能够比测试工程师 更清楚修正缺陷的难度和风险。
按照缺陷的类型进行归类，比如按功能，语法，赋值， 文档，环境等等进行分类 可以按照以下步骤收集记录关于缺陷的数据： ◆ 为测试和同行评审中发现的每一个缺陷做一个记录 ◆ 对每个缺陷要记录足够详细的信息，以便以后能更好 地了解这个缺陷 ◆ 分析这些数据以找出主要哪些缺陷类型引起大部分的 问题 ◆ 设计出发现和修复这些缺陷的方法（缺陷排除）
A、对测试目标进行测试的方法与过程集合，可称为测 试用例(TestCase)。 B、测试用例的集合，可容纳多个测试用例(TestCase)， 将其称作测试包(TestSuite)。 C、测试结果的描述与记录。(TestResult) 。 D、测试过程中的事件监听者(TestListener)。 E、每一个测试方法所发生的与预期不一致状况的描述， 称其测试失败元素(TestFailure) F、JUnit Framework中的出错异常 （AssertionFailedError）。