轉載自? ?開發人員也要懂點的測試知識

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

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

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

?

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軟件測試之道》

總結

以上是生活随笔為你收集整理的开发人员也要懂点的测试知识的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。