数字化测试的三个特征及能力建模

李侠，华为技术有限公司、数据通信系统测试高级专家（首席）。毕业后就职华为北京研究所，现为华为数据通信系统测试首席专家，目前主要负责数据通信产品系统测试技术研究和能力建设，构建数通数字化测试系统，保障路由器、交换机、安全网关等数据通信产品的测试设计、执行和评估的质量和效率。 擅长领域：测试对象建模、测试分析设计方法、韧性测试。      

大到国家的数字经济，小到企业的数字化变革，数字化成为最近几年各行各业的热门话题，那么到底什么是数字化？     提到数字化，很多人容易和信息化混淆，两者既有区别也有联系，也有不少专家对此进行了论述，本文尝试用另一个视角去看数字化，以及数字化为测试带来的变化。  

本书是麦克卢汉在1964年出版的《理解媒介》，是他关于媒介定律的开山之作，其中一段话对理解数字化有很好的启示：电子媒介是中枢神经系统的延伸，其余一些媒介，尤其是机械媒介，是人体个别器官的延伸。举个例子，我们的汽车是腿的延伸，电话是听觉的延伸，沿着这个思路，数字化本身也是一种电子媒介，它本质上是对人类神经系统的一种延伸。  

相对于信息化的管理思维，数字化是一种业务思维，如果把测试工作也看做一种业务，我们希望数字化为测试业务带来一种“延伸”，我们称这种延伸为“数字化测试”，按照实现的程度，数字化测试应该具备如下三个特征：        

特征一：连接   连接拓展测试感知。数字化能够记录从测试分析到设计、执行的测试业务全生命周期数据，并在这个数据基础上，建立更多的连接，构建更丰富的数据模型，实现全生命周期的数据闭环。这大大超过了我们通过阅读文档、面对面交流获取的信息和连接。           

特征二：智能 智能提升测试认知。基于数字化构建的测试连接，辅助以智能化技术，测试人员会加快、加深对被测系统的理解。         

特征三：数字世界 最后，随着数字化测试的不断发展，实现物理世界和数字世界的业务对象的一致，我们会在数字空间中构建一个与真实世界平行的测试孪生世界，从而，这个孪生世界将改变测试的工作模式。  

数字化要为业务带来增益，如果测试是一种业务，那么测试的业务目标是什么？     不论哪种类型的测试，测试的目标都围绕着覆盖全、周期短和成本低这三个核心目标。那么，数字化对这个目标有什么推动作用？我们通过三个维度进行对比分析：          

用例有效   传统测试工作主要依赖于个人经验和知识，数字化以后，将会引入知识工程和程序分析技术，能够帮助测试更快更好地获取输入信息。          

过程高效   传统测试过程依赖人工操作和自动化运行，随着数字化的发展，将会变成知识驱动和AI使能，使测试更趋近于超自动化。          

闭环增效   在测试的持续改进闭环上，传统做法是人工开展缺陷分析，做一些缺陷的总结。数字化以后，可以通过数字世界的测试数据闭环来实时完成测试业务闭环改进。  

数字化测试也是产业发展对测试的诉求。以华为数据通信产品测试为例，演进历程分为三代：1.0->2.0->3.0。在1.0->3.0的过程中，被测系统从一个简单的计算机网络、1G带宽，单核单进程的系统，演进到全速率、全连接和全系统。测试系统随着被测系统的演进也是在不断变化的。最初在1.0阶段，测试工作主要是用例手工执行，以覆盖功能为目标。2.0阶段，引入了DFX测试、场景测试、自动化工厂和自研工具。3.0阶段，传统的测试很难再满足被测系统的演进，需要测试具备海量场景覆盖的能力、更高可靠性和安全韧性测试的能力、组件测试的能力，这对测试提出了更高的要求。  

被测系统的变化直接驱动了测试的变化，测试想要看清被测对象，讲清测试覆盖，就必须思考要做怎样的改变。结合数字化，我们提出了构建被测系统的数字孪生，构建测试能力的数字大脑。被测系统的数字孪生，指将我们对被测系统的理解转换为数字世界的模型，测试能力的数字大脑，指将测试人员多年积累的测试能力进行数字化沉淀。
  基于这样一个目标，把整个测试设计分解为三个要素：

