本文來自於作者投稿，作者陳彩華，貝聊後端開發工程師。

最近參加了保利威測試總監李樂的《網際網路測試姿勢》為主題的分享交流會，收穫頗豐，作為一個開放，秉承“不懂產品和測試的開發不是好開發的原則”，總結一下。

分享交流會的主題主要涉及網際網路態勢下，如何高效測試，如何提升工作效率，提高產品質量，測試團隊建設，以及作為網際網路從業人如何快速學習成長。

why 為何做測試

what 測試涉及的知識

傳統測試VS敏捷測試

敏捷測試各階段測試的測試活動

測試觀

發現缺陷的時間與缺陷修復成本關係

越後期修復缺陷的成本越高，且指數增長，而缺陷主要是開發前期引入的，且前期缺陷修復成本很低，測試越早越好

測試分層概念

 越往上層，構建速度越來越慢，成本投入越來越大 * 越往下層，構建速度越來越快，成本投入越來越低

how 如何做好測試

測試現狀

生產力改造

測試團隊關注點

、

挖掘公司業務測試痛點

注意點 * 產品質量改進需要長期投入 產品質量改進的投入產出週期較長，立即投入並不能直接對收益產生重大回報 * 只在合適階段對測試資源做合理的投入 

提高測試人員思維

測試技術棧參考

Q&A

• 1 人員架構組成的困惑 問題：請問您認為成熟度高，利益一致的開發測試團隊是人員組織架構是怎麼樣的？ 回答：測試，開發，產品垂直上隸屬各個獨立部門統轄管理，針對每一個產品專案，各個目標抽調出相關人員組成小組，共同為產品的質量，產品需求，產品完成效率負責。

• 2 冒煙測試的困惑 關於冒煙測試之前實踐的時候遇到的問題：開發完成一個功能的開發，測試完成功能冒煙，後面開發進行功能迭代時改了這個功能，功能沒有改完，測試冒煙測出問題並提bug，經常發生類似情況導致專案領導有意見，這種情況如何避免？ 回答：首先，開發需要與測試溝通協商好,確定可測試度，哪些可以測試，哪些不可測試，同時，對於暫時不可測試的部分，開發人員需要給出完成期限，便於測試做測試計劃。

• 3 測試人員如何做KPI考核 回答：類似如果基於開發人員寫多少行程式碼做KPI考核沒有意義，基於測試人員測出多少Bug來進行考核並沒有意義。更傾向用OKR(Objectives and Key Results即目標與關鍵成果法)考核方法，根據每個成員關鍵目標完成情況進行考核。

• 4 手機客戶端如何做程式碼覆蓋率測試 回答：比較常見的方案是通過定製開發，在測試環境，客戶端植入測試覆蓋率收集的程式碼，並上報給服務端的統計中心進行統計

• 5 測試與研發關於bug的修改發生意見分歧的困惑 問題：測試與研發關於bug的修改發生意見，測試人員改bug有必要改，但是開發認為沒有必要改，如何協調溝通好該類矛盾？ 回答： 測試人員收集好相關測試統計資料,拉上開發，產品一起評估這個bug的嚴重程度，計算好投入產出比，bug影響範圍，360度環評有沒有必要改這個bug,是這個版本馬上改還是暫時放一放。一般而言，針對大版本升級本身存在很多風險，建議bug儘快修復。如果是小版本升級，測出以前的舊bug，那麼比較傾向於使用保守策略，畢竟改bug有可能引入新bug.

• 6 如何做好效能測試 回答：效能測試除了在生產環境閒時(比如深夜)進行測試，還可以在測試環境做，這時要根據測試環境，線上環境的硬體引數，由測試環境測出的結果再進行比例換算，可以得到線上環境的效能引數。

參考資料

《Google軟體測試之道》