CN114036074A - 终端设备的测试方法和测试装置 - Google Patents

Abstract

本申请提供了一种终端设备的测试方法和测试装置，可以提高测试效率。该方法包括：确定目标测试用例和目标测试版本；判断待测试终端的系统版本是否与目标测试版本相同；确定目标测试版本对应的测试结果的存储路径；在待测试终端的系统版本与目标测试版本相同的情况下，向待测试终端发送测试指令，测试指令用于指示待测试终端执行目标测试用例；接收来自待测试终端对目标测试用例的测试结果；按照存储路径，存储待测试终端对目标测试用例的测试结果。

Description

终端设备的测试方法和测试装置

技术领域

本申请涉及终端领域，尤其涉及一种终端设备的测试方法和测试装置。

背景技术

随着终端技术的发展，终端设备的形态日趋增多，例如，智能手机、智能电脑以及智能手表等等，对终端设备的测试也提出了新的挑战。

目前，测试人员对终端设备进行测试的过程中，仍存在许多人工干预的过程，例如，用户需要手动查找测试用例，手动启动测试，手动将测试结果保存到指定路径下等，严重降低测试效率。

因此，亟需一种测试方法，可以尽可能地减少测试过程中的人工干预，提高测试效率。

发明内容

本申请提供一种终端设备的测试方法和测试装置，可以提高测试效率。

第一方面，本申请提供了一种终端设备的测试方法，包括：确定目标测试用例和目标测试版本；判断待测试终端的系统版本是否与目标测试版本相同；确定目标测试版本对应的测试结果的存储路径；在待测试终端的系统版本与目标测试版本相同的情况下，向待测试终端发送测试指令，测试指令用于指示待测试终端执行目标测试用例；接收来自待测试终端对目标测试用例的测试结果；按照存储路径，存储待测试终端对目标测试用例的测试结果。

目标测试用例和目标测试版本可以是根据测试人员的需要确定的。

测试设备确定目标测试用例和目标测试版本可以存在多种实现方式。

在一种可能的实现方式中，测试设备可以通过测试脚本确定目标测试用例和目标测试版本，该测试脚本为测试人员编写的，可以用于调用目标测试用例，并通过参数配置了测试人员想要测试的版本，即目标测试版本。

在另一种可能的实现方式中，测试设备可以为测试人员提供人机交互界面，该人机交互界面可以提供测试版本的输入框和测试用例的输入框。

测试设备需要先确定待测试终端的系统版本是否为目标测试版本，在待测试终端的系统版本为目标测试版本的情况下，进行后续的测试。在待测试终端的系统版本不是目标测试版本的情况下，测试设备将不会进行后续的测试，或者，先将待测试终端的系统版本更新为目标测试版本，再进行后续的测试过程。

存储路径可以用于保存目标测试版本对应的测试结果，目标测试版本对应的测试结果可以理解为测试设备在待测试终端的系统版本为目标测试版本的情况下进行测试得到的测试结果。

不同的版本可以对应不同的存储路径，在多个版本中包括目标测试版本的情况下，测试设备可以根据目标测试版本，在预设对应关系中确定目标测试版本对应的测试结果的存储路径。

测试设备向待测试终端发送测试指令的时间点可以存在多种情况。

在一种可能的情况下，测试设备在确定待测试终端的系统版本与目标测试版本相同之后，立即发送测试指令。

在另一种可能的情况下，测试设备在确定待测试终端的系统版本与目标测试版本相同之后，间隔一段时长发送测试指令。该段时长可以是预设的，也可以是测试人员通过测试脚本或者通过人机交互界面设置的。

在又一种可能的情况下，测试设备可以为测试人员在人机交互界面中提供测试控件，当测试设备检测到测试人员点击测试控件的操作时，发送测试指令。

测试结果可以为通过（pass）或者失败（fail）。

当目标测试用例的数量为多个时，测试结果的数量可以为一个，也可以为多个。在测试结果的数量为一个的情况下，该一个测试结果可以包括该多个目标测试用例的测试结果。在测试结果的数量为多个的情况下，测试结果和目标测试用例是一一对应的，测试设备可以分别接收来自待测试终端对该多个目标测试用例的测试结果。

本申请提供的终端设备的测试方法，在测试过程中，测试设备可以自动确定待测试终端的系统版本是否与目标测试版本相同，在相同时自动发送目标测试用例对应的测试指令，并自动获取存储路径，按照存储路径保存测试结果，在整个测试过程中，减少了人工干预，提高了测试效率，有利于实现自动化测试。

结合第一方面，在第一方面的某些实现方式中，在系统版本与目标测试版本不相同的情况下，通过超文本传输协议HTTP访问版本库，版本库中包括多个版本和多个版本中每个版本的软件包；判断多个版本中是否存在目标测试版本；若多个版本中存在目标测试版本，则从版本库中获取目标测试版本的软件包；向待测试终端发送目标测试版本的软件包和版本更新指令，版本更新指令用于指示待测试终端按照目标测试版本的软件包将待测试终端的系统版本更新至目标测试版本；接收来自待测试终端的版本更新结果。

版本库中的多个版本和多个版本的软件包可以预设的，版本库中可以包括不同终端产品的不同版本和该不同版本的软件包，也可以只包括同一终端产品的不同版本和该不同版本的软件包，本申请实施例对此不作限定。

不同的版本可以用不同的版本号或者不同的版本名称加以区别，测试设备可以通过多个版本的版本号或者版本名称判断多个版本中是否存在目标测试版本。

多个版本中存在目标测试版本，可以表示版本库中包括版本库中包括目标测试版本的软件包，测试设备可以从版本库中获取目标测试版本的软件包。

本申请提供的终端设备的测试方法，测试设备在待测试终端的系统版本与目标测试版本不同的情况下，自动获取目标测试版本的软件包，并自动向待测试终端发送目标测试版本的软件包和版本更新指令，以便于待测试终端可以基于该版本更新指令进行更新，可以较少人工在待测试终端下载目标测试版本，提高了测试效率，有利于实现自动化测试。

结合第一方面，在第一方面的某些实现方式中，确定目标测试版本对应的测试结果的存储路径，包括：基于多个版本和多个存储路径之间的预设对应关系，确定目标测试版本对应的测试结果的存储路径。

结合第一方面，在第一方面的某些实现方式中，当出现下列至少一种情况时，测试结果为测试失败：多个版本中不存在目标测试版本；待测试终端的版本更新结果表示待测试终端的系统版本更新失败；或者，测试结果表示对目标测试用例测试失败。

结合第一方面，在第一方面的某些实现方式中，方法还包括：若测试结果为测试失败，统计测试结果为测试失败的次数；在测试失败的次数小于或等于预设阈值的情况下，重新启动目标测试用例的测试流程，直至出现新的测试结果为测试成功或者测试失败的次数大于预设阈值。

本申请提供的终端设备的测试方法，在目标测试用例测试失败、且失败次数未超过预设阈值的情况下，测试设备可以自动重新发送测试指令，可以较少人工重复使用同一目标测试用例进行测试，可以提高测试效率，有利于实现自动化测试。

结合第一方面，在第一方面的某些实现方式中，在重新启动目标测试用例的测试流程之后，方法还包括：若出现新的测试结果为测试成功，则将测试结果更新为测试成功。

结合第一方面，在第一方面的某些实现方式中，方法还包括：在测试失败的次数大于预设阈值的情况下，结束目标测试用例的测试流程，并向目标测试用例对应的研发人员的设备发送测试结果。

结合第一方面，在第一方面的某些实现方式中，存储路径为服务器中的文件路径，方法还包括：向服务器发送测试结果对应的测试数据，测试数据包括目标测试用例在测试过程中的日志信息和/或截图信息。

第二方面，本申请提供了一种终端设备的测试装置，该装置可以用于执行上述第一方面或第一方面任意可能的实现方式中的方法。具体地，该装置包括用于执行上述第一方面或第一方面任意可能的实现方式中的方法的单元。

第三方面，本申请提供了另一种终端设备的测试装置，包括处理器和存储器。该处理器用于读取存储器中存储的指令，并可通过接收器接收信号，通过发射器发射信号，以执行上述第一方面中任一种可能实现方式中的方法。

可选地，处理器为一个或多个，存储器为一个或多个。

可选地，存储器可以与处理器集成在一起，或者存储器与处理器分离设置。

在具体实现过程中，存储器可以为非瞬时性（non-transitory）存储器，例如只读存储器（read only memory，ROM），其可以与处理器集成在同一块芯片上，也可以分别设置在不同的芯片上，本申请实施例对存储器的类型以及存储器与处理器的设置方式不做限定。

应理解，相关的数据交互过程例如发送指示信息可以为从处理器输出指示信息的过程，接收能力信息可以为处理器接收输入能力信息的过程。具体地，处理输出的数据可以输出给发射器，处理器接收的输入数据可以来自接收器。其中，发射器和接收器可以统称为收发器。

上述第三方面中的终端设备的测试装置可以是一个芯片，该处理器可以通过硬件来实现也可以通过软件来实现，当通过硬件实现时，该处理器可以是逻辑电路、集成电路等；当通过软件来实现时，该处理器可以是一个通用处理器，通过读取存储器中存储的软件代码来实现，该存储器可以集成在处理器中，可以位于该处理器之外，独立存在。

第四方面，提供了一种计算机可读存储介质，所述计算机可读存储介质有计算机程序（也可以称为代码，或指令）当其在计算机上运行时，使得计算机执行上述第一方面中任一种可能实现方式中的方法。

第五方面，提供了一种计算机程序产品，计算机程序产品包括：计算机程序（也可以称为代码，或指令），当计算机程序被运行时，使得计算机执行上述第一方面中任一种可能实现方式中的方法。

附图说明

图1是本申请实施例适用的一种测试系统的示意图；

图2是本申请实施例适用的另一种测试系统的示意图；

图3是本申请实施例提供的一种终端设备的测试方法的示意性流程图；

图4是本申请实施例提供的一种保存存储路径的方法的示意性流程图；

图5是本申请实施例提供的一种版本更新方法的示意性流程图；

图6是本申请实施例提供的另一种版本更新方法的示意性流程图；

图7是本申请实施例提供的另一种终端设备的测试方法的示意性流程图；

图8是本申请实施例提供的又一种终端设备的测试方法的示意性流程图；

图9是本申请实施例提供的一种检测待测试终端的版本信息的方法的示意性流程图；

图10是本申请实施例提供的一种生成测试报告的方法的示意性流程图；

图11是本申请实施例提供的一种格式化测试报告的方法的示意性流程图；

图12是本申请实施例提供的一种第一界面的示意图；

图13是本申请实施例提供的又一种终端设备的测试方法的示意性流程图；

图14是本申请实施例提供的筛选目标测试用例的示意图；

图15是本申请实施例提供的设置延时时间的示意图；

图16是本申请实施例提供的设置定时时间的示意图；

图17是本申请实施例提供的另一种第一界面的示意图；

图18是本申请实施例提供的又一种第一界面的示意图；

图19是本申请实施例提供的另一种第一界面的示意图；

图20是本申请实施例提供的一种终端设备的测试装置的示意性框图；

图21是本申请实施例提供的另一种终端设备的测试装置的示意性框图。

具体实施方式

下面将结合附图，对本申请中的技术方案进行描述。