要素一：测试对象数字化建模

要素二：测试能力数字化沉淀和演进

要素三：测试设计数字化，高效构建测试系统。  

要想数字化测试对象，先要“解构”被测系统。这里引用钱学森钱老对系统的定义“系统是由相互作用、相互依赖的若干组成部分结合而成，具有特定功能的有机整体，而且这个整体又是从属于它的更大系统的组成部分”。这个定义里有两个关键要素，一个是“组成部分”，即系统元素，一个是“相互作用相互依赖”，即系统关系。被测系统，既然是一个系统，就一定具备这两个要素。   解构被测系统，就是以测试（用户）的视角建模系统元素和系统关系。上图以路由器为例，单机系统由组件（含软件和硬件）组成，多个单机系统又可以组成解决方案。如果以单机系统为被测系统，用户可见的特性和硬件可以提取为系统元素，解决方案场景（简称场景）和系统实现机制（简称机制）因为决定了特性和硬件相互作用相互依赖的方式，可以提取为系统关系，其中场景确定了特性的应用组合关系，机制决定了特性的实现依赖关系。总结来说，解构被测系统，就是以用户的视角找到系统元素，然后再根据应用和实现上的约束找到系统关系。  

找到被测系统的系统元素和系统关系后，就可以对被测系统进行测试建模。这里有两个概念容易混淆，一个是被测系统，一个是测试对象，本文中被测系统是客观存在的系统，也就是开发人员开发出来的，能够卖给用户的产品，而测试对象是测试如何看待一个被测系统，是测试语言描述的被测系统，是通过解构被测系统得到的系统元素和系统关系，重构成测试对象。

上图以路由器为例，基于“特性”这个系统元素建模测试对象，可以采用共性特征聚合的建模方法，具备共性特征的一组特性抽象为一类测试对象，如IP路由、IP业务等。对于同一类测试对象，可以按照对象业务演进过程继续逐级细化，如对于一个路由协议，首先要能够建立邻居，建好邻居以后能够发布路由，发布路由以后因为路由过大，需要区域和进程进行隔离控制，因为需要过滤不同的路由，又产生了策略和过滤器等，这些可以作为路由这个测试对象的细化分析维度。   针对每一个细化后的测试对象，都有属于这个对象的“属性”，相比开发的设计规格，“属性”更接近产品规格，是从用户使用的角度结构化一个测试对象。如IP单播邻居，从外部来看，有邻居状态、邻居容量等性能指标，从内部来看，有多种影响因素，如系统资源使用情况等。  

测试能力数字化是数字化测试的第二个要素，相对测试对象数字化难度更大。因为“能力”这个词语不仅与知识相关，还与经验相关。要想数字化测试能力，首先要对测试能力进行结构化定义。上图以数据通信产品的测试能力为例，匹配系统工程能力架构做了分层聚合，自顶向下分别是流程层、逻辑层和技术层：          

 流程层 流程层描述的是测试业务流对应的作业活动能力，如测试分析能力、测试策略制定能力、测试设计能力等，主要是根据测试活动构建。            

 逻辑层   逻辑层是支撑测试作业活动的作业基础能力。以上图为例，要做测试分析，需要完成组网分析、部署分析和行为分析，要做测试设计，需要完成因子设计、判定设计和用例生成等。 如果一个能力包含很多内容，很难做到很好的聚合，可以再进行分层。以上图为例，逻辑层又分为组合构件和基础构件，组合构件是对流程层能力的分解，如测试分析能力分解为静态组网分析能力、业务部署分析能力和动态行为分析能力，基础构件是测试作业的原子能力，如报文的行为，操作的行为，流量的行为等。组合构件由基础构件支撑实现，如动态行为分析由报文行为、流量行为等组成。           

技术层   技术层是专业的测试能力，这些专业测试能力包括质量属性测试技术，也包括通用技术。质量属性测试技术包括不同质量属性的测试模式分析能力、测试设计能力和判定设计能力以及评估能力。通用技术如AI、程序分析、知识图谱等，这些目前在各个领域应用比较好的技术都可以拿来为测试服务。  

