今天回到我們的主題，繼續(xù)技術(shù)管理工作的第三篇文章，主要講講軟件研發(fā)流程。

說(shuō)到軟件研發(fā)流程，一些同學(xué)可能看不起這種標(biāo)準(zhǔn)化流程，會(huì)覺(jué)得不管三七二十一，立即上手編碼才是王道，需求可以等到后面再明確，設(shè)計(jì)則是完全不需要的步驟，否則感覺(jué)速度太慢，他們管這叫互聯(lián)網(wǎng)軟件開(kāi)發(fā)精神。什么是互聯(lián)網(wǎng)軟件開(kāi)發(fā)精神？開(kāi)源共享、模塊化編程、極客精神，而不是野蠻開(kāi)發(fā)。

我在讀《聊聊架構(gòu)》這本書時(shí)寫過(guò)一篇讀后感，感嘆終于出了一本可以讓我看很久的架構(gòu)書，而不是 1、2 小時(shí)就能看完的所謂 ** 牛逼架構(gòu)寶典。我們經(jīng)常遇到這樣的面試者，你請(qǐng)他畫總體架構(gòu)圖，他估計(jì)連聽(tīng)都沒(méi)聽(tīng)過(guò)，你換一個(gè)提問(wèn)的方式，問(wèn)他采用了哪些框架，他立馬和你說(shuō) SSH、Spark、Mesos，一大堆，但當(dāng)你讓他畫出架構(gòu)圖時(shí)，他會(huì)很茫然。當(dāng)然，你更不用期望他思考諸如為什么 Hadoop 的 MapReduce 并行計(jì)算模型會(huì)采用 Pull（拉）模式介于 Map 和 Reduce 之間，而不是采用 Push（推）模式？為什么會(huì)有 Spark 出現(xiàn)等等此類問(wèn)題了。這些問(wèn)題我會(huì)在后續(xù)文章討論，這里只是想說(shuō)，其實(shí)這些框架的產(chǎn)生，都是源于研發(fā)流程中的架構(gòu)設(shè)計(jì)環(huán)節(jié)發(fā)現(xiàn)了問(wèn)題，并逐漸積累的解決方案。

以基線產(chǎn)品開(kāi)發(fā)過(guò)程為例

一般情況下，企業(yè)開(kāi)發(fā)軟件時(shí)會(huì)按照基線和定制兩塊并行方式執(zhí)行項(xiàng)目開(kāi)發(fā)工作。無(wú)論什么公司，都需要遵從一套成熟的產(chǎn)品研發(fā)過(guò)程體系，才能做出質(zhì)量較好的產(chǎn)品。因此，如果出現(xiàn)項(xiàng)目較多的情況，應(yīng)該合理地安排基線和定制之前的里程碑，讓基線產(chǎn)品能夠盡量多地收集用戶的通用型需求，為定制項(xiàng)目進(jìn)度實(shí)現(xiàn)技術(shù)支撐，減少定制項(xiàng)目中大量更改代碼、需要新增模塊情況發(fā)生。此外，產(chǎn)品研發(fā)過(guò)程體系也需要按照業(yè)務(wù)實(shí)際時(shí)間要求變化，不要拘泥于一定要按照瀑布方式，或是敏捷方式進(jìn)行管理，凡事都需要找到契合自己的方式。鞋合不合腳，只有腳知道。

我們這里以一個(gè)基線產(chǎn)品開(kāi)發(fā)過(guò)程作為流程解釋基礎(chǔ)，需要注意的是，以下說(shuō)描述的各個(gè)階段，在項(xiàng)目執(zhí)行前要明確各個(gè)階段的目標(biāo)、指定計(jì)劃、及時(shí)溝通，并確保各個(gè)時(shí)期所有成員對(duì)項(xiàng)目理解一致。

項(xiàng)目啟動(dòng)會(huì)

