Respect！

1. 技术哪里都能学习，主要看自己。 而且 LZ 这几个 offer 的技术氛围都不错
2. LZ 想 30 岁以前不换工作，所以建议背靠大（a）厂（li）

分批提测，拥抱敏捷吧。
不过大多数公司身处瀑布追求敏捷，结果可能不太理想。

如果贵司的 CI、冒烟和以及接口自动化到位，我觉得可以尝试去分批测试。
如果没有达到敏捷的条件，确实可能需要整体交付一个版本后统一测试、再修复、在测试。。。。。。

“羡慕刚毕业的自己”。。。很认可这句话
祝好加油！

说一个比较实在的情况（可能会阻碍未来的发展，但是适合现在情况）
让你老公在华为的外包公司给你寻找一个测试或者 QA 的职位（当然，可选一个对加班没有严格要求的部门）

加油吧！
试用期不过并不可怕，毕竟还年轻。
选择好一个团队，努力提升自己才是最重要的。

除了功能
边界值 200 个字符在前端页面的展示上有时候也是很奇葩的

樓主還是非常的敬業
通過樓主的樓主開發測試的角色無縫切換.......證明出：技術是王道
加油

楼主还是很励志的，加油！
裸辞没有绝对的对与错，如果没有裸辞，又如何会有那么多的精力去转移方向学习呢？
只是希望我们的未来会越走越宽！

能否贴一下运行正常的 log 看一下？
异常 log 中还有 1 处有点意思：
info: [debug] Waiting for device to be ready and to respond to shell commands (timeout = 5)
info: [debug] executing cmd: F:\android-sdk-windows\platform-tools\adb.exe -s 127.0.0.1:62001 wait-for-device
info: [debug] Retrying restartAdb
error: Error running wait-for-device

adb 为什么要重启，adb 重启了，那么之前的 wait-for-device 命令肯定就会报错
系统就认为是 adb 环境崩溃，然后执行了 kill-server，就断开了

建议你们公司讨论评审是否需要啊专门做 App 的升级特性测试
看是否之前有相关升级的问题
多数公司会在灰度环境进行一下升级验证，保证新老数据兼容，可以正常登陆就好。

如果评审以后有升级特性的专项测试，

1. 升级、卸载和更新，以及对应的方式、检查和基本操作
2. 版本升级树（对应的版本配套表，是否支持间隔多个版本一步升级到位）
3. 升级场景的备选流覆盖

成都还算是二线？
我觉得如果自家经济条件允许，你有一定的经济资本，就回去创业吧。多经历一些总没坏处（虽然你年轻，虽然履历少，虽然坑有很多）
如果自己经济一般，那么还是继续打工吧，攒点资本。毕竟创业风险太高，收入可能成为一段时期的瓶颈。

小时候的我们，无忧无虑乐于分享。
小时候的我们，都有一门课叫做 “思想品德”，总是在讲述各种各样的真善美。
小时候的我们，总是高唱 “我们是共产主义接班人”。

长大后的我们，明白了什么是自主产权。
长大后的我们，都会面临着 “市场经济”，总是在告诉各行各业的创收规则。
长大后的我们，总是呐喊 “经济决定一切”

举个不恰当的例子，很多 MP3 歌曲免费下载；但是随着版权的深入，很多歌曲现在要开始收费下载。
我们现在当然不会说收费下载的都是流 mang，因为我们心底承认这件事的存在

社区帮助过我们很多
很多人都是从小白一步步成长起来的
我们先不说社区，想想自己公司的同事，有些人就是很。。。那时候你真希望把你的脑子塞进他的脑子里。
这种人能怎么办？
当然也许有些同事可能知道自己过于小白，见你花费那么大力气帮忙解答，工作中可能请你吃个午饭或下午茶报恩。

再看社区，我们先不说论坛这样基于网络平台的，我们就说实体的社区，对，就好比居住的小区。
前期，假如某个业主可能学雷锋，不辞辛劳的帮忙，帮助各种各样的业主生活诉求，可能包括插电卡这样的小白操作，不收费用。
可是有一天，该业主家人说自己生活开销都不够，决定采取有偿服务，然后根据业主诉求收费。
业主们肯定也会明白，虽然有部分人难以接受。
然后有些业主也想到自己，其实也可以采取有偿服务的，为自己创收一些。
这样涌现出的业主越来越多。
直到多年后的某一天，所有业主发现，某些生活技巧不是只有自己会就好的。
技能交换分享可能更美好一些，共创全能业主的小区才有意义。

这样看来，楼主的分享理念基本等于实现共产主义了。
想法美好，我们也都愿意为之奋斗，但是需要时间，“收费” 是这条路上的代价。。。

简单说下我的意见吧

1. 如果你身处一个大厂/大公司，那么你每天的测试任务基本是固定的，前期的单元测试开发人员应该也都完成了。而且你还有可能长期测试同样的功能。那么通过你这期间不断的学习和经验积累，除了所谓的需求覆盖/场景覆盖，你会产生一定的 “敏感度”，可以用于探索性测试。正是因为大公司里面流程完善，所以完成某个流程后，会有相应的规则指引去评估一个版本的风险，侧面的去协助你评价测试是否做的好。

2. 如果身处规模小一些的公司，那么可能就是身处瀑布，追求敏捷。及时响应新的功能和新迭代的验证。正因为如此，在每次迭代提测的前期，测试要充分的理解需求（Story），然后设计用例，提前发出评审，让相关人员都看下是否有补充的，场景是否有遗漏。开发阶段争取让开发人员完成单元测试，然后到正式的测试阶段去覆盖场景和用例，到迭代后期主要以回归测试为主，在代码保证的前提下，全量回归如果没有问题的话即达到了版本上线标准。（虽然很多传统的测试对这一点并不认同）

1. 请检查驱动
2. 请检查设备端口是否有 ADB Interface
3. 不排除数据线的问题，尝试换个数据线或者端口试试
4. 检查自己的手机是否开启了 “开发者模式”

你的安卓版本是多少？
还有，请检查一下你的 appium 脚本中的 android 相关配置是否正确？

写的挺对，确实符合大多数性能测试工程师
如果一定要有价值且不尴尬的话，那就是测试自己至少具备性能调优能力

现在很多老一辈的测试人员，会在测试技术上比较落后，因为各种原因，比如编码能力薄弱，比如没有及时跟进新的技术，抱残守缺，比如踏入管理岗位后丢弃了技术，比如学会了混日子再也没有了激情。
-----------------------------------------------------------------------------------------------深陷其中，正在努力挣扎跳出。。。