本申请实施例涉及的终端设备可以为手机、平板电脑、个人计算机（personalcomputer，PC）、智能手表等可穿戴电子设备，各种教学辅助工具（例如学习机、早教机）、智能玩具、便携式机器人、个人数字助理（personal digital assistant，PDA）、增强现实技术（augmented reality，AR）设备、虚拟现实（virtual reality，VR）设备等。应理解，本申请的实施例对终端设备所采用的具体技术和具体设备形态不做限定。

为了便于描述，本申请实施例中测试终端设备的设备可以称为测试设备，被测试的终端设备可以称为待测试终端，但本申请实施例对此不作限定。

本申请实施例中的测试设备可以为安装有windows系统的任意设备，本申请实施例对此不做限定。

随着终端技术的发展，终端设备的形态日趋增多，例如，智能手机、智能电脑以及智能手表等等，对终端设备的测试也提出了新的挑战。目前，测试终端设备可以由多个测试人员共同完成，每个测试人员可以测试待测试终端的一部分功能。待测试终端的测试报告可以由每个测试人员得到的测试结果组成。

示例性地，待测试终端可以为手机，测试手机的功能可以由5个测试人员共同完成，该5个测试人员可以分别为测试人员1、测试人员2、测试人员3、测试人员4以及测试人员5。测试人员1可以通过测试设备1测试手机的通话功能，测试人员2可以通过测试设备2测试手机的拍照功能，测试人员3可以通过测试设备3测试手机的联网功能，测试人员4可以通过测试设备4测试手机的用户识别模块（subscriber identity module，SIM）功能，测试人员5可以通过测试设备5测试手机的提示功能（例如短信提示、闹钟提示等）。测试人员1、测试人员2、测试人员3、测试人员4以及测试人员5得到的测试结果可以组成手机的测试报告，以作为评价手机功能的依据。

测试人员对待测试终端进行测试的过程中，仍存在许多人工干预的过程，严重降低测试效率。

示例性地，以上述测试人员1通过测试设备1测试手机的通话功能为例进行详细说明。图1示出了一种测试系统100的示意图。该测试系统100包括手机101和测试设备102。其中，测试设备102可以理解为上述示例中的测试设备1，手机101可以理解为上述示例中的待测试的手机，测试设备102用于测试手机101的通话功能。手机101和测试设备102之间可以通过通用串行总线（universal serial bus，USB）口连接，但本申请实施例对此不作限定。

测试人员1通过测试设备102测试手机101的过程可以包括：测试人员1手动在测试用例的保存路径下找到测试手机101的测试用例，并在测试手机101的测试用例中通过手动查找确定测试通话对应的测试用例（可以简称为“通话测试用例”）。测试人员1可以根据手机101的型号、版本等信息编写调用通话测试用例的脚本，以通过该脚本调用通话测试用例对手机101进行通话测试，得到测试结果。测试人员1需要手动将测试结果保存在特定的路径下，以供后续查看或统计。

上述过程存在许多人工干预的过程，导致测试效率不高。有鉴于此，本申请实施例提供一种终端设备的测试方法和测试装置，可以尽可能地减少测试过程中的人工干预，提高测试效率。

本申请实施例提供的终端设备的测试方法可以适用于图1所示的通信系统，还可以适用于另一种测试系统200，如图2所示，该测试系统200可以包括手机101、测试设备102以及服务器201。该测试系统200中可以包括一个或多个测试设备，测试系统200中的测试设备的个数仅仅为一个示例，本申请实施例对测试设备的具体个数不做限定。

测试设备102可以对手机101进行测试，得到测试结果。服务器201可以用于接收并汇总来自测试设备102的测试结果和测试结果对应的测试数据。当测试设备为多个时，服务器201可以接收来自多个测试设备的测试结果和测试结果对应的测试数据。

在介绍本申请实施例提供的终端设备的测试方法和测试装置之前，先做出以下几点说明。

第一，在下文示出的实施例中，各术语及英文缩略语，如目标测试用例、目标测试版本以及存储路径等，均为方便描述而给出的示例性举例，不应对本申请构成任何限定。本申请并不排除在已有或未来的协议中定义其它能够实现相同或相似功能的术语的可能。

第二，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项（个）”或其类似表达，是指的这些项中的任意组合，包括单项（个）或复数项（个）的任意组合。例如，a、b和c中的至少一项（个），可以表示：a，或b，或c，或a和b，或a和c，或b和c，或a、b和c，其中a，b，c可以是单个，也可以是多个。

图3为本申请实施例提供的一种终端设备的测试方法300的示意性流程图，该方法300可以应用于上述图1所示的测试系统100，也可以应用于上述图2所示的测试系统200，本申请实施例对此不作限定。该方法300中的测试设备，例如上述图1中的测试设备102，该方法300中的待测试终端可以为任意终端设备，例如上述图1中的手机101，但本申请实施例对此不作限定。

如图3所示，该方法300可以包括以下步骤：

S301、测试设备确定目标测试用例和目标测试版本。

目标测试用例和目标测试版本可以是根据测试人员的需要确定的。例如，测试人员想要测试手机在版本1.0下的通话功能，可以通过测试设备将目标测试版本设置为1.0，并通过测试设备选择测试通话的测试用例。应理解，目标测试用例为测试人员想要测试的版本，目标测试用例为测试人员想要测试的功能对应的测试用例。

测试设备确定目标测试用例和目标测试版本可以存在多种实现方式。

在一种可能的实现方式中，测试设备可以通过测试脚本确定目标测试用例和目标测试版本，该测试脚本为测试人员编写的，可以用于调用目标测试用例，并通过参数配置了测试人员想要测试的版本，即目标测试版本。

在另一种可能的实现方式中，测试设备可以为测试人员提供人机交互界面，该人机交互界面可以提供测试版本的输入框和测试用例的输入框。

示例性地，人机交互界面可以提供测试版本的输入框和测试用例的输入框，测试人员可以在人机交互界面中测试版本的输入框输入1.0，在测试用例的输入框输入通话测试用例的编号，测试设备响应于测试人员的输入操作，可以确定目标测试版本为1.0，目标测试用例为通话测试用例。

可选地，测试设备可以包括测试用例库，该测试用例库包括功能、制式以及测试用例编号之间的对应关系，人机交互界面还可以提供测试用例的筛选框，该筛选框可以包括功能筛选框和制式筛选框。其中，制式可以分为单卡和双卡两种制式，功能可以分为通话功能、拍照功能、联网功能以及提示功能等，本申请实施例对具体的功能不做限定。

测试人员可以在功能筛选框和制式筛选框中进行选择，测试设备根据测试人员选择的功能和制式，从测试用例库中确定测试用例编号，并将测试用例编号输入至测试用例的输入框。

示例性地，测试用例库可以如表一所示。

表一

测试用例编号	功能	制式
			1000	通话功能	单卡
1001	拍照功能	单卡
			1010	通话功能	双卡
1011	拍照功能	双卡

如表一所示，测试用例库中测试用例编号1000、通话功能以及单卡之间是对应的，测试用例编号1001、拍照功能以及单卡之间是对应的，测试用例编号1010、通话功能以及双卡之间是对应的，测试用例编号1011、拍照功能以及双卡之间是对应的。

当测试人员在功能筛选框中选择通话功能，在制式筛选框中选择单卡时，测试用例的输入框可以显示测试用例编号1000。

S302、测试设备判断待测试终端的系统版本是否与目标测试版本相同。

测试设备需要先确定待测试终端的系统版本是否为目标测试版本，在待测试终端的系统版本为目标测试版本的情况下，进行后续的测试。在待测试终端的系统版本不是目标测试版本的情况下，测试设备将不会进行后续的测试，或者，先将待测试终端的系统版本更新为目标测试版本，再进行后续的测试过程。

示例性地，测试人员想要通过测试设备测试版本为1.0的手机，测试设备可以将目标测试版本确定为版本1.0，同时获取手机的系统版本，判断手机的系统版本是否为版本1.0，若手机的系统版本不为版本1.0，则说明不是测试人员想要测试的版本，测试设备将不会进行测试。若手机的系统版本为版本1.0，则说明是测试人员想要测试的版本，测试设备进行后续的测试。

S303、测试设备确定目标测试版本对应的测试结果的存储路径。

存储路径可以用于保存目标测试版本对应的测试结果，目标测试版本对应的测试结果可以理解为测试设备在待测试终端的系统版本为目标测试版本的情况下进行测试得到的测试结果。例如，存储路径可以是www.1.2.0.com。存储路径也可以称为回填路径，本申请实施例对此不作限定。

存储路径可以保存在服务器中，也可以保存在测试设备中，本申请实施例对此不作限定。

示例性地，测试设备可以从服务器中获取目标测试版本对应的测试结果的存储路径。具体地，测试设备可以通过超文本传输协议（hypertext transfer protocol，HTTP）中的 get方法从服务器中确定目标测试版本对应的测试结果的存储路径，其中，get方法可以用于请求获取目标测试版本对应的测试结果的存储路径。

可选地，测试设备可以基于多个版本和多个存储路径之间的预设对应关系，确定目标测试版本对应的测试结果的存储路径。

不同的版本可以对应不同的存储路径，在多个版本中包括目标测试版本的情况下，测试设备可以根据目标测试版本，在预设对应关系中确定目标测试版本对应的测试结果的存储路径。

可选地，上述多个版本和多个存储路径之间的预设对应关系可以存储在服务器中，测试设备可以向服务器发送目标测试版本，服务器可以根据目标测试版本，在预设对应关系中确定目标测试版本对应的测试结果的存储路径。

S304、在待测试终端的系统版本与目标测试版本相同的情况下，测试设备向待测试终端发送测试指令，测试指令用于指示待测试终端执行目标测试用例，对应地，待测试终端接收该测试指令。

示例性地，目标测试版本可以为版本1.0，测试设备获取待测试终端的系统版本也为版本1.0，则待测试终端的系统版本与目标测试版本相同，在该情况下，测试设备向待测试终端发送测试指令。

测试设备向待测试终端发送测试指令的时间点可以存在多种情况。

在一种可能的情况下，测试设备在确定待测试终端的系统版本与目标测试版本相同之后，立即发送测试指令。

在另一种可能的情况下，测试设备在确定待测试终端的系统版本与目标测试版本相同之后，间隔一段时长发送测试指令。该段时长可以是预设的，也可以是测试人员通过测试脚本或者通过人机交互界面设置的。

在又一种可能的情况下，测试设备可以为测试人员在人机交互界面中提供测试控件，当测试设备检测到测试人员点击测试控件的操作时，发送测试指令。

测试指令用于指示待测试终端执行目标测试用例，目标测试用例的数量可以为一个或者多个，本申请实施例对此不作限定。

当目标测试用例的数量为多个时，测试指令的数量可以为一个，也可以为多个。在测试指令的数量为一个的情况下，该一个测试指令用于指示待测试终端执行多个目标测试用例。在测试指令的数量为多个的情况下，目标测试用例和测试指令可以是一一对应的。

S305、待测试终端向测试设备发送目标测试用例的测试结果，对应地，测试设备接收目标测试用例的测试结果。

测试结果可以为通过（pass）或者失败（fail），即用pass表示测试通过，用fail表示测试失败。其中，测试通过也可以称为测试成功，本申请实施例对此不作限定。

