1、立項階段

立項階段從公司戰略分解開始，然后通過市場調研獲取客戶需求，然后梳理產品方向形成產品提案給產品委員會審批，審批通過后正式進入產品研發階段。

1、市場調研

需求調研就是通過調研篩選典型客戶，并對這些客戶的需求細節進行匯總和梳理。

典型客戶一般都通過用戶畫像的形式進行描述。對已有產品，可以直接通過數據統計部門拿到用戶畫像數據。用戶畫像一般都是通過抽樣方法，隨機抽取一批客戶（例如1%或者1萬個以下）進行問卷調查。

QQ早期用戶畫像數據，對新產品則需要先約定大致客戶群特征，然后針對這個群體做抽樣問卷調查。問卷設計一般都需要產品經理完成，然后可以找專業調研公司去實施。

新華信協助QQ音樂產品團隊進行用戶調研

2、客戶需求分析

客戶需求分析就是將調研過程中涉及的需求信息，根據需求重要程度分級，優先滿足客戶基礎需求，也就是我們常說的客戶痛點。

騰訊視頻的需求層次分析V1.0

3、編寫產品提案

立項階段主要是要輸出產品提案，提交給公司產品委員會決策。產品提案也就是“商業需求文檔”，簡稱BRD（Business Requirement Document），是基于商業目標或價值所描述的商業需求。其核心用途是用于在投入研發之前，為企業高管層提供決策評估依據。其內容涉及產品概述、市場需求、競爭環境、重要性、成功要素、營銷策略、盈利預測等內容，一般比較短小精煉，不包含產品細節。

支付寶用戶事業部產品提案模板

4、提交產品決策委員會評審

提案評審主要是判斷以下要點：與戰略關聯關系是否緊密？產品價值有多大？資源投入有多大？公司產品決策委員會根據提交的產品提案進行評估，評估流程如下圖所示：

產品決策委員會決策流程

2、產品設計

產品設計分為輸出概念設計、輸出功能清單、輸出需求概要文檔、輸出需求詳情文檔等步驟。

1、產品概念設計

概念設計是非常關鍵的產品環節，簡單明確的概念不僅讓客戶更容易理解，也讓產品研發過程思路清晰、少走彎路。而且，概念設計也是軟件架構師將產品概念轉化為技術對象化模型的關鍵環節。

以支付寶產品為例，就是采用了“錢包”概念模型。錢包里有現金、銀行卡，也可以放身份證、名片、照片、小票、發票等。區分好需求層級，產品交互體驗的層次和用力程度自然就出來了。

支付寶錢包用戶產品模型

2、確定產品功能組合

根據產品概念模型和需求優先級，確認關鍵性的功能要點。

QQ音樂關鍵功能要點

3、確定功能清單

然后對功能進行樹狀化梳理，把所有功能點都整理到一個列表里。

QQ影音產品功能清單V1.0

這些功能點后續都作為需求點加入項目管理系統TAP中，方便團隊所有成員溝通和完善這個功能清單。形成功能清單初稿后，產品經理需要先在產品團隊中組織討論完善，然后再找運營團隊溝通完善，然后是找交互視覺團隊補充完善，最后再找研發項目經理、研發、測試、運維等角色溝通完善。

這個過程既是幫產品經理完善的過程，也是形成團隊共識、激發團隊熱情的過程。

4、輸出需求概要文檔

概要文檔明確某個功能模塊下的功能介紹，一般是多個功能點的描述。需求概要一般由產品經理負責撰寫，不包含功能細節描述。為了方便與產品設計師們溝通需求，可以將主要功能界面草稿加入該文檔中，用原型草圖能更好地描述主要功能。

騰訊視頻PC版播放模塊的需求概要文檔

有了某個模塊的需求概要文檔后，研發項目經理組織團隊溝通需求概要。產品經理首先介紹需求概要然后由其他團隊成員提出自己關心的專業問題。會前產品經理提前分享文檔，并收集準備大家的問題點。

會后主架構師根據需求概要做架構設計框架，研發工程師也可以針對自己負責的模塊做技術預研。有經驗的工程師，往往在這個階段就開始試著做個Demo，把主體功能流程跑通，這樣在正式進入研發時就會比較輕松，專注于細節完善和產品質量。

5、輸出需求詳情文檔

