植入仿真器的自动化测试系统及SSD硬盘测试方法

摘要

本发明涉及一种植入仿真器的自动化测试系统及SSD硬盘测试方法，该系统包括部署在同一台测试主机上的客户端和服务端；客户端上部署有第一中间件，第一中间件用于在对SSD设备进行第二阶段的测试场景中接收测试管理系统发送来的第一测试用例，生成对应的测试指令，若需要调用的驱动程序为仿真驱动程序，则将测试指令发送给仿真驱动程序；仿真驱动程序将测试指令发送给仿真器；服务端上部署有仿真器和共享内存，仿真器通过软件模拟SSD设备，根据测试指令和共享内存中的测试数据对软件模拟的SSD设备进行测试，在测试完成后依次通过仿真驱动程序和第一中间件反馈至测试管理系统。本发明消除了软硬件调用不一致导致的天然“应用孤岛”现象。

权利要求

1.一种植入仿真器的自动化测试系统，其特征在于，所述系统包括部署在同一台测试主机上的客户端和服务端；其中：所述客户端上部署有第一中间件，所述第一中间件中封装有仿真驱动程序；所述第一中间件用于：在对SSD设备进行第二阶段的测试场景中，接收测试管理系统发送来的第一测试用例，根据所述第一测试用例生成对应的测试指令，确定需要调用的驱动程序，若需要调用的驱动程序为所述仿真驱动程序，则将所述测试指令发送给所述仿真驱动程序；所述仿真驱动程序用于将所述测试指令通过socket协议发送给仿真器；

所述服务端上部署有所述仿真器和共享内存，所述仿真器用于：通过软件模拟SSD设备，在接收到所述测试指令后，根据所述测试指令和所述共享内存中的测试数据对软件模拟的SSD设备进行测试，并在测试完成后依次通过所述仿真驱动程序和所述第一中间件反馈至所述测试管理系统；

其中，所述第二阶段位于第一阶段和第三阶段之间，所述第一阶段为对SSD设备进行设计之前进行测试的阶段，所述第三阶段为对SSD设备的设计完成之后进行测试的阶段。

2.根据权利要求1所述的系统，其特征在于，所述客户端上还部署有仿真驱动测试程序，所述服务端上还部署有专家数据库；其中：所述仿真驱动测试程序用于：在对所述仿真驱动程序进行测试的场景中，接收所述测试管理系统发送来的第二测试用例，将所述第二测试用例提交给所述专家数据库，接收所述专家数据库反馈回来的测试业务代码段，将所述测试业务代码段提交给所述仿真驱动程序，以使所述仿真驱动程序执行所述测试业务代码段，实现对所述仿真驱动程序的测试；

所述专家数据库用于：接收所述仿真驱动测试程序发送来的第二测试用例，根据所述第二测试用例确定适用于所述仿真驱动程序执行的测试业务代码段，并将所述测试业务代码段反馈至所述仿真驱动测试程序；

其中，在对所述仿真驱动程序进行测试的场景中，所述仿真驱动程序设置在所述仿真驱动测试程序中，在对所述仿真驱动程序测试通过后，根据所述仿真驱动程序形成所述第一中间件。

3.根据权利要求1所述的系统，其特征在于，所述服务端中还部署有仿真服务程序，所述仿真服务程序用于：管理第一共享数据，并将所述第一共享数据存储至所述共享内存中；

所述第一共享数据用于在所述客户端和所述服务端为Windows系统的场景下进行测试所采用的测试数据，所述第一中间件为Windows系统下的第一中间件。

4.根据权利要求1所述的系统，其特征在于，所述服务端中还部署有仿真服务程序，所述仿真服务程序用于：管理第二共享数据，并将所述第二共享数据存储至所述共享内存中；

所述第二共享数据用于在所述客户端和所述服务端为不同的操作系统的场景下进行测试采用的测试数据；

其中，所述客户端运行于WLS2系统上，WLS2系统中创建有Linux虚拟系统，所述服务端运行于Windows系统上；所述仿真服务程序能够使得所述Linux虚拟系统中的所述客户端和Windows系统中的服务端访问同一份第二共享数据，以实现跨操作系统的测试数据传输；所述Windows系统下的第一中间件被封装为所述Linux虚拟系统下的第一中间件进行跨平台使用。

5.根据权利要求1所述的系统，其特征在于，所述第一中间件为将仿真驱动程序内嵌至第二中间件中封装得到，所述第二中间件中包括NVMe驱动程序，所述NVMe驱动程序用于通过PCIe总线与SSD设备连接。

6.根据权利要求5所述的系统，其特征在于，

所述第一中间件还用于：在对SSD设备进行第三阶段的测试场景中，接收所述测试管理系统发送来的第三测试用例，根据所述第三测试用例生成测试指令，若确定需要调用的驱动程序为所述NVMe驱动程序，则将所述测试指令发送给所述NVMe驱动程序；所述NVMe驱动程序用于：将所述测试指令发送给所述SSD设备以对所述SSD设备进行测试。

7.根据权利要求1所述的系统，其特征在于，所述客户端上还部署有主机仿真程序，所述主机仿真程序用于：对测试主机进行仿真，在所述第一阶段的测试场景中，向所述仿真器下发测试指令，以使所述仿真器依据所述测试指令和所述共享内存中的测试数据进行仿真测试。

8.一种SSD硬盘测试方法，其特征在于，所述方法基于权利要求1～7任一项所述的自动化测试系统实现，在对SSD设备进行第二阶段的测试场景中，所述方法包括如下步骤：所述第一中间件接收测试管理系统发送来的第一测试用例，根据所述第一测试用例生成对应的测试指令，确定需要调用的驱动程序，若需要调用的驱动程序为所述仿真驱动程序，则将所述测试指令发送给所述仿真驱动程序；

所述仿真驱动程序将所述测试指令通过socket协议发送给仿真器；

