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

如果说测试工作效果的话，我们一般会有这几个度量指标：
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 号的时候，刚发了一波

转行做测试，有几点需要考虑一下：
1、年龄问题 （工作经验，虽然现在有非常多的手段来填补这个，但真实面试过程中，工作能力需要年纪相匹配）
2、学历问题 （非常现实，大部分公司要求是本科起）
3、沟通能力 （现在除了必需具备的能力外，很多公司都会考虑个人沟通、应变处理能力 ）
4、自我预期 （做这一行，不代表真的比其他行业赚很多钱，尤其是测试，除非真的能精在一个领域上面，或者入职公司比较大，给的比较多）

pmp 项目管理 那本书

@fishfish-yu 我是社区的徐士钊，老师能留人微信嘛

测试环境是否独享资源，建议先和团队成员以及运维同学确认一下吧

我们基本和你这个一样，测试环境就是走 mock 或者沙盒测试，正式环境会针对特定测试账号生成一个支付订单，只要有支付链接回调，就默认接口没问题。
但是每次发版后，我们会使用这个账号进行一次真实订单支付，验证一次支付流程

每个公司不同阶段诉求不同，公司业务所需技术也不同，我理解没办法一概而论
现在外面都在抄一个概念，市场不景气呀，行业不景气呀，都在裁员，掌握了各种 各样技术就不会被裁之类的
但在公司中，就会发现，裁员和具备什么技术不能说毫无关联，只能说只有一丁丁关系
主要还是看的公司业务形态，对于现有团队规模的调整方式，以及测试团队在部门中的占比。

比如：
1、部门要求整体裁员 15%，人数一平均，各个团队分一分，有需要换新血的就借这个机会换一波，当然在测试人员本身就不够的情况下，是有可能不对测试进行裁员的
2、业务稳定，没有过多测试任务，公司确实会倾向于保留有自动化能力的同学
3、业务不稳定，资源严重不够，公司更愿意保留更熟悉业务的同学
4、在无法平衡的情况下，更愿意保留，平时在团队中担事，解决问题的同学

除了废开发外，就全剩收益了呀，定位方便，跟踪方便~

社区版会一直免费