需求詳情文檔由產品設計師負責編寫。需求概要中的需求點，每個都需要單獨編寫需求詳情文檔，而不是把所有的需求詳情都寫在一個文檔里。這樣會導致需求詳情文檔非常長，內容龐雜，這個會導致后續很多問題。需求點最好都能拆分到1周內能完成研發測試比較好，這樣才能有效實現敏捷開發。

騰訊視頻PC版自動登錄需求文檔

需求文檔并不是產品設計師一個人閉門造車就能寫出來的。產品設計師需要頻繁與交互、運營、視覺、用戶研究（UER）、架構師、測試經理、開發、運維等人員溝通。溝通的過程更多是產品設計師學習和融合各個角色思考的過程，同時也讓各個角色的工作更加明確。

一般需求文檔的編寫分成以下步驟：

第1步：根據需求概要設計用戶操作流程圖。

第2步：根據用戶操作流程拆分各個界面，繪制主界面草圖加入文檔，再分別描述每個界面的主要元素和功能點，再描述界面之間交互的邏輯，最后加上交互背后涉及的業務邏輯。

第3步：找運營溝通需求，根據運營人員的建議補充營銷位、運營后臺工具等內容。

第4步：找交互設計師溝通交互細節，根據交互設計師的疑問補充界面中的交互邏輯。交互設計師完成交互設計稿后，將交互稿截圖并加入文檔，并完善交互邏輯說明。

第5步：找視覺設計師溝通視覺細節，提醒視覺設計師突出重點。視覺設計師完成設計稿后，將設計稿截圖并加入文檔，并完善視覺界面說明。

第6步：找架構師溝通算法和技術邏輯，根據架構師提出的疑問完善業務邏輯。

第7步：找測試經理溝通測試用例，根據測試經理提出的疑問完善功能細節。因為測試經理需要寫測試用例，測試用例是以需求文檔為藍本，如果需求文檔不清楚必然會導致測試用例不完善，因此測試經理往往對產品設計師的幫助很大，甚至會比產品設計師更了解產品細節。

第8步：找UER做功能調研。UER將需求文檔轉化為調研文檔，然后通過產品體驗群、邀請客戶當面體驗等方式找出產品設計中的問題。然后UER反饋給產品經理，產品設計師合并優化成產品需求詳情文檔。有的公司UER調研也是由產品設計師承擔，但是專業性上有可能難以保障。

第9步：找產品經理、研發項目經理、運維確認需求文檔，并初步確定排期。

6、需求評審

如果之前編寫過程與每個角色都有了充分的溝通，需求評審就會變得很輕松愉快。否則，產品經理和產品設計師將會陷入無止境的辯論中，往往動輒就讓整個團隊消耗了幾個小時還無法形成結論。

因此，需求評審的關鍵就是產品設計師事先做好評審會的一切準備。提前準備好所有資料并提前發給團隊所有成員，并事先與所有角色都逐一確認過關鍵問題，而且得到了產品經理和研發項目經理的確認。在評審會上，先講總體，再講重要細節，再講次重要細節，并層層確認。

對于會議上爭議較大的問題點，5分鐘后還沒結論的馬上記錄下來，會后再單獨討論。如果問題點太多，就說明產品設計師還沒考慮清楚，那就盡早結束會議，重新修改后再召開評審。這種情況會嚴重影響產品團隊的聲譽，因為耽誤的是所有人的時間。為了減少這種風險，需求評審一定要提前1-2周召開，而不要等到開發前夕才進行評審。

3、交互設計

交互設計主要是將產品經理的功能設計，用原型圖和交互流程的形式展現出來，方便與用戶及團隊進行溝通。交互設計原型將產品經理提供的產品原型草圖具象化，減少了需求不確定性，保證產品功能可用性。

騰訊設計完整流程圖

1、交互設計需求分析

交互設計需求分析主要是要回答以下問題：

A）重點是給哪些角色看？

涉及交互稿的角色很多，幾乎每個角色都需要，但是只要有專業細致的交互稿，也就能滿足所有角色的需求了，無需針對每個人提供不同的交互稿版本。

產品經理：產品經理需要將交互稿截圖合并到需求文檔，提供給各個角色作為需求源。

視覺設計師：需要以交互設計稿為基礎，設計出每個界面的PSD文檔。

研發經理：需要通過交互設計稿，判斷需要調配哪些角色參與，大概需要多少時間。

