标准规范下载简介

GB／T 38634.1-2020 系统与软件工程 软件测试 第1部分：概念和定义.pdf简介：

GB/T 38634.1-2020《系统与软件工程 软件测试 第1部分：概念和定义》是中国国家标准，由国家标准化管理委员会和中国电子工业标准化技术委员会发布。该标准是为了规范和统一软件测试领域内的术语、定义、原则和基本要求。它对软件测试的各个方面进行了详细的阐述，包括但不限于测试的目的、测试的范围、测试方法、测试对象、测试生命周期等。

1. 内容概述：该标准首先定义了软件测试的基本概念，明确了软件测试的目的是验证软件的功能、性能、安全性、可靠性和兼容性等，确保软件满足用户需求和预期。然后，它还规定了测试环境、测试用例、测试策略和方法，以及测试人员的角色和职责。

2. 适用范围：该标准适用于所有类型的软件开发项目，包括商业、政府、教育和科研等领域。无论是软件开发过程中的测试，还是软件产品上市后的维护测试，都可以参考该标准进行。

3. 更新意义：随着信息技术的快速发展，对于软件质量的要求越来越高，该标准的发布有助于提升软件测试的标准化水平，促进软件行业的健康发展。

总的来说，GB/T 38634.1-2020是一个指导软件测试实践的重要规范，对于规范软件开发过程，提高软件质量具有重要意义。

GB／T 38634.1-2020 系统与软件工程 软件测试 第1部分：概念和定义.pdf部分内容预览：

量特性保持一致。非功能性需求与部分或所有功能相关，并且通常功能性需求可与单独或 组的非功能性需求相关联。

4.5.6 复测和回归测试

4.5.7测试设计技术

GB 5135.4-2003 自动喷水灭火系统 第4部分 干式报警阀测试设计技术包括静态测试技 助领试人员尽日育 和高效地发现测试项的缺陷。静态测试通 档测试项中的明显缺陷(“问题”)或源代码 异常来实现。动态测试通过 实现此自的

4.5.7.2静态测试设计技术

4.5.7.3动态测试设计技术

动态测试的测试设计技术用于识别测试条件、测试覆盖项以及随后在测试项上执行的测试用例 动态测试设计技术根据测试输入的导出方式分为三类。分别是基于规格说明、基于结构和基于经验的 技术。GB/T38634.4详细描述了每类动态测试设计技术。 基于规格说明的测试设计技术用于从描述测试项的预期行为的测试依据导出测试用例。使用这些 技术，从测试依据中导出测试用例测试的输人和预期结果。特定情况下选择哪种基于规格说明的测试 没计技术取决手测试依据和/或测试项目的性质和所涉及的风险。GB/T38634.4中涉及的基于规格说 明的测试设计技术示例包括边界值分析、状态转移测试和判定表测试。 基于结构的测试设计技术基于结构特征导出测试用例，例如源代码结构或菜单结构。如果将这些 技术用于应用程序源代码，则测试用例的预期结果将从测试依据导出。在任何特定情况下选择使用哪 种基于结构的测试设计技术取决于测试依据的性质和所涉及的风险。在GB/T38634.4测试技术中详

细定义和描述了该类技术。GB/T38634.4中涉及的基于结构的测试设计技术的示例包括分支测试、状 态测试和数据流测试。

4.4中所描基于风险的测试已被广泛采用，是本标准的基本方法。有许多不同的实战用手策划 和实施项目的测试。传统的实践是依据需求进行测试，在测试执行前人工设计测试用例，并混合使用人 工和自动化测试来执行。使用基于风险的测试并不意味着不能使用这些实践作为声称符合 GB/T38634.2的测试计划的一部分。测试策略的选择取决于各种风险，例如组织、项目和测试项目的 风险。例如，如果组织无法确保每项要求都经过测试，则可能面临违反合同的风险。因此，使用基于需 求的实践将是管理组织风险的方法。本条介绍了多个测试实践，每个测试实践都可以作为符合 GB/T38634.2创建的测试策略的一部分。通常这些测试实践中的任何一种都不可能单独使用，而是用 作更大的测试策略的一部分。 本条闻述了当前使用的一些测试实践，以演示一些可在测试计划时使用的选项。

