周报在我看来,一方面是对一周工作的总结复盘,另一个方面是给上级看,简洁明了即可。我之前写都是做了什么模块的功能测试、回归测试这种,感觉很含糊,再回顾的时候都有点忘了自己做了啥发现了哪些缺陷,但是也不能像开发一样做了哪些功能这种把缺陷列出来,这种又太繁琐。所以想请问一下大家都是怎么写的,以及以什么思路来写。
那就写执行了多少用例、回归了多少 bug,产出了什么文档或者其他什么,把自己的工作量化出来
我们不写用例 orz,产出文档有写,回归 bug 数量我在犹豫,因为之前看到论坛里有说不要把缺陷数量化这种类似 kpi,我担心写了之后上级会盯这个数量
不写比较好
如果手头有一些什么专项,比如自动化,也可以按照类似上面的思路去写,但是要换成一些关键的统计指标,比如计划这个季度覆盖 xx 场景自动化,实现 xx 条用例,实际写了 xx 条。
发现了什么缺陷等等酌情写,如果是零碎的东西写进去没信息量,没人看,如果是通过这个 bug 去表达项目测试困难或者其他实质的问题,那是可以写的。
不写比较好
感谢大佬的回复。先大概说下我的情况,我是公司第一个测试还是新人测试,目前也没什么正规测试流程,基本就是开发做完我来测,主要还是业务功能测试,有时候也不止做测试的活。关于项目进度,我们现在是不写测试用例,所以只能说用了多久,用回归的缺陷数代替行不行,又担心上级盯这个数量;有什么风险主要还是我一个人有时候忙不过来,测试环境没 ready 这点我很困扰,开发还在做的时候我一般没事干,想补测试的知识感觉又很多不知道从哪里下手,上一个项目里用到了压力测试,囫囵吞枣的看了些教程做了压测出了报告,也是形式大于内容(甲方需要);是否需要支持,也只能加班了没办法。写周报一方面是为了自己复盘,还有一个为了年底提加薪,以及开发们都写我不写好像不是很好
我们的周报是在哪些项目或需求上用了多少时间
第一个测试,太爽了
1、可以考虑建立提测标准;开发自测到什么程度,才能达到提测标准;前期你可以写冒烟测试用例,开发慢慢接受之后,就让开发自己写,自己做
2、一定要写测试用例;描述好测试点,前置准备、执行步骤、检查点等,用例要评审,这样用例没有覆盖的部分,出现 BUG 你就不是主责,对测试结果,最好留存截图,防止甩锅
3、BUG 数量是一定要提的,这个是测试工作价值最直观的体现,你是第一个测试,公司也在观察你这个岗位的价值,作为公司第一测试,统计所有需求/BUG,计算出一个需求平均产生多少 BUG,以后测试工作完成后,根据平均值算下,低于的,就需要回去再看看
4、建立 BUG 等级(BUG 质量),可以抄网上同类型公司相关 BUG 的等级(一般根据上线之后,触发 BUG 造成影响划分)
5、建立用例留存,防止相关功能改动,测试不是原负责人,抓瞎
6、尝试建立自动化体系;先用现成 Jmeter,Postman(后期购买或自研),快速回归,划分上线核心场景(上线必回归)
《因为之前看到论坛里有说不要把缺陷数量化这种类似 kpi,我担心写了之后上级会盯这个数量》,先确认里 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,我有个疑惑就是,测出问题让开发改,这样的话测试的时间就不能确定了,新项目很多功能都是新做的,可能一个功能出了问题让开发改好我再测又有别的问题,开发改的时间我也不能确定,这样怎么算时间?
你需要事先让开发去评估工时,如果对方是一个工作多年的开发,他应该对 bug 解决有基本的耗时评估。
我们也先不用管他评估得准不准,反正是开发说的,到时候你计算出来结果被别人质疑(比如为什么评估要这么久),你可以说是开发给的解决工时就是这么久。这样也能倒逼开发去认真看待评估这个事情
测开周报怎么写呀 要写发现 bug 数量和严重度吗
1、冒烟测试就是主流程走的通,例如登录注册页面测试;最起码新注册(或登录)一个账号流程走的通过
2、测试用例这个事,还是要写的,毕竟你不能在这个公司呆一辈子,还是要考虑以后的,这个也是对自己能力的一种提升
3、不同产品,有不同风格,所以需求有大有小,例如登录时候加一个可勾选的用户协议算一个需求,也有整个登录注册模块也算一个需求;
4、没有问题,标准最好对齐下,避免开发有疑问,对高优先级的 bug 不上心
6、都挺好,分享一个很好的思路:尝试用代码实现你想的自动化形式,尝试有什么思路都用代码实现
嗯嗯,好的,关于代码,之前学了下 selenium 和 pytest 写了几个小 demo 试试手,真正用起来还是很困难的,随之弃。很多东西学起来好像没多大用,就很难坚持下去
你是第一个测试的话,那就是什么规范和流程都没有,所以,最好的话,就是慢慢的建立起来测试的流程和规范。给一个建议,就是一定要加入写测试用例的流程,这个流程其实是双向的,可以给开发和产品看,然后也可以检查有没有需求遗漏。功能完不完善,都是很好的。然后周报的话,就看周报的目的是什么,本身就是同步项目进度的话,那就写一下这周大概干了什么,然后这周测的项目大概的进度就行了。