軟體交付的終態是提供一個穩定可預期的系統，可預期的系統要確保環境和軟體製品的一致性。而在軟體研發協作的過程中，無論是製品、環境，還是釋出過程，往往都是定義在程式碼裡的。軟體交付體現為釋出，而提升交付能力的目標，是要發的容易，發的頻繁，增量要多，每次發的時間要少。
以上圖為例，橫軸是時間，縱軸是每一次釋出的耗時。一個紅點表示一次失敗的釋出，一個綠點表示一次成功的釋出。圖中該應用的釋出成功率只有30%左右。在我們的實際工作中，很多問題都會導致釋出成功率特別地低。例如：
約定的時間沒有辦法交付，可能是因為在軟體的溝通和設計階段耗時過多，導致開發很晚開始，或者軟體質量特別差，缺陷特別多，導致花費大量的時間修復問題。隨著時間的推移，團隊花到維護上的時間越來越多，用於新功能開發的時間越來越少。同時為了發地更快，就會減少原來應該在進入維護階段前做掉的事情，讓維護的工作在後期堆得更多。 
隨著問題暴露得越來越晚，修復成本呈指數級上升，一旦問題留到客戶那裡，成本將會非常高的。舉個例子，有一年在法國出現過一個電信故障，因為電信軟體生產環境和開發環境是隔離的，一旦出現問題，意味著需要派工程師從中國飛過去，在現場進行問題調研，再給出相應的修復補丁。在這個過程中，電信裝置是沒有辦法正常工作的，電信裝置的停機將會帶來極高的成本。在商業角度，電信運營商會向裝置商提出賠償要求，如果一個小時不能恢復，可能就需要賠付好幾百萬歐元。在網際網路行業裡也是一樣，問題發現的越晚修復成本越高。修復成本分為兩類：我們把上線之後出現質量問題帶來的修復成本，稱為交付質量的成本，即交付出去之後由於缺陷導致的成本。另一方面，在交付的過程中產生的成本，也是越到後面越高，因為涉及到的研發團隊的角色、職能越多。所以，要提升釋出的成功率，我們需要保證待發布內容的質量。只有釋出內容的質量得到保證，才能做到發的容易，發的頻繁。
上圖把測試做了簡單的分類，下半部分偏技術實現導向，上半部分偏業務結果導向，右側面向整個產品來看質量，左側面向團隊功能實現層面看質量。1象限（左下角），包括單元測試和元件測試，都是偏技術實現的，而且是團隊內部要搞定的。功能測試、工作流、場景性的測試，包括使用者體驗測試和結對測試偏業務，但是也屬於團隊實現過程當中做的測試，所以放到2象限。3象限，在整個產品的角度是偏業務的，包括可用性探索測試、客戶結對測試和驗收測試。最後的4象限一方面偏技術實現，另一方面又是站在整個產品的完整性角度做的驗證，如壓測、效能測試、安全測試、資料遷移測試、擴充套件性測試、負荷測試等，要把這些測試都做好成本是特別高的。有了完整的測試分類，在整個軟體交付的生命週期裡如何來合理安排它們呢？需要質量保障體系來定義。
上圖是企業裡比較常見的質量保障體系。從需求評審和架構設計開始，這時需求的質量和架構的質量是非常重要的，如果這時候質量出現問題，後面所有的工作都需要返工。需求和架構明確下來後就進入編碼和開發環節，程式碼質量和安全質量就會成為核心關注點。接下來是編碼的測試驗證階段，包括測試質量，資料質量，穩定性質量等。當功能測試告一段落之後，效能和使用者體驗成為主要關注物件，直到釋出完成。釋出之後需要綜合線上使用者的反饋，產生一個非常全面的質量評估。往下一層是大量的實踐，比如自動化測試的實踐，穩定性測試的實踐，效能測試的實踐，安全測試的實踐等。再往下是整個基礎平臺和流程支撐，包括測試承載的環境和工具等。整個軟體交付週期中上下游所有的角色都應該參與在質量保障的工作中。質量是團隊所有人的事。有的團隊說要加強業務需求評審，之所以質量問題多，是前序業務輸入的需求問題多；有的團隊說要加強開發自測，之所以質量不好是因為開發自測的質量不好，事實上，這些觀點都是片面的，這些舉措往往不但於事無補，還可能造成團隊成員間的對立。解決質量問題的第一步是要有一個明確的標準，比如需求的質量標準，作為程式碼的質量標準，每個階段有相應的標準定義。另外，上游永遠要考慮能否很好地幫助下游把工作做好。比如如果在做架構設計的時候沒有考慮可測性，等到開始測試的時候就沒有辦法開展了。上游的人應該承擔更重大的角色，上游做好下游可以省很多事情。第三，要避免測試程式碼的“公地危機”。做測試自動化會產生相應的測試程式碼，可能會涉及到通用的一些部分，幾個團隊大家都要共用，這時如果沒有很好的維護，沒有一種程式碼集體所有制，沒有建立好標準化，測試程式碼就會變成“公地危機”。
要做到持續的交付，一定要有持續的測試保證達到待發布狀態。要做到這一點，以微服務為例。
上圖是比較典型的微服務應用的例子，如果要給它做相應的質量保障，提供相應的測試來守護它，整體的測試策略如下：
紅色虛線部分是單元測試的時候就可以保證質量的，將測試限定在被測試系統的某一部分，比如只測Service那一層某一個介面或是函式，或者是domain裡面的某一個方法。在這個基礎上，更大的範圍是元件層面的，元件之間能否互動，介面是否正確等。整個元件裡中，排除掉外部的依賴（如資料依賴和網路的訊息依賴），更多的是跟閘道器之間的介面測試。再往外，才是與外部應用的整合測試，應用與應用之間會有協議互動，彼此交付所遵循的協議和規範即為契約。基於契約的測試，我們稱之為契約測試。而再往外就是端到端的測試了，關注的就是不是一兩個應用，而是多個應用組合在一起的完整的系統。站在使用者的角度來說，交付的系統是否提供了一個正常的業務服務，只要關注端到端測試就可以了。而站在元件的開發的角度來說，我只負責Service layer這一層的修改，我只要把這一層用單元測試保護一下。因此，對於不同的角色，選擇的測試是不一樣的，而且不同的時間階段裡面選擇的測試也會不一樣。在這個過程當中，選擇什麼樣的測試主要考慮的是成本和收益的平衡。
如圖，縱軸表示成本，橫軸表示質量，紅色的曲線表示質量成本的曲線，成本的曲線會隨著質量的要求做相應的變化。
兩條斜的虛線，向上的這條是指不做測試，認為質量投入會有成本，不投入相應的手段保證質量。這條虛線一開始的成本為0，因為完全不做跟質量相關的事情。但是隨著後面缺陷越來越多，故障越來越多，管理質量的成本就不會不得不越來越高，呈指數級上升。另一條往下的虛線，認為質量就應該做到極致，一開始就投入了非常多的成本，到質量變好的時候，投入將會快速地下降。我們給質量的成本做了個簡單的分類：
一個是低質量的成本，包括內部缺陷成本，研發過程當中由於缺陷帶來的種種制約。另外也包括外部缺陷成本，缺陷留給客戶，可能會產生的業務上的損失。如果覺得這個缺陷成本很低，在質量這一方面就可以不用投入。另一個是高質量的成本，包括預防的成本和驗證的成本，驗證成本也被叫做“評估成本”，用來評估質量好與不好。比如，如何知道這個製品的質量好還是不好？需要定義相應的一些驗收的用例驗證，然後執行它，看是符合預期還是有一些意想不到的問題。選擇哪些測試在哪個階段執行，是取決於這些成本考慮的。有些測試，要投入很多測試機器，要僱很多人寫測試用例，執行和分析很多測試自動化的指令碼，有一些測試成本特別高，買一臺測試裝置需要幾十上百萬，如果在產品的早期就進行這樣的投入，往往是不經濟的。從這個角度來說選擇什麼樣的測試策略，其實是從經濟學的角度來考慮，測試是非常高成本的事情。一方面，要提升應用的釋出成功率，需要建立在全面的質量守護體系的基礎上。研發團隊的上下游各個角色都需要參與到質量守護的活動中，併為之負責，特別是上游要更多地為下游考慮質量問題，共同提升質量水平，避免測試的公地危機。另一方面，質量是有成本的，守護質量也是有成本的，我們對質量的投入要平衡成本與收益，既要避免質量問題帶來的過高管理成本，也要避免對質量保障的過度投入。簡而言之，質量問題首先是一個經濟問題，然後是管理問題，最後才是工程技術問題。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024924/viewspace-2929047/，如需轉載，請註明出處，否則將追究法律責任。