4.6.2 基于需求的测试

基于需求的测试主要目的是确保在测试中解决（即“覆盖”）测试项的需求，以确定测试项是否满足 最终用户需求。此外，还用于在生存周期中收集并尚利益相关方提供其他有价值的信息，例如测试项中 标识的缺陷。在使用此实践时，需求为测试计划、测试设计和实现以及执行过程的决策提供信息。注 意，基于需求的测试可以部分用于完成ISO/IEC/IEEE12207中概述的需求验证。 基手需求的测试主要使用脚本测试。测试用例是在测试执行之前，在测试设计和实现过程中编写 的。然后根据测试过程中定义的计划，在测试执行过程中执行测试用例。随后对测试执行结果进行分 析，完善测试，可能还会有更深入的测试设计和测试用例脚本。在此测试设计期间所创建的测试用例将 被记录，并在此测试执行生存周期后期执行。 其他测试实践可以支持基于需求的测试，用以证明需求已经过充分的测试。除了使用基于需求的 则试以确保满足所有需求之外，还可以采用其他实践（即基手经验的测试）来解决其他风险。例如，交付 产品中常常存在回归缺陷。或许探索性测试可以解决这些回归风险。 使用基于需求的测试的实用性是高度依赖于周境的。如果需求不完整或不一致，则测试可能会受 此影响。即使需求明确，但预算和时间限制可能意味着无法测试所有需求。当需求补充有相关优先级 的信息时，应重新确定测试优先级（在这种情况下，可以使用基于风险的方法来确定优先级较高需求的 优先级）。在实践中，使用基于需求测试的测试人员通常会以这种方式补充基本需求，以便更彻底和更 早地测试量重要（最高风险）的需求

4.6.3基于的测试

所有的测试都使用的概念来表示测试项的预期行为可用作测试依据。该可以用自然语言 表述的需求、思维图、数学公式、图形符号（例如状态转移图、UML图）或矩阵（例如决策表）的形式表 下，或者混合这些方式来表示。传统，测试人员使用人工导出执行基于规格说明测试的测试输入 和预期结果，以及执行基手结构测试的预期结果（此处测试输入是通过测试项结构得出的），随后人工或 使用测试工具执行测试。 基于的测试虽然也是基于预期行为的，但其实践从根本上不同。不同之处在于，对于基于 的测试，应充分形式化、足够详尽，以便从中导出有用的测试信息。信息可包括测试 计划、设计、规程、输入、风险、结果参照物。使用基于测试的优点包括可生成测试信息、提高测试生

存周期中自动化水平（计划到文档），以及能尽卓识别某一些错误类型。这种自动化水平可在相对较短 的时间内自动生成、执行和检查数百万个测试用例。 使用基于的测试的典型周境是针对关键应用程序，其失效可能导致很大的损失，并且应用程序 的需求行为适合由基于的测试工具进行建模（熟练工可以创建和更新）。UML图形符号通常 用作这些的基础，也可采用其他符号。使用基测试的另一个考量因素是应用程序维护过程 中，修改将比修改自动化测试脚本更容易（每次更新时，基于的测试工具随后可以相对较 低的成本导出并运行测试）。 的使用可以为其他领域提供益处。例如，基于的自动源代码生成可以减少在开发期间出 现的某些类型的缺陷（即错误的代码和可以通过检查检测到缺陷）。这有助手减少测试过程中开发 过程引人测试项的缺陷数量。

6.4基于数学方法的测

当可以充分详细地描述测试项输人或输出范围时，基于数学方法的测试实践可用于计划、设计、选 数据和设置输人条件。数学方法实践使用数学分支来推动。这些实践有助于减少测试用例选择和优 先级排序中人为因素的影响。 基于数学方法的实践用到了多种技术；特别是以下测试设计技术（在GB/T38634.4中描述）： 组合测试： 一随机测试用例选择， 此外，统计建模可用于确定测试覆盖率（未在GB/T38634.4中提及），例如： 一分层抽样； 模糊测试； 聚族抽样： 专家翔判断抽样。 基于数学方法的测试实践，也可使用基于数学的工具和技术客观地对测试用例进行采样。 使用数学方法的实践通常会产生大量的输人，因此通常需要使用自动化工具来实现

