没在 linux 下弄过 android 模拟器，所以没什么可以推荐的。

mac 的话用过 genymotion ，还不错，但 linux 怎样不清楚。

可以看看《海盗派测试》，会有点难懂，但也是一种新的思维方式

有的人写的用例出 bug 的效率低，有的人写的用例出 bug 的效率高

这个倒是建议你们可以内部交流下。个人建议是不能直接用出 bug 效率评估的，也得综合看 bug 的严重程度，有些非常偏僻的路径出的 bug ，优先级并不高。

报错的不是你截图这个代码文件，是另一个 test.py 文件。报错原因是在那段代码里， AppiumBy 是个 None 类型数据（类似其他语言的 null ），所以没有任何子属性和子方法可供调用。

你确认下那段代码的 driver 是不是真的有 AppiumBy 这个子属性？driver 会不会引用错了，用了 selenium 的而不是 appium 的？

如果想统计，提几个建议：

1、用专业问卷来收集，而不是让大家自己想办法遵守你的格式
2、通过匿名方式收集，而不是让大家用真实账号回帖
3、这种数据建议找几个关系比较不错的同行哥们去私聊问吧。你这里的外网 bug 在我看来像是线上故障数相关指标，这种数据还是比较敏感的（毕竟谁会对外说自己负责的业务线上故障率高，揭自己的短？）。怎么规避才相对不那么敏感。

linux 下安装 android 模拟器，我试了下，用 linux android 模拟器 能找到很多资料呀。所以为啥卡住？

测开我理解有两类，一类是业务测开，一类是平台测开

业务测开应该和你现在做的差不多，业务为主，过程中涉及部分技术类工具的使用和少量的脚本/二次开发，主要需要的技能是业务测试 + 各种技术工具的使用（包括自动化）+ 脚本开发能力（比如 shell 、python ）。这类其实在很多公司也直接叫业务测试，相当于把业务测试的要求提高了。

平台测开则偏开发多一些，接触业务相对少一些。相比质量保障，更偏向于做效能提升。做的事情主要是公司统一的测试工具/平台开发，比如开发自动化平台、自动化测试框架、性能测试平台等，有时候还会跨界做 DevOps 平台之类的。技能一般要求是有一定的平台/工具开发经验（比如 Web 平台前后端开发、自动化框架设计开发等）

这里面其实没有绝对的分界线，更多看公司自己对测开岗位的定义和理解。据我所知，运维也有类似的运维开发岗位，专门开发一些自助上线相关的工具平台，提高自己的效能。

有几个点和我的认知有些差异，一起探讨下：

中台是作为一个数据存储并提供所需数据的地方吧，就是有多源数据经过大数据的清洗处理后存放的地方，个人简单理解就是作为一个多源数据的存储仓库。

这个我理解就是数据仓库，不是中台。因为听起来基本没有业务逻辑在里面，只是单纯数据存储和获取。

在中台进行算法，前端只负责显示，这个毫无疑问速度是最为流畅的。

我理解这里的前端和题目里的前台应该不是同一个东西？一般说 中台、前台 ，里面的前台指的还是服务端里的一些服务，而不是前端。

2.双 11 做一个抽奖活动的功能。①抽奖核心抽奖算法功能在前台做，中台负责相关数据存储。 ②前台只做数据展示，中台负责核心抽奖算法。
①：以上两种各有什么缺点
②：如果是你，你该如何设计

这道题尝试回答下。仅个人观点，欢迎拍砖：

①：以上两种各有什么缺点

大前提：因为这里没明确前台中台的定义，我先按比较常见的 “大中台，小前台” 概念来，即前台=整体服务端架构中接近业务应用的部分，典型的如 app 直接对接的 app 服务端；中台=整体业务架构中各业务共用比较多的部分，典型的如交易系统、支付系统，中台内部通过租户等方式进行各业务数据隔离同时，服务共用。

• 抽奖核心抽奖算法功能在前台做，中台负责相关数据存储

优点：题目有提到双 11，意味着会有高并发。放在前台做的话可以让抽奖算法这块的压力由前台去抗，降低中台的压力。
缺点：通用性比较弱一些，比如这套算法如果别的业务也要用，得自己另行开发 + 测试，形成重复建设。

• 前台只做数据展示，中台负责核心抽奖算法

优点：前台很简单，只需要做一些参数转换就可以。别的业务要用这个抽奖算法也可以快速接入。
缺点：中台处理压力很大，而且由于中台一般是多业务共用，压力过大会影响性能，进而影响别的同样用这个中台的业务

②：如果是你，你该如何设计

如果团队人足够多，可以多维护一个服务的话，单独拆一个活动服务放到中台部分，内置抽奖算法相关逻辑，并进行独立部署方便按需扩容。否则直接用前台做，先保障抗住压力。

@ZhouYixun 看下？

已解决。

问题已修复，相关 PR：https://github.com/testerhome/homeland/pull/160

