哪些產業應該使用cmmi，fema，哪些產業不需要使用。如何微縮cmmi和fema。這些過程帶來的是敏捷還是沉重的？什麼又是敏捷？
大部分的遊戲公司的測試可以通過各種缺陷管理軟體來獲得乙份簡單的缺陷管理分析圖，甚至額外外掛程式所裝的餅圖和甘比圖等。隨著軟體的公升級變遷，一些可以量化的東西糅和在裡面。
那麼缺陷管理是如何做的？每個版本的階段該如何介入？
在拿到一項新的需求任務時，先需要確定該項任務的時間，規模（內容涉及點），人力（和其他專案是否有衝突），工作量（度量專案完整度），範圍（優先測試範圍）。其中人力部分是一切的關鍵。p-cmmi
當這部分確定了，我們才開始進行下一步。
首先對規模裡的內容進行分析屬性，哪些需要交叉，哪些需要重新開始做。**行數（遊戲產業未知），變更複雜度進行度量。
然後制定模組的型別，參與的人員，考量人員的對應的熟悉度。參與人員越少時越需要注意，一次錯誤的度量將導致本次任務的延期。（除非團隊中有多個特性員工，快速工作能力，那就可以彌補），測試負責人需要有乙份cmmi裡的piid表（簡略）。這部分是個人所帶的團隊條件許可情況下，必須要有的。團隊成員或者自己乙個人填滿這張表，就可知道，風限是可以控制還是不可控制的了。推薦團隊成員一起提公升。
分二個工作流程線，一部分在做模組文件和模版時，一部分會做測試套件，在平時測試的過程中，我們累積了一些功能模組的缺陷和易發缺陷的測試點，這個時候會把這些內容單獨放在乙個表裡，新增測試用例進去就完成了套件的功能。用測試套件具備較強的機動性。通常情況下，前期的籌畫分為2組即可。
上述內容最終轉化為確定一項關鍵，測試粒度的大還是小。測試時間的週期是否需要順延。如何照顧團隊人員的情緒等。而這部分需要明確的是缺陷管理對於測試的方向定位並不關注。（測試方向定位可看未來的教程裡）
執行時，測試案工作（發現問題）和（驗收上個版本問題）及（測試套件的回歸），收斂缺陷。產生最基本的缺陷圖，模組分布圖，nop圖，風險槓桿圖等，所謂的八表歸元法，也就是8張不同作用的表，統計辦法根據缺陷管理工具和平時記錄，不追求什麼美觀的話，可以用execl或者ppt快速生成這類的表。統計的過程需要比較長。
可以用多款工具一起來做，但要思考工具之間的關聯性。
測試過程中記得定期支援你的隊友或者平級或者下屬上司，提供一些測試過程中有幫助的截圖或者類似ps，當然如果一直沒有組織級的資料庫和平時不在意缺陷管理軟體的版本正確性，那就只能袖手旁觀了。
統計學最怕是混入了大量看起來很對或者一看就很糟的資料。勤用指筆有時候會比電腦好。
團隊工作第一次結束後，可以定義交付這次結果的乙個模型，是該用線型（瀑布）或者v,w,**，螺旋等？
這個時候如果迷茫的話，可以借助經驗資料的得出的指標，對於未來的這次做為管理依據，但用了這種方法，並不會記得在案。無論結果與否，下次依然需要和這次的相匹配。
希望看的明白。
需要談談的遊戲測試（五）
剛獲悉一些問題，有壓力。基本框架本年內肯定是沒完成，每天碎片時間不超過2小時，只能依賴重寫系統測試案，來試圖查出隱患。框架的協作性需要磨合，核心也是節約時間和人力成本 先圖表再歸納成文字。產品最終是定義穩定性和健壯性，某種意義取捨還是關注的是產品的健壯性。如何尋找現有突破，依然是82原則和28定律的...
需要談談的遊戲測試（九）
順應九九歸一，第9章就結束了。到底什麼是黑盒和白盒，我們之前的工作到底完成了覆蓋了多少。測試分為黑盒和白盒，遊戲測試又以入門門檻低而被人熟悉。最原始的方法 根據策劃案按策劃案的模組來實際遊戲的行為步驟書寫測試用例。日常行為執行測試用例為主。tester交叉測試來確保漏測和試圖發現更多的測試點。測試行...
需要談談的遊戲測試（五）
剛獲悉一些問題，有壓力。基本框架本年內肯定是沒完成，每天碎片時間不超過2小時，只能依賴重寫系統測試案，來試圖查出隱患。框架的協作性需要磨合，核心也是節約時間和人力成本 先圖表再歸納成文字。產品最終是定義穩定性和健壯性，某種意義取捨還是關注的是產品的健壯性。如何尋找現有突破，依然是82原則和28定律的...