音视频行业，比如语音直播房间，怎么用技术手段监测语音抱麦后，声音是否正常，目前在自动化业务测试，遇到声音如何做自动化监测，有推荐的方案建议吗？

现在 perdog 收费了，可以自己根据 android 指标写一个后台监控页面，私有化部署

一、试验结果：bluestacks 可以支持 arm 架构 app 运行。
常用模拟器比较：bluestacks、andy 和 Genymotion，前者支持 ARM 架构，中者支持远程控制，后者启动速度快，各有优缺点。
对比结果是网易 mumu 模拟器兼容性比较好，也支持 arm 运行，没有 linux 版本。

二、centos 服务器上跑支持 arm 的 Android 模拟器
Appium 和模拟器环境推荐 docker 部署：butomo
github 地址：https://github.com/budtmo/docker-android

这都是平台化的东西，任何一个实现实施起来都不容易，除了多金的巨头公司，真正能完全做到的公司有几个，还不如先培养效能文化，推下敏捷流程，改善下当前工作流，工具是辅助人更好的工作。

就是求助遇到这种问题，大家有没有更好的解决方案，而不是走错路，越走越远。

非常感谢，很全面很周到，技术、流程、人员、组织的问题都需要考虑，需要加深复盘，找到本质问题再想策略去应对问题。

很好，带着主人翁的心态去面对评审，评审会议效果都不会差，还是得提高需求评审会的结束的要求标准、而不是走马观花、一扫而归，需求评审会就得严卡，解决需求不对齐、澄清的问题，治理需求混乱的本质问题

好的，后续按规范发帖，多谢支持

不能这样说，说明写平台的都已经具备开发能力了，但是并没有解决测试痛点，只是技能提升了，web 接口自动化维护成本跟不上迭代速度，所以还是跟 Jmeter 一样的神态存在，如何吧测试框架跟业务框架集成打通，实现增量更新就好了，要跑在开发前面，这就是 TDD 一直强调吧，预防缺陷，而不是一直做一个写接口测试的开发人员，到头来不知道自己的价值是测试强过开发，还是开发能力优于开发，要站在项目的全局角度去处理当前测试存在的问题，才是有良心的测试开发所想。

大概在 10-18K 之间吧，特别优先的不清楚，测试很难在 20K 以上，因为大部分都是业务公司，非科技、管理岗位又越来越少，被敏捷影响的，想要高薪资，可以考虑转产品经理、或者项目经理，比测试高一个薪资水平。

不违规、不炫富、没有其他的目的，请理解

楼哥，说的很对，一眼就看出实践过自动化的人发出来的心酸之言，首先是二个维度，流程规范的执行到位确实能避免一些问题，但是如果没有这个段位、能力影响组织变革，那对应测试内部来说，就先做好自己，只能考虑采用技术去改变解决问题了，大家都明白，工具只是辅助人去更好的完成工作，都要在时间、成本、质量做到平衡的。

非打广告，请尊重每个想解决实际问题的人，只是引用链接，多谢理解，要是平台不允许，我删除就是了

用例评审确实能消除三方的需求对齐、澄清逻辑等问题，但是需求变更控制，还是需要流程工具去拦截要求，在权利面前，一线人员是没有驳回余地的。。

测试部门归产品管理，技术团队是独立的，好的敏捷工作流也没有推行，一直处于领导引领需求变化，各个人都扎心的工作者，如何采取好的手段策略去影响进行需求精细化管理，如何做到业务有拆分、逻辑有梳理、未来有规划？

说的很对，有些产品团队就是类似拍脑袋，业务体系没有建立、走一步看一步，提测后需求一直还在补充，要怎么影响他们建立合理的产研体系呢？个人魅力，还是组织架构的优化。。

看到培训机构软文，看起来标题吸引人，不知道有没有落地，实施效果如何？
《智能遍历测试在回归测试与健壮性测试的应用》

