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

业务测开应该和你现在做的差不多，业务为主，过程中涉及部分技术类工具的使用和少量的脚本/二次开发，主要需要的技能是业务测试 + 各种技术工具的使用（包括自动化）+ 脚本开发能力（比如 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：少发这类大表情图吧，毕竟这里不是微信群，有点闪瞎眼。。。

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

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

只看这部分内容，感觉写得太细节了，也缺少成果说明，在现在 hc 紧张的大环境下没什么吸引力。写项目经历还是用下 star 法则吧。

不熟悉 locust ， @debugtalk 帮忙看下是不是参数化姿势问题？

收藏了，后面如果需要弄鸿蒙原生包的时候用得上。

get 到大家的意思了，就是帖子列表页屏蔽掉私人社团的帖子，避免出现看到帖子点进去却没权限看内容。

这个应该是之前遗漏的一个功能点，我加到我的 todo 里，五一抽空弄一下

这个是 android 平台，和 ios 的 WDA 没太大关系。 WD = Web Driver 。