一、版本測試:
1. 詳說測試流程,闡明重點把握細節,提公升qa節點把控能力。
2. 降低偏差值、提公升產品質量。
二、版本測試流程:
1. 溝通產品需求,了解產品設計方向以及產品需求。
a) 版本質量要求:
1. 通常版本質量有abc之分,但一般性遊戲產品只需要做abc即可。qa人員或測試主管,需要和版本負責人或製作人,溝通產品質量要求。
2. a級,功能流程暢通無卡死bug,且功能覆蓋邏輯符合設計,同時數值及介面無異常。
3. b級,功能流程暢通無卡死bug,且功能覆蓋邏輯符合設計。
4. c級,功能流程暢通無卡死bug。
5. 溝通的重點,是確認在對應週期內,目標的版本質量是乙個什麼要求。比如技術測試,c級即可,但不同的專案組負責人要求不一樣,視具體情況確認。
b) 版本覆蓋面及時間節點:
1. 通常版本確定下來後,會定下來未來版本覆蓋面,一般是個一句話簡述,後續在實際開發中,將會逐步補充策劃文件。
2. qa人員或測試主管,需要和版本負責人或製作人,溝通產品的設計覆蓋面,至於細節在後續的計畫中展開即可。
3. 除了溝通產品的覆蓋面之外,每個執行細節的任務內容簡述、提測文件時間、提測功能時間、提交發布時間等確定下來。
2. 梳理版本功能結構表,制定測試計畫。
a) 版本測試計畫的制定:
1. 一般由專案的測試qa負責編寫,編寫完畢後,提交測試主管進行整理,以及補充覆蓋面及執行細節。
2. 文件的格式,一般兩種,比如完整性新專案即結構表樣式,比如常規版本即常規迭代表樣式。
3. 文件的維護,這個是版本主題計畫,後續的執行都是以此為依據時時更新。
b) 測試周工作計畫:
1. 測試主管,編寫測試週報,以執行人的周單位,編寫任務池。
2. 週報,分為上週完成情況、本週計畫、後續任務。
3. 週報,涉及到上線時間要求的,需要在單任務後面加上截至時間。
4. 週報,任務池,寫明任務名稱和執行即可,不要過於累贅,描述清晰即可。
3. 梳理測試用例,以及需要的測算列表。
a) 功能案例分析:
1. 根據功能文件或者設計相關溝通說明,拆解功能塊。
2. 拆解方法:開始-過程-結束,將所有的涉及測試細節,羅列出一張list清單。
3. 拆解大同小異,一般小功能可以直接繞過該細節。
b) 測試用例彙編及測算列表編寫:
1. 測試用例,常規兩種彙編方法,一種基準用例,一種是完整性用例。
2. 使用哪種彙編,視當前的版本時間而定,後者更加嚴謹,時間充裕盡可能後者。
3. 極個別的行為功能,或者重複性的用例,可以採取不編寫或者修改復用即可。
ii. 測試用例彙編或者沿用,無論哪種需要把執行用例傳送測試主管處確認。
iii. 測試主管審核用例,將覆蓋面不足及遺漏的方法,進行詳盡說明。
iv. 測算表,通常做好元素覆即可。
4. 執行功能測試,快速迭代bug。
a) 冒煙測試:
1. 在功能未完整完成前,可以提前涉入測試,優先堆疊bug過去。
2. 測試越早介入功能,越早提交及修改,對產品的幫助比較大,盡可能提前。
b) 重推迭代測試:
1. 功能流程走通後,進行重推測試,一般兩個環節:邏輯深度環節、資料測算環節。
2. 常規,前者優先測試,其次是後者。
3. 特殊說明,在這裡需注意對邏輯的細節進行分拆,比如試練測試,其中的試練碰撞會有很多事件,若對碰撞事件不熟悉,必然會出現遺漏等,會導致測試認知度和理解度產生較大問題,需重點關注。
c) 相容性測試:
1. 裝置相容測試:比如ios版本、安卓版本,支援最低最高版本。以及中間的特殊大版本,需要全介面性的通跑測試。
2. 裝置解析度測試:比如ios環境、安卓環境下,裝置解析度的測試,對於ios來說,公司常備機型都可以支援到。對於安卓公司內部採集主流裝置進行測試,同時可以發布testbird、testin之類雲環境進行相容性測試。
3. 中低配樣機測試:主要測試中低端環境下,流暢度、記憶體、cpu等資料緯度檢測。工具使用比如gt。
4. 裝置特性測試:音量鍵、關機鍵、hom鍵等操作性測試,比如安卓一二三節目通過返回鍵操作易出問題。來電、語音、切換等內部操作性測試,比如新手環境切程序重新進入遊戲,易出現流程卡住問題。
d) 部署更新測試:
1. 更新測試,一般兩種,資源增量更新測試、整包更新測試。
2. 具體方法詳見更新測試,對於更新測試,內部需測試更新前和更新後環境測試。
3. 重點,測試的內容不是僅僅是更新後資料和邏輯正常,更重要的是在更新過程中,操作行為的測試異常情況。
e) 節點性活動測試:
1. 節點性活動,以及禮包等,一般作為特殊通道優先測試。
2. 這型別測試,需要做規則、邏輯、數值獎勵測試,備份記錄。
5、系統功能驗收測試,確認覆蓋資源到位。
a) 功能驗收測試:
1. 根據測試計畫中內容,進行詳盡驗收完成情況。
2. 包括:測試計畫內容驗收模組、測試用例執行驗收模組、禪道bug驗收模組等。
b) 驗收測試重點:
1. 確認計畫內內容完成情況,新增和刪除內容,和策劃、程式溝通確認。
2. 覆蓋面到線,確認覆蓋到面、線的資源到位(包括差異比對)、規則正常。
3. bug層面,所有的嚴重級及以上等問題,重新複驗解決情況。
4. bug層面,和策劃、程式溝通,小細節問題放到後面版本進行解決。
6. 線上環境部署測試,七日常規跟進。
a) 線上部署測試:
1. 線上部署跟進測試,確保和內部部署測試一致,以及新增問題跟進。
b) 七日常規根據測試:
1. 上線後,一般七日內是問題易發期,需重點關注。
三、版本質量偏差值的控制:
1. bug統籌分析:
i. bug的統籌分析,通常分析迭代效率、跟進效率。
ii. 迭代效率,不僅僅是指提交bug的效率,而且也包括bug的及時回歸。
iii. 迭代效率,可以通過bug的新增、解決兩張表對比,一般乙個常規測試一天應該20+真實bug。爆發期可以2-5倍,空檔期或者測算期可能只有3~5條,實屬正常。但是週量和月量變化曲線,一般是均衡的。
iv. 通過版本bug的分析,後續提公升迭代效率,降低偏差值。
2. 測試用例、測算列表:
i. 測試用例及測算列表的執行覆蓋,直接影響到偏差值。
ii. 測試需要吃透功能,但有時候測試經常會遇到策劃沒有文件的情況,而新測試往往很難下手。因此測試必須自己彙編用例,更加謹慎性的進行執行測試。
iii. 當然,即便是有文件,測試也需要彙編測試用例,以確認的內容覆蓋到位。
iv. 分析、彙編、審核、執行、覆盤,是測試用例、測算用例執行的五個關鍵性步驟,check到位,較大層度降低偏差值。
3. svn差異:
i. 一般bug,除了介面和邏輯bug外,最多bug發生區域,在於策劃配置表。
ii. 針對於遊戲產品,比對的內容是策劃陪表。
iii. 比對的目標:確認提交內容覆蓋面,和實際測試覆蓋面出入,以確認兩者差異性。然後跟進差異性展開測試。
iv. 切記,svn比對不是測試結果,而是分析,策劃之所以所比對就可以了,因為站在角度不同,測試的原則是質量。
v. 差異性測試確認功能覆蓋,降低偏差值。
4. 驗收測試:
i. 驗收往往是最經常疏忽出錯的時候,這個時候往往面對所有人的催促,不僅僅測試上,心理上往往會承受很大的壓力,越是這個時候,越是需要冷靜。
ii. 隨著開發周期的推移,往往約定好的時間,會出現delay,當然delay原因會多種多樣這裡不闡述,一般會把測試時間吃掉一部分,這個時候是相當尷尬的。
iii. 其實這本身就是一種質量失控的表現,當然對於專案負責人層面來說『我完成了』、『大不了,我降低質量要求』。先不管外力,那我們如何做呢。
謹記質量要求原則,做好保底測試。
周邊性內容或者後續內容,放到第二天後面測試,周知專案負責人清楚,哪些是現在保證的,哪些是後面要做補刀的,將可控的牢牢控制好,不可控的放後補刀測試。
iv. 牢記原則,抓大放小,降低偏差值。
從如何提公升自己開始吧
從事這行也算很久了一直想寫點什麼記錄下來,結果忙於懶惰。從這裡開始嘗試乙個起點吧。最近由於新工作對人員的需要再次開始面試了,短時間內見了不少的候選人。雖然沒有選到合適夥伴到是進行了很多的交流,其中乙個主要的話題是怎麼學習以及為什麼換工作。在這裡我總結一下自己的想法,希望能給到一些後來者有用的建議。大...
從設計模式怎樣提公升設計
設計模式是一種非常有用的設計參照,基本上每次去讀設計模式的內容總是會獲得新的體會。但是有沒有新的模式呢?我想,這個大概是有的,不過新的模式產生估計會非常困難。在編碼一段時間之後,大概在一年或者兩年之後,我們一般都在想,可不可以把編碼做的更好一些,讓別人更加容易閱讀,更加好維護,更加好修改。懷著這種簡...
從0開始Python 選擇流程 分支流程
在根據某一部的判斷,有選擇的執行相應的邏輯的一種結構。分為單分支 雙分支和多分支。單分支模式 if 條件表示式 一條條的python 一條條的python 一條條的python 雙分支模式 if 條件表示式 一條條的python 一條條的python 一條條的python else 一條條的pyth...