可能我表述也不够清晰。我不是说不涉及这些规范，而是这些规范并不像是导致 迁云时间跨度长 的根本原因。 “因为迁云时间跨度太长了，所以我们要落实代码规范/code review”，这个因果关系不够明确，也说服不了别人。

对于项目跨度时间长，因素会很多。而且很多时候这些地方缺少的不是规范或流程，而是大家的意识。好的程序员，并不会因为规范的缺失而写出很烂的代码，因为规范已经在他意识里面了，没规范他自己也会去制定规范。而改变意识成本是很高的，周期也比较长，需要找好节奏，循序渐进，并且每一步都找到合适切入点。

明天回公司看下 appium 版本，感觉像是 appium 版本不同导致的问题。

听你描述，学 java 至少可以看开发代码，修下小 bug 之类的。学 go 好像能做的事情更少？

感觉你的问题和原因有点对不上呀。迁云我理解更多是运维部署层面的，最多和发布管理有一些关系，前面的这些不规范和迁云有什么关系呢？比如代码命名不规范，主要影响其他人的阅读和理解，但不会直接造成缺陷的。建议要先复盘清楚，到底根本原因是在哪里，没有解决根因，其他改进都是吃力不讨好。

另外，要特别留意，这些规范，限制的不仅自己下面的测试团队，更多是开发、运维这些兄弟团队。先和大家沟通好达成共识，这个是大前提。

我按我经历过的大概写下吧：

• 代码规范

阿里、google 这些大公司都有各个语言的代码规范白皮书这类文档分享出来的，各个语言自己也有自己的一些推荐规范（比如 idea 自带的规则基本是基于这些规范），可以基于这些来调整。我们之前具体的调整是由一些资深开发 + 测试组成的技术委员会来操刀，保障调整的有效性。而且这些人参与了制定过程，后面落地认同感也更强，更容易推进落地。

同时也可以搞一些 bad case 之类的文化活动，分享一下某些不规范的写法会导致什么样的 bug ；或者组织大家看看 clean code 这本书，对怎么写好代码有更好的认识。

• 分支规范

这个核心就是分支模型了。一般主流就几个，主干开发 + 主干发布，分支开发 + 主干发布，主干开发 + 分支发布。一般需求并行比较多的，采用 分支开发 + 主干发布 会比较多。然后配合 gitlab 提供的 protect 分支特性，可以把主干保护起来，只有 master 权限才能合并，普通开发改不了，只能在自己的分支上修改，然后提 merge request（后面缩写为 MR）来申请合并。

master 一般由团队里对系统比较熟悉的人来做，这样在 MR 的时候做的 code review ，会更有效。同时 MR 也可以定制补充一些自动检查项（如前面大家提到的 sonar 、单测这类），检查结果直接呈现在 MR 中，作为 code review 的参考。

• code review

这里面东西比较多，比如 review 的时机（赶早不赶晚，谁都无法认真 review 改动行数过千的改动），review 的方式（评审人和写代码的人一起的方式，如 review 会议、结对 review；不在一起的方式，如前面提到的用 MR review ），review 的限制程度（阻塞式，必须 review 通过才能合并和提测，节奏相对慢的用得比较多；非阻塞式，可以提测后再 review，节奏快的更适用）。这块建议微信公众号搜索下吧，以前看到过挺多好文章的。

我们实际落地更多是提测后测试去阅读代码（我们一般不叫 review ），有问题会和开发沟通确认。通过阅读代码可以了解实现逻辑，也能更直接的找到一些问题，比如空指针隐患、if else 的场景不够全、事务性操作没有包到一个事务里等。

• 版本发布

不知道你们那边运维发布相关的基础设施做到什么程度，是已经做到了一个带审批流程的平台上，还是只是一个 jenkins job ，还是更人工的。如果想 QA 在这个层面上做很大的限制（比如二次确认开发有没有在最后时刻自己加料啥的），那需要在发布的审核流程里加上 QA 这个环节，QA 审核通过才能到实际部署这个步骤。

我们实际落地，审核流程会有 QA 环节，并且 QA 不能只是管审核，还需要在上线后和开发、产品一起通过线上测试/指标监控等手段，确认上线后没问题，为最终上线结果负责。

• 最后

代码规范、分支规范、code review 这些，本质上更多是在开发阶段做的事情，如果本身开发都没这方面经验甚至想法，需要长期灌输慢慢接受。

要逐步落地，建议可以先从线上问题复盘改进开始，一方面都出事故了，大家容易配合推进；另一方面这些问题一般也是破坏性比较大，最需要解决的问题。

个人经验，任何规范都是约束，都是会产生额外成本的，而且落地最终要靠的还是人。所有的要推行的规范，一定要能解决某些目前存在的实际问题，并和大家取得共识。切勿为了规范而规范，最后变成一张废纸。

