現在的遊戲公司是不是覺得做不做測試除錯都無所謂了？
前網路時代遊戲測試除錯是非常嚴肅的事，很多超大作就因為DEBUG進度趕不上，導致超長延期或是揮淚砍內容，所以大項目在進度管理上都比較慎重。自從遊戲機和PC強制聯網後，廠商就越來越隨便了，這次育碧居然能在《俄羅斯方塊》上爆出嚴重等級的BUG，簡直荒誕，當年用彙編寫俄羅斯的時候也沒聽說過這種事。不僅發售前測試不認真，補丁也不認真，過去廠商還知道盡量減小補丁體積，現在一律整個封包替換了事，結果就是40G的大革命補丁。
總之現在的遊戲公司對除錯這件事的認真程度絕對是在下降的，遊戲第一版補丁比遊戲發售日期還早這種事10年前還能上新聞，現在幾乎每個遊戲都這麼干。
因為互聯網思路入侵遊戲界了，快速迭代，先發再修
這是（美國）軟體業的MVP（Minimum Viable Product / 最小可行產品）開發思想感染遊戲業的例子。從軟體業的角度看，MVP是很先進的思想，因為快速推向市場快速試錯最後能得到最匹配用戶需求的產品，而且能保持項目不會錯過deadline很遠。軟體業和互聯網業現在都這麼做了，不這麼做的已經成為歷史的塵埃了。但是如果把這套搬到遊戲業的話...
大部分的成功產品都很少存在這個問題，所謂的快速迭代更多指的是快速測試出用戶的喜好，再根據用戶的選擇來製作傾向內容，這個是一個合理選項的優化問題而不是半成品的測試問題。
1.想出一個理念
2.創造一個原型去測試該理念
3.通過與團隊中的其他成員，更重要的是與之前從未聽說過遊戲的人一起嘗試原型而測試並記錄數據
4.回顧收集到的數據去檢查它是否複合最初的理念和遊戲理念
5.1）如果收集到的數據表明原型並不符合最初的理念或遊戲理念，那就從步驟1再次開始，但記錄下收集到的信息
2）如果收集到的數據表明原型複合最初的理念和遊戲理念，那就移向一個新理念
在Brenda Brathwaite和Ian Schreiber所編寫的《Challenges for Game Designers》以及Jacob A. Stevens所編寫的《Practical Tips for Independent Game Development》等書籍或文章中都以大致相同的方式描述了迭代設計。最近我發現在提到迭代設計時未被討論到的內容便是其陰暗面。當你不具有足夠的經驗，沒有穩定的核心或美感，或者並未基於正確的方式使用迭代設計時，其陰暗面便會出現。我將在本文中更詳細地討論迭代設計，提供給你們關於如何適當地使用迭代設計的足夠信息。
與其它過程一樣，當你擁有更多迭代經驗和遊戲開發經驗時，迭代設計過程將變得更有效。關於迭代設計我學到的一些基本內容是：
存在兩種迭代設計原型類型
整個項目——這應該是你第一個創造的原型。在此確定你的基本遊戲玩法。
個體機制——在基本原型之後你所創造的每個原型都將測試個體機制和較小的改變。這些機制和原型都應該在整體項目中進行測試，從而確保它們不僅能夠有效運行，同時還能夠作用於遊戲中。
如果你不斷遇到特定的設計理念，機制，甚至是核心等問題，請勇敢地丟棄它並重新開始。較小或較短的高質量遊戲總是比一款低質量的長遊戲好得多。註：你應該在製作前做出重新開始的決定，否則將會浪費太多錢與時間，並且將很難重新開始。
不要依賴於迭代設計去為自己創造遊戲。儘管迭代設計是一種強大的工具，你還需要利用美感，動態和機製作為潛在的基礎。如果你嘗試著通過快速創造原型去創造一款遊戲，那麼你最終創造出來的將只是一個有趣但卻毫無關聯的機制。
如果你並不熟悉迭代設計，那麼你需要學習的最重要的部分便是先想出一個理念。
就像你會假設自己何時將想出科學方法一樣，為了更適當地使用迭代設計過程，你便需要為遊戲想出一個主要理念。如果原型是有趣並且可理解的話你仍然能夠找到一個合適的理念，但是你卻不清楚它該如何整合到你的其它理念中。顯然你可以結合所擁有的每個理念進行測試，但是你最好能夠設定一個前進目標，然後想出一個符合該目標的理念。有些遊戲開發者更喜歡先想出機制，然後基於該機制去創造遊戲。正像任何其它開發方法那樣，你也需要明確哪個方法更適合自己。對於那些喜歡從機制開始的人來說，他們將基於各種主題和遊戲風格去測試機制從而明確哪個最適合。需要記住的一個重要元素便是不要在真空中使用迭代設計。你需要不斷比較原型以及你伴隨著自己所希望的遊戲發展整體理念的附件內容。如果你不能從整體上確定自己希望的遊戲發展方向，你最終便只會創造出一款聚集著一些不相干元素（遊戲邦註：雖然有趣，但組合在一起並沒有意義）的遊戲。每當我帶著一個主要想法，如美感或核心理念，而不只是快速創建的原型機制而開始一個項目時，我最終都能創造出一款高質量的遊戲。迭代設計中最容易被忽視的一部分便是，這是為了創造一款最終遊戲而與其它工具一起使用的工具。
使用迭代設計的正確方法是不要單獨使用。舉個例子來說吧，迭代設計可能與測試相混淆，但卻缺一不可。迭代設計是關於不斷重新嘗試新理念去找到最佳的理念結合。測試是關於理念的運行以及目標用戶的理解進行衡量。迭代設計主要是一種前期製作工具，但如果測試發現機制或遊戲某一方面不適合發行時也能夠使用這一工具。測試是用於整個遊戲製作過程。它可能被當成是整體的前期製作過程，只包含許多迭代設計，而當你嘗試著去尋找最佳的機制結合時，你或其它團隊將能明確其它遊戲元素。
我們需要繼續做的一件事便是著眼於遊戲外觀。在前期製作過程中這包含了許多概念藝術。如果你的原型主要是用紙創造的，你還需要找到一個遊戲引擎並開始創造一個數字原型。儘管前期製作過程包含了許多概念藝術，這在開始開發和執行最後的圖像時也不是特別明顯。大多數公司都是帶著較粗糙的圖像開始創造數字原型。這看起來可能很奇怪，但等到原型創建好之後再執行最後的圖像太久了，這將會減少圖像的質量並導致它們最終被丟棄。我們必須記得之前投入於遊戲中的許多創造最終可能都不會被用到。
嘗試著減少無用功的數量，不要強制將這些努力添加到遊戲中，而是在圖像團隊開始創造前明確需要做些什麼並使用什麼。如果你認為遊戲中有個關卡突出了玩家可能需要進入的一艘大船，那就讓一名關卡設計師去創造一個較為粗糙的關卡去突出這樣的船隻，並使用迭代設計去測試這一部分是否與關卡相符合。在測試船隻的同時，你的概念設計師將想出許多不同的船隻外觀。如果所有的一切都進展順利並且船隻符合關卡設定，之後你的圖像團隊將致力於它的最終迭代。需要注意的是我說的是迭代，因為就像遊戲一樣，你的圖像和資產也將經歷迭代。大多數資產迭代都需要與概念藝術一起完成，因為概念藝術比完整的紋理模型更難創造。創造一款遊戲需要投入許多時間和努力，所以你必須確保好好使用自己所擁有的每一種工具。迭代設計是能夠完善遊戲質量並提高效能的工具之一。
至少部分項目是的，我在安裝微軟的framework 3.5時，提示要必須已經安裝好framework3.5才能繼續
你跟我說這是經過完整測試我肯定是不認的
證據嘛，百度一下，你就知道
因為網路時代之前出了bug修復成本很高，如果出現壓盤後曝出重大bug，重新壓盤、鋪貨的成本研發公司要承擔的。就和手機、汽車召回一樣。
其實比這個更恐怖的是做柏青哥，當初國內有些公司接過日本的外包項目，都是讓最牛逼的程序員來做。因為如果柏青哥出了bug，要被黑社會叫去喝茶的…簡單來說，是因為市場變化太快，時間就是生命。
端游和頁游的市場我不是很了解，但是對於手游來說，一個遊戲能火半年左右時間就是很成功的，一個題材能火一年左右也就差不多到頭了。而國內現在的遊戲製作主流還是抄襲，這就造成留給抄襲者的時間非常之短，比如某個公司看到最近新上線了一個遊戲保衛蘿蔔很火爆，於是該公司也想做一個類似的，但如果該公司不能把開發時間控制在3到6個月以內，就意味著上線時間就是1年左右（因為要算上商務洽談，評審，接入渠道，內測等等流程的時間）。而大家現在可以看到1年之後保衛蘿蔔這個類型的題材，基本已經沒有多少熱度了。所以6個月的研發時間基本就是大部分抄襲類手游的生死線，但這個研發時間是根本無法保證深度測試和調優的。
而對於手游中的網遊也是類似，基本上廠商做出前一個月的遊戲內容就要開始找渠道聯繫上線了，某些遊戲甚至過分到只有2個星期的內容就敢上線內測，然後就期待遊戲可以火爆，賺錢，在運營過程中再把後面的內容補上。如果讓他們做3-6個月的內容再把遊戲放出來，估計研發周期都要到1年以上，大部分小公司是根本沒有這個財力支持的。
大公司財力倒是沒問題，可是內部的遊戲製作團隊卻大多都是小規模的，每個團隊也都是有年度目標和KPI要背的，如果1年多沒任何收入和業績，被砍掉的可能性很大，就算沒有被砍掉，被別的成功團隊挖走骨幹或者隊內成員直接跳槽的可能性也很大，結果就造成了大家都急功近利的往前趕，因為只有賺錢了團隊才能活下來。
總的來說，是整個環境太浮躁，絕大部分產品的目的是賺錢，不是做個好遊戲。
附圖說明當前手游團隊的開發狀態：
一些公司戰線拉得太長，項目太多，遊戲出得太快，這樣導致給每個遊戲分配的工時嚴重不足。
也就是在遊戲開發之初，高層的計劃就出現了錯誤，他們1)對項目的困難程度沒做出正確的評估，2)在出現困難的時候沒有考慮增加開發時間，3)可能也覺得有打補丁的後路。
測試肯定還是做過的，但人手不足，測試的效果就會大打折扣了。
(我還以為只有大學裡老師帶學生做項目才會犯這種低級錯誤，沒想到，育碧這樣濃眉大眼的也...建議育碧好好總結經驗，出一本《大革命神話》。)我現在在加拿大一個IT公司做QA，就是測試員，上一個工作也是QA。雖然我們公司並不是做遊戲的，但是作為在不同的公司工作過的QA，我應該可以稍微回答一下這個問題。
首先，不要質疑說QA不認真工作。至少我待過的兩個團隊的理念都是："我們一定要在客戶發現之前先找到bug"。每個release我們都要做至少一遍的regression testing把我們所有的產品和功能都測一遍，大一點的release要反反覆復的測很多遍。有時候程序員只花了幾個小時改了一個bug我們整個team要加班把整個產品測一遍。——我們每天就浸淫在產品里，絕對比客戶使用的頻率高多了。
題主說居然有嚴重bug，這個其實挺正常的。我們工作的時候如果發現了bug，第一件事是嘗試重現它(reproduce it)，很多時候它就曇花一現了。經常就是我在我機子上發現了這個，程序員無法重現，我再試它又沒了，整個team沒人遇到過。這個bug會被暫時擱置因為可能是剛剛網路有問題啦，或者你的機子剛剛傻啦。
另一種可能是在測試環境里沒有這個bug，但是在把程序deploy到產品里的時候這個bug才出現。在這個情況下就只能緊急的去改bug，重新在QA環境測試，再做一遍regression(以防產品變得更糟)，再把改好的代碼放出去。當然，這個時候你們(用戶)都已經發現這個bug啦。
第三種可能：有個東西叫code freeze。就是在產品發售或者大更新前一段時間，程序員就不能再commit code了。也就是測試環境里的代碼不能更改了。那段時間QA發現的bug很多都要在後一個更新里再發出去。這也可能是為什麼很多遊戲發售的時候已經有第一個補丁了。
最後一個可能(個人猜測)：大部分育碧的QA估計忙著測刺客信條吧：P
———————————————————————
收尾：
1. 測試人員沒有不認真之說，大家都工作賺錢，不認真錢怎麼來？而且我們每天都是花一整天在一個產品上，看著它從一小塊一小塊變成完整的產品，大家某種角度都當它是自己的孩子，都希望讓它更好，也希望用戶的體驗更好。
2. 現在的測試可能是比過去越來越好的，技術也在提升。以前測試員只能在測試環境測，在代碼deploy到production之前都不敢完全確定在實際環境會不會有問題。現在有些行業已經有技術手段可以模擬了。QA行業也越來越專業化了。
3. 一個產品在製作的過程中真的有很多很多的bug，有的時候真的是改不過來，加班也改不過來。可能你修好了這個，附帶著又出了新的。但是發售日是定的，不能為了一兩個bug而延期。如果延期那真的是bug太多了(我們就有過)，損失很大。我說一個不一樣的原因，以我們公司為例：
程序花了一周多時間（算上查問題的時間）修改的底層bug，需要全系統回歸測試。然後測試組分分鐘就fixed了該任務項。
沒錯，我就是在說遊戲測試的問題。說策劃普遍坑、從業者素質低下，但好歹有個主策劃製作人什麼的還能靠譜點。那一些小公司的遊戲測試，真的就是那些想做低素質策劃都不夠格人了。腳本要策劃給、工具要程序寫、環境要運維部署，除了登陸遊戲開個按鍵精靈點點點，真的不會別的了。為什麼遊戲測試這麼坑，因為老闆不重視測試，招人第一原則是工資低，只是覺得我們需要個測試部門而已。吐槽完畢匿了網遊的話，現在都用腳本語言了，發現了問題就直接在線熱更新。看著每天收集上來的報錯，想這要是過去程序這樣不停的掛掉產品早死了
遊戲大廠當然是有自己的測試流程的。連這都沒有也別厚著臉皮稱自己是大廠了，最多算是個大作坊。甚至流傳的某些流程也可能是真的。但是這個流程是不是總能不折不扣執行，那就是另一回事了。為了趕進度而砍測試流程，早就是司空見慣的事情了。
不管怎麼說遊戲本質是藝術品，遊戲仍然有工業產品性質，符合工業產品的規律。項目進度管理一向是世界性難題，世界級大廠+世界級大師+世界級項目三重BUFF都保證不了不翻車，所以無論是誰，只要混得時間久了，早晚都得面對時間不夠，不能跳票的場面。這時候質量和進度最多只能管住一頭。
選前者，結果就是FF15和MGSV那樣。遊戲缺胳膊少腿，但是已經做完的部分質量有保障。
選後者，那就是育碧和EA的BUG流咯。
我有點好奇書記為什麼問這個問題。按說以書記從ET到FF15如數家珍的閱歷，不應該看不出來背後這個原因啊。莫非就是想發發牢騷？
也別厚古薄今了，ET就是沒有測試直接趕鴨子上架。黑心資本家從未變過，30年和現在一個樣。
如何評價育碧彩虹六號bug導致ps4系統崩潰？
主機玩家可能是頭一次見到這種等級的bug，IT界的話也是見怪不怪了。
轉發一個很歡樂的bug：一個空格引發的慘劇 | 創意科技小組 | 果殼網 科技有意思
這個BUG觸發機率100%（只要你試圖卸載bumblebee），結果是毀滅你的linux系統。沒錯，是毀滅，保證再起不能，只能重裝。
先回答題主的問題: 當然不是，雖然我不在育碧工作，但我可以肯定育碧這種公司對於測試的要求是相當嚴格的，即使到今天絕大多數遊戲公司（包括國內的公司)也是十分重視測試環節的。為什麼我這麼肯定？學過軟體工程的都知道，問題發現的越早，解決問題的代價越小，再唯利是圖的公司，也不會再主觀上放任遊戲不嚴格測試就面向市場。那麼肯定有人會問，你說你們都仔細測試了，為什麼還會有各種各樣的bug產生？下面是複製黏貼:
軟體缺陷中的8020原則（即二八原則）：
在軟體測試過程中，從需求分析開始到集成測試階段引入測試手段，能發現所有缺陷的80%；系統測試階段引入測試手段，能發現剩餘缺陷的80%；在運行維護階段經長時間，大量運行軟體後，能夠發現剩餘的20%。
解釋的已經很清楚了不是？碼農和QA也是普通人，不可能100%預見所有可能的情況，即使預見了，有時候也不能執著於萬分之一的可能性而拖延交付/上線日期。更何況路並不是只有一條，聰明的碼農們有各種打補丁/熱更新/回檔的防備措施，運營同學們還有補償方案準備著。玩家們又有什麼可擔心的呢？
他們把封測當內測，內測當公測，越來越沒節操了。
不，至少我的84部作品都是排除了漏洞才發布的
如果想問現在的大廠是不是不做測試了？答案是當然還在做，否則你看到的bug會更多。
如果想噴那個40g的補丁，可以先去閱讀下除了國內二手媒體之外的遊戲媒體。40g是xb1平台獨享的問題，是M$的補丁機制搞出來的。當然，6g的補丁和你平時喜聞樂見的30m漢化補丁或者600k破解補丁相比，確實大了很多。但根據官方說法，整個巴黎的地圖數據被重新調整了，這個大小並不奇怪。
其他的就不用發揮了，這些事情和po主這樣靠YY來了解業界的玩家其實都沒什麼關係……本質上是一個檔期和工程進度的矛盾造成的必然結果，再加上媒體的發揮而醞釀出的公關災難而已。
玩家真正該關心的事情：我自己遇到bug了嗎？這bug能否被補丁解決？不能解決我可以退貨嗎？下次買遊戲之前先緩一緩，看看風評。當然，如果是下載的就別那麼糾結了……別說遊戲了。。。這玩意兒出了bug還能給你打補丁。現在就是有實體的玩意兒也是這尿性了，一代代更替越來越快，不更新怎麼圈錢
遊戲都是一邊賣一邊Alpha Test的，steam 上一堆
為什麼ea不是最爛的美國遊戲公司？因為育碧在法國朋友 您知道 bug革命-大補訂 么
一般都是出了事又開始重視質量了
是的，X1是6.7G的補丁，但是不適用與第三版補丁之後，打了之前第三版補丁的X1用戶只能卸載遊戲再安裝然後再更新補丁，這對於數字版用戶而言，就是46.7G的補丁！
我從一個玩家的角度來說下吧。現在很多遊戲還是有測試的。比如我知道的很多手游，例如supercell的皇室戰爭、荒野亂斗都是現在紐西蘭加拿大之類的市場先上線。包括我朋友的手游公司都是現在韓國等海外市場上線。為啥？就是為了在國外這些小市場做足了測試，才會在國內上線。這樣避免因為重大bug沒有發現，從而影響中國這個大手游市場的表現。
推薦閱讀：
※你是如何接觸到自己最喜愛的那款遊戲的？
※為什麼女生基本都不愛玩策略類遊戲？
※遊戲中有哪些知名的大型公司/財閥/社團？
※你們玩群星時，是否會關注每一位領導人的一生？