CN109032624A - 一种基于烧录系统的测试方法及其装置 - Google Patents

Abstract

本发明公开了一种基于烧录系统的测试方法及其装置，烧录系统包括服务器、客户端以及烧录器；该方法包括：调用并运行预设客户端测试脚本，控制客户端执行烧录过程中的各项操作，测试客户端的执行结果，生成客户端测试结果并显示；调用并运行预设服务器测试脚本，控制服务器执行烧录过程中的各项操作，测试服务器的执行结果，生成服务器测试结果并显示。本发明能够自动调用相应的测试脚本进行测试，并保存测试结果，工作人员的工作量小，测试效率高。

Description

一种基于烧录系统的测试方法及其装置

技术领域

本发明涉及设备烧录技术领域，特别是涉及一种基于烧录系统的测试方法及其装置。

背景技术

随着云技术的发展，越来越多的设备需要与云平台连接来实现云服务的应用，在设备连接云平台时，云平台需要验证该设备是否为合法设备，而判定是否为合法设备的依据即为该设备上是否烧录有真实的ID号，在此条件下，设备想要连接云平台的话则均需要进行ID号的烧录。

目前的设备烧录方式是将烧录器与客户端连接，将待烧录设备放置于烧录器内，之后在客户端内手动输入待烧录的ID号，后台服务器用于对客户端进行管理。而目前在设备烧录前，想要进行测试的话，一般是手动控制客户端执行各项操作，来查看客户端的反应，从而确定是否存在故障，这种人工测试的方式效率低，工作量大。

因此，如何提供一种效率高的基于烧录系统的测试方法及其装置是本领域技术人员目前需要解决的问题。

发明内容

本发明的目的是提供一种基于烧录系统的测试方法及其装置，能够自动调用相应的测试脚本进行测试，并保存测试结果，工作人员的工作量小，测试效率高。

为解决上述技术问题，本发明提供了一种基于烧录系统的测试方法，所述烧录系统包括服务器、客户端以及烧录器；所述方法包括：

调用并运行预设客户端测试脚本，控制所述客户端执行烧录过程中的各项操作，测试所述客户端的执行结果，生成客户端测试结果并显示；

调用并运行预设服务器测试脚本，控制所述服务器执行烧录过程中的各项操作，测试所述服务器的执行结果，生成服务器测试结果并显示。

优选地，还包括：

调用并运行批量导入脚本，在所述服务器内导入多个身份编码，测试导入效果，得到导入测试结果并显示。

优选地，所述测试导入效果的具体过程包括：

测试导入多个身份编码时所述服务器是否出现不稳定状态；

测试导入多个身份编码的导入速度和总体导入时间；

测试导入重复身份编码时，所述服务器内是否能够过滤重复身份编码。

优选地，所述控制所述客户端执行烧录过程中的各项操作，测试所述客户端的执行结果的过程具体包括：

控制所述客户端发送相应请求至所述服务器，并控制所述服务器不回应，测试所述客户端是否显示请求失败及失败原因。

优选地，所述相应请求包括身份编码获取请求、烧录器身份标识查询请求以及烧录结果中的任一种。

优选地，所述控制所述客户端执行烧录过程中的各项操作，测试所述客户端的执行结果的过程还包括：

控制所述客户端发送身份标识查询请求至所述烧录器，并控制所述烧录器不回应，测试所述客户端是否显示请求失败及失败原因。

优选地，所述控制所述服务器执行烧录过程中的各项操作，测试所述服务器的执行结果的过程具体包括：

控制所述服务器发送身份编码至所述客户端后，测试所述服务器是否将所发送的身份编码的状态修改为烧录中；

控制所述客户端发送烧录成功的烧录结果至所述服务器后，测试所述服务器是否设置所述烧录结果对应的身份编码的状态为已烧录；

控制所述客户端发送烧录失败的烧录结果至所述服务器后，测试所述服务器是否设置所述烧录结果对应的身份编码的状态为未烧录。

优选地，所述控制所述服务器执行烧录过程中的各项操作，测试所述服务器的执行结果的过程还包括：

控制所述服务器发送身份编码至所述客户端，并控制所述客户端不发送烧录结果，测试所述服务器在超过预设时间未接收到所述烧录结果时是否设置对应的身份编码的状态为未烧录。

优选地，还包括：

启动多个客户端并发请求所述服务器进行烧录操作，测试所述服务器是否稳定以及所述服务器的运行速度。

为解决上述技术问题，本发明还提供了一种烧录系统的测试装置，所述烧录系统包括服务器、客户端以及烧录器；所述装置包括：

客户端测试模块，用于调用并运行预设客户端测试脚本，控制所述客户端执行烧录过程中的各项操作，生成客户端测试结果并显示；

服务器测试模块，用于调用并运行预设服务器测试脚本，控制所述服务器执行烧录过程中的各项操作，生成服务器测试结果并显示。

本发明提供了一种基于烧录系统的测试方法及其装置，烧录系统包括服务器、客户端以及烧录器；本发明预先设置好用于对客户端及服务器进行测试的脚本，在测试过程中，直接调用预设客户端测试脚本以及预设服务器测试脚本，即可控制客户端以及服务器进行相应的操作，并能够根据客户端以及服务器的执行结果，自动生成测试结果。可见，本发明相比手动控制客户端和服务器执行各项操作的方式，大大减小了工作人员的工作量，减少了测试时间，提高了测试效率。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对现有技术和实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明提供的一种烧录系统的结构示意图；

图2为本发明提供的一种基于烧录系统服务器的烧录管理方法的过程的流程图；

图3为本发明提供的一种基于烧录系统服务器的并行烧录管理方法的过程的流程图；

图4为本发明提供的另一种基于烧录系统服务器的烧录管理方法的过程的流程图；

图5为本发明提供的一种基于烧录系统服务器的信息管理方法的过程的流程图；

图6为本发明提供的一种基于烧录系统客户端的烧录管理方法的过程的流程图；

图7为本发明提供的一种烧录系统的测试方法的过程的流程图；

图8为本发明提供的一种烧录系统的测试装置的结构示意图。

具体实施方式

本发明的核心是提供一种基于烧录系统的测试方法及其装置，能够自动调用相应的测试脚本进行测试，并保存测试结果，工作人员的工作量小，测试效率高。

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明提供了一种烧录系统包括服务器、客户端以及烧录器。参见图1所示，图1为本发明提供的一种烧录系统的结构示意图。

其中，烧录器20是用于对设备进行烧录的装置，将待烧录设备10放置进烧录器20后，由烧录器20将身份编码烧录至待烧录设备10内以及显示烧录结果。

