2019年10月26日，由Testin主办的第二届NCTS中国云测试行业峰会在京召开，主题为“AI+未来”为主题，汇聚国内外测试领域知名专家学者、企业决策领导者、高层技术管理者、媒体从业者等，共同探讨高端云测试技术帮助测试从业者了解最前沿的行业趋势和最新的行业动态。实践。会上，DevOps专家顾宇做了主题演讲《DevOps的交付质量从需求质量开始》。顾宇介绍了企业DevOps转型的经验，并表示，“我不建议企业在DevOps能力不足的情况下做微服务转型，微服务应该是DevOps成熟度高的必然结果，否则很多质量问题会显着增加。”成本和时间成本。在质量标准不高的情况下，缩短发布周期和增加部署频率是没有意义的。p.p1{边距：0.0px0.0px0.0px0.0px;行高：22.0px；字体：15.0px'HelveticaNeue';color:#000000}以下为谷雨演讲实录：大家下午好！做开发工程师的同学请举手。做测试的同学，你是做运维的吗？在之前的会议上，我发现没有运维的同学。DevOps有开发、测试、运维，但是运维的同学一般不来。今天我做了主题演讲，从需求质量出发，讲了DevOps的交付质量。我来自一家咨询公司，我们为高科技、互联网和传统电信公司做DevOps咨询。五年来一直在做DevOps转型和咨询，也参与了一些DevOps标准的制定，辅导过企业。测试、开发、运维我都做过。我在这里谈论DevOps。上一讲讲到OverMind。四年前我还开发了一个开源工具。OverMind这个词的意思是《星际争霸》Zerg的首领——大师。今天我要讲三件事。先说案例吧。在咨询公司工作的好处是你可以认识不同的公司和不同的人。很多概念的理解都不一样。然后会讲经常遇到的技术问题，最后讲DevOps的质量理念，最重要的是需求质量提升的实践。先说案例吧。客户的领导告诉我，产品刚完成微服务改造，需要做DevOps。其实DevOps是什么根本不重要，关键是DevOps能帮你解决什么问题。他们要解决的问题是释放。每两个月发布一个版本。产品节奏如下：两周分析，两周开发，两周SIT，两周UAT。通常情况并非如此。他们的需求分析需要5周，开发需要4周，留给SIT足够的时间去测试，最后留给UAT，用户验收部门。这就导致测试的时候bug越来越多，因为UAT的时间不够，增加了4倍的人一周集中做UAT，每天都要解决一堆bug，而且每个版本都以这种方式发布。我们发现，很多企业完成微服务改造后，其测试成本有所增加。因为，以前是单体应用，后来改成了分布式应用。需要测试的点很多，各种功能测试和服务之间的非功能测试都要测试，尤其是SIT部分，增加了成本，起到了延迟leadtime的效果。我做微服务架构，也做DevOps架构改造。我不建议企业在DevOps能力不足的情况下做微服务转型。微服务应该是DevOps高度成熟的必然结果。否则，很多质量问题会大大增加人工成本和时间成本。当质量标准很低时，缩短发布周期和增加部署频率是没有意义的。DevOps解决了两个问题，第一个是软件交付的效率，另一个是提高软件交付的质量。质量和效率都需要，而且都很重要。如何提高软件质量？是否有必要增加测试人员和测试时间？提高质量会增加测试时间，从而导致更频繁的测试。所以我们刚才的例子，70%的交付周期是用来做测试的，还加了更多的人。为什么还有那么多bug？这是他们当时问我的问题。更少的错误是否意味着更高的质量？首先第一个问题，bug是什么？第一个错误是爱迪生的一封信。最早的计算机错误是日志。那时候的电脑都是用电子管做的，大概有会议厅那么大，计算都是靠灯泡和电子管来完成的。一个房间里有很多灯泡发光发热，飞蛾飞起来被高压击穿，形成短路，计算结果是错误的。这是机房管理失误，不是软件开发商的问题。说Bug的时候，我们用不同的词，Bug在国际标准中是没有定义的。我们现在能找到的定义来自维基百科，是一个软件bug。好吧，当我和客户说什么是bug时，他愣了一下。他说我们的bug指的是问题列表，所以我们区分一下这三个词。说到问题，你的反应是什么？谷歌在中国唯一能用的就是翻译。这里有很多问题。用户通常会遇到问题。一个问题在于不同的人，因为话语的内容不同。我们早上做自动化测试的时候，中文的东西词性是没法表达的。用户在使用中出现的障碍称为问题。另外，什么是缺陷？它本质上是非理性的，取决于你如何定义正常。缺陷是开发过程中逻辑不完整的意外后果。什么是故障？这是《黑客帝国》的截图，是系统故障。失败是应用程序运行时的意外结果。出现的原因比较复杂，可能是开发、设备、网络或用户自己引入的。维基百科这样定义Bug。Bug是计算机或系统中导致意外结果和行为的错误、瑕疵、故障或故障。我们明确Bug的定义，寻找形成的原因。我们之所以这样定义Bug，就是为了发现低质量的问题，然后解决它。准确定义bug是质量提升的开始，用户当然不关心是什么原因。软件开发是对用户期望的承诺，未能满足这些期望就是质量差。我们之前做过一个改进项目。之所以提高质量，不是为了增加测试，而是为了改变程序交互界面中使用的文字。用户具有相同的行为期望。会下降，这是在不增加测试的情况下提高质量的一个例子。什么是软件质量？这是ISO在1999年对软件质量的定义，翻译为软件产品满足需求的能力。对于一般的需求，可能会有客户，发现每一个环节过程都会出现质量问题，因为我们在沟通的时候，会有一个问题，就是对方到底想要多少内容，不想要多少内容。内容有没有表达，有没有记录，你有没有想过他没有表达的东西？还有一个非功能部分，表达出来了吗，要求不能慢，这个慢怎么定义？一秒内还是三秒内？也没有安全稳定的表现。缺失的需求去哪儿了？语言文字的表达能力是有限的，包括我们之前说的话，不同的人理解不同的意思，我们在这个过程中肯定会忘记一些问题，我们怎么能提出在需求阶段没有想到的问题。通常的做法是添加需求文档。查明质量问题是需求引起的。之前只写了三句话，现在又要交PPT，Word文章，Excel表格。业务部门，包括提出需求的部门，实力很强。他们经常对我说一套模板，这些人就变成了模板僵尸。这时我们只关注需求结果的质量，不去分析需求活动的质量。DevOps不仅关注结构的质量，还关注每一个活动的质量。需求文档能解决质量问题吗？在我们的示例中，就是这种情况。客户和用户之间的第一个环节是业务设计环节，业务BA，中间是产品BA。审核通过后，这个方案没有问题。把测试拉进开发，谈开发，谈测试，互相印证。这个过程就是需求的过程，这个过程就是我们前面说的我们花了五个星期做的。每个环节都会有四个不同的文件，而这些文件在开发的手里是拿不到的，包括后面用户测试的手里。DevOps需要打破组织壁垒。在这个过程中，软件质量有两种，一种叫做客观质量，满足质量指标，比如接口覆盖率，各种指标，比如之前的项目，单元测试都是100%的。用户肯定会觉得质量好？不一定，产品一定没问题？或许。另一个是主观品质。每个人对软件的结果和过程的体验，不仅包括最终使用软件的用户，还包括参与各个环节的人。他们的经历也算作素质，分为内在素质和外在素质。如果团队之间，开发觉得需求不够细，测试觉得代码不够好，没人改进，内部质量就已经先崩了，更不用说外部质量了。让我们谈谈DevOps测试概念。每次测试听到DevOps，心都碎了。这不是关于测试人员和开发人员，而是关于包括运营商在内的开发团队。因为在国外很多组织中，测试人员已经融入到开发团队中，所以我们说的是开发团队，或者说产品团队，还有运维团队。这会导致一个问题。当DevOps被引入中国的时候，大家的认识并不统一，大家都不知道该怎么做。回顾DevOps的发展历程，比利时人Patrick是DevOps的创始人。他是一名独立的质量顾问。通俗地说，他就是一个外包测试人员。在比利时做数据迁移的时候，他白天用敏捷开发的方式和开发人员一起开发弄一个软件，下午去机房和运维工程师一起上线测试。他发现两个团队白天和下午的工作方式都有些问题，因为上午考的还不错，下午就完全不一样了。为什么不把这两个团队放在一起呢？然后是DevOps运动。从一开始，DevOps本质上就是一场端到端的质量提升运动，关注质量，提高质量后再提高速度。DevOps的质量理念是质量人人有责，测试是验证需求的手段。你的要求不提，质量就没法保证。测试是整个团队的一项任务，而不是一个角色。每个人都可以做测试。有前测、中测、后测。每个人都可以做不同的事情。非功能测试和功能测试同样重要，生产环境中还存在很多问题，尤其是微服务架构。除了功能，每个服务放在一起后还正常吗？测试越早越好，越频繁越好，所以就有了自动测试开发。一切都是可衡量的，总是可衡量的。从需求开始，我以前在敏捷团队，每天讨论一个东西，我们问两个问题，第一，这个东西怎么测试？第二，这个东西怎么自动测试呢？这就形成了我们团队的文化，就是测试的文化。因此，在研发团队中，要问的问题是如何测试，如何将测试自动化，想办法提高自动化的效率和覆盖率。设计偏向于测试。我们在做自动化测试的时候，前端是不好测试的。那是因为前端没有按照测试驱动开发的方式设计，在设计的时候没有把自动化测试的适用性放到前端项目中。而且考虑的是项目，所以变得难以衡量。我们选择了折衷的方式，使用MVVM模型简单测试中间的ViewModel层，将发布的内容拆分到几乎没有发布风险，随时可以上线的程度。有几种发布风险的技术。首先是减少代码提交的内容。每次发布的内容很小，需要快速知道哪一行代码有问题。然后就是TDD，持续集成部署，还有金丝雀发布，灰度发布，蓝绿部署。微服务就是在测试周期比较长的时候把应用拆成小块进行测试。如果自动化测试能跑texture，那肯定是能独立部署的。通过拆分自动化测试对应的代码来拆分服务，拆分服务一般是没有问题的，因为对测试有一层保护。提高需求质量的做法，首先是用户故事地图，把需求记录的很好。我们把用户的句子拆分，比如“我要订个外卖软件”，直到每次测试的代码，把所有用户的故事都讲完，用户故事的概念，在给别人介绍特别好的软件的时候，会用到讲故事的方法。这个方法可以描述我们的软件，让我们知道这个软件是干什么的。推荐一本书，《用户故事地图》，里面有很多关于需求和质量的金句。我们不仅关注写需求的结果，更关注需求如何实现的过程和参与者的体验。如果您的团队没有聚在一起讨论用户故事，那您就错了。我们使用了一个相对较小但有效的方法，将“需要”替换为“需要”。用户问需求的时候，是在求你，但是当他们需要的时候，他们的态度和想法，包括他们提出的问题，都是不一样的。结果也不同。你可以尝试一下。我们不再问用户的需求是什么，而是问他们需要什么。一个好的用户故事具有3C原则和INVEST原则。3C原则，Card，Conversation，Confirmation，一定是记录少，讨论多。你必须就你的解决方案与用户达成一致，并始终指导整个软件的开发。发展。INVEST的原则首先是独立。我们希望故事之间的发展顺序不会影响最终结果。属于迭代循环，不会影响最终结果。这是故事的力量。这是可以商量的。如果用户直接告诉你怎么做，那是没有商量余地的。因此，需要以客户为中心，引导这一需求方向。有价值，设置两到三个高优先级，越紧急价值越高。small,estimable,testable,andrelevant，太大的话没办法估计，也没有办法给出一个准确的时间，所以要把它弄小。我们需求的可测试性就是这个需求。如果测试不能自动化，则它是不可测试的。因为只有那些能自动测试的规格是明确的，不能自动测试的规格是模糊的。如何生成用户故事？通过用户故事工作坊，大家在一个工作坊里一起讨论。此人是下议院院长，他常说的一句话就是“维持秩序”。在这个workshop中，一定要让用户先发言，不要打断，否则很快就会引起争论。先让用户充分表达，因为他才是质量的最终决定者。用户故事，要做到“5W1H”，确认用户（Who），确认功能（What），确认价值（Why），确认场景（When&Where），确认规格（How），我们将生成新的那些我们草拟问题的时候，产生了新的bug，当追溯原因的时候，找到这些原因，放到需求阶段，提出这些问题，在这个阶段回答。当未被问到的问题在列表中累积时，软件交付的质量就会越来越高。另外，不要让用户告诉你该怎么做。如果导航仪随意指令，司机就会走错方向。你应该让专业司机开车。还有实例化要求，需要客户举例说明，有明确的规范。先确认规格和结果，不要先确认表格。从输入到输出，中间有多种形式。先确认结果是什么，输入是什么，后面再设计。一般来说，语言的表达是非常有限的。我们制作纸人，讨论，设计，给用户讲故事，让他们明白。大家确认后，我们就可以开始开发了。还有一点，用户故事一定要讲，跟大家确认，然后让用户再讲一遍，确认。用一句话描述原理。如果不能用一句话表达出来，那么内容量很大，需求量很大。我们使用需求规范成熟度。一个好的需求规范有用户故事、验收条件和测试场景分析。用户故事是根据格式编写的。每个故事都有接受条件。有BDD式的验收条件和验收条件。测试场景和测试用例分析可以自动接受用户故事。我们要求所有的团队都在level3和level4之间。我们不使用文档，而是使用思维导图。我们的需求、测试和结果都是一一对应的。思维导图做大了，我们就知道怎么拆了。当我介绍TDD的时候，我发现每个人的理解都不一样。TDD分为三种类型，第一种是测试用例驱动开发，测试人员驱动开发人员，最后是测试计划驱动开发计划。测试人员需要在需求阶段分析和理清测试用例。一开始，大家因为工作时间的增加，对TDD产生了抵触情绪。在用了一段时间TDD之后，所有的开发者都表示不要停下来。而且，当自动化测试的覆盖率低于76%时，并不能减轻测试人员的工作量。还需要尽可能以自动化的方式实现测试用例。如果不容易实施，需要评估和审查。开发者以完成测试用例为验收条件，没有自己测试过的不能交给测试。这是最低要求。测试人员带动开发人员，即测试人员不再做重复的测试工作，而是以用户的身份接受交付的软件。测试工作是开发人员必须完成的任务。测试人员的转型有两个，一个是倒过来做DevOps，一个是往QA和业务方向做前面的几项。在这个过程中，QA和BA可以轮换。我做一段时间的需求分析，然后做一段时间的质量验收，都是站在用户的角度，要求开发者开发出符合测试质量要求的产品。大多数QA或测试人员最终在团队中得到提拔，成为团队负责人。测试计划驱动开发计划。第一个优点是可以分担测试压力。上周的UAT测试分布到每一天，每天的测试量比较平均。根据测试计划与开发计划相反，采用pull方式代替push方式。.实施DevOps的关键是将用户发布和测试拆分到每个发布的风险都可以高度可控的级别。如果能拆分成两周，就可以在两周内开发出来。如果能拆分成一天，每天都可以释放。最快的是15分钟发布一次，强度是一行代码。当要求很高的时候，我们发现了一个问题。我们两个讨论了一天，写了很多测试代码和测试用例。最后，我们只写了一行代码，这是高度讨论和充分测试的结果，这个结果是我们场景中最优化的，使得每次提交更小，风险更可控。我的演讲到此结束，谢谢大家！
