https://testerhome.com/topics/32042
https://testerhome.com/topics/32723
我建议有些内容，可以参考下这两篇文章，但是一般情况下线上出问题后，首要责任人确实会是测试，但不同的情况确实又有不同的处理方式

个人建议：
1、每个版本整理个需求列表
2、每个版本的用例拉大家一起评审下
3、每次上线后，做个总结
总结的好外，可以归类问题产生原因，比如你提到的：
这个为什么做成这个样子和我的需求完全不符？
是否为本次需求，而且在未影响这些功能情况下，确实不会进行回归测试
同时要求提供些功能的需求文档，进行确认，并要求开发同时确认当时开发情况
如果产品说这个功能全不对，那么就进行排期开发，修改功能

下午客户来验收，现在还一个劲的加新需求
将问题拉会讨论，要求开发同时表态，这种 情况开发很难完成，同时提测质量又不高，还可能影响已测试完成的功能
完全严重影响客户验收，请产品在每次提需求时，梳理 清楚本次上次内容，在进行测试时，不允许添加新功能

其实还是要推进流程 规范

图裂了，楼主修复下吧

这种还真没有碰到过，你换个 Charles 看看能不能抓，看下抓取 https 有没有配置
如果没有调置 ，确实是抓 不了 https 请求的

没头没尾啊，请把问题描述清楚一下吧，为什么需要修改

是前几年的衣物，实在是不太好送给大家，后面我们也会定制一批十周年 T 恤，和小礼物，放到社区积分商城中，小伙伴们可以积分兑换
因为积压的比较久，才翻出来。。。。不计成本，出给社区的大妈、大爷了 抵扣一些积分商品的邮费

这种情况下要与不仔细负责的人员进行沟通的，需要正事这个问题，进行横向对比，所有交叉测试发现的缺陷，可以做为为测试遗漏，同时进行用例复盘，建议进行问责以及淘汰

还有这种群？你说的是不是以前深圳沙龙的活动群呀。。。。。

如果说测试工作效果的话，我们一般会有这几个度量指标：
1、用例完整度 、评审通过率
2、系统测试期间缺陷率
3、功能测试按时完成率
3、上线缺陷率

但这些指标的完成度，又和项目各个阶段又有关系，同时也会对项目其他阶段的一些内容进行管控：
1、需求变更次数（改动较大，或当出现需求歧义时，产品无法快速理清的，推动干掉）

在研发需求分析期间，允许需求变更可能性会大一些，但只要进入开发阶段后，需求变更通过率我们会控制的很低。

2、研发计划（所有的测试时间，都会根据研发计划进行，要求其所有功能全部迭代陆续进行提测）

我们同时也会控制研发计划的变更 ，开发同学只要产品找来说改东西，一般都会接受，但未考虑后续流程是否有影响 ，我们会拒绝所有开发自接的需求，所有需求必须走需求变更

3、功能提测（跟进并推进研发开发进度，确保研发能如期提测）

所有不能如期提测的功能，功能测试只能延后或者进行计划调整

4、缺陷修改周期（严格控制缺陷响应、修改时间，所有超出约定的时间后，测试会进行测试计划调整，项目计划变更）

5、风险控制（研发或测试进度出现严重风险）

周知项目，安排加班或砍需求，推进闭环。
加班可以加，但是项目需要知晓为什么加班解决了，

6、资源日历（人员工作量情况，人员分布 情况）
记录所有资源分布情况，当出现强加需求或者无法拒绝需求时，与大家一起调整资源日历

当然这样的话，测试做的事情会有些多，像以前团队就负责了需求管理、计划管理、进度管理、风险管理，最终上线日期其实也是测试根据各种计划给出的。（当然固定发版日项目，所有计划全部向上逆推）

上面说了，粗暴呀，而且也说了，要明确标准和流程 才行呀。

8 个开发 2 周，工作量得有多大？
在没有数据、流程支持下，测试时间是不是要最大化？（上线不只是单单 功能测试完就上线了吧，集成、系统测试、上线验收这些都不要时间嘛？）

为什么会被怼，只能说明没有证据证明为什么用这么长时间才是关键，当然这就又回归原点了，没有标准和流程 。

功能或者接口不占用工作量，这不应该是一个测试会说出来的话，这些要不要测试，既然要测试为什么不算工作量呢？

被人怼不可怕，这是催进成长的一部分，如果当有理由和证据说明就需要 5 周，谁来怼，就一句，质量出问题你负主责，我 ok