示例性地，目标测试用例可以为测试通话的测试用例，可以用于测试待测试终端是否能拨打电话号码，测试设备向待测试终端发送测试指令，测试指令用于指示待测试终端执行目标测试用例，即指示待测试终端拨打电话号码，该电话号码可以是10086等公知的电话，也可以拨打测试人员或者其他测试人员的电话号码，如159****1223，此示例不作限定。若待测试设备可以通过电话号码拨通电话，可以表示待测试终端的通过功能良好，可以向测试设备发送pass，用以表示测试通过。若待测试设备通话电话号码未能成功拨通电话，可以表示待测试终端的通话功能存在故障，可以向测试设备发送fail，用以表示测试失败。

示例性地，目标测试用例可以为测试相机的测试用例，可以用于测试待测试终端是否可以拍照，测试设备向待测试终端发送测试指令，测试指令用于指示待测试终端执行目标测试用例，即指示待测试终端拍摄照片。若待测试设备可以成功拍摄照片，可以表示待测试终端的相机功能良好，可以向测试设备发送pass，用以表示测试通过。若待测试设备未能成功拍摄照片，可以表示待测试终端的相机功能存在故障，可以向测试设备发送fail，用以表示测试失败。

当目标测试用例的数量为多个时，测试结果的数量可以为一个，也可以为多个。在测试结果的数量为一个的情况下，该一个测试结果可以包括该多个目标测试用例的测试结果。在测试结果的数量为多个的情况下，测试结果和目标测试用例是一一对应的，测试设备可以分别接收来自待测试终端对该多个目标测试用例的测试结果。

示例性地，目标测试用例的数量为3个，该3个目标测试用例分别为目标测试用例1、目标测试用例2以及目标测试用例3，测试设备可以接收到1个测试结果，该测试结果可以为目标测试用例1通过、目标测试用例2失败以及目标测试用例3通过，或者，测试设备可以接收到3个测试结果，该3个测试结果分别为目标测试用例1通过、目标测试用例2失败以及目标测试用例3通过。

需要说明的是，当目标测试用例的数量为多个、且测试指令为一个时，测试结果可以为一个或多个。当目标测试用例的数量为多个、且测试指令为多个时，测试结果可以为一个或多个，本申请对此不作限定。

S306、测试设备按照存储路径，存储目标测试用例的测试结果。

测试设备接收到测试结果后，按照存储路径保存测试结果。

示例性地，存储路径可以是www.1.2.0.com，目标测试用例的测试结果可以为fail，测试设备可以按照存储路径www.1.2.0.com存储测试结果fail。

可选地，在存储路径中可以存在预设的文件，测试设备还可以按照存储路径将目标测试用例的测试结果存储在存储路径中的文件中，但本申请实施例并不限于文件。

若该测试结果是以文件的形式保存，具体可以存储为不同的文件格式，例如word、PDF、txt等等，本申请实施例对测试结果的具体存储格式不作限定。

当测试结果的数量存在多个时，测试设备可以将该多个测试结果分别存储在不同的文件中，也可以将该多个测试结果存储在同一个文件中，本申请实施例对此不作限定。

示例性地，当测试结果的数量为3个时，测试设备可以将该3个测试结果分别保存在文件1、文件2以及文件3中，也可以将该3个测试结果均保存在文件1中。

本申请实施例提供的终端设备的测试方法，在测试过程中，测试设备可以自动确定待测试终端的系统版本是否与目标测试版本相同，在相同时自动发送目标测试用例对应的测试指令，并自动获取存储路径，按照存储路径保存测试结果，在整个测试过程中，减少了人工干预，提高了测试效率，有利于实现自动化测试。

作为一个可选的实施例，上述S303、测试设备确定目标测试版本对应的测试结果的存储路径之后，测试设备还可以将存储路径作为配置信息保存在配置文件中，当测试设备执行S306、按照存储路径，存储目标测试用例的测试结果时，测试设备可以获取配置文件中的存储路径，并按照存储路径，存储目标测试用例的测试结果。

示例性地，如图4所示，测试设备可以判断存储路径是否确定成功，在确定成功的情况下，将存储路径写入配置文件中，在确定失败的情况下，通过邮件推送确定存储路径失败的信息。

若测试设备可以获取到存储路径，则测试设备可以判断存储路径确定成功，若测试设备未获取到存储路径，则测试设备可以判断存储路径确定失败。

在确定成功的情况下，测试设备可以通过特定规则将存储路径写入配置文件中，该特定规则可以指任意将存储路径写入配置文件的方式，本申请实施例对此不作限定。

在确定失败的情况下，测试设备可以向测试人员的邮件发送邮件，该邮件可以包括确定存储路径失败的信息，可以用于提示测试人员进行调整，使以正常测试。

本申请实施例提供的终端设备的测试方法，可以在确定存储路径存储路径保存在配置文件中，便于以后使用时获取，不需要每次使用时，再次确定存储路径，可以节省测试设备的处理能力，提高测试效率，有利于实现自动化测试。

作为一个可选的实施例，在待测试终端的系统版本不是目标测试版本的情况下，上述测试设备需要先将待测试终端的系统版本更新为目标测试版本，再进行后续的测试过程。应理解，待测试终端的版本更新应该在上述S302和S303之间执行，且执行条件为系统版本与目标测试版本不相同。

示例性地，图5示出了一种版本更新方法500的示意性流程图。如图5所示，方法500可以包括以下步骤：

S501、在系统版本与目标测试版本不相同的情况下，测试设备通过HTTP访问版本库，版本库中包括多个版本和多个版本中每个版本的软件包。

示例性地，目标测试版本可以为版本2.0，测试设备获取待测试终端的系统版本为版本1.0，则待测试终端的系统版本与目标测试版本不相同，在该情况下，测试设备通过HTTP访问版本库。

版本库可以存储在服务器中，测试设备通过HTTP访问服务器中的版本库。

版本库中的多个版本和多个版本的软件包可以预设的，版本库中可以包括不同终端产品的不同版本和该不同版本的软件包，也可以只包括同一终端产品的不同版本和该不同版本的软件包，本申请实施例对此不作限定。

示例性地，版本库中的多个版本和多个版本的软件包可以保存在特定的网站中，测试设备可以通过HTTP访问网站中的版本库。

S502、测试设备判断多个版本中是否存在目标测试版本。

不同的版本可以用不同的版本号或者不同的版本名称加以区别，测试设备可以通过多个版本的版本号或者版本名称判断多个版本中是否存在目标测试版本。

示例性地，目标测试版本可以为版本2.0，则版本号可以为2.0，测试设备可以判断多个版本的版本号是否存在2.0，若存在，则可以表示多个版本中存在目标测试版本。若不存在，则可以表示多个版本中不存在目标测试版本。

若多个版本中存在目标测试版本，可以表示版本库中包括版本库中包括目标测试版本的软件包，若多个版本中不存在目标测试版本，可以表示版本库中未保存目标测试版本和目标测试版本的软件包，或者，可以表示测试设备访问错误。

S503、若多个版本中存在目标测试版本，测试设备则从版本库中获取目标测试版本的软件包。

多个版本中存在目标测试版本，可以表示版本库中包括版本库中包括目标测试版本的软件包，测试设备可以从版本库中获取目标测试版本的软件包。

示例性地，版本库可以保存在服务器中，在多个版本中存在目标测试版本的情况下，测试设备向服务器发送获取目标测试版本的软件包的请求，并接收来自服务器的目标测试版本的软件包。

可选地，在多个版本不存在目标测试版本的情况下，测试设备可以接收来自服务器的通知消息，该通知消息用于通知测试设备未获取成功。该通知消息的表现形式可以是邮件、短信或者弹框等，本申请实施例对此不作限定。

S504、测试设备向待测试终端发送目标测试版本的软件包和版本更新指令，版本更新指令用于指示待测试终端按照目标测试版本的软件包将待测试终端的系统版本更新至目标测试版本，对应地，待测试终端接收目标测试版本的软件包和版本更新指令。

目标测试版本的软件包和版本更新指令可以是测试设备并行向待测试终端发送的，也可以是测试设备依次向待测试终端发送的，本申请实施例对此不作限定。

目标测试版本的软件包可以是压缩包的形式，也可以是文件的形式，本申请实施例对此不作限定。

S505、待测试终端基于版本更新指令，按照目标测试版本的软件包将待测试终端的系统版本更新至目标测试版本。

示例性地，目标测试版本为版本2.0，待测试终端的系统版本为版本1.0，待测试终端可以基于版本更新指令，按照版本2.0的软件包将待测试终端的版本1.0更新至版本2.0。

更新至目标测试版本的待测试终端也可以称为升级后的待测试设备，本申请实施例对此不作限定。

S506、待测试终端向测试设备发送版本更新结果，对应地，测试设备接收版本更新结果。

版本更新结果可以是更新成功的消息，也可以是更新失败的消息。若测试设备接收到更新成功的消息，可以进行后续的测试，即可以继续进行上述S302~S306。

若版本更新结果为更新失败的消息，该消息的表现形式可以是邮件、短信或者弹框等，本申请实施例对此不作限定。

本申请实施例提供的终端设备的测试方法，测试设备在待测试终端的系统版本与目标测试版本不同的情况下，自动获取目标测试版本的软件包，并自动向待测试终端发送目标测试版本的软件包和版本更新指令，以便于待测试终端可以基于该版本更新指令进行更新，可以较少人工在待测试终端下载目标测试版本，提高了测试效率，有利于实现自动化测试。

作为一个可选的实施例，在上述S506之后，测试设备还可以对待测试终端进行初始化设置。

示例性地，如图6所示，上述方法500还可以包括以下步骤：

S507、测试设备基于版本更新结果，判断是否更新成功。

当版本更新结果为更新成功时，测试设备可以判断更新成功，当版本更新结果为更新失败时，测试设备可以判断更新失败。应理解，本申请实施例对测试设备如何判断是否更新成功的具体方式不作限定。

在更新成功的情况下，测试设备可以执行S508，在更新失败的情况下，测试设备可以执行S511。

S508、测试设备对升级后的待测试终端进行初始化设置。

测试设备可以向升级后的待测试终端发送指示信息，该指示信息用于指示待测试终端进行初始化，对应地，升级后的待测试终端可以接收该指示信息，并基于该指示信息，进行初始化，并可以向测试设备发送初始化的结果。其中，初始化的结果可以是初始化成功，也可以是初始化失败，本申请实施例对此不作限定。

S509、测试设备判断是否初始化成功。

当初始化的结果为初始化成功时，测试设备可以判断初始化成功，当初始化的结果为初始化失败时，测试设备可以判断初始化失败。

在初始化成功的情况下，测试设备可以执行S510，在初始化失败的情况下，测试设备可以执行S512。

S510、测试设备开启自动化测试流程。

在初始化成功的情况下，测试设备可以开始测试，即执行上述S302~S306，具体实现方式可以参考上述描述，此处不再赘述。

S511、测试设备通过邮件推送更新失败的信息。

具体地，测试设备可以向测试人员的邮箱发送邮件，该邮件可以包括更新失败的信息，可以用于提示测试人员进行调整，使以正常测试。

S512、测试设备通过邮件推送初始化失败的信息。

具体地，测试设备可以向测试人员的邮箱发送邮件，该邮件可以包括初始化失败的信息，可以用于提示测试人员进行调整，使以正常测试。

本申请实施例提供的终端设备的测试方法，测试设备将待测试终端的系统版本更新为目标测试版本之后，还可以进行初始化设置，可以较少人为对待测试终端的初始化，可以提高测试效率，有利于实现自动化测试。

