2019年DevOps-的質量從用戶故事開始.pdf

《2019年DevOps-的質量從用戶故事開始.pdf》由會員分享，可在線閱讀，更多相關《2019年DevOps-的質量從用戶故事開始.pdf（90頁珍藏版）》請在三個皮匠報告上搜索。

1、中國軟件技術大會CHINA SOFTWARE TECHNOLOGY CONFERENCEDevOps 的質量從用戶故事開始一個案例的啟示01章 節 PA RT我們的產品微服務改造完，需要搞 DevOps什么是 DevOps？兩周一次發布！案例背景：一個微服務轉型后的產品案例需求分析-5 周開發-4周SIT-4周UAT 1 周需求分析2 周開發2周SIT2周UAT 2 周案例背景：一個微服務轉型后的產品案例需求分析-5 周開發-4周SIT-4周UAT 1 周質量低下的提升發布頻率是沒有意義的那么？DevOps 解決什么問題？兩周發布一次的意思1.軟件交付效率2.軟件交付質量如何提升軟件質量？增加

2、測試人員？測試時間？用了交付周期的 70%來測試，為什么 Bug 還那么多？Bug 少就是質量高嗎？你說的 Bug 是什么？在我所有的發明中都如此。第一步是直覺，然后靈光一閃，然后出現困難這件事發生了，然后“Bug”這樣稱呼那些微小的錯誤和困難展現出來。在明確到達商業的成功或失敗之前，數個月的密切關注、研究和勞動是必需的。1878年愛迪生的一封信最早的 Bug最早的計算機 Bug？問題？缺陷？故障？當談到 Bug，我們指的是什么？當談到問題，你指的是哪一種？問題：用戶使用中出現的障礙什么是缺陷缺陷：開發過程中邏輯不完備產生的意外結果。什么是故障故障：應用程序運行時出現的不符合期望的結果。維基百

3、科的定義A software is an error,flaw,failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result,or to behave in unintended ways.軟件 Bug 是在計算機程序或系統中一個錯誤、瑕疵、失敗或故障。它導致了非預期的結果或者非計劃中的行為。明確 Bug 的定義是為了找到形成原因問題：用戶發現的和預期不符合的結果缺陷：開發過程中出現的錯誤故障：運行過程中出現的錯誤導致 Bug 的原因準確定

4、義“Bug”，是質量改進的開始當然，用戶才不關心是哪一種原因所以，軟件開發是對用戶預期的一種承諾不符合預期，就是質量差那么，話說回來，什么是軟件質量？capability of a software product to conform to requirements.ISO/IEC 9001:Quality management systems ISO/IEC 9001:Quality management systems-Requirements,1999.Requirements,1999.ISO/IEC 24765:Systems and software engineering IS

5、O/IEC 24765:Systems and software engineering Vocabulary,2010.Vocabulary,2010.軟件產品符合需求的能力那么，需求怎么來的？那么，需求怎么來的？那么？需求是怎么來的？用戶需求分析開發測試用戶需求分析開發測試在需求傳遞中會出現什么問題？想要不想要表達出來？沒有表達出來？在需求傳遞中會出現什么問題？功能性非功能性表達出來？沒有表達出來？遺失的需求去哪里了？遺失的需求去哪里了？語言文字的表達能力有限語言文字的表達能力有限一定會忘記一些問題！一定會忘記一些問題！怎么辦？增加需求文檔??！怎么辦？增加需求文檔??！“你給我一套模板把？”

6、需求文檔真能解決質量的問題嗎？在軟件交付流程中“活動”和“結果同樣重要”業務設計IT 概要設計IT 詳細設計評審講解反講解業務BA產品 BA開發產品 BA開發測試IT 詳細設計評審大量的需求文檔是“組織墻”的表現形式客觀質量：符合質量的度量標準主觀質量：每個人對結果和過程的體驗軟件質量是一種主觀感受DevOps的質量觀02章 節 PA RT測試聽到 DevOps，內心是崩潰的測試聽到 DevOps，內心是崩潰的運維？持續集成？流水線？自動化測試？QA？誰來做？“DevOps 之父”Patrick Debois回顧一下 DevOps 的發展DevOps 一開始就是一個端到端的質量改進運動1.每個

