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

我的建议是，既然平台已经花了不少精力做出来了，不妨先做一阵子实际推广，也借机了解下大家实际上对于写 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 个开发找一些来执行一下测试）。

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

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

rest-assured 挺好用的。

哈哈，这个前几天我们公司内部技术群也有在传。整个过程和原因复盘都非常详细，很值得学习。

先说下简历：

整体看完后感觉：应届生常见的 学生干部经历、获奖经历、内部学校项目经历 基本没有，大篇幅的项目经历也没有一个能打的（项目经历不是越多越好，1-2 个但能体现你能力最强的一面就足够了）。

1、项目经历看似很多，但都比较简单，多而不精。而且你这里附上了代码仓库，大概率面试官会去看具体代码情况，如果写得不咋地或者用例数量很少，可能反而是扣分项。不知道是否方便公开下代码仓库？

2、简历上看，感觉像是面向自动化测试岗的，而非业务测试岗。而且你的项目经验看起来并非是公司工作经验，而只是自学经验。大部分情况下，自学经验是经不起推敲的，只能作为加分项，不适合作为基本盘，因为自学项目相比实际工作项目，复杂度低太多了，只能用于辅助了解技能学习程度，无法认为有工作经验。所以如果有工作经验，尽量突出工作经验，而不是自学经验。然后学下 STAR 法则，用符合这个法则的方式去写工作经验，不要单纯只是说做了啥。

3、专业技能里，“了解掌握” 到底是了解还是掌握？两个要分开，不要合在一起。“Redis 数据库” 这个，redis 不是数据库呀。

然后简历之外，有几个建议：

1、你目前是已毕业还是明年毕业？现在行情，从学校里招人，测试岗实习比直接招应届性价比更高，所以大多是直接实习转正。直接招应届生的，你这里面没有相应实习经验也会比较吃亏。

2、你是下定决心做测试吗，还是只是权宜之计？如果并不是下定决心做测试，更建议你去针对面试中自己答得不好的地方，去进行针对性学习，深化自己的开发能力，走开发路线。

比如你在测试注册接口的时候，会由后端发一个手机验证码，这个验证码你很有可能会通过查数据库的方式去获取，否则你就很难进行下一步操作。

挑个小毛病，这个验证码只是临时数据，基本不会是存数据库吧。

另外，标题里 “应不应该用数据库” ，这里的 用 字很奇怪，很难理解。从文中的内容看，应该主要是说应不应该涉及数据库吧。