现在从填报专业到选择就业完全处于没有任何情报支撑的情况，出来以后找不准自己的定位很正常，换个角色换个视角是一个方法，建议可以先维护一个 github 投石问路，看看自己是否真的适应开发的工种再去针对性的学习课程，能找到一份好一点的工作

人在杭州，超想去，请问会后可以索要相关资料吗

1. 测试从按次测试改成按轮测试，整轮开始之前记录版本号，整轮结束之前不接受提交代码修改
2. sonar 规则扫描，每次出问题花时间跟到代码层追溯，整理成 sonar 的规则；建议初期用 findbugs 排除低级错误
3. 测试过程数据分析：建议全部测试开始前清理掉数据库和日志，测试过程中全部保留，最后测完之后分析，比如测试环境限制了邮件发送，那么发送记录表里面就不能有成功的记录；再比如主数据与关联数据关系应该是 1:3，做个联表 group 找找有没有关系不对的；日志里面所有的异常必须全部过一遍、另外，对各个流程节点关键日志进行统计，在某一个节点数量大幅增加的可能就是有 bug 的
4. 推动 jenkins 和 docker，部署脚本建议测试维护，确保上线环境与测试环境一致
5. 埋点提前预测线上 bug，这个一两句很难说完，建议自己查资料

我有过这种经历，但是试着反过来考虑一下，如果你的上司什么都答应了，那你推动任何事情都会被开发各种甩回来还甩你一句你老大答应了啊或者你要不好说话我就找你老大了，你更郁闷，这个世界上当好人永远比坏人容易了

当然了，不是说完全顺着自己的脾气来了，我觉得你的主管既然还在这个位置，那就是说至少他的做法在这个环境是适用的吧大概，人家也是被逼的

Postman,Charles 都有 mock 功能能做到这点

因为之前有人问过我相同的问题但是当时我没答上来，这里放一下我自己总结的请大家也帮忙看一下：

1.测试平台的出发点：经验分享、标准统一、便于量化执行
2.好的测试平台需要关注的点：
针对主营业务近几年的发展已经和将要遇到的问题，能不能起到正确的引导方向；
如何去考核平台对执行效果的影响（问的人看来有相当的眼界和水平了，第三个问题实际上是第二个问题的答案）；
平台推广的方案
3.平台对效率的提升，实际上这个问题完全取决第一个问题有没有答到点上，如何量化看第二个问题的回答

需求问题，明确本期的建设目标，别什么都压在这一期，要划出基线；

过程中有共性的问题，举一反三，别一个地方数值不对相关的部分就放过了

另外，本期风险较高的，比如框架改造、对外接口、不合规的调用、自定义的控件交互等等可能要反复回归的，优先自动化，别一直功能测试

还有，每天八小时，最少留一小时总结一下，别死干

“你用自动化解决过什么问题”，我面过多数做过自动化的测试，都答不上来；

关于这一点，我觉得作为 QA，让公司认识到自动化的价值本身也是我们的工作之一。认为自动化达到天花板的，请问你有认真的评估过目前的行业都会遇到哪些问题吗？

首先，测试开发比的下降，自动化是一个方向，但是只靠 web、APP、UI 等他能带来的下降是有极限的，随着系统的扩张，还是需要进行进一步抽象和框架性的优化的，当然，这需要了解这些技术的同时也要熟谙业务

再一个就是解决的问题深度；接口 Web 和 APP 测试，我认为只是前人把自己遇到的问题抽出公共的部分，不同行业还会有多得多的问题，比如游戏中难度设置的测试，又比如法务领域的合同文本关键点标亮，还有金融领域的高频交易问题等等，不通过建模和算法辅助去预测和实践，根本无从入手

自动化的价值核心，并不在技术和工具本身，而在于方案

当年几个人创业做手游发行，一个 JENKINS，一天出去 400 个包就一个测试，如果问小厂用不用得上自动化，我认为得看决策者的眼光

基本还是造数据调接口返回断言这个套路，不过调用的部分是 socket 协议，没有 http 的头什么的，需要注意报文长度等等

