【第四課】 三個環境：開發，測試和線上

來自專欄從零開始學產品5 人贊了文章

人間，仙界，神界，真的存在么？

不知道，但是我知道，開發，測試和線上，是一定存在的。

上節課我們說到了，Bug的生命周期，而只有在測試環境和線上環境發現的Bug，才會被稱之為Bug。

倒底是什麼是測試環境，什麼是線上環境呢？開發環境又是什麼，三者之間的關係怎麼樣？

一 從【開發環境】說起

這是蠻荒之地，惟有力量和自然法則永存。

開發環境是研發團隊的領地，你可以把開發環境當成是蠻荒之地，在這裡，惟有力量和自然法則才是統治者，野蠻的研發團隊成群結隊的出現，頻繁的發布版本，經常爆發小規模的資源衝突，荒草重生，各種奇異和鬼怪的現象都會在開發環境出現，就像是一個還未完全成形的小世界，你看到的一切都有可能是假像，昨天發生的事情，到了今天就可能是完全不一樣的結果。

為什麼會這樣？

第一，研發團隊需要提供假數據來保證前後端並發開發。第二，研發團隊經常會出現思維漏洞。第三，不少研發團隊的成員沒有持續集成的習慣， 總是在自己本地環境中做研發。第四，開發環境沒有版本管理，所有的依賴關係都不夠穩定。第五，開發環境是思想從誕生到落地的重要過程， 產品經理的意志最終被研發團隊執行並展現在世人面前， 研發團隊和產品經理的理解偏差也會隨之浮現。

在開發環境中，產品經理或者是測試人員需要提前介入么？

按照我們之後描述的敏捷開發來看，產品經理和測試人員不需要在開發環境正式的介入，特別是當出現開發人員說來不及測試了，所以請測試團隊在開發環境先進行測試的時候。

這樣會導致更混亂，合理的解決辦法是，在明確優先順序的情況下，分出迭代，先保證重要的功能進入測試環境。

那麼，產品人員和測試人員需要做的是什麼？需要是每天在晨會之後，或者是任意一個時間段，到開發環境去看一下，關鍵的邏輯有沒有錯誤，有沒有重大的偏差，而不是做嚴謹的測試。

開發環境對於產品人員和測試人員而言，最重要的環節還在於是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個的NormalBug。

從開發環境通過了Demo，升級到測試環境，就進入了我們的秩序山谷-測試環境（是的，我改了名字，秩序山谷更適應測試環境的名字~）

二 秩序的力量-【測試環境】

我們更新一下圖，如下所示。

測試環境，是測試人員所掌控的世界。在這裡，所有的Bug的發現，流轉，驗收和版本的管理，必須擺脫開發環境的野蠻和無序。

測試環境的秩序體現在以下幾個環節：

1。 發布到測試環境需要登記。我們通常使用Wiki來管理測試環境的發布， 在測試環境中，只有兩種情況下才允許被發布，一種是新的迭代開發，一種是Bug的修復。 這是指，每一次的發布，要麼是對一個迭代開發的需求， 要麼是對一個Bug的修復，不允許說， 我這次發布的功能改了什麼什麼東西，而我們在需求和Bug管理工具上根本看不到。2。發布到測試環境，必須要指定版本號。3。發布到測試環境，必須要指定回滾版本。4。測試環境發布之後，必須由運維，開發依次驗證是否發布成功。5。測試環境的發布，原則上只允許每天發布一次， 運維人員依據每天的測試登記，無腦發布， 所有的操作步驟應該寫在Wiki上， 所有的腳本和Sql都應該在測試環境的Wiki中登記 ， 嚴格執行流程，嚴禁開發人員和運維人員脫離Wiki單獨發布。6。測試環境中，開發人員應該只有讀日誌的許可權，不應該重啟和發布的許可權。