架構師：需要通過交互設計稿，梳理出軟件架構設計，特別是功能流程設計與軟件架構和網絡架構設計緊密相關。

Web前端開發：需要通過交互設計稿，確認網頁界面是如何串聯起來的。這里不僅涉及功能流程設計，也包括交互細節。

APP客戶端開發：需要通過交互設計稿，確認APP軟件界面是如何串聯起來的。這里不僅涉及功能流程設計，也包括交互細節。

后臺開發：需要通過交互設計稿，確認采用哪種后臺調用方式，以及如何通過交互設計讓用戶在面對網絡延遲等情況時體驗更佳。

測試：需要通過交互設計稿，編寫功能測試用例，以及每個交互體驗細節的測試用例。

用戶研究：需要通過交互設計稿，訪談客戶，讓客戶更容易理解產品功能，從而獲得更有效的反饋。

B）用戶場景是什么？

確定是要做什么場景下的交互設計。具體包括用戶畫像、主要功能流程等。

C）采用什么樣的形式？

交互文檔大多都采用Axture進行設計，一般都采用線框稿的形式。

使用Axture創建交互設計文檔

D）要達到什么標準？

一般衡量交互水平的指標，是整個功能操作流程的流量轉化率。

以注冊登錄為例，可以通過抽樣監測從進入注冊到登錄完成每個步驟進行數據跟蹤，然后得出轉化率數據值，然后再跟競品或類似產品進行對比，不斷提升這個轉化率。

2、功能交互設計

功能交互設計主要是將軟件界面之間的跳轉關聯關系表達清楚。

3、交互細節設計

交互細節涉及點非常多，不同公司、不同類型的產品都會有自己不同的交互設計風格和細節處理方式。為了保證產品交互細節上的統一和規范，互聯網公司一般都會制定自己的交互設計規范，以便指導設計師完成交互設計。

騰訊網站產品交互設計規范V1.0

交互細節設計，一般涉及交互控件元素、交互文案、裝飾圖形等內容。每個看似很小的功能細節，都往往需要花費大量精力去做細。為了節省成本，在這樣的功能開發出來后，都最好對象化模塊化，其他場景只需調用這個模塊即可快速創建類似的功能。

網頁翻頁功能細節交互設計

產品上線后運維工作才剛開始，具體包括升級版本上線工作、服務監控、應用狀態統計、日常服務狀態巡檢、突發故障處理、服務日常變更調整、集群管理、服務性能評估優化、數據庫管理優化、隨著應用PV增減進行應用架構的伸縮、安全、運維開發等工作。

4、視覺設計

1、視覺設計需求分析

視覺設計需求分析主要是明確視覺設計需要達到的目的。以Logo設計為例，最常見的需求要點是兩個：明確表義、吸引視線。因此在設計過程中，通過把競品和不同設計方案可以放到一起，從而找到最優的設計方案。

百度輸入法Logo設計需求調研

2、視覺概念設計

視覺概念設計建立在視覺風格推導基礎上，用以描繪出產品視覺風格的基本方向。

該步驟需要確定產品風格，為后續確定設計元素、明度、色調、質感等設計細節奠定基礎。

3、主界面設計

主視覺設計師拿到交互稿后，針對主要功能界面設計風格定位稿。

百度影音播放器主界面

4、視覺細節設計

然后針對界面中的每個控件，都按照像素級標準進行繪制。

每個空間的分層素材都需要通過PSD文檔進行保留，色塊區域的顏色值需要標注，按鈕的每個狀態都需要單獨設計，每個控件的尺寸也需要明確標注。交互設計中的每個細節設計狀態，也都應該有對應的設計稿。

騰訊視頻播放器內容庫視覺細節設計

5、視覺設計規范

與交互設計類似，視覺設計涉及點也非常多。為了保證產品視覺細節上的統一和規范，互聯網公司一般都會制定自己的產品視覺設計規范，以便指導設計師完成視覺設計。

QQ音樂視覺設計規范

5、架構設計

架構設計是架構師對各個子系統關系的抽象模型，用于指導大型系統的開發和運維。

架構設計主要包括三項工作：系統架構設計、軟件架構設計、網絡架構設計三個部分。

