这个就看实际情况了，如果大家能力够，且觉得写代码效率还可以，那就写代码呗。否则可能引入 itest 会好一些，能避免写代码规范不一造成的额外理解成本。

至于造数据要用 UI 自动化这个，可以考虑把准备数据和接口测试解耦一下。准备数据搞个凌晨的定时任务自动造好（具体每个场景造多少个，可以根据实际情况自行评估下）并记录相关信息（如账号 id）到某个数据库表里，接口自动化直接从里面拿，并标记是否已使用。

极客时间 52 讲里，也有提过这种方式，详细的可以参照下这部分内容。

木有这样的设备，无法解答。。。

建议先把 appium 日志发上来？只有个 loading 截图，我们知道的信息并不比你多，所以也没办法提出什么建议。

不加精对不起这么详尽的一个问题排查记录

有点没太明白，为何会需要选择和排除其中一些方案呢？

如果是设计框架，想要通用性尽量强，那 4 个都得支持。
如果是业务项目的测试方案制定，那正常需求里就明确了需要支持的用户场景是什么，对应选择测试就行。

这 4 个场景，个人理解核心的差异：

1、web 打开和手机打开：内核的少许差异带来的渲染或特殊 api 调用差异 + 屏幕大小差异带来的布局改变 + 触屏和鼠标/键盘交互的差异（比如按钮要大一些之类的）。布局差异一般是大头，不过随着响应式布局的流行，不大复杂的网页一般都可以自动适配。

2、手机浏览器打开和 app webview 打开（你可以理解为 3 里面的套壳）：内核的少许差异带来的渲染或特殊 api 调用差异（webview 用的内核一般是系统自带/app 自带，和手机浏览器自带的内核一般会有一些差异，但因为总体 h5 标准还是比较清晰的，所以差异一般不至于很大）+ app 额外提供的 api 差异（比如有的网页为何要求必须微信打开，就是因为要调用微信的特定 api ，比如获取用户信息 api 等）。api 差异一般是大头，这个只能用指定 app 打开解决，自己随便弄的套壳 app 也不会有这类 api 的。

没太看懂这个问题，你是想验证啥？

是要收集确认线上环境是否存在音画不同步，还是验证开发说音画不同步问题已修复，是不是真的修复完没问题？

建议补充清楚问题的背景，以及具体想解决问题吧。直接把问题的一句话描述抛出来，容易导致理解偏差，而且这个一句话描述的问题可能在大家看来范围会太大，要回答清晰需要花不少时间，所以放弃回答。

举个例子，“如何减少线上 bug”，这个是很大的问题，可以说是每个测试人的终极目标之一，基本测试所有做得事情都是在解决这个问题，很难回答，所以也很难收集到答案。但如果是 “我所在的公司 .... ，所以导致由于 ... 出现的问题会比较频繁，大家有没有什么好的建议” ，那大家理解了上下文后，范围会缩小，回答起来也更容易，所以更容易收获答案。

@imath60 这个项目看起来还挺不错的，是你开发的么？

可以在社区的 开源项目 板块发布一下，方便后面其他人快速找到？

虽然没有直接关系，但只要是会频繁造成线上 bug，不管是推动其他部门解决还是自己部门内解决，测试还是有责任想办法规避的吧。

针对原因 1，可以在上线部署环节，加一个测试审核，测试确认代码分支有没有错，有没有夹带一些测试不知道的变更上去。

针对原因 2，看是运维手工操作导致的问题，还是本身上线计划有遗漏导致。
如果是前者，可以推动运维前期做线上操作双人制（1 人操作，1 人 review，降低犯错概率），甚至建设自动发布的平台，减少人工操作，避免出错；
如果是后者，那上线计划测试多加一个审核，以及在上预发布这种类生产环境时就用这个计划演练一遍，确认下有没有遗漏。

1、针对 h5 自动化测试的时候，大家是如何进行 “驱动” 的。使用浏览器驱动直接转到 web 端自动化？还是说使用原本的 app，在此之外进入一些需要测试的 h5 应用中。（因为面向的 h5 应用不一样，有些 h5 应用在 web 端无法打开，有些 h5 应用用浏览器打开的时候会无法加载一些用户 SDK，相当于无法使用。也就是说，用浏览器驱动直接转到 web 自动化的话，会有一部分限制）

