CN110659215A - 一种开放式工业app快速开发及测试验证方法 - Google Patents

Abstract

本发明属于APP开发测试领域，具体提供一种开放式工业APP快速开发及测试验证方法，包括：接口检测步骤，使用虚拟检测系统对各功能模块的各接口进行检测；第一修复步骤，当接口检测步骤的检测结果为存在BUG时，对该BUG进行修复，并返回接口检测步骤；冲突检测步骤，当接口检测步骤的检测结果为无BUG时，使用虚拟检测系统对各功能模块进行交叉事件检测；第二修复步骤，当冲突检测步骤的检测结果为存在BUG时，对该BUG进行修复，并返回冲突检测步骤；封装步骤，将通过冲突检测步骤的各功能模块进行封装，得到工业APP；整体检测步骤，对工业APP进行检测。使用本方法，可以缩短工业APP的整体开发时长。

Description

一种开放式工业APP快速开发及测试验证方法

技术领域

本发明属于APP开发测试领域，尤其涉及一种开放式工业APP快速开发及测试验证方法。

背景技术

工业互联网APP，简称工业APP，是基于工业互联网，承载工业知识和经验，满足特定需求的工业应用软件，是工业技术软件化的重要成果。

相对于传统工业软件，工业APP具有轻量化、定制化、专用化、灵活和复用的特点。工业APP体系框架是一个三维体系，包含了工业维、技术维和软件维三个维度。三个维度彼此呼应，和谐地构成和体现了“工业·技术·软件(化)”的工作主旨。

和普通的APP相比，由于工业APP的使用环境较为特殊，其对于稳定性的需求程度较高。

现有的APP开发的常规流程是，首先开发各功能模块，并对各功能模块进行简单的测试后封装，之后，对整体APP进行完整的测试。这样的好处是，只需要在完成封装后进行完整的测试即可。对于普通的APP，这样的开发流程能够保证较高的效率。

但工业APP由于其对稳定性的要求较高，进行测试时采用测试用例很系统、复杂，并且，一旦检测结果中出现了任何小BUG，必须找到相应的功能模块进行修复，之后再组装、再检测，直到通过检测。用常规APP开发的方法来开发工业APP，检测的时间会拉得很长,从而使得工业APP的整体开发的时间拉得很长。

发明内容

本发明针对常规的APP开发方法来开发工业APP时，整体开发的时间会拉得很长的问题，提供了一种开放式工业APP快速开发及测试验证方法。

本发明提供的基础方案为：

一种开放式工业APP快速开发及测试验证方法，包括：

功能模块开发步骤，对工业APP的各功能模块分别进行开发；

接口检测步骤，使用虚拟检测系统对各功能模块的各接口进行检测；

第一修复步骤，当接口检测步骤的检测结果为存在BUG时，对该BUG进行修复，并返回接口检测步骤；

冲突检测步骤，当接口检测步骤的检测结果为无BUG时，使用虚拟检测系统对各功能模块进行交叉事件检测；

第二修复步骤，当冲突检测步骤的检测结果为存在BUG时，对该BUG进行修复，并返回冲突检测步骤；

封装步骤，将通过冲突检测步骤的各功能模块进行封装，得到工业APP；

整体检测步骤，对工业APP进行检测；

第三修复步骤，当整体检测步骤的检测结果为存在BUG时，对该BUG进行修复，并返回整体检测步骤。

名词解释：

虚拟检测系统，用于程序测试的检测系统，可设置于服务器中，使用虚拟检测系统，不用等到APP后端开发完成即可对APP进行检测。

交叉事件检测，又叫冲突测试，是对当短信、电话等其他软件进入时，是否会影响APP功能正常使用的一种测试。

基础方案工作原理及有益效果：

由于在整体检测步骤前，工业APP中的各功能模块已经通过了接口检测步骤及冲突检测步骤的测试，各功能模块的各功能接口均可以正常工作，并且，各功能模块在各种交叉事件下的性能也能保持稳定，即，规避了各个功能模块之间发生功能冲突的情况。和普通的开发方法相比，工业APP进行整体检测时，检测出BUG的可能性降低了很多。并且，即使检测出BUG，其BUG的类型范围也缩小了很多，调节起来也会很快。

