如果设备通过USB连接，并且存在于您的系统范围内，您可以查看此项目（http://usbip.sourceforge.net），它允许您使用USB作为DPI（设备编程接口）在另一台服务器上通过IP与实际设备通信。
第二种方法是编写模拟器作为虚拟驱动程序-可能比购买设备更昂贵，但我们曾经在硬件和软件的共同开发中这样做过，而硬件实际上并不存在工作形式。
首先，这是一个相当普遍的问题，您可以针对一类设备获得更好的答案。
我的观点是，这是可能的，它将需要更多或更少的工作，具体取决于设备类别、设备和您想要探测的功能。某些设备类别具有共享功能和特定功能。我理解您想要获取通用信息，即共享信息。
首先要记住的是，驱动程序是操作系统（例如内核）和硬件之间的接口。因此，存在共享的 接口。驱动程序可能非常复杂（例如图形驱动程序），并且可能具有自己的 GUI 和内部逻辑，我认为如果您不涉及此部分，您可以编写一个程序，以获得您想要获取的设备类别的答案。
我认为最通用/一般的方法是实现如何获取有关设备信息，这是通过获取驱动程序，从dll (dumpbin.exe /exports) 或 so 文件中提取符号，并找出如果您请求例如打印机可以使用哪种格式，您可以获得哪些答案。要获取可能的答案，需要进入驱动程序的逻辑，例如使用IDA pro。
对于这个任务，您可能还需要使用依赖项。
在FreeBSD上，我们可以从驱动程序的Windows二进制文件构建一个freebsd驱动程序 (设置网络接口卡)。有一个从FreeBSD调用到Windows调用的翻译。阅读源代码可以帮助您了解它是如何完成的。
最后，您确实可以去硬件农场（正如nbari提到的AWS移动农场），或者只需询问供应商有关其硬件的表格，或者驱动程序测试API模拟硬件，以便您可以直接查询驱动程序。
是否有模拟器可用？
如果有，使用它们；如果没有，使用类似的模拟器，首先寻找同一制造商的模拟器，然后是任何打印机模拟器。如果没有，除非客户可以被说服需要购买他们将在现场使用的特定硬件，否则该要求无法测试。有时候你必须成为坏消息的传递者，但他们以一种不能归咎于你的方式强迫你采取行动。
后者是风险最小的做法。如果您使用其他建议中的任何一个，您必须告诉客户，风险会随着测试距离硬件越远而增加。然后他们必须做出决定，采取哪种行动，并因此承担风险。
顺便问一下，如果您在现场使用打印机，不能安排借用一台打印机来进行测试吗？
除非我误解了问题，否则这就是我会采取的方法。
