今天下午，團隊開了乙個簡短的版本總結會。會上測試經理分析了乙個案例：某子程式在轉測試後發現不能被平台排程，原因是子程式的排程入口跟不符合平台規範。很明顯開發在轉測試前沒有充分自驗證，測試經理提出，後續對跟平台對接的子程式轉測試必須要有將子程式接入平台跑通後的驗證報告和相關checklist，否則不予轉測試！然後大家開始討論，主要觀點大致如下：
1、測試的兄弟認為從提公升質量出發，開發應該充分驗證，對每個子程式，都應該跟平台充分除錯，並輸出除錯報告作為轉測試入口條件。降低轉測後發現低階問題，導致重新測試，浪費測試人力。
2、開發的兄弟認為，通常大部分需求實現都是對已有子程式的功能做優化公升級，子程式跟平台之間的介面一般不會修改，而子程式的功能是可以脫離平台進行驗證和測試的，如果要求每次子程式優化後轉測試都輸出跟平台除錯的報告，必然增加開發人力投入，這也是一種資源浪費。
從開發和測試兩個角色來說，矛盾點主要在於：質量和資源(人力)投入，大家都希望少投入，但把事情做好（質量高）。團隊一直強調基於角色和流程開展工作，開發和測試之間定義了標準交付件（如自驗證報告，**檢視報告等），因此測試很自然地想到在角色之間的交付件中增加乙個跟平台的除錯報告來攔截開發問題流入測試。基於流程規範來解決問題的思路應該來說沒有問題，但這也僅僅是頭痛醫頭腳痛醫腳的辦法，如果問題都這麼解決，那麼下一次出現另外乙個問題，再增加乙個轉測試交付件（並且這個交付件真正能起到攔截問題的作用還很小），這樣機械式執行，開發人力浪費無疑非常大，作為專案經理，希望用最少的開發和測試人力，交付高質量的產品，這當然不是上上策。那麼如何避免開發的低階錯誤流入測試從而導致測試人力的浪費呢？從本文前面描述的問題可以抽象出問題的特性：
1、子程式包含功能和介面，而開發通常關注於功能驗證，介面因為涉及到其他平台或者子程式，被忽略了。
2、開發粗心，或者意識不到位，導致沒有驗證到介面
那麼這類問題如何避免呢?開發在轉測試前必須保障交付的子程式的功能和介面的正確性是不可更改的，那麼是否一定要輸出除錯報告等交付件呢，個人覺得只需要乙個checklist即可（即：開發在轉測試前，只需要在checklist上簽字畫押，表示該子程式基於***平台除錯通過，如果不涉及，即寫明無需跟任何平台除錯並說明原因）即可轉測試，即如果子程式涉及跟平台聯調，那麼聯調必須執行，但無需輸出報告。有人會擔心了，萬一需要聯調的子程式，開發人員明明沒有聯調卻在checklist上註明除錯通過怎麼辦，問題還是要流入測試，其實這個問題可用考核來解決，將質量和個人績效掛鉤，轉測試不通過計入開發質量關鍵事件，作為績效考核輸入，很多時候，只要有這一條，無需在流程中增加很多交付件，各個角色會自己想辦法提公升交付件的質量的，專案管理，甚至團隊管理不應該將每個人都塑造成乙個模式的，大家基於乙個大的流程和規範，在流程規範內保持適當的靈活性（個性），所謂八仙過海各顯神通，我們不必要求所有人都像何仙姑那樣使用蓮花過海。
乙個案例的簡單總結
翻看去年處理的乙個案例，發現處理時間挺長的，而且這個案例也有點意思，就再看多兩眼，做個簡單總結。1.首先是應用伺服器效能不穩定，排查之後，伺服器是vm，要求加資源，並且所有資源都reserved.2.接著就是應用伺服器連線資料庫時很不穩定，資料庫經常報 recovery mode 好像是資料庫莫名被...
乙個事故引發的思考
今天線上服務出現了乙個事故，思考下這個事故，覺得有好幾個地方需要思考。1 對於前端而言，回滾的功能是必須的。前端介面出現了問題，第乙個應該想到的是將 回滾到乙個穩定版本。2 快取和資料庫的使用，需要注意乙個問題，當快取失效的時候，可能會有大併發的請求去訪問資料庫，這個時候資料庫會不會崩潰？如果這個時...
關於溝通問題的乙個案例
我們需要測試乙個安裝包，安裝包中包含了資料庫公升級指令碼，這是測試的乙個重點。我們以前能訪問客戶的一台伺服器，並且在5.2號對資料庫進行了備份，但是在5.3號手動對資料庫進行了一點修改，這些修改是不包含的備份中的。而我們現在不能遠端桌面連線到客戶的伺服器了，這樣我們就沒有乙個真實的資料庫來測試公升級...