2018年年底，接手了先後兩個質控同事都跟進過然後因故沒做的功能模組，回顧這麼多年的工作經歷，很多經驗都沒有形成文字形式儲存，而這次的測試出現的問題也比較能涵蓋之前的工作總遇到的問題，故總結文字記錄之：

App—要約收購解除
一、應用端委託成功，生產了委託單，方向買入，資金扣減了
業務理解：解除業務是T+1日返回成交確認，當日不應該進行資金持倉扣減，怎麼會扣減？
找原因：到交易系統查詢委託詳情，發現委託屬性不是要約收購解除
問題：介面調錯了，調了買入的介面
總結：對於調周邊介面的應用，介面返回的成功、失敗應答需要有深入質疑的精神，刨根究底，確定返回的資料不是偽應答

二、收購期限屆滿前三個交易日不可做解除
場景：包含週六日時，是否可以做業務
原因：開發沒理解到交易日的概念
總結：對行內業務要有敏感度，方能充實測試場景

三、需求原型和UI設計均顯示：收購人程式碼 欄位名
業務理解：個人根據交易所官方文件，文件中均定義的是：收購編碼
原因：產品經理直接借鑑了hs交易系統的介面，直接就定義為收購人程式碼
總結：測試不應該是基於產品經理設計的原型，而是基於官方業務和客戶實際需求來做測試

四、深市解除需要判斷可解除數量，委託數量滿足可解除數量方可解除
問題：因為沒有存量可做解除的資料，委託訂單無法生成，測試場景無法執行
分析：按照整個的PM流程，該問題在開發自測，產品經理驗收時，就應該暴露出來，因為其他同事的工作遺漏，最終流落到質控測試組。
困難：為了完成場景執行，需要解決可解除數量是怎麼算出來的，進而造業務資料，需求經理忙碌。。。開發和介面供應商溝通後答覆質控需要在xx表加資料即可，我在幾個環境中找了歷史資料，仿造了幾筆，仍然無法完成場景執行，與開發溝通，開發繼續和供應商溝通，答覆仍然是在xx表加資料即可。時間就這樣過去了，工作進度沒有推進。。。後，我直接和介面供應商聯絡，提供log日誌，針對供應商的開發的答覆提出了自己的疑問，確認了xx表某幾個欄位的含義和來龍去脈，最終造出正確的資料，解決此問題。
總結：工作各司其職沒有問題，但上游應該規避的問題最終流落到我們手中，如何能快速解決問題是第一要務，不要覺得這個問題是上游導致的，然後就耗著，停滯不前，等待上游去返工解決（當然如果上游有快速解決問題的能力最好），總的來說，就是要有主動型，遇到問題的時候需要動起來，而不是坐等，最後跟領導反饋說遇到xx問題阻塞，應該是上游xx來解決的，因為他解決不了，我這裡無法開展