由于各功能模块是同步进行开发，各功能模块的第一检测及第二检测可以同步进行，不存在先后顺序，和常规的APP开发方法，仅对各功能模块进行基础测试相比，不会多用太多的时间。且工业APP封装后的检测，减小了产生BUG产生的概率和数量，还缩小了APP封装后产生BUG的类型种类，排查、调试或修改起来都会快速许多。和现有技术相比，能够缩短工业APP的整体开发时长。

进一步，接口检测步骤包括：

检测请求子步骤，向第一服务器发送第一检测请求信号；

接口确定子步骤，根据第一检测请求信号，通过第一服务器在接口文档中找到对应的第一接口；

接口状态检测子步骤，检测第一接口的状态，第一接口的状态包括开启和关闭；

返回数据子步骤，当第一接口的状态为开启时，根据接口文档从第一接口获取返回数据，并根据第一检测请求信号的请求类型与返回数据的格式之间的映射关系，确定返回数据的第一格式，将返回数据按第一格式封装生成第一封装数据，并返回给待测功能模块；

第一检测子步骤，根据接收到的第一封装数据，检测功能模块是否存在BUG；

第一修复步骤中，当第一检测子步骤的检测结果为存在BUG时，对该BUG进行修复，并返回检测请求子步骤。

名词解释：接口文档，即，对接口进行说明的文档，一般接口文档包含了功能、请求方式(GET/POST)、地址、参数、返回值、请求示例、返回示例以及全局的安全验证方式、错误码等信息。

这样，能够通过虚拟检测系统，对各功能模块的各接口的性能进行测试，当功能模块的接口存在问题时，如，某个功能模块的负责输入数据的接口存在问题，不能进行数据输入时，可及时发现问题，并在封装前进行修复。当一个功能模块存在多个接口时，只需将这些接口分别作为第一接口进行检测即可。

进一步，检测请求子步骤中，向第一服务器发送带有第二服务器参数的第一检测请求信号；

数据返回子步骤中，当第一接口的状态为关闭时，获取第二服务器参数，并根据第二服务器参数分析对应的第二服务器，将第一检测请求信号发送给对应的第二服务器，并获取该第二服务器的反馈数据后，将反馈数据发送给功能模块；

第一检测子步骤，根据接收到的第一封装数据或反馈数据，检测功能模块是否存在BUG。

这样，能够对各功能模块的各接口的各种状态进行检测，检测的过程更加充分，封装后出现BUG的可能性更低。

进一步，功能模块开发步骤中，各功能模块的接口采用的数据格式为json格式。

与xml格式相比，json格式有格式简洁和层次结构清晰的特点，易于人阅读和编写，同时也易于机器解析和生成，可以有效地提升网络传输效率，进而提高整体的测试效率。

进一步，冲突检测步骤包括：

冲突检测请求子步骤，发送交叉事件检测请求信号；

获取测试用例子步骤，根据接收到的交叉事件检测请求信号，确定功能模块的待测试项，再根据待测试项，从第三服务器中获取匹配的自动化测试用例集；

第二检测子步骤，执行获取的自动化测试用例集，对功能模块进行交叉事件检测；

第二修复步骤中，当第二检测子步骤的检测结果为存在BUG时，对该BUG进行修复，并返回冲突检测请求子步骤。

这样，能够对各功能模块在各种交叉事件，即，冲突事件下的表现进行检测。

进一步，获取测试用例子步骤中，自动化测试用例集包括指定交叉事件和随机交叉事件。

这样，能够对功能模块在各种交叉事件下的表现进行检测。

进一步，获取测试用例子步骤中，自动化测试用例集的指定交叉事件来源于正常事件交叉关系库的必选项事件，以及异常操作事件库的必选项事件；随机交叉事件来源于正常事件交叉关系库的可选项事件，以及异常操作事件库的可选项事件。

这样得到的自动化测试用例集的包含范围更广，既包含了各种常规的交叉事件用例，同时也包含了各种极端情况才会出现的非常规交叉事件用例，能够对各功能模块进行更为充分的交叉事件检测。

进一步，获取测试用例子步骤中，自动化测试用例集的生成过程为：将指定交叉事件和随机交叉事件导入用例模型库中，模型库分别生成指定交叉事件的自动化测试用例和随机交叉事件的自动化测试用例，并构成自动化测试用例集。

