今年分別出差過青島銀行和興業銀行做現場測試支持，感覺和公司裏產品還是有蠻大的區別。

剛入場時，有三點一定要再次確認下：

• 專門給測試的環境。 只給測試用，不能用作項目開發或者是缺陷修復。現在項目基本模式都是敏捷模式，測試入場時，只有部分功能塊已經提測，還有部分功能需要開發，所以一定要有3套環境才行，以免缺陷修復的時候占用測試環境。
• 提前告知提測條件（比如已經冒煙測試和聯調）後，在開發提測後，先走一遍冒煙測試。青島銀行時候是對方聯調過，但是後來代碼改動卻沒有再聯調，而興業銀行是根本沒有聯調，甚至部分功能都沒有單元測試。先走一遍冒煙測試可以將各個功能塊的問題提前發現，讓開發修復，避免影響到測試進度。
• 如果有需求方面的疑問，在和項目經理溝通後，一定要再找行方確認下。所有的需求變動都要找行方確認，哪怕是字段名字的變化，不然銀行人員還是會顯示下存在感。
• 現場的項目git和公司的已經分開，包括各個依賴包， 以免公司開發人員對依賴包這些基礎功能的改動引入問題。

測試過程中：

• 發現的缺陷每天都需要找個固定時間發給開發，並約定好修改時間。然後親自前往對方那邊再次確認，以確保缺陷分配給正確的人修改。
• 每天要詢問開發的進度，以確保後續測試不會因為進度中斷。
• 如果必要的話，還是要提醒下開發，新包先部署到開發環境，然後在上面冒煙下今天要測試的內容，如果ok，才準許部署到測試環境。項目中經常存在開發迷之自信，為了節省時間，代碼不自測就提交打包。

測試結束後：

• 項目到後期後，大部分開發都已經結束了開發工作，如果這時候第一輪功能測試還未結束。可以建議項目安排人員優先對未測試功能聯調，如果人員富余，可以安排開發人員以冒煙測試的形式進行回歸測試，如果能按照測試的用例進行回歸測試，那就更好了。
• 第一輪功能測試結束後，一定要在進行一輪回歸測試。
• 如果時間還有，那就看情況對測試範圍外的我方新增改動進行測試。

兩次項目出差的經驗總結