最近部門在推質量標準化，透過質量標準化，推動質量內建，從而提高研發部門的交付質量，我也深度參與其中，並在推進過程中總結了一些經驗以及思考，在此透過以下定義、共識、實踐三個大方向和大家分享一下。
一 定義
1 質量標準化
何為質量標準化？用個不太恰當的比喻，大家都知道工廠的流水線作業，每個位置上的人或者機器要做什麼都是提前規範好、定義好的，流水線上的商品從原材料到成品經過的都是同一套流程，因此成品間的質量不會相差太遠。研發流程和流水線作業有一定的相似性。我們希望透過標準化各條業務線的研發流程，以做的比較好的業務線作為標準樣板間，規範出一套標準化的流程，並適用到其它業務線，從而使各條業務線都能進行高質量的交付。
2 質量內建
不少研發團隊的同學都認為質量都是靠測試同學去守護的，會認為產品出現了質量問題，是測試的鍋，這是對測試工作和質量保障的一種狹隘的認識。測試同學是質量的守護神，可是質量不能只靠測試同學在最後一環去兜底。想要給使用者交付高質量的產品和體驗，必須是在研發流程各個環節都遵守質量規範，在需求評審、方案設計、開發、自測環節上的產品、開發、測試同學都要有質量意識並嚴格執行質量規範，這就是質量內建。
3 交付質量
交付質量包含系統質量和產品體驗兩部分。系統質量指的是系統的功能完備性、系統的穩定性和健壯性，產品體驗是指客戶使用此產品時是否有絲滑的體驗。
二 共識
要讓研發流程中的各個角色都願意去踐行一套統一的標準和規範，必不可少的條件是各個角色意識形態上的統一。只有團隊的思想一致了，標準和規範才能被推進並落實。在推動 ICBU 跨境資金-國際結算團隊標準化建設的過程中，我們團隊從上到下首先在以下觀點下達成了高度統一。
1 質量不只是測出來的
在知乎上看到針對“質量是被設計出來的，還是被測出來的”問題有一個討論，覺得寫的挺好的，從不同角度分析了這個命題，我把它摘抄出來，針對“質量之道”的本源之爭，大家的發言很踴躍，我摘抄了幾個具有代表性的：
A同學：我認為質量是設計出來的，在設計上考慮的各種非功能質量資料，都會落地到程式碼中。設計的最佳化會不斷的驅動系統質量的最佳化。
B同學：我認為質量是測試出來的，設計的東西可以避免已知的問題，但在實際測試的過程中，還是會發現其他未考慮到的問題，例如相容性問題，你能提前透過設計預防嗎？所以測試發現問題，問題驅動質量提升。
C同學：聽完B同學的發言，我更堅信了質量是設計出來的。在不斷的BUG驅動下，我們打補丁式做出來的系統，質量會更好嗎？打補丁解一時之急，而後續系統性的設計、重構、升級，才是提升質量的關鍵點。所以…
D同學：如果站到產品層面，我們會怎樣去定義產品好不好？在我們定義產品好壞的質量模型裡，很可能會包含軟體研發相關的非功能質量屬性(ISO9126)，可能會包括產品輿情、競品對比中挖掘出的東西。例如，我們去定義一款內容推薦產品的好壞，除了“內容不重複”、“多樣性”等維度外，“是否支援分享”、“是否支援點贊”也會成為質量好壞的評判標準，新功能上線、滿足需求，使用者就會認為產品好。我們的認知會不斷升級，“好”的標準也會有更高的要求。使用者無時無刻不在使用、測試、反饋，讓質量不斷變好。
2 既要、又要、還要、且要
上述的四位同學的觀點，代表了不同的質量理念和追求：
-
謀而後動的觀點：無論是對需求的二義性分析、對設計中UML圖的流程分析、時序分析、狀態分析，都是希望能夠磨刀不誤砍柴工、降低成本。A同學說得對。
-
探索式測試的觀點：無論是保證在設計變成程式碼的過程中是否100%的完成翻譯，還是在測試的過程中受到啟發認為應該寫下更多的邏輯程式碼，都是希望所見即所得，想人之未想。B同學說得也對。
-
技術債的觀點：無論是對前段時間的補丁程式碼進行重構，還是對系統進行架構的升級，還是對基建能力進行最佳化，都是希望能夠打好底盤，走的更遠，走得更穩。C同學靠譜。
-
持續改進的觀點：無論是做競品分析、輿情分析、線上主動檢測、監控、產品質量模型等事情，都希望能夠在已有認知和未有認知裡發現問題、發現不足。D同學思維廣。
既然大家都說得對，都代表了一種優秀的質量理念，那麼就不需要取捨了，既要、又要、還要、且要。
“質量既是設計出來的，也是測試出來的，還是被逼出來的”，但質量一定不只是測出來的，質量保障不只是測試一種角色的責任，是貫穿研發流程各個角色共同的責任。
3 缺陷發現的時間越早，成本越低
毫無疑問，缺陷被越早的發現，修復的成本就越低。在需求評審階段就發現需求上的不合理，在技術設計階段就發現技術方案的問題所在，在測試驗證階段發現系統的bug和產品bug，修復這些環節發現的問題的成本逐漸升高，但如果問題對客後才被發現，修復的成本將是巨大的，可能會影響客戶體驗和滿意度，或造成資損，甚至導致公司名譽受損。
4 測試策略本質上是在質量成本和質量風險之間取得平衡的一種方法
我們知道，程式的執行場景和場景中涉及的資料輸入都是無法窮舉的，因此測試是不能被窮舉的。所以我們需要進行測試方案的設計，透過運用黑盒測試用例設計的等價類、邊界值法等，白盒測試用例設計的條件覆蓋法、路徑覆蓋法等從無限的測試資料中選出有效的測試資料，在有限的測試時間內進行有效的測試。
5 開發自測是基本要求和基本素養
我們一直在強調開發自測，無論需求是否有測試接手，開發都必須要自覺地完成自測。作為一名合格的開發，本身就要對自己交付的程式碼有充分的質量保證，這應該是自上而下地在團隊裡需要貫徹的思想和共識。
三 實踐
ICBU 跨境資金-國際結算團隊是 ICBU 質量標準化實踐的樣板間，我們團隊在研發流程各個環節都有嚴格的質量規範。國際結算團隊承接的業務多且複雜，特別是涉及到資金的需求交付，我們都是非常謹慎的。在國際結算團隊，一個需求從提出到上線，對於測試接手類的重要需求需要經歷如下環節：
需求評審->資源投入評估->技術方案設計評審->開發&聯調&自測->測試方案評審 -> 功能預演->測試->釋出計劃評審-> 灰度-> 全量
需求評審->資源投入評估->技術方案設計評審->開發&聯調>自測-> 灰度-> 全量
下面將闡述這些環節的規範以及衡量每個環節做得好不好的指標。
1 需求階段
在需求階段我們常遇到的問題是，在專案開發過程中，才發現存在未評估到的需求點，如果要實現這些未評估到的需求點，可能會導致專案延期，也無疑會加重專案組成員的壓力。為了解決這個問題，我們提出了以下應對機制和規範：
-
專案開發過程中，發現存在未評估到的需求點，如果不影響到主流程，透過走變更的方式解決。
-
大型專案進入開發前，需要再評審一遍細的PRD，如果有UED 變更，需要先準備好設計稿再組織PRD評審；
2 資源投入評估
需求評審結束後，開發和測試同學需要評估投入的開發資源和測試資源，需求PM會拉通各方定下排期，主要包括聯調時間、提測時間和釋出上線時間，各個節點的時間一旦確定，PM和 TPM將會嚴格按照這個時間點來推進，一般是不允許延期交付的，除非有特殊原因，比如其它緊急需求臨時插入等。
在資源投入評估中，除了定下排期，測試還會評估該需求是開發自測還是測試介入，會有一套評估機制。在國際結算團隊，開發測試比是9:1，這意味著測試不可能接手每一個需求，對於一些評估出來沒有資金風險、不對客的頁面需求，會要求開發自測。
2. 確定聯調時間、提測時間、釋出上線時間，接下來PM和TPM 會嚴格按照這三個節點推進專案
3 系分階段
在進入開發前，必不可少的環節便是技術方案的設計和評審。技術方案評審我們要求團隊 master 以及架構師必須參加，並且有一套技術方案設計模板。此環節做得好的話，可以讓後面的環節走得事半功倍。
-
-
-
-
-
介面設計（包括提供給前端的介面和提供給業務上下游的介面）
-
-
-
-
-
-
-
如果技術方案裡沒有詳細地描述清楚上述方面的設計，在技術評審時會被打回，改完後再次組織下次的技術方案評審，通過後，才會進入開發。這種方式可以卡住那些在技術方案設計上就有問題的實現，避免到提測後才發現系統設計問題的不可控局面。
4 測分階段
毫無疑問，詳細的測試方案和測試用例評審一來可以讓測試同學對本次需求的改動和風險瞭然於胸，二來可以幫助開發梳理功能點和影響範圍，三來可以正式拉通三方（測試、開發、產品）對本次交付功能點的共識。為了達到這個三個目的，我們整理了測試方案設計的模板和規範，要求團隊內的測試同學：
1. 在接手超過2天的測試專案時必須要有測試方案和測試用例的評審環節
2. 要在開發技術方案評審後的五天內完成測試方案的評審
-
-
-
-
-
-
-
-
5 開發&聯調&自測階段
在比較大的專案裡，比如 xx專案，參與研發的開發同學多達13位，研發時長長達一個月，在長達一個月的研發時間裡，如果沒有在關鍵節點及時同步進展，專案的進度和質量很可能是不受控的。xx專案踩了這個坑，沒有在關鍵節點在專案組內同步每日的研發進度，導致問題（專案中中途有人被其他需求插入導致某模組沒能按時聯調，提測質量差；開發為新人，沒能按時提測等）集中在提測節點暴發。基於這個教訓，我們進行了覆盤，並定下後續在這個環節的規範，即：
1. 進入專案聯調環節後，需要發聯調日報（PM彙總發出），並每日晨會同步聯調進度。
責任人：PM
2.原則：聯調前需要先完成域內的自測；
責任人：開發
3.遇到卡點問題，由介面依賴方主動去push被依賴方解決，如果被依賴方沒有及時解決，並影響了進度，需要同步風險
責任人：上游開發
4.聯調階段，上游Mock聯調或者真實鏈路聯調發送訊息，跟對方開發確認訊息是否正確，增加確認過程；真實鏈路聯調和mock聯調介面不允許有差異。
責任人：下游開發
5. 由測試同學提供冒煙用例給到開發自測，開發必須把冒煙用例的所有場景走完才可以提測
責任人：開發執行、測試監督
6. 釋出前單測增量覆蓋率需達到60%，單測透過率 100%
責任人：開發執行、測試監督
7. 提前兩天後需完成組內CR
責任人：開發
在自測環節，測試會提前提供一份冒煙用例給到開發自測。
我們會要求開發必須把冒煙用例的所有場景走完才可以提測。目前冒煙用例是用語雀文件的形式提供給開發，這是一種線下的方式，不太利於回溯和標準化推廣，因此ICBU質量團隊在菲爾茲平臺上結合 aone 的用例管理提供了線上化的冒煙流程，後續會基於菲爾茲平臺提供線上化的冒煙用例及冒煙狀態管理。
6 功能預演階段
在沒有提出功能預演這個環節之前，常常會出現開發們提測的功能連頁面都打不開或者介面調不通的低質量問題，低質量的提測會導致測試非常被動。為了避免這種問題，我們在團隊裡提出了功能預演，即在提測前PM需要拉測試和開發一起對提測的版本進行一輪功能預演，保證主流程是可以走通的，這樣子可以快速地在提測前就把非常低階的問題快速解決，也讓測試同學能有更多的時間測試系統異常流，保證專案的交付質量。
如果功能預演沒有透過，提測將會被打回，問題解決後，開發需要再次組織功能預演，並順延發布時間，我們會在菲爾茲平臺上記錄提測被打回的原因以及延遲釋出的原因，並定期review 資料，對於多次延遲的現象進行復盤，商討改進方案。
以前很多團隊可能都提過提測不透過，那就打回，把問題解決後再提測，但是從來沒有提過因此需要順延的釋出時間，導致測試的壓力非常大，前面開發的鍋丟給了測試加班來兜底。更為嚴重的是，不少團隊認可測試兜底的邏輯。為了糾正這種思想，我們做了不少努力，針對延期的專案，專門組織了專案覆盤會議，定下了規範：
-
-
功能預演由測試主導，開發需要在場，如果主鏈路卡住，需要由開發給出下次預演的時間，並順延發布時間，周知專案組；
-
功能預演出現的問題，如果是bug問題，需要由開發本人去推動解決，如果是資料問題，則由測試去推動
-
7 測試階段
目前超過3天的測試時間的專案，測試同學會發每天發日報，透過日報來及時同步測試進展和風險，同時要求 bug 開發日結。日報模板：
-
12.30：開票流程最佳化功能預演，已完成（延期6.5個工作日）
-
1.8-1.12：預發回歸測試，進行中（延期2個工作日上預發，原計劃1.5日）
-
1.13：釋出（延期5個工作日，原因：開發人員被其他專案佔用資源，進入此專案時間晚）
-
專案延期：專案延期至2022.1.13釋出，延期5個工作日。 原因：① 開發人員被其他專案佔用資源，進入時間晚；② 開發同學前期對工作量評估略少於實際；③xxx專案緊急插入，前端同學需要投入一天。④ 缺陷修復完成時間未如預期，預發提測時間延期2天。
-
-
-
-
透過日報觸專案組的所有同學（包括開發、產品、業務、測試），可以讓大家對目前的測試進度和問題有個清晰的認知，同時如果專案有風險需要延遲，也可以及時周知到產品和業務，方便拉齊大家的預期。目前大家對日報還是非常認同的，後續也會堅持這個規範。
8 釋出計劃評審
相信不少同學會遇到過這樣一種情況，很多場景在預發驗收的時候沒有問題，一發到線上發現這些場景就走不通了，經過一番排查發現原因是：介面沒有多註冊、metaq的 topic 沒有配置、switch 或 diamond 的開關沒有配置好、dts 定時任務沒有啟用等配置類問題。為了避免這類問題再度發生，我們要求：
在大專案釋出前，需要進行釋出計劃評審，在釋出前在專案組內同步一遍準備工作，之後再進行釋出。
-
-
-
-
-
-
-
-
-
配置資源（diamond、switch、antx）
-
-
-
-
-
-
-
-
-
-
-
-
-
-
9 釋出&釋出後
2. 業務上可灰度，灰度沒問題後再放開到全量使用者
對於功能釋出後的系統跟蹤，主要透過系統監控、服務監控、核對來覆蓋，當出現異常時，開發和測試會第一時間去關注原因並解決問題。
對於功能釋出後的使用者體驗跟蹤，目前主要是透過灰度客戶的反饋以及全量後工單的分析。
可以看到最近存在較多工單的業務模組是哪些，從而進行針對性的最佳化，目前這一塊主要是開發在跟進。
10 專案回顧
在大型專案釋出後，如果這個專案過程中出現過一些問題，我們一般會要求組織一個專案覆盤會議，對專案中出現的問題進行復盤，並商討出後續的機制和規範，以免後續的專案再踩同樣的坑。
透過這種方式，可以不斷地完善我們團隊研發流程的規範，並及時解決當下存在的問題。
11 和菲爾茲釋出平臺的結合
菲爾茲平臺，定位為對釋出進行管控和質量管理，並對開發自測有更多輸入和幫助的一個平臺。
自測類需求與菲爾茲平臺的實踐
目前菲爾茲平臺與 aone 卡點打通，對於自測類需求，要求開發在釋出前需要先完成開發自測，並在平臺上提供自測反饋後才能釋出到線上。
透過把自測流程線上化，我們希望可以給開發自測提供更多的幫助。
1. 構建主幹案例庫，做到每個場景有詳細的操作步驟，以及一鍵觸發的介面自動化
2. 對於自測類需求，由測試在菲爾茲平臺上圈選需要回歸的主幹用例給到開發執行
我們發現，不少開發只瞭解部分的業務，或者只知道後端的部分業務邏輯，有時難以評估自己的改動會帶來的影響，或者有時想回歸某個業務但是不知道怎麼操作，為了解決這些問題，我們最近在建立國際結算業務的主幹用例庫，讓開發即使在不熟悉相關的業務的前提下，也能按照我們的用例“傻瓜式操作”地進行迴歸，從而解決開發自測的痛點。
測試接手類需求與菲爾茲平臺的實踐
一般測試接手類的需求，需求都比較大，研發週期比較長，參與人員會比較多。目前這類需求菲爾茲平臺提供給給我們的能力有：
-
冒煙流程線上化，測試可以在平臺上新增冒煙用例，並由開發標記冒煙狀態，由此我們可以統計冒煙透過率
-
提測流程線上化，測試可以在平臺上把提測打回，由此我們可以統計提測透過率，從而衡量當前開發提測的質量，並針對性地進行復盤
但對於後續流程，比如測試環節的測試日報、風險同步、釋出計劃等，目前平臺能提供的能力還在探討中，期待後續。
四 總結
前面給大家闡述了國際結算團隊在質量標準化上的一些共識，以及經過前面不少專案覆盤總結出來的規範和標準。這些規範和標準定下來後，還是得依靠測試和開發同學在後續的專案中運營、落實、完善並繼續最佳化。我們也在思考，整個研發流程能否都線上化運營，目前還沒有好的解決思路，更多的還是依賴人來分析並驅動。