7、人都對質量負責。2.測試是驗證需求的手段。3.測試是一項任務，而不是一個角色。4.非功能測試和功能測試同等重要。5.越早越好，越頻繁越好。DevOps 的質量觀事事可測，時時可測DevOps 的測試觀：一言以蔽之用自動化測試描述需求DevOps 的需求觀：一言以蔽之將發布內容拆分到幾乎沒有發布風險的程度DevOps 的本質：一言以蔽之1.減少代碼提交內容2.TDD3.持續集成4.持續部署5.金絲雀發布6.灰度發布7.藍綠部署8.微服務降低發布風險的技術提升需求質量的實踐03章 節 PA RT1.用戶故事地圖2.用戶故事工作坊3.需求規格成熟度4.三種不同的TDD提升需求質量的實踐1.用戶故事地

8、圖用戶故事用戶故事地圖用戶故事地圖另一種需求文檔？用戶故事的錯誤認識：1 用戶故事地圖用戶故事地圖“用戶故事不是另一種寫需求的方式，用戶故事不是另一種寫需求的方式，而是一種建立共識的機制。而是一種建立共識的機制?！庇脩艄适碌腻e誤認識：2 用戶故事地圖用戶故事地圖“用戶故事也不是需求，用戶故事是關于問用戶故事也不是需求，用戶故事是關于問題解決方案的討論。題解決方案的討論?！庇脩艄适碌腻e誤用法：3 用戶故事地圖用戶故事地圖“如果團隊沒有聚在一起對用戶故事進行充如果團隊沒有聚在一起對用戶故事進行充分的討論，就說明你們運用用戶故事的方式分的討論，就說明你們運用用戶故事的方式不對不對”用“需要”替代“需

9、求”用戶故事用戶故事描述的是用戶需要需求規格描述的是解決方案軟件開發軟件開發不是實現用戶需求而是設計一個滿足用戶需要的解決方案好的用戶故事3C 原則 和 INVEST 原則好的用戶故事-3C3CCardConversationConfirm好的用戶故事-INVEST 原則獨立的（Independent）可協商的（Negotiable）有價值的（Valuable）小的（Small）可估計的（Estimable）可測試的（Testable）好的用戶故事-INVEST 原則獨立的：業務設計解耦，開發不依賴可協商的：實現細節可以討論和修改有價值的：“降本”or“增效”小的：超出一個迭代 or 開發人員

10、不能承諾可估計的：不可測試，就是不可估計可測試的：不能自動化測試，就不算可測試的2.用戶故事工作坊用戶故事工作坊-讓所有角色都參與用戶故事工作坊-先讓用戶說，不要打斷用戶故事工作坊-只提問、確認和記錄5 W 1 H:Who：確認用戶What：確認功能Why：確認價值When：確認場景Where：確認場景How：確認規格and之前積累的其它需求問題注意：一定不要讓用戶告訴你怎么做實例化需求-舉個例子先確認規格和結果，不要先確認形式。團隊需要討論和設計語言表示不清楚，就用原型用戶故事要講出來一句化描述原則：如果一句話說不完，那么就太大了。3.需求規格成熟度好的需求規格1.有用戶故事2.有驗收條件3

11、.有測試場景分析4.根據測試場景設計測試用例需求規格成熟度Level-1：按格式寫作用戶故事Level-2：用戶故事有驗收條件Level-3：有 BDD 風格的驗收條件Level-4：有基于驗收條件的測試場景和測試用例分析Level-5：能夠自動化驗收用戶故事用思維導圖記錄用戶故事全景4.分階段實施三種不同的TDD分階段實現不同的 TDD1.測試用例驅動開發。2.測試驅動人員驅動開發人員。3.測試計劃驅動開發計劃。測試用例驅動開發 測試人員在需求階段就要分析明確測試用例。盡量采用自動化的方式實現測試用例。如果不好實現，需要進行評估和評審。開發人員已完成測試用例為驗收條件。測試人員驅動開發人員 開發人員自己完成測試用例分析中的驗收條件。測試人員做最后的驗收工作，這類驗收條件是需求分析階段就有的。測試人員向 DevOps 或者 QA 的方向轉型。QA 和 BA 可以輪換。測試計劃驅動開發計劃 分散測試壓力，將測試分散到每天或者每周。根據測試計劃倒排開發計劃，采用拉動，而非推動。每天測試的粒度越小，開發的壓力也就越小，風險也就越小。將用戶故事的發布和測試拆分到每次發布風險高度可控的程度如何落地 DevOps 的關鍵之一THANK YOU感謝聆聽