几个月前，我和我的前老板正在讨论他公司的最新产品以及他们在办公室和工厂中用于测试目的的系统。“一切都是 DOS——你想要的是便宜，”他告诉我。我相信这句话概括了 DOS 成为工厂和许多实验室首选操作系统的原因。一个设备齐全的 SCSI DOS 系统只需要很少的内存、一块廉价的显卡和显示器，以及一个相对便宜的 SCSI 控制器。当然，如今还有许多其他原因可以使用 DOS 来测试 SCSI 外围设备。这里有大量的知识库、基于 ASPI 的工具，而且很可能公司已经在测试软件或开发自己的测试方面进行了大量投资。（ASPI 代表高级 SCSI 协议接口，由 Adaptec 开发。它是 DOS 和 Windows 上事实上的 SCSI 编程接口。）然而，Linux 也是一个可行的 SCSI 测试系统，并且有一些非常充分的理由说明您应该考虑使用 Linux 来测试您的 SCSI 设备。

测试 SCSI 顺序访问设备并非易事。这些设备（具体来说是 DDS 和 AIT 磁带驱动器）通常用于服务器环境中，系统停机是不可接受的，尤其是当停机是由于数据备份设备挂起 SCSI 总线时。（DDS，数字数据存储，是索尼的 4mm 磁带驱动器技术。AIT，高级智能磁带，是索尼新的 8mm 磁带驱动器技术。）为了将此类产品推向市场，需要在相当多的领域进行广泛的测试。目前，测试是在运行索尼内部测试或独立软件供应商 (ISV) 备份软件或 OEM 专有系统（运行 UNIX、NT 或其他一些专有操作系统）的 PC 上进行的。这些设备的认证周期比硬盘驱动器长得多，但产品的生命周期也更长。您可以测试的系统越多，您可以运行的测试类型越多，您的产品就会越可靠。

如果不使用专门的工具（例如 Itech SCSI 模拟器），就无法测试 SCSI 协议的某些部分。这种类型的工具允许工程师开发强大的低级 SCSI 测试来测试 SCSI 协议处理。例如，使用这种工具，您可以发出写入命令，向驱动器发送一个或多个字节，提升 ATN（注意控制信号），然后在驱动器输出数据时，发送中止或复位消息。然而，这些工具非常昂贵（超过 5000 美元），而且并非所有工程师都需要它们，因为并非所有固件工程师都从事 SCSI 协议工作。当产品进入测试实验室时，大多数 SCSI 协议问题都已解决，因此实验室只需要这些专用测试仪中的一个，主要用于固件回归测试。

然而，尽管我们拥有所有专门的测试，但我们一些最重要的测试是在商业 UNIX 系统上完成的，令人惊讶的是，这些测试是通过使用标准 UNIX 实用程序（如 dd、tar 和 mt）编写良好的 C shell 脚本完成的。我猜想，过去至少一半的固件问题是通过在 UNIX 系统上运行这些脚本发现的。Linux 拥有所有这些实用程序，以及各种 shell。在商业 UNIX 系统上运行的相同 shell 脚本可以轻松移植到 Linux，并保持相同的功能。这意味着您可以使用一些运行 Linux 的低成本 PC 来补充您实验室中昂贵的商业 UNIX 系统。仅此一点就使 Linux 成为 SCSI 测试领域中强大的竞争者。

走进正在测试 SCSI 设备的实验室，您通常会在连接到 PC 的单个 SCSI 总线上看到几个设备。一次测试多个设备当然很重要；然而，让三个或四个以上的设备在同一测试下运行很少有意义。即使您完全填充了 SCSI 总线，如果一个设备一夜之间挂起，有时也会挂起 SCSI 总线，从而阻止其余设备继续运行。在这种情况下，您连接了其他六个设备也无关紧要。更好的做法是连接第二个甚至第三个 SCSI 控制器，并在每个控制器上运行不同类型的测试。这样，您可以更有效地利用系统，从而在相同的时间内完成更多工作。此外，如果一个测试发现了一个固件错误并且总线挂起，则其他测试可以继续进行。然而，DOS 不是一个多任务操作系统，如果您希望在每个 SCSI 控制器上运行不同的测试，您将不得不将所有这些复杂性添加到您的测试中。好吧，我从未见过这样做也就不足为奇了。调试复杂的 SCSI 测试已经够难了，不知道故障是由于测试还是设备造成的。向测试添加额外的复杂性肯定会占用固件工程师的时间，他们将不得不调试可能最终证明是测试问题而不是驱动器固件问题的问题。另一方面，Linux 没有这种限制。您可以编写基本测试，将它们添加到您的 shell 脚本中，然后让操作系统担心多任务处理。如果一个测试由于设备挂起而失败，其他测试可以继续运行。

标准 UNIX 实用程序提供了高级功能测试，但是，为了完成测试套件，工程师需要对 SCSI 设备进行更精细的控制。发送任何 SCSI 命令（包括设置了非法位的命令）以及非法命令的能力是必须的。这是标准 UNIX 实用程序无法完成这项工作的一个领域，需要一种替代方法。不久前，我决定拥有一个 SCSI 命令库会很好，这样可以轻松编写测试，并扩展库本身。因此，我开始尝试 Linux 通用 SCSI 驱动程序，这似乎是最简单的方法，并且我最近在 GPL 下发布了这样一个库。libdat.a 包含几乎所有顺序访问 SCSI 命令，如果您需要其他命令，添加新命令非常简单。该库与一个名为 stt（SCSI 磁带实用程序）的磁带工具打包在一起，该工具基于 libdat.a。stt 为我在办公室的 Linux 工作站增加了强大的功能。我现在可以交互式地向磁带驱动器发送任何命令，以及重新编程驱动器和制作重新编程固件磁带。（最后两个功能已从 GPL 版本中删除。）这也是一个如何使用 libdat.a 和通用驱动程序轻松编写 SCSI 测试的示例。最重要的是，我现在发现为我的 Linux 工作站编写测试比为专有工具编写测试更容易。这是一个简短的 C 程序示例（未显示 #includes）

_Inquiry();      /* show device information */
_Space(EOD,0);   /* space to End Of Data */
_ReadPosition(); /* show current logical
                  * position */
_Space(FMK, -2); /* space reverse 2 filemarks */

虽然上面的程序没有做太多事情，但它确实显示了程序员编写测试的容易程度。stt 实用程序提供了一个基于 libdat.a 的功能齐全且有用的程序的更长示例。

您可能对当前的测试设置感到满意，但请考虑以下问题。如果您的操作系统功能更强大，您能做得更多吗？如果您可以编写 C 程序和 shell 脚本，而不是 DOS 批处理文件呢？如果您的测试系统完全联网呢？您可以将日志文件通过 Perl 过滤器进行格式化，并在您的内部网站上显示它们吗？您可以从您不必重写的标准 UNIX 实用程序中受益吗？当然，您可以从将多个控制器连接到您的系统并在操作系统处理多任务处理的同时运行多种类型的测试中受益。如果有一个通用的、易于使用的 SCSI 接口和库，让您可以完全控制您的 SCSI 设备并访问所有源代码呢？如果您可以在一个拥有丰富开发工具（包括编译器、调试器、版本控制系统等）的平台上进行开发呢？下次您考虑为您的 SCSI 测试选择平台时，请查看这些问题的答案，并帮自己一个忙。考虑一下，如果该平台运行的是 Linux，您还能做多少事情。

资源