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

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

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

分享交流會的主題主要涉及互聯(lián)網(wǎng)態(tài)勢下，如何高效測試，如何提升工作效率，提高產(chǎn)品質量，測試團隊建設，以及作為互聯(lián)網(wǎng)從業(yè)人如何快速學習成長。

?

why 為何做測試

?

what 測試涉及的知識

傳統(tǒng)測試VS敏捷測試

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

測試觀

發(fā)現(xiàn)缺陷的時間與缺陷修復成本關系

越后期修復缺陷的成本越高，且指數(shù)增長，而缺陷主要是開發(fā)前期引入的，且前期缺陷修復成本很低，測試越早越好

測試分層概念

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

?

how 如何做好測試

測試現(xiàn)狀

生產(chǎn)力改造

?

?

?

?

測試團隊關注點

、

?

挖掘公司業(yè)務測試痛點

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

提高測試人員思維

測試技術棧參考

?

Q&A

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

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

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

• 4 手機客戶端如何做代碼覆蓋率測試 回答：比較常見的方案是通過定制開發(fā)，在測試環(huán)境，客戶端植入測試覆蓋率收集的代碼，并上報給服務端的統(tǒng)計中心進行統(tǒng)計

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

• 6 如何做好性能測試 回答：性能測試除了在生產(chǎn)環(huán)境閑時(比如深夜)進行測試，還可以在測試環(huán)境做，這時要根據(jù)測試環(huán)境，線上環(huán)境的硬件參數(shù)，由測試環(huán)境測出的結果再進行比例換算，可以得到線上環(huán)境的性能參數(shù)。

參考資料

互聯(lián)網(wǎng)測試姿勢 ——李樂

《Google軟件測試之道》

總結

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

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