测试部门是我公司的新部门，因此我正在尝试建立一些测试报告政策。我们从开发一套回归测试开始，这将有利于程序的长期稳定性，但我不希望通过这种方式捕获太多错误，所以我担心测试结果一开始会很无聊和。我们有一个敏捷的开发流程，每两周发布一个新版本的待测试程序。我担心一段时间后通过电子邮件发送测试结果会变得过于常规，并且这些电子邮件最终会被视为垃圾邮件而被忽略。我想将测试结果发布在内部 Web 服务器上，因为这将提供过去测试过和未测试过的内容的历史存储库，但我担心利益相关者会忽略这一点。
是否有任何最佳实践可以在正确的时间向正确的人提供有意义的测试结果，并保持良好的测试结果历史记录？
我喜欢在网上发布结果，然后只针对失败向利益相关者发送电子邮件。没有电子邮件意味着一切顺利。如果有人不确定或只是想看看运行了什么，则可以在线获得完整的结果集。
正如 TristaanOgre 在评论中指出的那样，测试人员需要更频繁的沟通来确保测试运行。我要补充一点，标题应该提到运行是否失败或通过，以便于分类到文件夹中。因此，对于测试人员来说，缺少电子邮件就意味着缺少测试运行。
除非有要报告的错误，否则测试结果对测试人员以外的任何人都毫无意义。至少，这是我的经验。为什么我需要知道我们每天早上发现的错误为零？作为一名业务分析师、开发人员等，这对我来说每天都没有用处。因此，利益相关者忽略它的事实实际上是意料之中的，不应该成为问题。
也就是说，历史仍然很重要，需要保存在某个地方，而不是向所有人广播。如果在运行测试时发现错误，开发人员可能想知道最后一次成功测试运行的版本/构建、日期和时间，以便他们可以查明可能导致错误的更改集。
包含以下内容的错误报告可能是有意义的：
1. 通过、失败和通过百分比的测试用例数量
2.失败的分析和分类：这非常重要。简要的故障分类有助于了解它是自动化问题、应用程序代码错误还是环境问题。如果大部分测试用例由于自动化/环境问题而失败，它会提醒我们自动化套件
3 的健康状况不佳。正如@Tristaan 指出的那样，让开发人员循环中的错误列表有助于让 DEV 了解bug的优先级和时间线
4.被bug阻塞的TC数量- 这再次可以帮助开发人员了解错误的重要性。如果一个 bug 阻塞了 300 个测试用例，不管它是一个微不足道的问题，都需要尽快修复。在这些情况下，您也可以添加 DEV 的经理
维护测试结果的历史记录也很重要。如果我想找到在过去版本中通过并在当前版本中失败的测试用例的增量，历史会有所帮助。我通常将测试结果按发布方式组织在一个共享文件夹中。
我喜欢将报告带回到几个基本问题。
这些问题的答案不是一成不变的，所以对我来说，只依赖于一成不变的报告风格是没有意义的。如果您一周又一周地通过电子邮件将相同的报告发送给相同的人，而不考虑正在完成的工作，那么是的，它可能会被忽略。我建议你做的是用一套测试报告风格武装自己，并在适当的时候把它们拿出来。
你正在做的事情会有所不同。理所当然地，您的报告应该改变以适应。如果你有一套回归检查，那就太好了。这些结果对开发团队以外的任何人都很重要吗？你还向谁报告？他们对什么感兴趣？
如果您正在做站立会议，那么您可以报告开发组需要在那里听到的任何信息（或者至少告诉相关开发人员您需要他们的时间）。
如果您要向项目经理或产品团队或任何人报告，请确保在开始测试之前与他们交谈以了解他们想了解的内容。报告一堆他们不关心的东西是没有用的（需要注意的是，这是他们不知道需要听到的信息）。
报告不一定是您在测试结束时所做的没有灵魂的枯燥乏味的工作。您不必每次都上交小说。举报方式有很多种。这里有几个。考虑一下您可能会使用这些的不同情况：
我相信你能想到更多。