客户端30两端分别连接烧录器20和服务器40，客户端30是用于在连接烧录器20后，发送烧录请求至服务器40来获取身份编码，之后将服务器40返回的身份编码发送至烧录器20，由烧录器20烧录至待烧录设备10内。

服务器40作为烧录系统的后端，其内部存储有控制整个烧录过程的固件以及若干个身份编码，服务器40用于对其存储的身份编码进行管理，具体管理过程包括在接收到客户端30发送的烧录请求后，选择未烧录的身份编码发送至客户端30。

服务器40包括：

存储器402，用于存储计算机程序；

处理器401，用于执行计算机程序时实现以下任一种烧录管理方法的步骤。

基于该烧录系统，在大量设备待烧录时，工作人员不需要一个一个人为输入身份编号至客户端30，而是可由客户端30自动从服务器40内获取预存的未烧录的身份编码，不仅减小了工作量，且尽可能避免了人为输入时的误差，提高了设备烧录的准确性和效率。

基于上述烧录系统，本发明提供的烧录管理方法如下。

参见图2所示，图2为本发明提供的一种基于烧录系统服务器的烧录管理方法的过程的流程图。该方法包括步骤s101至步骤s104。

步骤s101：将用于控制烧录过程的烧录固件保存至服务器40的固件数据库内。

可以理解的是，为了控制整个烧录过程，需要预先设置烧录固件，烧录固件内保存有用于控制烧录过程的程序。

步骤s102：将待烧录的若干个身份编码依次保存至服务器40的身份数据库内。

将待烧录的身份编码预先保存至身份数据库，是为了使后续烧录过程中，接收客户端30请求后，可以直接调用，而不再需要工作人员每次都人工输入，从而提高了后续烧录过程的效率。

并且，统一将身份编码进行保存的话，能够方便工作人员对身份编码进行统一查验，减小了身份编码漏存的可能。

步骤s103：接收客户端30发送的烧录请求后，运行烧录固件。

只有运行了烧录固件，烧录程序才会启动，服务器40才会进行后续动作。而客户端30只有连接烧录器20，且烧录器20上连接待烧录设备10后，客户端30才会发送烧录请求至服务器40。

步骤s104：调用相应的身份编码发送至客户端30，供客户端30将身份编码发送至烧录器20进行设备烧录。

客户端30与烧录器20相连，烧录器20上连接有待烧录设备10，烧录器20接收到客户端30返回的身份编码后，会将身份编码烧录至自身连接的待烧录设备10上。

其中，客户端30可以设置为：检测到所连接的烧录器20放置有待烧录设备10后即自动发送烧录请求至服务器40，或者也可设置为用户触发后发送烧录请求，本发明对此不做限定。

在另一具体实施例中，也可在服务器40上设置“创建任务”以及“上传身份编码”两个按钮，在需要进行烧录时，由用户触发两个按钮来生成相应的指令，从而触发烧录流程。其具体过程为：用户需要烧录身份编码，则首先需要点击“上传身份编码”，则服务器40会响应于该点击指令后在服务器40内创建身份数据库来保存用户上传的若干个身份编码内容，之后用户再点击“创建任务”，并设置所需烧录的身份编码的数量，并在固件类型中选择“不烧录固件”。当然，若想要烧录身份编码时，服务器40内已经存在有身份数据库了，则可直接点击“创建任务”而不再需要进行身份编码上传操作。另外，在部分情况中，用户可能需要将服务器40内保存的固件烧录至设备内，此时即进行固件烧录，则可点击“创建任务”，并在固件类型中选择“烧录固件”，则服务器40会响应于该点击指令后将服务器40内保存的固件通过客户端30发送至烧录器20进行烧录。

可以理解的是，由于身份编码可能包含很多个类型，为了方便管理，优选将不同类型的身份编码分别保存至不同的数据池中。

这种情况下，在一种优选实施例中，在客户端30发送烧录请求至服务器40时，服务器40可首先选择某一类型的数据池，并在接收烧录请求后，始终从所选择的这一个数据池中取身份编码，直至该数据池内身份编码全部烧录完成后，服务器40再选择另一类型的数据池，或者等待上传新的身份编码。

在该实施例中，由于同一类型的数据池中的全部身份编码是连续进行烧录的，因此其烧录时间是依次进行排序的，这种情况下，在服务器40对每个身份编码的烧录详情进行记录后，工作人员进行记录查询时，能够更方便的得知各个数据池内的整体烧录情况，以及每个数据池内各个身份编码的烧录情况，更加方便工作人员进行管理。

作为优选地，待烧录的若干个身份编码在身份数据库内以列表形式存储。

可以理解的是，由于每个身份编码独立存在，因此采用列表形式，每个表格内保存一个身份编码的话，不仅方便身份编码的调用，且方便对身份编码进行排序、筛选和查找。当然，在其他实施例中，也可以其他文件进行存储身份编码，例如文本形式，本发明对此不作特别限定。

另外，在保存身份编码时，为了方便统计，可设置身份编码统计表，用于统计身份编码的总数以及未烧录的个数。并且由于身份编码也存在多种类型，因此，在进行上述统计时还可以按照身份编码的类型分别进行统计。举例来说，若身份编码为ID号，ID号的类型包括mac、id2、fogid、sds、aws、IOT套件、飞燕ID等，则以表1为例，表1为一种具体实施例中的身份编码统计表：

表1 一种具体实施例中的身份编码统计表

统计	mac	id2	fogid	sds	aws	IOT套件	飞燕ID
								总数	0	0	4	50	0	0	0
剩余数	0	0	0	50	0	0	0

当然，以上仅为一种具体的实施例，本发明不限定身份编码的具体类型以及身份编码统计表的具体格式。

进一步的，在优选实施例中，还可以在服务器40内设置的身份编码统计表上设置分别对应于每种身份编码的导出按钮，在待烧录设备10存在身边编码类型要求时，可由工作人员通过触发对应的导出按钮，来控制服务器40发送对应类型的未烧录的身份编码至客户端30，供烧录器20进行烧录。例如，若待烧录设备10要求仅烧录sds类型的身份编码，则此时工作人员可触发sds类型对应的导出按钮，之后服务器40响应于用户触发，会选择一个sds类型的未烧录的身份编码发送至客户端30。通过这种方式，可方便工作人员在客户存在特殊需求时，人为控制服务器40所发送的身份编码。

