從零開始學產品第五篇：三個環境，開發、測試和線上
本篇為【從零開始學產品】系列課第1章第4節
歡迎到公眾號選單欄，獲取產品經理課程更多資料
上節課我們說到了，Bug的生命週期，而只有在測試環境和線上環境發現的Bug，才會被稱之為Bug。
倒底什麼是測試環境，什麼是線上環境，開發環境又是什麼，三者之間的關係怎麼樣？
一 從【開發環境】說起
這是蠻荒之地，惟有力量和自然法則永存。
研發領域
開發環境是研發團隊的領地，你可以把開發環境當成是蠻荒之地。
在這裡，惟有力量和自然法則才是統治者：
野蠻的研發團隊成群結隊的出現，頻繁的釋出版本，經常爆發小規模的資源衝突。
荒草重生，各種奇異和鬼怪的現象都會在開發環境出現，就像是一個還未完全成形的小世界。
你看到的一切都有可能是假像，昨天發生的事情，到了今天就可能是完全不一樣的結果。
為什麼會這樣？
第一，研發團隊需要提供假資料來保證前後端併發開發。
第二，研發團隊經常會出現思維漏洞。
第三，不少研發團隊的成員沒有持續整合的習慣
第四，開發環境沒有版本管理，所有的依賴關係都不夠穩定。
第五，開發環境是思想從誕生到落地的重要過程，產品經理的意志最終被研發團隊執行並展現在世人面前，研發團隊和產品經理的理解偏差也會隨之浮現。
破局
在開發環境中，產品經理或者是測試人員需要提前介入麼？
按照我們之後描述的敏捷開發來看，產品經理和測試人員不需要在開發環境正式的介入：
特別是當出現開發人員說來不及測試了，所以請測試團隊在開發環境先進行測試的時候。
這樣會導致更混亂，合理的解決辦法是，在明確優先順序的情況下，分出迭代，先保證重要的功能進入測試環境。
那麼，產品人員和測試人員需要做的是什麼？
需要是每天在晨會之後，或者是任意一個時間段，到開發環境去看一下，關鍵的邏輯有沒有錯誤，有沒有重大的偏差，而不是做嚴謹的測試。
Demo
開發環境對於產品人員和測試人員而言，最重要的環節還在於是Demo。
關於Demo，我們陸續發現有一些誤區，特此宣告。
第一，Demo是開發團隊向產品團隊交付，所以Demo的主角是研發團隊。
第二，Demo應該依照Story去演示功能，防止有遺漏。
第三，Demo之後就會打Tag（固定程式碼版本），所以Demo應該是非常嚴謹的。
從來都沒存在所謂的主流程跑通，而是應該一行程式碼都不需要改動，直接釋出到測試環境。
第四，Demo過程中，有一個Demo通過的基本原則：
就是但凡是肉眼能夠發現的錯誤，都應該記為不通過。
而不是說，有幾個Minor級別的小問題，可以通過。
第五，下次Demo的時候，可以只演示Demo中出現的問題，以節省時間。
第六，產品人員和測試人員應該參加Demo。
Demo的時候不僅是要看一下研發團隊的操作，還應該自己親自在PC或者是手機上操作。
第七，Demo的資料應該使用模擬資料 ，（而不是隨意填寫的測試一，測試王八蛋之類的）。
第八，在Demo之前，應該先進行效能測試，UI自檢規範和CodeReview，三者通過之後才允許Demo。
第九，如果有Bug的修復，也應該在開發環境先向測試人員演示通過，才允許釋出到測試環境，以減少反覆釋出測試的次數。
第十，Demo過程中發現的問題，應該記錄下來責任人和預計修復時間。
好了，從混沌無序的開發環境，到釋出到測試環境，必須有序且穩定：
隨著開發人員的深入，衝突的規則越來越少，我們通常認為在測試環境，應該檢測出來的Major級別以上的Bug為0，不多於4個的Normal Bug。
從開發環境通過了Demo，升級到測試環境，就進入了我們的秩序山谷-測試環境
（是的，我改了名字，秩序山谷更適應測試環境的名字~）
二 秩序的力量-【測試環境】
我們更新一下圖，如下所示。
測試領域
測試環境，是測試人員所掌控的世界。
在這裡，所有的Bug的發現，流轉，驗收和版本的管理，必須擺脫開發環境的野蠻和無序。
測試環境的秩序體現在以下幾個環節：
第一，釋出到測試環境需要登記。
我們通常使用Wiki來管理測試環境的釋出，在測試環境中，只有兩種情況下才允許被髮布：
一種是新的迭代開發，一種是Bug的修復。
這是指，每一次的釋出，要麼是對一個迭代開發的需求，要麼是對一個Bug的修復。
不允許說，我這次釋出的功能改了什麼什麼東西，而我們在需求和Bug管理工具上根本看不到。
第二，釋出到測試環境，必須要指定版本號。
第三，釋出到測試環境，必須要指定回滾版本。
第四，測試環境釋出之後，必須由運維，開發依次驗證是否釋出成功。
第五，測試環境的釋出，原則上只允許每天釋出一次。
運維人員依據每天的測試登記，不能無腦釋出。
所有的操作步驟應該寫在Wiki上，所有的指令碼和Sql都應該在測試環境的Wiki中登記。
嚴格執行流程，嚴禁開發人員和運維人員脫離Wiki單獨釋出。
第六，測試環境中，開發人員應該只有讀日誌的許可權，不應該重啟和釋出的許可權。
測試到釋出
測試環境並不是單純意義上的找Bug，更是對線上環境釋出的演練。
所以測試環境其實是包含了“演練釋出指令碼”+“尋找系統Bug”兩個環節。
而我們往往會忽視掉第一點，等到線上環境釋出的時候出現問題，再怎麼甩鍋都沒用了。
你可以理解為測試環境是試婚，又或者是婚前同居，但其實測試環境遠遠比試婚或者是同居更復雜和嚴謹。
在測試環境中，找出來的問題越多，心裡會越踏實，如果你一個Bug沒找到，太完美反而會有不真實的感覺。
在測試環境中，遇到被卡住流程，無法進行操作驗證是非常頭疼的一件事，所以倒推而來，Demo的重要性。
測試環境中，還應該做出一個很重要的判斷，就是釋出計劃：
這應該由測試，產品和研發共同決定釋出的排期。
釋出到正式環境，同樣應該是需要在Wiki登記，我們接下來看一看，穿越秩序山谷，是怎麼樣到達真實界元的。
三 【線上環境】-愛我，就用這把刀插進我心裡
我想看看，我自己的心裡倒底喜歡誰，聽說只要刀夠快，就可以讓我在死之前，看到一個真實的自己。
不，你看不到，你只能看到她在心裡，留下了什麼。
上線
上線永遠都是一件恐怖又期待的事情，像少女等情人，怕他不來，又怕他亂來。
上線的嚴肅程度遠超開發環境，歷經開發和測試的層層把關，倒底系統上線之後是什麼樣子，答案即將揭曉。
但無論如何，對線上的操作應該謹記的重要原則如下：
1.如有問題，五分鐘之內無法解決，立刻回滾，嚴禁在線上除錯和解決問題。
2.釋出必須選擇每天活躍使用者最少的時候。
3.視釋出版本的重要度來決定是否要對使用者公告停機或者是不停機維護。
4.視釋出版本的重要度來決定是否對新功能做運營推廣。
5.線上釋出必須所有團隊線上 （不要求在場，畢竟通常都是深夜釋出，或者是凌晨5點發布）
6.釋出之後，運維，研發，測試和產品必須依次驗證。
7.釋出之後，重點觀察使用者的反饋和系統日誌，有很多種異常情況，是你無論在測試環境測試的多嚴謹，都可能預料不到的。
（就好像無論你認識一個人多久，都不可能完全瞭解他一樣）。
8.正常來講，一週只允許兩個時間點來發布，週二或者是週四，不選擇週末之前的一天，這樣，如果真的釋出失敗，還有一個白天的時間用以解決問題。
9.準備好要祭天的程式設計師。
10.釋出應該分成正常釋出和緊急釋出。
嚴謹的流程
線上的Bug，一旦是Major級別，可以定性成是事故了，對事故：
往往需要擺脫正常釋出的限制，可以走緊急釋出流程：
通常是在單獨的Wiki頁面登記，由產品總監和技術總監簽字畫押。
流程可以後補，但是不能不補，特別是對於沒有打版本釋出的場景，手工修改的一些頁面，或者是欄位：
往往有可能會被開發人員忘記，又被覆蓋掉。
對於App的，有稽核時間的限制，所以向前相容性，是產品經理要提前重點告知開發團隊，並在測試環境嚴謹測試的。
版本更新通常是分成強制更新和非強制更新，也由產品人員和研發人員共同決定。
四 小結
規範
這次講的三個環境，開發，測試和線上，每一個環境都有他自己不同的特點。
測試人員的正常工作環境，就是測試環境，但是不可避免的和開發環境/線上環境都有接觸。
不知道哪裡有一些遺漏，歡迎在評論中指出～～
另外，文中舉的例子，和一些約定，可以結合自己公司的實際情況做一些變動。
但是希望大家能夠理解：
每一條，其實都是踩著由無數Bug和程式設計師、產品經理的屍體形成的規範~
這其實是屬於敏捷開發中的內容，在我們的另一個專欄裡,從零開始學敏捷開發，會有一些內容和這裡的有部分重複,也可以用來互相印證。
小編注：
【從零開始學敏捷開發】致力於將一套可落地執行的敏捷開發流程分享給大家
該流程面向專案團隊全體成員，定位了每個職業在敏捷開發流程中扮演的角色，以及在專案研發不同階段的流程規範。
無論是對團隊協作開發一無所知的專案新手，還是想要提高團隊開發效率，減少BUG數量的技術總監，都能從自己的角度有所收穫。
歡迎掃碼關注
第一章第四節的內容就到此結束
下節預告：
【更強大的測試：自動化測試和效能測試】，敬請期待
歡迎來交流群與大家一起學習討論，在裡面進行實時的溝通答疑
微信分享人：
暗滅，出身搜狐，葡萄藤創始人/CEO，10年敏捷開發最佳實踐
駐場大神：
搜狐產品大神張春源：10年+產品開發經驗，高屋建瓴
冰秀大神：出身搜狐，連續創業，創業者的產品即是公司：一家被收購，一家上市，匠心獨運
想進群的請加大師姐微信邀請進群：
記得備註學產品喲