周报在我看来，一方面是对一周工作的总结复盘，另一个方面是给上级看，简洁明了即可。我之前写都是做了什么模块的功能测试、回归测试这种，感觉很含糊，再回顾的时候都有点忘了自己做了啥发现了哪些缺陷，但是也不能像开发一样做了哪些功能这种把缺陷列出来，这种又太繁琐。所以想请问一下大家都是怎么写的，以及以什么思路来写。
那就写执行了多少用例、回归了多少 bug，产出了什么文档或者其他什么，把自己的工作量化出来
沫沫sir
回复
我们不写用例 orz，产出文档有写，回归 bug 数量我在犹豫，因为之前看到论坛里有说不要把缺陷数量化这种类似 kpi，我担心写了之后上级会盯这个数量
不写比较好
- 在测哪些项目
- 项目测试进度（不要就一个抽象的进度 xx%；而是 “执行用例数 + 已花费时间 + 剩余用例数”，最后折算出整体进展 xx%，并得出还要多久才能测完）
- 有什么风险（数据构造？研发不配合？测试环境没 ready？工作量太多？）
- 是否需要支持（加班？摇人？延期？）
如果手头有一些什么专项，比如自动化，也可以按照类似上面的思路去写，但是要换成一些关键的统计指标，比如计划这个季度覆盖 xx 场景自动化，实现 xx 条用例，实际写了 xx 条。
发现了什么缺陷等等酌情写，如果是零碎的东西写进去没信息量，没人看，如果是通过这个 bug 去表达项目测试困难或者其他实质的问题，那是可以写的。
不写比较好
王稀饭
回复
感谢大佬的回复。先大概说下我的情况，我是公司第一个测试还是新人测试，目前也没什么正规测试流程，基本就是开发做完我来测，主要还是业务功能测试，有时候也不止做测试的活。关于项目进度，我们现在是不写测试用例，所以只能说用了多久，用回归的缺陷数代替行不行，又担心上级盯这个数量；有什么风险主要还是我一个人有时候忙不过来，测试环境没 ready 这点我很困扰，开发还在做的时候我一般没事干，想补测试的知识感觉又很多不知道从哪里下手，上一个项目里用到了压力测试，囫囵吞枣的看了些教程做了压测出了报告，也是形式大于内容（甲方需要）；是否需要支持，也只能加班了没办法。写周报一方面是为了自己复盘，还有一个为了年底提加薪，以及开发们都写我不写好像不是很好
我们的周报是在哪些项目或需求上用了多少时间
第一个测试，太爽了
1、可以考虑建立提测标准；开发自测到什么程度，才能达到提测标准；前期你可以写冒烟测试用例，开发慢慢接受之后，就让开发自己写，自己做
2、一定要写测试用例；描述好测试点，前置准备、执行步骤、检查点等，用例要评审，这样用例没有覆盖的部分，出现 BUG 你就不是主责，对测试结果，最好留存截图，防止甩锅
3、BUG 数量是一定要提的，这个是测试工作价值最直观的体现，你是第一个测试，公司也在观察你这个岗位的价值，作为公司第一测试，统计所有需求/BUG，计算出一个需求平均产生多少 BUG，以后测试工作完成后，根据平均值算下，低于的，就需要回去再看看
4、建立 BUG 等级（BUG 质量），可以抄网上同类型公司相关 BUG 的等级（一般根据上线之后，触发 BUG 造成影响划分）
5、建立用例留存，防止相关功能改动，测试不是原负责人，抓瞎
6、尝试建立自动化体系；先用现成 Jmeter，Postman（后期购买或自研），快速回归，划分上线核心场景（上线必回归）
《因为之前看到论坛里有说不要把缺陷数量化这种类似 kpi，我担心写了之后上级会盯这个数量》，先确认里 BUG 等级，根据等级去列出数量，有问题就和领导沟通，消除疑惑，不用防着他，前提他是个正常人，好沟通
MT
回复
情况还有点特殊，那我尝试换位思考一下，从开发和开发老板希望从你那里获取什么信息。
- 需求什么时候能测完，什么时候能上线
- 需求的 bug 多不多，解 bug 需要花的时间会不会阻碍上线
- 这次的需求测出来问题很多，有没有办法让下次差不多的需求没那么多问题
- 上线的需求有很多 bug 反馈过来，以后能不能再也没有这些反馈
- 除了基本需求测试外，你还有没有什么额外的测试产出
就只能从这些角度去写；3、4、5 其实很抽象，靠你自己去想。1、2 比较明确
要是刚毕业的问这问题 OK,
工用一两年了 还问这问题
说明都不会向上管理，或是不懂领导要你汇报什么，只要懂点项目管理都明白咋写
那拿低工资也是很正常的事
如果你是第一个且唯一的测试，那建议你循环渐进，一开始不要做得很好，毕竟你的同事和领导们也不知道测试的周报是怎么写的。
第一期： 只写自己完成了什么任务
第二期：加上量化或者一些能改进测试效率的计划 (可以提前做，然后再慢慢体现在周报上)
第三期：就跟五楼说的那样
每期间隔半年或者三个月，反正一开始不要太完美，同时每一期观察下领导和同事的反应。其实把自己看轻些，你没那么重要，他们只是按部就班的叫你写而已，还没出事前不会期待你这边能交出什么成绩
青蛙
回复
感谢大佬回复。1.因为公司之前是没有测试的，所以开发有自测的习惯，不过提测标准大佬可以举个列子嘛？这个我还没研究过，都是他们做好我就测。
2.关于测试用例，现在这个阶段应该是弄不了，项目急人也少，上级对测试用例的态度不是很重视，我们是纯敏捷。
3.bug 数量，统计所有 bug，这个目前而言还做不到因为系统还在开发，等系统上试试，以及请问什么叫一个需求，是指一个功能嘛？
4.关于 bug 等级，目前我是用在提 Bug 的时候，一些重要的 bug 标高优先级这样。是大佬说的这个意思的话，等项目上线后再看看。
5.和 2.一样
6.自动化体系，就我目前而已，在上个项目用 postman 写小 demo 做过回归，用 jmeter 做过接口压测（试试水），自动化体系是个大工程后面再慢慢学习怎么建立体系（目前确实没时间做 orz）。
王稀饭
回复
谢谢大佬，对于 1 和 2，我有个疑惑就是，测出问题让开发改，这样的话测试的时间就不能确定了，新项目很多功能都是新做的，可能一个功能出了问题让开发改好我再测又有别的问题，开发改的时间我也不能确定，这样怎么算时间？
MT
回复
你需要事先让开发去评估工时，如果对方是一个工作多年的开发，他应该对 bug 解决有基本的耗时评估。
我们也先不用管他评估得准不准，反正是开发说的，到时候你计算出来结果被别人质疑（比如为什么评估要这么久），你可以说是开发给的解决工时就是这么久。这样也能倒逼开发去认真看待评估这个事情
，感谢
测开周报怎么写呀 要写发现 bug 数量和严重度吗
MT
回复
1、冒烟测试就是主流程走的通，例如登录注册页面测试；最起码新注册（或登录）一个账号流程走的通过
2、测试用例这个事，还是要写的，毕竟你不能在这个公司呆一辈子，还是要考虑以后的，这个也是对自己能力的一种提升
3、不同产品，有不同风格，所以需求有大有小，例如登录时候加一个可勾选的用户协议算一个需求，也有整个登录注册模块也算一个需求；
4、没有问题，标准最好对齐下，避免开发有疑问，对高优先级的 bug 不上心
6、都挺好，分享一个很好的思路：尝试用代码实现你想的自动化形式，尝试有什么思路都用代码实现
青蛙
回复
嗯嗯，好的，关于代码，之前学了下 selenium 和 pytest 写了几个小 demo 试试手，真正用起来还是很困难的，随之弃。很多东西学起来好像没多大用，就很难坚持下去
你是第一个测试的话，那就是什么规范和流程都没有，所以，最好的话，就是慢慢的建立起来测试的流程和规范。给一个建议，就是一定要加入写测试用例的流程，这个流程其实是双向的，可以给开发和产品看，然后也可以检查有没有需求遗漏。功能完不完善，都是很好的。然后周报的话，就看周报的目的是什么，本身就是同步项目进度的话，那就写一下这周大概干了什么，然后这周测的项目大概的进度就行了。
