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 用户故事地图用户故事地图“用户故事不是另一种写需求的方式，用户故事不是另一种写需求的方式，而是一种建立共识的机制。而是一种建立共识的机制。”用户故事的错误认识：2 用户故事地图用户故事地图“用户故事也不是需求，用户故事是关于问用户故事也不是需求，用户故事是关于问题解决方案的讨论。题解决方案的讨论。”用户故事的错误用法：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感谢聆听