大家在給甲方做大型專案的時候，有時候參與的廠商比較多，而公司負責的部分又需要第三方廠商提供介面支援。
例如我們做醫療行業的，給醫院提供醫保控費系統服務的，就需要HIS廠商提供介面給我們採集資料。有時候他們不理解你們提供的介面需求文件，所以一些資料給錯了或者沒給到，也可能他們介面本來就開發錯了，還有一種可能就是我們的測試人員沒有按照HIS的要求進行測試使用導致，這個時候就需要他們積極的協助配合。
但是呢，有些通用介面已經開發好的不一定就你們公司使用，一旦修改的話可能影響了別的系統，所以HIS廠商一般不太樂意去幫你修改，尤其是當你提出的修改需求他們都聽不懂的時候，更不想費力去聽你講了。
這時候，一份詳細且又規範的文件就顯得特別重要，我們可以設計一個文件來儘可能詳細的描述我們發現的問題，是怎樣測試的時候發現的以及我們真正需要的是什麼樣的資料，把這份文件丟給他們，讓他們一看就能馬上定位問題，問題就很好解決了。
以下是我設計的關於介面測試問題向第三方廠商反饋並尋求積極配合處理的文件模版（文末提供文件下載地址）：
本文件是站在第三方技術人員的角度去思考他們需要什麼資訊來輔助他們定位問題
- 文件說明解釋了為什麼發這份文件給他們
- 問題反饋記錄彙總記錄了所有可能存在問題的介面，因為有時候處理介面並不是一次性就能完善的，需要不斷的協調並進行修改，文件的目的也是為了記錄我們處理介面問題的過程，做留檔。
- 介面地址用於說明我們測試這個介面的時候是用了這樣的url，可以讓第三方技術人員判斷我們是不是測錯介面了。
- 測試人員用於第三方技術人員直接於測試人員聯絡並做出解釋。
- 測試時間記錄的測試發生的時間，方便他們查詢日誌文件。
- 請求方式、請求頭部資訊、請求引數可以讓第三方技術人員快速判斷測試人員是否按照介面要求進行測試，此外請求猜數也方便第三方技術人員自己測試進行問題復現。
- 響應狀態碼則直接告訴他們介面有沒有通。
- 實際返回值和預期返回值可以讓第三方技術人員進行對比我們想要得到什麼樣的資料。
- 問題描述記錄我們發現什麼問題以及希望解決什麼樣的問題。
以上是我作為一個開發著的角度設計的文件，至於有沒有用那就 見仁見智了，反正我要是第三方廠商看到這種文件，我會盡可能積極配合。
每一個開發工程師都有一個共同點，那就是交卷不改，開發好的介面憑什麼說改就改，且有時候一些需求的確是很過分的。
所以要想少跟開發工程師尤其是第三方的拉扯，你是不是該思考思考你的介面設計的是否合理？有些資料可以自行計算的是否應該自己去計算？有些資料在別的介面已經提供了是否可以利用起來？
另外，關於技術公司跨部門間溝通的問題，你可以閱讀這篇談“技術公司跨部門間溝通”問題及解決方案
或者是第三方API介面測試報告模版
文件模版下載：百度雲盤：https://pan.baidu.com/s/1NZQLrCVmsZqIXgUApqvU1Q 提取碼：dppj