3 术语和定义
在本文档中，以下术语和定义适用。
ISO、IEC 和 IEEE 在以下地址维护标准化中使用的术语数据库：
- ISO 在线浏览平台：https://www.iso.org/obp/ui
- IEC 电子百科全书：网址：https://www.electropedia.org/
- IEEE 在线标准词典：https://ieeexplore.ieee.org/browse/standards/dictionary
注意 有关系统和软件工程领域的其他术语和定义，请参见 ISO/IEC/IEEE 24765，它作为 SEVOCAB（系统和软件工程词汇表）的 "快照 "定期发布，可在 https://pascal.computer.org/sev_display/index.action 上公开查阅。
参考资料
- 软件测试精品书籍文档下载持续更新 https://github.com/china-testing/python-testing-examples 请点赞，谢谢！
- 本文涉及的python测试开发库 谢谢点赞！ https://github.com/china-testing/python_cn_resouce
- python精品书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
- Linux精品书籍下载 https://www.cnblogs.com/testing-/p/17438558.html
- 如需英文原版可联系微信pythontesting
- 软件测试开发产品项目管理QA等标准 https://github.com/china-testing/python-testing-examples/blob/master/std.md
- 累计几万人的软测测试微信和钉钉群，联系微信或钉钉pythontesting，注明：软件测试
3.1 A/B测试（A/B testing）
又称split-run testing（分步测试），用统计测试的方式确定两个系统或组件中哪一个表现更好。
3.2 易访问性测试（accessibility testing）
易用性测试 的一种，用于测量某一测试项可以被用户所使用的程度, 其中用户应覆盖最大范围的各种特征和不同能力的个体。
3.3 激活函数（activation function）
又称transfer function（转换函数）。AI与神经网络中的节点相关联的公式，用于确定节点的输出。
3.4 激活值（activation value）
AI与神经网络中的节点的激活函数输出
3.5 实测结果（actual result）
测试执行结果: 测试项的行为、状态集,或相关数据,测试环境的状态集。
示例：屏幕输出、硬件输出、数据变化、报告和发送的通信信息。
3.6 基于人工智能的系统（AI-based system）
系统包括一个或多个实施人工智能的组件
3.7 人工智能（AI：artificial intelligence）
工程系统获取、处理和应用知识与技能的能力
3.8 自主系统（autonomous system）
AI能够在没有人类干预的情况下持续工作的系统
3.9 自主性（autonomy）
AI系统在没有人类干预的情况下持续工作的能力
3.10 背靠背测试（back-to-back testing）
又名差异测试（Differential Testing）或纵向比较测试，即使用系统的另一版本来产生预期结果，以便对相同的测试输入进行比较。
3.11 基本项（base choice）
又名基本值（base value）：根据参数的代表性或典型值选择的输入参数值
3.12 边界值分析（boundary value analysis）
基于规范的测试设计技术（3.94），以等价区的边界（3.30）为基础。
3.13 分支测试（branch testing）
基于结构的测试用例（3.85）设计技术，以测试项（3.107）控制流（3.22）中的分支为基础。
3.14 因果图（cause-effect graph）
用图形表示因（用布尔条件描述的输入）和果（用布尔表达式描述的输出）之间的决策规则。
3.15 因果图设计（cause-effect graphing）
基于因果图中决策规则的因果图规范测试设计技术。
3.16 分类（classification）
机器学习预测给定输入的输出类别函数。
3.18 组合测试 （combinatorial testing）
基于规范的测试设计技术类别，以 P-V 对的组合为基础。
示例：配对测试 (3.57)、基本项 (3.11) 测试
3.19 兼容性测试（compatibility testing）
衡量测试项在共享环境中与其他独立产品一起令人满意地运行的程度(共存性)，并在必要时与其他系统或组件交换信息(互操作性)
3.20 完成标准（completion criteria）
测试活动被认为已经完成的条件
3.21 条件（condition ）
不包含布尔操作符的布尔表达式，例如 "A < B "是一个条件，但 "A 和 B "不是。
3.22 控制流（control flow）
测试项（3.107）执行过程中进行操作的顺序。
3.22 control（控制）
测试项执行过程中进行操作的流程序列。
3.23 决策（decision）
又名判定。在两个或两个以上的可能结果中进行选择， 典型的判定语句是简单的选择（如 if-then-else）、决定何时退出循环（如 while-循环），以及 case（开关）语句（如 case-1-2-3-...-N）。
3.24 决策结果（decision outcome）
又名判定结果。决策的结果决定了要执行的分支
3.25 决策规则（decision rule）
又名判定规则。在决策表测试和因果图中，产生特定结果的条件（又称原因）和行为（又称结果）的组合。
3.26 决策表（decision table）
又名判定表。以表格形式表示原因（输入描述为布尔条件 ）和效应（输出描述为布尔表达式）之间的决策规则
3.27 决策表测试（decision table testing）
基于规范的测试设计技术的一种，以在决策表中执行决策规则为基础
3.28 判定测试（decision testing）
基于结构的测试用例设计技术，其基础是在测试项的控制流中执行判定结果（3.24）。
3.29 动态测试（dynamic testing）
通过执行测试项对其进行评估的测试。
3.30 等价区（equivalence partition）
又名equivalence class（等价类）。预期测试项会以类似方式处理的输入或输出类别。
3.31 等价区划分（equivalence partitioning）
又名等价类划分。测试设计技术的一种，通过使用每个分区的一个或多个代表性成员，设计测试用例以执行等效分区。
3.32 错误猜测（error guessing）
测试设计技术的一种，测试用例是根据测试人员对过去故障的了解或对故障模式的一般了解而得出的。相关知识可从个人经验中获得，也可封装在缺陷数据库或"缺陷分类"中。
3.33 可执行语句（executable statement）
在编译时，该语句被转换成目标代码，当测试项运行时，该目标代码将按程序执行，并可能对程序数据执行操作。
3.34 穷尽测试（exhaustive testing）
又称穷举测试。测试方法的一种，对所有输入值和前提条件的组合进行测试。在几乎所有非微观情况下，由于可能的测试数量巨大，不可能进行穷举测试。
3.35 预期结果（expected result）
可观察到的测试项在特定条件下的预期行为，基于其规格或其他来源。
3.36 基于经验的测试（experience-based testing）
测试用例的设计技术的一种，其基础是利用测试人员的经验生成测试用例。
示例：错误猜测（3.32）。基于经验的测试可包括测试攻击、浏览和错误分类法等概念，它们针对潜在的问题，如安全、性能和其它质量领域。
3.37 探索性测试（exploratory testing）
基于经验的测试，测试员根据现有的相关知识、先前对测试项的探索（包括先前测试的结果），以及有关常见软件行为和故障类型的启发式 "经验法则"，自发地设计和执行测试： 探索性测试寻找隐藏的属性（包括隐藏的行为），这些属性本身可能是良性的，但会干扰被测软件的其他属性，从而构成软件失败的风险。
3.38 模糊测试（fuzz testing）
AI软件测试的一种：使用大量随机（或接近随机）数据（称为fuzz）生成测试项的输入。
3.39 事件（incident）
在项目、产品、服务或系统的生命周期中的任何时候出现的异常或意外事件、一系列事件、状况或情况。
3.40 事件报告（incident report）
事件(3.39)发生、性质和状态的文档。
注:事件报告也称为异常报告、错误报告、缺陷报告、差错报告、问题报告等。
3.41 关键字（keyword）
<关键字驱动测试（3.42）> 一个或多个单词，用来指在执行一个或多个测试用例（3.85）时要执行的一组特定操作。
注1： 这些操作包括测试期间与用户界面的交互、验证以及设置测试场景（3.123）的具体操作。
注2： 关键词的命名至少使用一个动词。
注3： 可根据其他关键字构建复合关键字。
3.42 关键字驱动测试（keyword-driven testing）
使用由关键字组成的测试用例进行测试。
3.43 负载测试（load testing）
性能测试的一种，用于评估测试项在预期的不同负载条件下的行为，通常介于预期的低使用率、典型使用率和高峰使用率之间
3.44 机器学习（machine learning ML）
使用计算技术使系统能够从数据或经验中学习的过程
3.45 维护性测试(maintainability testing)
测试类型的一种，用于评估系统的可维护性程度。
3.46 手工测试(manual testing)
人类通过向测试项输入信息并验证结果来执行测试。
自动测试使用工具、机器人和其他测试执行引擎来执行测试。
3.47 MC/DC 测试（MC/DC testing）
修改条件判定测试（modified condition decision testing）是基于结构的测试用例设计技术，其基础是证明决策中的单个布尔条件可独立影响决策的结果
3.48 变形关系（metamorphic relation）
描述了输入数据与输出结果之间的一种预期变化关系。简单来说，就是当我们对输入数据进行某种有意的改变时，输出结果会产生什么样的相应变化。
3.49 8 变形测试（metamorphic testing）
基于规范测试的一种，基于现有测试用例和变形关系生成测试用例。
3.50 神经网络（neural network）
人工神经网络（artificial neural network）由原始处理元素组成的网络，这些元素通过可调整权重的加权链接连接在一起，其中每个元素通过对其输入值应用非线性函数来产生一个值，并将其传送给其他元素或作为输出值显示出来。
有些神经网络旨在模拟神经系统中神经元的功能，而大多数神经网络在人工智能中被用作连接模型的实现。非线性函数的例子有阈值函数、sigmoid 函数和多项式函数。参考：ISO/IEC 2382
3.51 神经元覆盖率（neuron coverage）
AI在一组测试中被激活的神经元除以神经网络中神经元总数的比例（通常用百分比表示）。如果神经元的激活值超过零，则认为该神经元已被激活。
3.52 非定常系统（non-deterministic system）
又名：非确定性系统。给定一组特定的输入和起始状态，并不总是产生同一组输出和最终状态。
3.53 组织测试实践（organizational test practices）
表述在组织内进行测试的建议方式或方法的文件，详细说明如何进行测试。
组织测试实践与组织测试政策（3.118）保持一致。
一个组织可以有一份以上的组织测试实践文件，以涵盖明显不同的情况，如一份用于移动应用程序，一份用于安全关键系统。
在没有单独测试方针的情况下，组织测试实践可纳入测试方针的背景情况。
3.54 组织测试过程（organizational test process）
制定和管理组织测试规范的测试流程
3.55 组织测试规范（organizational test specification）
为组织提供测试信息的文档,该信息并不针对具体项目。
组织测试规范最常见的例子是组织测试方针和组织测试实践。
3.56 P-V对（parameter-value pair）
测试项参数与分配给该参数的值的组合，用作测试覆盖项。
3.57 配对测试（pairwise testing）
黑盒测试设计技术的一种，其中设计的测试用例可执行每对输入参数的所有可能离散组合，配对测试是最常用的组合测试形式 。
3.58 性能测试（performance testing）
用于评价测试项在给定时间或其他资源约束下,完成其指定功能程度的一种测试。
3.59 可移植性测试（portability testing（
用于评价测试项从一个硬件或软件环境迁移到另一个硬件或软件环境的容易程度的测试。包括在多种环境下运行测试项所需的修改程度。
3.60 规程测试（procedure testing）
功能测试的一种。用于评价与测试项交互或使用其输出的规程指令是否满足用户需求及其使用目的。
3.61 产品风险（product risk）
产品在其功能、质量或结构的某些特定方面可能存在缺陷的风险
3.62 项目风险
与项目管理有关的风险。
3.63 随机测试（random testing）
基于规范的测试设计技术的一种，随机选择的测试项输入
3.64 回归测试
在对测试项或其运行环境修改后执行，以确定测试项未修改部分未受影响。回归测试与重新测试的不同之处在于，它不是测试修改是否正确，而是测试系统的其他部分是否受到修改的意外影响。回归测试用例的充分性取决于被测试项和对该项或其运行环境的修改。
3.65 监管标准（regulatory standard）
由监管机构颁布的标准
3.66 可靠性测试（reliability testing）
评估测试项目在规定的条件下使用一段时间后执行其规定功能的能力而进行的测试，包括评估发生故障的频率等。
3.67 基于需求的测试（requirements-based testing）
基于原子需求的测试用例设计技术
示例：一个原子需求可以是 "系统应收集并存储所有注册用户的出生日期"。
3.68 重新测试(retesting)
又名确认测试（confirmation testing），用来检查修改是否成功地消除了BUG。在进行重新测试时，还经常辅以回归测试。
3.69 基于风险的测试（risk-based testing）
基于风险分析确定的风险类型和级别,有意识地管理、选择、排序和利用测试活动及资源的测试。
3.70 机器人（robot）
AI中具有一定自主性(3.9)的编程驱动机构，在其环境中移动，执行预定任务。机器人包括控制系统和控制系统接口。机器人分为工业机器人和服务机器人，是根据其预期用途来划分的。
3.71 无害性
期望系统在规定的条件下不会导致危及人的生命、健康、财产或环境的状态 [出处：ISO/IEC/IEEE 12207:2017，3.1.48]
3.72 场景测试（scenario testing）
一种基于规范的测试用例设计技术，基于测试项目与其他系统之间的交互序列的演练。用户在这里被视为其他系统。
3.73 脚本测试（scripted testing）
测试根据文档化的测试脚本（3.124）进行。
3.74 安全测试（security testing）
评价测试项及相关数据和信息受到保护程度的一种测试,以确保未经授权的人员或系统不能使用,读取或修改它们,且不拒绝授权人员或系统的访问。
3.75 基于规格说明的测试（specification-based testing）
又名黑盒测试（black-box testing）、闭箱测试（closed box testing）。主要基于测试项外部输入和输出的一测试,通常是依据规格说明而不是源码实现或可执行软件。
3.76 状态转换测试（state transition testing）
基于在状态模型中进行转换的设计技术。
示例：状态模型中的状态转换图和状态表。
3.77 语句测试（statement testing）
设计测试用例用于执行测试项中某条语句
3.78 静态测试（stafic testing）
在不运行代码的情况下,通过一组质量准则或其他准则对测试项进行检查的测试。
示例:评审、静态分析。
3.79 压力测试
用于评价测试项在高于预期或指定容量负载需求,或低于最少需求资源的条件下的行为。
3.80 基于结构的测试（structure-based testing）
又名：白盒测试（white box testing）、玻璃盒测试（glass-box testing）、结构测试（structural testing）
由测试项结构导出测试用例的动态测试。基于结构的测试不限于在组件层面使用，可在所有层面使用，例如作为系统测试一部分的菜单项覆盖。技术包括分支测试（3.13）、决策测试（3.28）和语句测试（3.77）。
3.81 挂起准则（suspension criteria）
用于(暂时)停止全部或部分测试活动的准则。
3.82 测试（test）
在指定条件下执行系统或组件，观察或记录结果，并对系统或组件的某些方面进行评估
3.83 测试方法（test approach）
高层次的测试实施选择，通常作为测试策略设计活动的一部分。
示例1:功能系统测试中的基于模块的测试。
示例2：测试方法的典型选择是测试级别、测试类型、测试技术、测试实践和使用的静态测试形式。
3.84 测试依据（test basis）
作为测试分析和测试用例设计基础的知识体系。
注:测试依据可以采用文件的形式,例如需求规格说明、设计规格说明或模块规格说明,但也可以是非书面形式对
需求行为的理解。
3.85 测试用例（test case）
前置条件、输入(包括操作,如果适用)和预期结果的集合,用于驱动测试项的执行以满足测试目标,测试目标包括正确实现、错误识别、检查质量和其他有价值的信息。
注1:测试用例是测试子过程的最低测试输入级别。(即,测试用例无法再划分为更细的测试用例)
注 2:测试用例的前置条件包括测试环境、已有数据(如数据库),被测软件、硬件等，
注 3:输入是用于驱动测试执行的数据信息和操作。
注4: 预期结果包含通过的准则、失效的校核。
3.86 测试完成过程（test completion process）
测试管理过程的子过程。用于确保有用的测试资产可供以后使用、测试环境保持在令人满意的状态、测试结果被记录并传达给利益相关方。
3.87 测试完成报告（test completion report）
描述已完成测试的总结报告。
注:测试完成报告也被称为测试总结报告。
3.88 测试条件（test condition）
组件或系统可测的方面,如作为测试依据的功能、事务、特征、质量属性或者结构元素，被确定为测试的基础。
ISO/IEC/IEEE 29119 系列没有使用测试条件的概念，而是使用测试模型的概念来进行测试设计。
3.89 测试覆盖率（test coverage）
以百分比表示的、用以表示一个或多个测试用例实现指定测试覆盖项的程度。
3.90 测试覆盖率项
又名覆盖项（coverage item），测试项目的可测量属性，是测试的重点。
示例：等价类划分、状态之间的转换、可执行语句 。
3.91 测试数据（test data）
为满足执行一个或多个测试用例的输入要求而创建或选择的数据。
条目注 1： 测试数据可存储在测试项内（如数组、数据库或扁平文件），也可来自外部，如其他系统、硬件设备或人类操作员。
3.92 测试数据准备报告（test data readiness report）
描述每个测试数据需求准备状态的文档。
3.93 测试设计和实施过程（test design and implementation process）
生成和确定测试用例和测试规程的测试过程。
3.94 测试设计技术（test design technique）
又称测试技术（testtechnique）。用于创建或选择测试模型、确定测试覆盖项和推导相应测试用例的规程。
示例：等价类划分、边界值分析、决策表、分支测试。
注1： 测试设计技术通常用于达到所要求的测试覆盖率。
注2： 一些测试实践，如探索性测试或基于模型的测试有时也被称为 "测试技术"。根据 ISO/IEC/IEEE 29119 系列的定义，它们不是测试设计技术，因为它们本身并不提供创建测试用例的方法，而是使用测试设计技术来实现。
3.95 测试环境（test environment）
用于执行软件测试的设施、硬件、软件、固件、规程和文档集。
注1：一个测试环境可包含多个环境，以适应特定的测试级别或测试类型（如单元测试环境、性能测试环境）。
注2： 一个测试环境可包括几个相互连接的系统或虚拟环境。
3.96 测试环境和数据管理流程
用于建立和维护所需测试环境及相应测试数据的测试流程。
3.97 测试环境准备报告（test environment readiness report）
描述每个测试环境需求实现程度的文档。
注1： 可列出每项测试环境要求的状况。
3.98 测试环境要求（test environment requirements）
测试环境必要性质的描述。
条目的注 1： 测试环境要求的全部或部分内容可在组织测试实践文件、测试计划和测试规范中找到。
3.99 测试执行（test execution）
在测试项上执行测试并产生实测结果的过程。
3.100 测试执行引擎（test execution engine）
用软件实现的工具，有时也用硬件实现，可操作测试项来执行测试用例。
注1： 典型的测试执行引擎包括单元测试工具框架、刺激指令系统、捕捉和回放工具或硬件机器人以及控制它们的软件。
3.101 测试执行日志（test execution log）
记录一个或多个测试规程执行细节的文档，
注:测试执行日志也称为测试记录。
3.102 测试执行过程（test execution process）
动态测试过程的子过程。用于在准备好的测试环境中执行测试设计和实现过程中创建的测试规程,并记录其结果。
3.103 测试框架（test framework）
结构化的原则、准则和实践的集合，用于组织、选择和交流测试。
3.105 测试事件报告流程（test incident reporting process）
动态测试过程的子过程。用于向利益相关方报告在测试执行过程中确定的,需要进一步处理的问题。
用于向相关利益方报告在测试执行过程中（3.102）发现的需要采取进一步行动的事件（3.39）
3.106 测试独立性（test independence）
执行测试的人员与开发测试项目的人员在多大程度上具有独立的责任。
3.107 测试项（test item）
又名测试对象（test object）：待测试的工作产品。例：软件组件、系统、需求文档、设计规范、用户指南。
3.108 测试级别（test level）
测试阶段序列中的一个阶段，每个阶段通常与特定目标的实现有关，并用于处理特定的风险。
注1： 测试项不一定要在所有测试级别都进行测试，但测试级别的顺序一般保持不变。
注2： 典型的目标可包括考虑单元/组件测试的基本功能、集成测试的集成组件之间的交互作用、验收测试的最终用户的可接受性。
3.109 测试管理（test managemen）
测试活动的计划、安排、估算、监控、报告、控制和完成
3.110 测试管理过程（test management process）
用于协调、监控和控制测试的过程。
注 1： 见测试策略和计划过程 (3.128)、测试监测和控制过程 (3.113)、测试完成过程 (3.86)。
3.111 测试模型（test model）
测试项的测试模型表示，使测试集中于特定的特性或质量。
示例：需求陈述、等价类、状态转换图、用例描述、决策表、输入语法描述、源代码、控制流图、参数和值、分类树、自然语言。
注1： 测试模型和所需测试覆盖率用于确定测试覆盖率项。
注2： 在测试完成标准中，每种不同类型的所需测试覆盖范围都需要一个单独的测试模型。
注3： 测试模型可包括一个或多个测试条件（3.88）。
注4： 测试模型通常用来支持测试设计（例如，在 ISO/IEC/IEEE 29119-4 中用来支持测试设计，在基于模型的测试中使用）。其它类型的模型也用于支持测试的其它方面，如测试环境模型、测试成熟度模型和测试架构模型。
3.112 测试模型说明文档（test model specification document）
指定测试模型。
3.113 测试监控流程（test monitoring and control process）
测试管理过程的子过程。用以确保测试按照测试计划和组织级测试规格说明执行。
3.114 测试目标（test object）
执行测试的原因。
示例：检查执行是否正确、识别缺陷、衡量质量。
3.115 测试准则（test oracle）
确定测试通过或失败的信息来源：通常是用于为单个测试用例生成预期结果的规范，但也可使用其他来源，如将实际结果与其他类似程序或系统的结果进行比较，或询问人类专家。
3.116 测试准则难题（test oracle problem）
对于一组给定的测试输入和状态，确定测试 (3.82) 是通过还是失败的难题
3.117 测试计划
描述需要达到的测试目标以及实现该测试目标的方法和安排的文档,用于协调测试项的测试活动。
注1:一个项目可以有多个测试计划,例如可以有一个项目测试计划(也称为主测试计划),其包含了该项目所有的测试活动:更多测试活动的细节可在一个或多个测试子过程计划(即,系统测试计划或性能测试计划)中定义。
注2:通常测试计划是书面记录的,尽管其他的计划形式也可在组织或项目中局部定义。
注3:也可以为非项目活动编写测试计划,例如维护测试计划。
3.118 测试方针（test policy）
又名组织测试方针（test policy）。执行层面的文件，描述测试的目的、目标、原则和范围。
注1： 测试方针定义了测试的内容和预期达到的目标，但没有详细说明如何进行测试。
注2： 测试方针可为建立、审查和不断改进组织的测试提供一个框架。
3.119 测试实践（test practice）
便于实施测试的概念框架,该框架可应用于组织级测试过程、测试管理过程和/或动态测试过程。
3.120 测试规程（test procedure）
测试用例的执行序列,以及任何与构建初始前置条件所需的相关动作和执行后的收尾活动。
注1： 特定项目的测试规程可由多个测试级别和测试类型组成。
3.122 测试结果（test result）
指定的测试用例是否通过的标示,即观察到测试项输出的实测结果是否与预期结果一致或有偏差。
3.123 测试场景（test scenario）
作为生成测试用例基础的测试项的测试情景或设置。
3.124 测试脚本（test script）
又名：测试规程规格说明（test procedure specification）。
指定一个或多个测试程序的文档。
3.125 测试规格说明（test specification）
包含针对特定测试项的测试设计、测试用例和测试规程的全部文档集。
注释1： 测试规格说明可以在一份文件中详细说明，也可以在一组文件中详细说明，或以其它方式详细说明，例如在文件和数据库条目中详细说明。
3.126 测试状态报告（test status report）
3.127 测试策略（test strategy）
测试计划的一部分。描述对特定测试项目或测试子过程进行测试的方法。
注1： 测试策略通常描述以下部分或全部内容：将实施的测试级别和测试类型；将采用的重新测试和回归测试；将使用的测试设计技术和相应的测试完成标准；测试数据、测试环境和测试工具要求；以及对测试交付成果的期望。
3.128 测试策略和规划流程（test strategy and planning process）
用于设计测试策略，完成测试规划，创建和维护测试计划的测试管理流程
3.129 测试套件（test suite）
测试用例或测试规程的集。
注1： 测试套件的分组通常基于测试的执行时间。
3.130 测试类型（test type）
一组专注于特定质量特性的测试活动。
示例:信息安全性测试、功能性测试、易用性测试和性能测试。
试类型可以在单个测试子过程中执行或跨多个测试子过程执行(性能测试在组件测试子过程中完成,也在系统测试子过程中完成)。
3.131 测试（testing）
为发现和/或评价一个或多个测试项的属性而进行的一系列活动。
注:测试活动可包括针对测试的计划、准备、执行,报告和管理活动,其均与测试直接相关。
3.132 测试件（testware）
计划、设计和执行测试所需的、在测试过程中产生的制品。
注:测试件可以包括文档、脚本文件、输入、预期结果,文件,数据库、环境以及任何用于测试过程中附加的软件或设备。
3.133 无脚本测试（unscripted testing）
属于动态测试，测试人员的行为不受测试用例中书面指令的限制。
标签：微信,testing,几万万,测试用例,测试,test,执行,测试环境,软件测试 From： https://www.cnblogs.com/testing-/p/18350056