并且，由于在实际应用中，可能出现客户端30故障导致烧录器20、客户端30与服务器40之间通信出现问题，进而使得服务器40内某些身份编码无法确定是否烧录成功，在本发明的优选实施例中，这种情况下，会令服务器40暂停这些身份编码的发送，服务器40下次接收到烧录请求后，会跳过这些身份编码发送其他未烧录的身份编码，为了避免这些身份编码的浪费，本发明可在工作人员确认这些身份编码的烧录情况后，通过上述提到的导出按钮，人为的将其中未烧录的身份编码发送至客户端30内，从而避免了身份编码的漏烧，减小了成本浪费。

作为优选地，该方法还包括：

周期性地将已烧录的身份编码转存至烧录完成数据库内。

可以理解的是，在身份数据库内的身份编码数量很大的情况下，每次从身份数据库中选择身份编码时均需要大量的查找筛选工作，影响烧录速度，而周期性地将已烧录的身份编码转存至烧录完成数据库后，会尽可能避免身份数据库内的身份编码数量过多，从而一定程度上减短身份编码的筛选时间。

本发明提供了一种基于烧录系统服务器的烧录管理方法，服务器在自身数据库内保存用于控制烧录过程的固件以及多个待烧录的身份编码后，一旦接收到的客户端的烧录请求，则选择一个未烧录的身份编码发送至客户端，由客户端将其发送至烧录器进行烧录。可见，本发明只要将身份编码保存至服务器之后，服务器即可根据客户端的请求自动选择身份编码发送至客户端，进而对该身份编码进行烧录，而不再需要工作人员每次手动在客户端内输入待烧录的身份编码，降低了工作人员的工作量，提高了工作效率；并且，相比人工的方式，服务器选择身份编码发送的方式，尽可能减少了身份编码输入错误的情况以及漏掉ID号的情况，提高了设备烧录的准确性，尽可能减少了客户的损失。

在存在大量的待烧录设备10时，若采用一台烧录完成再烧录另一台设备的方式的话，则会使烧录过程持续时间过长，为了提高烧录效率，本发明提供了一种基于烧录系统服务器40的并行烧录方法，即多台客户端30均连接服务器40，每台客户端30连接有数量不定的烧录器20，从而减少整体烧录时间。参见图3所示，图3为本发明提供的一种基于烧录系统服务器的并行烧录管理方法的过程的流程图；在该方法包括：

步骤s103的过程具体为：

步骤s103A：依次接收各个客户端30发送的烧录请求，并运行烧录固件；

并行烧录过程中，通常服务器40连接有多个服务器40。

步骤s104的过程具体为：

步骤s104A：依据接收烧录请求的先后顺序，从身份数据库内依次调用相应的未烧录的身份编码发送至各个客户端30；供客户端30将相应的身份编码发送至烧录器20内进行设备烧录。

可以理解的是，若服务器40同时采用多个进程并行处理客户端30的烧录请求的话，可能会出现服务器40同时选择同一个身份编码发送至客户端30的情况，使多个待烧录设备10上烧录同一个身份编码，即重烧的情况，影响烧录的可靠性。因此，需要依次调用未烧录的身份编码发送至各个客户端30。

进一步可知，烧录请求请求内包含客户端30对接的烧录器20个数；相应的，接收烧录请求后，从身份数据库内调用与烧录器20个数相同数量的未烧录的身份编码发送至客户端30。

可以理解的是，在本实施例中，为了进一步增加并行烧录的烧录器20个数，允许每个客户端30上连接多个烧录器20，即客户端30上的烧录器20也为并行烧录，这种设置方式能够在保证多个烧录器20并行烧录的同时，尽可能减少客户端30的数量，从而降低烧录系统的整体成本。

不过，由于客户端30内存大小以及接口设置的限制，客户端30不能无限制的增加自身连接的烧录器20的个数，每个客户端30连接的烧录器20的个数需要不超过自身承载上限，且各个客户端30连接的烧录器20的个数可以相同也可以不同，本发明不限制各个客户端30连接的烧录器20的个数。

在进行设备烧录时，每个身份编码均需要客户出钱购买，因此，若出现漏烧(有身份编码没有烧录至设备内)以及重烧(同一身份编码烧录至多个设备内)的情况，则不仅会造成客户的损失，而且会导致烧录完成的设备也无法正常登陆云平台。

为了防止重烧漏烧的情况，基于以上各个实施例，本发明还提供了一种具体实施例，所述身份编码对应有编号状态，所述编号状态包括未烧录、烧录中和已烧录。参见图4所示，图4为本发明提供的另一种基于烧录系统服务器的烧录管理方法的过程的流程图；

该实施例中，选择未烧录的身份编码发送至客户端30后，还包括：

步骤s105：在自身数据库内，将调用的身份编码的状态修改为烧录中；

步骤s106：接收烧录器20通过客户端30返回的烧录结果；

步骤s107：若烧录结果为烧录成功，则依据烧录结果内携带的身份编码，将自身数据库内的相应身份编码的状态修改为已烧录；若烧录结果为烧录失败，则依据烧录结果内携带的身份编码，将自身数据库内的相应身份编码的状态修改为未烧录。其中，烧录结果内携带所烧录的身份编码。

其中，在将身份编码保存至服务器40内时，各个身份编码的初始状态均为未烧录。发送至客户端30的身份编码必须是未烧录过的，因为每个设备与身份编码应该是唯一对应的，不能烧录其他设备烧录过的身份编码。故通过在身份编码上设置未烧录状态，能够尽可能避免同一身份号烧录至多个设备的重烧情况。

另外，在烧录过程中，将对应的身份编码的状态改为烧录中，以及在烧录成功后，将烧录成功的身份编码的状态改为已烧录，是为了在后续再次接收到烧录请求后，服务器40仅会从未烧录状态的身份编码内选择，而不会再选择状态为烧录中或已烧录的身份编码发送至客户端30，从而尽可能避免了多个设备烧录同一身份编码的重烧情况。

而在烧录失败时，将烧录失败的身份编码的状态改回未烧录，是由于该身份编码既然烧录失败，则表明该身份编码并未被烧录至设备内，即实质上并未被使用，因此，为了避免身份编码漏烧，造成客户损失，此时需要将其状态改回未烧录，方便后续再次使用该身份编码发送至客户端30进行烧录。

另外，在上述并行方法的基础上，在一种优选实施例中，接收客户端30发送的烧录请求后，选择未烧录的身份编码发送至客户端30之前，本发明还包括：

步骤s1031：判断当前处于烧录中的身份编码的个数，若该个数超出预设的并行上限，直接返回暂停烧录的响应至当前发送烧录请求的客户端30，并暂停调用未烧录的身份编码。

