CN112256560A - 应用程序测试方法、装置及电子设备 - Google Patents
应用程序测试方法、装置及电子设备 Download PDFInfo
- Publication number
- CN112256560A CN112256560A CN202011003845.8A CN202011003845A CN112256560A CN 112256560 A CN112256560 A CN 112256560A CN 202011003845 A CN202011003845 A CN 202011003845A CN 112256560 A CN112256560 A CN 112256560A
- Authority
- CN
- China
- Prior art keywords
- test
- tested
- application program
- target application
- thread
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012360 testing method Methods 0.000 claims abstract description 585
- 238000000034 method Methods 0.000 claims abstract description 37
- 230000015654 memory Effects 0.000 claims description 17
- 238000012544 monitoring process Methods 0.000 claims description 10
- 230000000977 initiatory effect Effects 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 9
- 230000004044 response Effects 0.000 description 6
- 238000010998 test method Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 238000004590 computer program Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000013515 script Methods 0.000 description 2
- 241000208306 Apium Species 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000013522 software testing Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3644—Software debugging by instrumenting at runtime
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本公开关于一种应用程序测试方法、装置及电子设备，属于测试技术领域。其中，该方法包括：通过响应于获取到的应用程序测试指令，确定当前待测试的目标应用程序及对应的各个待测设备，然后启动与每个待测设备对应的测试线程，执行启动的测试线程，对与目标应用程序对应的测试文件进行解析，生成对应的测试指令集，并控制每个待测设备执行测试指令集，以对目标应用程序进行测试。由此，通过启动与每个待测设备对应的测试线程，利用多线程实现对多个测试设备进行自动化测试，不仅降低了人工测试成本和人工漏测的概率，而且提高了测试效率。
Description
技术领域
本公开涉及测试技术领域，尤其涉及一种应用程序测试方法、装置及电子设备。
背景技术
通常应用程序会运行在不同电子设备上，如平板电脑、手机、智能穿戴式设备等。随着电子设备的不断更新，应用程序的兼容性问题逐渐成为考核应用程序质量的一个指标。对此，在应用程序发布前，对应用程序在多个设备上进行测试，以避免应用程序发布后出现大量的兼容性问题。
目前，主要采用基于桌面测试应用的测试方法，但是该测试方法必须依靠人工点击操作，且一次只能测试一个设备。可见，相关技术中应用程序测试方法，人工成本高、测试效率低。
发明内容
本公开提供一种应用程序测试方法、装置及电子设备，以至少解决相关技术中应用程序测试方法，人工成本高、测试效率低的问题。本公开的技术方案如下：
根据本公开实施例的第一方面，提供一种应用程序测试方法，包括：
响应于获取到的应用程序测试指令，确定当前待测试的目标应用程序及对应的各个待测设备；
启动与每个所述待测设备对应的测试线程；
执行启动的所述测试线程，对与所述目标应用程序对应的测试文件进行解析，生成对应的测试指令集，并控制每个所述待测设备执行所述测试指令集，以对所述目标应用程序进行测试。
在本公开实施例一种可能的实现方式中，所述确定当前待测试的目标应用程序及对应的各个待测设备，包括：
根据当前连接的各个设备的设备信息，确定所述对应的各个待测设备。
在本公开实施例一种可能的实现方式中，在所述确定所述对应的各个待测设备之后，还包括：
利用所述各个待测设备的设备信息，更新与所述目标应用程序对应的待测设备信息表。
在本公开实施例一种可能的实现方式中，所述启动与每个所述待测设备对应的测试线程，包括：
顺序启动与所述各个待测设备中的每个待测设备对应的测试线程；
在每启动一个测试线程后，监测测试系统的剩余资源数量。
在本公开实施例一种可能的实现方式中，在所述每启动一个测试线程后，监测测试系统的剩余资源数量之后，还包括：
如果所述测试系统的剩余资源数量大于第一阈值，则继续启动新的测试线程；
如果所述测试系统的剩余资源数量小于或等于第一阈值，则暂停启动新的测试线程，并继续监测所述测试系统的剩余资源数量，直至所述测试系统的剩余资源数量大于所述第一阈值时，继续启动新的测试线程，直至将与每个所述待测设备对应的测试线程启动完毕。
在本公开实施例一种可能的实现方式中，在所述控制每个所述待测设备执行所述测试指令集，以对所述目标应用程序进行测试之后，还包括：
获取每个所述待测设备在执行所述测试指令集时，所述目标应用程序的运行状态；
根据所述目标应用程序的运行状态，生成所述目标应用程序在所述各个待测设备中的测试报告。
在本公开实施例一种可能的实现方式中，在所述控制每个所述待测设备执行所述测试指令集，以对所述目标应用程序进行测试，包括：
如果任一所述待测设备在执行所述测试指令集时产生中断操作，则获取产生所述中断操作的目标测试指令；
记录所述任一待测设备的设备信息及所述目标测试指令。
在本公开实施例一种可能的实现方式中，在所述获取产生所述中断操作的目标测试指令之后，还包括：
控制所述任一待测设备重新执行所述目标测试指令。
在本公开实施例一种可能的实现方式中，在所述控制所述任一待测设备重新执行所述目标测试指令之后，还包括：
如果所述任一待测设备在执行所述目标测试指令的次数达到第二阈值，则控制所述任一待测设备继续执行所述测试指令集中与所述目标测试指令相邻的后一测试指令。
根据本公开实施例的第二方面，提供一种应用程序测试装置，包括：
确定模块，被配置为响应于获取到的应用程序测试指令，确定当前待测试的目标应用程序及对应的各个待测设备；
启动模块，被配置为启动与每个所述待测设备对应的测试线程；
控制模块，被配置执行启动的所述测试线程，对与所述目标应用程序对应的测试文件进行解析，生成对应的测试指令集，并控制每个所述待测设备执行所述测试指令集，以对所述目标应用程序进行测试。
在本公开实施例一种可能的实现方式中，所述确定模块，被配置为根据当前连接的各个设备的设备信息，确定所述对应的各个待测设备。
在本公开实施例一种可能的实现方式中，该装置还包括：
更新模块，被配置为利用所述各个待测设备的设备信息，更新与所述目标应用程序对应的待测设备信息表。
在本公开实施例一种可能的实现方式中，所述启动模块，包括：
启动单元，被配置为顺序启动与所述各个待测设备中的每个待测设备对应的测试线程；
监测单元，被配置为在每启动一个测试线程后，监测测试系统的剩余资源数量。
在本公开实施例一种可能的实现方式中，所述启动单元，还被配置为当所述测试系统的剩余资源数量大于第一阈值时，继续启动新的测试线程；
所述启动模块，还包括：
第一控制单元，被配置为当所述测试系统的剩余资源数量小于或等于第一阈值时，暂停启动新的测试线程，并继续监测所述测试系统的剩余资源数量，直至所述测试系统的剩余资源数量大于所述第一阈值时，继续启动新的测试线程，直至将与每个所述待测设备对应的测试线程启动完毕。
在本公开实施例一种可能的实现方式中，该装置还包括：
获取模块，被配置为获取每个所述待测设备在执行所述测试指令集时，所述目标应用程序的运行状态；
生成模块，被配置为根据所述目标应用程序的运行状态，生成所述目标应用程序在所述各个待测设备中的测试报告。
在本公开实施例一种可能的实现方式中，所述控制模块，包括：
获取单元，被配置为当任一所述待测设备在执行所述测试指令集时产生中断操作时，获取产生所述中断操作的目标测试指令；
记录单元，被配置为记录所述任一待测设备的设备信息及所述目标测试指令。
在本公开实施例一种可能的实现方式中，所述控制模块，还包括：
第二控制单元，被配置为控制所述任一待测设备重新执行所述目标测试指令。
在本公开实施例一种可能的实现方式中，所述控制模块，还包括：
第三控制单元，被配置为当所述任一待测设备执行所述目标测试指令的次数达到第二阈值时，控制所述任一待测设备继续执行所述测试指令集中与所述目标测试指令相邻的后一测试指令。
根据本公开实施例的第三方面，提供一种电子设备，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如上述前所述的应用程序测试方法。
根据本公开实施例的第四方面，提供一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如前所述的应用程序测试方法。
根据本公开实施例的第五方面，提供一种计算机程序产品，该计算机程序由电子设备的处理器执行时，使得电子设备能够执行如前所述的应用程序测试方法。
本公开的实施例提供的技术方案至少带来以下有益效果：通过响应于获取到的应用程序测试指令，确定当前待测试的目标应用程序及对应的各个待测设备，然后启动与每个待测设备对应的测试线程，执行启动的测试线程，对与目标应用程序对应的测试文件进行解析，生成对应的测试指令集，并控制每个待测设备执行测试指令集，以对目标应用程序进行测试。由此，通过启动与每个待测设备对应的测试线程，利用多线程实现对多个测试设备进行自动化测试，不仅降低了人工测试成本和人工漏测的概率，而且提高了测试效率。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。
图1是根据一示例性实施例示出的一种应用程序测试方法的流程图。
图2是根据一示例性实施例示出的一种设备接入测试系统的示意图。
图3是根据一示例性实施例示出的另一种应用程序测试方法的流程图。
图4是根据一示例性实施例示出的另一种应用程序测试方法的流程图。
图5是根据一示例性实施例示出的另一种应用程序测试方法的流程图。
图6是根据一示例性实施例示出的一种应用程序测试装置框图。
图7是根据一示例性实施例示出的一种电子设备的框图。
具体实施方式
为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。
需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
通常在应用程序发布前，对应用程序在多个设备上进行测试，以避免应用程序发布后出现大量的兼容性问题。
目前，主要是基于桌面测试应用的测试方法，但是该测试方法必须依靠人工点击操作，且一次只能测试一个设备。可见，相关技术中应用程序测试方法，人工成本高、测试效率低。
基于此，本公开实施例示出一种应用程序测试方法，该应用程序测试方法可应用于测试系统，测试系统可配置电子设备中。下面结合图1进行说明，图1是根据一示例性实施例示出的一种应用程序测试方法的流程图，如图1所示，该应用程序测试方法包括以下步骤。
在步骤101中，响应于获取到的应用程序测试指令，确定当前待测试的目标应用程序及对应的各个待测设备。
本实施例中，在测试应用程序时，测试人员可以输入测试命令，由此，测试系统获取应用程序测试指令。或者，测试系统提供测试界面，测试界面上具有测试控件，那么测试人员可以通过点击测试界面上的测试控件对设备上安装的应用程序进行测试，这时测试系统获取到应用程序测试指令。
其中，应用程序测试指令中可包括待测试的应用程序的标识，这里将待测试的应用程序称为目标应用程序。
测试系统响应于获取到的应用程序指令，对应用程序测试指令进行解析，获取当前待测试的目标应用程序的标识，由此可以确定当前待测试的目标应用程序。另外，应用程序测试指令还可携带待测设备的设备信息，比如待测设备的型号、待测设备的品牌、待测设备的操作系统等信息，那么通过对应用程序测试指令进行解析，可以确定对应的待测设备。
可以理解的是，各个待测设备上安装有当前待测试的目标应用程序。需要说明的是，各个待测设备可以是不同品牌，也可以是同一品牌不同系列，或者同一品牌同一系列，各个待测设备的操作系统可以相同，也可以不同，本公开实施例对此不作限定。
在步骤102中，启动与每个待测设备对应的测试线程。
相关技术中通常是利用主线程监听测试设备，在多设备的场景下该技术会有很大的局限性，存在程序执行卡顿等问题。基于此，本实施例中，每个待测设备具有对应的测试线程。
在确定待测试的目标应用程序及对应的各个待测设备后，启动与每个待测设备对应的测试线程。在启动测试线程时，可以依次启动每个待测设备对应的测试线程，或者同时启动每个待测设备对应的测试线程。
在步骤103中，执行启动的测试线程，对与目标应用程序对应的测试文件进行解析，生成对应的测试指令集，并控制每个待测设备执行测试指令集，以对目标应用程序进行测试。
测试人员可预先编写针对目标应用程序的测试文件，其中，测试文件包括：测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。
本实施例中，执行启动的测试线程，对预先编写的目标应用程序对应的测试文件进行解析，获取测试脚本，从而生成对应的测试指令集。其中，测试指令集中包括至少一个测试指令，测试指令集用于对目标应用程序进行测试。在具体实现时，可以在执行启动的第一个测试线程时，对测试文件进行解析。
在生成测试指令集后，控制每个待测设备执行测试指令集，具体的，控制待测设备顺序执行测试指令集中的测试指令，以对每个待测设备上的目标应用程序进行测试。
本实施例中，启动与每个待测设备对应的测试线程，并控制每个待测设备执行测试指令集，使得每个待测设备能独立运行测试指令集中的测试指令，不相互干扰。
本公开实施例中，通过响应于获取到的应用程序测试指令，确定当前待测试的目标应用程序及对应的各个待测设备，然后启动与每个待测设备对应的测试线程，执行启动的测试线程，对与目标应用程序对应的测试文件进行解析，生成对应的测试指令集，并控制每个待测设备执行测试指令集，以对目标应用程序进行测试。由此，通过启动与每个待测设备对应的测试线程，利用多线程实现对多个测试设备进行自动化测试，不仅降低了人工测试成本和人工漏测的概率，而且提高了测试效率。
在本公开的一个实施例中，在确定当前待测试的目标应用程序对应的各个待测设备时，可根据测试系统当前连接的各个设备确定。
在进行测试之前，测试人员可将多个设备与测试系统所在的电子设备进行连接，比如通过USB线连接。测试系统在获取到应用程序测试指令后，读取测试系统当前连接的各个设备的设备信息，其中，设备信息包括设备的型号、设备所属品牌、设备的操作系统等信息。然后，根据当前连接的每个设备的设备信息，可将当前连接的各个设备确定为目标应用程序对应的各个待测设备。由此，可以确定当前待测试的应用程序对应的各个待测设备。
图2是根据一示例性实施例示出的一种设备接入测试系统的示意图。图2中，当前与测试系统210连接的设备有设备A、设备B和设备C，那么设备A、设备B和设备C为待测设备。
在具体实现时，测试人员可以根据需要接入想要测试的设备，测试系统可对接多个产品线，具有较强的延展性，有效提升了应用程序测试效率。
本公开实施例中，在确定当前待测试的目标应用程序及对应的各个待测设备时，可根据当前连接的各个设备的设备信息，确定对应的各个待测设备。由此，通过根据当前连接的各个设备，确定待测试的目标应用程序对应的各个待测设备，简单、方便。
为了便于了解应用程序在不同设备上的测试情况，在本公开的一个实施例中，在确定对应的各个待测设备之后，可利用各个待测设备的设备信息，更新与目标应用程序对应的待测设备信息表。
本实施例中，每个待测试的目标应用程序具有对应的待测设备信息表。其中，待测设备信息表包括对目标应用程序进行测试所用的每个待测设备的设备信息，比如设备型号、设备所属品牌、设备的操作系统等等。
具体地，判断目标应用程序对应的每个待测设备的设备信息，是否在待测设备信息表中。如果不在待测信息表中，则将该待测设备的设备信息添加到待测设备信息表中。如果在待测信息表中，则不更新待测设备信息表。由此，通过设备信息表可以确定在哪些设备上对目标应用程序进行了测试。
本公开实施例中，在确定对应的各个待测设备之后，利用各个待测设备的设备信息，更新与目标应用程序对应的待测设备信息表。由此，可以实时加载目标应用程序对应的待测设备的设备信息，无需人工预先配置设备信息，降低了人力成本。
为了监测系统的运行情况，在本公开的一个实施例中，在启动与每个待测设备对应的测试线程时，可顺序启动与各个设备中的每个待测设备对应的测试线程，并在每个启动一个测试线程后，监测测试系统的剩余资源数量。
具体地，可以按照待测设备与测试系统连接的时间早晚顺序或晚早顺序，依次启动每个待测设备对应的测试线程，或者按照预先设置的各个接口连接的设备对应的测试线程的启动顺序，启动每个待测设备对应的测试线程，或者随机方式逐个启动每个待测设备对应的测试线程等等。
比如，有3个接口a、b、c，设置先启动接口a连接的待测设备对应的测试线程，然后启动接口b连接的待测设备对应的测试线程，最后启动接口c连接的待测设备对应的测试线程。
又如，有4个待测设备，可以先启动其中一个待测设备对应的测试线程，然后再从剩余的3个待测设备随机选择一个，启动其对应的测试线程，之后再从剩余的2个待测设备中随机选择一个，启动其对应的测试线程，最后启动剩余的一个待测设备对应的测试线程。
在每启动一个测试线程后，对测试系统的剩余资源数量进行监测，比如对剩余的CPU、剩余的内存大小等进行监测。
本公开实施例中，在启动与每个待测设备对应的测试线程时，顺序启动与各个待测设备中的每个待测设备对应的测试线程；在每启动一个测试线程后，监测测试系统的剩余资源数量。由此，通过顺序启动每个待测设备对应的测试线程，并在每启动一个测试线程后，监测测试系统的剩余资源数量，从而可以实时监测系统的运行情况，并了解每个测试线程启动后对测试系统的影响。
在实际应用中，如果启动多个待测设备对应的测试线程，可能会存在多线程之间竞争CPU、内存等资源导致线程死锁的情况。基于此，在本公开的一个实施例中，在启动每个待测设备的测试线程时，可根据监测的测试系统剩余资源数量进行启动。下面结合图3进行说明，图3是根据一示例性实施例示出的另一种应用程序测试方法的流程图。
如图3所示，上述启动与每个待测设备对应的测试线程，包括：
在步骤301中，顺序启动与各个待测设备中的每个待测设备对应的测试线程。
具体地，可以按照待测设备与测试系统连接的时间早晚顺序或晚早顺序，依次启动每个待测设备对应的测试线程，或者按照预先设置的各个接口连接的设备对应的测试线程的启动顺序，启动每个待测设备对应的测试线程，或者随机方式逐个启动每个待测设备对应的测试线程等等。
比如，有3个接口a、b、c，设置先启动接口a连接的待测设备对应的测试线程，然后启动接口b连接的待测设备对应的测试线程，最后启动接口c连接的待测设备对应的测试线程。
又如，有4个待测设备，可以先启动其中一个待测设备对应的测试线程，然后再从剩余的3个待测设备随机选择一个，启动其对应的测试线程，之后再从剩余的2个待测设备中随机选择一个，启动其对应的测试线程，最后启动剩余的一个待测设备对应的测试线程。
在步骤302中，在每启动一个测试线程后，监测测试系统的剩余资源数量。
为了避免多线程之间竞争CPU、内存等资源，本实施例中，在每启动一个测试线程后，对测试系统的剩余资源数量进行监测，比如对剩余的CPU、剩余的内存大小等进行监测。
在步骤303中，如果测试系统的剩余资源数量大于第一阈值，则继续启动新的测试线程。
本实施例中，在每启动一个测试线程后，监测测试系统的剩余资源数量，然后将监测的测试系统的剩余资源数量，与第一阈值进行比较。其中，第一阈值可以根据实际需要进行设定，本公开实施例对此不作限定。
如果测试系统的剩余资源数量大于第一阈值，可以认为启动新的测试线程不会使已启动测试线程之间竞争资源，则继续启动新的测试线程。其中，启动的新测试线程，可以是随机选择的，也可以是按照设定的启动顺序确定的等。
在实际应用中，由于监测的资源可能有多种，可以为每种资源设置对应的第一阈值，当测试系统的剩余的每种资源数量均大于对应的第一阈值时，继续启动新的测试线程。或者，根据预先的每种资源的权重和剩余的每种资源数量，计算剩余资源数量的加权和，将加权和与第一阈值进行比较，当剩余资源数量加权和大于第一阈值时，继续启动新的测试线程。
在步骤304中，如果测试系统的剩余资源数量小于或等于第一阈值，则暂停启动新的测试线程，并继续监测测试系统的剩余资源数量，直至测试系统的剩余资源数量大于第一阈值时，继续启动新的测试线程，直至将与每个待测设备对应的测试线程启动完毕。
如果测试系统的剩余资源数量小于或等于第一阈值，说明启动新的测试线程，可能会导致已启动的测试线程之间竞争资源，则暂停启动新的测试线程，并继续监测测试系统的剩余资源数量，将测试系统的剩余资源数量与第一阈值进行比较，若测试系统的剩余资源数量大于第一阈值，则继续启动新的测试线程。
在启动新的测试线程后，监测测试系统的剩余资源数量，判断测试系统的剩余资源数量是否大于第一阈值。如果大于第一阈值，则继续启动新的测试线程；如果测试系统的剩余资源数量小于或等于第一阈值，则暂停启动新的测试线程，并继续监测测试系统的剩余资源数量，直至测试系统的剩余资源数量大于第一阈值时，继续启动新的测试线程，直至启动完毕与每个待测设备对应的测试线程。从而，在测试系统的剩余资源数量充足时，启动新的测试线程。
本公开实施例中，在每启动一个测试线程后，监测测试系统的剩余资源数量之后，如果测试系统的剩余资源数量大于第一阈值，则继续启动新的测试线程；如果测试系统的剩余资源数量小于或等于第一阈值，则暂停启动新的测试线程，并继续监测测试系统的剩余资源数量，直至测试系统的剩余资源数量大于第一阈值时，继续启动新的测试线程，直至将与每个待测设备对应的测试线程启动完毕。由此，通过在每启动一个测试线程后，监测测试系统的剩余资源数量，根据测试系统的剩余资源数量确定是否启动新的测试线程，保证在启动每个新的测试线程时，不会使已启动的测试线程之间竞争资源，从而避免了多个测试线程之间竞争资源导致线程死锁的情况。
为了实现多设备的测试报告的集成管理，在本公开的一个实施例中，可以生成目标应用程序在每个待测设备中的测试报告。下面结合图4进行说明，图4是根据一示例性实施例示出的另一种应用程序测试方法的流程图。
如图4所示，该应用程序测试方法包括：
在步骤401中，响应于获取到的应用程序测试指令，确定当前待测试的目标应用程序及对应的各个待测设备。
在步骤402中，启动与每个待测设备对应的测试线程。
在步骤403中，执行启动的测试线程，对与目标应用程序对应的测试文件进行解析，生成对应的测试指令集，并控制每个待测设备执行测试指令集，以对目标应用程序进行测试。
本实施例中，步骤401-步骤403与上述步骤101-步骤103类似，故在此不再赘述。
在步骤404中，获取每个待测设备在执行测试指令集时，目标应用程序的运行状态。
在控制每个待测设备执行测试指令集，以对目标应用程序进行测试之后，获取每个待测设备在执行测试指令集时，目标应用程序的运行状态，具体的，可获取每个待测设备在执行测试指令集中每个测试指令时，目标应用程序的运行状态。
比如，目标应用程序为视频播放程序，执行点击播放按钮的指令后，目标应用程序是否播放视频。
在步骤405中，根据目标应用程序的运行状态，生成目标应用程序在各个待测设备中的测试报告。
在获取每个待测设备执行测试指令集时，目标应用程序的运行状态后，根据目标应用程序在执行每个测试指令时的运行状态，生成目标应用程序在每个待测设备中的测试报告。由此，可以获取目标应用程序在各个待测设备中的测试报告，通过对目标应用程序在待测设备中的测试报告进行分析，可以对目标应用程序进行改进。
其中，测试报告中可包括测试开始时间、测试指令通过的数量和失败的数量、每个测试指令对应的测试结果等等，其中，每个测试指令对应的测试结果，包括测试次数、通过次数、失败次数、错误次数等等。
本公开实施例中，在控制每个待测设备执行测试指令集，以对目标应用程序进行测试之后，可获取每个待测设备在执行测试指令集时，目标应用程序的运行状态，然后根据目标应用程序的运行状态，生成目标应用程序在各个待测设备中的测试报告。由此，通过根据各个待测设备执行测试指令集时，目标应用程序的运行状态，生成目标应用程序在各个待测设备中的测试报告，从而实现了集成多设备的测试报告的管理，可以快速准确的定位自动化测试过程中出现的问题。
在实际应用中，待测设备执行测试指令集的过程中可能会产生中断，比如闪退、无响应等，为快速定位中断的位置，在本公开的一个实施例中，在控制每个待测设备指令测试指令集时，可以记录出现中断的待测设备和产生中断的测试指令。下面结合图5进行说明，图5是根据一示例性实施例示出的另一种应用程序测试方法的流程图。
如图5所示，该应用程序测试方法包括：
在步骤501中，响应于获取到的应用程序测试指令，确定当前待测试的目标应用程序及对应的各个待测设备。
在步骤502中，启动与每个待测设备对应的测试线程。
在步骤503中，执行启动的测试线程，对与目标应用程序对应的测试文件进行解析，生成对应的测试指令集。
本实施例中，步骤501-步骤503与上述步骤101-步骤103类似，故在此不再赘述。
在步骤504中，如果任一待测设备在执行测试指令集时产生中断操作，则获取产生中断操作的目标测试指令。
本实施例中，可通过“断言”等方式去校验目标应用程序页面的正确性，当“断言”测试指令执行不通过时程序会中断。如果某待测设备在执行测试指令时产生中断操作，则获取产生中断操作的测试指令，为了便于区分，这里称为目标测试指令。
在步骤505中，记录任一待测设备的设备信息及目标测试指令。
本实施例中，在获取到产生中断操作的目标测试指令后，记录出现中断操作的待测设备的设备信息，以及对应的产生中断操作的目标测试指令，到日志中。由此，在每个待测设备执行测试指令集时，记录出现问题的待测设备的设备信息和测试指令。
比如，有3个待测设备分别为A、B、C，其中，待测设备A在执行测试集时产生中断操作，产生中断操作的测试指令为iA，待测设备C在执行测试集时产生中断操作，产生中断操作的测试指令为iC。那么，记录待测设备A的设备信息和测试指令iA，以及记录待测设备C的设备信息和测试指令iC。
本公开实施例中，在控制每个待测设备执行测试指令集，以对目标应用程序进行测试时，如果任一待测设备在执行测试指令集时产生中断操作，则获取产生中断操作的目标测试指令，然后记录任一待测设备的设备信息及目标测试指令。由此，通过记录产生中断操作的待测设备的设备信息和产生中断操作的测试指令的日志，可以快速准确的定位和分析产生中断操作的测试指令。
在实际应用中，在测试过程中产生中断，可能是偶然因素导致的，为了提高测试效果，在本公开的一个实施例中，在获取产生中断操作的目标测试指令之后，可控制任一待测设备重新执行目标测试指令。
本实施例中，对于在执行测试指令集时产生中断操作的待测设备，在获取产生中断操作的目标测试指令后，控制该待测设备重新执行目标测试指令进行重试，避免因偶然因素产生中断而结束测试。
本公开实施例中，在获取产生中断操作的目标测试指令之后，可控制任一待测设备重新执行目标测试指令。由此，对于产生中断操作的待测设备，通过控制其重新执行产生中断操作的测试指令，从而通过重试机制提高了自动化测试的鲁棒性。
在实际应用中，当“断言”执行不通过时程序会中断，从而导致后续测试指令无法继续执行，鲁棒性较差。为了保证产生中断操作的测试指令后面的测试指令能继续执行，在本公开的一个实施例中，在目标测试指令的执行次数达到第二阈值时，控制待测设备执行后续的测试指令。其中，第二阈值可以根据需要设置，本公开实施例对此不作限定。
具体地，对于在执行测试指令集时产生中断操作的待测设备，在获取产生中断操作的目标测试指令后，控制该待测设备重新执行目标测试指令。如果待测设备重新执行目标测试指令，目标测试指令仍然产生中断操作，则继续执行目标测试指令。当该待测设备执行目标测试指令的次数达到第二阈值时，认为该中断操作不是偶然，为了不影响后续测试指令的执行，控制该待测设备执行测试指令集中与目标测试指令相邻的后一测试指令。
可以理解的是，当该待测设备执行目标测试指令后续的测试指令时，某测试指令产生中断操作，则记录该测试指令，并控制该待测设备重新指令该测试指令。如果待测设备执行该测试指令的次数达到第二阈值时，则控制待测设备继续执行该测试指令相邻的后一测试指令，直至执行完毕测试指令集中所有测试指令。
本公开实施例中，在控制任一待测设备重新执行目标测试指令之后，如果任一待测设备执行目标测试指令的次数达到第二阈值，则控制任一待测设备继续执行测试指令集中与目标测试指令相邻的后一测试指令。由此，通过在待测设备对产生中断操作的测试指令的执行次数达到第二阈值时，控制待测设备执行产生中断操作的测试指令相邻的后一测试指令，从而不影响后续测试指令的执行，提高了测试效果和鲁棒性。
下面以基于Appium框架进行应用程序测试为例，说明本公开实施例的应用程序测试方法。其中，Appium是一个开源、跨平台的测试框架，可以用来测试原生及混合的移动端应用，Appium由Appium服务器和Appium客户端两部分组成。
具体地，在测试系统工程目录下创建yaml格式的文件，用于配置测试设备的信息。当用usb连接手机、平板等测试设备时读取该设备的设备信息，进行录入存入配置文件。
在主函数中创建一个init_appium方法和run_app方法。其中，init_appium方法用于启动Appium服务器和Appium客户端；run_app方法利用多线程的方式去分布式的执行测试指令集，避免了多设备之间测试指令的干扰，有效的提高了程序的可用性。
当测试系统获取应用程序测试指令后，主函数中的init_appium方法启动Appium服务器和Appium客户端，以对测试设备进行驱动和操作的监听。
具体地，通过Appium服务器顺序启动与各个待测设备中的每个待测设备对应的测试线程，在每启动一个测试线程后，监测测试系统的剩余资源数量，根据测试系统剩余资源数量，启动每个待测设备对应的测试线程。然后，run_app方法控制各待测设备执行测试指令集，并通过Appium客户端对每个待测设备上目标应用程序的运行状态进行监听。之后，测试系统根据目标应用程序的运行状态，生成目标应用程序在各个待测设备中的测试报告。
除了该Appium框架，还可用uiautomator2框架启动各待测设备对应的测试线程，或者其他能够启动测试线程的框架。其中，uiautomator2是一个可以使用Python对安卓设备进行用户界面自动化的库，其提供了可视化的操作界面。
图6是根据一示例性实施例示出的一种应用程序测试装置框图。参照图6，该应用程序测试装置600包括：确定模块610、启动模块620、控制模块630。
确定模块610，被配置为响应于获取到的应用程序测试指令，确定当前待测试的目标应用程序及对应的各个待测设备；
启动模块620，被配置为启动与每个待测设备对应的测试线程；
控制模块630，被配置执行启动的测试线程，对与目标应用程序对应的测试文件进行解析，生成对应的测试指令集，并控制每个待测设备执行测试指令集，以对目标应用程序进行测试。
在本公开实施例一种可能的实现方式中，该确定模块610，被配置为根据当前连接的各个设备的设备信息，确定对应的各个待测设备。
在本公开实施例一种可能的实现方式中，该装置还可包括：
更新模块，被配置为利用各个待测设备的设备信息，更新与目标应用程序对应的待测设备信息表。
在本公开实施例一种可能的实现方式中，该启动模块620，包括：
启动单元，被配置为顺序启动与各个待测设备中的每个待测设备对应的测试线程；
监测单元，被配置为在每启动一个测试线程后，监测测试系统的剩余资源数量。
在本公开实施例一种可能的实现方式中，该启动单元，被配置为当测试系统的剩余资源数量大于第一阈值时，继续启动新的测试线程；
该启动模块620，还包括：
第一控制单元，被配置为当测试系统的剩余资源数量小于或等于第一阈值时，暂停启动新的测试线程，并继续监测测试系统的剩余资源数量，直至测试系统的剩余资源数量大于第一阈值时，继续启动新的测试线程，直至将与每个待测设备对应的测试线程启动完毕。
在本公开实施例一种可能的实现方式中，该装置还可包括：
获取模块，被配置为获取每个待测设备在执行测试指令集时，目标应用程序的运行状态；
生成模块，被配置为根据目标应用程序的运行状态，生成目标应用程序在各个待测设备中的测试报告。
在本公开实施例一种可能的实现方式中，该控制模块630，包括：
获取单元，被配置为当任一待测设备在执行测试指令集时产生中断操作时，获取产生中断操作的目标测试指令；
记录单元，被配置为记录任一待测设备的设备信息及目标测试指令。
在本公开实施例一种可能的实现方式中，该控制模块630，还包括：
第二控制单元，被配置为控制任一待测设备重新执行目标测试指令。
在本公开实施例一种可能的实现方式中，该控制模块630，还包括：
第三控制单元，被配置为当任一待测设备执行目标测试指令的次数达到第二阈值时，控制任一待测设备继续执行测试指令集中与目标测试指令相邻的后一测试指令。
在实际使用时，本公开实施例提供的应用程序测试装置，可以被配置在任意电子设备中，以执行前述应用程序测试方法。因此，关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
本公开的实施例提供的应用程序测试装置，通过响应于获取到的应用程序测试指令，确定当前待测试的目标应用程序及对应的各个待测设备，然后启动与每个待测设备对应的测试线程，执行启动的测试线程，对与目标应用程序对应的测试文件进行解析，生成对应的测试指令集，并控制每个待测设备执行测试指令集，以对目标应用程序进行测试。由此，通过启动与每个待测设备对应的测试线程，利用多线程实现对多个测试设备进行自动化测试，不仅降低了人工测试成本和人工漏测的概率，而且提高了测试效率。
图7是根据一示例性实施例示出的一种用于应用程序测试的电子设备700的框图。
如图7所示，上述电子设备700包括：
存储器710及处理器720，连接不同组件(包括存储器710和处理器720)的总线730，存储器710存储有计算机程序，当处理器720执行所述程序时实现本公开实施例所述的应用程序测试方法。
总线730表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(ISA)总线，微通道体系结构(MAC)总线，增强型ISA总线、视频电子标准协会(VESA)局域总线以及外围组件互连(PCI)总线。
电子设备700典型地包括多种电子设备可读介质。这些介质可以是任何能够被电子设备700访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。
存储器710还可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(RAM)740和/或高速缓存存储器750。电子设备700可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统760可以用于读写不可移动的、非易失性磁介质(图7未显示，通常称为“硬盘驱动器”)。尽管图7中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如CD-ROM,DVD-ROM或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线730相连。存储器710可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本公开各实施例的功能。
具有一组(至少一个)程序模块770的程序/实用工具780，可以存储在例如存储器710中，这样的程序模块770包括——但不限于——操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块770通常执行本公开所描述的实施例中的功能和/或方法。
电子设备700也可以与一个或多个外部设备790(例如键盘、指向设备、显示器791等)通信，还可与一个或者多个使得用户能与该电子设备700交互的设备通信，和/或与使得该电子设备700能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口792进行。并且，电子设备700还可以通过网络适配器793与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器793通过总线730与电子设备700的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备700使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。
处理器720通过运行存储在存储器710中的程序，从而执行各种功能应用以及数据处理。
需要说明的是，本实施例的电子设备的实施过程和技术原理参见前述对本公开实施例的应用程序测试方法的解释说明，此处不再赘述。
本公开实施例提供的电子设备，可以执行如前所述的应用程序测试方法，通过响应于获取到的应用程序测试指令，确定当前待测试的目标应用程序及对应的各个待测设备，然后启动与每个待测设备对应的测试线程，执行启动的测试线程，对与目标应用程序对应的测试文件进行解析，生成对应的测试指令集，并控制每个待测设备执行测试指令集，以对目标应用程序进行测试。由此，通过启动与每个待测设备对应的测试线程，利用多线程实现对多个测试设备进行自动化测试，不仅降低了人工测试成本和人工漏测的概率，而且提高了测试效率。
为了实现上述实施例，本公开还提出一种存储介质。
其中，该存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如前所述的应用程序测试方法。
为了实现上述实施例，本公开还提供一种计算机程序产品，该计算机程序由电子设备的处理器执行时，使得电子设备能够执行如前所述的应用程序测试方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。
应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。
Claims (10)
1.一种应用程序测试方法，其特征在于，包括：
响应于获取到的应用程序测试指令，确定当前待测试的目标应用程序及对应的各个待测设备；
启动与每个所述待测设备对应的测试线程；
执行启动的所述测试线程，对与所述目标应用程序对应的测试文件进行解析，生成对应的测试指令集，并控制每个所述待测设备执行所述测试指令集，以对所述目标应用程序进行测试。
2.如权利要求1所述的方法，其特征在于，所述确定当前待测试的目标应用程序及对应的各个待测设备，包括：
根据当前连接的各个设备的设备信息，确定所述对应的各个待测设备。
3.如权利要求2所述的方法，其特征在于，在所述确定所述对应的各个待测设备之后，还包括：
利用所述各个待测设备的设备信息，更新与所述目标应用程序对应的待测设备信息表。
4.如权利要求1所述的方法，其特征在于，所述启动与每个所述待测设备对应的测试线程，包括：
顺序启动与所述各个待测设备中的每个待测设备对应的测试线程；
在每启动一个测试线程后，监测测试系统的剩余资源数量。
5.如权利要求4所述的方法，其特征在于，在所述每启动一个测试线程后，监测测试系统的剩余资源数量之后，还包括：
如果所述测试系统的剩余资源数量大于第一阈值，则继续启动新的测试线程；
如果所述测试系统的剩余资源数量小于或等于第一阈值，则暂停启动新的测试线程，并继续监测所述测试系统的剩余资源数量，直至所述测试系统的剩余资源数量大于所述第一阈值时，继续启动新的测试线程，直至将与每个所述待测设备对应的测试线程启动完毕。
6.如权利要求1-5任一所述的方法，其特征在于，在所述控制每个所述待测设备执行所述测试指令集，以对所述目标应用程序进行测试之后，还包括：
获取每个所述待测设备在执行所述测试指令集时，所述目标应用程序的运行状态；
根据所述目标应用程序的运行状态，生成所述目标应用程序在所述各个待测设备中的测试报告。
7.如权利要求1-5任一所述的方法，其特征在于，在所述控制每个所述待测设备执行所述测试指令集，以对所述目标应用程序进行测试，包括：
如果任一所述待测设备在执行所述测试指令集时产生中断操作，则获取产生所述中断操作的目标测试指令；
记录所述任一待测设备的设备信息及所述目标测试指令。
8.一种应用程序测试装置，其特征在于，包括：
确定模块，被配置为响应于获取到的应用程序测试指令，确定当前待测试的目标应用程序及对应的各个待测设备；
启动模块，被配置为启动与每个所述待测设备对应的测试线程；
控制模块，被配置执行启动的所述测试线程，对与所述目标应用程序对应的测试文件进行解析，生成对应的测试指令集，并控制每个所述待测设备执行所述测试指令集，以对所述目标应用程序进行测试。
9.一种电子设备，其特征在于，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如权利要求1-7中任一项所述的应用程序测试方法。
10.一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如权利要求1-7中任一项所述的应用程序测试方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011003845.8A CN112256560A (zh) | 2020-09-22 | 2020-09-22 | 应用程序测试方法、装置及电子设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011003845.8A CN112256560A (zh) | 2020-09-22 | 2020-09-22 | 应用程序测试方法、装置及电子设备 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112256560A true CN112256560A (zh) | 2021-01-22 |
Family
ID=74232898
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011003845.8A Pending CN112256560A (zh) | 2020-09-22 | 2020-09-22 | 应用程序测试方法、装置及电子设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112256560A (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113672505A (zh) * | 2021-08-05 | 2021-11-19 | 浙江万朋教育科技股份有限公司 | 一种多终端交互自动化回归测试的方法 |
| CN113836035A (zh) * | 2021-10-14 | 2021-12-24 | 东莞新能安科技有限公司 | 电池管理系统测试方法、装置及电子设备 |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101128007A (zh) * | 2007-09-21 | 2008-02-20 | 中兴通讯股份有限公司 | 移动通讯终端测试方法 |
| CN103713991A (zh) * | 2012-10-08 | 2014-04-09 | 腾讯科技（深圳）有限公司 | 一种在安卓设备上测试应用程序的方法和装置 |
| CN105022688A (zh) * | 2014-04-28 | 2015-11-04 | 腾讯科技（深圳）有限公司 | 设备测试方法及装置 |
| CN106557369A (zh) * | 2016-11-25 | 2017-04-05 | 武汉斗鱼网络科技有限公司 | 一种多线程的管理方法及系统 |
| CN107045475A (zh) * | 2016-02-06 | 2017-08-15 | 北京京东尚科信息技术有限公司 | 测试方法和装置 |
| CN107450973A (zh) * | 2017-07-28 | 2017-12-08 | 成都优博创通信技术股份有限公司 | 一种检测方法及装置 |
| US20180287926A1 (en) * | 2017-03-29 | 2018-10-04 | Mobile Integration Technologies | MCellblock for Parallel Testing of Multiple Devices |
| CN109471789A (zh) * | 2018-09-04 | 2019-03-15 | 中国平安人寿保险股份有限公司 | 用于测试的多设备管理方法、装置、服务器及存储介质 |
| CN109726100A (zh) * | 2018-04-19 | 2019-05-07 | 平安普惠企业管理有限公司 | 应用性能测试方法、装置、设备及计算机可读存储介质 |
| CN111240909A (zh) * | 2019-12-31 | 2020-06-05 | 深圳市元征科技股份有限公司 | 一种车载设备测试方法、装置及存储介质 |
-
2020
- 2020-09-22 CN CN202011003845.8A patent/CN112256560A/zh active Pending
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101128007A (zh) * | 2007-09-21 | 2008-02-20 | 中兴通讯股份有限公司 | 移动通讯终端测试方法 |
| CN103713991A (zh) * | 2012-10-08 | 2014-04-09 | 腾讯科技（深圳）有限公司 | 一种在安卓设备上测试应用程序的方法和装置 |
| CN105022688A (zh) * | 2014-04-28 | 2015-11-04 | 腾讯科技（深圳）有限公司 | 设备测试方法及装置 |
| CN107045475A (zh) * | 2016-02-06 | 2017-08-15 | 北京京东尚科信息技术有限公司 | 测试方法和装置 |
| CN106557369A (zh) * | 2016-11-25 | 2017-04-05 | 武汉斗鱼网络科技有限公司 | 一种多线程的管理方法及系统 |
| US20180287926A1 (en) * | 2017-03-29 | 2018-10-04 | Mobile Integration Technologies | MCellblock for Parallel Testing of Multiple Devices |
| CN107450973A (zh) * | 2017-07-28 | 2017-12-08 | 成都优博创通信技术股份有限公司 | 一种检测方法及装置 |
| CN109726100A (zh) * | 2018-04-19 | 2019-05-07 | 平安普惠企业管理有限公司 | 应用性能测试方法、装置、设备及计算机可读存储介质 |
| CN109471789A (zh) * | 2018-09-04 | 2019-03-15 | 中国平安人寿保险股份有限公司 | 用于测试的多设备管理方法、装置、服务器及存储介质 |
| CN111240909A (zh) * | 2019-12-31 | 2020-06-05 | 深圳市元征科技股份有限公司 | 一种车载设备测试方法、装置及存储介质 |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113672505A (zh) * | 2021-08-05 | 2021-11-19 | 浙江万朋教育科技股份有限公司 | 一种多终端交互自动化回归测试的方法 |
| CN113672505B (zh) * | 2021-08-05 | 2024-04-19 | 浙江万朋教育科技股份有限公司 | 一种多终端交互自动化回归测试的方法 |
| CN113836035A (zh) * | 2021-10-14 | 2021-12-24 | 东莞新能安科技有限公司 | 电池管理系统测试方法、装置及电子设备 |
| CN113836035B (zh) * | 2021-10-14 | 2024-03-01 | 东莞新能安科技有限公司 | 电池管理系统测试方法、装置及电子设备 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10552301B2 (en) | Completing functional testing | |
| JP7209034B2 (ja) | エッジコンピューティングテスト方法、装置、機器及び読み取り可能な記憶媒体 | |
| US9747192B2 (en) | Automated operating system installation on multiple drives | |
| CN107463500B (zh) | 测试脚本的调试方法、介质、系统和计算设备 | |
| US20140331209A1 (en) | Program Testing Service | |
| US20120331351A1 (en) | N-way runtime interoperative debugging | |
| US9262299B1 (en) | Simulation observability and control of all hardware and software components of a virtual platform model of an electronics system | |
| US9262305B1 (en) | Simulation observability and control of all hardware and software components of a virtual platform model of an electronics system | |
| US9542304B1 (en) | Automated operating system installation | |
| US20150370691A1 (en) | System testing of software programs executing on modular frameworks | |
| CN112256560A (zh) | 应用程序测试方法、装置及电子设备 | |
| US8762781B2 (en) | Method and apparatus useful in manufacturing test case operations | |
| CN108572895B (zh) | 一种Linux下自动检查软硬件配置的稳定性测试方法 | |
| US20160188441A1 (en) | Testing multi-threaded applications | |
| CN112650676A (zh) | 软件测试方法、装置、设备及存储介质 | |
| US20140331205A1 (en) | Program Testing Service | |
| CN111694684B (zh) | 存储设备的异常构造方法、装置、电子设备及存储介质 | |
| US7174359B1 (en) | Apparatus and methods for sequentially scheduling a plurality of commands in a processing environment which executes commands concurrently | |
| CN113986719A (zh) | 基于云服务的大规模集群性能自动化测试方法及系统 | |
| CN112817869A (zh) | 测试方法、装置、介质及电子设备 | |
| CN112506772A (zh) | web自动化测试方法、装置、电子设备和存储介质 | |
| CN111666200A (zh) | 一种pc软件冷启动耗时的测试方法及终端 | |
| US10936475B2 (en) | Automated scripting and testing system | |
| US10339229B1 (en) | Simulation observability and control of all hardware and software components of a virtual platform model of an electronics system | |
| CN113655846A (zh) | 一种OpenPOWER服务器时间同步方法及系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |