如何在產品研發中控制質量

本文主要闡述軟件產品的研發的質量把控策略，如何規避軟件產品的質量風險。產品質量須要在產品生命週期中的各個環節進行控制，各個環節的疏忽均可能致使最終產品的質量風險，每一個節點都環環相扣，筆者經過十年的IT從業經驗，將產品生命週期中的七大環節的質量把控策略進行分析，本文僅爲我的經驗積累，確定有紕漏不足之處，有待進一步學習、優化。html

產品生命週期七大環節分別爲：需求分析 → 業務設計 → 技術設計 → 編碼實現 → 測試檢驗 → 實施部署 → 運維監控。前端

1、【需求分析】是產品研發實施階段的「源頭」，錯誤的需求分析會致使產品的失敗，誤差的需求分析會致使產品的預算、工期超支。獲取真實的需求有以下幾個關鍵點：

「準備」就如當學生上課前要預習功課同樣作好準備，將要調研的內容提早列好，提早學習專研行業的術語、業務。有準備的溝通，能讓對方感覺到你的誠意，願意跟你溝通，表達想法；有針對性地提早學習，能讓雙方的溝通在同一個專業水平層次上，互相溝通更順暢。sql

而後是溝通的對象，要找出用戶方的關鍵干係人，通常關鍵干係人分爲領導層和執行層，領導層決定了軟件產品的定位及方向，項目背景是什麼，爲何要作這個產品。執行層是實際的產品用戶，這層面的用戶更關注產品的業務流程是否合理閉環，交互體驗，操做便捷。數據庫

溝通調研的順序要根據實際狀況而定，若是跟領導層有過合做，比較熟悉，能夠「以點帶面」先跟領導層溝通，大方向把握後再跟執行層用戶細化需求。若是對領導層的意圖把控信心不足，能夠先跟執行層用戶作個摸底調研，內心有底後，再跟領導層溝通，以農村包圍城市的方式。編程
「溝通」調研跟記者採訪、訪談節目同樣，需求調研的人員就是記者、主持人，要能挖掘用戶的需求，引導用戶提出他的需求。直接問用戶你有什麼需求，你須要什麼功能，是需求調研的大忌，而是要提出你的方案，讓用戶去選擇改進。比較經常使用的方法是繪製流程圖、原型，把產品的流程、交互形象地圖形化出來，讓用戶頗有針對性地去提需求。後端
「確認」每一個人的生成環境、知識水平不同，你理解到的可能跟用戶表達的意思是有出入的，站在客戶的角度理解客戶需求的描述，不管你以爲客戶要求是否合理，都應當跟客戶複述你的理解，判讀你的理解是否跟客戶所想的一致。安全
「分析」收集到用戶的想法信息後，就須要進行分析，鑑別信息是屬於「需求」仍是「要求」，每每用戶提的都是「要求」，咱們要經過現象看本質，透過要求找出用戶真正的內在需求。下面舉一個簡單的例子，說明需求和要求的區別：服務器

【要求】：有一個表單目前設計是仿報告模板(見下圖)，讓用戶再上面填空，但客戶以爲輸入框太亂，要把佈局進行調整，輸入的文本框都集中起來，同時要求輸入框加上提示。網絡

【分析】：對於客戶的要求進行分析，把輸入框集中起來，解決了輸入框歸集，可是原來仿造報告模板來作這個表單頁面的效果就沒了，仿報告模板的表單填寫方式對於輸入框的上下文很是清楚，不用那麼多囉嗦的註釋或者提示。架構

【需求】：因此真正的用戶需求，實際上是「表單填寫時，哪裏是輸入框須要填寫，不夠突出」，分析到最終的用戶需求以後，就好辦了，原來的佈局不變，只要要一個底色，把輸入框的白底凸顯出來，用戶使用時就直觀了。改造前和改造後的表單編輯頁效果以下：

2、【業務設計】有別於研發層面的技術設計，業務設計是對數據流、業務流的分析，進而對系統的總體邏輯有一個把控，只有邏輯清楚了，產品質量才能獲得基本的保障。