一般根据实际使用场景来驱动，比如这个 h5 设计是放在 app 里用的，那就用 app 去启动。放在浏览器里用的，那就用浏览器去启动。

2、针对兼容性测试有一个问题：我需不需要针对多浏览器内核进行测试兼容性，需不需要针对手机浏览器内核进行测试，需不需要针对一些微信/支付宝进行一些应用测试（挺迷茫的）

这个看用户使用场景和线上问题情况。相对来说，h5 标准已经比较细，各家浏览器的实现差异已经没有以前 ie 和其他浏览器那么大了，只要不调用一些相对偏门或者特别新的 js api ，一般不怎么会有兼容问题。倒是不同 app 内置的 webview ，提供的调用 app 功能 api 差异比较大（比如调起微信的支付，和调起支付宝的支付，api 是不一样的，但界面按钮大概率是同一个），这块如果有涉及，最好验证下。

3、针对性能测试：假设现在用浏览器进行驱动，那能拿到的一些自动化性能数据的偏重点，可能就是响应速度等等，这些预想之中确实有手段去拿到，但是在这之外，我还可以输出些什么。

我一直觉得，如果你功能测试的时候没太感觉性能有很大问题，暂时可以先不用特别关注性能。先把前面兼容性这些搞好吧。真要搞，包括接口响应速度、界面帧率、白屏时间等都需要测试，还挺多的，这些通过 chrome 浏览器的开发者工具，大部分都可以捕获到。

4、针对 h5“自动化”“功能测试”，由于本人对 web 端了解较少，web 端上有没有类似 Fastbot 的智能遍历工具（有最好，无则自己写一个瞎点也是可以的）

fastbot 本身也支持遍历 app 内的 webview 吧，只要控件树能拿到里面的内容就可以支持。只是 web 端出问题不如 app 出问题直接 crash 那么明显且容易捕获，更多只是 js 报错，界面无响应而已，所以反而需要下功夫的是怎么捕获错误。不过确实没怎么见到有 web 端的智能遍历工具，可能是因为更新非常容易，所以质量要求没有 app 那么高？

这也不算很底层吧，只是确定下原因，便于后续遇到类似情况后解决而已。

如果不是定位到原因后解决问题，而是随便改，改完发现生效后就当解决问题，容易导致一些副作用而不自知，也不利于系统地积累知识。

前面光说问题漏了建议了。

我的建议是，既然平台已经花了不少精力做出来了，不妨先做一阵子实际推广，也借机了解下大家实际上对于写 python 代码的意愿如何，实在不愿意写代码的比例有多少。比例不高的话，暂时没太大必要再专门搞一套界面了，对提高大家技术水平也有好处。

如果比例实在高，那建议还是换开源的界面化写用例平台吧，比如 meterphere ，到时候辛苦一点，人工把用例全部迁移上去，后面就可以长期用了。

能同时兼顾会写代码以及不会写代码的同事

让不会写代码的同事用，基本上就只能是通过 web 界面了。但这样就变成你要维护两种不同的写法（代码的、界面的），工作量 x2 了。

一般来说，如果本身需求就包含要兼顾不会写代码的同事，可能一开始就统一用界面方式写会好一些，要不以后两种写法共存，学习成本 x2。别的平台基本都是前后端一体的，你想继续使用你的后端，只用别人的前端，可能改造成本也会比较高。

1、先读官方的文档，把 demo 跑起来，有个大致了解
2、在工作中用起来，因为只有工作用起来，才容易产生深入了解的兴趣和根据工作需要做完善改造的需要。
3、在 2 的过程中，搭建起项目源码编译环境。后面对于感兴趣的功能，逐步去通过阅读源码了解其背后原理，并到播客或者社区写文章记录下来。
4、当对源码熟悉到一定程度后，就可以尝试去做一些二次开发改造，使其更满足自己工作需要。
5、如果有兴趣有时间，强烈推荐自己尝试去把这个开源项目的某个部分，自己造一个功能相似的轮子。从技术方案设计开始做起，这样你能更深入理解到这个项目为何和这么设计，利弊是什么等信息。这方面可以看看 debugtalk（httprunner 作者）的一些公众号文章，里面有很多设计方案的思考记录。

