網際網路的產業裡，網路遊戲產業也是其中的一部分，改良流程的一部分也介紹一些基礎的模型。本章介紹的是瀑布模型的應對辦法。
瀑布生命週期模型：（也被稱為線性模型）
[需求分析]=>[概要設計]=>[詳細設計]=>[編碼和單元測試]=>[軟體集中]=>[系統集中]=>[驗收測試]=>[結束]
這是乙個版本簡單的交付過程，最後一步測試才介入。這個軟體行業剛發展時的流程。現在依然還是不少遊戲公司的交付模式。
遊戲產業有些許的變化：
前者
[需求分析]由策劃部門給予 通常由2個部門執行：程式，美術
[概要設計]通常由3個部門執行：策劃，程式，美術。
[詳細設計]通常由3個部門執行：策劃，程式，美術。
[編碼和單元測試]由程式部門執行。
遊戲產業測試大部份公司都無法獲悉**，所以這部分就沒辦法了。
[軟體集中]由程式部門執行。
這個應該是程式的**view，具體對不對我也不清楚。
[系統集中]功能模組的集中，準備交給測試了。
在瀑布生命週期裡，這時候還是沒有交給測試。
[驗收測試]
這個版本的內容終於交到測試手中了。
如果遇到這種情況，我們該怎麼辦呢？接下來看看這個流程：
後者
[需求分析]由策劃部門給予 對口的部門：程式，美術，測試
測試獲得策劃部門的策劃案後，先進行需求分析。新增總表的測試計畫，分析關係點和測試粒度。
[概要設計]通常由3個部門執行：策劃，程式，美術，測試。
測試也可以加入，但是和其他2個部門無交集。編寫第乙個版本的測試用例。
[詳細設計]通常由3個部門執行：策劃，程式，美術。
測試也可以加入，可能和策劃溝通較多。考慮到一些介面設計和測試用例補充完整。
[編碼和單元測試]由程式部門執行。
當然如果你願意的話，也可以提供些靜態**測試工具。例如pr公司的prqa。靜態的**不需要經過調式。
[系統集中]功能模組的集中。可能在這個階段進行了多次迭代測試。當缺陷數量滿足缺陷密度大概2次左右，實際是根據當前版本內容而定的。
[驗收測試]
接下來按策略進行快速回歸和冒煙就可以發布，看這個時候就能輕鬆交版本了。而測試團隊的能力也不會因為大量等待的空檔期而荒廢。
然後前者傳統等待的辦法，會一時很緊一時過鬆。而且整個專案的進度也會因為測試週期和延後修復bug占用正常研發團隊的沉餘時間。
另外注意一些固定規則的無益：
（1）團隊比較忌諱有不合理的空檔期 （2）在缺陷密度已經達到後，依然進行量化測試、 end
需要談談的遊戲測試（五）
剛獲悉一些問題，有壓力。基本框架本年內肯定是沒完成，每天碎片時間不超過2小時，只能依賴重寫系統測試案，來試圖查出隱患。框架的協作性需要磨合，核心也是節約時間和人力成本 先圖表再歸納成文字。產品最終是定義穩定性和健壯性，某種意義取捨還是關注的是產品的健壯性。如何尋找現有突破，依然是82原則和28定律的...
需要談談的遊戲測試（九）
順應九九歸一，第9章就結束了。到底什麼是黑盒和白盒，我們之前的工作到底完成了覆蓋了多少。測試分為黑盒和白盒，遊戲測試又以入門門檻低而被人熟悉。最原始的方法 根據策劃案按策劃案的模組來實際遊戲的行為步驟書寫測試用例。日常行為執行測試用例為主。tester交叉測試來確保漏測和試圖發現更多的測試點。測試行...
需要談談的遊戲測試（五）
剛獲悉一些問題，有壓力。基本框架本年內肯定是沒完成，每天碎片時間不超過2小時，只能依賴重寫系統測試案，來試圖查出隱患。框架的協作性需要磨合，核心也是節約時間和人力成本 先圖表再歸納成文字。產品最終是定義穩定性和健壯性，某種意義取捨還是關注的是產品的健壯性。如何尋找現有突破，依然是82原則和28定律的...