系統架構設計一般都會采用MVC（Model-View-Controller）模型，將業務邏輯模型、軟件界面、控制器邏輯層進行分層處理，然后通過控制器邏輯層確保業務邏輯層和軟件界面層的同步。MVC模型的好處是在優化界面及用戶交互的同時，無需重新編寫業務邏輯。同時也有助于管理復雜的應用程序，可以在不依賴業務邏輯的情況下專注于視圖設計，不同開發人員可以同時開發界面、控制器邏輯和業務邏輯，同時也讓測試變得更加容易。

1、系統架構設計

如果整個系統研發是從零開始的，架構設計則需要從概況圖開始梳理，然后再補充各個模塊的架構圖。這部分一般由首席架構師牽頭，屬于整個產品技術架構的總綱。

支付寶平臺系統架構概況圖

一般而言，子系統名稱都會與產品概念保持一致。子系統不論是應用前臺還是后臺，通過公共服務層、業務邏輯層、基礎業務邏輯層關聯到一起。這種對象化的架構設計方法，會讓整個團隊使用同一種語言在溝通， 相互理解起來更容易，有利于提高協作效率 。

支付寶財會系統架構圖

2、軟件架構設計

軟件架構設計一般采用分層架構設計模型。

軟件首先分為兩個大層次：前端和后臺。前端應用負責提供與用戶交互的軟件，分成Web應用，PC客戶端應用、移動APP應用等場景；后臺負責實現所有業務相關的操作和服務，分成接口層、業務邏輯層、基礎邏輯層。

軟件架構設計時，需要主要做到以下幾點：支持模塊化、高內聚、低耦合、可伸縮性，同時也要防止過度設計。已上線軟件如果要新增某個功能，則需要針對該功能進行軟件架構設計，并最終形成軟件架構設計圖。

騰訊視頻郵件推薦功能軟件架構設計圖

然后針對這個軟件架構圖進行細化，先明確系統涉及的所有基礎邏輯層模塊（對象），以及該模塊的輸入和輸出項，并明確模塊內部的基本處理邏輯。這些模塊有的有可能已經存在，則無需再開發，單獨標注出來即可；還沒有開發的模塊，則可以交給軟件項目經理指派給工程師開發。

然后明確界面上可以直接調用的各個業務邏輯層模塊（對象）名稱，以及對應接口、屬性、方法。

對于還未開發的接口，如果涉及到數據調用，則需要梳理相關的數據結構，并確定算法。

上面介紹的只是最基礎的軟件架構設計流程，為了保證軟件的柔性可用，經常還會RPC服務組件（讓網絡分布式應用開發變得更容易）、消息中間件（將模塊之間的交互異步化）等方案。

3、網絡架構設計

A）運維架構

架構設計需要保證每個環節都能快速迭代配置，尤其是在服務器CPU、內存、存儲、帶寬幾個方面需要做到高可用性。

以新零售個性化推薦動態Feed為例，我們梳理下整個網絡結構設計的流程。首先需要根據業務數據分析網絡系統需求。一般Feed信息流前3頁訪問量往往占了90%以上，因此在做緩存設計的時候，我們完全可以在緩存數據中只保存每個用戶最近的100條數據，其他的需要用戶下拉再從數據庫中實時生成。

然后需要從技術上解決高并發和高性能的問題。因為Feed性能壓力主要集中在查詢請求量上，而且一條Feed數據經常是數百甚至上百萬人訪問，因此Feed很適合采用緩存系統。當訪問壓力不大時，采用單層緩存數據就可以了。如果日均訪問量達到了百萬人次而且峰值非常明顯，則最好采用雙層緩存機制以增加系統擴容的靈活性。當寫入Feed量很小但是訪問量暴增時，只需擴容L1層服務即可；寫入量暴增，則對L2層服務快速擴容。緩存擴容主要是提升QPS、帶寬瓶頸以及緩存數據庫性能。

如果希望降低研發成本，也可以考慮購買騰訊云個性化推薦服務，這些中間處理過程就全部交給云服務去處理，這樣可以集中力量解決業務層問題。

Feed中除了文本數據外，還會有大量圖片甚至視頻數據，此時可以采用該CDN做文件緩存。Local Cache+ 分布式緩 存，這是常見CDN緩存策略。此時比較經濟的選擇，是購買CDN云服務，發布Feed時，把這些圖片和視頻數據先Post到服務器，然后再同步到CDN云服務中去。

