请问有无线上直播和录播渠道？

有几个疑点：

1. 正如 10 楼所说，提效部分是否当前效率最大痛点，还是说为了让工作中体现提效而找个简单轻松的地方去落地
2. 提效工作做得够不够好，还是说勉强 60 分的形象工作，大家对提效工作根本没信心还是要人肉兜底
3. 提效有了但是人的理念有没有转变过来，还是说依然选择人肉兜底保心安

实际中比较多的是第 2 和第 3 种情况

成都机会就多很多了，如果没有 base 限制倒是可以过去成都碰碰运气

fastmonkey 和 fastbot 都是同一个作者，前者更多是个人项目（完全不维护），后者是团队项目（作者在字节跳动）。

1. iOS 有必要做 monkey 测试，大厂一定都会做，100%
2. 目前市面上 iOS，应该就是 fastbot 最好了（指国内免费使用的，国外或收费的不了解）

这么说确实是，不过考虑到 appium 本身的初衷，它留着一层中间层也无可厚非，因为完全没必要因为 windows 和 mac 而去掉它再维护一套；毕竟你也不能排除它用这台 windows，通过远程通信去 dump 另一台 windows 的控件嘛。

不过文章确实精彩

移动端框架搞中间层是为了屏蔽不同平台之间的差异，让 client 端使用同一套协议实现不同的平台自动化，相当于降低 client 端的复杂度，固定的 DSL 可以让项目会更好维护。中间抽象层的损耗个人感觉不大，就是 pc 端发请求到移动端的 server，server 调用平台接口实现。这里逃不掉一次通信，除了通信外其他的本地工作只要没 bug 都不会带来损耗。

楼主的想法是通过 adb 命令去 dump 控件，有没有想过 adb 命令一样会出现通信拥挤导致不可接受的卡顿延迟问题？因为这里本质上还是需要手机和外部通信，只是说 appium 走网络协议（http），adb 可以是数据线也可以是网络协议。

思来想去，好像本质问题依然还在？

做平台和用平台不是一波人，从来都是这样，习惯就好。
就看做平台这波人会不会尽快去找用平台的人拿到反馈然后赶紧迭代了

需要开发的专项测试工具一般是指什么：

1. 特定业务场景才适用的工具 —— 比如基于这些工具在特定网络协议上再做一层封装才能在业务上使用
2. 需要针对某些指标项钻研得更深 —— 比如工具中有些指标项欠缺，而业务中刚好需要
3. 需要和公司平台打通的工具 —— 把工具能力集成到公司内部的体系，打通数据收集存储展示 ……

如果想自己真的算有能力开发这样的工具，应该如何学起：
我的方法可能比较低效，找别人的源码就是一顿看，一切从抄袭开始，抄着抄着随着知识储备提升你就会意识到当前方案的问题，然后找到更好或者更适合自己需求的实现方案，然后再做一遍（在别人看来你就是在搞轮子，大家一样质疑你，就像这个帖子一样 ）

我的老板一句话概括：对内不同业务方向，把控线下到线上全流程质量风险对应的质量建设；对外沟通研发产品运营，及时获取各种产运研动向以不停给大家输入。

活挺抽象，时间也比较碎片，老板更多是务虚而不是务实，但是务虚也有务虚的价值，不是每个人都有务虚的毅力和能力（想想你一天到晚都在开会，你开会得保证有意义，会后零散时间还要沟通、想规划、把关下属工作）。这些都依赖有前期大量务实的沉淀和思考。

从目标触发去考虑你要做什么事情。

• 如果公司对 app 安全性要求并不高，而且历史上也没出过什么太严重的安全问题，那可能：
  1. 公司 app 的安全性也许还挺高，找安全问题的空间不大
  2. 公司根本不太在意 app 的安全，在现阶段不会有多大投入

这种情况总结起来就是，你也没必要把这个东西研究得多深，有个结果交付给上司就行了。

• 如果公司对 app 要求很高，我建议还是直接找乙方做安全测试，安全领域真的很深，我以前在外围简单涉猎过，这些东西如果不花大量时间实践是没结果的

按匹配度排序，如不匹配则逐级下降：

1. 完全一样业务的业界测试团队的质量工作
2. 业务不完全一样但是依然处于同一个大领域的业界质量工作
3. 业务不一样，领域也不一样，但是要做的事情和你们想做的事情接近的质量工作（比如都是要做覆盖率、都是要做接口/UI 自动化）

第 1 和第 2 点基本上到手就能直接参考；第 3 点需要你们已经有建设目标才能找，结合楼主说的【不知道应该关注哪些内容】，我理解就是没有明确的建设目标。如果楼主所在业务内部交流本身也没提什么特殊的建设，那就先当做是常规业务去建设就好了。至于常规业务一般建设什么，这个网上很容易搜索到。

个人观点：

1. 211 的优势更大，一本和二本在面试筛选时虽然有区别，都其实也都是本科。而 985、211 这些显然是第一批被筛选出来的
2. 进 211 如果专业不理想，前一到两年要刻苦学习随时准备转专业，越早转过去理想专业越好
3. 电气不清楚，电子信息、计算机方向我理解就是出来做程序员，写代码是门手艺，在校写得越多能力越强，所以老师并不重要，最好能混进去学校的 xxx 计算机实验室跟着老师做项目，不行就自学（我自己也算是半个自学），还是讲究实践