首先先从外到内去分析，路径：前端，反向代理、后端、数据库。。。
第一就是对前端页面进行分析，可以用的是浏览器的调试功能，包括页面加载渲染时间，启动速度，内存变化，耗电量都要关注
# 参考 blog：
1.使用性能 API 快速分析 web 前端性能
https://segmentfault.com/a/1190000004010453?utm_medium=referral&utm_source=tuicool
2.chrome 浏览器开发者工具 network 使用笔记
https://segmentfault.com/a/1190000012057767
3.Chrome 开发者工具详解（五）之 Network 面板
https://www.cnblogs.com/kunmomo/p/11200945.html
4.前端优化总结
https://jelly.jd.com/article/6006b1035b6c6a01506c879f

在此建议
一、测试人员应对的措施如下：
1、加强自身的需求分析能力：业务体系的熟悉程度、背后技术体系的测试风险，需要不断熟悉梳理业务，学习提升新的测试技术
2、加强需求评审时测试人员的积极性，如何进行良好的需求分析，需求评审中前置测试分析工作，需要规范需求评审过程。--》输出《需求评审会议测试问题清单》
3、严格按测试规范标准去执行测试过程阶段工作：
测试分析 --》需求、系统分析是前提
测试设计 --》用例设计是核心
测试执行 --》自动化测试能力增强
测试度量 --》绩效管理是重心
测试过程 --》过程优化，复盘是催化剂
从测试发现 BUG--》测试验证--》测试预防，前置测试工作，提升自身的测试效能减少研发内耗，以降低 BUG 率。

二、需求评审注意事项
评审前期：--提前熟悉需求
1.在评审需求会议之前，产品应提前一天发出要评审的文档，测试在评审会议开始之前必须要先熟悉需求文档，了解每个功能点是干什么的。
需求评审会中工作：--评估测试风险
2.在需求评审中进行测试方案的选择，--》测试工作量的分析评估
（1）根据需求内容明确测试范围；确定本次需求需要保证的内容，可能影响的原有业务，是否需要其他业务的支持等等。
（2）根据需求类型选择测试方案，比如：需求确认 ---- 功能测试，并发需求 ---- 性能测试，影响范围 ----- 回归测试等。
评审会后 --需求封版及变更控制
3.要对评审过程需要修改的内容进行跟踪、是否结束需求澄清封版工作 --》确定测试范围
在需求评审会议即将结束的时候，需要确认在评过程中存在不一致的地方，是否达成了一致？异议达成一致的方案是否已经确认？
一定要对评审后进行跟踪，避免有头无尾，导致前期工作付诸东流。

参考：总结：如何做好测试需求分析
https://blog.csdn.net/ggf123456789/article/details/39180239
测试人员如何进行需求评审
https://blog.csdn.net/lionking0318/article/details/83988773

666

真是澄清了最近几年测试平台的官方定义，测试内卷的本质就是一群非科班计算机人干这外包测试，一心想学开发，于是就学了 CRUD 本领后开始写 web 系统，贴了个标签 “XX 测试平台”,各种公众号，博客园疯狂发文，搞的业内都一会写测试平台去标注一个测试人员水平的指标了，可仔细看后，发现就是一个框架 web 系统，只是传统工具的 web 化，并没有反映出其测试思想，测试理念；咋一看，很酷，跟真的开发对比一下，开发水平又差很远；测试不好好干测试，确标榜着测试头衔，干些开发的事，不去思考，测试平台到底需要解决真实测试行业，公司内部测试现况的事情，工具需要具备实用性，而不是多华丽，技术栈多高端；越来越发现，测试人太浮躁了，真正测试架构师在哪里？这个快速更替的职位，我们最多就是从国外的测试博文翻译应用而已，而不是有测试理念上的创新，测试专利，新的测试思维；看了 itest,恍然给自我一丝测试未来的好景，每一个功能都是从一线反馈实用，非常沉稳，希望像博主这种心怀测试情感的人越来越多，真正让国内的测试人员同开发人员在一个水平线上，是个对等的职位空间，拉起测试人的职业逼格，itest,come on!

我在 centos 部署用过，可以的

bug 度量分析是我见过最专业,最全面,最符合质量管理的视角统计的,再看看禅道.bugfree 这种传统测试工具,都想抛弃了,省去了测试经理主管很大一部分精力去把控测试过程指标

贴上宝藏资源:
https://gitee.com/itestwork/itest.git