然后是數據庫的分布式架構。網絡架構師拿到軟件架構師的數據結構后，首先對Feed數據區分冷熱數據。Feed數據冷熱一般都非常明顯，可以按時間維度拆分做分表（例如每天Feed數據是獨立一張分表）進行冷熱數據分離，并對冷熱數據采用不同的存儲方案降低成本。Feed數據還有快速檢索的需求，因此需要通過建立索引提高檢索速度。

B）服務撥測系統

運維發布系統后，運維團隊的壓力才真正開始。隨著用戶量的不斷增加，穩定性、性能和監控成了剛需。每個客戶請求過來，都需要在后臺不同機器之間不停地調用并返回。只要有1個接口出現問題，就會導致整個系統出現性能下降、服務延時甚至崩潰。

此時，就需要有效的服務追蹤系統。對新零售企業而言，最經濟有效的辦法是采用騰訊云撥測系統。通過部署抽樣接口到云撥測系統，特別是在高峰時段進行監測，即可通過手機短信或郵件監控服務異常。

C）日志統計系統

日志統計系統建議直接采用騰訊云日志服務。

此外，還要考慮全鏈路壓測、服務器登錄安全性、運維權限分配、流量峰后降級預案、共享Docker集群資源等問題，確保系統可用性、安全性、單位成本。

6、創建版本計劃

當架構設計完成并評審后，研發項目經理開始對需求和架構進行切分，形成版本計劃。

版本主要作用是用來明確研發節奏，方便團隊協作，特別是方便測試和產品發布。

一般產品研發節奏都是按每周1個小版本，以便安排和協作。但是因為APP有發布周期和推廣成本的考慮，因此會每隔幾周發布一個大版本。

每個版本都包括若干需求點，因此自然就明確了測試范疇，這樣測試范圍就不會無限制蔓延，可以讓產品節奏非常明確，形成快速迭代和敏捷開發的研發風格。

版本落地到代碼管理層面上，關鍵就是代碼管理系統（一般都選用Git）中的Trunk版本。首先項目經理需要在Git中創建Trunk版本，并為每個研發人員創建分支版本。研發人員在分支版本中測試沒有問題的版本代碼，將由架構師或項目經理合并到Trunk版本中，這個版本經過編譯后進行功能和系統測試，沒問題后再同步到運維發布系統中發布。

7、開發階段

1、開發測試環境準備

主要是部署Web、APP開發測試環境，以及部署需求管理系統、代碼管理系統Git等。

QQ游戲大廳研發環境搭建計劃

2、開發設計文檔

開發工程師拿到架構師設計文檔后，就可以將自己負責的部分拆分出來，然后提前對這部分的開發細節進行補充和完善，形成開發設計文檔。開發設計文檔主要用來提高軟件開發效率，保證軟件質量，并有利于后續產品客服文檔的編寫，也非常有利于后續的研發迭代和代碼維護工作。

前端開發、APP客戶端開發、后臺開發完善的內容和細節各不相同，但是內容主要集中在開發環境、開發語言、使用框架、對象屬性方法、接口封裝、數據結構設計、界面開發、編譯發布等方面。

3、前端開發

前端開發工程師通過使用JavaScript來編寫和封裝具有良好性能的前端交互組件，并通過CSS+XHTML輸出Web操作界面。前端工程師經常不僅要考慮前端實現，很多時候也需要了解后臺研發，從而能不斷優化前端代碼分層架構，讓Web產品的穩定性和可用性不斷提升。

4、APP客戶端開發

App客戶端開發主要是指IOS、Android、微信小程序的開發。

IOS開發推薦使用Xcode，需要運行在Mac OS上；Android開發推薦使用Eclipse；微信小程序開發需要使用微信開發者工具。

5、后臺開發

后臺開發主要是指的服務器端的程序開發，包括Web后臺開發、組件開發兩類。兩者之間其實本質上一體的，web后臺可以看作是組件的前端。Web后臺解析了HTTP請求，然后通過層層轉發給了后面分布式系統的多個組件并調用服務。

因為互聯網公司的server一般都是Linux，因此還會涉及到Shell腳本編寫、Linux環境編程等內容，需要熟悉Linux/Unix下各種環境編程的API。

6、開發工程師自測

開發工程師可以一邊研發一邊自測，完成所負責功能模塊的開發后再進行完整功能模塊的自測。

