BS架構通用質量保障工作流程
質量保障是做好產品十分重要的一步，但是為了快速起專案形成業務，很多專案在設計之初全由前後端開發人員自測，穩定上線後才補上質量保障側的內容。本文旨在梳理一套BS架構產品的通用質量保障模型。
產品設計與技術評審階段
在設計階段，QA應當在各評審會1小時前開始閱讀並評論方案，以此提高會議效率並儘可能發現其中問題。
產品定義文件（PRD）評審/使用者體驗設計（UED）評審
在此階段，開發（RD）與測試（QA）人員應當替PRD/UED捉蟲，尋找PRD/UED當中的缺漏和未定義行為。在開發之前就儘量完善PRD到RD、QA沒有疑問。舉個例子：
需求名為“為搜尋框增加搜尋歷史記錄與搜尋建議”，PRD中沒有顯式說明該需求的“記錄的歷史記錄”是點選搜尋按鈕、按下回車哪一種方式觸發；也沒有說明搜尋歷史記錄記錄的是使用者所有搜尋行為還是僅記錄使用者點選搜尋建議後產生的搜尋行為。這樣RD可能會理解/曲解PRD，只記錄點擊搜尋建議以後的搜尋關鍵詞。顯然從使用者視角這樣的產品很奇怪，但是從RD視角來看“反正PRD這裡沒定義，怎麼好做怎麼來唄”。這樣的厚度哦就是功能做出來PM發現和自己想的不一樣，使用者用起來不爽。如果在需求評審階段就能解釋清楚需求定義不明確的內容，這種問題就能大大減少。
一些常見的思考發散方向為：
| 方向名 | 發散舉例 | 意義 |
|---|---|---|
| 許可權控制 | 這個需求不需要做許可權控制嗎 | 防止需要控制的功能PM忘記做許可權控制，或新功能需要收縮許可權但是忘了或者沒注意 |
| 資料 | 這個需求埋點設計成這樣是不是不合適 | 埋點放在哪裡、怎麼觸發才能達成PM的需求，收集到他們需要的資料需要一定的前端常識，而PM不一定有相關技術積累 |
| 互動邏輯 | 當用戶沒有某某許可權時，這個按鈕是否需要置灰 | 有些小需求沒有UED直接參與，一些展示邏輯PM想的可能不會很全，需要問清楚 |
| 邊緣案例 | 當子節點數量太多，這個頁面下半截會全部被子節點遮擋，要不要加個max-height | 同上 |
| 設計過於複雜/簡單 | 這個功能可以通過和某某現存功能整合的方式實現，不單獨開一個頁面是否可行？（反之亦然）否則實現成本會太高/維護成本會太高 | PM可能不會考慮技術上可以通過耦合/解耦合降低系統維護和開發/測試成本 |
值得注意的是，除非需求太離譜，**不要輕易質疑PM這個需求有什麼意義**。我們研發人員如果沒有去和使用者做調研，不知道客戶在想什麼就去拍腦袋搶PM的工作只會讓PM覺得你很煩。
技術評審
一般而言PM不具備很強的技術背景，技術評審中PM會難以捕捉RD設計的方案中可能與PRD不同的地方；因此QA作為技術人員，應仔細評估技術方案能否覆蓋整個需求。有研發相關知識的QA更應當就自己理解的技術難點向RD提問來提前暴露排期、技術設計中的漏洞。一些常見的思考方式有：
| 方向名 | 發散舉例 | 意義 |
|---|---|---|
| 效能 | 介面這樣設計有可能效能不足？這樣改介面對效能有多少影響 | 效能應當是後端考慮的重要問題，但是如果他們沒有考慮，QA要替PM問道 |
| 資料安全 | 這些東西放在local storage是否合理，會不會導致洩露或許可權控制失敗？ | 防止RD實現的時候只考慮實現難易程度，不考慮安全性 |
| 實現建議 | 最近在推行自動化，請在程式碼中新增ID等識別符方便QA定位元素 | 給前端元素加id、給後端程式碼加探針都是對前後端沒有直接意義但是對整個產品質量保障有重大意義的事情。 |
| 邊緣案例 | 當子節點數量太多，這個頁面下半截會全部被子節點遮擋，要不要加個max-height | 同產品方案評審 |
測試用例評審
測試用例評審的最重要目的是告知RD哪些測試用例需要在交付QA前自行測試完成——這些測試用例被稱為“自測用例”；其次，測試用例評審中團隊內其他角色可以站在他們的視角上為QA提供更多思路完善測試用例。自測用例的作用是為研發交付測試的產品設定准入門檻，防止研發寫了一堆bug以後自己也沒試過就直接丟給QA，消耗QA過多人力做重複而無用的工作。自測用例應當覆蓋該功能的所有核心要素和最直接影響使用者體驗的介面元件。但是，自測用例不應該超出PRD顯式定義的範疇，覆蓋過大面積的自測用例會讓RD心力憔悴，也會降低RD充分自測的意願。
研發階段
研發階段QA參與相對較少，主要由RD遵守預先設定的質量保障規範來保障前期質量。當然這不意味著在需求開發的時候QA沒事情做。QA一般可以在此時完成已上線產品功能的自動化覆蓋、巡檢和其他未完成的質量管理流程建設。
程式碼規範
嚴格遵守PEP； 使用TypeScript替代JS；使用ESLint並致力於消除絕大多數error/warning；正確命名變數並在弱型別語言/動態型別語言中主動使用型別定義等程式碼編寫策略都可以減少意外的問題。一般而言公司會有編寫程式碼的標準流程，團隊應在自身實際情況的基礎上修改、優化規範並努力執行。
單元測試
單元測試是測試單個函式邏輯是否正確必不可少的部分，單元測試一般由RD團隊編寫，並儘可能覆蓋功能的每個函式。做單元測試時，所有資料全部使用假資料（Mock），所有用例跑在本地，著眼於單個函式內部邏輯而非多個元件之間的聯絡。
單元測試一般應占到開發實踐20%以上.
整合測試
在交付QA前，RD應當根據自測用例列表將整合好的前後端試用、測試一遍。這一過程可以手動進行，也可以通過執行已有的自動化測試用例作迴歸，只對增量手動測試。
整合測試的自動化可以考慮QA與RD共建，RD做最低限度的、僅包含自測用例的整合測試；其餘邊緣、發散用例由QA自動化。
程式碼審查
程式碼審查不僅要做，還應該好好做。交叉程式碼稽核有利於找出低階編碼錯誤、統一程式碼風格、嚴格落實編碼規範。這一過程主要在RD內部進行。
測試階段
測試階段QA應按照基本的工作規範完成端到端手工、自動化測試。根據測試情況對專案做質量評估，決定是否能交付PM驗收或是否拒絕RD提測。
拒絕RD提測一般由於過多測試用例失敗或核心流程沒走通就提測。
上線流程管控
程式碼在本地跑的通不代表程式碼上線能跑，QA驗收了也不代表真的發現了所有的bug。因此，上線流程管控是必不可少的。在上線流程中，QA和專案組長可以通過一些自動化或流程管理手段減少或消除上線風險。
CICD
現代軟體開發流程為了減輕編譯上線中的重複勞動一般都會配備基本的持續整合開發流水線，在流水線中，我們可以通過新增自動化測試和手動確認卡點來進行各類上線前的檢查。
可能你會問，我們之前做了很多手工和自動化測試了，有必要在臨上線還要做卡點檢查呢？答案是有必要——一個迭代不會只做一個需求，而測試階段每個需求是獨立測試的。在上線過程中涉及到程式碼合併、配置檔案增刪，很有可能出現牽一髮而動全身的問題。在這個階段，我們可以通過下面的節點來增強穩定性
- 自動化迴歸測試節點
在這個節點，我們通過執行已有的API自動化、UI自動化、Diff測試、壓力測試指令碼檢查本次上新的功能有沒有影響已上線邏輯、有沒有導致線上效能劣化。 - 小流量/灰度測試
當自動化測試沒有發現問題，對於多機房/多叢集服務，我們可以先在一個機房的一臺機器或部分機器部署服務並在前端實際體驗一下新舊業務的核心流程是否出現問題。人在流程中永遠是最後兜底的角色。
線上質量管控
線上質量管控指的是QA和RD針對已在線上的服務設計的服務穩定性監控。除了對本產品的邏輯進行監控，這種監控還有助於發現由於依賴服務未告知即變更帶來的線上問題。
巡檢
API自動化、UI自動化、Diff測試都可以設定定時巡檢。定時巡檢的目的就是幫助及時發現依賴服務、基礎服務變動導致的自身業務崩潰，避免在大量使用者反饋無法使用服務以後才後知後覺，產生巨大影響。巡檢的建設中，API自動化和API Diff測試應當為首要建設目標——它們建設簡單，收益巨大，也可以作為QA瞭解本產品所有介面的最好切入點。
相比侵入性較小的API自動化，效能測試一般只在使用者量較低的時段、在部分機房周知各個依賴方的情況下進行。這樣操作是為了避免對上下游產生不必要的壓力，也為了防止壓測時使用者量居於高位，影響使用者的體驗。
UI自動化有其自身特點——UI改動一般較為細緻，也較為沒有結構無法預測改動，因而建設優先順序相對較低。
穩定性監控
穩定性監控可以通過關注時段內日誌聚類（介面呼叫成功率、服務報錯數）、資源監控（伺服器資源佔用情況）等服務資料波動情況來儘早發現可能存在的問題。常用的指標有：
鏈路完成速度同比、常見錯誤數量波動、服務呼叫數跌零/過低/過高、業務資料（如走某個業務分支的請求數佔總請求數比例）跌零/過低/過高、QPS跌零/過低/過高等
質量保障標準
QA的另一個關鍵工作時制定質量保障標準。服務不可能永遠不出錯，出錯後的應對措施必須再出錯前就決定好，才不會在出錯後無所適從。QA需要建設的質量保障標準一般有測試用例標準、提測准入標準、bug修復流程與時效要求、線上事故定級標準與覆盤流程等
測試用例標準
指的是QA編寫測試用例的方式方法和基本結構、不同優先順序的用例劃分的標準。
提測准入標準
指的是達到何種標準，RD可以交付產品到QA進行測試。一般而言要求100%自測用例通過方可提交測試。
bug修復流程與時效要求
指的是不同優先順序的bug要求的平均響應時長、平均問題定位時長、平均修復時長及無法及時完成時的升級流程。
線上事故定級標準與覆盤流程
事故定級標準指的是線上事故的定義方式、發生線上事故時的定級定損標準與事故響應流程、時效要求。
事故覆盤流程指的是線上事故解決後如何進行事故根因追查、工作流程優化（以避免同類事故重複發生）