項(xiàng)目啟動(dòng)會(huì)的目標(biāo)是明確該產(chǎn)品開(kāi)發(fā)項(xiàng)目的目標(biāo)。目標(biāo)不是孤立存在的，目標(biāo)與計(jì)劃相輔相成，目標(biāo)指導(dǎo)計(jì)劃，計(jì)劃的有效性影響著目標(biāo)的達(dá)成。所以在執(zhí)行目標(biāo)的時(shí)候，考慮清楚自己的行動(dòng)計(jì)劃，怎么做才能更有效地完成目標(biāo)，是每個(gè)人都要詳情清楚的問(wèn)題，否則，目標(biāo)越是不清晰或是過(guò)高，都會(huì)影響項(xiàng)目的實(shí)際結(jié)果。

項(xiàng)目啟動(dòng)會(huì)需要說(shuō)明項(xiàng)目目標(biāo)、階段劃分、組織結(jié)構(gòu)、管理流程等關(guān)鍵事項(xiàng)，并將這些內(nèi)容寫入 PPT（最好是有固定格式和范文，讓團(tuán)隊(duì)內(nèi)部或者公司內(nèi)部共同遵守規(guī)范），需要大家達(dá)成一致。對(duì)于關(guān)鍵角色任命，事前也需要聽(tīng)取相關(guān)領(lǐng)導(dǎo)和項(xiàng)目主要干系人的意見(jiàn)。

用戶需求

軟件開(kāi)始開(kāi)發(fā)前需要確定代價(jià)和所獲得價(jià)值的對(duì)比，也就是 ROI（Return On investment），一旦確定需要?jiǎng)?chuàng)建，就需要安排一系列的資源來(lái)支撐這個(gè)軟件的生存。這是需求的最原始描述。

為什么既要有用戶需求，也要有產(chǎn)品需求？因?yàn)閮烧呤怯胁町惖?，用戶需求由用戶提出，?duì)技術(shù)一般不描述，只描述產(chǎn)品目標(biāo)。產(chǎn)品需求是根據(jù)用戶需求轉(zhuǎn)化而來(lái)的技術(shù)實(shí)現(xiàn)需求，需要針對(duì)用戶提出的產(chǎn)品目標(biāo)進(jìn)行細(xì)分，總結(jié)出具體的每一個(gè)功能點(diǎn)，再針對(duì)每一個(gè)功能點(diǎn)細(xì)分為各種不同的操作流程，對(duì)每一個(gè)操作流程進(jìn)行技術(shù)化定義。

用戶需求和產(chǎn)品需求容易發(fā)生不一樣，這是因?yàn)殡m然大家都在談需求，但是出發(fā)點(diǎn)可能不同，造成了雙方關(guān)注點(diǎn)和思維方式不同。用戶需求關(guān)注的是系統(tǒng)如何支持業(yè)務(wù)流程，背后的需求是“實(shí)現(xiàn)業(yè)務(wù)目標(biāo)”。技術(shù)人員關(guān)注的是合理技術(shù)方案，背后的需求是“工作量”、“實(shí)現(xiàn)難度”和“系統(tǒng)性能”。

產(chǎn)品需求

我們需要弄清楚產(chǎn)品經(jīng)理或項(xiàng)目需求提出者為什么要做這個(gè)項(xiàng)目？這是最本質(zhì)的業(yè)務(wù)需求。需求分析確定的業(yè)務(wù)需求，都是從業(yè)務(wù)需求推導(dǎo)出來(lái)的，都必須為業(yè)務(wù)需求服務(wù)。

產(chǎn)品需求一般包括產(chǎn)品需求規(guī)格說(shuō)明書和產(chǎn)品需求矩陣。產(chǎn)品需求矩陣一般按照子系統(tǒng)、功能集、執(zhí)行單元的結(jié)構(gòu)列出所有的功能需求，每列則對(duì)應(yīng)每項(xiàng)功能的工作步驟以及每個(gè)步驟的工作量。

產(chǎn)品需求寫完后，需要進(jìn)行評(píng)審。在需求評(píng)審會(huì)上，產(chǎn)品、技術(shù)詳細(xì)評(píng)審需求是否完整，產(chǎn)品功能的正常場(chǎng)景是什么？是否形成閉環(huán)？異常場(chǎng)景是什么？是否考慮周全？