综合楼上观点，分情况讨论可能是这个样子：

1. 如果你能确保上游服务稳定，如上游服务变更少，逻辑简单等，可以偷懒省去 mock 的环节直接测，我们默认上游没问题，在测试的时候一并观察上游返回是否符合预期即可 —— 相对来说，省了 mock 成本，但是在校验时有额外的心智负担
2. 如果你无法确保上游服务稳定，如上有服务变更频繁，逻辑复杂，可能有更复杂的依赖，这种为了测试效率考虑还是走 mock，如果直接测，一旦出问题要排查半天是哪里的问题，长期来看效率可能是负向 —— 相对来说，有 mock 成本，mock 了之后就可以尽量去转化为接口自动化测试

大多数情况下，大家可能都是按照 1 去操作，有些业务形态真的复杂，那就只能 2，这些工作省不了。

一般系统设计接口是稳定的，如果频繁变动接口（mock 轻易就 break），我觉得可以质疑研发的接口设计水平。所以不太需要考虑 mock 要经常维护的问题。如果你能预见这个接口它就是因为业务迭代肯定会频繁变动，好像也没更好办法，因为你的被测服务可能也要跟着变动，那时候你也要被叫过来测试。这种情况先和研发探讨一下再做决定

找一份靠谱的工作，还是熟人介绍或者找猎头推荐比较方便

想学，但是每天卷到很晚，下班回到家可能就快 11 点了，很难强迫自己再学点什么了 😭 终究还是欲望不够强烈

昨天刚好看完雷军的《小米创业思考》，深深感慨能力强的人是如何不受任何外力束缚有非常变态的毅力和自控力去做事情，另外从书里也认识到商业化的一些基本考虑（如文中提到的供应商、成本计算、营收预期等）。感觉自己好菜

同意，测试配合协助解决问题，其实也是在解决问题。

如果精力时间允许，可以帮助开发缩小排查范围，这何尝不是在努力解决问题？有些工作，不是测试做就是开发做，它总得需要有人做。而最后找到有 bug 的代码再修复，只是解决问题的环节之一，甚至都不是最后环节（因为你还得复验，上线……）。

不要和开发站在对立面，只能说尽量追求统一的共识为更好的产品交付效率和产品质量去做努力吧

1. 评估这个问题带到线上的严重性，看是否需要阻塞发版先在线下复现修复了
2. 让开发在可能的复现路径上埋更多日志以及监控，以便后续复现出来有更完整的证据链，或者第一时间从线上感知到问题发生尽早接入

其实需要的考虑的问题就是：

1. 是否严重到阻塞上线，不上线的损失是什么？
2. 如果线上问题复现，能否第一时间监控到，能否更高效地定位与修复
3. 最后才是线下测试需要改进的环节

曾经我也像你这么看待过 “架构师”，直至到后来我做抽象的事情多了一些，部分理解开始改变，其实觉得那些听起来天马行空虚无缥缈的建议也没有错，问题是当时的自己并没有跟 ta 同一层次的理解深度，又或者是 ta 的表达没有考虑到我的理解水平，最后相互都觉得水平好低……

还是多从自己身上去找原因吧，一切建议都应该虚心听讲，甭管建议是否恶臭，关键是换位思考、空杯心态。可以保留自己的判断，但不能一听到别人的意见就直接否决。

哎，这个时代是这样的了，不是你卷我就是我卷你，或许咱们可以用以前的思维，管它叫 “勤奋” 吧。毕竟咱们又不是什么学习效率爆表的硬核大佬，比不了学习效率就只能比学习时长。这个也是长远来看保证未来生活能过得好一些的重点投资项

确实啊，IT 行业，讲究的自驱力我感觉比很多行业要高，因为它的更新迭代速率会很快，另一方面又有大量新生劳动力加入行业。现在门槛也开始慢慢升高，如果不自驱，可能有一天会成为低性价比员工然后被清扫出行业

可能没有你想象中那么晚，大多数时候 11 点就差不多了。主要是晚上时间可以调节一下，有时抽 20 分钟跑跑步再回来继续补 20 分钟工作（或者下班回家继续搞），整体来说也不算很差。不过确实累，精神上是高压状态。

我已经高强度加班接近一个月了，依然保持着热情（但是这个状态其实不太健康，身体上的）。

重复项目重复测试咱们就把它理解为单纯的工作量，而热情就留在自我提升上。我自己的办法是 “每天有固定的时间留给自己去做提升”，真的很重要！！！虽然最近忙起来导致这块时间被压缩了，但还是得有。

如果每天全部时间都是在搞重复的测试，那你在怎么挖掘都没有热情，因为你每天都是过得一样的，谁能不恶心

cookie 做登录态维持已经是很古老的机制了，现在的系统很多都是自己以 cookie 之外的其他方式去做登录态维持，比如 header 里面的某一个字段，或者其他什么特殊信息识别，它不一定放在 cookie 里面。你需要问问后台开发

我的年终总结也是从 2 月份写到 6 月还没发