这样，能够生成各功能模块对应的自动化测试用例集。

进一步，还包括更新步骤，当整体检测步骤的检测结果为存在交叉事件型BUG时，根据BUG的内容，更新正常事件交叉关系库和/或异常操作事件库中的数据。

这样，能够不断完善冲突检测步骤，使冲突检测步骤的检测更加充分。

进一步，整体检测步骤中，用虚拟检测系统对工业APP进行检测。

使用了虚拟检测系统对封装后的APP进行检测，不用等到后台数据接口开发完成，即可对APP进行检测，可以进一步提高工业APP开发的整体效率。

附图说明

图1为本发明一种开放式工业APP快速开发及测试验证方法实施例一的流程图；

图2为图1中接口检测步骤的内部流程图；

图3为图1中冲突检测步骤的内部流程图。

具体实施方式

下面通过具体实施方式进一步详细说明：

实施例一

本发明一种开放式工业APP快速开发及测试验证方法依托于一种模拟测试系统。

该模拟测试系统包括开发端、第一服务器、第二服务器和第三服务器。在应用程序开发过程中，开发端可登录第一服务器获取用于参数配置的web页，通过web页，开发端可以为待测APP的接口文档中的所有接口配置第二服务器参数、返回数据和开关状态，并将配置好接口的接口文档保存于第一服务器。通过第二服务器参数，可找到对应的第二服务器。

除此，开发端可经由web页动态修改待测APP的各个接口对应的当前配置好的第二服务器参数、返回数据及/或开关状态信息，以便待测APP进行各种模拟mock测试，如返回数据的测试等。

某个接口的当前开关状态为开状态，通过所述web页，可以将该接口的开关状态修改为关状态。这样，能够对带检测功能模块的各个接口的各种状态进行检测。

第三服务器中存储有自动化测试用例集，自动化测试用例集包括指定交叉事件和随机交叉事件。具体的，自动化测试用例集的生成过程为：将指定交叉事件和随机交叉事件导入用例模型库中，用例模型库分别生成指定交叉事件的自动化测试用例和随机交叉事件的自动化测试用例，并构成自动化测试用例集。

其中，指定交叉事件来源于正常事件交叉关系库的必选项事件，以及异常操作事件库的必选项事件；随机交叉事件来源于正常事件交叉关系库的可选项事件，以及异常操作事件库的可选项事件。这样得到的自动化测试用例集，既包含了各种常规的交叉事件用例，同时也包含了各种极端情况才会出现的非常规交叉事件用例。

根据自动化测试用例集和设备的配置，生成设备可识别的配置文件作为后续自动化测试的输入。如何生成配置文件属于本领域技术人员的常规技术，在此不再赘述。

用这样的自动化测试用例集进行交叉时间测试，能够充分的检测带检测功能模块在各种交叉事件，即，冲突事件下的表现。

如图1所示，一种开放式工业APP快速开发及测试验证方法，包括：

功能模块开发步骤，对多个功能模块分别进行开发。

接口检测步骤，使用虚拟检测系统对各功能模块的各接口进行检测；具体的，如图2所示，接口检测步骤包括：

检测请求子步骤，向第一服务器发送带有第二服务器参数的第一检测请求信号。

接口确定子步骤，根据第一检测请求信号，通过第一服务器在接口文档中找到对应的第一接口。

接口状态检测子步骤，检测第一接口的状态，第一接口的状态包括开启和关闭；

返回数据子步骤，当第一接口的状态为开启时，从第一接口获取返回数据，并根据第一检测请求信号的请求类型与返回数据的格式之间的映射关系，确定返回数据的第一格式，将返回数据按第一格式封装生成第一封装数据，并返回给待测功能模块；当第一接口的状态为关闭时，获取第二服务器参数，并根据第二服务器参数分析对应的第二服务器，将第一检测请求信号发送给对应的第二服务器，并获取该第二服务器的反馈数据后，将反馈数据发送给功能模块。

第一检测子步骤，根据接收到的第一封装数据或反馈数据，检测功能模块是否存在BUG。