PS：正常一个稍微大一点的开发团队，分支规范应该是最基础的协作基础，不可能没有的。建议你先和开发团队沟通下，了解下对于一个新开发进入团队，他们会教些什么，这里面一般就会有代码规范、分支规范这些了。

日志发一下？

然后，也试试去掉 "usePrebuiltWDA": False, 试试？

分享下我们实际用的：

"desiredCapabilities": {
    "noReset": true,
    "xcodeOrgId": "xxx",
    "bundleId": "xxx",
    "skipLogCapture": true,
    "deviceName": "iPhone6s",
    "wdaLocalPort": 25000,
    "webDriverAgentUrl": "http://192.168.25.12:20474",
    "waitForQuiescence": false,
    "newCommandTimeout": 43200,
    "platformVersion": "14.5.1",
    "automationName": "XCUITest",
    "useNewWDA": false,
    "wdaStartupRetries": 0,
    "platformName": "iOS",
    "udid": "xxx",
    "wdaConnectionTimeout": 1800000,
    "autoAcceptAlerts": true
}

这个问题好大，一时不知道从何说起。而且个人经验，这个东西必须因地制宜的，别人的经验你不一定适用。比如大公司代码规范会配套做 ide 扫描工具、持续集成的自动卡点等，小公司可能就一个文档和 leader 多看几眼代码。

可以简单说下你们的当前情况和主要问题点，这样大家比较好给建议？

如果是想了解那种通用型、讲概念型的，可以社区里搜索下，或者到微信公众号搜索下。

看下浏览器开发者工具的 network ，是不是有的 Js 基础库获取失败了？

有点没看懂你的问题。这两个工具一个是测试工具，一个是网络代理工具，本身就可以相互独立使用。

你说要联合，是要做到什么效果？自动化测试的时候，自动配置代理，并且自动改代理里的 mock 配置，返回你想返回的 response ？

appium 日志里，有个地方要留意下

[BaseDriver] Capability 'usePrebuiltWDA' changed from string to boolean. This may cause unexpected behavior
[BaseDriver] Capability 'useNewWDA' changed from string to boolean. This may cause unexpected behavior

这种转换不知道结果是布尔值的 true 还是 false

"webDriverAgentUrl": "http://localhost:8100/",
"usePrebuiltWDA": "false",
"useNewWDA": "false",

建议第二、第三个改为用布尔值的 false，不要用字符串的 false 。

我们内部用，只需要配置 webDriverAgentUrl、useNewWDA（值为 false ），就可以用 atx server 云真机上提供的 wda 来执行自动化了。

感觉楼主是累了，进入了疲惫期。这个主要还是心态上的变化。我毕业 2-3 年的时候也遇到过，各种新想法，然后否定自己的新想法，否定多了就会觉得啥都没意思，不想做。最后是去了一次旅游放松，然后就好很多了。

建议楼主可以先暂停思考一下，放松下自己 1-2 周。然后再去思考这个问题，找到自己的方向。

新公司项目虽然用 python 但是我没有参与

后面建议可以主动申请参与下，参与了可能就没那么多疑问了。

我的方法是：多练、多比较，然后每次练的时候，都借鉴下其他更好的，融入进来。

比如，我基本上从高中开始全部作文都写议论文，都是总论点、2-3 个分论点、总论点的结构。重复写了这么多遍后，基本上现在想、说、写都是 1、2、3 这样的分点描述的结构了。写代码、写用例本身，其实也是一种非常锻炼逻辑思维的工作，因为要求逻辑严谨。

前期建议先从写作开始，想是最快速的，说第二，写的速度最慢，思考时间也最充分。阿里不是每周都要写周报么，刚好可以借助这个来练习下，一举两得。写完周报可以也看看其他人的，看有什么写得比自己好的，然后下一次周报借鉴提高。

如果想要先了解下怎么能分论点阐述，可以看看《金字塔原理》这本书。

描述问题，先说清楚用的啥框架吧。。。看图明显不是编程语言，应该用的是 robot framework

至于你这个问题，可以用 robotframework 不定参数 搜索下，很容易找到答案。基本思路是封装成字典来传，而非传 10 个参数。

不过这个答案是受限于 robot framework 机制（.robot 格式的用例，没有类和对象，也没有函数可选参数机制，只有关键字、逻辑操作符和变量）所以只能这么做，如果是编程语言，直接 java bean + builder 模式（没有可选参数可用的语言，如 java ）或者用函数的可选参数（keyword argument）更好。

实际编程要尽量避免传一个字典作为参数，解析字典还得各种判空和让使用者想办法保障 key 名称一致（编程工具无法帮你自动补全，重构改名字也没法直接帮你每个地方都改到位），很容易出错。