開發自測和測試的重點不一樣，是為了減少不必要成本，而不是要替代測試工程師的工作。因為代碼是開發自己寫的，自測可以發現的問題，就完全沒必要讓測試工程師去發現。而且發現問題馬上就可以自己修改自己驗證，減少了溝通和返工成本。

8、測試階段

從需求詳情文檔經過評審，測試工作就開始了。

1、測試用例

測試經理組織測試工程師，根據需求詳情文檔撰寫測試用例。

測試用例是軟件測試質量穩定的保障，用于指導測試的實施、規劃測試數據、設計測試腳本、評估測試結果、分析缺陷標準等。測試用例一般都詳細記錄測試工程師應該有的操作信息，這樣可以幫助測試工程師參與測試。

測試用例文檔一般包括修訂記錄、測試用例、測試數據等內容。測試用例可以直接在項目管理系統TAPD中批量創建。TAPD可以快速編寫并管理測試用例，制定測試計劃并執行，然后利用Bug跟蹤管理進行問題跟蹤與解決。

TAPD平臺中的測試用例列表與詳情頁

有很多常見模塊可以歸納成測試用例庫，然后不斷優化完善，這樣可以減少重復設計測試用例。相當于把測試工作也組件化，減少低效溝通提高效率。例如注冊功能測試用例，每隔一段時間就更新一次，以后出現需要測試注冊功能的時候測試工程師即可按照此規范進行測試，而無需針對這個功能重復編寫測試用例。

注冊功能的測試用例規范（部分）

2、功能體驗測試

功能測試就是對產品功能進行驗證，根據功能測試用例逐項測試，檢查產品功能是否達到用戶要求。功能測試主要采用黑盒測試方法，把測試對象看作黑盒子，主要測試功能而不考慮軟件內部結構及代碼。一般從軟件產品的界面、架構出發，按照需求編寫出來的測試用例，輸入數據在預期結果和實際結果之間進行評測，進而提出更加使產品達到用戶使用的要求。

黑盒測試試圖發現以下類型的錯誤：功能錯誤或遺漏、界面錯誤、數據結構或外部數據庫訪問錯誤、性能錯誤、初始化和終止錯誤等。

這部分測試除了測試工程師需要參與外，產品、交互、視覺設計師也需要深度參與，因為很多隱性信息都很難在需求文檔中寫得無一遺漏，但是產品設計師一看就能看出很多的問題，而這些問題測試工程師卻難以判斷，因為他們經常不知道產品設計師怎么想的。

功能體驗測試最好是與研發同步。Web測試提供測試環境，產品設計團隊通過配置host即可訪問測試環境，隨時能看到開發進展情況。對客戶端的開發，則每天定時合并代碼到trunk并提供daily build版本，產品設計團隊及時下載體驗，并在下班前將體驗問題通過工作群告知研發人員，以便研發人員第2天及時改進。這樣可以及時糾偏，減少研發憋大招。這個地方看似很小的工作習慣改變，但是會產生天壤之別的結果。所謂敏捷開發，也體現在這些協作細節里。

3、性能測試

性能測試關注軟件完成特定功能的響應速度、穩定性和運維成本消耗。主要是為了優化系統容量、可擴展性、系統穩定性、資源利用率等指標。

性能測試一般采用壓力測試的方法，通過給系統加載一定負荷的業務壓力，讓系統持續運行一段時間（一般為7x24小時），檢測系統是否能穩定運行。

性能測試方案模板（大綱部分）

性能測試主要步驟如下：

A）羅列主要用戶場景及相應負載量

重點針對可能出現性能瓶頸的場景，逐項分解和預估負載量。

為了讓系統抗壓能力更大一些，一般都會多預估一定比例的負載量，以防出現意外情況。

B）識別穩定性的主要性能指標

然后根據每個場景的負載量，分解每個后臺服務、APP、web端所需關注的系統指標，比如響應時間、CPU、內存使用率等。

C）單元性能測試與改進

在準備好測試環境后，使用測試工具對每個接口按照合法輸入格式進行壓力測試，確保在目標負載量都不會導致出現問題。比較常用的壓力測試工具是Loadrunner。

如果系統出現響應延遲或崩潰的情況，則需要運維和研發快速迭代。然后再次測試，直到系統性能指標達標為止。

D）客戶端兼容性測試

Web界面的兼容性測試，可以直接用Chrome內置開發工具即可完成。