測試環境並不是單純意義上的找Bug，更是對線上環境發布的演練，所以測試環境其實是包含了「演練發布腳本」+「尋找系統Bug」兩個環節，而我們往往會忽視掉第一點，等到線上環境發布的時候出現問題，再怎麼甩鍋都沒用了。

你可以理解為測試環境是試婚，又或者是婚前同居，但其實測試環境遠遠比試婚或者是同居更複雜和嚴謹。在測試環境中，找出來的問題越多，心裡會越踏實，如果你一個Bug沒找到，太完美反而會有不真實的感覺。

在測試環境中，遇到被卡住流程，無法進行操作驗證是非常頭疼的一件事，所以倒推而來，Demo的重要性。

測試環境中，還應該做出一個很重要的判斷，就是發布計劃。這應該由測試，產品和研發共同決定發布的排期。

發布到正式環境，同樣應該是需要在Wiki登記，我們接下來看一看，穿越秩序山谷，是怎麼樣到達真實界元的。

三 【線上環境】-愛我，就用這把刀插進我心裡

我想看看，我自己的心裡倒底喜歡誰，聽說只要刀夠快，就可以讓我在死之前，看到一個真實的自己。

不，你看不到，你只能看到她在心裡，留下了什麼。

上線永遠都是一件恐怖又期待的事情，像少女等情人，怕他不來，又怕他亂來。

上線的嚴肅程度遠程開發環境，歷經開發和測試的層層把關，倒底系統上線之後是什麼樣子，答案即將揭曉。

但無論如何，對線上的操作應該謹記的重要原則如下：

1.如有問題，五分鐘之內無法解決，立刻回滾， 嚴禁在線上調試和解決問題。 2.發布必須選擇每天活躍用戶最少的時候。 3.視發布版本的重要度來決定是否要對用戶公告停機或者是不停機維護。 4.視發布版本的重要度來決定是否對新功能做運營推廣。 5.線上發布必須所有團隊在線 （不要求在場，畢竟通常都是深夜發布，或者是凌晨5點發布） 6.發布之後，運維，研發，測試和產品必須依次驗證。 7.發布之後，重點觀察用戶的反饋和系統日誌， 有很多種異常情況，是你無論在測試環境測試的多嚴謹， 都可能預料不到的（就好像無論你認識一個人多久，都不可能完全了解他一樣）。 8.正常來講，一周只允許兩個時間點來發布， 周二或者是周四，不選擇周末之前的一天， 這樣，如果真的發布失敗，還有一個白天的時間用以解決問題。 9.準備好要祭天的程序員。 10.發布應該當成正常發布和緊急發布。

線上的Bug，一旦是Major級別，可以定性成是事故了，對事故，往往需要擺脫正常發布的限制，可以走緊急發布流程，通常是在單獨的Wiki頁面登記，由產品總監和技術總監簽字畫押。

流程可以後補，但是不能不補，特別是對於沒有打版本發布的場景，手工修改的一些頁面，或者是欄位，往往有可能會被開發人員忘記，又被覆蓋掉。

對於App的，有審核時間的限制，所以向前兼容性，是產品經理要提前重點告知開發團隊，並在測試環境嚴謹測試的。

版本更新通常是分成強制更新和非強制更新，也由產品人員和研發人員共同決定。

四 小結

這次講的三個環境，開發，測試和線上，每一個環境都有他自己不同的特點，測試人員的正常工作環境，就是測試環境，但是不可避免的和開發環境/線上環境都有接觸。

不知道哪裡有一些遺漏，歡迎在評論中指出～～

　另外，文中舉的例子，和一些約定，可以結合自己公司的實際情況做一些變動，但是希望你們能夠理解，每一條，其實都是踩著無數Bug和程序員和產品經理的屍體而來形成的規範~

這其實是屬於敏捷開發中的內容,在我們的另一個專欄里,從零開始學敏捷開發,會有一些內容和這裡的有部分重複,也可以用來互相印證.