需要談談的遊戲測試（五）

剛獲悉一些問題，有壓力。基本框架本年內肯定是沒完成，每天碎片時間不超過2小時，只能依賴重寫系統測試案，來試圖查出隱患。（框架的協作性需要磨合，核心也是節約時間和人力成本）

先圖表再歸納成文字。

產品最終是定義穩定性和健壯性，某種意義取捨還是關注的是產品的健壯性。

如何尋找現有突破，依然是82原則和28定律的通過過往的問題來**將來可能重點方向的。

1.create test case from bug（從缺陷建立測試用例，又要追回傳統軟體的一些辦法）

2.通過rbt中風險概率計算因子的更進一步細化和風險影響因子計算的模型（最起碼需要1-2個人）

3.半自動和自動化參與到冒煙測試中，最終目標為把1次冒煙的時間可以完成1.5次為佳。冒煙時間以使用者視角和當前版本開放多少為內容基本，以更新了服務端，客戶端或者配置表為時間定向，來完成。

4.至於交付方面，還需要思考下 在冒煙測試前，通過內-外部評審，然後「通過測試」，才執行冒煙測試（驗證版本完整性）->交付。

冒煙測試發現了大的問題，如果不是發版本前更新出來的，那本階段測試的質量需要測試自己打個問號？然後去優化和尋找原因。測試還是先找自己原因，然後在追尋**的問題。

最近幾周工作壓力，下面的也比較緊了。

需要談談的遊戲測試（五）

剛獲悉一些問題，有壓力。基本框架本年內肯定是沒完成，每天碎片時間不超過2小時，只能依賴重寫系統測試案，來試圖查出隱患。框架的協作性需要磨合，核心也是節約時間和人力成本 先圖表再歸納成文字。產品最終是定義穩定性和健壯性，某種意義取捨還是關注的是產品的健壯性。如何尋找現有突破，依然是82原則和28定律的...

需要談談的遊戲測試（九）

順應九九歸一，第9章就結束了。到底什麼是黑盒和白盒，我們之前的工作到底完成了覆蓋了多少。測試分為黑盒和白盒，遊戲測試又以入門門檻低而被人熟悉。最原始的方法 根據策劃案按策劃案的模組來實際遊戲的行為步驟書寫測試用例。日常行為執行測試用例為主。tester交叉測試來確保漏測和試圖發現更多的測試點。測試行...

需要談談的遊戲測試（六）好像不是遊戲測試

哪些產業應該使用cmmi，fema，哪些產業不需要使用。如何微縮cmmi和fema。這些過程帶來的是敏捷還是沉重的？什麼又是敏捷？大部分的遊戲公司的測試可以通過各種缺陷管理軟體來獲得乙份簡單的缺陷管理分析圖，甚至額外外掛程式所裝的餅圖和甘比圖等。隨著軟體的公升級變遷，一些可以量化的東西糅和在裡面。那...