可以理解的是，由于服务器40的内存大小和进程等资源限制，不可能无限的调用身份编码发送至客户端30，若当前处于烧录中的身份编码过多，可能会导致服务器40运行缓慢，导致无法及时依据烧录结果进行更新，甚至会导致烧录状态修改错误。因此，本实施例设置了一个并行上限，一旦当前处于烧录中的身份编码的个数超出并行上限，则暂停服务器40调用身份编码的服务，从而减小服务器40的负载压力，保证服务器40运行的可靠性。

在一具体实施例中，选择未烧录的身份编码发送至客户端30后，将所选择的身份编码的状态修改为烧录中之前，还包括：

调用未烧录的身份编码发送至客户端30后，等待客户端30返回的接收响应；

若在预设时间段内接收到客户端30返回的接收响应，则将调用的未烧录的身份编码的状态由未烧录修改为烧录中；接收响应内包括调用的未烧录的身份编码以及客户端30接收成功或接收失败的状态标识。

可以理解的是，发送身份编码至客户端30后，等待客户端30的接收响应，是为了确认客户端30是否成功接收到该身份编码，若此时客户端30未返回接收响应，则表明此时客户端30存在故障(例如客户端30崩溃)，此时客户端30很可能并未成功接收到身份编码并将其发送至烧录器20，因此，为了避免身份编码浪费，此时对应的身份编码的状态仍旧保持为未烧录，客户端30返回接收识别的响应时也是同理。只有客户端30返回接收成功的响应后，服务器40才将对应身份编码的状态修改为烧录中，从而减少避免漏烧的情况出现，减小客户损失。

作为优选地，步骤s105还包括：在发送身份编码至客户端30后启动计时器计时；

步骤s107还包括：若预设时间后未接收到客户端30返回的烧录结果，则将自身数据库内的身份编码的状态修改为未烧录。

可以理解的是，烧录器20烧录所需的时间一般是固定的，即使略有浮动，也不会差别过大，而若客户端30正常的话，则从服务器40发送身份编码至客户端30到客户端30返回烧录结果所需的时间一般不会超出预设时间，若超时未接收到客户端30返回的烧录结果的话，则表明此时很可能是烧录器20烧录故障，烧录已经失败，因此，为避免对应身份编码一直处于烧录中导致的漏烧，需要将对应的身份编码修改为未烧录，方便后续再次使用该身份编码进行烧录，减少客户损失。

但是在部分情况下，服务器40超时未接收到客户端30返回的烧录结果，可能并不是因为烧录器20故障，而是因此客户端30故障，导致烧录器20返回的烧录结果无法传输至服务器40，而实际上已经烧录成功了，这种情况下若直接将对应的身份编码改为未烧录的话，则会出现将同一身份编码烧录至两个设备内的情况。

为了避免上述重烧情况的发生，进一步的，该方法还包括：

在超过预设时间未接收到烧录结果而将身份编码的状态修改为未烧录后，检测客户端30此时是否处于故障状态，若是，则将身份编码的状态修改为暂停，后续接收到烧录请求后，选择其他未烧录的身份编码发送至客户端30。

可以理解的是，将身份编码的状态修改为暂停，指的是暂时不对该身份编码进行处理，即不会将其发送至客户端30，也不会修改其当前状态，因为，若超时未接收到烧录结果时客户端30处于故障状态，则该超时很可能时由于客户端30的问题，而烧录器20烧录可能已经成功了，但是，由于暂时无法判断超时是由于客户端30引起的还是烧录器20引起的，故暂停对该身份编码的使用，后续由工作人员查看对应设备的烧录情况后，人为修改该身份编码的状态，从而能够避免客户端30故障引起超时的情况下，身份编码改为未烧录后的重烧情况，提高了烧录的可靠性。

作为优选地，步骤s107之后还包括：

接收烧录结果并完成身份编码的状态修改后，返回完成响应至客户端30；

供客户端30接收完成响应后，发送显示指令至烧录器20；控制烧录器20显示烧录结果。

可以理解的是，若烧录器20一旦完成烧录即显示烧录结果的话，工作人员看到烧录器20显示烧录成功，则很可能会在烧录器20上立即更换新的待烧录设备10，若此时某种原因(例如客户端30崩溃或数据延迟)导致服务器40超时未接收到烧录结果的话，服务器40会将更换前烧录成功的那个设备所对应的身份编码恢复为未烧录状态，而此时实际上该身份编码已经烧录成功，这样就可能出现同一身份编码烧录至多个设备的情况，即导致重烧，而出现重烧的设备很可能无法正常登入云平台，给客户带来极大损失。因此，本实施例中，在烧录完成后烧录器20暂时不显示烧录结果，而是先发送烧录结果至服务器40进行状态修改，服务器40完成状态修改后，客户端30才发送显示指令至烧录器20，再由烧录器20进行烧录结果显示，此时，工作人员看到烧录结果，才会进行设备更换，从而尽可能避免由于设备更换过早导致的重烧的情况。

在一种优选实施例中，在保存身份编码时，为了方便查看各个身份编码的烧录情况，可采用表格的形式来统计各个身份编码的内容、类型以及烧录情况，以下表为例，表2为一种具体的身份编码详情表：

表2 一种具体的身份编码详情表

Id号内容	ID号类型	ID名称	ID状态	烧录时间	所属任务
						87AQRbOcC/Ag	fogid	fogid	已烧录	2018-7-4 15:10:20	Fog-4
88AQRbOcC/Ag	fogid	fogid	烧录中	None	Fog-4
						Mt9K3RepdpYj	sds	sds	未烧录	None	none

当然，以上仅为一种具体实施例，身边编码详情表内还可包含其他有关身份编码的内容信息，身份编码详情表的格式设定本发明不作具体限定。

可以理解的是，通过上述身份编码详情表，工作人员即能够直观方便的了解到服务器40内保存的各个身份编码的当前状态以及烧录情况，不仅方便后续进行烧录统计和分析，也方便对各个身份编码进行管理和查询。

另外，由于服务器40内存储的身份编码的个数可能很多，因此，可能导致一个身份编码详情表会非常长，这样不仅不利于身份编码详情表的保存，也不利于工作人员的查看，因此可根据身份编码的类型、烧录状态或者烧录时间等来对身份编码详情表进行分表，即分为多个表来保存各个身份编码的详情信息。举例来说，可将不同类型的身份编码分别保存至不同的身份编码详情表内，也可创建对应于不同烧录状态的身份编码详情表，一旦身份编码的状态发生变化(例如由未烧录变为烧录中)，则将该身边编码移至烧录中的身份编码详情表内进行保存。当然，具体以哪种分类方式对身份编码详情表进行分类，本发明不作具体限定。