可选地，当待测试终端存在新系统版本发布时，测试设备需要测试新系统版本，测试系统可以接收推送新系统版本的服务器的信息，该信息可以包括新系统版本的软件包和推送新系统版本的时间。测试系统接收到该信息后，可以在推送新系统版本的时间向待测试终端发送新系统版本的软件包和版本更新指令，该版本更新指令用于指示待测试终端按照新系统版本的软件包将待测试终端的系统版本更新至新系统版本。应理解，新系统版本即为目标测试版本。

本申请实施例提供的终端设备的测试方法，测试设备可以与发布待测试终端版本的服务器进行通信，可以及时获得待测试终端新系统版本的软件包，可以自动向待测试终端发送该版本更新指令，可以较少人工在待测试终端下载新系统版本，并在推送版本之后及时进行测试，可以提高测试效率，有利于实现自动化测试。

作为一个可选的实施例，上述方法300和方法500中，当出现下列至少一种情况时，测试结果为测试失败：多个版本中不存在目标测试版本；待测试终端的版本更新结果表示待测试终端的系统版本更新失败；或者，测试结果表示对目标测试用例测试失败。

在上述S303、若测试设备基于多个版本和多个存储路径之间的预设对应关系，确定目标测试版本对应的测试结果的存储路径中，若多个版本中不存在目标测试版本，则可以表示测试设备对待测试终端的测试结果为失败。

在上述S506、待测试终端向测试设备发送版本更新结果中，若版本更新结果为更新失败的消息，则可以表示测试设备对待测试终端的测试结果为失败。

在上述S305、待测试终端向测试设备发送目标测试用例的测试结果，对应地，测试设备接收目标测试用例的测试结果中，测试结果为失败，则可以表示目标测试用例测试失败。

作为一个可选的实施例，在上述方法300的 S305中，测试结果为失败，即目标测试用例测试失败的情况下，测试设备可以自动重新向待测试终端发送测试指令，测试指令用于指示待测试终端执行目标测试用例。

具体而言，若测试结果为测试失败，测试设备可以统计测试结果为测试失败的次数；在测试失败的次数小于或等于预设阈值的情况下，测试设备可以重新启动目标测试用例的测试流程，直至出现新的测试结果为测试成功或者测试失败的次数大于预设阈值。

可选地，在重新启动目标测试用例的测试流程之后，若出现新的测试结果为测试成功，测试设备则将测试结果更新为测试成功。

可选地，在测试失败的次数大于预设阈值的情况下，测试设备可以结束目标测试用例的测试流程，并向目标测试用例对应的研发人员的设备发送测试结果。

示例性地，图7示出了另一种终端设备的测试方法700的示意性流程图。如图7所示，该方法700可以包括如下步骤：

S701、当测试结果为测试失败时，测试设备统计测试结果为测试失败的次数。

测试设备统计测试结果为测试失败的次数，即将测试失败的次数加1。应理解，测试失败的次数初始值为0，当目标测试用例的测试结果为测试失败，测试设备可以将该目标测试用例对应的测试失败的次数加1。

还应理解，当目标测试用例的数量为多个时，该多个目标测试用例分别对应一个测试失败次数，初始值均为0。

S702、测试设备判断测试失败的次数是否小于或等于预设阈值。

预设阈值可以是大于0的整数，例如，预设阈值可以为3。

当测试失败的次数小于或等于预设阈值时，测试设备可以再次使用目标测试用例进行测试，当测试失败的次数大于预设阈值时，测试设备可以不使用该目标测试用例进行测试。

S703、在测试失败的次数小于或等于预设阈值的情况下，测试设备重新启动目标测试用例的测试流程。

测试设备重新启动目标测试用例的测试流程，即重新向待测试终端发送测试指令，测试指令用于指示待测试终端执行目标测试用例，接收待测试终端的新的测试结果。

S704、测试设备判断新的测试结果是否为成功。

若新的测试结果为测试通过（即pass），测试设备可以判断新的测试结果为测试成功，若新的测试结果为测试失败（即fail），测试设备可以判断新的测试结果为测试失败。

若新的测试结果为测试通过，测试设备可以执行S705，若新的测试结果为测试失败，测试设备可以执行S701，即测试设备可以将该目标测试用例对应的测试失败的次数再加1。

S705、若出现新的测试结果为测试成功，测试设备则将测试结果更新为测试成功。

在测试结果为测试成功的情况下，测试设备可以将目标测试用例的测试结果更新为测试成功。

S706、在测试失败的次数大于预设阈值的情况下，测试设备结束目标测试用例的测试流程。

测试设备结束目标测试用例的测试流程，即测试设备不会再重新向待测试终端发送测试指令。

S707、测试设备向目标测试用例对应的研发人员的设备发送测试结果。

在测试失败的次数大于预设阈值的情况下，测试设备向目标测试用例对应的研发人员的设备发送测试结果，该测试结果为失败。

本申请实施例提供的终端设备的测试方法，在目标测试用例测试失败、且失败次数未超过预设阈值的情况下，测试设备可以自动重新发送测试指令，可以较少人工重复使用同一目标测试用例进行测试，可以提高测试效率，有利于实现自动化测试。

可选地，当目标测试用例的数量为多个、且该多个目标测试用例中存在部分目标测试用例的测试结果为失败时，测试设备重新启动目标测试用例的测试流程存在两种可实现的方式。

在一种可实现的方式中，当测试设备检测到目标测试用例的测试结果为失败时，立即重新启动目标测试用例的测试流程。

在另一种可实现的方式中，在测试设备得到该多个目标测试用例的测试结果之后，针对部分测试结果为失败的目标测试用例，分别重新启动目标测试用例的测试流程。

在上述两种可实现的方式中，当存在一个目标测试用例的测试失败次数大于预设阈值时，可以立即向目标测试用例对应的研发人员的设备发送测试结果，也可以在测试设备得到多个目标测试用例中所有测试失败次数大于预设阈值的目标测试用例之后，分别向目标测试用例对应的研发人员的设备发送测试结果。

本申请实施例还提供一种终端设备的测试方法，该方法可以适用于上述图2所示的测试系统200。该方法可以包括：测试设备（例如图2所示的测试设备102）可以按照上述方法300对待测试终端（例如图2所示的手机102）进行测试，得到测试结果，其中，方法300的S303、测试设备确定目标测试版本对应的测试结果的存储路径中，存储路径可以为服务器中的文件路径。例如，服务器可以是图2所示的服务器201。

测试设备在执行上述方法300之后，还可以向服务器发送测试结果对应的测试数据。测试数据包括目标测试用例在测试过程中的日志信息和/或截图信息，对应地，服务器接收测试设备的测试数据。

测试设备可以将目标测试用例在测试过程中产生的日志信息和/或截图信息、以及测试结果按照存储路径保存在服务器中。

示例性地，测试设备可以通过套接字（socket）方法，按照存储路径向服务器发送日志信息、截图信息以及测试结果。

应理解，服务器可以接收至少一个测试设备的测试结果，该至少一个测试设备可以用于测试上述待测试终端的其他功能，也可以用于测试其他测试终端的功能，本申请实施例对此不作限定。

可选地，存储路径下可以包括多个文件夹，该多个文件夹可以用于保存多个目标测试用例的测试结果，应理解，文件夹和目标测试结果可以是一一对应的。

测试设备接收到测试结果后，可以自动按照存储路径判断是否存在目标测试用例对应的文件夹，若存在，则将测试结果保存至目标测试用例对应的文件夹；若不存在，则创建目标测试用例对应的文件夹，并将测试结果保存至创建的文件夹。

可选地，当至少一个测试设备用于测试上述待测试终端的其他功能时，服务器可以对接收到的至少一个测试设备的测试结果进行统计，并按照预设规则得到测试报告。测试报告的表现形式可以为图形、列表或者文字，本申请实施例对此不作限定。

示例性地，表二示出了一种测试报告。

表二

功能模块	通话功能	拍照功能	联网功能	提示功能
					失败的测试用例（个）	3	2	1	2
重跑的测试用例（个）	10	5	6	4
					通过的测试用例（个）	15	20	18	22
总测试用例（个）	18	22	19	24

如表二所示，待测试终端的功能模块包括通话功能、拍照功能、联网功能以及提示功能。对于通话功能的测试结果中，总测试用例为18个，失败的测试用例为3个，重跑的测试用例为10个，通过的测试用例为15个；对于拍照功能的测试结果中，总测试用例为22个，失败的测试用例为2个，重跑的测试用例为5个，通过的测试用例为20个；对于联网功能的测试结果中，总测试用例为19个，失败的测试用例为1个，重跑的测试用例为6个，通过的测试用例为18个；对于提示功能的测试结果中，总测试用例为24个，失败的测试用例为2个，重跑的测试用例为4个，通过的测试用例为22个。

服务器得到测试报告后，可以自动向该至少一个测试设备、研发人员的设备、部门领导的设备等发送测试报告。应理解，接收测试报告的设备可以是预设的，也可以是测试人员手动设置的，本申请实施例对此不作限定。测试报告可以是邮件、短信或者弹框的形式显示在接收测试报告的设备中，本申请实施例对此不作限定。

可选地，测试报告中还可以包括失败的测试用例的链接，研发人员可以直接通过测试报告上的链接确定失败的测试用例，以便于后续对测试用例进行修改。

本申请实施例提供的终端设备的测试方法，服务器可以接收测试数据和测试结果，并对测试结果进行统计，可以节省测试设备的存储功能和处理功能，同时，服务器可以将测试报告发送给多个设备，以便于后续的维护管理，有利于实现自动化测试。

图8为本申请实施例提供的又一种终端设备的测试方法800的示意性流程图，该方法800是上述方法300的一种具体实现方式。该方法800可以应用于上述图2所示的测试系统200，本申请实施例对此不作限定。该方法800中的测试设备，例如上述图2中的测试设备102，该方法800中的待测试终端可以为任意终端设备，例如上述图2中的手机101，该方法800中的服务器，例如上述图2中的服务器201，但本申请实施例对此不作限定。

如图8所示，该方法800可以包括以下步骤：

S801、测试设备确定目标测试用例、目标测试版本和待测试终端的信息。

测试设备确定目标测试用例和目标测试版本的方法可以参考上述S301，此处不再赘述。

待测试终端的信息可以包括待测试终端的的序列号和待测试终端的端口号，但本申请实施例并不限于此。

测试设备确定待测试终端的信息可以存在多种实现方式。

在一种可能的实现方式中，测试设备可以通过测试脚本确定待测试终端的信息，该测试脚本为测试人员编写的，可以用于调用目标测试用例，并通过参数配置了待测试终端的信息。

在另一种可能的实现方式中，测试设备可以为测试人员提供人机交互界面，该人机交互界面可以提供待测试终端的信息的输入框。测试设备可以通过待测试终端的信息的输入框获取待测试终端的信息。

S802、测试设备定时启动测试流程。

测试设备定时启动测试流程，即测试设备在某一个时间点启动测试流程，该时间点可以是测试人员设置的。

示例性地，测试设备可以为测试人员提供人机交互界面，该人机交互界面可以提供定时测试时间输入框，测试设备可以通过定时测试时间输入框获取定时测试时间，当定时测试时间到达时，启动测试流程。

S803、测试设备检测待测试终端的版本信息。

测试设备检测待测试终端的版本信息，以此判断是否要更新待测试终端的版本。测试设备可以判断待测试终端的版本列表中是否存在比当前系统版本高的新系统版本，在存在新系统版本且为目标测试版本的情况下，将待测试终端的系统版本更新为新系统版本，即可以执行S804。