第一修复步骤，当第一检测子步骤的检测结果为存在BUG时，对该BUG进行修复，并返回检测请求子步骤。

当一个功能模块存在多个接口时，只需将这些接口分别作为第一接口进行检测即可。本实施例中，第一接口采用的数据格式为json格式，与xml格式相比，json格式有格式简洁和层次结构清晰的特点，易于人阅读和编写，同时也易于机器解析和生成，可以有效地提升网络传输效率，进而提高整体的测试效率。

通过接口检测步骤，可对功能模块的各接口进行检测，看各接口是否存在问题，并可以在将各功能模块组装以前进行修复，将经过接口检测步骤的功能模块组装起来时，各功能模块的自身功能已经通过了检测，可以缩短测试的整体周期。例如，某功能模块用于数据输入的接口出现了问题，若没有接口检测步骤，直接组装起来后，APP的该功能模块将不能进行数据输入，由于组装起来后才发现该问题，需要将对应的功能模块进行修复后，再组装，之后再测试，直到所有功能都可以正常进行。这样，测试的周期会被拉得较长。

冲突检测步骤，当接口检测步骤的检测结果为无BUG时，使用虚拟检测系统对各功能模块进行交叉事件检测；具体的，如图3所示，冲突检测步骤包括：

冲突检测请求子步骤，发送交叉事件检测请求信号；

获取测试用例子步骤，根据接收到的交叉事件检测请求信号，确定功能模块的待测试项，再根据待测试项，从第三服务器中获取匹配的自动化测试用例集；

第二检测子步骤，执行获取的自动化测试用例集，对功能模块进行交叉事件检测。

第二修复步骤，当第二检测子步骤的检测结果为存在BUG时，对该BUG进行修复，并返回冲突检测请求子步骤。

通过冲突检测步骤，可对功能模块在交叉事件下，即冲突事件下的稳定性进行检测，测试的内容如当切换不同的网络环境时，是否会影响功能使用；当有短信、电话等其他软件进入时，是否会影响功能的正常使用；前后台切换是否影响其功能的正常使用等。

这样，将通过冲突检测步骤的功能模块组装起来后，由于各功能模块已经通过了交叉事件的测试，APP测试时，其交叉事件存在问题的可能性得到降低了许多，可提高整体开发的流畅性。同时，各功能模块的冲突检测步骤不存在时间上的冲突，可以同时进行，APP的整体开发流程降低了很多。例如，某个功能模块与手机的短信功能之间存在冲突，即，在使用该功能模块时，若手机收到短信，该功能模块会崩溃。通过冲突检测步骤，可以在组装前发现该BUG。如果组装完成后再进行检测，组装完成才发现该问题，需要将对应的功能模块进行修复后，再组装，之后再测试，直到APP通过交叉事件测试。这样，测试的周期会被拉长。

封装步骤，将通过冲突检测步骤的功能模块进行封装。本实施例中，采用微服务架构进行开发与封装；这样的好处是，由于采用了微服务架构，出现BUG时，可以更好的对BUG进行隔离，之后，对出现BUG的相关部分进行更改即可；并且，微服务架构还拥有灵活的可扩展性，非常适合大型的工业APP的开发与封装。

整体检测步骤，对封装后的APP进行检测。

第三修复步骤，当整体检测步骤的检测结果为存在BUG时，对该BUG进行修复，并返回整体检测步骤。

更新步骤，当整体检测步骤的检测结果为存在交叉事件型BUG时，根据BUG的内容，更新正常事件交叉关系库和/或异常操作事件库中的数据。通过更新步骤，能够不断完善冲突检测步骤，使冲突检测步骤的检测更加充分。

由于本方法中，使用了虚拟检测系统，对封装后的APP进行检测时，同样可用虚拟检测系统，这样，和常规检测相比，不用等到后端系统开发完成，即可对APP进行检测，可以进一步提高工业APP的整体开发流程。

同时，由于在第三检测步骤前，工业APP中的各功能模块已经通过了接口检测步骤及冲突检测步骤的测试，各功能模块的各功能接口均可以正常工作，并且，各功能模块在各种交叉事件下的性能也能保持稳定。和普通的开发方法相比，工业APP进行整体检测时，检测出BUG的可能性降低了很多。并且，即使检测出BUG，其BUG的类型范围也缩小了很多，调节起来也会很快。

