導讀：測試任務的多樣性、組織人員流動以及人員技能備份、測試工作節奏等因素決定了一個測試人員不可能一直做著自己熟悉領域內的測試工作任務。

一個測試人員需要經常性的接手完成你不太熟悉領域、不擅長的測試任務，如何在任務要求的截止時間內有質量的完成是一個硬實力和軟實力結合的技術活。今天小編就為大家聊下這個話題。

通常來說，大部分任務到某個測試人員身上都是任務驅動的?？赡墚敎y試任務來的時候，熟悉該項測試工作的A正在投入某項緊急任務中無法投入，領導自然就會將這個測試工作安排到不熟悉或者完全不懂的B身上。

你說B可以以自己不熟悉該任務拒絕嗎？拒絕是不太可能的。測試工作中有太多類似的測試任務了。每個人都拒絕，活就沒法干了。每個人都永遠干自己熟悉的測試任務，人員技能也無法備份。。這些因素是后話不討論。通常來說，這種不太擅長的任務你還是得接手，不僅要接手，也不要有太多的情緒，別活還得干還讓領導覺得你挑肥揀瘦就得不償失了。想辦法怎么在規定時間內**質量完成是你要考慮的問題。有事別怕事，下來想轍就是了。

一個不擅長的任務接了又得把它干好，這是個技術活。這時候每個人處理的方式就不一樣了。

首先，接收測試任務的時候一定要先了解清楚任務的背景、任務完成時間、任務相關責任人。我就以我自己和身邊所看到的同事舉一兩個例子。從我自己來說，這種任務沒啥毛病，但是我不喜歡那種要求時間很短又很不擅長的測試任務。一個是本來就不熟悉風險無法評估、質量不可控，第二個時間緊急壓力大容易出問題。但是通常這些都不是理由，還是得去完成并且**不出問題。

了解清楚之后，就開始干活。在了解清楚任務的背景、任務完成時間、任務相關責任人，下來就需要了解測試任務本身內容了。只有了解了測試內容，你才能相對合理評估測試工作量、識別測試風險、哪些需要提前求助、是否需要提前上升。

既然知道問題所在，任務要做也要讓自己心情保持好一點。不然會經常感覺在受苦。太苦逼了。需要改變一下自己。從個人層面來說，需要自己基本過一下測試內容，然后在規定時間內（比如不超過30分鐘）讓之前搞過的同事講解一下重點、可能的風險點、之前遇到哪些問題需要提前去問、去了解的。這樣基本框架就有了。下來就自己好好了解一下內容，有風險的提前上報、有疑問點的記錄后面集中拉一下釋疑。另外，每天及時反饋進展、反饋阻塞點、風險點，讓領導知道情況。另外，從組織層面來說，如果是一個后期較長的測試任務或者外地出差的測試任務（比如半個月一個月），需要安排好測試任務相關責任人，明確問題接口責任主體和職責，遇到問題可以讓測試人員及時找到求助對象，及時推動問題解決。不然所有問題讓測試人員都自己臨時去協調，可能找不到也可能找到了別人沒時間支撐拒絕。會讓測試人員很心累，次數多了，就容易出現人員穩定性問題。

另外，測試任務完成后，自己一定要注意測試經驗積累，多寫一些經驗文檔，包括環境操作、問題FAQ、測試技巧、業務邏輯、測試問題以及解決方案等等。不要覺得不重要，一個很小的問題FAQ可能就會導致后續的人阻塞很長時間。重視這些經驗文檔積累，對自己、對組織都是一個很重要的財富。想想自己這么痛苦搞著這件事，后續同事繼續搞這些事情的時候使用這些文檔就可以起到助力作用。