另外，采用表格的形式保存身份编码的详情信息仅是一种优选方案，在其他实施例中也可采用其他的文件形式来对身份编码的详情信息进行保存。

并且，本发明上述提到的身份编码统计表以及身份编码详情表均保存在服务器40内，通常保存与服务器40的身份数据库内。

在实际烧录时，由于往往需要对大量的设备进行烧录，为了对这些数据进行管理，通常需要记录每个设备的烧录结果及其烧录的身份编码，来方便后续进行追溯，而目前通常采用的人为记录的方式效率低且准确性差。对此，本发明提供了一种信息管理方法。参见图5所示，图5为本发明提供的一种基于烧录系统服务器的信息管理方法的过程的流程图。

该实施例中，若烧录成功，烧录结果还包括其对应设备的身份标识。

本发明还提供了一种基于烧录系统服务器的信息管理方法，除前述步骤s101～107之外，还包括：

步骤s108：接收到烧录成功的烧录结果之后，将所述服务器40内保存的、所述烧录结果内对应的身份编码与所述烧录结果包含的身份标识进行绑定。

可以理解的是，通过将设备的身份标识与其所烧录成功的身份编码进行绑定，后续用户可以通过输入服务器40内保持的设备的身份标识来查询相应设备的烧录记录，烧录记录的追溯性更强，且相比人工管理的方式，信息管理的效率更高，且错误率低。

其中，该绑定操作通常设置在服务器40返回完成响应至客户端30之前，即绑定完成后，再发送完成响应至客户端30。

由于需要将烧录完成后的身份编码与对应的设备的身份标识进行绑定，因此，这里的绑定通常指的是将该身份标识添加至对应的身份编码的详情信息中。例如，若身份编码的详情信息是以表格形式体现的话，则具体实现的方式可采用如下实现方式，表3为另一种具体的身份编码详情表：

表3 一种具体的身份编码详情表

在一种优选实施例中，接收所述客户端30发送的烧录请求之前还包括：

步骤s1021：接收所述客户端30获取所述烧录器20的身份标识后发送的查询指令，所述查询指令内携带有所述烧录器20返回的身份标识；

步骤s1022：查询自身数据库内是否包含与所述身份标识绑定的身份编码，若存在，返回存在响应至所述客户端30，供所述客户端30控制此次烧录结束，若不存在，返回不存在响应至所述客户端30，供所述客户端30发送烧录请求至所述服务器40。

在其他实施例中，客户端30获取烧录器20的身份标识的时，也可以同时获取烧录器20上烧录的身份编码，并将获取的身份标识和身份编码发送至服务器40查询，当然，具体采用以上哪种实现方式，本发明不作限定。

可以理解的是，通过前述各种实施例，本发明能够很容易的确认身份编码的烧录状态，但是仍无法确认当前待烧录设备10内是否已经烧录有身份编码，在某些情况下，工作人员可能会误将已经烧录过的设备再次进行烧录，而若是在同一设备内烧录多个身份编码的话(这也属于一种身份编码漏烧的情况)，不仅会造成身份编码的浪费，而且会导致烧录有多个身份编码的设备无法正常登陆云平台，造成客户损失。例如，在前述部分实施例中，烧录器20会等待客户端30返回显示指令后再显示烧录结果，若烧录器20烧录成功且服务器40完成状态修改后，但是客户端30崩溃，则烧录器20长时间等待不到客户端30返回的显示指令后，工作人员可能会认为此次烧录失败，并重新对该设备进行烧录，但实际上，该设备已经完成了烧录，故会对该设备进行重复烧录，导致身份编码的漏烧，造成身份编码浪费。

而本实施例中，每次烧录完成后，会将烧录成功的设备的身份标识与其所烧路的身份编码进行绑定保存，这样使得服务器40内就保存了各个成功烧录的设备的烧录记录，因此，只需要每次烧录前，客户端30查询当前待烧录的设备的身份标识是否已经存储至服务器40内，即可确认该设备是否已经烧录完成，从而避免了同一设备内烧录多个身份编码的情况，减少身份编码的浪费，提高烧录的可靠性。

在另一实施例中，烧录成功时，烧录结果内除包含所烧录的设备的身份标识外，还包括此次烧录的烧录信息。其中，这里的烧录信息可以包括身份编码类别、烧录时间、烧录器20类型、烧录设备类型中的任一几种的组合以及烧录成功的状态信息(方便工作人员区分该条烧录记录是烧录成功记录还是烧录失败记录)，另外，也可以包括烧录对应的设备类型以及烧录器20和客户端30的相关信息，烧录信息是用于方便工作人员了解烧录情况的，烧录信息的内容可自行设定，本发明对此不作限定。因此，客户端30发送携带有烧录信息的烧录结果至服务器40后，服务器40在执行步骤s108的操作之后，还包括：保存所述烧录结果中的身份编码及其绑定的身份标识以及所述烧录结果内的烧录信息，得到烧录记录。可以理解的是，保存得到烧录记录的意思是将该烧录结果内的、身份编码、身份标识以及烧录信息整合到一起，共同保存为一条烧录记录，使得根据此条烧录记录即可得知本次烧录的全部情况，从而方便后续工作人员利用这些烧录记录进行数据追溯，进而进行烧录统计和分析。

进一步的，该方法还包括：

依据所述烧录结果，若烧录失败，保存所述烧录结果对应的身份编码、烧录信息以及烧录失败的状态信息，得到烧录记录。

可以理解的是，虽然烧录失败后，本次烧录的身份编码优选会恢复为未烧录状态，但是，本次烧录失败的烧录信息(例如烧录失败的设备的身份标识等)仍能够为后续工作人员对设备的管理提供证据，因此，在烧录失败时，记录烧录失败的相关信息，能够进一步提高整个烧录系统的数据追溯性，方便用户对历史烧录记录进行追溯。

具体的，上述身份标识为MAC地址。当然，这里的身份标识用于唯一表征设备身份，只要能够具有上述功能的标识均可作为设备的身份标识，本发明不限定身份标识的具体类型。

进一步可知，该方法还包括：

接收查询指令后，依据所述查询指令携带的查询条件查询相应的烧录记录，查询完成后，对查询结果进行显示。其中，这里的查询条件包括身份编码或设备的身份标识，因为身份编码与设备的身份标识均对应特定的一条或几条烧录记录，或者查询条件也可以为时间区间范围，来查询该时间范围内的全部烧录记录。当然，查询条件还可以为其他内容，本发明不限定查询条件的具体内容。