S804、当待测试终端的系统版本低于目标测试版本时，测试设备将待测试终端的系统版本更新至目标测试版本。

测试设备可以获取目标测试版本的软件包，并按照该软件包将待测试终端的系统版本更新至目标测试版本，具体实现方式可以参考上述方法500，此处不再赘述。

S805、测试设备确定目标测试版本对应的测试结果的存储路径。

具体实现步骤可以参考上述S303，此处不再赘述。

S806、待测试终端执行目标测试用例。

测试设备向待测试终端发送测试指令，测试指令用于指示待测试终端执行目标测试用例，待测试终端接收该测试指令，并基于该测试指令执行目标测试用例，同时可以向测试设备发送测试结果。

测试结果可以为测试成功，也可以为测试失败，本申请实施例对此不作限定。

S807、测试设备判断是否测试成功。

当测试结果为测试成功时，测试设备可以判断测试成功，当测试结果为测试失败时，测试设备可以判断测试失败。

在测试结果为测试失败的情况下，测试设备可以执行S808。在测试结果为测试成功的情况下，测试设备可以执行S809。

S808、在测试结果为测试失败的情况下，待测试终端再次执行目标测试用例。

当测试结果为测试失败时，测试设备可以再次向待测试终端发送测试指令，测试指令用于指示待测试终端执行目标测试用例，待测试终端接收该测试指令，并基于该测试指令执行目标测试用例，同时可以向测试设备发送测试结果。测试设备可以继续执行上述S807，判断测试结果是否为测试成功。当测试结果为测试失败的情况下，测试设备可以执行S808。在测试结果为测试成功的情况下，测试设备可以执行S809。

可选地，当测试结果为测试失败时，测试设备可以执行上述方法700，本申请实施例不作限定。

S809、在测试结果为测试成功的情况下，测试设备按照存储路径，存储目标测试用例的测试结果。

此步骤的具体实现方式可以参考上述S306，此处不再赘述。

S810、测试设备向服务器发送测试结果和测试数据，对应地，服务器接收测试结果和测试数据。

测试数据包括目标测试用例在测试过程中的日志信息和/或截图信息。测试结果可以为测试通过或者测试失败，与上述方法300中的测试结果相同，此处不再赘述。

S811、服务器基于测试结果和测试数据，生成测试报告。

服务器可以基于特定规则将测试结果和测试数据进行汇总，生成测试报告。例如，服务器可以基于特定规则生成如上述表二所示的测试报告。应理解，特定规则为生成测试报告的任意实现方式，本申请实施例对此不作限定。

S812、服务器通过邮件向对应人发送测试报告。

对应人可以是测试人员、研发人员以及部门领导等人。服务器可以向测试人员、研发人员以及部门领导的邮箱发送邮件，该邮件可以包括测试报告。

本申请实施例提供的终端设备的测试方法，在测试过程中，测试设备可以自动检测待测试终端的版本信息，在系统版本与目标测试版本不同的情况下，自动将待测试终端的系统版本更新至目标测试版本，同时在测试失败的情况下，可以自动重新执行测试用例，还可以通过服务器生成测试报告，在整个测试过程中，减少了人工干预，提高了测试效率，有利于实现自动化测试。

作为一个可选的实施例，上述S803、测试设备检测待测试终端的版本信息，可以包括：测试设备可以判断待测试终端的版本列表中是否存在比当前系统版本高的新系统版本，在存在新系统版本且为目标测试版本的情况下，将待测试终端的系统版本更新为新系统版本。

示例性地，图9示出了一种检测待测试终端的版本信息的方法900的示意性流程图。如图9所示，该方法900可以包括以下步骤：

S901、测试设备通过HTTP访问版本库，版本库中包括多个版本列表，多个版本列表中每个版本列表均包括多个版本。

版本库的访问方式可以参考上述S501，此处不再赘述。

不同型号的待测试设备可以对应不同的版本列表，版本库可以包括不同型号对应的版本列表。

S902、测试设备判断在版本库中是否能匹配到待测试终端的版本列表。

测试设备可以通过特定规则在版本库匹配出待测试终端的版本列表，本申请实施例对特定规则不作限定，可以匹配出待测试终端的版本列表的方法均在本申请实施例的保护范围内。

待测试终端的版本列表的数量可以为一个，也可以为多个，本申请实施例对此不作限定。

若测试设备可以匹配到待测试终端的版本列表，则可以执行S903，若测试设备匹配不到待测试终端的版本列表，则可以执行S906。

S903、测试设备判断待测试终端的版本列表中是否存在新系统版本，该新系统版本是高于待测试终端的系统版本的。测试设备可以通过特定规则，将待测试终端的系统版本与待测试终端的版本列表中的版本依次做比较，判断待测试终端的版本列表中是否存在比待测试终端的系统版本高的版本，即新系统版本。本申请实施例对特定规则不作限定。

新系统版本的数量可以为一个，也可以为多个，本申请实施例对此不作限定。

若待测试终端的版本列表中存在新系统版本，则测试设备可以执行S904，若待测试终端的版本列表中不存在新系统版本，则测试设备可以执行S908。

S904、测试设备判断新系统版本是否为目标测试版本。

若新系统版本为目标测试版本，可以表示测试人员想要测试的系统版本高于待测试终端当前的系统版本，测试设备可以将待测试终端的系统版本更新为新系统版本。

测试设备可以通过版本号或者版本标识判断新系统版本是否为目标测试版本。

若测试设备判断新系统版本为目标测试版本，则测试设备可以执行S905，若测试设备判断新系统版本不为目标测试版本，则测试设备可以执行S908。

S905、测试设备进行测试。

测试设备进行测试，即测试设备向待测试终端发送测试指令，测试指令用于指示待测试终端执行目标测试用例，待测试终端向测试设备发送目标测试用例的测试结果，具体实现方式可以参考上述S304和S305，此处不再赘述。

S906、测试设备通过邮件推送匹配失败的信息。

具体地，测试设备可以向测试人员的邮箱发送邮件，该邮件可以包括匹配失败的信息，可以用于提示测试人员进行调整，使以正常测试。

S907、测试设备通过邮件推送查找新系统版本失败的信息。

具体地，测试设备可以向测试人员的邮箱发送邮件，该邮件可以包括查找新系统版本失败的信息，可以用于提示测试人员进行调整，使以正常测试。

S908、测试设备通过邮件推送查找目标测试版本失败的信息。

具体地，测试设备可以向测试人员的邮箱发送邮件，该邮件可以包括查找目标测试版本失败的信息，可以用于提示测试人员进行调整，使以正常测试。

本申请实施例提供的终端设备的测试方法，测试设备可以自动查找是否存在新系统版本，且在存在新系统版本的情况下，判断新系统版本是否为测试人员想要测试的版本，可以自动判断是否需要更新版本，有利于实现自动化测试。

作为一个可选的实施例，当目标测试用例的数量为多个时，上述S811可以包括：服务器保存测试结果和测试数据，并判断多个目标测试用例是否执行完成，在执行完成的情况下，生成测试报告。

示例性地，图10示出了一种服务器生成测试报告的方法1000的示意性流程图，如图10所示，该方法1000可以包括以下步骤：

S1001、服务器保存测试结果和测试数据。

服务器可以基于特定规则保存测试结果和测试数据，例如，服务器可以基于预设表格的格式，将测试结果和测试数据写入相应的表格中。本申请实施例对特定的规则不作限定。

S1002、服务器判断目标测试用例是否执行完成。

当目标测试用例的数量为多个时，服务器可以判断该多个目标测试用例是否执行完成，若存在未执行的测试用例，服务器可以继续接收测试结果和测试数据，即执行上述S1001，若不存在未执行的测试用例（即多个目标测试用例均执行完成），服务器可以执行S1003。

S1003、服务器基于测试结果和测试数据，生成测试报告。

具体实现方式可以参考上述S811，此处不再赘述。

本申请实施例提供的终端设备的测试方法，当目标测试用例的数量为多个时，服务器可以自动判断目标测试用例是否执行完成，并在执行完成的情况下，自动生成测试报告，减少了认为干预，可以提高测试效率，有利于实现自动化测试。

可选地，服务器生成测试报告之后，发送测试报告之前，还可以格式化测试报告。

示例性地，图11示出了一种格式化测试报告的方法的示意性流程图，如图11所示，服务器通过超文本标记语言（hyper text markup language，HTML）格式化测试报告，并通过简单邮件传输协议（simple mail transfer protocol，SMTP）发送包括测试报告的邮件。

测试格式化报告中可以包括每个目标测试用例执行的具体情况，可以用于分析待测试终端的性能和功能。

在上述方法中，测试设备可以为测试人员提供人机交互界面，该人机交互界面可以提供测试版本的输入框、测试用例的输入框。测试人员可以在测试版本的输入框输入目标测试版本，在测试用例的输入框输入目标测试用例，测试设备响应于测试人员的操作，可以执行上述方法300。本申请实施例将结合图12至图19介绍人机交互界面，该人机交互界面可以称为第一界面。

图12示出了第一界面的示意图。如图12所示，第一界面包括目标测试用例的信息区域401、待测试终端的信息区域402以及测试控件403，目标测试用例的信息区域401包括一个第一输入框4011，该第一输入框4011用于输入目标测试用例的编号，待测试终端的信息区域402包括三个第二输入框，该三个第二输入框分别为第二输入框4021、第二输入框4022以及第二输入框4023，第二输入框4021用于输入待测试终端的序列号，第二输入框4022用于输入待测试终端的端口号，第二输入框4023用于输入待测试终端的系统版本，测试控件403用于启动测试流程。

基于图12所示的界面，测试设备可以执行上述方法300、方法500以及方法700，除此之外，本申请实施例还提供一种终端设备的测试方法1300。

图13为本申请实施例提供的一种终端设备的测试方法1300的示意性流程图，该方法1300可以应用于上述图1所示的测试系统100，也可以应用于上述图2所示的测试系统200，本申请实施例对此不作限定。该方法1300中的测试设备，例如上述图1中的测试设备102，该方法1300中的待测试终端可以为任意终端设备，例如上述图1中的手机101，但本申请实施例对此不作限定。

如图13所示，该方法1300可以包括以下步骤：

S1301、显示第一界面，第一界面包括第一输入框、第二输入框以及测试控件，第一输入框用于输入目标测试用例的信息，第二输入框用于输入待测试终端的信息，目标测试用例的信息包括目标测试用例的编号，待测试终端的信息包括待测试终端的序列号和待测试终端的端口号。

第一输入框可以是一个，也可以是多个，本申请实施例对此不作限定。第一输入框用于输入目标测试用例的信息，故第一输入框的个数可以根据目标测试用例的信息的个数确定。

示例性地，目标测试用例的信息可以包括目标测试用例的编号，第一输入框的个数可以为一个，该一个输入框用于输入目标测试用例的编号。

目标测试用例的编号可以用于区分不同的测试用例。目标测试用例的编号可以与测试用例存在一一对应的关系，该一一对应的关系（即目标测试用例的编号与测试用例的对应关系）可以存在数据库中，以表格或文字的形式表示，应理解，本申请实施例应不限于此。目标测试用例的编号可以是字母、数字或者符号中的至少一个表示，本申请实施例对此不作限定。

第一输入框可以支持测试人员输入一个目标测试用例的编号，也可以支持测试人员输入多个目标测试用例的编号，本申请实施例不做限定。应理解，当第一输入框中包括多个目标测试用例的编号时，该多个目标测试用例的编号之间可以用分号或者逗号连接，但本申请实施例不限于此。

