回答：本期話題分幾個要素點，我將根據命題劃分的幾個關鍵詞：緊急情況，壓縮，測試周期，來一起分析探討。
項目中難免會碰到很多“緊急情況”，如：
1、需求變更
客戶是善變的，我們必須伺候好客戶，不是么？沒有任何理由，他們要變更需求，一般情況下，最為乙方、丙方只有服從。
2、項目外包
很少有人碰到過吧？不過的確存在！項目進行到一半時由于自身團隊或者高層決策、成本等方面上的要求，直接將項目外包出去，或者重新讓一個項目團隊接手。
3、開發設計架構存在明顯嚴重缺陷
顯然，架構師、項目經理等沒有在前期做好評審和確認，但是很多項目，尤其是政府項目團隊成員很隨意，反正是有扶持款項。但這不是質量低下的理由！
4、不確定因素造成人員減少
如核心員工跳槽離職、女同事懷孕、家里生老病死等。
5、客戶要求提前上線
在交付階段，再次回到客戶，他是老大，出錢的，給項目的！甲方要求提前項目上線，這不得不加快進度，不是么？
關鍵點把握——“壓縮”
綜合上述我列舉的幾個原因，在項目決策和進度上已經批復下來，我們必須得“壓縮”進度安排。這里明顯不存在溝通、協商的必要了，或者說與相關部門、人員溝通/協商無效了。
但是對于我們測試團隊的“測試周期”，個人認為，有必要澄清或者繼續不斷與相關涉眾進行溝通和協商！畢竟整個周期被砍，直接最大影響的是我們測試部門同事！
這里根據之前列舉的5大理由，我會有側重地整理下解決方案：
1、需求一旦變更，項目團隊前面階段也肯定有影響，開發需要重新設計編碼，然后才是到測試階段。由于需求變更是客戶方提出的，我們有權利去交涉爭取最長“測試周期”。這里作為測試經理必須和項目經理統一戰線，和客戶方達成共識。因項目后期客戶自身提出的臨時需求變成要求，本不在合約范圍內，所以綜合已有的項目計劃和人員安排，在強制要求“壓縮”進度、或者保證原有進度的情況下，個人認為必須給客戶列舉出詳細的測試風險和影響要素。讓客戶方明確在進度被壓縮的前提下，我們能保證的質量效果和最佳狀態！知道風險是多方面必須一起承擔的。
2、項目突然被外包給別人，有點不可思議！但是整個項目被第三方接手，這里的交接情況，主要是新項目組對需求的快速把握、理解，開發方對項目架構、設計及代碼的熟悉都是不得不去考慮的。這樣對于測試團對來說，只能延后開始執行測試時間點，那勢必得把握測試要素的重點。個人建議按測試優先級、功能重要等級進行分類和劃分，給客戶方一個明確能保證質量的測試業務點清單。畢竟不可能在短時間項目被重新分包情況下，讓測試團隊控制什么進度來交付產品/項目。這個是整個項目進度的問題。
3、開發設計有嚴重問題。這個是自己團隊得承擔的責任！但是也因此影響到了測試部門人員。我們在開發人員緊急處理問題時，可以同步參與
單元測試、
接口測試等。因為已經大架構上錯誤了，測試人員協助開發人員一起確保系統設計、搭建沒有問題，其實是不能再出問題！
4、非受迫性減員很普遍，但是各項目組或者總的測試團隊負責人/測試項目經理必須分配好冗余資源進行補充，自己得多承擔責任。作為缺崗人員的備份者，更加要協調好剩余同事的任務安排，穩定軍心。
5、客戶要求趕工上線，正常情況下不能保證質量是否完全可靠，同問題1，得讓他們承擔接受潛在風險！上線交付是個很嚴肅的過程，對系統功能、性能、安全、穩定性，軟、硬件環境要求必須都滿足上線的前提，才能正式交付，客戶在計劃外要求提前上線，除去自己業務方面需求，沒有對項目團隊有啥合理理由或者要求，我們作為測試團隊，得把握其上線要求的最佳業務點，如某個功能模塊一定要運行正常穩定，有側重的去測試該部分，若他們可以接受條件的話。
其實上述方面我還是側重與責任方進行交流溝通！雖然已經被壓縮了進度，但有些情況必須闡明，才能安心工作，對于測試部門，測試經理也有義務進行責任承擔的同時，給予同事們最大程度保護！
對于傳統的加班加點，加人加米等方式，這里我其實不想多說，因為這些都是非正常的要求，才稱之為“緊急情況”，所以除去那些人力、費用、資源等成本不說，在項目進度，這里主要是測試進度加快情況下，只能先理清思路，針對不同要求去協商并溝通，爭取最佳的效果吧。盡可能保證項目在預期內打到理想的最好質量狀態。
我個人是沒有見過被壓縮進度下，又要做到很好，又要滿足各種要求的！這不現實！這里只是給出最可能的、理想的、較好的處理方式和技巧而已~
希望其他大神補充，指正！