1.沒有什么常理上不可能發生的bug
2.時刻要記住測試的是程序,是代碼邏輯,一切都有跡可循,而不是一個自然事物
3.前期的用例編寫盡可能細膩,覆蓋度全面,并提前清除需求不確定項
4.測試過程中要進入用例深處,同時也要跳出用例之外,在測試后期要有段時間專門站在用戶角度使用軟件
5.清楚你所測項目的核心業務是什么,需要保證核心業務。明確核心業務,需要你理解你測試的東西的作用,從用戶角度去確定什么是最重要的,什么是次重要的,而不是想當然
6.某種意義上,bug沒有偶現,只有在一定條件下出現的必現,所以不要輕視每一個突然出現的錯誤現象,尤其這個現象一旦出現就會比較嚴重時,要保持警惕性和敏銳性
7.很多遺漏bug有時候不發生在你經常盤查的地方,而是在你完全沒有考慮到的地方,時刻記得這一點 ,在測試過程中階段性問自己是否有那些case完全沒想到,有利于避免嚴重問題遺漏
8.在你提bug的時候,一旦有“這問題太小了,開發是不是不愿意改”的想法時,那么bug一定要提,測試負責的是問題暴露,先暴露出來
9.之所有有第五條,在于有時候你以為問題比較小,其實有可能會在別的場景產生別的大問題
10.保持測試環境的穩定性對于測試的進行十分重要,在穩定的環境下測試有利于排除外因,定位問題
11.根據具體項目以及具體測量周期,調整自己的測試節奏,保持頭腦清醒,把控測試節奏,清楚自己測到哪種地步
12.一些測試盲點:容易忽略可變化的大前提條件,比如環境、當前定位等
13.遇到問題不要慌,問題再嚴重但是如果已經在測試周期發現,那么就在可控范圍內,要做的是冷靜收集信息,確認問題根源,記錄并通知RD
14.在測試期間,阻礙整體測試進行下去的問題嚴重性會更大一些
15.如果是在線上反饋之前發現了一些嚴重問題,那么此時第一要務是要通知相關RD,進行回滾等操作,先處理線上問題,并事后復盤
16.h5/web/App測試,其實都是客戶端+后端測試,即前端+接口測試
17.適時地進行探索性測試,不去死板遵循前期的測試用例
18.bug是有優先級的,需求也是有優先級,要有這個意識,如果全部不分優先級一把抓,對于不同優先級的位置分配不同的精力,不只是測試要這樣,人的精力是有限的,時間是有限的,在有限時間的保證核心功能正常
19.一般來說,需求-需求審查-用例書寫-接口測試-功能測試,對于剛接手的需求迭代的話,需要在自己理解整個系統的前提下,自我評審下這個邏輯是否有問題,不清楚的地方與PM確認;接口測試期間與RD確認接口設計,盡可能少地把產品設計問題和接口設計問題拖到功能測試階段
20.問題記錄很重要,記錄在缺陷管理工具上,包括一些討論過程討論結果,有利于后期問題跟進
21.是人都會犯錯,不一定誰都想犯錯,給RD信任,對RD同學好一些體諒一些。。
22.5W1H原則與二八定律
23.自我提升,工具學習與代碼學習
24.雙客戶端對比測試一個很有用的測試手段,某端出現了問題后要留意另一客戶端是否有同樣的問題
文章來源:博客園 版權歸原作者所有
上文內容不用于商業目的,如涉及知識產權問題,請權利人聯系博為峰小編,我們將立即處理。