从目前给到的日志，只能看出是某个底层的请求可能由于卡住超时了，超过 240 秒都没返回。但因为不知道你使用的自动化驱动方式，所以不知道是 ios wda 卡住，还是 android uiautomator2 卡住，还是别的其他底层驱动卡住。

可以跑的时候也收集下对应操作系统的日志（如 android logcat ，ios 的系统日志），看下发生超时的同一时刻，操作系统有没有报什么异常？

也特别感谢你之前开源的脑图编辑器，我们内部的 vue 脑图编辑器就是基于你开源的版本进行调整的，省了很多力。

目前已经封装成了独立的 vue 组件，方便各个 vue 工程直接接入。目前在内部申请开源中。

学习了。

文章概念略多，想确认下，Light Merge 是不是相当于：

1、从 master 拉出一个新分支
2、选择一堆开发完待测试的 feature 分支，逐个 git merge 到这个新分支
3、全部成功则可以基于这个分支进行测试，有冲突则提示信息，让开发改为手动 merge

这三个点？

实际实践中，有个疑问点，修改 bug 是在 feature 分支上修，还是直接基于合并后的新分支修？是否会遇到某个功能，在单独 feature 分支独立没问题，但 merge 后的新分支有问题的情况？

个人理解，2 年一般要求是一个独立的执行者 + 入门的协调者吧

1、可以独立 Hold 住中小型项目的整个测试过程，包括前期评审到测试到最后上线。
2、接口、UI 自动化至少两者有其中一者的经验，能基于工具或框架编写用例
3、对自己测试的系统整体架构有了解，自己测的最多的部分能说清背后怎么实现的
4、视野除了自己所在的小公司，还能看到一些行业的东西，比如接口测试除了自己用过的，还有什么流行的工具，大概优缺点是什么，不一定用过，但有一些了解。

不过，实际上招聘不是看 2 年经验要有什么能力或技术，你是否符合，而是岗位要有什么能力或技术，你是否符合，然后再看你工作年限，年限只要不是过大一般没问题。2 年一般对应的是中级或者高级 title，可以参考下照片网站上这方面的岗位招聘要求。

RPC 应该不算是协议吧？

明白。

避免用例丢失思路我们是一致的，都是保存历史记录，并支持一键恢复。

可以随时选择任意父节点进行拼接这个挺好的，可以像前面其中一位同学说的，可以任意组合用例库里的用例形成自己的测试计划。从目前大家使用上来说，这种场景比较少，偶尔遇到直接在脑图里复制粘贴也基本可以满足。后面如果需要这方面的特性，我们也参考下这个思路。感谢分享。

语言很通俗易懂，也有很多例子，点赞！

针对消息不一致，分享下我接触过的系统做法：

首先，消费者在消费成功后通过同步请求或者另一条 mq 队列，反馈给生产者，生产者更新自己内部这条消息的状态为已处理。

同时生产者内置一个定时任务，查看内部所有待处理消息是否超时，如果超时，进行自动补偿。补偿大概步骤是

1、发起 http 同步查询给消费者，确认消费者是否有消费
2、若消费者反馈已消费，直接更新生产者自身内部消息状态
3、若消费者反馈未收到，则进行预警，人工介入处理（一般不会直接重发，因为重发有可能引发更严重的问题，如加剧 mq 消息堆积的情况）

好奇问下，你们当时数据存储设计，把用例拆那么细的初衷是？每次读取完整脑图都需要各种连表查询重新组合，会不会对数据库造成比较大的负载？

文章中的思路应用到你提到的 “不想每次给到后端的 json 都是整个脑图”，其实也是可以的，json-patch 的生成改为由由前端来做就行了，这样就可以只提交 patch 内容给服务端（json-patch 和 json-merge-patch 两个格式设计初衷就是做 json 数据增量保存，节省大型 json 修改保存时的带宽用的）。至于统计每个人每天新建、修改了多少用例，个人理解已经不是增量保存的范畴了，应该用你说的加更新时间和更新用户信息会更好。

我当时整个 patch 生成的逻辑全部放服务端，主要 2 个原因。一个是找到的库是 java 的，另一个是冲突时后端有全量 json ，方便做整体备份避免丢失用例。从我们引入 agileTC 进行落地的整个经历看，对于用例平台来说，丢失写过的内容（哪怕是引起冲突无法保存的内容），是用户最无法容忍的问题，所以要尽一切努力去存储用户期望保存的内容。

tapd 也支持 xmind 测试用例？看介绍好像没提及。

可以问下在京东里面的测试同学帮查，这方面信息客服不一定能看到。

这个得京东内部查下登录方式了。一般这种大型 app，除了用账号密码，还可能会提供别的登录方式。

不同团队可能需求不一样。我们这的优先级、自定义标签，用得还挺多的。

比如写用例的时候，有些地方需要用例评审时特别关注，就打个【待确认】标签。
比如给开发自测用例的时候，一般就直接给 P0 优先级的