此话题先关闭，如果再出现，请再开贴 @ 我。

OK，已审核通过

css 用得不对，导致没适配。已修正。

顺便也关贴了。

越来越强大了，特别支持多协议这个，点赞！

TCDD（测试用例驱动开发）这个新概念，可以扩展说下具体是什么意思么？和 TDD、ATDD 这些有什么不同？学习学习下

然后你这两个部分，感觉相比前面的 12 个步骤，会不会有点过了？。需求质量、代码质量在你抽象后都没了，这个我理解应该是你标题说到的 测试过程左移 的核心之一。

第一轮估计我就过不了了，有些东西不常用记不住，只能说个大概。。。

不错，怎么用技术解决问题和提效 这方向是对的，继续加油吧！

PS：如果觉得自己这么久都没拿得出手的成果，有可能是你日常任务波澜比较小，挑战性不高。可以试下后面遇到挑战性任务（简单点说，就是你第一反应会是个深坑或者很难的任务）时，自己主动去争取做一下。这类任务一般数量不多，但完成后给到你的成长会比普通任务要明显的多，而且成果相对亮眼，也容易让领导看到你，后面给你更多的机会。

管理不好这个，有啥好工具建议么？

现在测试用例通过平台编辑历史可以跟踪、代码通过 git 可以跟踪，唯独需求啥时候变、变了啥没有合适工具去跟踪。经常需求评审的时候需求质量还不错，后面实际开发时有些需求会进一步补充或者微调，就会因为管理不好出各种问题。

找不到元素的时候，打印 page source 看看先？

有时候 page source 看到的，和你浏览器 elments 看到的会有一些出入。也可能是这个是延迟加载的，你找元素的时候还没加载出来。

先打印 page source 确认有控件，再 find ，会比较稳。

如果你是想找测试技术积累比较不错的中大厂，建议想办法找内推，不要想着靠海投。海投的话一般第一关是 hr 筛，学历一个过滤条件可能你的简历就没在列表里了，而且现在 HC 少的情况下，对人员的要求会更高一个档次。

另外，7 年经验，总归要有点拿得出手的成果吧（不一定是技术的，业务方面的也可以，测试也不仅仅是技术），可以写一下这些成果？

可以粗细结合，但不能都是细节。

筛简历的人一般是 leader ，习惯性会优先关注成果，其次才是过程细节（毕竟有些总监其实过程细节已经很久没怎么接触了）。细节不用写全，毕竟内容比较多，一般都是面试才会把细节聊透。

你这里没有写任何成果，写的过程细节也没啥亮点（都是网上很容易就能找到且使用很普遍的技术），所以在茫茫简历中，吸引度远不如那些写着 “测试时间缩短 xx%/线上故障率降低 xx%” 这类带有量化成果说明的简历。

TCDD 是啥？第一次听。

...产品参与；从上面的 12 步骤里，抽象出三部分
1、测试用例开发；-基本能力
2、测试脚本开发；-升级能力
3、QA 质量体系监控；--数据可视化
这两部分才是测试重点关注的地方，但要把 12 部分内容释放出来：分两部分实践：

是有错别字么？一会两部分，一会三部分，表示没看懂。然后这个抽象也没懂，12 个步骤怎么能抽象成这 3 个部分。

如何通过 adb 命令检测 server 进程是否存活

你之前贴的 appium 日志里就有：2022-04-27 03:17:51:407 [ADB] Running '/lib/android-sdk/platform-tools/adb -P 5037 -s emulator-5554 shell pm list instrumentation'

E wifi_forwarder: RemoteConnection failed to initialize: RemoteConnection failed to open pipe

查了下，你这个的进程号和 UIAutomator 无关，而且出现了 N 次，不过既然涉及 port ，确实有一定概率是有关的。要排除也很简单，在关闭 Uiautomator2 server 后，继续捕获 logcat 日志，看会不会出现。会的话说明没关系。

关闭 UIAutomator2 server 的方式，可以参照 appium 日志 2022-04-27 03:17:52:252 [ADB] Running '/lib/android-sdk/platform-tools/adb -P 5037 -s emulator-5554 shell am force-stop io.appium.uiautomator2.server.test'

我调大 server 检测的超时时间，'uiautomator2ServerLaunchTimeout':'500000', 还是无法启动 UiAutomator2 server

从快速解决问题的角度，建议你直接换台别的测试机试试。如果要继续定位，可以参照我上面写的来看，日志实在没线索的话，需要继续追到 UIAutomator2 server 源码。

不客气

PS：少发这类大表情图吧，毕竟这里不是微信群，有点闪瞎眼。。。

都是比较大的公司，没说具体业务和团队不好比。

只能说整体印象上，招行的测试技术在银行里还是算很不错的，可能相对来说没有互联网那么极致（主要是业务体量差异引起），但比其他银行应该是好不少的。联想就不大清楚了，接触比较少。