APP兼容性測試，最好借用第三方工具（例如Testin云測），提交APP后，Testin云測將會部署APP到數百款手機，然后自動輸出兼容性穩定性報告。也可以根據測試工程師提供的測試用例，針對每款手機批量進行功能和體驗測試。

E）整體系統測試與改進

當每個場景下的單元測試完成后，再針對整個系統進行完整的壓力測試。

同樣，如果出現響應延遲或崩潰的情況，則需要運維和研發快速迭代，找到出問題的后臺接口或前臺模塊進行優化，直到系統性能指標達標為止。

（4）數據初始化運營

數據初始化首先是數據庫工程師根據產品和運營人員的需求，對基礎數據進行完善和補充，以達到能用戶能正常使用的狀態。

比較麻煩的是以往舊系統的數據遷移，由于舊系統和現有系統的字段，類型，日期格式，數字格式等差異，需要抽絲剝繭一層層把數據注入到對應的數據表里，特別是表間關系需要繼續保留下來。

然后是運營人員通過運營后臺，手動修改部分有問題的數據。

（5）產品內部測試

測試工程師完成所有測試用例的測試工作，研發人員將所有必須完成的Bug修正修正完成，其他待修正bug完成轉需求后，就可以啟動產品內部測試了。

內部測試首先可以針對產品相關的所有員工，包括產品、研發、運營、市場、運維等各個角色。這個過程一方面是為了收集產品缺陷反饋，同時也是讓相關人員有參與產品改進的機會，讓大家能榮辱與共。同事對于產品的容忍度比用戶要高得多，就算產品做得很爛，他們都會堅持著把產品所有功能都用一遍，而真實用戶很可能看到一個不好的體驗點轉身就走。因此產品經理一定要高度重視同事反饋，同事發現每個的缺陷，都一定會導致大量用戶流失。

員工反饋的問題如果是之前沒有發現的缺陷，就需要盡快改進修正。如果對當前版本影響不大，就可以放到以后版本Bug轉需求，并記錄下反饋人信息和詳細溝通結論。

等員工完成內測后，產品經理可以將產品內部測試版發到核心用戶群里，以有獎測試的形式刺激大家提交缺陷。如果線上反饋不夠深入，可以由UER調研小組邀請用戶當面溝通交流，找到更深入的缺陷。這些問題匯總提交到Bug列表中，可以馬上修正的盡快修正，可以放下個版本的Bug轉需求。

9、發布上線階段

發布環境的搭建，包括預發布環境、生產環境、灰度發布環境的準備等工作。而正式上線的工作，則包括數據庫上線、程序文件上線等工作。

推薦騰訊云毫秒服務引擎，這是一個開源框架，適用于在廉價機器組成的集群上開發和運營分布式后臺服務。毫秒服務引擎集RPC、名字發現服務、負載均衡、業務監控、灰度發布、容量管理、日志管理、key-value存儲于一體，非常適合中小型互聯網公司部署發布分布式應用。

1、發布環境準備

預發布環境準備：預發布環境是跟生產環境配置一模一樣的系統，只是往往只有一個測試節點，但是它后面調用的是正式生產環境的資源（例如DB、Cache、隊列等）。

預發布環境主要是要在正式發布前，做一次完整回歸測試。測試人員可以通過地址參數、Cookie、請求頭參數、VPN等工具，接入預發布環境進行系統整體回歸測試。預發布環境下，最常見的Bug如下：生產環境代碼已更新到最新版本了，但是數據庫變更卻忘了操作生產數據庫。這個情況下，測試環境很可能都是正常的，但是預發布環境就可以很好的發現bug。

跟開發環境不同，預發布環境不允許開發人員直接接觸，以防因為開發人員提交代碼的瑕疵影響預發布環境里的系統。因為這是運維人員保障上線質量的最后一道屏障，運維標準也基本等同于生產環境。

正式生產環境準備：生產環境包括發布產品所需要的所有服務器資源，包括Web服務器、數據服務器、CDN服務等。

灰度發布環境準備：每個項目一般都會部署到多臺機器，所以一般會拿1-3臺服務器看看是否可用，如果失敗則只需要回滾這幾臺服務器，比較方便。灰度發布需要使用跳板機并進行域名綁定，這樣才能保證用戶訪問到的只有最新代碼的服務器。

2、數據庫上線