需求評(píng)審后，開(kāi)發(fā)和測(cè)試負(fù)責(zé)人，分別編寫技術(shù)方案和測(cè)試用例。技術(shù)方案評(píng)審，開(kāi)發(fā)負(fù)責(zé)人拉上涉及到其他系統(tǒng)的負(fù)責(zé)人一起討論，技術(shù)方案中必須要有業(yè)務(wù)流程圖和時(shí)序圖，業(yè)務(wù)流程圖是為了梳理開(kāi)發(fā)對(duì)業(yè)務(wù)的理解，是否和需求一致。時(shí)序圖是了梳理本次需求涉及的系統(tǒng)交互。技術(shù)方案評(píng)審?fù)ㄟ^(guò)后，確認(rèn)工作量和交付時(shí)間，反饋給產(chǎn)品。

總體設(shè)計(jì)

設(shè)計(jì)階段的目標(biāo)主要是對(duì)待開(kāi)發(fā)系統(tǒng)的構(gòu)架進(jìn)行分析和設(shè)計(jì)，并建立系統(tǒng)構(gòu)架的基線，以便為之后的實(shí)施工作提供一個(gè)穩(wěn)定的基礎(chǔ)。

設(shè)計(jì)階段包括了系統(tǒng)架構(gòu)的輸出，一個(gè)好的系統(tǒng)架構(gòu)設(shè)計(jì)可以幫助人類梳理業(yè)務(wù)邏輯且抓住核心需求，設(shè)計(jì)穩(wěn)定可擴(kuò)展的業(yè)務(wù)系統(tǒng)，評(píng)估業(yè)務(wù)開(kāi)發(fā)周期和開(kāi)發(fā)成本，有效的規(guī)避風(fēng)險(xiǎn)。例如蓋房子的時(shí)候得有建筑圖紙，有了圖紙，才能核算施工周期。

總體設(shè)計(jì)是整個(gè)系統(tǒng)的框架型設(shè)計(jì)，意義及其重大，一般情況下不能省略（只有維護(hù)項(xiàng)目可以省略總體設(shè)計(jì)，因?yàn)榛鶞?zhǔn)項(xiàng)目已經(jīng)設(shè)計(jì)完畢），所有的產(chǎn)品開(kāi)發(fā)項(xiàng)目均需要首先進(jìn)行總體設(shè)計(jì)，它是設(shè)計(jì)首要步驟，決不允許本末倒置，不能出現(xiàn)先編碼后設(shè)計(jì)的情況，這是軟件開(kāi)發(fā)的第二大痛點(diǎn)（第一大是需求不明確、任意變更需求）。

總體設(shè)計(jì)分為三個(gè)階段：

第一階段：初始設(shè)計(jì)。在對(duì)給定的數(shù)據(jù)流圖進(jìn)行復(fù)審和精化的基礎(chǔ)上，將其轉(zhuǎn)化為初始的模塊結(jié)構(gòu)圖。

第二階段：精化設(shè)計(jì)。依據(jù)模塊“高內(nèi)聚低耦合”的原則，精化初始的模塊結(jié)構(gòu)圖，并設(shè)計(jì)其中的全局?jǐn)?shù)據(jù)結(jié)構(gòu)和每一模塊的接口。

第三階段：設(shè)計(jì)復(fù)審階段，對(duì)前兩個(gè)階段得到的高層軟件結(jié)構(gòu)進(jìn)行復(fù)審，必要時(shí)還可能需要對(duì)軟件結(jié)構(gòu)做一些精化工作。

概要設(shè)計(jì)

概要設(shè)計(jì)的目的是描述系統(tǒng)的每個(gè)模塊的內(nèi)部設(shè)計(jì)，對(duì)總體設(shè)計(jì)和詳細(xì)設(shè)計(jì)承擔(dān)承上啟下的作用。