所述仿真器在接收到所述测试指令后，根据所述测试指令和所述共享内存中的测试数据对软件模拟的SSD设备进行测试，并在测试完成后依次通过所述仿真驱动程序和所述第一中间件反馈至所述测试管理系统。

9.根据权利要求8所述的SSD硬盘测试方法，其特征在于，所述方法基于权利要求2所述的自动化测试系统实现，在对所述仿真驱动程序进行测试的场景中，所述方法包括如下步骤：仿真驱动测试程序接收所述测试管理系统发送来的第二测试用例，将所述第二测试用例提交给所述专家数据库；

所述专家数据库接收所述仿真驱动测试程序发送来的第二测试用例，根据所述第二测试用例确定适用于所述仿真驱动程序执行的测试业务代码段，并将所述测试业务代码段反馈至所述仿真驱动测试程序；

仿真驱动测试程序在接收所述专家数据库反馈回来的测试业务代码段后，将所述测试业务代码段提交给所述仿真驱动程序，以使所述仿真驱动程序执行所述测试业务代码段，实现对所述仿真驱动程序的测试。

10.根据权利要求8所述的SSD硬盘测试方法，其特征在于，所述方法基于权利要求3所述的自动化测试系统实现，在对SSD设备进行第二阶段的测试之前，所述方法还包括：若所述客户端和所述服务端运行在Windows系统中，则仿真服务程序管理第一共享数据，并将所述第一共享数据存储至所述共享内存中。

11.根据权利要求8所述的SSD硬盘测试方法，其特征在于，所述方法基于权利要求4所述的自动化测试系统实现，在对SSD设备进行第二阶段的测试之前，所述方法还包括：若所述客户端运行在Linux虚拟系统中且所述服务端运行在Windows系统中，则仿真服务程序管理第二共享数据，并将所述第二共享数据存储至所述共享内存中。

12.根据权利要求8所述的SSD硬盘测试方法，其特征在于，所述方法基于权利要求6所述的自动化测试系统实现，在对SSD设备进行第三阶段的测试场景中，所述方法包括：所述第一中间件接收所述测试管理系统发送来的第三测试用例，根据所述第三测试用例生成测试指令，若确定需要调用的驱动程序为所述NVMe驱动程序，则将所述测试指令发送给所述NVMe驱动程序；

所述NVMe驱动程序将所述测试指令发送给所述SSD设备以对所述SSD设备进行测试。

13.根据权利要求8所述的SSD硬盘测试方法，其特征在于，所述方法基于权利要求7所述的自动化测试系统实现，在第一阶段的测试场景中，所述方法包括：所述主机仿真程序在所述第一阶段的测试场景中，向所述仿真器下发测试指令；

所述仿真器依据所述测试指令和所述共享内存中的测试数据进行仿真测试。

说明书

植入仿真器的自动化测试系统及SSD硬盘测试方法

技术领域

[0001] 本发明涉及SSD技术领域，尤其是涉及一种植入仿真器的自动化测试系统及SSD硬盘测试方法。

背景技术

[0002] 在SSD产品开发的各个验证阶段，企业会针对自己的产品研发出对应的测试平台，特别是在EVT测试阶段和DVT测试阶段，主要对当前产品的主要设计和功能进行验证。成熟的SSD测试验证平台可以提早发现产品设计开发阶段的诸多问题和故障，同时对产品验证的加速性、可靠性也提出了更高的要求。由于SSD产品具有周期短、功能迭代快等特点，因此对测试的提升空间巨大。

[0003] 目前现有的EVT测试适用于当前研发产品的FPGA，以此来模拟或替代产品的内嵌式单元、输入输出单元等，以达到功能调试的目的。但对于隐蔽性故障或特殊的硬件错误在短时间内无法复现或复现成本极高。为加快主控芯片固件设计研发周期的功能验证、提高固件代码质量、扫清固件代码隐藏故障，研发部门研发了一套搭载主控芯片固件的仿真器。SSD仿真器采用软件模拟SSD的主要外围硬件及寄存器的行为动作，SSD仿真器在搭载主控固件后可以仿真出一台SSD Device,从而可以模拟现有SSD产品的功能，接收并响应测试主机发送的指令。

[0004] 现有DVT测试采用的是一套自动化测试系统，自动化测试系统主要是通过第三方系统对测试任务和缺陷进行自动化管理，由第三方系统向测试主机下发测试指令，通知测试主机执行对应的测试用例。测试主机是搭载着需要测试的SSD Device的测试服务器，SSD Device不仅限于直接连接测试主机。有时也会根据测试需求放入一些特定的测试环境（例如，高低温箱、风速盒等）中。因此测试需求繁多，一些硬件环境或测试环境变更麻烦且复杂，所以虽然现有的测试能够满足自动化测试基本需求，但投入成本高、维护性不佳、测试效率不高。

[0005] 随着SSD仿真器建设的深入，用SSD仿真器替代SSD Device势必会提升当前的测试效率。将仿真器植入自动化测试系统，让SSD仿真器代理真实的SSD Device完成一些需求复杂、测试环境多样性的测试，所以加快测试平台的改善变得越来越迫切。

[0006] 在测试主机中，测试用例无法直接操作SSD Device,需要一个中间件来协助脚本对SSD Device进行控制，该中间件可以称为SOHO中间件。SOHO中间件是一套使用C++开发的动态库文件，它支持NVMe协议，封装了多套NVMe协议下的标准指令和公司自主研发的NVMe自定义指令。当NVMe驱动即NVMeDrive注册PCIe总线后，SOHO中间件通过NVMe驱动将NVMe指令通过PCIe总线传输到SSD Device。SOHO中间件还支持测试主机的其他硬件或驱动控制，如电源管理、IO管理、总线驱动管理、温控等。整个测试主机装载着测试用例、SOHO中间件和SSD Device三部分，由测试用例协同SOHO中间件提供的接口对SSD Device进行读/写、控制或Dera自研指令进行下发，配合测试主机的第三方系统务达到自动化测试的目的。

[0007] 现有SSD仿真器测试平台，简称Sim_Test平台，采用双进程方式，包含2个程序，一个是Simulator设备端，采用软件模拟SSD主要外围硬件，搭载主控CPU固件后可模拟真实SSD盘的功能，另一个是模拟Host主机端程序TestPro。可见整个Sim_Test平台全部由软件实现，部署在测试服务器上后，使用Socket 代替PCIe接口传输NVMe协议标准格式的请求指令，由Simulator设备端模拟SSD Device, 模拟Host主机端程序来模拟测试主机端向设备端发送指令，Simulator设备端应答返回给主机，从而完成一次通信。

[0008] 现有的自动化测试系统的缺陷主要集中在测试主机。由测试用例协同SOHO中间件提供的接口对SSD盘进行指令下发的这种常规测试操作虽然是产品测试阶段必须完成的，但也限制了自动化测试系统。试想在EVT测试初期，即在还没有真实产品的测试阶段，只针对真实盘测试的自动化测试系统是无法适配EVT测试的。即，在EVT阶段采用Sim_Test平台测试，在DVT阶段可以采用自动化测试系统测试。在EVT测试阶段和DVT测试阶段之间却没有办法进行测试，即测试阶段之间产生真空区域，无法被现有测试流程全覆盖。可见，EVT测试阶段使用Sim_Test平台对产品主控固件代码进行了初期设计验证，在DVT测试阶段对应的真实SSD Device进行测试，而在这之间没有其他测试衔接，自动化测试系统的作用被削弱和制约。

发明内容

[0009] 为了解决上述技术问题或者至少部分地解决上述技术问题，本发明提供了一种植入仿真器的自动化测试系统及SSD硬盘测试方法。

[0010] 第一方面，本发明实施例提供一种植入仿真器的自动化测试系统，所述系统包括部署在同一台测试主机上的客户端和服务端；其中：

[0011] 所述客户端上部署有第一中间件，所述第一中间件中封装有仿真驱动程序；所述第一中间件用于：在对SSD设备进行第二阶段的测试场景中，接收测试管理系统发送来的第一测试用例，根据所述第一测试用例生成对应的测试指令，确定需要调用的驱动程序，若需要调用的驱动程序为所述仿真驱动程序，则将所述测试指令发送给所述仿真驱动程序；所述仿真驱动程序用于将所述测试指令通过socket协议发送给仿真器；

[0012] 所述服务端上部署有所述仿真器和共享内存，所述仿真器用于：通过软件模拟SSD设备，在接收到所述测试指令后，根据所述测试指令和所述共享内存中的测试数据对软件模拟的SSD设备进行测试，并在测试完成后依次通过所述仿真驱动程序和所述第一中间件反馈至所述测试管理系统；

[0013] 其中，所述第二阶段位于第一阶段和第三阶段之间，所述第一阶段为对SSD设备进行设计之前进行测试的阶段，所述第三阶段为对SSD设备的设计完成之后进行测试的阶段。

[0014] 第二方面，本发明实施例提供一种SSD硬盘测试方法，所述方法基于第一方面提供的自动化测试系统实现，在对SSD设备进行第二阶段的测试场景中，所述方法包括如下步骤：

[0015] 所述第一中间件接收测试管理系统发送来的第一测试用例，根据所述第一测试用例生成对应的测试指令，确定需要调用的驱动程序，若需要调用的驱动程序为所述仿真驱动程序，则将所述测试指令发送给所述仿真驱动程序；

[0016] 所述仿真驱动程序将所述测试指令通过socket协议发送给仿真器；

[0017] 所述仿真器在接收到所述测试指令后，根据所述测试指令和所述共享内存中的测试数据对软件模拟的SSD设备进行测试，并在测试完成后依次通过所述仿真驱动程序和所述第一中间件反馈至所述测试管理系统。

[0018] 本发明实施例提供的植入仿真器的自动化测试系统及SSD硬盘测试方法，在测试主机上，第一中间件中的仿真驱动程序将测试指令发送给仿真器使仿真器对模拟的SSD设备进行测试，测试完成后的测试结果也通过仿真驱动程序反馈给第一中间件，可见第一中间件和仿真器之间通过仿真驱动程序进行交互，而且仿真驱动程序通过socket协议与仿真器交互，仿真器通过软件模拟SSD设备，可见第一中间件连接的并非是真实的SSD设备，而且不需要硬件的PCIe总线通信，而是通过socket协议通信。还有，测试数据只需要从共享内存中获取即可。可见本发明实施例提供的自动化测试系统有效解决目前自动化测试系统无法植入SSD仿真器的不适配问题，消除了软硬件调用不一致导致的天然“应用孤岛”现象，将仿真器和现有的自动化测试系统结合在一起。同时，实现了在第一阶段和第三阶段之间进行第二阶段的测试，而在目前能实现的测试仅是第一阶段的测试和第三阶段的测试，即填补了EVT、DVT测试阶段之间的空白流程，提升测试效率，加快了产品固件研发速度。

附图说明

[0019] 此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

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

[0021] 图1为本发明一个实施例中植入仿真器的自动化测试系统的结构框图；

[0022] 图2为本发明一个实施例中植入仿真器的自动化测试系统的结构框图；

[0023] 图3为本发明一个实施例中Back‑Up形式碎片整合技术的示意图；

[0024] 图4为本发明一个实施例中共享内存实现数据共享的原理示意图。

具体实施方式

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

[0026] 针对现有技术中的缺陷，提出了将Sim_Test平台植入到自动化测试系统中替代真实SSD盘进行测试的构想。如果真的可以将两个测试平台结合，就可以将2个测试平台的优势发挥出来。

[0027] 但是如果直接将Sim_Test平台植入，现有的自动化测试系统是无法适配的。原因是自动化测试系统的测试主机是通过SOHO中间件提供的接口来连接真实SSD Device硬件，所有的数据通路都是由中间件调用NVMe驱动，并通过PCIe 总线完成数据或指令的传输。而Sim_Test平台是属于一款软件模拟硬件的测试验证平台，由仿真器模拟SSD设备, 由TestPro模拟测试主机端，模拟出的数据通道与真实的硬件数据总线有着巨大的差距。将仿真器替换真实SSD Device， TestPro改为真实主机直接发送指令，存在软硬件调用不一致导致的天然“应用孤岛”现象，无法直接适配。

[0028] 可见，目前两大测试平台的合并存在不适配现象，是目前测试平台发展的瓶颈。

[0029] 为此，本发明实施例提供一种植入仿真器的自动化测试系统。

[0030] 参见图1和2，该系统包括部署在同一台测试主机上的客户端和服务端；其中：

[0031] 所述客户端上部署有第一中间件，所述第一中间件中封装有仿真驱动程序；所述第一中间件用于：在对SSD设备进行第二阶段的测试场景中，接收测试管理系统发送来的第一测试用例，根据所述第一测试用例生成对应的测试指令，确定需要调用的驱动程序，若需要调用的驱动程序为所述仿真驱动程序，则将所述测试指令发送给所述仿真驱动程序；所述仿真驱动程序用于将所述测试指令通过socket协议发送给仿真器；

[0032] 所述服务端上部署有所述仿真器和共享内存，所述仿真器用于：通过软件模拟SSD设备，在接收到所述测试指令后，根据所述测试指令和所述共享内存中的测试数据对软件模拟的SSD设备进行测试，并在测试完成后依次通过所述仿真驱动程序和所述第一中间件反馈至所述测试管理系统；

[0033] 其中，所述第二阶段位于第一阶段和第三阶段之间，所述第一阶段为对SSD设备进行设计之前进行测试的阶段，所述第三阶段为对SSD设备的设计完成之后进行测试的阶段。

[0034] 其中，将服务端和客户端部署在同一台测试主机上，目的是可以保证两端IO交互的效率。

[0035] 其中，测试过程一般包括EVT测试和DVT测试，EVT测试即第一阶段的测试，是在SSD设备进行设计之前进行的测试，一般对主控组件的功能是否正常进行测试和验证，不需要借助测试用例。DVT测试一般为第三阶段的测试，是对设计完成的SSD设备进行的测试，一般需要借助测试用例对SSD设备的代码功能性进行验证和测试。在本发明实施例中可以实现在第二阶段的测试，即在EVT测试阶段和DVT测试阶段之间的测试，这是现有技术所不能实现的。

[0036] 其中，在服务端上部署有仿真器即Simulator和共享内存即share Memory，其中仿真器用来通过软件模拟SSD设备，并在第二阶段的测试场景中对模拟的SSD设备进行测试。共享内存的目的是存储测试过程中所需要的测试数据，例如，读写数据。当然，在服务端上还可以部署有仿真服务程序即SimServer进程，这一点会在下文中阐述。

[0037] 其中，仿真器即Simulator.exe属于服务端部件，可以认为是虚拟SSD设备的逻辑运算部分。Simulator是实现SSD仿真测试的核心部件，采用软件模拟SSD主要外围硬件设备的寄存器、信号量、电源、存储介质和内存管理等，以达到仿真SSD设备的目的。仿真器中载入主控固件即Firmware。在启动Simulator后即可模拟搭载主控芯片的SSD Device，这样可以有效模拟固件代码在真实硬件环境下运行时的状态，让其与真实SSD Device产生相同的功能。

[0038] 其中，客户端上部署有第一中间件，第一中间件中封装有仿真驱动程序。当然在第一中间件中除了仿真驱动程序之外还存在其它的部件，用来与测试管理系统交互，将测试管理系统传过来的测试用例转换为对应的测试指令，发送给仿真驱动程序或者NVMe驱动程序。仿真驱动程序用来在第一中间件和仿真器之间交互、传输数据等。NVMe驱动程序用来在第一中间件和SSD设备之间交互、传输数据等。在不同的测试场景下，采用的驱动程序不同，具体采用哪一个驱动程序，可以由第一中间件根据相应的参数确定。

[0039] 其中，仿真驱动程序和仿真器之间可以通过socket协议交互，而NVMe驱动程序可以通过PCIe总线交互。

[0040] 其中，测试管理系统可以为第三方系统，工作人员通过测试管理系统控制自动化测试系统进行测试，并将自动化测试系统的测试结果在测试管理系统的界面上展示出来，以供工作人员及时了解测试情况。

[0041] 其中，测试用例在客户端使用，属于客户端部件,是Python脚本。

[0042] 可理解的是，基于上述自动化测试系统，在第二阶段的测试流程大致包括如下内容：

[0043] 在测试之前，需要编写测试用例，将测试用例上传到测试管理系统中。工作人员在不同的测试阶段选择不同的测试用例，将测试用例通过测试管理系统下发给自动化测试系统，并通知自动化测试系统开始进行测试。自动化测试系统中的第一中间件接收到测试用例后，根据第一测试用例生成对应的测试指令，然后确定需要调用的驱动程序是仿真驱动程序还是NVMe驱动程序。如果是仿真驱动程序，则将生成的测试指令下发给仿真驱动程序。仿真驱动程序将所述测试指令通过socket协议发送给仿真器。仿真器根据接收到的测试指令以及从共享内存中的测试数据对模拟的SSD设备进行测试。仿真器在测试完成后将测试结果发送给仿真驱动程序，仿真驱动程序将测试结果发送给第一中间件，第一中间件将测试结果反馈给测试管理系统中进行展示。

[0044] 其中，由于本发明实施例提供的自动化测试系统中采用了中间件的封装技术和数据共享技术，因此自动化测试系统可以称为MPAST，即Middleware packaging and sharing technology for auto‑test system，即，基于中间件封装和共享技术的自动化测试系统。

[0045] 本发明实施例针对现有技术中的自动化测试系统进行了改进，在服务端上除了增加仿真器外，还有共享内存，当然还有下文中提到的仿真服务程序。在客户端上增加了第一中间件，第一中间件中封装有仿真驱动程序，这些新增部件为仿真器植入现有的自动化测试系统提供了支持，克服了软硬件不一致的问题。

