我们是每天发报告

测试报告一般是上线前发，就是保证 bug 都已关闭，已达到上线标准，然后提示一下版本的风险等；测试总结一般是上线后做，如果有生产问题，会重点分析这些生产问题，没有的话就着重总结一下这次项目的整个过程中的一些优缺点。

这么夸张 好累

每次发版三十个 Bug 没改，十几个 UserStory 没有彻底开发完，你们应该不是这个情况吧
测试报告 测试总结 这是要写 2 份文档

你们是发版到生产还有 30 个 bug 没改？这样的质量上生产，这么虎的吗？还有每次这么多 bug 没改，是不是评项目的时间有问题

一般在大版本更新时才会出具测试报告（比如从 V1.0 升级到 V2.0 这种必须要有对应的测试报告，从 V1.0.0 升级到 V1.1.0，这种最好也要提供测试报告，像 V1.0.0 升级到 V1.0.1 就没必要了）。
测试报告应该是在发版前邮件发送项目经理，产品经理，开发经理及相关责任人，告知测试结果及已知风险，证明版本内容已经过测试验证，符合发布上线标准。说句难听点的，就是发布上线后出现问题，测试要担负一定责任。
测试发版后有必要的话，需要做测试分析总结，针对当前版本的测试密度、缺陷密度做数据统计，查漏补缺，为后续测试工作做提升改善。

是的，初创团队，问题一堆。

现在开发想法是测试出报告，线上有问题，报告没写就是测试担责，测试写了就是开发担责。这个做法很慌

前后发都有道理，发版前发相当于是发版决策的参考依据，发版后发是整个项目包括线上质量的总结。

估计你们开发想要发版前发，期望是达到发版决策参考依据的目的，那就发版前发呗。

小孩子才要做选择，领导说：发版前后的报告我都要

这事建议你和你领导好好聊聊，就算是为了抢占风口拼进度，你们这个做法也太粗糙了。应该要好好地做一下项目规划，你们可以设立一些大的时间节点，例如几月几号要正式上线对外公开这种，然后根据时间节点好好地规划一下你们的项目，而不是像你现在这样埋头瞎做，把这种质量不太过关的产品发到生产上去。

做成模板就可以了，把 story 和 defect 新建对应的图表，每天只要把最新的图表截图放上去，然后加上当天的重点，比如有什么阻碍，有什么风险，大概就是几分钟的事情

测试通过封包后

发布前叫测试报告，发布后叫测试总结。另外任务没完发布毛线。

前：发 “测试报告”，代表测试完成，同步风险；
后：发 “上线成功报告”，代表 上线完成了，验证没问题，不用回滚 。

就测试报告而言肯定是发版前发，因为是否发版是要参考最终的测试报告内的测试结果来进行评估的，如果直接发版了还测了干啥。

初创团队领导应该更善于做减法，而不是加法吧。不会取舍容易浪费资源。

感谢各位大佬指点。已经和几个负责人沟通了，先解决项目估时问题，把 Story 和 Bug 收敛起来，严格控制发版代码质量，借助 Jira 统计评估是否发版，当收敛到个位数，主流程回归 ok 情况下，出测试报告，澄清测试内容和遗留问题。

测试报告一般是个泛指，包括：
1、测试日报。反应每日测试执行进度以及质量风险，过程信息透明之用。
2、版本/迭代测试报告。上线前一般给出准出标准，以及质量数据即可，完整版可以上线后补充。质量数据有提测通过率、需求覆盖率、bug 修复情况、bug 趋势、测试执行完成率、bug 分布、reopen 率，还有一些上线前的 checklist（配置项审核、sql 变更申请、上线方案、回滚方案等）
3、产品质量报告。周期性与研发、产品一同复盘后输出，反应周期内版本质量情况、以及趋势；建议固定以月周期