概要設(shè)計(jì)按照結(jié)構(gòu)化設(shè)計(jì)方法進(jìn)行設(shè)計(jì)。結(jié)構(gòu)化設(shè)計(jì)方法的基本思路是：按照問(wèn)題域，將軟件逐級(jí)細(xì)化，分解為不必再分解的的模塊，每個(gè)模塊完成一定的功能，為一個(gè)或多個(gè)父模塊服務(wù)（即接受調(diào)用），也接受一個(gè)或多個(gè)子模塊的服務(wù)（即調(diào)用子模塊）。模塊的概念，和編程語(yǔ)言中的子程序或函數(shù)是對(duì)應(yīng)的。

概要設(shè)計(jì)階段把軟件按照一定的原則分解為模塊層次，賦予每個(gè)模塊一定的任務(wù)，并確定模塊間調(diào)用關(guān)系和接口。

在這個(gè)階段，設(shè)計(jì)者會(huì)大致考慮并照顧模塊的內(nèi)部實(shí)現(xiàn)，但不過(guò)多糾纏于此。主要集中于劃分模塊、分配任務(wù)、定義調(diào)用關(guān)系。模塊間的接口與傳參在這個(gè)階段要制定得十分細(xì)致明確，需要編寫嚴(yán)謹(jǐn)?shù)臄?shù)據(jù)字典，避免后續(xù)設(shè)計(jì)產(chǎn)生不解或誤解。概要設(shè)計(jì)一般不是一次就能做到位，而是反復(fù)地進(jìn)行結(jié)構(gòu)調(diào)整。典型的調(diào)整是合并功能重復(fù)的模塊，或者進(jìn)一步分解出可以復(fù)用的模塊。在概要設(shè)計(jì)階段，應(yīng)最大限度地提取可以重用的模塊，建立合理的結(jié)構(gòu)體系，節(jié)省后續(xù)環(huán)節(jié)的工作量。

概要設(shè)計(jì)文檔最重要的部分是分層數(shù)據(jù)流圖、結(jié)構(gòu)圖、數(shù)據(jù)字典以及相應(yīng)的文字說(shuō)明等。以概要設(shè)計(jì)文檔為依據(jù)，各個(gè)模塊的詳細(xì)設(shè)計(jì)就可以并行展開(kāi)了。

詳細(xì)設(shè)計(jì)

詳細(xì)設(shè)計(jì)階段就是依據(jù)概要設(shè)計(jì)階段的分解，設(shè)計(jì)每個(gè)模塊內(nèi)的算法、流程，為每個(gè)模塊完成的功能進(jìn)行具體的描述，要把功能描述轉(zhuǎn)變?yōu)榫_的、結(jié)構(gòu)化的過(guò)程描述。

詳細(xì)設(shè)計(jì)這個(gè)階段，各個(gè)模塊可以分給不同的人去并行設(shè)計(jì)。設(shè)計(jì)者的工作對(duì)象是一個(gè)模塊，根據(jù)概要設(shè)計(jì)賦予的局部任務(wù)和對(duì)外接口，設(shè)計(jì)并表達(dá)出模塊的算法、流程、狀態(tài)轉(zhuǎn)換等內(nèi)容。這里要注意，如果發(fā)現(xiàn)有結(jié)構(gòu)調(diào)整（如分解出子模塊等）的必要，必須返回到概要設(shè)計(jì)階段，將調(diào)整反應(yīng)到概要設(shè)計(jì)文檔中，而不 能就地解決，不打招呼。詳細(xì)設(shè)計(jì)文檔最重要的部分是模塊的流程圖、狀態(tài)圖、局部變量及相應(yīng)的文字說(shuō)明等。一個(gè)模塊對(duì)應(yīng)一篇詳細(xì)設(shè)計(jì)文檔。