下面详细介绍测试能力数字化中的两个能力，作业基础能力和专业能力。上图展示了对动态行为分析这个作业基础能力的分析过程。首先对动态行为这个概念做一个解读，所谓的动态行为是相对于静态组网来说的，以路由器为例，设备上网运行后，组网基本上是确定的，静态就是体现这种相对很少变化的特点。而动态行为指设备上网运行后，由于外部和内部影响因素的不断变化，会对被测系统产生不同的激励，动态就是体现这种实时变化的特点。   对于动态行为，分为外部和内部两种影响因素，从外部来看，有配置操作、网络事件等变化，还可能有攻击等安全事件。从内部来看，来自系统的架构以及设计的影响，如定时器变化。基于这个分析，对动态行为的数据模型进行分类，分为配置类、操作类、资源类、网络事件类、报文类和流量类。对其中的流量类再进行展开分析，如果要描述一个流量的数据模型，先要定义一条流量。一条流量的变化来自于流量内容变化和流量发送特征变化，其中流量内容变化就是流量涉及报文的字段变化，流量发送特征变化包括发送/接收的端口变化、发送速率变化、发送时长变化等，这些就组合成描述一条流量的维度。确定了流量数据模型的维度，就可以定义每个维度的默认值和取值范围，只要对这些数据模型的不同字段进行赋值，就可以变化一条流量。  

下面介绍专业能力，专业能力大部分来自质量属性的测试能力，以上图为例，质量属性与设计同源，对运行类质量属性进行分解，分解出来的每种测试能力都会数字化一个测试模式库。测试模式库是测试模式的集合，测试模式是对产品实际应用中普遍存在（反复出现）的各种缺陷，所提取的可复用的测试方法和手段，是测试知识积累固化的核心资产。测试模式库有四个来源，正向来源包括业界标准，现网应用和设计规范，而逆向来源主要是缺陷分析或者问题改进。   数字化测试模式库与传统测试模式库的区别在于，测试模式中的信息如何转换为数字化表示。测试模式主要包含两类信息，测试步骤和预期结果，测试步骤可以分解为不同的动态行为，预期结果可以体现为结果判定。动态行为之前我们已经讲过，不同质量属性的相同动态行为复用相同的行为模型，通过不同的数据进行区分，结果判定在本文后续的讨论中讲解。每一条测试模式，用这样的数字化方式描述，形成一个数字化测试模式库。  

在测试对象数字化和测试能力数字化之后，就可以开展测试设计了。这里所说的测试设计数字化，更多的是说怎么用测试对象数字化和测试能力数字化，快速实现测试设计。
以上图为例，左上角展示了特性、架构和硬件三个测试对象大类，以及每个大类细化的测试对象小类，特性对象大类细化到了单播邻居、单播路由，架构对象大类细化到了消息，硬件对象大类细化到了主控板。右上角展示了可靠性测试能力，其中网络级可靠性细化到震荡、超限，网元级可靠性细化到故障。  

在讨论测试对象和测试能力如何相互作用之前，先回顾一下什么是测试？测试就是对被测对象进行一系列操作，评估预期结果是否达到用户要求的过程。如果把一系列操作提取为测试模式，测试就是在测试对象上应用某些测试模式，测试设计就是找到测试对象和测试模式的应用关系。

传统的测试设计依赖测试人员的知识和经验，通过把测试对象和测试模式之间的关系抽象为规则，可以将这种依赖降低到最低。如“单播邻居”是一个与状态相关的对象，“震荡”是一个对状态进行变化的模式，那么“单播邻居 + 震荡”就形成了交互关系，同时“单播邻居”也是一个与容量相关的对象，“超限”是一个对容量变化的模式，那么“单播邻居 + 超限”就形成了另一个交互关系。这种交互结果称为“测试因子”，可以类比看做测试对象类的预制件，比如单播邻居这个测试对象下有一个或多个方法（测试因子）。

当单播邻居这个对象下的具体特性（如ISIS）实例化的时候，可以直接继承单播邻居的测试因子，并对测试因子中的具体操作进行实例化。   自动化架构也按照上述过程进行组织，具体的架构可能不同，建议分别构建测试对象、测试模式类，测试因子是测试对象和测试模式交互后的方法，可以实现测试设计的快速拼装。  