第二输入框可以是一个，也可以是多个，本申请实施例对此不作限定。第二输入框用于输入待测试终端的信息，故第二输入框的个数可以根据待测试终端的信息的个数确定。

示例性地，待测试终端的信息可以包括待测试终端的序列号和待测试终端的端口号，第二输入框的个数可以为两个，该两个输入框可以分别用于输入待测试终端的序列号和待测试终端的端口号。

可选地，待测试终端的信息还可以包括待测试终端的设备接口、产品配置名称以及可支持的仿真工具等信息。

可选地，待测试终端的信息还可以包括待测试终端的更新版本等信息。测试设备更新到测试设备的更新版本，还可以获取待测试终端的权限和可运行文件等信息。

可选地，第一界面还可以包括测试级别的输入框和计划任务的输入框，测试设备可以根据测试级别的输入框和计划任务的输入框获取测试级别和计划任务的数量等信息，测试级别可以包括需求测试、组件或单元测试、集成测试、系统测试、验收测试、Alpha测试、Beta测试以及用户验收测试（user acceptance test，UAT）测试。

本申请实施例对第一输入框、第二输入框以及测试控件在第一界面的位置和顺序不做限定。

可选地，第一输入框还可以包括筛选控件，该筛选控件用于从多个目标测试用例编号中筛选目标测试用例的编号。测试设备可以预设测试用例库，该测试用例库可以包括多个目标测试用例的编号，本申请实施例对该测试用例库中目标测试用例的编号的具体个数不做限定。当测试设备检测到测试人员点击第一输入框的筛选控件时，测试设备响应于该操作，显示多个目标测试用例编号，以供测试人员选择。

需要说明的是，在第一界面中，显示多个目标测试用例编号的区域（可以简称为“编号区域”）是固定的，当目标测试用例编号的数量较多时，会存在隐藏的目标测试用例编码，在编号区域的最右边可以显示滑动栏，同时滑动栏中可以显示滑动控件，以供测试人员拖动滑动控件以显示隐藏的目标测试用例编码。

示例性地，图14示出了筛选目标测试用例的示意图。如图14所示，在图14中a界面中，第一输入框4011包括筛选控件501，应理解，图14中的a界面所示的第一界面相比于上述图6中的第一界面还包括筛选控件501，其他相同，此处不再赘述。还应理解，图14所示的第一界面和图12所示的第一界面为第一界面的两种不同的实现方式。

测试人员可以通过鼠标操控箭头502点击筛选控件501，测试设备响应于测试人员点击筛选控件501的操作，可以显示编号区域，如图14中的b界面所示，在第一输入框4011的下方显示编号区域503，编号区域503包括滑动栏5031和滑动控件5032。编号区域显示的编号可以包括1000、1001、1002 、1011以及1100，当测试设备响应于测试人员向上拖动滑动控件5032时，可以显示隐藏的测试用例编号。

S1302、响应于用户在第一输入框的输入操作，确定目标测试用例的信息。

用户即测试人员可以在第一输入框中输入目标测试用例编号，测试设备响应于测试人员在第一输入框的输入操作，确定目标测试用例的信息，即目标测试用例编号。

测试设备可以根据目标测试用例的编号和目标测试用例的编号与测试用例的对应关系，调用目标测试用例的编号对应的测试用例。

S1303、响应于用户在第二输入框的输入操作，确定待测试终端的信息。

用户即测试人员可以在第二输入框中输入待测试终端的序列号和待测试终端的端口号，测试设备响应于测试人员在第一输入框的输入操作，确定目标测试用例的信息，即待测试终端的序列号和待测试终端的端口号。

第二输入框中的信息可以是测试人员手动填写的，也可以是测试设备主动获取后写入的，本申请实施例对比不做限定。

S1304、响应于用户点击测试控件的操作，启动待测试终端对目标测试用例的测试，并获得测试结果。

用户即测试人员可以点击测试控件，测试设备响应于测试人员的操作，启动待测试终端对目标测试用例的测试，并获得测试结果。其中，测试人员可以通过手指点击测试控件，也可以通过鼠标操控箭头点击测试控件，本申请实施例对此不做限定。

具体而言，测试设备可以向待测试终端发送测试指令，该测试指令可以用于指示待测试终端执行目标测试用例，对应地，待测试终端接收该测试指令，并在执行目标测试用例后，向测试设备发送目标测试用例的测试结果，对应地，测试设备接收目标测试用例的测试结果。

需要说明的是，若上述S1303中待测试终端的信息是测试人员手动填写的，测试设备在向待测试终端发送测试指令之前，需要先判断待测试终端的信息是否与S1303中获取的信息相同，若相同，执行S1304，若不同，则显示提示消息，用于提示测试人员待测试终端并不是目标待测试终端。

本申请实施例提供的终端设备的测试方法，测试人员在测试时，均可以通过第一界面输入目标测试用例的信息和待测试终端的信息进行测试，得到测试结果，测试结果不会因为测试人员的测试流程、测试习惯以及测试能力产生差异，可以适用于不同的测试人员，提高测试效率。

作为一个可选的实施例，第一界面还包括延时控件；在上述S1304、启动待测试终端对目标测试用例的测试之前，方法1300还包括：响应于用户点击延时控件的操作，显示第二界面，第二界面包括第三输入框，第三输入框用于输入延迟测试时间；响应于用户在第三输入框的输入操作，确定待测试终端对目标测试用例的延时测试时间；S1304、启动待测试终端对目标测试用例的测试，包括：响应于用户点击测试控件的操作，开启计时器；当计时器的时长等于延时测试时间时，启动待测试终端对目标测试用例的测试。

测试设备可以为测试人员提供延时测试的功能，故第一界面还可以包括延时控件。测试人员可以点击延时控件，测试设备响应于测试人员点击延时控件的操作，可以显示第二界面，第二界面可以包括第三输入框，第三输入框用于输入延迟测试时间。延迟测试时间可以是以分钟为单位，也可以是以小时为单位，还可以是以毫秒为单位，本申请实施例对此不做限定。

示例性地，图15示出了一种设置延时时间的示意图，如图15所示，图15中的a界面中，第一界面相比上述图12所示的第一界面还包括延时控件601，其他相同，此处不再赘述。应理解，图15所示的第一界面与上述图12和图14所示的第一界面为第一界面的不同实现方式。

测试人员可以通过鼠标操控箭头602点击延时控件601，测试设备响应于测试人员点击延时控件601的操作，可以显示第二界面603，如图15中的b界面所示。在图15中的b界面中，第二界面603可以包括第三输入框6031，第三输入框6031用于输入延迟测试时间。例如，延迟测试时间可以是30分钟。应理解，本申请实施例对延时控件在第一界面的具体位置不做限定。

应理解，箭头602和上述图14所示的箭头502可以相同，也可以不同，本申请实施例不做限定。

需要说明的是，第二界面可以包括关闭控件，也可以不包括关闭控件，本申请实施例对此不做限定。当第二界面包括关闭控件时，测试人员可以通过关闭控件关闭第二界面。当第二界面不包括关闭控件时，测试人员可以通过点击除第二界面之外的任意区域关闭第二界面。

应理解，上述图15仅仅为一种可能的实现方式，在另一种可能的实现方式中，上述第二界面的第三输入框可以显示在第一界面中，且是灰色的，表示不可输入，当检测到测试人员点击延时控件的操作，测试设备响应于测试人员点击延时控件的操作，可以使第三输入框正常显示，以便于测试人员输入延迟测试时间。

测试人员设置完成延迟测试时间后，可以点击测试控件启动测试流程，当测试设备检测到测试人员点击测试控件时，测试设备响应于测试人员点击测试控件的操作，开启计时器，计时器开始计时，当计时器的时长等于延时测试时间时，启动待测试终端对目标测试用例的测试。

本申请实施例提供的终端设备的测试方法，还可以为测试人员提供延时测试的功能，可以更加灵活的启动测试，有利于适用于更多的场景，满足用户的需求，提高用户的体验。

作为一个可选的实施例，第一界面还包括定时控件；在上述S1301、启动待测试终端对目标测试用例的测试之前，方法1300还包括：响应于用户点击定时控件的操作，显示第三界面，第三界面包括第四输入框，第四输入框用于输入定时测试时间；响应于用户在第四输入框的输入操作，确定待测试终端对目标测试用例的定时测试时间；S1301、启动待测试终端对目标测试用例的测试，包括：响应于用户点击测试控件的操作，判断定时测试时间是否到达；当定时测试时间到达时，启动待测试终端对目标测试用例的测试。

测试设备可以为测试人员提供定时测试的功能，故第一界面还可以包括定时控件。测试人员可以点击定时控件，测试设备响应于测试人员点击定时控件的操作，可以显示第三界面，第三界面可以包括第四输入框，第四输入框用于输入定时测试时间。定时测试时间可以是以分钟为单位，也可以是以小时为单位，还可以是以毫秒为单位，本申请实施例对此不做限定。

示例性地，图16示出了一种设置定时时间的示意图，如图16所示，图16中的a界面中，第一界面相比上述图12所示的第一界面还包括定时控件701，其他相同，此处不再赘述。应理解，图16所示的第一界面与上述图12、图14以及图15所示的第一界面为第一面的不同实现方式。

测试人员可以通过鼠标操控箭头702点击定时控件701，测试设备响应于测试人员点击定时控件701的操作，可以显示第三界面703，第三界面703可以包括第四输入框7031，第四输入框7031用于输入定时迟测试时间。例如，定时测试时间可以是下午3点。

应理解，箭头702和上述图15所示的箭头502、上述图15所示的箭头602可以相同，也可以不同，本申请实施例不做限定。

需要说明的是，第三界面可以包括关闭控件，也可以不包括关闭控件，本申请实施例对此不做限定。当第三界面包括关闭控件时，测试人员可以通过关闭控件关闭第三界面。当第三界面不包括关闭控件时，测试人员可以通过点击除第三界面之外的任意区域关闭第三界面。

应理解，上述图16仅仅为一种可能的实现方式，在另一种可能的实现方式中，上述第三界面的第四输入框可以显示在第一界面中，且是灰色的，表示不可输入，当检测到测试人员点击定时控件的操作时，测试设备响应于测试人员点击定时控件的操作，可以使第四输入框正常显示，以便于测试人员输入定时测试时间。

测试人员设置完成定时测试时间后，可以点击测试控件启动测试流程，当测试设备检测到测试人员点击测试控件时，测试设备响应于测试人员点击测试控件的操作，判断定时测试时间是否到达；当定时测试时间到达时，启动待测试终端对目标测试用例的测试。

需要说明的是，上述延时控件和定时控件可以同时显示在第一界面中，也可以分别单独显示在第一界面中，本申请实施例对此不作限定。同时，本申请实施例也不限定延时控件和定时控件在第一界面的位置以及两者之间的位置关系。

本申请实施例提供的终端设备的测试方法，可以为测试人员提供定时测试的功能，可以更加灵活的启动测试，有利于适用于更多的场景，满足用户的需求，提高用户的体验。

作为一个可选的实施例，第一界面还包括停止测试控件；上述方法1300还包括：响应于用户点击停止测试控件的操作，停止待测试终端对目标测试用例的测试。

第一界面还可以包括停止测试控件，测试人员可以通过点击停止测试控件停止对待测试终端的测试。测试设备响应于用户点击停止测试控件的操作，可以向待测试终端发送停止测试指令，该停止测试指令可以用于指示待测试终端停止执行目标测试用例，对应地，待测试终端接收该测试指令，停止执行目标测试用例。