首先要确保测试是否有了标准的测试流程，需求到上线所涉及的流程是什么？
1、 8 个人做了 2 周，粗暴的统计一下功能测试时间：
研发时间 = 8*2*5*8 = 640 个小时
测试时间 = 研发时间 /2 = 320 个小时
测试天数 = 320/8/2/5 = 5 周

如果需要 5 周的时间做功能测试，有多少个测试阶段，那么每个阶段都需要时间。 继续往上加呀

2、我理解的是，在开发过程中，测试的精力一般也都在需求分析、用例编写、用例评审、测试场景准备中。空闲时间也不会太多的。如果很空闲，就和你上面所述描述不一致了。

测试是可以每天跟进开发进度，和开发协商功能提测，提前介入功能测试阶段

3、项目负责人从哪些方面压缩测试时间呢？并没有描述这块内容呀。。。如果我是负责人，核心点你没有说清楚 ，我也会压缩你呀.

缩减测试时间，那么是否接受测试质量差？
不接受测试质量差，那么测试为什么不压缩开发提测时间呢？
接受不了测试质量差、开发接受不了压缩提测时间的话，那么部分功能的质量为什么不可由开发负责。

其实根本原因在于，你们应该没有标准的测试流程，资源分配应该也没有资源日历用于查看资源工作量情况，建议先完善测试流程，对于资源进行管理，这样才会有标准的数据，以证明测试工作量，测试工时，用于向负责人证明，测试资源不够，测试工作量过大等等

只能给公众号发下，才能看到，后台邮寄的地址可以，没办法对接给你，你丢个图到公众号，公众号可以推给你微信

审核的时候有的不小心点了审核拒绝，优惠码未使用完时，默认都有效，请无视这个操作，直接发图就行

大家要给公众号发消息，索要码啊
没办法通过后台自动
发给大家呀。。。。

感觉有些跑偏了，楼主应该是偏业务方向测试的同学或者刚转行的同学
自己说自己点点点，这个明显有些妄自菲薄，我觉着这样是不对的，每个领域专精不一样的，所以工作重点也不一样，不能一概而论

说白了，市面上 80% 左右的公司，都是在做业务测试的，虽然很多公司都要求各种语言、技能之类的，但业务测试能力还是会放在第一位的，其他的测试技术是可以学习补充 的。

最近工作难找，疫情也是主要原因，不要太心急，工作机会少，可以看一些测试类视频和资源，补充 一下

正好也借机会梳理 一下未来个人发展~~

新同学感觉还是有些浮躁，做测试嘛，百屈不挠、没皮没脸。
想请教东西，心态还是平和一些的好

怎么说呢，不过我觉着万事可以先往好的地方想，从测试转向开发，也是一个好的方向和出路。
第 1 点来看，你应该是有一定的 java 基础的，能够编写 java 代码进行增删改查。
后端开发做的事情，其实和你是一样的，不外乎就是数据库表的删改查，只不过开发用的框架更多更杂一些，了解和学习下这些框架，应该是可以很快上手的。

内部转岗成功，未尝也不是好事。加油
就算后面又转回测试，但你有开发经验，也是加分项的，怎么算都不算吃亏

回复测试

我帮你改了~

接口可以理解只是服务端对外展示的一部分。
服务端构成相对来说，还是较为复杂的，spring 也有非常多的组件，很多我们看到的接口都是组件包装后的结果。
从架构层面来讲，又可能涉及到熔断、限流、降级、缓存、穿透、改写、异常保护等措施
接口测试过程中，可以将测试内容上升至架构层面开始，能够更加全面的了解服务端处理逻辑
不能指导研发进行接口开发的，不是好的接口测试

这里分为两种情况：
1、后端接口进行数据加工后，传递到前端，前端直接显示
2、后端接口直接将原始数据，传递到前端，前端加工后再显示

我理解现在是第二种情况，（不过建议还是要和开发确认清楚，很多公司对于这块区分理解是不一样的，划重点和开发确认）

当成正常的功能测试验证就可以了，所有的数据展示，就按照前端处理逻辑进行测试即可。（测试用例编写时应该与前端开发进行逻辑确认，接口开发进行原始数据确认）

同时也可结合接口文档，构造接口返回原数据，配合 Fiddler、Charles 改变返回值，进行前端其他逻辑覆盖验证

我们以前一般会根据自己的经验罗列一个影响范围，再找开发要一个影响范围，结合这个拉出一批测试用例。（当然这个范围是要项目组同学共同认可的，后面有其他歧义的时候再做查缺补漏）
如果要再细的话，就做代码版本 diff，但一般来讲没有这个必要，这个阶段进度就比较靠后了。

明天发出，6 号的时候，刚发了一波