[0046] 在上述过程中实现了在第一阶段和第三阶段之间进行第二阶段的测试，而在目前能实现的测试仅是第一阶段的测试和第三阶段的测试。在测试主机上，第一中间件中的仿真驱动程序将测试指令发送给仿真器使仿真器对模拟的SSD设备进行测试，测试完成后的测试结果也通过仿真驱动程序反馈给第一中间件，可见第一中间件和仿真器之间通过仿真驱动程序进行交互，而且仿真驱动程序通过socket协议与仿真器交互，仿真器通过软件模拟SSD设备，可见第一中间件连接的并非是真实的SSD设备，而且不需要硬件的PCIe总线通信，而是通过socket协议通信。还有，测试数据只需要从共享内存中获取即可。可见本发明实施例提供的自动化测试系统有效解决目前自动化测试系统无法植入SSD仿真器的不适配问题，消除了软硬件调用不一致导致的天然“应用孤岛”现象，将仿真器和现有的自动化测试系统结合在一起。同时，填补了EVT、DVT测试阶段之间的空白流程，提升测试效率，加快了产品固件研发速度。

[0047] 在第二阶段的测试场景中，为了实现对测试数据的管理和控制，所述服务端中还可以部署有仿真服务程序，即SimServer进程。该程序的作用是管理和控制共享数据，将共享数据存储在共享内存中。仿真服务程序属于服务端部件,可以认为是虚拟SSD设备的可持久化部分，它创建了共享内存给仿真器和仿真驱动程序使用，进而通过共享内存建立了仿真驱动程序和仿真器之间的数据通路，替代了真实的数据总线的数据传输功能。

[0048] 通过仿真服务程序可以实现在两种情况下的数据传输：

[0049] （1）服务端和客户端处于同一操作系统下运行

[0050] 此时，所述仿真服务程序可以用于：管理第一共享数据，并将所述第一共享数据存储至所述共享内存中；所述第一共享数据用于在所述客户端和所述服务端为Windows系统的场景下进行测试所采用的测试数据，所述第一中间件为Windows系统下的第一中间件。

[0051] 也就是说，当客户端和服务端均运行在Windows系统时，仿真服务程序可以控制和管理第一共享数据，将第一共享数据存储在共享内存中，这样在第二阶段的测试场景中，仿真器可以从共享内存中获取到测试数据，进而根据测试指令和测试数据进行仿真测试。

[0052] （2）服务端和客户端处于不同操作系统下运行

[0053] 此时仿真服务程序可以用于：管理第二共享数据，并将所述第二共享数据存储至所述共享内存中；所述第二共享数据用于在所述客户端和所述服务器为不同的操作系统的场景下进行测试采用的测试数据；

[0054] 其中，所述客户端运行于WLS2系统上，WLS2系统中创建有Linux虚拟系统，所述服务端运行于Windows系统上；所述仿真服务程序能够使得所述Linux虚拟系统中的所述客户端和Windows系统中的服务端访问同一份第二共享数据，以实现跨操作系统的测试数据传输；所述Windows系统下的第一中间件被封装为所述Linux虚拟系统下的第一中间件进行跨平台使用。

[0055] 例如，在WLS2系统中创建了Linux虚拟系统，即Linux虚拟机，客户端运行在Linux虚拟系统上，而服务端仍运行在Windows系统上，通过仿真服务程序对第二共享数据进行管理，使得Windows系统和Linux虚拟系统可以访问同一份数据，以实现跨操作系统的数据传输。

[0056] 其中，在此场景下，Linux虚拟系统下的第一中间件为对Windows系统下的第一中间件进行封装后得到。

[0057] 除了以上两种情况下对共享数据进行管理和控制之外，仿真服务程序还可以对虚拟SSD设备中的寄存器、DDL存储空间、Nand介质和一些公共的跨进程数据结构进行管理，但仿真服务程序本身不操作共享内存，同时作为驻守进程，在后台运行。

[0058] 在一个实施例中，所述第一中间件可以为将仿真驱动程序内嵌至第二中间件中封装得到，所述第二中间件中包括NVMe驱动程序，所述NVMe驱动程序用于通过PCIe 总线与SSD设备连接。

[0059] 可理解的是，由于第二中间件中包括NVMe驱动程序，第二中间件和仿真驱动程序封装后得到第一中间件。同时，第二中间件中除了NVMe驱动程序外还包括各种接口。

[0060] 其中，第一中间件即SimClient，属于客户端部件。SimClient作为第一中间件，共分为2层：SimDrive和SimSoHo。即仿真驱动程序SimDrive和第二中间件SimSoHo。仿真驱动程序SimDrive可以认为是虚拟SSD设备的驱动层，负责与仿真器、仿真服务程序进行通信。第二中间件SimSoHo中包括接口层和NVMe驱动程序。可见，第一中间件在保证接口一致的情况下，可以提供两套业务分支，一套是通过NVMe驱动程序和PCIe总线直接连接真实的SSD Device，另一套是通过仿真驱动程序连接SSD仿真器，使得自动化测试系统为仿真测试和真实SSD设备测试提供支持。

[0061] 而且，第一中间件向测试用例提供的接口相对于现有技术没有发生变化，仍然是SimSoHo中的接口。由于第一中间件向外提供给测试用例即Python脚本调用的接口一致，保证了测试主机的测试用例即python脚本不需要变更，自动化测试系统更上一层的第三方系统、服务和框架也无需变更，即可以保证了现有技术中提供的第三方系统、服务、框架、测试用例针对本发明实施例提供的自动化测试系统仍然可以使用。