示例性地，图17示出了另一种第一界面的示意图，如图17所示，图17的第一界面相比上述图12所示的第一界面还包括停止测试控件801，其他相同，此处不再赘述。应理解，图17所示的第一界面与上述图12、图14、图15以及图16所示的第一界面均为第一界面的不同的实现方式。

测试人员可以点击停止测试控件801，测试设备响应于测试人员点击停止测试控件801的操作，停止待测试终端对目标测试用例的测试。需要说明的是，本申请实施例对停止测试控件在第一界面的位置不做限定。

本申请实施例提供的终端设备的测试方法，可以为测试人员提供停止测试的功能，有利于测试人员更加灵活的进行测试，方便发生特殊情况时及时停止测试。

作为一个可选的实施例，上述方法1300还可以包括：响应于用户在第一输入框的更改信息操作，确定更改后的目标测试用例；响应于用户点击测试控件的操作，启动待测试终端对更改后的目标测试用例的测试，并获得新的测试结果。

用户即测试人员可以更改第一输入框的信息，应理解，这里更改指的是将原来的目标测试用例删除并重新输入信息，测试设备响应于用户在第一输入框的更改信息操作，可以确定更改后的目标测试用例。

测试人员更改目标测试用例后，可以点击测试控件，测试设备响应于测试人员点击测试控件的操作，可以向待测试终端发送新的测试指令，该新的测试指令可以用于指示待测试终端执行更改后的目标测试用例，对应地，待测试终端接收该新的测试指令，并在执行更改后的目标测试用例后，向测试设备发送更改后的目标测试用例的测试结果，对应地，测试设备接收该更改后的目标测试用例的测试结果，即新的测试结果。

本申请实施例提供的终端设备的测试方法，测试人员更改测试用例的信息，使用新的目标测试用例对待测试终端进行测试，有利于测试人员使用多个目标测试用例对待测试终端进行测试，有利于测试的更加全面。

可选地，测试人员也可以更改第二输入框的信息，测试设备响应于测试人员在第二输入框的更改信息操作，确定更改后的待测试终端信息；测试人员可以点击测试控件，测试设备响应于测试人员点击测试控件的操作，可以向更改后的待测试终端发送测试指令，该测试指令可以用于指示更改后的待测试终端执行目标测试用例，对应地，更改后的待测试终端接收该测试指令，并在执行目标测试用例后，向测试设备发送测试结果，即测试设备得到新的测试结果。

需要说明的是，测试人员可以同时更改第一输入框的信息和第二输入框的信息，也可以分别更改，本申请实施例对此不作限定。

可选地，第一界面还可以包括重新测试控件。重新测试控件可以是测试设备在出现某些情况时在第一界面显示的。本申请实施例对重新测试控件在第一界面的位置不做限定。

在一种可能的情况下，第一界面包括测试控件和停止测试控件，测试设备在测试过程中，测试人员点击停止测试控件，测试设备检测到测试人员点击停止测试控件之后，测试设备可以在第一界面上显示重新测试控件，测试人员可以通过点击该重新测试控件，重新开始测试。在另一种可能的情况下，当测试结果为失败的情况下，测试设备可以在第一界面显示重新测试控件，测试人员可以通过点击该重新测试控件，重新开始测试。

作为一个可选的实施例，第一界面还可以包括显示框，显示框用于显示测试结果。

显示框可以为一个，也可以为多个，本申请实施例对此不作限定。

测试结果可以为测试通过（pass）或者测试失败（fail）。

可选地，当目标测试用例的数量为多个时，测试设备可以对多个目标测试用例的结果进行总结，得到总结的测试结果。例如，总结的测试结果可以包括测试通过的目标测试用例数量、测试失败的目标测试用例数量、总目标测试用例的数量、测试完成的目标测试用例数量或者未测试目标测试用例的数量中的至少一个。

显示框可以用于显示测试通过或者测试失败，也可以显示测试通过的目标测试用例数量、测试失败的目标测试用例数量、总目标测试用例的数量、测试完成的目标测试用例数量或者未测试目标测试用例的数量。

当显示框用于显示测试通过或者测试失败，且显示框为一个时，显示框可以用于显示一个目标测试用例的测试结果，也可以显示多个目标测试用例的测试结果，本申请实施例对此不作限定。

示例性地，当显示框为一个、且目标测试用例为一个时，显示框显示该一个目标测试用例的测试结果，例如，pass。当显示框为一个、且目标测试用例为三个时，显示框可以依次显示三个目标测试用例的测试结果，例如pass、fail、pass。

当一个显示框显示一个目标测试用例的测试结果时，显示框的个数可以根据目标测试用例的个数确定。在该情况下，第一界面可以包括计划任务的输入框，测试人员可以在该输入框输入计划任务的数量，测试设备可以确定目标测试用例的个数，并在第一界面显示与目标测试用例的个数相等个数的显示框，用于分别显示目标测试用例的测试结果。

当显示框用于显示测试通过的目标测试用例数量、测试失败的目标测试用例数量、总目标测试用例的数量、测试完成的目标测试用例数量或者未测试目标测试用例的数量中的至少一个时，显示框可以为一个，也可以为多个。示例性地，第一界面包括一个显示框。目标测试用例为五个，该五个目标测试用例的测试结果可以分别为pass、fail、pass、pass以及fail。测试设备可以对测试结果进行总结，得到测试通过的目标测试用例的数量为3，测试失败（failed）的目标测试用例的数量为2，测试设备可以将passed：3；failed：2写入第一界面的显示框。

示例性地，第一界面可以包括测试通过对应的显示框和测试失败对应的显示框。目标测试用例为五个，该五个目标测试用例的测试结果可以分别为pass、fail、pass、pass以及fail。测试设备可以对测试结果进行总结，得到测试通过的目标测试用例的数量为3，测试失败（failed）的目标测试用例的数量为2，测试设备可以将3写入测试通过对应的显示框，将2写入测试失败对应的显示框。

可选地，当显示框为多个时，第一界面可以包括总目标测试用例对应的显示框、测试完成对应的显示框、未测试对应的显示框、测试通过对应的显示框以及测试失败对应的显示框，总目标测试用例对应的显示框用于显示目标测试用例的总数量，测试完成对应的显示框用于显示测试完成的目标待测试用例的数量，未测试对应的显示框用于显示未进行测试的目标待测试用例的数量，测试通过对应的显示框用于显示测试完成的目标待测试用例中测试通过的数量，测试失败对应的显示框用于显示测试完成的目标待测试用例中测试失败的数量。

示例性地，图18示出了第一界面的示意图，如图18所示，图18的第一界面相比上述图12所示的第一界面还包括测试结果的区域901，其他相同，此处不再赘述。应理解，图18所示的第一界面与上述图12、图14、图15、图16以及图17所示的第一界面均为第一界面的不同实现方式。

具体地，测试结果的区域901包括总目标测试用例对应的显示框9011、测试完成对应的显示框9012、未测试对应的显示框9013、测试通过对应的显示框9014以及测试失败对应的显示框9015。测试设备得到测试结果后，可以将目标测试用例的总数量写入总目标测试用例对应的显示框9011、将测试完成的目标待测试用例的数量写入测试完成对应的显示框9012、将未进行测试的目标待测试用例的数量写入未测试对应的显示框9013，将测试完成的目标待测试用例中测试通过的数量写入测试通过对应的显示框9014，将测试完成的目标待测试用例中测试失败的数量写入测试失败对应的显示框9015。需要说明的是，本申请实施例对测试结果区域中的显示框的位置以及显示框之间的相对位置不做限定。

本申请实施例提供的终端设备的测试方法，可以在第一界面上显示测试结果，可以使测试人员更直观的看到测试结果，节省测试人员查找测试结果的时间，提高测试效率。

作为一个可选的实施例，上述方法1300还包括：显示第四界面，并在第四界面中显示测试结果。

第四界面是区别于第一界面的另一界面，用于显示测试结果。

当目标测试用例为一个时，第四界面可以显示一个测试结果，测试结果为通过（pass）或者失败（fail）。

当目标测试用例为多个时，第四界面可以依次显示该多个目标测试用例的测试结果，例如：pass、fail、pass。

第四界面可以包括多个显示框，该多个显示框可以分别用于显示测试通过的数量、测试失败的数量、总目标测试用例的数量、测试完成的目标待测试用例的数量以及未进行测试的目标待测试用例的数量。该多个显示框在第四界面的位置和显示框之间的相对位置可以上述图18所示，此处不再赘述。

需要说明的是，第四界面可以包括关闭控件，也可以不包括关闭控件，本申请实施例对此不做限定。当第四界面包括关闭控件时，测试人员可以通过关闭控件关闭第四界面。当第四界面不包括关闭控件时，测试人员可以通过点击除第四界面之外的任意区域关闭第四界面。

本申请实施例提供的终端设备的测试方法，通过第四界面显示测试结果，可以使测试人员直观的看到测试结果，同时相比直接在第一界面上显示测试结果，可以节省第一界面的空间。

作为一个可选的实施例，第一界面包括关闭控件；上述方法1300还包括：响应于用户点击关闭控件的操作，关闭第一界面；保存目标测试用例的信息和待测试终端的信息。

第一界面包括关闭控件，当测试人员测试完成后，可以点击关闭控件以关闭第一界面。测试设备响应于用户点击关闭控件的操作，可以关闭第一界面，并保存目标测试用例的信息和待测试终端的信息，以使第一界面被再次打开时，可以在第一输入框中显示目标测试用例的信息，在第二输入框中显示待测试终端的信息，即测试设备可以记录关闭第一界面之前，最后一次测试的目标测试用例的信息和待测试终端的信息。

可选地，上述方法1300还包括：当测试人员再次打开第一界面时，测试设备响应于用户再次打开第一界面的操作，显示第一界面，第一界面的第一输入框显示有目标测试用例的信息，第一界面的第二输入框显示有待测试终端的信息。

本申请实施例提供的终端设备的测试方法，可以记录关闭第一界面之前，最后一次测试的目标测试用例的信息和待测试终端的信息，可以使测试人员了解关闭第一界面之前的测试进度，有利于后续测试的正常进行，避免了测试人员需要查看测试结果才能了解测试进度，提高了测试效率。

除上述列举的多种第一界面外，图19示出了另一种第一界面的示意图，该第一界面可以包括目标测试用例的信息区域401、待测试终端的信息区域402以及测试结果的区域901，同时，还包括测试控件403、延时控件602、定时控件701以及停止测试控件801。其中，目标测试用例的信息区域401可以包括第一输入框4011。该第一输入框4011用于输入目标测试用例的信息，待测试终端的信息区域402包括两个第二输入框，该两个第二输入框分别为第二输入框4021、第二输入框4022，第二输入框4021用于输入待测试终端的序列号，第二输入框4022用于输入待测试终端的端口号。测试结果的区域901包括总目标测试用例对应的显示框9011、测试完成对应的显示框9012、未测试对应的显示框9013、测试通过对应的显示框9014以及测试失败对应的显示框9015。其中，总目标测试用例对应的显示框9011用于输入目标测试用例的总数量、测试完成对应的显示框9012用于输入测试完成的目标待测试用例的数量、未测试对应的显示框9013用于输入未进行测试的目标待测试用例的数量，测试通过对应的显示框9014用于输入测试完成的目标待测试用例中测试通过的数量，测试失败对应的显示框9015用于输入测试完成的目标待测试用例中测试失败的数量。