在优选实施例中，可直接在前述提到的身份编码详情表上设置查询窗口，用于供用于用于在该窗口内输入相应的查询条件来进行身份编码信息查询。并且为了提醒用户，查询窗口内可显示有待输入的查询条件的类型。例如，查询窗口内可显示有“输入MAC地址”的内容，从而方便用户了解查询身份编码时需要输入哪种查询条件，用户便利性更高。

当然，其他实施例中，也可不在身份编码详情表上设置查询窗口，而是可以由用户输入服务器40默认的查询指令来实现，或者也可在服务器40的其他位置设置设置查询窗口，并将查询窗口与服务器40的身份数据库进行链接。具体采用哪种方式来实现上述查询操作，本发明并不做具体限定。

进一步可知，上述对查询结果进行显示具体为：将查询结果导出为表格进行显示。

可以理解的是，由于查询结果内包含多条信息，将这些信息以表格形式显示的话，更为直观，也方便用户查阅。当然，也可以文本形式显示，本发明不限定具体的显示方式。

在烧录过程中，需要将客户端30与烧录器20连接，但是由于目前不同客户端30内存在的烧录程序不同，客户端30包含的用于控制烧录器20执行各项操作的控制接口也存在差异，工作人员使用时需要花费时间来熟悉和学习相应的烧录方法，烧录整体过程复杂。而本发明提供了一种封装有统一的控制接口(API接口)的客户端30以及相应的实施例。

在本实施例中，客户端30内封装有烧录器20驱动，烧录器20驱动内包括用于控制客户端30在烧录过程中动作的API接口，API接口包括开启烧录器接口、开启待烧录设备接口、写入接口、关闭待烧录设备接口以及关闭烧录器接口。本实施例应用于烧录系统中的客户端30，参见图6所示，图6为本发明提供的一种基于烧录系统客户端的烧录管理方法的过程的流程图。该实施例的烧录管理方法包括步骤s201至步骤s207。详细描述如下。

步骤s201：调用开启烧录器接口控制烧录器20开启；开启烧录器接口init，用于打开烧录器20，负责打开串口等，是执行所有烧录器20命令的前提条件。

步骤s202：调用开启待烧录设备接口控制烧录器20上连接的待烧录设备10连接上电；开启待烧录设备接口open，用于打开模组，负责检查模组上电，连接模组等，是烧录的前提条件。

放置待烧录设备10的方式是将待烧录设备10放置于烧录器20的相应位置后，压下夹具固定带烧录设备。之后工作时，烧录器20首先要开启上电，之后检测烧录器20上是否设置了待烧录设备10，然后才能建立烧录器20与待烧录设备10的连接，之后才能进行烧录。

步骤s203：发送烧录请求至服务器40。

步骤s204：接收服务器40返回的未烧录的身份编码后发送至烧录器20。

步骤s205：调用写入接口，控制烧录器20将接收到的未烧录的身份编码烧录至待烧录设备10内；写入接口write，用于负责配置参数，写入数据等。

步骤s206：调用关闭待烧录设备接口控制烧录器20上连接的待烧录设备10断开；关闭待烧录设备接口close，用于关闭模组，负责检查模组断电，断开模组等，是开始下次open的前提条件。

步骤s207：调用关闭烧录器接口控制烧录器20关闭。关闭烧录器接口fini，用于关闭烧录器20，负责关闭串口等。

在烧录完毕后，需要首先断开待烧录设备10与烧录器20之间的连接，方便工作人员打开夹具，拿下待烧录设备10，之后再关闭烧录器20。但是，若需要连续对多个设备进行烧录时，可以在待烧录设备10断开连接后，直接替换下一个待烧录设备10，而不需要关闭烧录器20，之后，直接返回步骤s202，并重复后续操作，直至不再需要烧录时，再关闭烧录器20。

在该实施例的基础上，客户端30烧录结果后的处理过程为：接收烧录器20返回的烧录结果并发送至服务器40；接收到服务器40返回的完成响应后，调用写入接口发送显示指令至烧录器20，控制烧录器20显示烧录结果。由于烧录器20时用于对烧录结果进行显示，需要将烧录结果写入显示组件内，因此可调用写入接口来控制实现这部分操作。或者，在其他实施例中，也可在客户端30内增加显示接口，用于控制烧录器20对烧录结果进行显示。具体采用哪种方式，本发明不作具体限定。

基于前述实施例，若客户端30发送烧录请求至服务器40之前，需要读取烧录器20的身份标识，则客户端30内的API接口还包括读取接口；相应的，此时客户端30的具体操作为：

调用读取接口，读取烧录器20当前连接的待烧录设备10的身份标识；读取接口read，用于负责获取参数，读取数据等；将身份标识发送至服务器40进行查询，确定服务器40内是否包含与身份标识绑定的身份编码；若接收到服务器40返回的存在响应，则显示该设备已烧录的信息；若接收到服务器40返回的不存在响应，则发送烧录请求至服务器40。

可以理解的是，读取接口时用于供客户端30从烧录器20内获取相应信息的接口，在其他情况下，若客户端30存在其他数据获取需求，也可通过读取接口来实现。

在Python实现中，把烧录器20抽象为一个类programmer，此类有open,write,read和close方法，构造函数是init，析构函数是fini。这样就实现了不同烧录器20的统一接口。

具体的，以上各个接口的详细定义可以为：

prog.open()

参数：无

返回：成功 True，失败 False

prog.close()

参数：无

返回：成功 True，失败 False

prog.write(name,data)

参数：name 数据类型，如FogID,SDS和ID2等

data 数据

返回：实际写的字节数

例如：prog.write(‘fogid’,‘AAQAAAAAAARanlQDAgEAAwEA’)

prog.read(name,size)

参数：name 数据类型，如FogID,SDS和ID2等

size 长度

返回：实际读的字节数

例如：mac＝prog.read(‘mac’,6)

当然，以上仅为一种实现方式，本发明不限定各个接口的具体定义方式。

具体的，客户端30与烧录器20之间可以采用线缆连接，连接接口可以采用SPI(Serial Peripheral Interface，串行外设接口)、UART(Universal AsynchronousReceiver/Transmitter，通用异步收发接口)、JTAG(Joint Test Action Group，联合测试工作组接口)中的任一种，或者客户端30与烧录器20之间也可采用无线通信连接，本发明不限定客户端30与烧录器20间的连接方式。

