我有一个 Windows 应用程序，它利用第 3 方工具 (FaxMan) 通过连接到 PC 的 COM 端口发送传真。为了对我的应用程序进行压力测试，我想创建一些假装连接了传真调制解调器的虚拟 COM 端口。然后，我想“欺骗”发送传真，而无需实际发送任何内容。虚拟 COM 端口需要像发送传真一样响应标准 AT 命令。欺骗失败的能力将是一个额外的好处。
我的第一个想法是使用虚拟 COM 端口驱动程序重定向到远程登录或其他 TCP 会话 - 然后我可以拥有一个假装通过传真动作的 TCP 服务器。但是，如果有组件，我很乐意为组件付费。
【问题讨论】：
我在这个问题上工作了几年，开发了一个局域网传真产品。我怀疑你能否做好。
开发虚拟 COM 驱动程序意味着开发内核驱动程序（除非您可以购买现成的）：这是可行的（我做到了），但我猜它的麻烦远大于它的价值（我会感到惊讶如果值得你花时间）。
另一个问题是有各种各样的传真调制解调器和传真调制解调器标准（你说你希望模仿一个足以欺骗 FaxMan）。
另一个（基本）问题是更简单（非纠错）传真协议是（硬）实时协议：传真上有一些（或多或少）缓冲调制解调器，但连接到传真调制解调器的 PC 不能承受发送时欠载或接收时超载...这意味着通过 telnet 重定向此流量（使用 TCP 计时器和缓冲区）在最坏的情况下会中断传真会话（FaxMan将超时）或充其量意味着您的测试不能代表真实世界（非模拟）的性能。
您到底要对什么进行压力测试：您的应用程序，还是第三方 FaxMan？
我建议最便宜的解决方案和最真实的测试是使用真实的硬件：真实的 COM 端口、真实的传真调制解调器和真实的（或可能是模拟的）电话线。
编辑以回答迈克尔回答中 cmets 提出的问题
假设数据传输是一个小问题（例如，因为您可以简单地将两个串行端口背靠背连接），那么编写模拟传真调制解调器的软件是一个小问题吗？
它可能很小：如果您的负载测试只是“将传真数据发送到比特桶”，那么您的模拟调制解调器主要只需要对看起来像 AT 命令的每个/任何东西响应“OK”，以及各种其他响应到各种特定于传真的 AT+F_whatever_ 命令。但这是一个相当低保真度、不是非常严格的测试。
这很简单——但传真数据传输中不涉及一些协议吗？还是该协议只是 AT 命令集的变体，而欺骗“OK”就是它的全部内容？老实说，我不知道，但我认为会有一个更复杂的协议。
电话协议的名称类似于“T.4”和“T.30”。 PC-to-faxmodem 协议通常是一种称为“1 类传真”或“2 类传真”的协议。后者（“2 类”或“2.0 类”）是两者中的更高级别：更多的 ASCII 和更少的二进制数据，对时间不那么敏感（1 类对 10 秒的毫秒 iirc 敏感），因为它封装了/比第 1 类包含更多的底层 T.30 协商；它由扩展的 AT 命令（即 AT+F_something_ 命令及其响应）以及二进制编码传真图像数据的转储组成。
一些响应不仅仅是“OK”（即它们代表可用/协商的传真会话参数），而且（在第 2 类而不是第 1 类中）它们是 ASCII 编码而不是二进制，所以不太难真的。
必须有某种握手，对吧？否则，一台普通的旧传真机在加载新页面时可能会丢失大量数据。
是的，有一些握手（“我现在可以发送吗？”）在 个页面之间（即在每个页面之前）。不测试时间的负载测试仿真只会响应“是的，继续（我只会将数据转储到位桶中，甚至不看它，所以我在乎什么）”握手查询。
仿真还必须观察<DLE><ETX> 和<DLE><DLE> 的二进制图像数据（它从PC 获取），以便在PC-dumps-image-data-to 结束时响应OK -调制解调器。
我不知道 FaxMan 应用程序中可能内置了哪些计时器（您是否可能需要在模拟的响应中添加人为延迟，以防止 FaxMan 意识到响应异常快）：也许没有，但也许.
页面内可能有也可能没有握手：
【讨论】：
我认为ChrisW's advice 不错——尤其是电话线模拟器——它们并不太贵，而且在我做调制解调器驱动程序时非常有用。
也就是说，有一个开源驱动程序包（根据他们的说法）可以让您设置成对的虚拟 com 端口：http://com0com.sourceforge.net/
您可以将 FaxMan 应用程序连接到一个 COM 端口，然后连接到一个传真“模拟器”，它处理 AT 命令集以及您要测试的传真协议中的任何内容。这听起来像您要找的东西 - 但是...
【讨论】：
【讨论】：