@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 的基础上，定期尝试去接触一些新的事物，给自己一些大的挑战，然后去克服困难解决它，并在过程中不要再想其他类似 “我解决它有啥价值” 之类的会动摇的问题。比如楼上说的找个开源框架自己撸一遍。

wifi 连接稳定性如何？

问题梳理得非常详细，点个赞。

楼上对于这种情况已经有很多建议了，我就不再重复了。楼主这种情况我理解其实并不算迷茫期，更多是工作内容和自己预期差异太大，做起来既辛苦又没有成就感，所以对是否要继续下去产生很大的动摇。

以前也曾经有过一段时间是处于这个状态，在团队里是唯一的测试，给测试提要求的是开发，而且有些要求相对来说会比较笼统（比如通过前置接口自动化测试，保障客户端和服务端联调时不出现问题），每天花比较长时间去测试，但还是无法保障到位。最后是因为团队工作内容调整，换到了另一个项目的测试团队里，才跳出这个困境的。

所以，建议楼主可以先针对上面的问题逐条想一下，自己是否想要去逐个突破，逐步建立流程和解决你提到的这些问题。如果觉得已经身心俱疲不想突破，那就出来投递一下简历，看能不能找到更适合自己的吧。

嗯嗯，这个确实是社区组织的。

@kasi 卡斯看看？

你具体说的是哪个微信群，群名字发一下，我们先确认下是不是社区组织的群？

项目负责人在做排期时压缩测试时间，该怎么说服 ta 给到足够的测试时间

这里没有怎么压缩的细节（比如是测试给出的排期计划有些模块测试时间他认为过久所以压，还是啥细节都不看无脑压），不好说怎么说服。

结合你提到的这个测试跟着项目走的背景，以及项目负责人认为效率优先牺牲质量，那大致能理解项目负责人压缩的出发点。建议是和项目负责人沟通清楚，如果按这个时间，测试只能保障到哪些核心内容，哪些部分无法安排测试会有风险，如果项目负责人接受，那就按这个来走，出问题就拿这个东西来说明这是项目组决定的，有锅一起背。如果项目负责人觉得风险太高，但时间不能延长，那就从别的地方抽调资源来支援（比如这 8 个开发找一些来执行一下测试）。

这和自己想要保证质量是相悖的，但想要快速上线也只能牺牲质量在后续迭代再来弥补，说到底可能还是对质量不够重视

这么说吧，新产品还在求生存的时候，质量只需要保障够用就好，速度高于一切。重视质量细节只会出现在业务已经相对稳定，需要进行用户体验等细节打磨的时候。甚至有的产品其实还在小规模内测/公测阶段，质量要求可以低到只要冒烟测试能通过，就可以上线。公司生存靠的是业务，所以有些时候还是要结合业务来决定质量要求。