应该是个 bug 我们跟进下 后面修复下

社区里大家分享的都是测试工具啊，你可以看看帖子先。就先不开放你这个问题了。
给你个方向，先了解自己团队，和公司对于你的诉求是什么？
在不知道诉求的情况下，所有动作都是偏离方向的。

一套持续集成平台、一个文件读取脚本，都可以说是测试小工具

来分享分享，测试工具平台搭建的心酸路程吧
能够用起来，就挺好的，加油

PPT 目前百度老师们还没有整理完，同步过来，收到后，第一时间推出

1、2 楼说的已经比较充分了。

• 对事不对人，不定性，下结论；
• 分析问题原因，进行归类总结，测试本职工作（如果涉及此类问题的研发，难沟通、配合度低，可以重点标注此类问题，要求研发重点关注，具体是改进和提高，归属于研发经理职能）
• 短期、长期数据整理，用于佐证各类风险。（基于数据可以开展各类自动化相关活动）

项目经理做什么取决于公司的赋能。
公司对于项目经理职责是非常明确的，如果不够明确，会导致管理混乱。

楼主公司的项目经理职能，明显就是基本的项目进度管控，确认上线时长，汇报上线周期以及跟进这个周期。而计划的排期是各阶段负责人的职能。这种组合项目经理处于团队辅助的角色，配合各阶段技术负责人进行计划跟进、协调整各阶段进度。

项目经理本身就是通过各阶段排期，从而统筹整个项目的进度。不过项目 总体周期，项目 经理也是根据上层决意而定的，所有各阶段负责人的排期也应该是在这个周期内的

社区内容是大家共建，社区并不会做任何性质引导。 不过对于引战、故意制造消极、焦虑的我们也会慎重进行审核

弱网的话我理解这两个其实都差不太多，就是网络状态不好的情况下，应用展示情况
比如：
接口请求响应情况
请求超时，应用处理情况，各种超时文案，缓存数据加载机制之类
页面展示情况，很多应用在不同网络情况下加载的图片也是不同分辨率的图片
应用更新机制，在什么网络情况下会自动更新应用相关

只是在移动情况下我们比较难人工模仿，连接 wifi 的情况下，可以制造各种网络延时、丢包，用于模拟弱网场景

这种 场景其实用例覆盖挺难的，主要是研发逻辑怎么整 的，不太好说
不过经常出这个问题的研发，后面工作中一定也会出，这个是真的

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

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

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

首先是票价问题

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

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

落地问题

说到这块，不得不说一下，为了议题的高质量，也成立了 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

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

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