[0062] 在一个实施例中，基于上述第一中间件，还可以进行第三阶段的测试，即对真实的SSD设备进行测试，将真实的SSD设备通过PCIe总线与测试主机连接，具体是与测试主机的客户端上的NVMe驱动程序连接。此时，所述第一中间件还可以用于：在对SSD设备进行第三阶段的测试场景中，接收所述测试管理系统发送来的第三测试用例，根据所述第三测试用例生成测试指令，若确定需要调用的驱动程序为所述NVMe驱动程序，则将所述测试指令发送给所述NVMe驱动程序；所述NVMe驱动程序用于：将所述测试指令发送给所述SSD设备以对所述SSD设备进行测试。

[0063] 举例来说，工作人员如果想要进行第三阶段的测试，则在测试管理系统上选择合适的测试用例，该测试用例可以称为第三测试用例，将该第三测试用例发送给自动化测试系统，自动化测试系统中的第一中间件接收到第三测试用例，根据第三测试用例生成对应的测试指令，并根据自动化测试系统传过来的测试阶段相关参数，根据该参数确定需要调用NVMe驱动程序，然后将测试指令发送给NVMe驱动程序，NVMe驱动程序将测试指令发送给SSD设备，从而控制SSD设备进行测试。在测试完成后，NVMe驱动程序将测试结果反馈给第一中间件，第一中间件将测试结果反馈给测试管理系统进行展示。

[0064] 可见，基于以上第一中间件也可以实现对真实的SSD设备进行测试，即在同一台测试主机上既可以实现第二阶段的仿真测试，又可以实现第三阶段的实物测试。

[0065] 在一个实施例中，所述客户端上还可以部署有主机仿真程序，所述主机仿真程序可以用于：对测试主机进行仿真，在所述第一阶段的测试场景中，向所述仿真器下发测试指令，以使所述仿真器依据所述测试指令和所述共享内存中的测试数据进行仿真测试。

[0066] 例如，主机仿真程序对测试主机进行仿真，即通过软件模仿测试主机，测试管理系统向自动化测试系统发送EVT测试指令，当自动化测试系统中的主机仿真程序接收到这个指令后，向仿真器下发测试指令，从而使得仿真器根据测试指令和共享内存中的测试数据进行仿真测试，在这个过程中仿真器用来模拟SSD设备。

[0067] 可见，测试主机还可以实现EVT测试。

[0068] 在一个实施例中，所述客户端上还可以部署有仿真驱动测试程序，所述服务端上还部署有专家数据库；其中：

[0069] 所述仿真驱动测试程序用于：在对所述仿真驱动程序进行测试的场景中，接收所述测试管理系统发送来的第二测试用例，将所述第二测试用例提交给所述专家数据库，接收所述专家数据库反馈回来的测试业务代码段，将所述测试业务代码段提交给所述仿真驱动程序，以使所述仿真驱动程序执行所述测试业务代码段，实现对所述仿真驱动程序的测试；

[0070] 所述专家数据库用于：接收所述仿真驱动测试程序发送来的第二测试用例，根据所述第二测试用例确定适用于所述仿真驱动程序执行的测试业务代码段，并将所述测试业务代码段反馈至所述仿真驱动测试程序；

[0071] 其中，在对所述仿真驱动程序进行测试的场景中，所述仿真驱动程序设置在所述仿真驱动测试程序中，在对所述仿真驱动程序测试通过后，根据所述仿真驱动程序形成所述第一中间件。

[0072] 也就是说，在将仿真驱动程序封装为第一中间件之前，还可以对仿真驱动程序进行测试，在测试成功后将其和第二中间件封装为第一中间件。在对仿真驱动程序测试时，仿真驱动程序是包括在仿真驱动测试程序中的。

[0073] 举例来说，工作人员在测试管理系统中下发针对仿真驱动程序进行测试的测试指令和测试用例，该测试用例称为第二测试用例。当自动化测试系统在接收到这一指令和第二测试用例后，通知仿真驱动测试程序进行测试。仿真驱动测试程序将第二测试用例发给专家数据库，专家数据库依据专家数据库内的数据、决策树算法、加权平均算法等自动分析出一段测试业务代码段，并将其反馈给仿真驱动测试程序。仿真驱动测试程序将测试业务代码段提交给仿真驱动程序，仿真驱动程序执行测试业务代码段，以对仿真驱动程序的功能完整性和稳定性进行测试。

[0074] 其中，仿真驱动测试程序即SimDrive_Test，属于客户端部件, SimDrive_Test是一款GUI 工具，面向开发与测试人员。仿真驱动测试程序接收测试管理系统发送来的收Python脚本，然后通过WebService提交给专家数据库DMS，并接收由专家数据库DMS反馈回的测试业务代码段，接着通过内存载入技术将测试业务代码段发送给仿真驱动程序，仿真驱动程序作为桩程序执行测试业务代码段，来验证仿真驱动程序功能的完整性和稳定性。

[0075] 其中，专家数据库DMS属于服务端部件，DMS也叫Data Manager System,是一套不断完善的数据中台，通过各类数据技术对研发、测试、生产制造等环节所产生的数据进行收集、处理、储存、计算、分析和可视化呈现。专家数据库DMS能根据WebService接口接收到的Python脚本，通过决策树算法、加权平均算法自动分析出一段适用于仿真驱动程序SimDrive执行的测试业务代码段，并通过WebService接口返回给仿真驱动测试程序SimDrive_Test，使其对仿真驱动程序SimDrive进行功能验证和测试。

[0076] 可见，本发明实施例提供的自动化测试系统，如图1所示，可以实现5种测试场景：测试场景1是通过仿真驱动测试程序和专家数据库对仿真驱动程序进行测试。测试场景2是通过主机仿真程序和仿真器实现EVT测试。测试场景3是通过第一中间件、共享内存、仿真器、仿真服务程序实现客户端和服务段在同一操作系统上运行时的第二阶段测试。测试场景4是通过第一中间件、共享内存、仿真器、仿真服务程序实现客户端和服务段在不同操作系统上运行时的第二阶段测试。测试场景5是通过第一中间件和SSD设备实现DVT测试。