使用本方法，由于各功能模块是同步进行开发，各功能模块的第一检测及第二检测可以同步进行，不存在先后顺序，和常规的APP开发方法，仅对各功能模块进行基础测试相比，不会多用太多的时间。且工业APP封装后的检测，减小了产生BUG产生的概率和数量，还缩小了APP封装后产生BUG的类型种类，排查、调试或修改起来都会快速许多。和现有技术相比，能够缩短工业APP的整体开发时长。

实施例二

与实施例一不同的是，本实施例中，还包括

存储步骤，对检测出的BUG进行存储；

BUG辅助修复步骤，当出现BUG时，根据BUG的类型，对BUG进行辅助修复。

具体的，BUG修复步骤包括：

BUG位置预判子步骤，根据代码量及代码的逻辑复杂度，预判BUG出现的位置；

BUG难度预判子步骤，根据预判的BUG的位置，以及BUG的类型，预判BUG的修复难度；

BUG复现率预判子步骤，将BUG与已存储的BUG进行匹配，根据BUG类型出现的频率，预判BUG的复现率。复现率，也就是相同BUG再次出现的概率。

修复人员推荐子步骤，根据预判的BUG修复难度以及BUG复现率，推荐修复人员；当修复难度高于N且BUG复现率低于M时，推荐高级技术人员进行BUG修复；当修复难度高于N且BUG复现率不低于M，或修复难度不高于N且BUG复现率低于M时，推荐中级技术人员进行BUG修复；当修复难度不高于N且BUG复现率不低于M时，推荐低级技术人员进行BUG修复。

使用本方法，当接口检测步骤、冲突检测步骤或者整体检测步骤的检测过程中出现BUG时，BUG位置预判子步骤根据代码量以及代码的路基复杂度，对BUG的位置进行预判，这样，可将技术人员的排查范围缩小到一个很小的范围，减小技术人员的工作量，提高BUG排查的效率，进一步提高APP的整体开发效率。

BUG难度预判子步骤根据预判的BUG的位置，以及BUG的类型，预判BUG的修复难度；同时，BUG复现率预判子步骤将BUG与已存储的BUG进行匹配，根据BUG类型出现的频率，预判BUG的复现率。通过修复难度和复现率，可预判修复该BUG对技术人员的能力要求，修复难度越大说明BUG的技术难度越高，复现率越低则说明BUG越不常见，修复使用的技术越冷门。

因此，修复人员推荐子步骤，根据BUG的修复难度及BUG的修复率，推荐对应等级的技术人员来进行修复，推荐的策略如下表所示。其中N和M的具体数值，本领域技术人员可依据开发团队的工作习惯具体设置。

这样，可以充分发挥利用各技术人员的能力，可减少出现将技术牛人安排去修复简单BUG，浪费人才资源，或者安排经验较差、能力较弱的技术人员去修复很难的BUG，效率低下，影响工业APP整体开发进度的情况。

以上所述的仅是本发明的实施例，方案中公知的具体结构及特性等常识在此未作过多描述，所属领域普通技术人员知晓申请日或者优先权日之前发明所属技术领域所有的普通技术知识，能够获知该领域中所有的现有技术，并且具有应用该日期之前常规实验手段的能力，所属领域普通技术人员可以在本申请给出的启示下，结合自身能力完善并实施本方案，一些典型的公知结构或者公知方法不应当成为所属领域普通技术人员实施本申请的障碍。应当指出，对于本领域的技术人员来说，在不脱离本发明结构的前提下，还可以作出若干变形和改进，这些也应该视为本发明的保护范围，这些都不会影响本发明实施的效果和专利的实用性。本申请要求的保护范围应当以其权利要求的内容为准，说明书中的具体实施方式等记载可以用于解释权利要求的内容。

Claims (10)

1.一种开放式工业APP快速开发及测试验证方法，其特征在于，包括：

功能模块开发步骤，对工业APP的各功能模块分别进行开发；

接口检测步骤，使用虚拟检测系统对各功能模块的各接口进行检测；

第一修复步骤，当接口检测步骤的检测结果为存在BUG时，对该BUG进行修复，并返回接口检测步骤；