概要設(shè)計(jì)階段通常得到軟件結(jié)構(gòu)圖，詳細(xì)設(shè)計(jì)階段常用的描述方式有：流程圖、N-S 圖、PAD 圖、偽代碼等。而詳細(xì)設(shè)計(jì)的目的是描述某一個(gè)模塊內(nèi)部的處理流程、開(kāi)發(fā)方法和編碼技巧。一般來(lái)說(shuō)，詳細(xì)設(shè)計(jì)由項(xiàng)目簡(jiǎn)介、模塊說(shuō)明（具體說(shuō)明每一個(gè)模塊內(nèi)部的流程、功能、邏輯、消耗以及未解決問(wèn)題）、接口設(shè)計(jì)（包括內(nèi)部接口和外部接口）、數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)（包括物理結(jié)構(gòu)和邏輯結(jié)構(gòu)）、特殊處理等幾個(gè)部分構(gòu)成。軟件的詳細(xì)設(shè)計(jì)，最終是將軟件系統(tǒng)的各個(gè)部分的具體設(shè)計(jì)方法、邏輯、功能采用文字方式進(jìn)行表述。這樣在實(shí)現(xiàn)過(guò)程中，編碼人員原則上嚴(yán)格按此進(jìn)行代碼實(shí)現(xiàn)即可。

編寫代碼

編寫代碼可以遵循以下幾點(diǎn)原則：

先做核心模塊的壓測(cè)：很多程序員，習(xí)慣把東西做完，然后等著快上線的時(shí)候才做性能測(cè)試，那么如果前面設(shè)計(jì)出了問(wèn)題，這個(gè)就很頭大了。當(dāng)然，后期快上線的時(shí)候也要做性能測(cè)試，但前期的我認(rèn)為還是很重要的。當(dāng)然，做好這一點(diǎn)，需要懂一些業(yè)務(wù)，你要知道業(yè)務(wù)壓力在哪里，業(yè)務(wù)請(qǐng)求的重心在哪里，很多時(shí)候，產(chǎn)品經(jīng)理不講，你也要問(wèn)清楚。

確保過(guò)程可控：代碼執(zhí)行時(shí)一定要保持中間的輸出，比如說(shuō)，每處理 10 萬(wàn)條日志，寫一條狀態(tài)日志，記錄處理的日志條目數(shù)和當(dāng)前的執(zhí)行時(shí)間。

多打日志：很多時(shí)候，代碼寫的自己也不是很滿意，比如某個(gè)處理效率不夠優(yōu)化，某個(gè)處理的方法不夠簡(jiǎn)潔，或者擴(kuò)展性比較差，代碼寫的很弱智，但可能短時(shí)間沒(méi)有辦法想清楚最合理的解決方案，考慮到上線初期這里并不是重心所在，所以也不會(huì)特意去優(yōu)化它，但這種情況下我往往會(huì)留下注釋，并說(shuō)明下一步優(yōu)化的可能思路是什么，或者想到的可行方案是什么。

簡(jiǎn)單易懂的邏輯：千萬(wàn)不要把自己繞進(jìn)去了，時(shí)間一長(zhǎng)，誰(shuí)都看不明白你的邏輯。如果邏輯真的很難在一個(gè)函數(shù)內(nèi)完成，嘗試切分。

不要沉迷于框架：框架最大的問(wèn)題是什么？是過(guò)于繁冗的嵌套。為什么我一直很煩框架？因?yàn)榻?jīng)常遇到需要一秒鐘幾千次請(qǐng)求的處理場(chǎng)景，那么調(diào)優(yōu)的時(shí)候，要從數(shù)不清的框架中尋找數(shù)據(jù)處理的邏輯，尋找性能卡點(diǎn)，可能改動(dòng)代碼只有兩行，但是找問(wèn)題需要兩天。程序員記住，你的技術(shù)能力絕對(duì)不能被框架約束住。

使用熟悉、成熟的技術(shù)：很多人根本沒(méi)搞明白自己的障礙和問(wèn)題在哪里，根本不知道相關(guān)技術(shù)產(chǎn)品的優(yōu)勢(shì)和劣勢(shì)在哪里，看一堆第三方的數(shù)據(jù)測(cè)評(píng)，腦子一熱，去學(xué)新技術(shù)，然后，掉進(jìn)坑里出不來(lái)，如果是創(chuàng)業(yè)公司，可能項(xiàng)目就死在里面了。使用新技術(shù)前，建議全面了解該技術(shù)的特征，適用范圍，以及不適用的范圍。