上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

上文中结合图1至图19，详细描述了本申请实施例提供的终端设备的测试方法，下面将结合图20和图21，详细描述本申请实施例提供的终端设备的测试装置。

图20示出了本申请实施例提供的一种终端设备的测试装置2000，该装置2000包括：处理模块2010和收发模块2020。该处理模块2010用于：确定目标测试用例和目标测试版本；判断待测试终端的系统版本是否与目标测试版本相同；以及，确定目标测试版本对应的测试结果的存储路径；收发模块2020用于：在待测试终端的系统版本与目标测试版本相同的情况下，向待测试终端发送测试指令，测试指令用于指示待测试终端执行目标测试用例；以及，接收来自待测试终端对目标测试用例的测试结果；处理模块2010还用于：按照存储路径，存储待测试终端对目标测试用例的测试结果。

可选地，处理模块2010还用于：在系统版本与目标测试版本不相同的情况下，通过超文本传输协议HTTP访问版本库，版本库中包括多个版本和多个版本中每个版本的软件包；判断多个版本中是否存在目标测试版本；若多个版本中存在目标测试版本，则从版本库中获取目标测试版本的软件包；收发模块2020还用于：向待测试终端发送目标测试版本的软件包和版本更新指令，版本更新指令用于指示待测试终端按照目标测试版本的软件包将待测试终端的系统版本更新至目标测试版本；接收来自待测试终端的版本更新结果。

可选地，处理模块2010还用于：基于多个版本和多个存储路径之间的预设对应关系，确定目标测试版本对应的测试结果的存储路径。

可选地，当出现下列至少一种情况时，测试结果为测试失败：多个版本中不存在目标测试版本；待测试终端的版本更新结果表示待测试终端的系统版本更新失败；或者，测试结果表示对目标测试用例测试失败。

可选地，处理模块2010还用于：若测试结果为测试失败，统计测试结果为测试失败的次数；在测试失败的次数小于或等于预设阈值的情况下，重新启动目标测试用例的测试流程，直至出现新的测试结果为测试成功或者测试失败的次数大于预设阈值。

可选地，处理模块2010还用于：若出现新的测试结果为测试成功，则将测试结果更新为测试成功。

可选地，处理模块2010还用于：在测试失败的次数大于预设阈值的情况下，结束目标测试用例的测试流程；收发模块2020还用于：向目标测试用例对应的研发人员的设备发送测试结果。

可选地，收发模块2010还用于：向服务器发送测试结果对应的测试数据，测试数据包括目标测试用例在测试过程中的日志信息和/或截图信息。

应理解，这里的装置2000以功能模块的形式体现。这里的术语“模块”可以指应用特有集成电路（application specific integrated circuit，ASIC）、电子电路、用于执行一个或多个软件或固件程序的处理器（例如共享处理器、专有处理器或组处理器等）和存储器、合并逻辑电路和/或其它支持所描述的功能的合适组件。在一个可选的例子中，本领域技术人员可以理解，装置2000可以具体为上述方法实施例中的测试设备，或者，上述方法实施例中测试设备的功能可以集成在装置2000中，装置2000可以用于执行上述方法实施例中与测试设备对应的各个流程和/或步骤，为避免重复，在此不再赘述。

上述装置2000具有实现上述方法实施例中的测试设备执行的相应步骤的功能；上述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

在本申请的实施例中，图20中的装置2000也可以是芯片或者芯片系统，例如：片上系统（system on chip，SoC）。

图21是本申请实施例提供的另一种终端设备的测试装置2100的示意性框图。该装置2100包括处理器2110、收发器2120和存储器2130。其中，处理器2110、收发器2120和存储器2130通过内部连接通路互相通信，该存储器2130用于存储指令，该处理器2120用于执行该存储器2130存储的指令，以控制该收发器2120发送信号和/或接收信号。

应理解，装置2100可以具体为上述方法实施例中的测试设备，或者，上述方法实施例中测试设备的功能可以集成在装置2100中，装置2100可以用于执行上述方法实施例中与测试设备对应的各个步骤和/或流程。可选地，该存储器2130可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。存储器的一部分还可以包括非易失性随机存取存储器。例如，存储器还可以存储设备类型的信息。该处理器2110可以用于执行存储器中存储的指令，并且该处理器执行该指令时，该处理器可以执行上述方法实施例中与测试设备对应的各个步骤和/或流程。

应理解，在本申请实施例中，该处理器2110可以是中央处理单元（centralprocessing unit，CPU），该处理器还可以是其他通用处理器、数字信号处理器（DSP）、专用集成电路（ASIC）、现场可编程门阵列（FPGA）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器执行存储器中的指令，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。

本申请还提供了一种计算机可读存储介质，该计算机可读存储介质用于存储计算机程序，该计算机程序用于实现上述方法实施例中测试设备对应的方法。

本申请还提供了一种芯片系统，该芯片系统用于支持上述方法实施例中测试设备实现本申请实施例所示的功能。

本申请还提供了一种计算机程序产品，该计算机程序产品包括计算机程序（也可以称为代码，或指令），当该计算机程序在计算机上运行时，该计算机可以执行上述方法实施例所示的测试设备对应的方法。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的模块及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（read-only memory，ROM）、随机存取存储器（random access memory，RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请实施例的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请实施例揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请实施例的保护范围之内。因此，本申请实施例的保护范围应所述以权利要求的保护范围为准。

Claims (18)

1.一种终端设备的测试方法，其特征在于，包括：

确定目标测试用例和目标测试版本；

判断待测试终端的系统版本是否与所述目标测试版本相同；

确定所述目标测试版本对应的测试结果的存储路径；

在所述待测试终端的系统版本与所述目标测试版本相同的情况下，向所述待测试终端发送测试指令，所述测试指令用于指示所述待测试终端执行所述目标测试用例；

接收来自所述待测试终端对所述目标测试用例的测试结果；

按照所述存储路径，存储所述待测试终端对所述目标测试用例的测试结果。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述系统版本与所述目标测试版本不相同的情况下，通过超文本传输协议HTTP访问版本库，所述版本库中包括多个版本和所述多个版本中每个版本的软件包；

判断所述多个版本中是否存在所述目标测试版本；

若所述多个版本中存在所述目标测试版本，则从所述版本库中获取所述目标测试版本的软件包；

向所述待测试终端发送所述目标测试版本的软件包和版本更新指令，所述版本更新指令用于指示所述待测试终端按照所述目标测试版本的软件包将所述待测试终端的系统版本更新至所述目标测试版本；

接收来自所述待测试终端的版本更新结果。

3.根据权利要求2所述的方法，其特征在于，所述确定所述目标测试版本对应的测试结果的存储路径，包括：

基于所述多个版本和多个存储路径之间的预设对应关系，确定所述目标测试版本对应的测试结果的存储路径。

4.根据权利要求2或3所述的方法，其特征在于，当出现下列至少一种情况时，所述测试结果为测试失败：

所述多个版本中不存在所述目标测试版本；

所述待测试终端的版本更新结果表示所述待测试终端的系统版本更新失败；或者，

所述测试结果表示对所述目标测试用例测试失败。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若所述测试结果为测试失败，统计所述测试结果为测试失败的次数；

在所述测试失败的次数小于或等于预设阈值的情况下，重新启动所述目标测试用例的测试流程，直至出现新的测试结果为测试成功或者所述测试失败的次数大于所述预设阈值。

6.根据权利要求5所述的方法，其特征在于，在所述重新启动所述目标测试用例的测试流程之后，所述方法还包括：

若出现新的测试结果为测试成功，则将所述测试结果更新为测试成功。

7.根据权利要求5或6所述的方法，其特征在于，所述方法还包括：

在所述测试失败的次数大于所述预设阈值的情况下，结束所述目标测试用例的测试流程，并向所述目标测试用例对应的研发人员的设备发送所述测试结果。

8.根据权利要求1所述的方法，其特征在于，所述存储路径为服务器中的文件路径；

所述方法还包括：

向所述服务器发送所述测试结果对应的测试数据，所述测试数据包括所述目标测试用例在测试过程中的日志信息和/或截图信息。

9.一种终端设备的测试装置，其特征在于，包括：

处理模块，用于确定目标测试用例和目标测试版本；判断待测试终端的系统版本是否与所述目标测试版本相同；以及，确定所述目标测试版本对应的测试结果的存储路径；

收发模块，用于在所述待测试终端的系统版本与所述目标测试版本相同的情况下，向所述待测试终端发送测试指令，所述测试指令用于指示所述待测试终端执行所述目标测试用例；以及，接收来自所述待测试终端对所述目标测试用例的测试结果；

所述处理模块还用于：按照所述存储路径，存储所述待测试终端对所述目标测试用例的测试结果。

10.根据权利要求9所述的测试装置，其特征在于，所述处理模块还用于：

在所述系统版本与所述目标测试版本不相同的情况下，通过超文本传输协议HTTP访问版本库，所述版本库中包括多个版本和所述多个版本中每个版本的软件包；

判断所述多个版本中是否存在所述目标测试版本；

若所述多个版本中存在所述目标测试版本，则从所述版本库中获取所述目标测试版本的软件包；

所述收发模块还用于：

向所述待测试终端发送所述目标测试版本的软件包和版本更新指令，所述版本更新指令用于指示所述待测试终端按照所述目标测试版本的软件包将所述待测试终端的系统版本更新至所述目标测试版本；

接收来自所述待测试终端的版本更新结果。

11.根据权利要求10所述的测试装置，其特征在于，所述处理模块还用于：

基于所述多个版本和多个存储路径之间的预设对应关系，确定所述目标测试版本对应的测试结果的存储路径。

12.根据权利要求10或11所述的测试装置，其特征在于，当出现下列至少一种情况时，所述测试结果为测试失败：

所述多个版本中不存在所述目标测试版本；

所述待测试终端的版本更新结果表示所述待测试终端的系统版本更新失败；或者，

所述测试结果表示对所述目标测试用例测试失败。

13.根据权利要求9所述的测试装置，其特征在于，所述处理模块还用于：

若所述测试结果为测试失败，统计所述测试结果为测试失败的次数；

在所述测试失败的次数小于或等于预设阈值的情况下，重新启动所述目标测试用例的测试流程，直至出现新的测试结果为测试成功或者所述测试失败的次数大于所述预设阈值。

14.根据权利要求13所述的测试装置，其特征在于，所述处理模块还用于：

若出现新的测试结果为测试成功，则将所述测试结果更新为测试成功。

15.根据权利要求13或14所述的测试装置，其特征在于，所述处理模块还用于：

在所述测试失败的次数大于所述预设阈值的情况下，结束所述目标测试用例的测试流程；

所述收发模块还用于：

向所述目标测试用例对应的研发人员的设备发送所述测试结果。

16.根据权利要求9所述的测试装置，其特征在于，所述收发模块还用于：

向所述服务器发送所述测试结果对应的测试数据，所述测试数据包括所述目标测试用例在测试过程中的日志信息和/或截图信息。

17.一种终端设备的测试装置，其特征在于，包括处理器和存储器，所述存储器用于存储代码指令，所述处理器用于运行所述代码指令，以执行如权利要求1至8中任一项所述的方法。

18.一种计算机可读存储介质，其特征在于，用于存储计算机程序，所述计算机程序包括用于实现如权利要求1至8中任一项所述的方法的指令。

Images