首先本人不是专业做测试的，本文内容难免会存在偏颇。但感觉这是中小型企业（或团队）测试人员的痛点。下面内容将根据本人平日收集到的测试人员咨询进行解答，也分享出来看能否给各位解解心宽。

PS: 在这我们先不讨论“谁对谁有意见，故意弄他”、“先入为主”、“消极怠工”等情况，就事论事对提问场景进行分析，thx all。

1. 小公司（团队）虽有测试岗但根本没有足够时间测试，出问题老板又责怪，要如何破局？

答：首先要分析“没有足够时间”的原因是什么，这里大概率是因为项目调研阶段、开发阶段耗费了大量的时间，等开发提交测试时时间不够。这时就会出现“项目经理是否能够把控项目进度”的分支。

若能够把控，要不就加时间（上线延后），要不就加资源（加班或者加人两种手段）。这是最好的结果，但出现这种情况项目经理一般是把控不了的（不然他不会压缩测试时间，你细品）。这个时候就只能跟项目经理协商，这个时候第二个分支又来了“协商是否成功”。

若双方各让一步的情况下一般来说都是能够协商成功的，这个过程中由于项目经理会有绝对权力，因此测试多多少少会被压一头的，这个是正常现象。但如果协商不成功时，测试人员就要守住自己的底线做事了（这里说的守住底线并不是说要有抵抗情绪，跟项目经理对着干）。

譬如：测试范围只能“尽可能”地多，一切都要在保证质量的情况下尽可能地多测。在要求完成时间前2个小时就要给出测试报告，测试报告中一定要明确写上本次测试的范围、开始时间和结束时间、测试覆盖率以及测试结论。若测试覆盖率和通过率没有达到公司对测试结果的最低要求，测试结论应写上“测试不通过，不建议上线”。

要强调一点的是，测试人员应当对测试结果负责，对客户负责，这个是底线。有时候项目经理会因为某些时间节点或者承诺需要强行上线，这时测试人员会出现“是否需要重测”这个分支。

若的确需要重测，那就做回归测试就好（全覆盖重测根本不可能）。这也是提前2小时通知项目经理的原因之一，测试人员要给自己留有余地。并且要在测试报告中说明“此次测试只针对问题进行了回归”，将范围锁死了，别落人口舌。

若决定不重测，测试人员需要项目经理对测试报告邮件进行回复，又或者手工签字确认。这个时候责任风险将转移到项目经理身上，这时当然可以上线（这种情况也确实存在，譬如有些功能虽然还没完善但是赶着要用来演示，同时它又不是特别重要的情况下是可以适当变通的）。

2. 我就一个小小测试只关注面前的一亩三分地就可以了，老板为什么老是对我有意见？

答：如果是这样想的话就大错特错了，你可以看看现在的招聘网站上，甚至去做市场调查。现如今企业对于人才的需求不再是以前的单一需求，而是复合需求。站在企业的角度复合型人才有更高的性价比（除专业性特别强岗位外），说白了就是“能请一个为什么请俩”。

如果你只关注眼前的一亩三分地，做得特别好的时候老板自然没有什么意见，但一旦出现问题了，就会找各种理由挑刺（没办法这是人的天性）。

举个例子，上级领导说要安排各自动化测试任务，你说我功能测试已经很多事情要做了，又要写用例又要评审、又要测又要回归......根本就忙不过来了，哪有时间学什么自动化，学脚本，做不了。

其实这话一听就是不想做，给人感觉就是“做好功能测试就好，其他的我可没办法别来找我”。这时，换位思考一下，如果你是老板你会怎么想？肯定是要不我就换一个听话的，能干的吧。市场最不值钱就是人（一般人），最值钱也是人（人才），你细品。而且“肯做”还不够还要及时响应，但这个话题超纲了不说了。

反正就是一句话老板觉得你“不值”，这个“不值”有可能来自市场对人才需求量，也有可能与你的成长空间有关，他觉得没有继续培养你的需要，培养也需要成本的大哥。

这时候就会有人站出来说，你说的“培养”不就是PUA么，老往你身上压任务美其名曰说给你机会，培养你，我们不受这一套。

是的，这样理解也没错。但凡事都有两面，你回过头来想想自己技能成长最快的那段时期是松容不迫的呢，还是紧张兮兮的呢？

人天性是懒惰的，在高压之下记忆和总结才是最快，最真实的。而且说到培养成本你以为是指给你出去培训的成本吗？这里说的成本是给你兜底的成本，你做错事团队、公司需要为此负责，兜底的成本（这里有可能是钱，有可能是名誉等等），不然你以为是谁给你试错机会。