[0077] 其中，测试场景1中，客户端和服务端均运行在Windows系统上，在客户端上包括仿真驱动测试程序SimDrive_Test GUI程序，仿真驱动测试程序SimDrive_Test内部包含仿真驱动程序SimDrive。该测试场景主要目的是通过仿真驱动测试程序SimDrive_Test和专家数据库生成简易测试逻辑，对仿真驱动程序SimDrive进行功能验证和测试，来捕捉仿真驱动程序SimDrive中缺失或未实现的功能，从而可以快速定位补充仿真驱动程序SimDrive的功能，并加速仿真驱动程序SimDrive的稳定性测试，实现了仿真驱动程序SimDrive的内部接口、功能的自检和压测。

[0078] 其中，测试场景2中，客户端和服务端均运行在Windows系统上，客户端包含一套主机仿真程序即TestPro程序，它是现有Sim_Test测试平台中的Host主机端仿真程序TestPro。该测试场景的目的是进行EVT测试。在保持原有Sim_Test测试平台的基础上，保持Simulator原有的开发进度，继续开发、扩充或支持更多产品机型的仿真。而TestPro程序将开发重心转移到对主控芯片固件即Firmware的工程验证测试用例的编写，加速对核心固件代码的健壮性测试。

[0079] 其中，测试场景3中，客户端和服务端均运行在Windows系统上，客户端包含第一中间件，第一中间件分为两层： SimDrive和第二中间件，第一中间件是将SimDrive直接内嵌到第二中间件中封装得到。该测试环境主要目的是利用第一中间件，实现在Windows环境下的第二阶段测试，在该测试过程中，采用仿真器替代真实SSD  Device, 第一中间件SimClinet替代原有的第二中间件SimSOHO，Python脚本则保持不变。

[0080] 其中，测试场景4中，客户端运行在WLS2系统上，需要安装WLS2即Windows Subsystem for Linux，安装WLS2的客户端与Windows系统的服务端在同一台服务器或PC中。并在WLS2中创建Linux虚拟系统。客户端中包含第一中间件SimClinet，SimClinet被封装成Linux 下的第一中间件提供给测试用例调用。该测试环境主要目的是实现跨系统的第二阶段测试。

[0081] 可理解的是，第一中间件SimClient是本发明实施例中的核心程序，中间件是介于操作系统和应用软件之间的一类软件，在测试过程中提供基础服务，达到资源共享、功能共享的目的。

[0082] 其中，第一中间件SimClient可以实现现有的第二中间件的所有接口功能。仿真驱动程序和第二中间件封装成第一中间件SimClient后，才能替代第二中间件，实现SSD仿真器代理真实SSD Device进行测试。

[0083] 其中，第二中间件主要支持设备电源管理、主机端内存管理、支持NVMe驱动及NVMe标准协议、Bus管理等，而数据主要使用PCIe Bus和UART串口通讯。其次仿真驱动程序SimDrive层还支持被仿真驱动测试程序SimDrive_Test包含，允许GUI工具通过内存载入技术提交测试业务代码段并执行。

[0084] 其中，剥离第二中间件的接口功能，并设定各功能的替代方案或技术，如下表1所示。现有第二中间件所操作的是真实SSD Device,仿真驱动程序SimDrive的替代方案或技术操作的是服务端的仿真服务程序SimServer和仿真器Simulator.exe，以下列举部分核心接口功能及仿真驱动程序SimDrive的替代方案。

[0085] 表1

[0086] 原接口功能 描述 替代方案设备电源管 通过控制电源使SSD Device 提供相应接口能实现Create&Kill 仿真器，用于模拟设备理 完成上电、掉电、异常掉电等 电源管理
操作。
主机端内存 声明Host内存存储空间，提 操作SharedMemory与Simulator交互管理 供测试数据临时给
SSDDevice使用。
支持NVMe驱 调用NVMe驱动程序，传递 模拟NVMe S/C Queue Entry管理模块，按标准协议组织动及NVMe标 64ByteNVMe标准协议指令。 NVMe cmd
准协议
Bus管理 用于识别和管理通讯的Bus。无，统一使用Socket
IO通讯 IO时数据的传输 IO的数据创建在SharedMemory中，放弃数据搬移，优化为指针传递，提高与Simulator的交互，保证模拟出真实盘IO
读写效率。

[0087] 其中，因为仿真驱动测试程序SimDrive_Test接收到的测试业务代码段大小不固定，或者客户端利用共享内存与服务端进行数据通讯的指令/用户数据大小不一，因此对内存载入技术所需的虚拟内存定义及管理。虚拟内存定义遵循极值定义原则，将虚拟内存的大小及各区域结构体配置信息同步到配置文件，仿真驱动程序SimDrive被启动时动态加载配置文件。虚拟内存的创建采用Back‑Up形式，具体参见图3，方便在虚拟空间不足时进行碎片整合技术优化虚拟内存。虚拟内存的管理机制采用内存链表法进行标记和定义，通过标记识别和内存交换技术腾出空闲内存，按先入先执行载入数据。

[0088] 其中，服务端的仿真服务程序SimServer和仿真器simulator.exe协定共享内存ShareMemory和跨系统环境下的第二共享数据。客户端与服务端的交互，有两条通路来替代原有的PCIe总线，一个是第一共享数据，一个是第二共享数据。通过Socket协议发送指令NVMe cmd,而数据User data/Meta data将会以Page方式（例如大小为4K）储存在共享内存ShareMemory中，ShareMemory可以最大效率的提升进程之间的数据共享用来模拟PCIe数据的传输，而测试主机中的数据搬移将优化成数据地址传输提升了数据传输效率。

[0089] 在现有的测试平台上对SSD设备进行读写时，其实是通过指令对数据进行搬移。参见图4，本发明实施例中通过共享内存技术，由仿真服务程序负责管理和维护共享内存，将需要相互传递的数据存储在共享内存中，在数据传输时只需要在指令中携带上共享内存中的数据地址，不需要对数据进行搬移，从而提高IO执行效率。

