我是"测试任何协议(TAP)" IETF小组的成员之一(如果有兴趣，请随时加入邮件列表)。许多编程语言都开始采用TAP作为其主要测试协议，并且他们希望从中获得比我们目前提供的更多的东西。因此，我们希望从具有xUnit，TestNG或者任何其他测试框架/方法学背景的人员那里获得反馈。

基本上，除了简单的通过/失败之外，我们还需要测试工具提供哪些信息？只是给你一些例子：

• 文件名和行号(如果适用)
• 开始和结束时间
• 诊断输出，例如我们得到的与期望值之间的差异。

等等 ...

解决方案

编写测试必须非常非常容易，并且运行起来也必须同样容易。对我而言，这是测试工具的最重要的单个功能。如果某人必须启动GUI或者跳过一大堆编写测试，那么他们将不会使用它。

在我们所说的内容中，我要添加：

• 方法/功能/类别名称
• 覆盖率计数工具，有例外(请勿计数这些方法)
• 最后N次运行的结果
• 要求必须存在轻松解析测试结果的方法

最肯定的是我们列表中每个项目的所有内容：

• 文档名称
• 电话号码
• 命名空间/类/函数名称
• 测试范围
• 开始时间和结束时间
• 和/或者总时间(对我来说，这比前两项要有用)
• 诊断输出，例如我们得到的与期望的差异。

从我的头顶来看，除了这些测试之外，我想知道

• 组名
• 总执行时间

任何类型的诊断输出(尤其是有关故障的诊断输出)都是至关重要的。如果测试失败，则不必总是在调试器下重新运行测试以查看发生了什么，输出中应该包含一些提示。

我还喜欢查看关键系统变量(例如可用的内存或者硬盘空间)的前后快照，因为它们也可以提供很好的线索。

最后，如果我们对任何测试使用随机种子，请将种子写到日志文件中，以便在必要时可以重现测试。

一组任意标签，因此我可以将测试标记为例如" integration，UI，admin"。

(你知道我要问这个不是吗：-)

我想要连接和嵌套TAP流的功能。

我将TAP用作一组简单的C ++测试方法的输出协议，并且发现了以下缺点：

• 测试步骤不能分为几组(只有几个测试脚本才能分组；但是要在我们的软件中运行所有测试，我至少需要再一层分组，以便可以通过" DB连接"来标识一个测试步骤"->"重新连接测试"->"测试步骤3")
• 看到预期产出与实际产出之间的差异是有用的；我或者将差异打印到stderr(作为注释)，或者实际启动图形化差异工具
• 协议和工具必须真正独立于语言。例如，到目前为止，我只知道用于运行测试的Perl"证明"工具，该工具仅限于运行Perl脚本

最后，测试输出必须适合作为轻松生成HTML报告文件的基础，该报告非常简洁地列出成功的测试，为失败的测试提供详细的输出，并可以快速跳入IDE到失败的测试行。

一个唯一的ID(uuid，md5sum)，该ID能够识别单个测试，例如，用于在数据库中插入测试结果或者在Bug跟踪器中识别它们以使QA可以重新运行单个测试。

这也将可能跟踪从构建到构建到产品的多个修订版本的整个生命周期中单个测试的行为。这最终可能允许在"历史性"事件(新员工，产品发布，硬件升级)与由于此类事件而失败的测试配置文件之间进行大规模关联。

我还认为，TAP应该通过专用的侧通道发出，而不是与stdout混合。我不确定这是否在协议定义的范围内。

• 可选的ascii彩色输出，绿色表示良好，黄色表示未决，红色表示错误
• 事物未决的想法
• 测试报告末尾的摘要，这些命令将运行各个测试，其中
• 测试中有待处理