代碼審核

眾所周知，在團(tuán)隊(duì)中進(jìn)行代碼審查（Code Review）可以提升代碼質(zhì)量，分享項(xiàng)目知識(shí)、明確責(zé)任，最終達(dá)到構(gòu)建更好的軟件、更好的團(tuán)隊(duì)。

代碼審核及其重要，一般來(lái)說(shuō)每周都要做一次代碼審核。首先，代碼審核有利于你跟蹤項(xiàng)目進(jìn)展情況，我們能真實(shí)地看到手下的人進(jìn)展如何，并且更早發(fā)現(xiàn)他們是否誤入歧途。有時(shí)候，手下人會(huì)說(shuō)“完成得差不多了！”，你去看代碼時(shí)發(fā)現(xiàn)什么都沒(méi)有或者只是一堆垃圾，諸如此類，總之離完成還很遙遠(yuǎn)。在管理中，這種情況是最讓人討厭的，所以我認(rèn)為代碼審查是避免這種麻煩的最佳途徑。

單元測(cè)試

要認(rèn)識(shí)單元測(cè)試，首先要明白什么是“單元（Unit）”。所謂“單元”指的是代碼調(diào)用的最小單位，實(shí)際上指的是一個(gè)功能塊（Function）或者方法（Method）。所以單元測(cè)試指的就是對(duì)這些代碼調(diào)用單元的測(cè)試。

單元測(cè)試是一種白盒測(cè)試，就是必須要對(duì)單元的代碼細(xì)節(jié)很清楚才能做的測(cè)試。所以，單元測(cè)試的編寫和執(zhí)行都是由軟件工程師來(lái)做的。相對(duì)于單元測(cè)試，還有集成測(cè)試。集成測(cè)試基本都是黑盒測(cè)試，主要是由測(cè)試人員根據(jù)軟件的功能手冊(cè)來(lái)進(jìn)行測(cè)試，需要有專門的測(cè)試環(huán)境配合。集成測(cè)試又分功能測(cè)試、回歸測(cè)試等。

需要單元測(cè)試的代碼實(shí)際上是開(kāi)發(fā)人員自己寫的邏輯，測(cè)試邏輯所依賴的環(huán)境是否正常不是單元測(cè)試的目的。在環(huán)境訪問(wèn)代碼中引入邏輯，只會(huì)讓邏輯更難測(cè)試，導(dǎo)致邏輯代碼無(wú)法進(jìn)行單元測(cè)試。因此，可單元測(cè)試的代碼，才能夠采用單元測(cè)試。判斷可測(cè)試的代碼還有一個(gè)方法，就是看這個(gè)方法能否用一個(gè) main 函數(shù)直接運(yùn)行，如果可以的話就是可單元測(cè)試的代碼。可測(cè)試的代碼還有另一個(gè)特征，就是該方法單元的參數(shù)，開(kāi)發(fā)人員可以自由模擬，不需要依賴外部環(huán)境。

集成測(cè)試

集成測(cè)試，也叫組裝測(cè)試或聯(lián)合測(cè)試。在單元測(cè)試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測(cè)試。實(shí)踐表明，一些模塊雖然能夠單獨(dú)地工作，但并不能保證連接起來(lái)也能正常的工作。一些局部反映不出來(lái)的問(wèn)題，在全局上很可能暴露出來(lái)。