上图展示了一个完整的测试过程，图中包含设计空间和测试空间，设计空间里包括设计的过程交付和资产，测试空间包含从测试分析到测试执行的活动，右上角是数字化的模式库，包括测试对象库、测试模式库和测试因子库，这些资产库支撑测试设计。下面完整描述一个数字化测试设计活动如何开展：  

首先，由设计空间场景库导入需求，包括组网硬件以及对应的业务部署，同时从设计文档和测试模式库中提取行为分析，这部分导入和提取的工作都是由作业基础能力来完成，即组网分析能力、业务部署分析能力和动态行为分析能力。  

之后，进入测试设计阶段，这里采用了逻辑、数据和判定分离的思想，将测试设计分为三个引擎，测试设计引擎、测试数据引擎和测试判定引擎。测试设计引擎是测试威廉希尔官方网站 的集成，提供处理周期技术（PCT）、状态转换技术（STT）、数据组合技术（DcoT）等算法。测试数据引擎是根据业务数据模型，生成实例化测试数据，同时实现数据FUZZ，也就是根据数据的取值范围，通过数据引擎进行FUZZ操作。测试判定引擎是对已经明确的协议标准、设计规范，提取判定规则。传统的测试用例每个用例都要自己编写预期结果，依赖个人能力，即使提取一些公共检查，也仅限于资源等通用检查，而判定引擎除了通用检查，更多的是业务层面的判定生成。这三个引擎可以在测试设计中被直接调用，相比之前每一个用例都是烟囱式构建，数字化后的测试设计是自动且复用的，既提升了测试设计效率，也减少了测试设计的质量差异。同时，这三个引擎的能力是开放的，可以根据测试能力的不断提升去完善。  

基于前面的数字化测试设计，我们实现了一些应用。上图展示的数字化测试应用是测试连接设计，这里的连接包含两个信息，一个信息是测试同源设计，一个信息是自动分析。测试同源设计指数字化后，同源了场景树、功能和组件，按照测试对象数字化模型自动导入设计信息。自动分析指针对导入信息，可以通过作业基础能力里的静态组网分析能力自动生成组网，通过作业基础能力里的静态组网分析能力自动提取动态行为模型，这里需要构建数字化模型的时候，定义一些文档描述范式，这样就可以基于范式的规则来提取。   测试连接设计有什么好处呢？最直接的好处就是做到了全生命周期数据的闭环，不会因为某个测试人员或者开发人员的离开，而导致这部分信息的断链。  

上图展示的数字化测试应用是测试连接标准。对于数据通信领域，协议一致性是一个重要的测试活动，用来验证产品是否满足协议标准的要求。数字化以后，我们可以把协议的标准顺从表直接转换成一个报文的因子库，具体做法就是根据标准分析提取出关键字段，确定字段取值范围。然后通过协议标准分析，提取协议测试模型，这个测试模型通常是一个处理周期模型，最后将报文注入测试模型，就可以完成测试设计。这里面还有一个隐含技术，就是报文的自动化封装。报文的编解码都是通过自动化编写一个框架和逻辑来实现的，当协议标准发生变化时，直接映射到报文因子有变化，或者测试模型有变化，通过修改报文因子和测试模型，就可以完成对标准变化的闭环。  

上图展示的数字化测试应用是测试连接客户场景。这里的连接主要指将客户场景和测试设计关联起来，这里引入场景因子的概念，场景因子是基于网络分层架构，按照客户场景的典型应用方案，把整个网络分成应用层、网络层、链路层和物理层，然后针对每层抽象对接的业务，如网络层抽象出公网信令场景，再抽象出域内公网单播信令场景因子。通过逐级抽象，最终形成场景因子库，场景因子是场景拼装的组件，可以完成一个新的场景。

当一个新的用户场景出现时，根据用户场景的特点，选取合适的场景因子，并基于场景库的维度进行交互分析，如信令层面有什么样的交互，隧道层面有什么样的交互等，用这种方式完成新场景的拼装。当外部客户场景发生变化，会同步触发分层架构建模的场景因子变化，继而直接影响测试设计变化，所以测试设计到用户场景的闭环也是打通的。  

