一、版本測試：
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...