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

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

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

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

把使用中的问题记录下来，并表述清楚这些问题严重影响效率，然后反馈得领导，借助领导的力量去推动平台维护方解决。当然就算解决确实不及时，也先用一段时间吧。

其实你第一句已经说的很清楚了，领导要强推这个测试平台（都和绩效绑定了，足够明显了吧），不管好用不好用都得用。那你的沟通就应该要先遵循这个大方向，然后在大方向下提问题和寻求解决方案。你提出用开源框架，和团队的大目标不一致，当然会被否决。

这是个开放性问题，更多看的是你的思考高度和对自己任务的理解。不知道楼主面得是什么岗位，如果是中级或以下，我觉得这个回答还算可以，不至于会直接否决。

如果楼主想复盘为啥面试没通过的话，建议还是综合评估，不要只是看这一个问题。对于这个问题，不同级别、不同业务领域、乃至于不同公司文化下，都会有不同的答案，没有标准答案的。就算有，那也不一定适合每个人，这里问的是个人的理解，而不是教科书标准答案。

实在改变不了环境，那就换环境吧。

你单独建个帖子，把你的详细操作步骤也补充贴上来吧。

光这样一个截图和错误日志，不好定位问题。我现在已经很少用 repeater 了，也没熟练到直接看日志就看得出问题的程度。

@A.D console 启动了么？文章顶部 console 相关的配置都配好了吗？

PS：请使用 markdown 排版

入网验收，入的是啥网？可以提供除了这 4 个字之外，更详细的描述么？

我能想到的就只有工信部对手机的入网验收，但不知道你说的是不是这个。