冲突检测步骤，当接口检测步骤的检测结果为无BUG时，使用虚拟检测系统对各功能模块进行交叉事件检测；

第二修复步骤，当冲突检测步骤的检测结果为存在BUG时，对该BUG进行修复，并返回冲突检测步骤；

封装步骤，将通过冲突检测步骤的各功能模块进行封装，得到工业APP；

整体检测步骤，对工业APP进行检测；

第三修复步骤，当整体检测步骤的检测结果为存在BUG时，对该BUG进行修复，并返回整体检测步骤。

2.根据权利要求1所述的开放式工业APP快速开发及测试验证方法，其特征在于：接口检测步骤包括：

检测请求子步骤，向第一服务器发送第一检测请求信号；

接口确定子步骤，根据第一检测请求信号，通过第一服务器在接口文档中找到对应的第一接口；

接口状态检测子步骤，检测第一接口的状态，第一接口的状态包括开启和关闭；

返回数据子步骤，当第一接口的状态为开启时，根据接口文档从第一接口获取返回数据，并根据第一检测请求信号的请求类型与返回数据的格式之间的映射关系，确定返回数据的第一格式，将返回数据按第一格式封装生成第一封装数据，并返回给待测功能模块；

第一检测子步骤，根据接收到的第一封装数据，检测功能模块是否存在BUG；

第一修复步骤中，当第一检测子步骤的检测结果为存在BUG时，对该BUG进行修复，并返回检测请求子步骤。

3.根据权利要求2所述的开放式工业APP快速开发及测试验证方法，其特征在于：检测请求子步骤中，向第一服务器发送带有第二服务器参数的第一检测请求信号；

数据返回子步骤中，当第一接口的状态为关闭时，获取第二服务器参数，并根据第二服务器参数分析对应的第二服务器，将第一检测请求信号发送给对应的第二服务器，并获取该第二服务器的反馈数据后，将反馈数据发送给功能模块；

第一检测子步骤，根据接收到的第一封装数据或反馈数据，检测功能模块是否存在BUG。

4.根据权利要求1所述的开放式工业APP快速开发及测试验证方法，其特征在于：功能模块开发步骤中，各功能模块的接口采用的数据格式为json格式。

5.根据权利要求1所述的开放式工业APP快速开发及测试验证方法，其特征在于：冲突检测步骤包括：

冲突检测请求子步骤，发送交叉事件检测请求信号；

获取测试用例子步骤，根据接收到的交叉事件检测请求信号，确定功能模块的待测试项，再根据待测试项，从第三服务器中获取匹配的自动化测试用例集；

第二检测子步骤，执行获取的自动化测试用例集，对功能模块进行交叉事件检测；

第二修复步骤中，当第二检测子步骤的检测结果为存在BUG时，对该BUG进行修复，并返回冲突检测请求子步骤。

6.根据权利要求5所述的开放式工业APP快速开发及测试验证方法，其特征在于：获取测试用例子步骤中，自动化测试用例集包括指定交叉事件和随机交叉事件。

7.根据权利要求6所述的开放式工业APP快速开发及测试验证方法，其特征在于：获取测试用例子步骤中，自动化测试用例集的指定交叉事件来源于正常事件交叉关系库的必选项事件，以及异常操作事件库的必选项事件；随机交叉事件来源于正常事件交叉关系库的可选项事件，以及异常操作事件库的可选项事件。

8.根据权利要求7所述的开放式工业APP快速开发及测试验证方法，其特征在于：获取测试用例子步骤中，自动化测试用例集的生成过程为：将指定交叉事件和随机交叉事件导入用例模型库中，模型库分别生成指定交叉事件的自动化测试用例和随机交叉事件的自动化测试用例，并构成自动化测试用例集。

9.根据权利要求8所述的开放式工业APP快速开发及测试验证方法，其特征在于：还包括更新步骤，当整体检测步骤的检测结果为存在交叉事件型BUG时，根据BUG的内容，更新正常事件交叉关系库和/或异常操作事件库中的数据。

10.根据权利要求1所述的开放式工业APP快速开发及测试验证方法，其特征在于：整体检测步骤中，用虚拟检测系统对工业APP进行检测。

Images