集成測(cè)試是在軟件系統(tǒng)集成過(guò)程中所進(jìn)行的測(cè)試，其主要目的是檢查軟件單位之間的借口是否正確。它根據(jù)集成測(cè)試計(jì)劃 ，一邊將模塊或其他模塊組合成越來(lái)越大的系統(tǒng)，一邊運(yùn)行該系統(tǒng)，以分析所組成的系統(tǒng)是否正確，各個(gè)組成部分是否合拍。集成測(cè)試的策略主要有自頂向下和自底向上兩種。也可以理解為在軟件設(shè)計(jì)單元、功能模塊組裝、集成為系統(tǒng)時(shí)，對(duì)應(yīng)用系統(tǒng)的各個(gè)部件（軟件單元、功能模塊接口、鏈接等）進(jìn)行的聯(lián)合測(cè)試，以決定他們能否在一起共同工作，部件可以是代碼塊、獨(dú)立的應(yīng)用、網(wǎng)絡(luò)上的客戶端或服務(wù)器端程序。

系統(tǒng)測(cè)試

系統(tǒng)測(cè)試階段包括系統(tǒng)測(cè)試方案及用例編寫、功能性測(cè)試、性能測(cè)試、穩(wěn)定性測(cè)試。

為了驗(yàn)證需求分析確定的功能是否齊全并被正確實(shí)現(xiàn)，同時(shí)還要對(duì)安裝、部署、適應(yīng)性、安全性、界面等非功能性需求進(jìn)行測(cè)試。系統(tǒng)測(cè)試也有測(cè)試人員負(fù)責(zé)，應(yīng)該在需求分析完成后進(jìn)行設(shè)計(jì)，在集成測(cè)試完成后進(jìn)行實(shí)施。

功能性測(cè)試一般由獨(dú)立測(cè)試小組采用黑盒方式來(lái)測(cè)試，主要測(cè)試系統(tǒng)是否符合“需求規(guī)格說(shuō)明書”。在經(jīng)過(guò)以上各階段測(cè)試確認(rèn)之后，把系統(tǒng)完整地模擬客戶環(huán)境來(lái)進(jìn)行的測(cè)試。系統(tǒng)測(cè)試是將已經(jīng)確認(rèn)的軟件、計(jì)算機(jī)硬件、外設(shè)、網(wǎng)絡(luò)等其他元素結(jié)合在一起，進(jìn)行信息系統(tǒng)的各種組裝測(cè)試和確認(rèn)測(cè)試，其目的是通過(guò)與系統(tǒng)的需求相比較，發(fā)現(xiàn)所開(kāi)發(fā)的系統(tǒng)與用戶需求不符或矛盾的地方，從而提出更加完善的方案。

性能測(cè)試驗(yàn)證系統(tǒng)的穩(wěn)定性和效率，檢查系統(tǒng)是否滿足規(guī)定的性能要求。性能測(cè)試通常選擇一些典型的功能，檢驗(yàn)這些功能在大量用戶同時(shí)使用系統(tǒng)時(shí)系統(tǒng)是否穩(wěn)定。性能測(cè)試由測(cè)試人員負(fù)責(zé)，可以在系統(tǒng)測(cè)試完成后進(jìn)行，也可以對(duì)重要模塊先進(jìn)行性能測(cè)試，可以貫穿整個(gè)測(cè)試周期，目的是盡早發(fā)現(xiàn)系統(tǒng)的性能瓶頸并提早解決。

穩(wěn)定性測(cè)試和性能測(cè)試都必須等到系統(tǒng)基本沒(méi)問(wèn)題、趨于穩(wěn)定時(shí)再進(jìn)行才有效果，否則很難順利測(cè)下去，出現(xiàn)異常也不能定位究竟是系統(tǒng)架構(gòu)的問(wèn)題，還是功能上的缺陷。

穩(wěn)定性測(cè)試（亦可稱可靠性測(cè)試）通過(guò)給系統(tǒng)加載一定的業(yè)務(wù)壓力，讓系統(tǒng)持續(xù)運(yùn)行一段時(shí)間（一般為 7x24 小時(shí)），檢測(cè)系統(tǒng)是否能夠穩(wěn)定運(yùn)行。

產(chǎn)品發(fā)布

