可以帮忙写单测

感觉看到了曾经的自己，哈哈

一开始我用的 unittest 框架写自动化脚本，跳槽以后心血来潮，想试试 jmeter，看看投入成本和产出是否成正比，也用 jmeter 整过接口自动化测试，写完第一版就发现维护成本很大，各种检索不便利，也没啥全局替换的功能。

接着继续研究数据驱动，能否有效的提升测试脚本编写效率，如果是简单的 http 接口做点数据驱动效果确实明显，但如果遇到组合场景，不同协议的比方说 socket tcp udp，又或者说需要做参数转换参数加密，实现一些数据驱动反而新增很多框架 bug，投入的时间成本反而增加。

之前也有搭过一整套自动化生成测试脚本的，只需要编写 excel，把所有服务交互的信息列出来，把所有输入输出分类好，base 概念，精准校验哪部分内容，还衍生出 AVU 的概念。那个 excel 是真的复杂，找个 985 高材生也要熟悉一个星期，才能介入进来，理解成本很大，框架搭建时也发现很多 bug。

后来跳槽到这家厂，经常要做各种服务交接工作，有交接过 rf 的脚本、pytest 的脚本、unittest 的脚本或者没框架的脚本，现在编写脚本更多的是考虑快速定位、报告可读性、源码阅读成本。还是用回 unittest 的框架，引入比较基础的数据驱动，定义好团队编码规范，编码量虽然比之前数据驱动那些多，但时间成本反而更低，复制粘贴 2s，改个描述参数 30s，一条 case 就出来。

接口自动化除了脚本框架外，核心其实还是用例设计，怎么设计用例才能保证代码覆盖率，更细粒度的场景能不能自动化，比方说服务与三方服务的异常交互，这样就衍变出单服务的自动化测试及测试思维，从单服务入手也能模拟各种故障演练，有时间的话可以研究研究这部分，比研究框架更有价值，框架够用就行。

有研发经验转研发 不算测试转研，这种按正常的市场行情算就可以。如果是纯测试转研发，能平薪转拿到 offer 就已经很好了。

请奶茶喝就行，最好星巴克这些，贵的深刻些

appscan 有个策略选择，你在里头勾选就可以，扫描时还要保证有覆盖到所有接口。之后遇到安全问题，根据描述去复现场景，复现出来记 bug 就可以了。不过 appscan 扫不全，可以扫些注入漏洞、xss、csrf，一般还需要补充些必要的安全测试用例直接手动测试，比方说越权场景、强刷（校验是否上锁）等。

每条消息都尽可能校验下，消息数量也是测试点，还要考虑时序、状态、消息丢失处理等情况

测试的定位就是保障质量，做好质量管理，可以推动质量前移后移事项，做到降本增效，要测试去搞钱那不叫测试。

对，可以照顾到编码能力欠缺的同学，在 ride 中把方法和类当作控件来使用，不然还是用 unittest、pytest 啥的舒服多

在大企业里有这么个东西来保证员工学习的驱动力，通用能力 - 学习能力、创新能力，作为晋升、加薪的标准之一，没有进步的同学自然会缺少更多的机会。

建议早点脱 RF 的坑，很多适配兼容问题，gui 界面可读性也差，脚本交接就会发现很多问题。

--------------------被 rf 伤害过的男人

和 3L 的建议一样，流程规范和开发自测分为两个事项来整，流程规范设好交付卡点不需要卡用例设计这块，比方说用例代码覆盖率、单测覆盖率、bug 激活率等。

开发自测用这种测试分享的形式可能没啥效果，可以定义好自测规范，自测的颗粒度、自测用例过审，像我们这的开发自测用例还是让测试提供，接着测试就做甩手掌柜。

"再写一个对外的微服务专门用来做测试"
可以写一个通用桩来解决，client 桩、内部服务桩，内部服务桩用来做依赖服务的 mock，每个服务都可以细致化的来测试，之前我们这么测代码覆盖率可以跑到 90%+

别恶性卷，从你的技能描述上大多是会写个 demo，只会写 demo 在面试时很难作为一个亮点，像接口测试只会简单的工具使用可能都不清楚接口的用例设计方法。
学得杂没用，我建议你选一个技术栈玩到深，能真正落地，能对团队创造实打实的价值，能作为团队的测试规范去展开，比方说接口测试，有自己的用例设计思维，能保证代码覆盖率达到 70%+，完成接口测试后进行的页面功能测试，没有后端 bug，基于 XX 实战接口自动化，并部署到 jenkins 实现持续集成，降本增效。
有亮点在竞争者中才显得差异化，跟面试官直接说 1 个我能顶 3 个点点点测试，怎么可能只给你开 6K。。。

团队中有落地的单体服务自动化测试方法吗

这种情况我一般不死磕，直接校验视频资源获取状态码 200。

这个是个练手的机会，目测之前没有专业的测试主管在管理，你按 4 楼大佬说的去做就行，最后结果可能是全系统需要重新测试，需要更多的人力，做着做着就成主管了。

挺羡慕能够按部就班的，楼主生活肯定很幸福。

看得出楼主在当前公司有落地一些有价值的事项，但简历整理得很烂，“主动学习”、“承担” 这些不应该描述出来，重新整理下，公司的相关经验可以分为岗位职责和落地事项，个人技能这块应该配合对应事项描述出来，比方说 “有一定的 java 基础，能配合开发定位服务日志，能自行辨别 java 空指针报错信息”

给个建议，找个心意的岗位对标着技能去整理简历，精进对应的技术栈，不要想着自己的技能值多少钱，要看的是你会的东西能给公司带来多少价值，比方说有的公司想招安全专项的测试，你就要尽可能体现安全这块的亮点，玩转 Burpsuite、owapsTOP10 的举一反三、能提供规范化的安全测试报告这样，这样即使你只会安全这块，也比会杂七杂八的测试要更有竞争力，性价比更高，要个 20K 也不是不可能。

比如说之前只建了 1 个 jenkins 任务跑，根据需求拆分成 10 个小需求小项目，建 10 个 jenkins 任务跑。

我觉得问题 1 有个点必须带上，线上 bug 复盘，再拓展下解决问题的能力，问题的快速定位、如何减小影响面。

问题 2 竞品维度是一个点，还可以先在公司内部推广使用，收集反馈，或者找个该产品的小白用户试用下，他们提出的体验问题质量很高。再进阶点就得学习学习用户体验相关的书籍或课程，也能从中取些经，从更细粒度去看用户体验，比如说按钮的点击效果。

赞成 2 楼和 6 楼的观点，再补充个方法，400 个 case 可以再根据业务细化开来，分成多个任务去执行，比如说 400 个 case 分成 10 个小业务去跑，效率提升比较直观 3.5h/10

我也想申请开通专栏，打算输出服务端专项这块

看来槽神也深受其害

那你作为一名开发跑来测试圈里吐槽，内心确实挺明亮的，在这答非所问，他只是说在平常的会议中突然被关系好的开发被刺，并未吐槽开发的不好，想表达公私分明的态度吧。

你想了解我们怎么吹牛皮，可以多看看论坛里的精华帖，像你这种有技术底子的肯定看得懂吧。