除了以上的应用，我们还期望数字化能够给测试带来什么？让我们再基于数字化的几个特征做一些展望。第一个是连接拓展测试感知，上图展示了两种连接：测试对象的连接、测试模式的连接。测试对象的连接，就像人脑一样，人脑神经的连接越多，对事物的认识就越深刻、越迅速，效率也越高。那么怎样才能把连接提升起来呢？上图右边的两张图给出两个方式，一个是inside/内部视角，一个是outside/外部视角。内部视角就是我们怎么认知被测系统，在对测试对象的不断细化过程中，最后细化到属性的时候，实际是外部视角和内部视角的对接界面。比如我们细化一个IP路由对象，从IP路由->单播邻居->影响因素，数字化前测试人员可能只知道单播邻居与接口相关，在inside视角下，程序分析会帮助测试人员打开实现单播邻居的这段代码，识别出一些规则特征，比如单播邻居与xx索引、xx表项有关系，这是测试人员以前所感知不到的，这就是从inside视角对测试对象连接进行了更深入的挖掘。除了建立更深的连接外，数字化还可以帮助测试人员建立更广的连接。在inside视角挖掘过程中，还可以建立从邻居->接口->硬件端口的连接，这些在数字化前测试人员是很难感知到的。

测试模式的连接，多数是从外部视角来看的，比如网络上有一些震荡，这些震荡影响了邻居，就建立了邻居和震荡之间的连接。这是一个简单的例子，如果引入机器学习技术，会发现之前想象不到的一些连接会建立起来，比如说芯片的休眠和接口震荡是不是有联系，以测试人员的知识和经验并不知道，当数字化以后，它就变成了一种可能性，会发现很多以前所不知道的连接，这是最有趣的地方。古代的时候，有句谚语：早霞不出门，晚霞行千里，现在我们知道这是有科学依据的，但是对古人来说，是通过几代人经验总结下来的，并不知道具体的科学依据。这和连接拓展感知有点像，就是通过一些数字化的方式，引入更多技术，让测试人员在不用关注内部细节的情况下，拓展理解被测系统的能力和提取测试方法的能力。  

第二个特征是智能提升测试认知。这里智能就是AI，上图列举了测试活动所涉及到的一些AI技术，以及期望能给测试带来哪些提升。如果说连接是帮测试人员找到感知不到的信息，那么AI则能帮助他们分析和决策，比如利用AI技术可以识别相关性很高的用例，能做到智能推荐、智能筛选，AI也可以帮助测试人员识别一些风险，去提升测试人员的学习和分析决策能力。AI有很多技术都可以使用在测试领域，包括知识图谱、机器学习、深度学习和语言处理。这些技术可以同时应用在开发领域和测试领域，在测试领域的作用会更大，因为对于开发来讲，是从无到有去构建一个系统，每一行代码都是确定的，即使在集成为一个系统以后可能会出现问题，那些问题主要是测试人员挖掘的范围。测试就像在一个浩瀚的茫茫大海里找东西，这个难度是非常高的，在不可能穷举所有问题的情况下，怎样高效地挖掘出最有价值的问题，就是测试的目标。AI技术能够帮助测试缩小范围，或者找到推荐的方向。  

第三个特征是数字世界改变工作模式。上图是对数字化后测试模式的展望，构建数字化测试系统，以目标系统的视角，测试评估从“执行评估—>设计执行双评估”。传统测试都是围绕着开发做的交付系统进行评估，数字化后，测试和开发同源同一个目标系统，测试和开发都根据对目标系统的理解去开展工作，开发和设计基于系统架构构建被测系统，测试从用户视角构建测试系统，在这个过程中，测试并不是一直等到最后编码结束才去做测试执行验证，而是在设计过程中，针对设计系统进行反馈和评估，在编码完成之后，针对交付系统进行一个执行评估。比如通过测试设计发现场景库遗漏，发现功能有遗漏，这是对设计系统的评估，系统交付后可以用用例和自动化脚本对交付系统进行评估。这个过程正好是设计与测试、开发与测试相互校验的过程，需求分析和系统设计以及编码过程中都会产生缺陷，而每一个阶段的缺陷在本阶段被发现就是最高效的。   数字化不是一个具体技术，它改变的是测试人员的思维方式，改变的是整个测试业务模式。数字化是从数据到业务，通过数字化技术使能业务创新。理解数字化并把它带入测试领域，会带来意想不到的视角和能力提升。    

编辑：黄飞