4.6.5基于经验的测试

基于经验的测试是基于： 一以往的测试经验； 一特定的软件和系统知识； 一领城知识： 一以往项目（在组织和行业内）的指标。 GB/T38634.4描述基于经验的测试设计技术中的错误猜测。其他基于经验的测试方法包括（但不 限于）探索性测试、软件攻击和特别测试。探索性测试和软件攻击不作为GB/T38634.4所包含的测试 设计技术。因为这两种技术应用了多种测试设计技术。 探索性测试压缩了GB/T38634.2中“测试设计和实现”和“测试执行”过程描述的活动，以便动态 执行这活动完成测试自标。当使用探索性测试时，测试用例通常不会提前设计和记录，测试人员使用 直觉、好奇心和先前测试的结果来决定接下来测试的内容和方法。 探索性测试、错误猜测和特殊测试是不依赖手大量文档（例如测试规程）来执行测试的测试实践。 在脚本测试到无脚本测试中，基于经验的测试实践主要是无脚本测试。使用这种方法可能只能符合 GB/T38634.2的剪裁符合性

4.6.6脚本测试和无脚本测试

相口 斥：它们通常结合起来，根据测试项的风险等级混合实践， 在决定是使用脚本测试、无脚本测试还是两者的混合时，主要考虑的是测试项的风险情况。例如 混合实践可能使用脚本测试来测试高风险测试项，而无脚本测试来测试同 一项目中的低风险测试项，

改行中的脚本和无脚本或

JC∕T 460.1-2006 水泥工业用胶带斗式提升机 第1部分：型式与基本参数GB/T38634.1—2020 以帮助测试人员记录测试事故报告和在必要时对缺陷进行重新测试。本标准未直接涵盖缺陷管理的其 他部分。缺陷管理概念和过程可以在以下标准中获取：ISO/IEC/IEEE12207、ISO/IEC20000和 GB/T32422—2015。

图A.1定义了种验证与确认（V&V)活动的分类。V&V可以在系统、硬件和软件产品上完成。 这些活动在GB/T32423一2015和ISO/IEC/IEEE12207中进行了定义和细化。许多V&V都是通过 测试完成的。GB/T38634解决了软件的动态和静态测试（直接或通过引用），因此涵盖了测试和验证 的部分内容。GB/T38634并没给出V&.V所有的元素.但对测试人员来说，理解测试在V&V模 型中的位置很重要。

图A.1验证和确认活动的层次结构图

测试的主要目的是提供有助手管理风险的信息。为了监测和控制测试并及时向利益相关方提供信 息，有必要对测试过程进行有效地测量。为了测量测试过程，有必要定义要提供的信息，以及如何获得 和呈现这些信息。因此，所有的测试工作都需要定义和使用度量，并提供关于产品和过程的测度。 可以在测试中使用度量的示例如下： 一残余风险；减轻风险数量/识别的风险数量。 累积缺陷打开和关闭；每天打开的缺陷数量与每天关闭的缺陷数量之比。 一测试用例进度：执行的测试用例数/计划执行的测试用例数。 一缺陷检测百分比，测试中发现的缺陷数/发现的缺陷数（总体）

JC∕T 933-2019 快硬高铁硫铝酸盐水泥附录C （资料性附录） 不同生存周期中的测试

本附录给出了调试如何适用于不同的软件并发生存周期的示例。对于一个给定的项目，需要 确定必要的开发阶段和/或活动，以及在开发生存周期过程中这些阶段和/或活动的相互关系。开发阶 设及其关系的集合称为开发生存周期”，或者更简单地称为“生存周期”。 多年来，软件行业已经使用了许多生存周期。这里按字母顺序（和它们的出现顺序相反）对典 型生存周期进行了分类，但这不是一个完整的列表： 敏捷； 一演化； 一顺序（即漆布）。 在所有生存周期中执行的开发活动或多或少是相同的；主要区别在于它们范围的定义、产生的 文档数量和性质以及它们在开发生存周期中重复的频率。 注：本部分的目的不是对不同的生存周期进行标准化，而是建立测试周境以勘于实施这此生存周期