从历史上看，在我们公司，即使没有发现任何错误，我们也会对测试脚本中的每个步骤进行截图。
我们现在正从瀑布方法转向迭代开发周期。
在过去的 6 个月里，我们一直在尝试使用思维导图的快速测试设计，而不是截屏，而是声明思维导图中的测试用例和管理电子表格是测试已经考虑和执行的证据。
我们认为，截屏并不能证明任何事情，实际上会浪费宝贵的测试时间。然而，人们认为思维导图或类似过程在日后被问及该测试时无法提供足够的证据，因此存在一些阻力。
我会很高兴获得与以下问题特别相关的建议或其他人的经验。无论哪种方式，我们都不打算购买录音工具。
请您说明您是为跨国公司、国家公司、地区公司还是初创公司工作。我们是小型的全国性公司，希望听取每个人的意见，但需要对我们可以实现和不实现的目标采取平衡的态度。
轶事：我为一家国有公司做过一个项目。测试由 Big Name 咨询公司之一进行和监督。他们的测试人员被告知要为每个测试步骤截取屏幕截图。他们放弃了这种做法，因为（1）它花费了太多时间，测试进度太慢；（2）我通过探索性测试发现了项目中 90% 的缺陷。
根据我的经验，收集正在执行的测试的证据（如屏幕截图）的要求是由您所在行业的法规驱动的。在测试军用航空电子设备 (MIL-STD-2167)、电信设备 (TL9000) 和上市公司 (Sarbanes-Oxley) 的财务报告时，我不得不收集证据。
在使用不受监管的软件时，不需要收集证据，通常也不会收集证据。（我不记得我们什么时候做的）
您可能需要检查是否需要在放弃之前收集该证据。否则，如果您不需要 - 那么这是您的商业决定。是否值得花时间收集通过测试的详细结果？你会知道你实际使用了多少次你收集的数据。根据我的经验，最好专注于收集失败测试的数据/屏幕截图，以帮助更快地诊断故障。
祝你好运。
我们在设计“好的”测试用例通过的样子后录制了一段测试视频，并将其放入共享存储中。之后，视频只会保持失败。这样我们就可以随时回过头来看看最初的良好运行是什么样的。
为了记录测试场景，我们使用带有基于文本的步骤的 wiki。我们的 wiki (FOSWiki) 具有版本控制功能，因此您甚至可以查看步骤如何随时间变化（以及谁进行了更改）。比共享驱动器上的文档好得多 - 超链接使导航变得轻而易举。FOSWiki 允许将图像附加到页面。链接到具有相关/相似场景和/或 bugzilla 的其他 wiki 页面是微不足道的。我们还使用（高度定制的）bugzilla（它也允许附加图像），但我们只在它有助于清除某些东西时使用它——在 95% 的情况下，文本就足够了。
我们是一家拥有敏捷流程和高可用性环境（100% Python）的国际公司，并拥有基于 Web 的应用程序。
如果我们从头开始，我们会选择 TRAC，它集成了 webSVN、wiki、bug 数据库，并在代码中添加了标记，以便在通过 webSVN 在浏览器中查看代码更改时创建指向 wiki 和 bug 数据库的超链接。它非常漂亮，免费/开源，但可惜我们的 bugzilla 和 wiki 太深了。但我们非常关注 TRAC 集成并考虑转换。