我们每周都要写周报，要汇报项目进度还要有一些思考，最近做了一个项目，问题很多，感觉很多都是开发并不认真导致的，一个 bug 反复改都改不好，而且不仅没改好，还导致了更严重的问题。让我们测试人员也比较累，感觉一个功能测过来测过去还是有问题。于是周报中反馈了项目问题较多，问题主要集中在哪一块，然后希望开发在修改时能多注意一点细节，争取上线时项目能给质量达标。然后我们负责人看见了，说要我以后统计一下 bug 类型，看看问题主要都出现在哪里？其实我的本意是想把项目存在的问题暴露出来，上线是否有风险。但是感觉这样说话好像有点得罪人了，心里很难受，想向各位前辈请教一下，测试该如何汇报工作，然后也不得罪人呢？
逻辑客观的事实，不带自己的主观观点。就比如你的负责人让你统计 BUG 数据一样，这是客观事实。你说的 “感觉很多都是开发并不认真导致的，一个 bug 反复改都改不好，而且不仅没改好，还导致了更严重的问题” 这个就是主观观点，这个是有问题的。
事先打好招呼：要统计哪些问题，事先打好招呼，让大家有个心理预期，也好准备查找根因（嗯，找好说辞）
对事不对人：不管什么原因，不要在周报上提及个人，表扬可以。
报风险，给方案：暴露问题和风险没有问题，最好能给方案。
- 反馈问题不带情绪，不指向个人，不怕自黑可以把人和自己一起来起来黑，我自己都黑，你就别 JJYY 了
- 分析问题根因，提出解决问题的办法，别抱着解决人的目的。。。
- 上升高度，让领导发起，开展类似问题排查总结，往什么 CMMI 之类高大上靠，规范项目流程，提高项目质量，顺便给领导找点事儿做（大概率会坑了自己，谨慎！）
- 用技术手段做点锦上添花的事，比如回归 bug 自动化，你们设置个提测标准，开发做完自动跑一下什么的，让领导觉得你有技术、有思考、会来事儿
然后这事儿就解决了。
1、2 楼说的已经比较充分了。
- 对事不对人，不定性，下结论；
- 分析问题原因，进行归类总结，测试本职工作（如果涉及此类问题的研发，难沟通、配合度低，可以重点标注此类问题，要求研发重点关注，具体是改进和提高，归属于研发经理职能）
- 短期、长期数据整理，用于佐证各类风险。（基于数据可以开展各类自动化相关活动）
既然是需要向上反馈，那么就是说明你看出了团队中的问题：
1、需要站在客观的角度，讲述一个事实，同时说清楚事实依据；
2、既然发现问题，那么就需要给出你认为可行的解决方案，供上面参考；
3、叙述事实，可以减少出现对应的人员名字（领导能通过你的事实，推断问题出在谁身上，不需要你指明）
前面说的都很充分了，就事论事就行。如果想有更亮眼的表现，可以提出对应的问题的解决方案，比如你觉得你觉得 bug 很多，是不是提测质量过差导致的，方案的话，可以考虑需不需要提高提测标准，要求研发自测更完善之类的。不得罪人的最直接的办法就是，让别人觉得你只是在正常工作，并没有刻意针对就行。
前面这些回复呀，我真的想喷，但是想想没必要，回答了半天儿，完全和人家楼主问的不一样，光嘴嗨！你们说了那么多，倒是给人家个例子呀
余霞成尔，夜无风雪
回复
不太 get 你的点，我理解 上面非常清楚 了
例子自己随便参考补充一下就可以了，如果内容都没办法扩展填充，真的没折，放弃吧
- 对事不对人，不定性，下结论；
本次 BUG 共 XX 个，经过分析共几类缺陷，各自占比，其中主要来源哪个模块哪个功能 之类的，模块缺陷分析
- 分析问题原因，进行归类总结，测试本职工作（如果涉及此类问题的研发，难沟通、配合度低，可以重点标注此类问题，要求研发重点关注，具体是改进和提高，归属于研发经理职能）
缺陷原因初步分析，什么原因导致，需求分析原因？代码逻辑原因？上层服务原因等等，每个公司都有自己的定义，根据定义进行统计汇总，没有的话就借这个机会生成这些定义。
问题原因也可以归属为：产品、研发、测试
- 短期、长期数据整理，用于佐证各类风险。（基于数据可以开展各类自动化相关活动）
拿多次版本数据，根据现阶段情况结合个人经验给出风险建议。
XXX 功能一直未提测，影响 XX 项目整体测试进度，如果在 xx 之前未能提测，项目有可能无法如期进行上线
由于 XXX 功能需求变更，研发重新调整开发计划 ，导致 XXX 功能还未进入开发， @ 产品 建议 XX 功能下个版本上线
XX 模块问题较多，质量较差，上版本由于功能需要，强制上线，导致用户投诉较多，本次版本建议延期上线此功能，待重新完整测试后，再进行上线
从各种角度去说明，由于问题而引起的问题啊。我们能解决的，我们不能解决的，都可以向上抛啊
楼上总结的很充分了，我说下自己的个人体会：
1、千万不要试图越级反馈，把你需要表达的反馈给直属领导，数据和理由给出来，积极参与就行；
2、这不是一蹴而就的事情，可能涉及多轮次沟通还未见任何成效，要做好心理准备；
3、做好自己的事情，多沟通多记录，免得最后引火上身；