在其他情况下，可能出现所需要烧录至设备的内容并未存储与服务器40中，而是存储与外部存储部件内，此时，需要令该外部存储部件与客户端30连接，之后在控制待烧录设备10连接完毕后，检测客户端30是否存储与其连接的外部存储部件，且是否存储需要烧录至待烧录设备10内的数据，若存在，则客户端30需要读取外部存储部件内的该部分数据，并调用写入接口将这部分数据烧录至待烧录设备10内。

在烧录系统进行工作之前，往往需要对烧录系统进行测试，而目前的测试方式，一般是手动控制客户端30执行各项操作，来查看客户端30的反应，从而确定是否存在故障，这种人工测试的方式效率低，工作量大。为提高测试效率，本发明提供了一种烧录系统测试方法，参见图7所示，图7为本发明提供的一种烧录系统的测试方法的过程的流程图。该测试方法包括步骤s301和步骤s302。详细描述如下。

步骤s301：调用并运行预设客户端30测试脚本，控制所述客户端30执行烧录过程中的各项操作，测试所述客户端30的执行结果，生成客户端30测试结果并显示。

步骤s302：调用并运行预设服务器40测试脚本，控制所述服务器40执行烧录过程中的各项操作，测试所述服务器40的执行结果，生成服务器40测试结果并显示。

可以理解的是，烧录系统中的多数信号传输的操作是由客户端30以及服务器40完成的，因此，主要测试对象即为客户端30以及服务器40。

该方法中，预先设置好用于对客户端30及服务器40进行测试的脚本，在测试过程中，直接调用预设客户端30测试脚本以及预设服务器40测试脚本，即可控制客户端30以及服务器40进行相应的操作，并能够根据客户端30以及服务器40的执行结果，自动生成测试结果。可见，本发明相比手动控制客户端30和服务器40执行各项操作的方式，大大减小了工作人员的工作量，减少了测试时间，提高了测试效率。

作为优选地，该测试方法还包括：调用并运行批量导入脚本，在服务器40内导入多个身份编码，测试导入效果，得到导入测试结果并显示。例如，导入100万个ID，重复测试10次等。可以理解的是，本发明的烧录系统在工作之前，需要在服务器40内导入大量的身份编码，因此，需要首先测试服务器40的导入性能，确定其稳定性和导入速度。当然，本发明不限定每次测试时导入的身份编码的个数。

进一步可知，测试导入效果的具体过程包括：测试导入多个身份编码时服务器40是否出现不稳定状态；这里的不稳定状态包括是否出现进程卡死、服务器40宕机等；测试导入多个身份编码的导入速度和总体导入时间；该导入速度和时间与服务器40的内存大小以及CPU的运行速度有关，该导入速度和时间能够指导工作人员确定合适的身份编码批量导入的数量；测试导入重复身份编码时，服务器40内是否能够过滤重复身份编码。

需要注意的是，服务器40本身具有去重的功能，但是需要测试其是否能够准确的过滤全部重复的身份编码，是否会出现过滤错误的情况，因此，一旦服务器40内保存了重复的身份编码的话，则可能会导致不同设备内烧录进相同的身份编码，进而使得这些设备可能无法登录云平台，导致客户损失，因此，能否过滤重复身份编码是很重要的测试项。

在一具体实施例中，步骤s301中，控制客户端30执行烧录过程中的各项操作，测试客户端30的执行结果的过程具体包括：控制客户端30发送相应请求至服务器40，并控制服务器40不回应，测试客户端30是否显示请求失败及失败原因。

可以理解的是，在烧录过程中，客户端30会与服务器40进行许多信息交互，通常来讲，客户端30发送请求至服务器40后，服务器40会返回相应的响应，这些返回的响应可能仅是告知客户端30自身已收到相关请求，也可能是包含有客户端30所请求的数据，但不论哪种响应，一旦客户端30在接收不到服务器40响应时，客户端30应该显示请求失败并显示原因，若客户端30未显示，则表明客户端30也存在故障。而若不显示请求失败，则用户无法及时得知此时出现了故障，进而及时进行相应的处理。

当然，在其他实施例中，客户端30在未接收到服务器40回应时，也可能仅显示请求失败，而不显示失败原因，这与客户端30的设置有关，本发明对此不作限定。

进一步可知，上述相应请求包括身份编码获取请求、烧录器20身份标识查询请求以及烧录结果中的任一种。

其中，身份编码获取请求即指的是前述实施例中所提的烧录请求；烧录器20身份标识查询请求指的是：在服务器40将身份编码与设备的身份标识进行绑定的情况下，客户端30发送烧录请求之前，向服务器40发送的、用于查询当前待烧录设备10是否已烧录的查询指令。

在另一实施例中，步骤s301中，控制客户端30执行烧录过程中的各项操作，测试客户端30的执行结果的过程还包括：

控制客户端30发送身份标识查询请求至烧录器20，并控制烧录器20不回应，测试客户端30是否显示请求失败及失败原因。

由于客户端30想要查询待烧录设备10是否已烧录时，需要首先从烧录器20获取待烧录设备10的身份标识，因此，客户端30需要首先向烧录器20发送身份标识查询请求，即此时客户端30与烧录器20之间存在信号交互，故此时需要检测客户端30能否在未接收到烧录器20回应时，显示请求失败及失败原因。因为，若不显示请求失败，则用户无法及时得知此时出现了故障，进而及时进行相应的处理。当然，在其他实施例中，也可不显示失败原因，本发明对此不作限定。

在另一实施例中，步骤s302中，控制服务器40执行烧录过程中的各项操作，测试服务器40的执行结果的过程具体包括：控制服务器40发送身份编码至客户端30后，测试服务器40是否将所发送的身份编码的状态修改为烧录中；控制客户端30发送烧录成功的烧录结果至服务器40后，测试服务器40是否设置烧录结果对应的身份编码的状态为已烧录；控制客户端30发送烧录失败的烧录结果至服务器40后，测试服务器40是否设置烧录结果对应的身份编码的状态为未烧录。

可以理解的是，在服务器40内的身份编码存在未烧录、烧录中、已烧录三种状态的情况下，则需要检测服务器40能否根据当前该身份编码的烧录状态对身份编码的状态进行相应的改变。由于实际应用中，若服务器40未及时改变身份编码的状态，则可能会出现将同一身份编码发送至多个设备的情况，或者出现漏烧身份编码的情况，给客户带来较大损失，因此，需要对此进行测试。

在另一实施例中，步骤s302中，控制服务器40执行烧录过程中的各项操作，测试服务器40的执行结果的过程还包括：控制服务器40发送身份编码至客户端30，并控制客户端30不发送烧录结果，测试服务器40在超过预设时间未接收到烧录结果时是否设置对应的身份编码的状态为未烧录。

