回复：这是关于一个菜鸟测试入行一年多以来踩坑吐槽，心得感悟的记录贴

入职手续技巧？
这段主要是给第一次入职的测试新人聊聊社保记录，银行流水，离职证明，这些资料怎么搞？
社保记录可以先找个你简历所属地的人搞个电子版出来，然后你再花点钱去某宝P一下，P到和入职信息保持对应就行了。银行流水道理类似，同样PS大法搞定。
离职证明的话，就是网上找个好点的离职模板，然后某宝找个刻章的店，做个离职公司全称（最好和网上能查到的公开信息对应一致的名字），然后盖章的时候，用点力，印迹清晰点。还有个注意点：盖章的时候别太正了，倾斜一定角度，再盖更自然。离职证明那张纸记得折几次，别弄得像刚打印出来的样子——！
其实呢，这些东西也就是走个流程，公司真要细究，你怎么造假都是白费功夫，分分钟查出来，只是公司懒得细查而已，毕竟他们的目的是招人来干活的，你能干活就行。

评审的心得：大家都是干测试的，评审用例肯定是跑不掉的。我提几点技巧。尽量精简表述，不要一个用例一个用例地读，然后具体的模块和路径最好加粗标注出来，念的时候自己和听众更容易弄懂这条用例是在说啥内容，不然太多用例了，有的功能相似，你自己念着念着都不知道是在说哪个功能了评审之前你自己最好先一个人试讲一遍（特别是初入行第一次评审前自己试讲一遍很有必要）多试讲几遍你就不紧张了，把试讲时一些卡壳的地方写清楚，评审的时候听众体验才更好。就我得到的反馈来看，Xmind的形式我看更容易被听众接受，所以可以写简洁点，不用写得太细。excel用例因为文本表格形式不直观，很枯燥，评审体验不太好。当然，相对而言，我觉得excel形式的用例更适合执行的时候用

测试用例的心得（这段主要还是写给才入行的菜鸟，对写用例不熟的这部分人）：除了需求文档里的功能点需要覆盖全面之外，一些不重要的小细节你如果觉得不清楚也最好还是找产品提前沟通好，免得漏测。然后写的时候，多用点综述性语言。别太细，不是特殊说明的字段，你也没必要每个都单独拎出来写用例，那就太啰嗦了。
关于用例的一些细节：一些容易忽略的功能要闭环，弹窗打开了，那关闭弹窗那个按钮功能也得写到吧。再比如转账，你转了过去，不仅你钱包的钱减少了，那对方收了后钱也相应增加了，你不能只测单方面的数字变化吧，然后收了钱那转账记录也该有，对吧。每个操作导致的所有变化你都得落实到用例上，不能漏，都得测试到位，要保证功能的闭环。
然后综述性的话。查询术语你可以浓缩成置空，单一，组合，精准，模糊，查不存在的条目这些。必填非必填这些你可以和提交按钮写在一起，有多种输入条件的，没必要每种输入都写，来得方便就可以综述成不同条件排列组合一条用例就解决，当然这只是站在用例层面上来说的，实际测试又是另一回事，条件你也得都尽量覆盖到。再比如某个输入框不支持某类型字符，直接可以综述成是否过滤非法输入，工作中没必要把大小写字母，数字，汉字，特殊字符还分开拆成用例。总之就是用例的颗粒度没必要弄太细，不然写得很痛苦，除非你想凑多点用例搞形式主义给别人看那又是另一回事，工作中我的宗旨是在不漏测试点的情况下，尽量精简用例，太罗嗦，颗粒度太细，你写得痛苦，评审的人听着也痛苦。Excel里的用例，像同一个功能，比如查询，可以把情况都写在一起，执行步骤啥的，标个不同序号，每一个序号代表不同的测试方案。①单一查询②组合查询……就这种，预期结果也标号对应就行了，不用分拆出来，这样的好处是用例看起来结构更合理，更清晰了

现在楼主工资多少了，在哪工作

和开发的交互：
这里主要是针对刚入行的菜鸟，能自己定位的尽量自己定位，实在搞不清前端还是后端的但又怕指错人挨怼，你可以先找和你相对更熟悉更聊的来的开发，演示给他看。开发判断后就稳妥了。前端和你更熟悉找前端，他看了演示排查到的是后端问题，那就指给后端。后端和你更熟悉你找后端，演示后排查到是前端问题，就丢给前端。其实定位bug这事多请教几次开发，你自然也就会了，也没多难，主要是本来该在入职前就掌握的东西你没掌握到，工作起来就很尴尬。总之就是，技术不行，那就人品来凑，平时能处好关系就处好关系，开发和测试的关系一旦弄僵，工作那是相当难受的。像我除了经常找开发吹牛闲聊，逗闷子。再比如写提测单这种小事，本来是该开发做的事，但我一般免费帮他们写好，反正也花不了多少时间，像开发的话，平时开发任务重，空闲时间少，所以你作为测试在开发期反正也闲，能帮点小忙就帮帮呗，事虽然小但很能增加他们的好感。

大佬，我现在也在成都，想从室内转测试得不得行啊

楼主，有交流群嘛

很像三年前的我

偶尔自顶

顶