这是百度内部团队，实际落地内容
上来就说别人显摆，承认别人优秀很难嘛。。。。

我们以前做技术优化，竞品数据比对的时候，就是测试去采集数据来着，各种启动呀、加载呀、响应呀，真心苦逼

首先是票价问题

不吹虚的，票价低廉代表成本有人分摊，而且我们确实都在尝试找联合主办的公司来分摊成本了，你们信嘛，我猜大家都不信。（如果大家有能对接来和社区联合主办的公司，可以直接介绍给我们也可以直接联系我）

那么关键问题来了，社区可以给企业带来什么？非常现实的问题，社区以及参会同学能为联合主办企业带来什么？
这是真实的企业问询，我也思考很久了没办法回答，社区同学们也可以一起开放性的探讨下，社区能带给企业什么价值。用于平衡企业的分摊成本。

落地问题

说到这块，不得不说一下，为了议题的高质量，也成立了 MTSC 技术委员会，每一个议题全是大家客观评选出来有借鉴、实践落地意义的。测试未来可能的发展方向在哪里？总得有先驱跑在路上！！！我们才有可能站在巨人肩膀上。

MTSC 大会正式的宣传，哪次不是会前一个月左右才正式进行宣传？有没有想过为什么这么晚？MTSC 大会的全新内容为什么又那么多呢？

这里我要为讲师喊冤，大会除了每年最多两个商业议题外，所有讲师全部是一线真实的，且司内落地实操的老师，而且很多熟悉的讲师也都是从以前社区沙龙的参与者变成了现在的内容分享者

说到讲师待遇好，我不太清楚这个结论是哪里来的，除了限额内的差旅费用外，剩余全部都是老师们自己负责的，而且每年有非常多的讲师为了节省大会成本，全部是向自己公司进行申请出差参会的。我们是非常感激老师们的付出的，看看其他类型的，逢年过节都给老师们送一些小福利，我很惭愧，我们做不到，因为穷。

如果有公司愿意联合社区做一起周边小福利，也欢迎联系！！！

大会的问题，请不要衍生到讲师身上，愿意出来分享内容，已经是讲师带给测试同学们最好的回报了。开始上升到讲师这块，已经过了。不过如果是讲师说我们福利好，我真是会谢，这是真爱啊！！！

打波广告

社区近期也做了几场线上技术沙龙，9 月中、10 月中也会分别有《生态质量保障、游戏测试》为主题的相关技术沙龙，欢迎同学们关注嘎。当然愿意分享内容的同学请联系我啊

嗯，这么好的技术沙龙，怎么就不值得关注呢~

感谢知识分享，已开通

我是觉着可以往好一方面来看：
1、产品使用手册编写
有些公司产品经理写，有些公司确实会由测试进行编写。
对于测试来讲，也是一个很好的梳理产品业务的机会，能够更全面的了解产品、熟悉产品。

其实应该也有许多测试同学兼顾实施工作，测试产品外，还要协助用户产品部署相关

2、客户答疑
测试有可能比产品经理更了解产品，是除产品经理外最合适对接用户的群体了，可以更直观的了解用户诉求，与用户进行深入沟通。
快速了解用户对产品的评估，同时也是获取线上问题的重要手段。
当然用户会有非常多类型 的问题，这块最好是做区分，系统问题可以由测试来进行、主导

我们以前 QA 每天都会，收集和确认线上用户反馈的系统问题。收集并汇总分析这些数据，也是用户对于产品功能接受度的一个重要衡量标准

当你对产品了解够深入，又非常善于挖掘用户需求的情况下，在整体产品线中，你就是业务专家，可以尝试向业务负责人方向发展，当然也可以尝试转向产品经理岗位哦，一切也都顺势而为嘎

感觉 社区后面可以成立一个这样的节点，试着运营运营，组建一个由社区同学组成的众测平台，尝试接取一些外包项目之类的

简单直白点来讲，就是初、中级开发

1、测试推送服务功能正常，确保已正常调用各推送渠道。
2、推送测试就是通达自动化脚本来触发各类型推送，然后人工测试

没有做推送到达手机的自动化，就像 2 楼说的那样，推送是延时性的，而且各推送渠道也不一样，所涉及的设备是不同的，而且 我记得是 vivo 还是 oppo 对推送条数也有限制

我们以前只自动化检测了推送服务链路跟踪，检测功能是否被调用，推送结果这个记不太清楚了，但好像也是有标记的回信的

每次上线前也会测试一下各渠道的推送功能，这块我们是找开发配合，将推送功能封装成服务，测试这边调用 api 进行指定设备触发测试

https://junit.org/junit5/docs/current/user-guide/index.html#writing-tests-parameterized-tests

刚学习出来，建议你工作一段时间后，再回过来看这个问题
比如：
培训中学习的自动化，应用于工作中了嘛？效果如何呢？

公司的业务、测试流程是什么，在这个过程中，你觉着哪些能够和可以自动化？
学习路径是根据实际业务来的

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

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

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