「信息化意義是什麼」在我目前的工做經歷內，思考信息化根本目的是爲了：規範和經驗共享。好比一個表單，能夠用一段文字表達，不是更自由，爲何要分割成一個個輸入框，實際是爲了規範你們的填寫內容，同時肯定模板，你們填寫時不用考慮要填寫哪些字段，模板已經定好了。好比一個oa流程，以前線下簽字，每一個新人都要培訓一次，先誰簽字，而後誰簽字，造成線上系統後，系統自動生成審批流。好比之前你們開車，記性好的方便，路盲就苦逼了，如今有導航，經驗均可以共享了。
「數據流」數據是系統的靈魂，一個業務系統最底層，最核心的就是數據，一個業務系統能產生什麼數據，這些數據之間又有什麼聯繫，以及數據實體之間是如何進行流動，數據的源頭是什麼。可使用E-R圖也稱實體-聯繫圖來對數據進行表達，從而爲後續的原型設計、技術設計打下基石。
「業務流」若是說數據是食材，業務就是菜譜。業務流將數據的操做，數據的變換進行集成，好比一條請假申請，先經過員工申請提交、再到主管審批、再到人力確認等。一系列業務流，把數據進行一步步加工出口。
「原型設計」有了數據流和業務流的基礎，就能夠進行具體用戶交互界面的原型設計，相似造一個汽車前，先話一個設計圖。軟件產品開發也有設計圖，就是原型設計，能夠經過簡單的畫圖工具，或者成熟的原型工具BalsamiqMockups、axure進行設計的快速實現，把交互的想法和軟件的思路快速繪製出來，進行設計的落地並跟客戶有效地交流確認。

END

3、【技術設計】軟件系統是鏈接需求、硬件以及使得系統實現的橋樑，好的軟件的設計才能讓業務順暢的運行表達，好的軟件設計才能讓硬件獲得合理的規劃，技術設計是質量保障的重要一環。

「可靠性原則」軟件可靠性和硬件可靠性本質區別在於：後者爲物理機理的衰變和老化所致，而前者是因爲設計和實現的錯誤所致。

保障策略一：【低耦合高內聚】。講應用進行業務拆分，拆分後的每一個服務都是獨立的，可單獨維護和擴展，服務之間的調用經過接口約定進行通訊。對比早期系統的設計都是單體架構，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本，存在的問題是一旦某個環節出現性能問題，整個應用跟着一塊兒連累，更新某一個小功能，可能致使全部應用都被傳染，一榮俱榮一損俱損。

保障策略二：【不在一棵樹上吊死】。主備機制，重要的環節要有雙通道，運用分佈式技術，對重要的服務進行多臺負載均衡。對於重要的第三方服務，如短信服務，要申請至少兩個不一樣廠家的接口，一旦某一個運營商因爲網絡攻擊等緣由停服，另一個接口服務就能夠提供應急服務。

保障策略三：【事前諸葛亮】。系統運行過程當中，都會產生各式各樣的故障，報錯，每每都是平臺事故的前奏，若是能事前感知到系統的生命體徵，就須要構建一個預警體系，給系統的重要接口、重要服務進行24小時定時自動檢測，一旦出現服務不可用，第一時間通知處理。

保障策略四：【保護現場痕跡】。理想狀況下，每一個用戶操做都是可追溯的，每一個數據記錄變動都是可還原的。出現接口異常、用戶操做報錯、用戶質疑平臺數據時，日誌庫就會起到重大的做用，它默默地記錄着系統操做的全部變動，爲破案提供重要的線索。
「安全性原則」道路千萬條安全第一條。特別是涉及金錢交易的系統，安全尤其重要，要麼都沒事，一出事可能就是災難性的。登陸、用戶信息等加密傳輸確定是要的，sql注入等安全性檢測也是必須的。
「可測試性原則」對於可測試性原則我我的沒有太多的經驗，也在學習中，引用《

如何提高研發的可測試性架構設計

》中的一句話https://cloud.tencent.com/developer/news/309024：測試是軟件開發過程當中很重要的一部分，會佔用大量的時間和人力。若是想要高效的測試和得到高質量的軟件產品，咱們必須在軟件項目的啓動初期就開始關注軟件質量。

END

4、【編碼實現】代碼就像是高樓大廈的一磚一瓦，沒有高質量的代碼，可信的產品就是空中樓閣。

「健壯性」對於規範要求之外的輸入可以判斷出這個輸入不符合規範要求，並能有合理的處理方式。

第一層判斷：前端的輸入的有效性控制，不能讓非法的文字傳入後端，好比報價金額填一箇中文，最終可能致使統計報錯。

第二層判斷：前端與後端的接口約定，接口對數據類型要有一個判斷，後端對於前端傳過來的數據進行鑑別，有異常的要進行拋出。