对于源码如何阅读，可以参照一些源码阅读相关的文章。例如我之前写的 通用流量录制回放工具 jvm-sandbox-repeater 尝鲜 (二)——repeater-console 使用 (已完成) ，或者 appium 中 sendkeys 方法会输入原有字符的原因及解决方案

看了下 github 的 readme ，用法没写，只写了个大概原理架构，所以具体怎么用都不知道，还得看源码。这个有点过于随性了吧，对用户不大友好呀。

理论上，调试取样器只是会获取所有中间变量并打印出来，不会对数据做任何操作，无论有无都不应该影响逻辑。

但楼主的实践中，调试取样器的开启与禁用，确实产生了影响逻辑的效果。这个并非普遍现象，可能和楼主的脚本写法或者待提取的数据，有比较强的关联关系。没有这个脚本和被测系统环境的其他人，连问题重现都做不到，更别说协助定位问题了，只能各种瞎猜。

建议楼主把 jmx 脚本发上来，或者直接去看看 jmeter 的取样调试器源码，找一些源码解析的文章，看具体里面会不会有一些操作相关的逻辑，造成这个影响？

PS：想要获得随机数字作为 id 值，用一个 random 函数就行了，不需要用正则表达式吧？

想问下，你有和一线测试的同学沟通过，了解过他们的具体水平情况，以及日常工作中对接口自动化要能达到的能力要求么？

框架基本完成，但还没能落地之前，先集中精力做落地的事情，甚至包括自己加入到业务团队里，和大家一起做测试并在过程中用自己的框架写接口自动化，让框架产生成果先（脚本你写还是团队写都行，得先有人写出来才能有用）。

接口自动化不是单纯 postman 的东西加上断言就完事的，前面的造数据啥的也有不少要注意的地方，听你说团队都没这方面经验，这个还是需要你加入他们，根据他们实际业务去找到最佳解决方案的。不要刚完成个第一版，想着后续堆功能啥的，作为一个小团队的测开，应该是最熟悉业务的专家型人才，而不是埋头搞平台的纯开发。

具体怎么落地，可以参照前面 5 楼说的。

我是怀疑 postman 做了很多请求的优化工作

不要凭感觉做事。。。你配置个 proxy ，抓下包对比下，不就知道差别是啥了么？然后 request 里面适配下就好了。个人经验，大部分情况下，问题都出现在大家基本都不怎么配置的 http header 里。

其实都是比较常见的问题，提几个建议：

1、不知道你们开展自动化的出发点是啥，重点想要自动化的用例或者场景是啥，预期成果是啥？从十几人的测试团队规模来说，自研一个接口自动化平台并不是一个性价比比较高的方式，根据自己的需求情况，调研后引入开源的进行二次开发适配，性价比更高。

2、任何新技术从零到一的推行，总会有阵痛，总会有比较难适应的同事。这点建议先和老板沟通清楚，从老板角度是期望通过人员能力提升解决，还是降低平台使用门槛解决，这是两条截然不同的路。

3、如果是要降低平台使用门槛，建议界面设计上尽量对齐 postman 这个大家已经养成习惯的工具，让大家平滑过渡，可以帮你省下很多推广成本。也推荐看看纯 UI 操作的 ms 或者 yapi 的测试模块设计。甚至直接用 postman 做接口自动化测试也是一条可选的路。

看起来，像是你平台前端设计相关的问题？request 库基本可以发送 postman 能发的 http 请求内容的，库的能力上应该没问题。

然后接口调试不用这个平台而是用 postman ，现阶段会有什么问题呢？没太理解。调试本身就不是自动化测试，用别的工具也不阻碍用平台做自动化测试吧。

第二个问题，其实也不算是个问题，算是感想。 如备注所说，其实上周我自己没写多少，都看别人写的代码。 网友们推荐的网站看了，推荐的框架也看了，可惜我水平还不够，连说明文档里的示例也没看懂，还要继续努力才行。 周末写着写着代码，突然很迷茫，这个自动化到底是在写脚本，还是在做测试？我是不是明知这个功能是正常的，才去实现自动化？ 于是我又把 Selenium 的文档看了一遍，里面有这么一段话，可能是一种答案，分享给大家。