產(chǎn)品發(fā)布是系統(tǒng)測(cè)試結(jié)束后的最后一步，通常在軟件產(chǎn)品開(kāi)發(fā)過(guò)程中不需要產(chǎn)品試制環(huán)節(jié)，可以直接上線，只需要系統(tǒng)測(cè)試員輸出系統(tǒng)測(cè)試報(bào)告并批準(zhǔn)產(chǎn)品發(fā)布（上線）就可以了。

產(chǎn)品發(fā)布前需要通過(guò)產(chǎn)品發(fā)布說(shuō)明會(huì)形式，對(duì)整個(gè)產(chǎn)品開(kāi)發(fā)過(guò)程從立項(xiàng)開(kāi)始回溯過(guò)程，指出整個(gè)過(guò)程中的不足點(diǎn)，總結(jié)經(jīng)驗(yàn)，為下一個(gè)項(xiàng)目提供經(jīng)驗(yàn)案例。這一會(huì)議可以通過(guò)正式會(huì)議形式召開(kāi)，需要召集產(chǎn)品經(jīng)理、主要開(kāi)發(fā)人員、測(cè)試人員、上級(jí)領(lǐng)導(dǎo)等參與，準(zhǔn)備充分，盡最大可能說(shuō)清楚這個(gè)產(chǎn)品發(fā)布之后的效果、效益，為上線后的價(jià)值評(píng)估做準(zhǔn)備。這一環(huán)節(jié)不可缺少，即便在互聯(lián)網(wǎng)公司，迭代速度很快的情況下，這一環(huán)節(jié)也需要滿足。

開(kāi)發(fā)過(guò)程復(fù)盤

其實(shí)開(kāi)發(fā)過(guò)程體系里并沒(méi)有這一過(guò)程，但是我個(gè)人認(rèn)為它非常重要。

所有的總結(jié)，只有帶著問(wèn)題去思考才會(huì)有收獲，這就是復(fù)盤。不論我說(shuō)多少，如果沒(méi)有過(guò)類似的經(jīng)驗(yàn)，就很難有很強(qiáng)的共鳴。我覺(jué)得看清一個(gè)問(wèn)題最好的方式，就是你曾經(jīng)處在一個(gè)問(wèn)題的兩個(gè)不同的角色中。

總結(jié)項(xiàng)目經(jīng)驗(yàn)教訓(xùn)的目的，在于總結(jié)問(wèn)題、分析原因，避免以后犯同樣的錯(cuò)誤，而不是追究誰(shuí)的責(zé)任。

假設(shè)一個(gè)需求理解的缺陷，如果在需求階段發(fā)現(xiàn)，修改一下可能只要一個(gè)小時(shí)，但是如果到了設(shè)計(jì)完成時(shí)發(fā)現(xiàn)這個(gè)缺陷，因?yàn)樯婕暗娜藛T、文檔增多，估計(jì)要一天時(shí)間，而如果等到代碼都編寫完成時(shí)才發(fā)現(xiàn)這個(gè)缺陷，可能需要十天八天了。如果缺陷沒(méi)被發(fā)現(xiàn)，而是直接到了生產(chǎn)系統(tǒng)中呢？這就不是工作量的問(wèn)題了，估計(jì)損失就難以估計(jì)了。在質(zhì)量管理的理論中，缺陷每延遲一個(gè)階段被發(fā)現(xiàn)，修復(fù)的代價(jià)就要乘上十倍。

寫在最后

敏捷開(kāi)發(fā)、極限開(kāi)發(fā)等等模型是為了解決需求不明確、時(shí)間緊迫情況下的快速迭代，而不是為了從根本上否定研發(fā)流程，該設(shè)計(jì)還是要設(shè)計(jì)，只是將生命周期進(jìn)行切分，將過(guò)程橫向切分為若干個(gè)周期。軟件開(kāi)發(fā)是一門工程性要求很嚴(yán)謹(jǐn)?shù)膶W(xué)科，讓我們堅(jiān)持嚴(yán)謹(jǐn)?shù)膽B(tài)度、高效的工作方式，打造高可用、高質(zhì)量的軟件產(chǎn)品。