第三層判斷：數據庫字段類型約束，對於關鍵的數值型字段，後續還會針對這個字段進行統計、計算、分析的。在數據庫層面進行字段類型約束。
「編碼規範」引用《任正非公開信：全面提高軟件工程能力與實踐，打造可信的高質量產品》https://news.cnblogs.com/n/616385/中第一句話：咱們要優化並遵循公司各類編程規範，聽從架構與設計原則，熟練使用各類編程庫和 API，編寫出簡潔、規範、可讀性強、健壯安全的代碼。
「單元自測」《信息系統項目管理師》教材中提到一個名稱：質量成本，它包含：預防成本 → 鑑定成本 → 內部損失成本 → 外部損失成本。預防成本是最小的，隨後的成本逐步增長，一旦發生外部損失成本，可能形成索賠、信譽等重大影響。

預防成本包含：代碼規範、培訓、代碼審覈、自測等測試以前的階段。

鑑定成本包含：測試人員投入、測試環境投入、測試報告輸出階段。

內部損失成本包含：測試以後的返工修改。

外部損失成本包含：一旦預防和鑑定都沒有修復存在問題，上線後事故形成的損失成本，包含人力的投入、補救措施的投入、索賠等。

因此代碼的質量不能徹底依賴於測試來保障，自測是代碼質量保障的第一道關卡，也是成本最低的一個環節。

END

5、【測試檢驗】是產品上線前的最後一道關卡，是質量控制的底線。

「提測範圍」若是是黑盒測試，測試不涉及研發代碼，對於代碼修改影響到的功能、接口，通常是經過UI交互操做進行檢驗。因此提測範圍的約定尤其重要，研發人員修改需求後，影響到的流程、功能等內容必定要描述清楚。
「測試要點」測試人員針對提測範圍，結合歷史總結的測試功能要點總結，進行本地提測範圍的測試規劃，初步造成測試要點初稿。
「測試評審」測試要點初稿，要通過主要研發人員和測試組長進行評審，避免漏測試、理解錯誤狀況。
「測試報告」針對產品測試bug造成總結報告，分析各產品質量，統計研發-測試投入比，從而推進開發團隊增強自測，從源頭上把控產品質量。

END

6、【實施部署】線上系統的更新落地。

「版本把控」系統發佈前和發佈後的新舊版本文件都要進行備份，這個是實施的基本規範。發佈目錄通常會分爲「實施目錄」、「更新目錄」、「備份目錄」。
「更新後驗證」根據以往的經驗，實施人員更新後，常常會出現幾種狀況：配置文件漏了、配置文件改錯地方、數據庫漏更新、整個文件目錄更新錯了等狀況，因此更新後的線上系統驗證是很是必要的，能夠防止低級的系統級別錯誤。
「分佈式部署」網站服務分佈式部署，多套實施目錄同步更新，最好要藉助自動化工具進行更新，避免遺漏，一旦分佈式系統，有些節點更新了，有些節點沒更新，可能形成嚴重的數據混亂和不可挽回的數據後果。曾經有一家上市公司，就因爲更新部署問題，致使公司倒閉：《

比刪庫還慘！45分鐘搞垮一家上市公司，只因一次失敗的部署？

》https://mp.weixin.qq.com/s/NlcuW-5ahkE4dmjcUPv98g

END

7、【運維監控】上線後的系統運維保障。

「安全保障」首先是服務器、數據庫資源安全管理，

近期的微盟「刪庫事件」就是超嚴重的事故。https://3g.163.com/news/article_cambrian/F6OUCNSS0519DTSV.html
「巡檢制度」分人工和自動，相似域名過時時效、服務器資源過時時效、服務器磁盤空間、內存、cpu、網站是否可訪問等均可以造成自動預警。人工操做就是一些數據庫或者服務器的按期維護重啓等。能造成程序自動預警的儘可能作成程序自動預警。
「性能分析」對於服務器和數據庫資源的監控巡檢，上面以提到，這裏講的性能分析主要包括數據庫性能分析和網站的性能分析。

數據庫性能分析，能夠經過數據庫的慢日誌進行查詢時間的排查，若是有使用阿里雲數據庫實例的話，阿里雲的後臺自帶有慢日誌的統計查詢和索引推薦。

網站的性能分析，能夠經過網站記錄的詳細請求日誌進行分析，針對請求用時比較長的數據進行判斷，是否須要優化。
「備份機制」包括按期的數據庫備份、服務器硬盤的快照，以及研發內部的源碼備份等。要進行模擬演練，一旦發生重大病毒事件，或者硬盤壞道，若是能快速恢復保障業務化運行。
「風險防控」每個月針對線上已發生的產品問題進行總結覆盤，明確後續保障措施。同時分析排查隱患，明確下月質量保證明施計劃。