3. 除了测试的专业技能外，我还需要关注些什么东西？

答：就我所知，测试跟运维可能会较为密切一点，不然也不会有TestOps这样的职位。学基础软件运维基本上就能够应对90%以上的问题。

譬如：SQL脚本编写、常用的Linux命令、Python、Go（有能力可以学学）、持续集成实现以及原理等。

4. 整天让我去学习，学完公司又实施不了，那我能怎么办？这能怪我吗？

答：当然不能怪你了，这个事情跟公司的战略方向和你个人能否有足够的能力推动这件事有关。但是学到的始终是自己的，谁也偷不走你，努力去学对于个人成长还是很有帮助的。他可以是你的知识储备，为你日后的升职加薪，换工面试等都有很好的帮助。

公司实施不了这件事，的确不是归测试去管，说实在的测试也管不了。但是你要想为什么这么好的技术公司就不实施了呢？换位思考一下，如果你是老板，你会做一些你全都不清楚没有把握的事情么？还是那一句你有主动想过去推动这件事情么？

要说服别人手上要有数据支撑、要有落地场景、要有投入产出比、要有达到的效果，最最重要的是要击中上级领导的利益点。譬如：你的上级领导在乎自己声望多于钱的，你要提供已经成功的案例（这个就要你利用自己的时间去实施了），不然他没有办法“吹”啊。如果你的上级是在乎钱高于一切的，你就要在方案中突出现投入产出比是怎样的，是否有成功案例，达到怎样的效果等等，在措辞方面多注意“提升”、“提高”、“降低”、“削减”、“高于”、“增效”等等的这些话语有利于你的方案通过。

5. 项目之初需求根本就没有定好，测试用例要怎么写？

答：不排查某些项目的需求在整个软件生命周期内都是一直在变的，这不是什么新奇的事了。至于如何把控需求这个跟项目经理的能力有关，也不在本次的讨论范围当中。

那测试用例需要跟着需求走，需求变了测试用例当然也需要变化。我的建议是写增量内容，原测试用例不变，新增一个测试用例与其关联即可。关联这点很重要，通过关联关系能够找到链路关系。从而可以得知这个需求或者这个功能“被修改”了多少次，从而体现出测试人员的工作量并且还可以将修改内容留底。这条链路或许会成为日后对质的“证据链”也说不准。

有的人会说关于需求的修改项目经理不是也有记录吗？不用测试自己来保存吧。坦白说，别人怎么干我们干预不了，也不可能要求别人怎样配合自己。所以万事要不求人的同时也要留个心眼，用于自保。

6. 测试的效率工具有哪些？

答：Jira工具虽然成熟且功能强大，但是过于复杂了。

所以选择了禅道开源版。其实什么工具都没有自己的大脑好用，工具只是用于打通数据壁垒而使用的，至于“效率”从本质上并没有太大的差别。

或许还有更多好用的工具，我这边没有发现到而已。

7. 老板资源上不重视测试，但有锅就测试背怎么办？

答：这个跟第一个问题有点类似，但在那基础上首先先了解一下公司里面是否有测试相关的测试流程或者规范，我建议是仔细研读一下里面的内容再跟老板谈谈。因为有很多时候不理解是因为信息不对等造成的，尝试减少这种信息差。

另外，建议每年都对流程规范进行修订，在实施的过程中吸收经验教训逐步完善即可。

最后，要给老板“上一课”，陈述利害关系，还是那一句要击中对方的利益点，不然还是会不为所动的。

若老板同意执行后，你要担起牵头人的责任，做好落实、跟踪、抽查、管理工作，这过程中一定会受到阻力的这个很正常（发生变革伴随而来的肯定是震荡，一发生震荡肯定有人就不舒服的了，所以阻力肯定会存在）。是否能够继续落实下去就要看你个人的手段了，因为老板同意执行他只关心结果，过程只能自己把控，别指望他能够给你更多的力量，他只是赋予了你执行的权力而已。

8. 测试人员如果要转型有哪些岗位适合转型？

答：转岗这个话题比较敏感，其实转岗分为自愿转岗还是被动转岗。自愿转岗的就不讨论了，因为是自己的意愿做什么岗位都合适的。问题就在于被动转岗的，被动转岗证明你其实并不适合做测试。但是有鉴于你长期做测试对于业务流程和操作都比较熟悉，那么无非就是转入业务部门的几率会高。

客服、售前、售后都比较合适。

以上就是所有内容，只代表个人立场，不想因此引战各位看过一乐就完了。