来个框架介绍啊，这个就是个命令的手册 哦

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

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

首先是票价问题

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

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

落地问题

说到这块，不得不说一下，为了议题的高质量，也成立了 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 恤，和小礼物，放到社区积分商城中，小伙伴们可以积分兑换
因为积压的比较久，才翻出来。。。。不计成本，出给社区的大妈、大爷了 抵扣一些积分商品的邮费

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

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