我是参与测试任何协议 (TAP) IETF 组的人员之一（如果有兴趣，请随时加入邮件列表）。许多编程语言开始采用 TAP 作为他们的主要测试协议，他们希望从中获得比我们目前提供的更多的东西。因此，我们希望从具有 xUnit、TestNG 或任何其他测试框架/方法背景的人那里获得反馈。
基本上，除了简单的通过/失败之外，您还需要测试工具提供哪些信息？只是给你一些例子：
- 文件名和行号（如果适用）
- 开始和结束时间
- 诊断输出，例如你得到的和你期望的之间的差异。
等等 ...
Ovid
问问题
2032 次
10 回答
7
绝对是您列表中每个项目的所有内容：
- 文件名
- 电话号码
- 命名空间/类/函数名
- 测试覆盖率
- 开始时间和结束时间
- 和/或总时间（这对我来说比前两项更有用）
- 诊断输出，例如你得到的和你期望的之间的差异。
从我的头顶上看，除了我想知道的一组测试之外，别无他求
- 团队名字
- 总执行时间
于 2008-09-18T11:10:01.780 回答
6
任意一组标签 - 所以我可以将测试标记为，例如“集成、UI、管理员”。
（你知道我会要求这个，不是吗:-)
于 2008-09-18T22:43:35.717 回答
6
编写测试必须非常非常容易，并且运行它们同样容易。对我来说，这是测试工具最重要的一个特性。如果有人必须启动 GUI 或跳过一堆圈来编写测试，他们不会使用它。
于 2008-09-18T11:05:10.810 回答
4
你说的我要补充：
- 方法/函数/类名
- 覆盖率计数工具，有例外（不计算这些方法）
- 最后 N 次运行的结果可用
- 要求必须存在轻松解析测试结果的方法
于 2008-09-18T11:09:01.800 回答
4
任何类型的诊断输出 -尤其是在失败时都是至关重要的。如果测试失败，您不希望总是在调试器下重新运行测试以查看发生了什么 - 输出中应该有一些包含。
我还希望看到关键系统变量（如可用内存或硬盘空间）的前后快照，因为这些也可以提供很好的线索。
最后，如果您在任何测试中使用随机种子，请将种子写入日志文件，以便在必要时可以重现测试。
于 2008-09-18T16:56:34.693 回答
1
能够识别单个测试的唯一 ID（uuid、md5sum）——例如，用于在数据库中插入测试结果或在错误跟踪器中识别它们以使 QA 可以重新运行单个测试。
这也可以在产品的多个修订的整个生命周期中跟踪单个测试的行为，从构建到构建。这最终可能允许在“历史”事件（新员工、产品发布、硬件升级）和因此类事件而失败的测试配置文件之间建立更大规模的关联。
我还认为 TAP 应该通过专用的侧通道发出，而不是与标准输出混合。我不确定这是否在协议定义的范围内。
于 2008-12-03T21:16:01.193 回答
1
我想要连接和嵌套 TAP 流的能力。
于 2008-09-20T17:09:04.560 回答
0
可选的 ascii 彩色输出，绿色表示良好，黄色表示未决，红色表示错误
事情悬而未决的想法
将运行各个测试的命令的测试报告末尾的摘要，其中
项目清单
出问题了
测试中的某些内容未决
于 2009-12-06T15:54:20.310 回答
0
我使用 TAP 作为一组简单的 C++ 测试方法的输出协议，并且看到了以下缺点：
- 测试步骤不能分组（只有分组到几个测试脚本中；但是为了在我们的软件中运行所有测试，我至少需要一个级别的分组，以便单个测试步骤可以通过“数据库连接”来标识" -> "重新连接测试" -> "测试步骤 #3")
- 查看预期输出和实际输出之间的差异很有用；我要么将差异打印到标准错误（作为评论），要么实际启动图形差异工具
- 协议和工具必须真正独立于语言。例如，目前我只知道运行测试的 Perl “证明”工具，它仅限于运行 Perl 脚本
最后，测试输出必须适合作为轻松生成 HTML 报告文件的基础，该报告文件非常简洁地列出了成功的测试，给出了失败测试的详细输出，并且可以快速跳转到 IDE 到失败的测试行。
于 2008-11-19T17:03:31.457 回答
0
TAP 的扩展思路：
1..4
ok 1 - yay
not ok 2 - boo
ok 3 - yay #json:{...}
ok 4 - see my json
能够附加 #json 注释... - 可以安全地被现有代码忽略 - 可以在 testanything.org 上轻松保留定义明确的标签 - 易于生成、解析和读取复杂类型 - yaml 很痛苦
于 2015-01-07T16:31:31.337 回答