在前述实施例中，包含有服务器40在超时的情况下将身份编码改为未烧录的情况，该情况是为了避免烧录器20故障时，身份编码浪费的情况，因此，需要检测服务器40在此种情况下能够进行身份编码状态的修改。

作为优选地，该方法还包括：启动多个客户端30并发请求服务器40进行烧录操作，测试服务器40是否稳定以及服务器40的运行速度。在支持多个客户端30并发烧录时，需要测试服务器40能否正常运行及其运行速度，因此，若服务器40不能稳定运行，或者运行速度过慢的话，则可能是由于并行的客户端30过多，需要调整客户端30的并行数量。

在一种具体实施例中，身份编码内包括身份号以及排序编号；待烧录的若干个身份编码在身份数据库内按照自身携带的排序编号的顺序依次保存。

可以理解的是，由于身份编码数量可能很多，若随机存储于身份数据库内的话，不仅不便于工作人员进行管理和查验，并且服务器40在某些情况下需要进行身份编码筛选查找时(例如后续查找某一个身份编码信息时)，乱序的身份编码也会影响服务器40的筛选和查找速度，影响服务器40效率。

其中，上述身份号具体为ID号。当然，这里的身份号用于作为设备的唯一表征，只要其能够作为烧录的对象，且烧录后能够被云平台识别即可，本发明不限定身份号的具体类型。

需要注意的是，由于在进行烧录时，仅需要身份号，而不需要身份编码内的其他数据，因此，在身份编码包含除身份号以外的其他内容时，以上各个实施例中所述的身份编码仅指的是身份号，即仅将身份号发送至客户端30即可，烧录结果内包含的也是身份号。当然，若身份编码仅包含有身份号的话，则发送身份号即为发送身份编码。

作为优选地，将待烧录的身份编码保存至服务器40之前还包括：

查询身份数据库内是否保存有与当前待保存的身份编码内身份号相同的身份编码，若存在，则放弃存储当前待保存的身份编码，若不存在，将当前待保存的身份编码保存至身份数据库内。

可以理解的是，为了避免身份号的重烧，需要保证服务器40内保持的身份编码不存在重复，因此，需要在将待烧录的身份编码保存至服务器40之前，对其进行去重操作。当然，在其他实施例中，也可以采用先保存至服务器40，再进行过滤重复的操作，具体采用哪种去重方式，本发明不作具体限定。

需要注意的是，本发明提供的以上各个具体实施方式仅是本发明的优选实施方式，以上几种具体实施例可以任意组合，组合后得到的实施例也在本发明的保护范围之内。应当指出，对于本技术领域的普通技术人员来说，相关专业技术人员在不脱离本发明精神和构思前提下推演出的其他改进和变化，均应包含在本发明的保护范围之内。

本发明还提供了一种烧录系统的测试装置。参见图8所示，图8为本发明提供的一种烧录系统的测试装置的结构示意图。该装置包括：

客户端测试模块1，用于调用并运行预设客户端测试脚本，控制客户端执行烧录过程中的各项操作，生成客户端测试结果并显示；

服务器测试模块2，用于调用并运行预设服务器测试脚本，控制服务器执行烧录过程中的各项操作，生成服务器测试结果并显示。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其他实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种基于烧录系统的测试方法，其特征在于，所述烧录系统包括服务器、客户端以及烧录器；所述方法包括：

调用并运行预设客户端测试脚本，控制所述客户端执行烧录过程中的各项操作，测试所述客户端的执行结果，生成客户端测试结果并显示；

调用并运行预设服务器测试脚本，控制所述服务器执行烧录过程中的各项操作，测试所述服务器的执行结果，生成服务器测试结果并显示。

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

调用并运行批量导入脚本，在所述服务器内导入多个身份编码，测试导入效果，得到导入测试结果并显示。

3.根据权利要求2所述的测试方法，其特征在于，所述测试导入效果的具体过程包括：

测试导入多个身份编码时所述服务器是否出现不稳定状态；

测试导入多个身份编码的导入速度和总体导入时间；

测试导入重复身份编码时，所述服务器内是否能够过滤重复身份编码。

4.根据权利要求1所述的测试方法，其特征在于，所述控制所述客户端执行烧录过程中的各项操作，测试所述客户端的执行结果的过程具体包括：

控制所述客户端发送相应请求至所述服务器，并控制所述服务器不回应，测试所述客户端是否显示请求失败及失败原因。

5.根据权利要求4所述的测试方法，其特征在于，所述相应请求包括身份编码获取请求、烧录器身份标识查询请求以及烧录结果中的任一种。

6.根据权利要求5所述的测试方法，其特征在于，所述控制所述客户端执行烧录过程中的各项操作，测试所述客户端的执行结果的过程还包括：

控制所述客户端发送身份标识查询请求至所述烧录器，并控制所述烧录器不回应，测试所述客户端是否显示请求失败及失败原因。

7.根据权利要求1所述的测试方法，其特征在于，所述控制所述服务器执行烧录过程中的各项操作，测试所述服务器的执行结果的过程具体包括：

控制所述服务器发送身份编码至所述客户端后，测试所述服务器是否将所发送的身份编码的状态修改为烧录中；

控制所述客户端发送烧录成功的烧录结果至所述服务器后，测试所述服务器是否设置所述烧录结果对应的身份编码的状态为已烧录；

控制所述客户端发送烧录失败的烧录结果至所述服务器后，测试所述服务器是否设置所述烧录结果对应的身份编码的状态为未烧录。

8.根据权利要求7所述的测试方法，其特征在于，所述控制所述服务器执行烧录过程中的各项操作，测试所述服务器的执行结果的过程还包括：

控制所述服务器发送身份编码至所述客户端，并控制所述客户端不发送烧录结果，测试所述服务器在超过预设时间未接收到所述烧录结果时是否设置对应的身份编码的状态为未烧录。

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

启动多个客户端并发请求所述服务器进行烧录操作，测试所述服务器是否稳定以及所述服务器的运行速度。

10.一种烧录系统的测试装置，其特征在于，所述烧录系统包括服务器、客户端以及烧录器；所述装置包括：

客户端测试模块，用于调用并运行预设客户端测试脚本，控制所述客户端执行烧录过程中的各项操作，生成客户端测试结果并显示；

服务器测试模块，用于调用并运行预设服务器测试脚本，控制所述服务器执行烧录过程中的各项操作，生成服务器测试结果并显示。