最常見的測試流程（a-d較成熟，但不認同有科學性，可改進）：
a.專案組 [新增項] =>研發測試[迭代測試] =>專案組[debug]
b.研發測試 [歷史版本缺陷跟蹤] => 專案組[debug]
c.專案組[debug反饋] =>研發測試 [debug回歸]-
d.研發測試[持續bug提交] =>專案組[debug]
a-d為順序，但也可以縮減 看新增項的質量和過往版本是否有交叉（都和質量有關）
過程一：a,c
--和週期有關
過程二：a,b,c
--和新增項的量有關
過程三：a,c,d
--和過程二基本相同，差別為無交叉性
華麗的分割線 華麗的分割線
華麗的分割線
華麗的分割線線線線線線
（e.f部分屬於遊戲測試很少接觸的分支）
e.研發測試[度量缺陷]= 研發測試[歷史版本缺陷跟蹤]+研發測試[剩餘高缺陷總量]-[風陷化]-[無法定向]
f.研發測試e[結果] =>是否停止提交缺陷
華麗的分割線 華麗的分割線
華麗的分割線
華麗的分割線線線線線線
g.研發測試f[結果] =>專案組（多線開發）
未完成的遊戲
半年前的某天，陽光穿過烏雲照射著滿是創痕的世界，我走在曾經熟悉的靜謐的寒冷的恐懼的街道。並沒有先前設想的那樣來一陣狂歡，大概是意識到了人生短暫，不應該花費過多精力在慶祝上。高考遠沒有預期的那樣滿意，不過我還是舒了一口氣，終於結束了。2015年的9月，寒雪社群掛上這樣一句話 由於種種原因，論壇暫時關閉...
需要談談的遊戲測試（五）
剛獲悉一些問題，有壓力。基本框架本年內肯定是沒完成，每天碎片時間不超過2小時，只能依賴重寫系統測試案，來試圖查出隱患。框架的協作性需要磨合，核心也是節約時間和人力成本 先圖表再歸納成文字。產品最終是定義穩定性和健壯性，某種意義取捨還是關注的是產品的健壯性。如何尋找現有突破，依然是82原則和28定律的...
需要談談的遊戲測試（九）
順應九九歸一，第9章就結束了。到底什麼是黑盒和白盒，我們之前的工作到底完成了覆蓋了多少。測試分為黑盒和白盒，遊戲測試又以入門門檻低而被人熟悉。最原始的方法 根據策劃案按策劃案的模組來實際遊戲的行為步驟書寫測試用例。日常行為執行測試用例為主。tester交叉測試來確保漏測和試圖發現更多的測試點。測試行...