我在这个问题上工作了几年，开发了一个 LAN 传真产品。我怀疑你能否做好。
开发虚拟 COM 驱动程序意味着开发内核驱动程序（除非您可以购买现成的）：这是可行的（我做到了），但我猜它的麻烦远大于它的价值（如果它值得我会感到惊讶你的时间）。
另一个问题是有多种传真调制解调器和传真调制解调器标准（你说你希望模仿一个足以欺骗 FaxMan）。
另一个（基本）问题是更简单的（非纠错）传真协议是（硬）实时协议：传真调制解调器上有一些（或多或少）缓冲，但连接到传真调制解调器的 PC不能承受发送时欠载或接收时超载...这意味着通过 telnet（使用 TCP 计时器和缓冲区）重定向此流量要么在最坏的情况下中断传真会话（FaxMan 将超时），要么在最好的情况下意味着您的测试不能代表真实世界（非模拟）的性能。
无论如何，您要对什么进行压力测试：您的应用程序，还是第三方 FaxMan？
我建议最便宜的解决方案和最真实的测试是使用真实的硬件：真实的 COM 端口、真实的传真调制解调器和真实的（或者，可能是模拟的）电话线。
编辑以回答迈克尔回答中评论中的问题
假设数据的传输是一个小问题（例如，因为您可以简单地将两个串行端口背靠背连接），那么编写模拟传真调制解调器的软件是一个小问题吗？
它可能很小：如果您的负载测试只是“将传真数据发送到比特桶”，那么您的模拟调制解调器大多只需要对看起来像 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 编码而不是二进制，所以一点也不难.
必须有某种握手，对吧？否则，一台普通的旧传真机在加载新页面时可能会丢失大量数据。
是的，页面之间（即每页之前）有一些握手（“我现在可以发送吗？” ）。不测试时间的负载测试仿真只会响应“是的，继续（我只会将数据转储到位桶中，甚至不看它，所以我在乎什么）”握手询问。
为了在 PC-dumps-image-data-to-the-modem 结束时响应 OK，仿真还必须观察<DLE><ETX>和的二进制图像数据（它从 PC 获取） 。<DLE><DLE>
我不知道 FaxMan 应用程序中可能内置了哪些计时器（您是否可能需要在模拟响应中添加人为延迟，以防止 FaxMan 意识到响应异常快）：也许不是，但也许。
页面内可能有也可能没有任何握手：
我认为ChrisW 的建议是合理的——尤其是获得电话线模拟器——它们并不太贵，而且在我做调制解调器驱动程序时非常有用。
也就是说，有一个开源驱动程序包（根据他们的说法）可以让您设置虚拟 com 端口对：http ://com0com.sourceforge.net/
您可以将 FaxMan 应用程序连接到一个 COM 端口，然后连接一个传真“模拟器”来处理 AT 命令集以及您要测试的传真协议中的任何内容。这听起来像你在找什么 - 但是......