[0090] 其中，第一中间件负责调用仿真驱动程序SimDrive，利用中间件发布动态库的特性，可以按不同系统环境发布.dll/.so等库文件，向外提供给测试Python脚本调用，达到功能共享的目的，同时支持在Windows或Linux系统上搭建自动化测试主机。

[0091] 上文中提到一些专有名词，下面简要介绍：

[0092] 1、EVT测试：是产品开发初期的设计验证测试。

[0093] 2、DVT测试：是产品的所有设计已全部完成，需要对产品的性能或功能进行测试。

[0094] 3、FPGA：属于专用集成电路中的一种半定制电路，是可编程的逻辑列阵,通过代码仿真保证设计方案符合实际要求，最后进行板级调试，验证实际运行效果。

[0095] 4、仿真器：仿真软件simulation software，专门用于仿真的计算机软件。它与仿真硬件同为仿真技术工具。

[0096] 5、自动化测试平台：一种SSD的自动化测试系统，通过第三方系统完成任务和缺陷的管理，驱动脚本进行测试、对信息数采汇总和统计展示。

[0097] 6、固件：即Firmware,是一种写入EPROM的设备“驱动程序”，通过固件，操作系统才能按照标准的设备驱动实现特定设备的运行动作，驱动设备工作。

[0098] 可理解的是，本发明实施例提出并实现了将SSD仿真器植入到自动化测试系统用于代理SSD Device测试的构想，为拓展自动化测试系统的测试业务进行了技术应用创新。本发明实施例将第二中间件的功能接口进行细化拆分，在Sim_Test测试平台原有功能基础上完成技术方案替代平移转换，并将这些测试接口业务封装入第一中间件，将原本毫无关联的两套测试平台实现串联。同时使用WLS2等新型虚拟机技术，在同一测试主机上搭载两套系统(NVMeDrive+真实SSD Device和SimDrive+SSD仿真器)，有效保障测试主机的测试功能性，同时也不会对性能产生影响。实现了由仿真器代理真实SSD Device提供自动化测试基础服务能力，达到了资源共享、功能共享的目的，打破了“应用孤岛”瓶颈。

[0099] 可理解的是，本发明实施例围绕现有自动化测试系统的技术瓶颈，将SSD仿真器植入自动化测试系统。通过技术应用创新，打破测试平台“应用孤岛”瓶颈，扭转了SSD仿真器只能用于EVT测试代码健壮性测试的单一目的。让EVT和DVT测试都将变的更加灵活，仿真测试拥有了自动化，自动化测试也能由仿真器来代理测试，大幅降低测试成本，解决了测试用例的可继承性、移植性，实现了可以一次性编写测试脚本，解决了由EVT到DVT测试流程之间的真空期问题。可见，种种优势将极大的提升产品研发周期的功能验证，为研发提供了更便捷多态化的测试环境。

[0100] 第二方面，基于第一方面中提供的自动化测试系统，本方面提供一种SSD硬盘测试方法，在对SSD设备进行第二阶段的测试场景中，所述方法包括如下步骤：

[0101] 所述第一中间件接收测试管理系统发送来的第一测试用例，根据所述第一测试用例生成对应的测试指令，确定需要调用的驱动程序，若需要调用的驱动程序为所述仿真驱动程序，则将所述测试指令发送给所述仿真驱动程序；

[0102] 所述仿真驱动程序将所述测试指令通过socket协议发送给仿真器；

[0103] 所述仿真器在接收到所述测试指令后，根据所述测试指令和所述共享内存中的测试数据对软件模拟的SSD设备进行测试，并在测试完成后依次通过所述仿真驱动程序和所述第一中间件反馈至所述测试管理系统。

[0104] 在一个实施例中，在对所述仿真驱动程序进行测试的场景中，所述方法包括如下步骤：

[0105] 仿真驱动测试程序接收所述测试管理系统发送来的第二测试用例，将所述第二测试用例提交给所述专家数据库；

[0106] 所述专家数据库接收所述仿真驱动测试程序发送来的第二测试用例，根据所述第二测试用例确定适用于所述仿真驱动程序执行的测试业务代码段，并将所述测试业务代码段反馈至所述仿真驱动测试程序；

[0107] 仿真驱动测试程序在接收所述专家数据库反馈回来的测试业务代码段后，将所述测试业务代码段提交给所述仿真驱动程序，以使所述仿真驱动程序执行所述测试业务代码段，实现对所述仿真驱动程序的测试。

[0108] 在一个实施例中，在对SSD设备进行第二阶段的测试之前，所述方法还包括：

[0109] 若所述客户端和所述服务端运行在Windows系统中，则仿真服务程序管理第一共享数据，并将所述第一共享数据存储至所述共享内存中。

[0110] 在一个实施例中，在对SSD设备进行第二阶段的测试之前，所述方法还包括：

[0111] 若所述客户端运行在Linux虚拟系统中且所述服务端运行在Windows系统中，则仿真服务程序管理第二共享数据，并将所述第二共享数据存储至所述共享内存中。

[0112] 在一个实施例中，在对SSD设备进行第三阶段的测试场景中，所述方法包括：

[0113] 所述第一中间件接收所述测试管理系统发送来的第三测试用例，根据所述第三测试用例生成测试指令，若确定需要调用的驱动程序为所述NVMe驱动程序，则将所述测试指令发送给所述NVMe驱动程序；

[0114] 所述NVMe驱动程序将所述测试指令发送给所述SSD设备以对所述SSD设备进行测试。

[0115] 在一个实施例中，在第一阶段的测试场景中，所述方法包括：

[0116] 所述主机仿真程序在所述第一阶段的测试场景中，向所述仿真器下发测试指令；

[0117] 所述仿真器依据所述测试指令和所述共享内存中的测试数据进行仿真测试。

[0118] 可理解的是，本发明实施例提供的方法中有关内容的解释、具体实施方式、有益效果、举例等内容可以参见第一方面提供的系统中的相应部分，此处不再赘述。

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

[0120] 本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、挂件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。

[0121] 以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。