测试任务的多样性、组织人员流动以及人员技能备份、测试工作节奏等因素决定了一个测试人员不可能一直做着自己熟悉领域内的测试工作任务。一个测试人员需要经常性的接手完成你不太熟悉领域、不擅长的测试任务，如何在任务要求的截止时间内有质量的完成是一个硬实力和软实力结合的技术活。今天小编就为大家聊下这个话题。

通常来说，大部分任务到某个测试人员身上都是任务驱动的。可能当测试任务来的时候，熟悉该项测试工作的A正在投入某项紧急任务中无法投入，领导自然就会将这个测试工作安排到不熟悉或者完全不懂的B身上。你说B可以以自己不熟悉该任务拒绝吗？拒绝是不太可能的。测试工作中有太多类似的测试任务了。每个人都拒绝，活就没法干了。每个人都永远干自己熟悉的测试任务，人员技能也无法备份。。这些因素是后话不讨论。通常来说，这种不太擅长的任务你还是得接手，不仅要接手，也不要有太多的情绪，别活还得干还让领导觉得你挑肥拣瘦就得不偿失了。想办法怎么在规定时间内质量完成是你要考虑的问题。有事别怕事，下来想辙就是了。

一个不擅长的任务接了又得把它干好，这是个技术活。这时候每个人处理的方式就不一样了。首先，接收测试任务的时候一定要先了解清楚任务的背景、任务完成时间、任务相关责任人。我就以我自己和身边所看到的同事举一两个例子。从我自己来说，这种任务没啥毛病，但是我不喜欢那种要求时间很短又很不擅长的测试任务。一个是本来就不熟悉风险无法评估、质量不可控，第二个时间紧急压力大容易出问题。但是通常这些都不是理由，还是得去完成并且不出问题。

了解清楚之后，就开始干活。在了解清楚任务的背景、任务完成时间、任务相关责任人，下来就需要了解测试任务本身内容了。只有了解了测试内容，你才能相对合理评估测试工作量、识别测试风险、哪些需要提前求助、是否需要提前上升。

　既然知道问题所在，任务要做也要让自己心情保持好一点。不然会经常感觉在受苦。太苦逼了。需要改变一下自己。从个人层面来说，需要自己基本过一下测试内容，然后在规定时间内（比如不超过30分钟）让之前搞过的同事讲解一下重点、可能的风险点、之前遇到哪些问题需要提前去问、去了解的。这样基本框架就有了。下来就自己好好了解一下内容，有风险的提前上报、有疑问点的记录后面集中拉一下释疑。另外，每天及时反馈进展、反馈阻塞点、风险点，让领导知道情况。另外，从组织层面来说，如果是一个后期较长的测试任务或者外地出差的测试任务（比如半个月一个月），需要安排好测试任务相关责任人，明确问题接口责任主体和职责，遇到问题可以让测试人员及时找到求助对象，及时推动问题解决。不然所有问题让测试人员都自己临时去协调，可能找不到也可能找到了别人没时间支撑拒绝。会让测试人员很心累，次数多了，就容易出现人员稳定性问题。

　　另外，测试任务完成后，自己一定要注意测试经验积累，多写一些经验文档，包括环境操作、问题FAQ、测试技巧、业务逻辑、测试问题以及解决方案等等。不要觉得不重要，一个很小的问题FAQ可能就会导致后续的人阻塞很长时间。重视这些经验文档积累，对自己、对组织都是一个很重要的财富。想想自己这么痛苦搞着这件事，后续同事继续搞这些事情的时候使用这些文档就可以起到助力作用。