生成數據庫項目時，可以先從測試環境導出數據庫對象定義腳本，然后再將預先部署腳本、數據庫對象定義和后期部署腳本合并為一個生成腳本，再將該腳本拿到主數據庫服務器上生成數據庫。然后通過主數據庫備份到各臺從屬數據庫。

如果系統對讀取及時性要求非常高，則可在數據庫層之上架構Redis這樣的分布式緩存，其性能肯定遠高于從數據庫讀取數據。

3、程序文件編譯上線

組件部署：將C/C++或Java編寫的組件編譯，然后通過自動部署工具發布到所有Web服務器。

Web前端部署：一般先將靜態資源（例如圖片、JS代碼等）拆分出來，發布到CDN云服務。然后再通過GIT將合并測試通過的Trunk版本發布到正式生產環境，再通過灰度發布工具同步到所有Web服務器。

IOS APP發布：App Stores是iTunes Store的一部分，是iPhone、iPod Touch、iPad以及Mac唯一的正規下載渠道。企業用戶申請證書后，即可上傳并發布IOS應用。

Android APP發布：推薦騰訊應用寶發布安卓版本的手機應用。應用寶提供防盜版功能，可有效幫助用戶解決誤下載山寨應用的問題。支持點擊微信、QQ分享鏈接，即可打開下載界面。因為沒有唯一的安卓發布市場，因此建議主流安卓市場都能上線安卓的版本。

4、上線版本整體評估

上線評估階段需經過市場、產品、運營、開發、測試等對于上線做出整體評估后才能正式上線運營。這個過程一般是由產品經理先在全員群里提醒大家最后一次確認還有什么問題。

如果有任何問題，則需要在群里和相關人員評估是否要在當前版本解決，如果是則盡快解決以免影響版本發布計劃，如果不是則轉需求到后續版本。

如果每個人都沒有提出異議則發出上線版本發布告知郵件，進入正式發布流程。

5、灰度發布

Web前端灰度發布：對比較小的Web應用，在頁面javascript或服務器端實現分流即可。但對于大規模用戶的Web應用，采用分流發布引擎很有必要。

組件灰度發布

IOS APP灰度發布：常見做法是制作一個帶數字簽名的測試版，然后提供給測試用戶使用。

Android APP灰度發布：由于Android沒有統一的發布渠道，因此只需逐個替換發布渠道的安裝包即可。

10、優化階段

1、研發工作總結

產品上線后需要對產品研發過程做總結，不論是產品上的還是流程配合上的，為后續加強溝通協作、產品運營打好基礎。

產品流程也并不是一成不變的，不同的產品有不同的要求。對一些中小互聯網公司而言，采用完整研發流程必然成本高昂，因此如何裁剪成自己需要的研發流程，是這類公司面臨的關鍵問題。

2、上線后收集用戶反饋

對于產品做出優化，對于用戶常見的問題及反饋做出調整，這階段更多是產品與用戶的磨合，做到更好的用戶體驗。

為了更好的收集用戶反饋，需要在所有產品上都增加反饋入口，以便用戶提交反饋內容。用戶反饋的所有問題將出現在用戶反饋平臺中，以便產品和運營團隊跟進。

支付寶用戶反饋平臺

一般每天的反饋量都數以萬計，因此產品設計師每天都需要花費相當比例的時間去瀏覽，并將反饋建議轉化產品需求點加入需求池。

3、產品體驗可用性測試

可用性測試常見方法是邀請一批真實的典型客戶，針對典型場景使用產品，用戶研究員在一旁觀察、聆聽、記錄，從而發現產品中存在的可用性缺陷。

為什么需要可用性測試呢？這是因為產品運營團隊的員工往往潛意識里會認為用戶一定會怎樣操作，但是事實上用戶很大概率上都不會按照他們希望的進行操作，甚至會陷入茫然根本用不下去。而通過可用性測試，就可以找到問題點，通過優化體驗設計降低用戶使用門檻。

騰訊UER團隊用戶參與體驗調研流程

4、運維系統優化

產品上線后運維工作才剛開始，具體包括升級版本上線工作、服務監控、應用狀態統計、日常服務狀態巡檢、突發故障處理、服務日常變更調整、集群管理、服務性能評估優化、數據庫管理優化、隨著應用PV增減進行應用架構的伸縮、安全、運維開發等工作。