看了下下面这段英文，大致是在说使用某种把应用模型化的方式，可以尽可能让你底层的测试命令在被测应用进行重构时，保持不变，好像和你说的这个问题不大对应？

自动化的核心价值，在于降低重复事情的执行成本，进而提高后续执行的效率。所以你现在做的事情，很明确就是在写脚本，不是在做测试。什么时候是做测试呢？答案就是执行脚本的时候。

至于是知道功能正常才去写自动化脚本，还是写完脚本去验证功能是否正常，这个就是开发模式上的差异了。大部分情况下，都是前者，先手工测试确认 OK 了，上线交付业务了，再补充自动化，提高后续回归测试的执行效率。而 ATDD、TDD 之类的测试驱动开发的模式，则是反过来，先写好脚本，然后不断改程序直到程序能通过脚本的测试。只是现在能把这个做好的不多（TDD 其实对每个模块做到低耦合要求挺高的），而且由于 UI 自动化本身的特性（需要有明确的界面控件及交互相关信息，才有办法写脚本，基于设计阶段的原型图和 UI 图基本没办法写，不像单测只要有设计阶段的函数定义就可以写），基本上没怎么见到过在 UI 自动化领域实现测试先行。

最后说一句，写脚本这门技能，是任何一个高效率的人都需要具备的能力，产品在 excel 写公式、运维写 shell 做批量处理，都是一种写脚本。不用太纠结它是不是测试，确认他能提升你的工作效率，让你具备更强的竞争力，这个就够了。

解决了就好。以后抄网上配置的时候，建议还是同时了解清楚每个配置的含义，这样才容易留下印象，真的学习到位。

soga，明白。

很详细的技术方案，点个赞。

这个是已经加入到现在最新的 sonic 开源版了吗？

额，这个不是 junit 或者 testng 的锅吧。。。

如果忽略自动化测试结果，用 -DskipTests=true 就好了，这样直接就不会触发自动化测试，省时省力。

然后测试运行结果，是否影响最终的构建结果，一般是 maven 运行 test 的插件决定的，比如常见的 Maven Surefire Plugin 这个插件。不知道你换成 junit 的时候，是不是 maven 对应执行插件也换了，可以看看插件是不是有这方面的对应配置。

针对抓包这个点，按 8 楼的方法，完全可以做成 release 无法抓包，内部 debug 才能抓包的方式，这样并不会影响安全性。实在不行，单独为你这个情况拉一个新分支改配置，打一个特殊包，改动的代码不合并到其他分支上，也没啥安全问题呀。况且还是开发让你协助抓包定位问题的，但又不给你提供便利，这个有点说不过去。

另外，如果复现步骤不复杂，可以直接到开发位置上，开发通过 debug 模式运行这个包，你手动复现这个问题，这样也可以获得更丰富的错误信息，有助于修复问题。

PS：如果你想真的自由地定位问题，拥有代码权限、日志权限，以及了解开发技术，都是很需要的。如果没有这些，你想定位问题，会发现寸步难行。

从最开始的执行用到到设计用例，到简单的自动化用例的编写，然后换了一个模块之后回到最开始的状态，感觉每天的工作都是重复枯燥的，感觉不到自己能够在工作中获得什么收获

这里面有一个比较明显的问题，就是你没有做总结和提升，上一个怎么做，这一个、下一个还是继续这么做。这样自然会觉得自己是在重复了，而且也没有新鲜感。

实际上，就算同一个事情重复做，每一次做遇到的具体问题都不会是一样的，比如大会的议题评审组织工作，每一年都会做复盘，然后在下一年应用上复盘里的改进方案，保持螺旋上升。

能意识到这点是一个好事，从个人经验角度，建议你做 2 个事情：
1、养成做总结的习惯。可以做周总结或者月总结，总结自己这期间做的好的，不足的，以及计划在下一个周期改进的，并在下一个周期真的去改进它。
2、在完成 1 的基础上，定期尝试去接触一些新的事物，给自己一些大的挑战，然后去克服困难解决它，并在过程中不要再想其他类似 “我解决它有啥价值” 之类的会动摇的问题。比如楼上说的找个开源框架自己撸一遍。