然后如果用户量大的话还需要考虑压测，强联网的需要特别关注心跳包那里

坑满了啊，只能说没赶上好时候了，然后
需要注意技巧，一般内推被拒之后 HR 给推荐人的说法都不会太好听的，所以你朋友有可能照顾你的感受就没说；当然还有另外一个可能是你被比你朋友更高的岗位相中或者是被和你朋友不对盘的部门看中了；
建议是一起喝一杯大家高兴的时候再问，一开始可以大吐自己的不足，铺垫的差不多以后再问问看是不是什么条件再好点就好了

主要目标是排除掉你简历的地雷，不然以后好点的岗位还有可能遇到这个情况；如果是学历等硬件条件不合格，就需要了解一下是不是这行业所有岗位都有这个要求，如果是就要考虑报班自考或者换行业了

问问看 HR 拒绝的原因，我觉得你的简历可能有致命问题；
另外问问推你的人有什么建议

最后就是建议调整好心态，内推的机会并不多，就算没有面过，也要弄明白为什么不过，应对上按写用例的思路多设置几个留心的点，着重了解这个公司的规划方向以及自己能在这个方向做到什么；如果你不过压力最大的其实是推你的人，无论结果如何注意沟通的方式

预祝顺利

所有面过的人都好有才，这个算是动力吗

人家估计也有人家的考虑了，能干上这个级别的工作本身情商不太可能差到这个程度；

我觉得，如果楼主描述的没问题，坑已经满员了或者薪酬谈不拢的可能性比较高，建议先了解用人单位的需求；

另外，楼主的表达方式建议调整一下，如果一定要写明面试的岗位，措辞尽量还是要留有余地，不然有考虑过同行业其他用人单位看到这个贴子人家怎么评价你吗，何必把自己的路堵死了呢

笑而不语

很实在很有触感的一篇文儿，学校的时候学的挺苦的觉得出来就应该牛逼了~结果瞬间打脸；10 年赶上移动支付转型移动端觉得自己挺牛的，再次瞬间打脸，最后连公司被清算了还一脸蒙逼；

情报对技术人员来说比其他的什么都重要

……300 行，好难维护了

如果是发布周期比较长的业务，这个方案能出成果，如果是多变的业务建议先考虑成熟的框架中适用于你当前业务的

建议在工作之余尝试一下，直接上手框架经常出现为了用框架而做自动化的情况。

。。。这里有几个不是接口测试工具吧

如何选择这一点上，感觉是看项目规模和人力的现状吧

一般场景的话，个人推荐 Postman，因为功能齐全上手也快，支持录制和 MOCK，而且人还好招
但是应对字段复杂（一个接口上百个字段、或者每个字段之间有条件非空枚举）的情况下，上面几个工具都会有点不足了，建议异常的场景走单元测试

分享一下之前的经验：

1. 样式：
   字体：机打单据需要覆盖包括宋体、黑体、微软雅黑等字体（视业务需求），手写单据需要到业务人员中采样
   宽度：如果是等宽字体只需要覆盖通常情况即可，但是如果是非等宽字体，例如 “长 12” 这里，汉字和数字宽度不等的，需要对不同宽度覆盖
   全角半角：如果需求有，那么需要两边都覆盖

2. 取值范围限定的字段需要保证正常识别
   例如：是否有 XX 记录、费用归属月份这种

3. 数字需要保证识别正常，尤其是价格、时间、电话这种

4. 上下承接关系的字段需要保证识别正常
   例如审批流程的节点名称

5. 如果单据中有需要根据空格、表格或者逗号拆字识别的字段，需要明确需求后注意单独写用例覆盖
   例如： “李总 1988-01-01 审批通过”，“2017-12|12|31|33”

总结：大多数人员对 OCR 这个技术理解有问题，OCR 识别率不是 100% 的，尤其是中文，人名、长句子、生僻字、换行段落、标点、公式识别错误非常普遍，如果文件本身包含图片的话结果惨不忍睹也是正常情况，需要保证技术能保证的部分，技术无法实现的部分不要深究！！！

学习