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

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

看来槽神也深受其害

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

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

“产出 ≠ 苦劳”，回答的很清晰，很专业

“做的工作说的是什么自动化测试，其实就是鼠标点点点”，当你说出这句话的时候就知道你对测试有非常深的认知，我就好奇这么懂测试的人能写出啥内容，简单看了下回帖全都是唱衰测试，也看出来你测试干了好些年，从你输出的干货能感觉到你比国内 3 万家互联网企业还懂测试。

说实话，这跟你们记多少 bug 没啥关系，测试资源这块确实没利用好，4：3 比例确实很高，像这种新需求、迭代快的真不建议搞 ui 自动化，耽误交付时间不说，产出也不明显，ui 自动化测试只是保障线上巡检和回归测试这块，是很难被认可的，大厂都支撑不了这样的资源消耗。

我建议调整下测试策略，先保障需求按时发版以及线上无严重 bug，联调时就能介入接口测试，接口自动化和接口点点点耗时差不多，等前端提测后点点点再介入，需求按时发版且无其他需求提测时，再分配到 ui 自动化，不能算在发版计划里头。从老板角度，测试的作用就是保障线上的稳定，给你人力也是为了需求按时上线，像性能这块耗时长的话可以往后放，线上真遇到性能问题也有研发的锅

测试学了主要是能介入 go 项目的单测，也能做些服务 mock 测试，还有就是性能测试工具，如果只是做些接口层的验证，python 足够，用 go 写的话之后交接可能没人接得住。

从语言来说 go 性能比 python 好，比 java 容易写（性能：java>go>python）

从受众程度来看，java 开发岗与 go 开发岗的比例大概有个 10:1 这样。

如果你时间充裕的话其实可以研究下 go，最好造些轮子，这样你就是先行者