关于质量标准化的思考和实践
簡介：最近部門在推質量標準化，通過質量標準化，推動質量內建，從而提高研發部門的交付質量，作者深度參與其中，并在推進過程中總結了一些經驗以及思考，在此通過以下定義、共識、實踐三個大方向和大家分享一下。
作者 | 靜藝
來源 | 阿里技術公眾號
最近部門在推質量標準化，通過質量標準化，推動質量內建，從而提高研發部門的交付質量，我也深度參與其中，并在推進過程中總結了一些經驗以及思考，在此通過以下定義、共識、實踐三個大方向和大家分享一下。
一 定義
1 質量標準化
何為質量標準化？用個不太恰當的比喻，大家都知道工廠的流水線作業，每個位置上的人或者機器要做什么都是提前規范好、定義好的，流水線上的商品從原材料到成品經過的都是同一套流程，因此成品間的質量不會相差太遠。研發流程和流水線作業有一定的相似性。我們希望通過標準化各條業務線的研發流程，以做的比較好的業務線作為標準樣板間，規范出一套標準化的流程，并適用到其它業務線，從而使各條業務線都能進行高質量的交付。
2 質量內建
不少研發團隊的同學都認為質量都是靠測試同學去守護的，會認為產品出現了質量問題，是測試的鍋，這是對測試工作和質量保障的一種狹隘的認識。測試同學是質量的守護神，可是質量不能只靠測試同學在最后一環去兜底。想要給用戶交付高質量的產品和體驗，必須是在研發流程各個環節都遵守質量規范，在需求評審、方案設計、開發、自測環節上的產品、開發、測試同學都要有質量意識并嚴格執行質量規范，這就是質量內建。
3 交付質量
交付質量包含系統質量和產品體驗兩部分。系統質量指的是系統的功能完備性、系統的穩定性和健壯性，產品體驗是指客戶使用此產品時是否有絲滑的體驗。
二 共識
要讓研發流程中的各個角色都愿意去踐行一套統一的標準和規范，必不可少的條件是各個角色意識形態上的統一。只有團隊的思想一致了，標準和規范才能被推進并落實。在推動 ICBU 跨境資金-國際結算團隊標準化建設的過程中，我們團隊從上到下首先在以下觀點下達成了高度統一。
1 質量不只是測出來的
在知乎上看到針對“質量是被設計出來的，還是被測出來的”問題有一個討論，覺得寫的挺好的，從不同角度分析了這個命題，我把它摘抄出來，針對“質量之道”的本源之爭，大家的發言很踴躍，我摘抄了幾個具有代表性的：
A同學：我認為質量是設計出來的，在設計上考慮的各種非功能質量數據，都會落地到代碼中。設計的優化會不斷的驅動系統質量的優化。B同學：我認為質量是測試出來的，設計的東西可以避免已知的問題，但在實際測試的過程中，還是會發現其他未考慮到的問題，例如兼容性問題，你能提前通過設計預防嗎？所以測試發現問題，問題驅動質量提升。
C同學：聽完B同學的發言，我更堅信了質量是設計出來的。在不斷的BUG驅動下，我們打補丁式做出來的系統，質量會更好嗎？打補丁解一時之急，而后續系統性的設計、重構、升級，才是提升質量的關鍵點。所以...
D同學：如果站到產品層面，我們會怎樣去定義產品好不好？在我們定義產品好壞的質量模型里，很可能會包含軟件研發相關的非功能質量屬性(ISO9126)，可能會包括產品輿情、競品對比中挖掘出的東西。例如，我們去定義一款內容推薦產品的好壞，除了“內容不重復”、“多樣性”等維度外，“是否支持分享”、“是否支持點贊”也會成為質量好壞的評判標準，新功能上線、滿足需求，用戶就會認為產品好。我們的認知會不斷升級，“好”的標準也會有更高的要求。用戶無時無刻不在使用、測試、反饋，讓質量不斷變好。
2 既要、又要、還要、且要
上述的四位同學的觀點，代表了不同的質量理念和追求：
既然大家都說得對，都代表了一種優秀的質量理念，那么就不需要取舍了，既要、又要、還要、且要。
所以我們最后的結論就成了：
“質量既是設計出來的，也是測試出來的，還是被逼出來的”，但質量一定不只是測出來的，質量保障不只是測試一種角色的責任，是貫穿研發流程各個角色共同的責任。
3 缺陷發現的時間越早，成本越低
毫無疑問，缺陷被越早的發現，修復的成本就越低。在需求評審階段就發現需求上的不合理，在技術設計階段就發現技術方案的問題所在，在測試驗證階段發現系統的bug和產品bug，修復這些環節發現的問題的成本逐漸升高，但如果問題對客后才被發現，修復的成本將是巨大的，可能會影響客戶體驗和滿意度，或造成資損，甚至導致公司名譽受損。
4 測試策略本質上是在質量成本和質量風險之間取得平衡的一種方法
我們知道，程序的執行場景和場景中涉及的數據輸入都是無法窮舉的，因此測試是不能被窮舉的。所以我們需要進行測試方案的設計，通過運用黑盒測試用例設計的等價類、邊界值法等，白盒測試用例設計的條件覆蓋法、路徑覆蓋法等從無限的測試數據中選出有效的測試數據，在有限的測試時間內進行有效的測試。
5 開發自測是基本要求和基本素養
我們一直在強調開發自測，無論需求是否有測試接手，開發都必須要自覺地完成自測。作為一名合格的開發，本身就要對自己交付的代碼有充分的質量保證，這應該是自上而下地在團隊里需要貫徹的思想和共識。
三 實踐
ICBU 跨境資金-國際結算團隊是 ICBU 質量標準化實踐的樣板間，我們團隊在研發流程各個環節都有嚴格的質量規范。國際結算團隊承接的業務多且復雜，特別是涉及到資金的需求交付，我們都是非常謹慎的。在國際結算團隊，一個需求從提出到上線，對于測試接手類的重要需求需要經歷如下環節：
需求評審->資源投入評估->技術方案設計評審->開發&聯調&自測->測試方案評審 -> 功能預演->測試->發布計劃評審-> 灰度-> 全量
對于自測類需求，需要經歷如下環節：
需求評審->資源投入評估->技術方案設計評審->開發&聯調>自測-> 灰度-> 全量
下面將闡述這些環節的規范以及衡量每個環節做得好不好的指標。
1 需求階段
在需求階段我們常遇到的問題是，在項目開發過程中，才發現存在未評估到的需求點，如果要實現這些未評估到的需求點，可能會導致項目延期，也無疑會加重項目組成員的壓力。為了解決這個問題，我們提出了以下應對機制和規范：
1、項目開發過程中，發現存在未評估到的需求點，如果不影響到主流程，通過走變更的方式解決。
責任人：
識別變更：模塊 owner or 模塊開發
操作變更：PM & PD
2、大型項目進入開發前，需要再評審一遍細的PRD，如果有UED 變更，需要先準備好設計稿再組織PRD評審；
責任人：PD（組織）、PM（監督&協調）
2 資源投入評估
需求評審結束后，開發和測試同學需要評估投入的開發資源和測試資源，需求PM會拉通各方定下排期，主要包括聯調時間、提測時間和發布上線時間，各個節點的時間一旦確定，PM和 TPM將會嚴格按照這個時間點來推進，一般是不允許延期交付的，除非有特殊原因，比如其它緊急需求臨時插入等。
在資源投入評估中，除了定下排期，測試還會評估該需求是開發自測還是測試介入，會有一套評估機制。在國際結算團隊，開發測試比是9:1，這意味著測試不可能接手每一個需求，對于一些評估出來沒有資金風險、不對客的頁面需求，會要求開發自測。
總的來說這一環節，最重要的規范是：
1、拉通各方資源，協調排期
責任人：PM
2、確定聯調時間、提測時間、發布上線時間，接下來PM和TPM 會嚴格按照這三個節點推進項目
責任人：PM 和 TPM
3、由測試確認是否需要測試接手
責任人：QA
衡量這一環節做的好不好的指標是：
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 數據，對于多次延遲的現象進行復盤，商討改進方案。
以前很多團隊可能都提過提測不通過，那就打回，把問題解決后再提測，但是從來沒有提過因此需要順延的發布時間，導致測試的壓力非常大，前面開發的鍋丟給了測試加班來兜底。更為嚴重的是，不少團隊認可測試兜底的邏輯。為了糾正這種思想，我們做了不少努力，針對延期的項目，專門組織了項目復盤會議，定下了規范：
1、預演前需要先完成域間聯調
2、功能預演由測試主導，開發需要在場，如果主鏈路卡住，需要由開發給出下次預演的時間，并順延發布時間，周知項目組；
責任人：預演-測試；排查-開發；
3、功能預演出現的問題，如果是bug問題，需要由開發本人去推動解決，如果是數據問題，則由測試去推動
4、環境問題需要完成治理
跟進人：架構師
7 測試階段
目前超過3天的測試時間的項目，測試同學會發每天發日報，通過日報來及時同步測試進展和風險，同時要求 bug 開發日結。日報模板：
一、項目里程碑
二、進展和問題
三、風險
四、明日計劃
比如發票平臺的一個日報：
一、項目里程碑
- 11.9-12.28：設計&開發&聯調，已完成
- 12.21：發票配置后臺功能預演，已完成
- 12.30：開票流程優化功能預演，已完成（延期6.5個工作日）
- 12.22-1.6：線下測試，已完成
- 1.8-1.12：預發回歸測試，進行中（延期2個工作日上預發，原計劃1.5日）
- 1.13：發布（延期5個工作日，原因：開發人員被其他項目占用資源，進入此項目時間晚）
二、進展和問題
- 線下測試進度：100%
-
預發測試進度：
- 發票配置后臺測試進度：100%
- 開票流程優化測試進度：90%
三、風險
四、明日計劃
通過日報觸項目組的所有同學（包括開發、產品、業務、測試），可以讓大家對目前的測試進度和問題有個清晰的認知，同時如果項目有風險需要延遲，也可以及時周知到產品和業務，方便拉齊大家的預期。目前大家對日報還是非常認同的，后續也會堅持這個規范。
8 發布計劃評審
相信不少同學會遇到過這樣一種情況，很多場景在預發驗收的時候沒有問題，一發到線上發現這些場景就走不通了，經過一番排查發現原因是：接口沒有多注冊、metaq的 topic 沒有配置、switch 或 diamond 的開關沒有配置好、dts 定時任務沒有啟用等配置類問題。為了避免這類問題再度發生，我們要求：
在大項目發布前，需要進行發布計劃評審，在發布前在項目組內同步一遍準備工作，之后再進行發布。
責任人：項目PM
模板如下：
1、發布范圍
a.應用范圍
b.發布順序
2、資源梳理
a.HSF接口
b.數據庫資源
c.消息資源（metaq）
d.調度資源（dts）
e.配置資源（diamond、switch、antx）
3、灰度計劃
4、發布過程
a.預發發布過程
b.線上發布過程
5、回滾計劃
6、跟蹤計劃
a.核對
b.系統監控
c.服務監控
7、風險控制和注意事項
a.歷史數據兼容
b.冪等邏輯確認
c.灰度方案
d.應急開關
衡量這一環節做的好不好的指標是：
線上bug率
9 發布&發布后
發布遵循集團的安全紅線
對于功能發布后的系統跟蹤，主要通過系統監控、服務監控、核對來覆蓋，當出現異常時，開發和測試會第一時間去關注原因并解決問題。
對于功能發布后的用戶體驗跟蹤，目前主要是通過灰度客戶的反饋以及全量后工單的分析。
可以看到最近存在較多工單的業務模塊是哪些，從而進行針對性的優化，目前這一塊主要是開發在跟進。
10 項目回顧
在大型項目發布后，如果這個項目過程中出現過一些問題，我們一般會要求組織一個項目復盤會議，對項目中出現的問題進行復盤，并商討出后續的機制和規范，以免后續的項目再踩同樣的坑。
通過這種方式，可以不斷地完善我們團隊研發流程的規范，并及時解決當下存在的問題。
11 和菲爾茲發布平臺的結合
菲爾茲平臺，定位為對發布進行管控和質量管理，并對開發自測有更多輸入和幫助的一個平臺。
自測類需求與菲爾茲平臺的實踐
目前菲爾茲平臺與 aone 卡點打通，對于自測類需求，要求開發在發布前需要先完成開發自測，并在平臺上提供自測反饋后才能發布到線上。
通過把自測流程線上化，我們希望可以給開發自測提供更多的幫助。
我們發現，不少開發只了解部分的業務，或者只知道后端的部分業務邏輯，有時難以評估自己的改動會帶來的影響，或者有時想回歸某個業務但是不知道怎么操作，為了解決這些問題，我們最近在建立國際結算業務的主干用例庫，讓開發即使在不熟悉相關的業務的前提下，也能按照我們的用例“傻瓜式操作”地進行回歸，從而解決開發自測的痛點。
測試接手類需求與菲爾茲平臺的實踐
一般測試接手類的需求，需求都比較大，研發周期比較長，參與人員會比較多。目前這類需求菲爾茲平臺提供給給我們的能力有：
但對于后續流程，比如測試環節的測試日報、風險同步、發布計劃等，目前平臺能提供的能力還在探討中，期待后續。
四 總結
前面給大家闡述了國際結算團隊在質量標準化上的一些共識，以及經過前面不少項目復盤總結出來的規范和標準。這些規范和標準定下來后，還是得依靠測試和開發同學在后續的項目中運營、落實、完善并繼續優化。我們也在思考，整個研發流程能否都線上化運營，目前還沒有好的解決思路，更多的還是依賴人來分析并驅動。
原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?
總結
以上是生活随笔為你收集整理的关于质量标准化的思考和实践的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 阿里云云原生一体化数仓正式发布 助力企业
- 下一篇： 使用AirFlow调度MaxComput