2019年10月26日，由Testin主办的第二届NCTS中国云测试行业峰会在京召开。以“未来”为主题，汇聚国内外测试领域知名专家学者、领先企业决策者、高层技术管理者、媒体从业者等，共同探讨高端云测试技术帮助测试从业者了解最前沿的行业动态和最新的行业实践。会上，中国卓越检测中心负责人陈晓鹏作了主旨演讲《基于BDD的敏捷测试案例分享》。陈晓鹏指出，“做自动化测试，必须要和CICD、DevOps结合，打通从Idea到实施，最后交付到市场的全链条。只有实现业务端的敏捷，自动化测试才能发挥作用。”它的最大价值。”以下为陈小鹏演讲实录：大家下午好，很高兴参加由Testin举办的NCTS中国云测试产业峰会。简介，我叫陈小鹏，目前在一家国际TOP3的IT咨询公司负责中国区的测试业务，即中国卓越测试中心负责人。现在整个测试团队约200人，服务于30-40个国内外项目。我的个人背景很简单。我在测试领域工作了18年多。我比较专一，这段时间也没有换过其他领域。但从服务公司的性质来看，前6年是民企，后12年是外企。外企的经历也很集中，主要就职于埃森哲、IBM、德勤这三个世界领先的IT咨询公司。我是2008年开始接触Agile的，但是21世纪的前10年，CMMI在国内非常流行，所以当时虽然接受过敏捷相关的培训，但总觉得有点国内很难实施敏捷，毕竟那时候是CMMI的天下。但是，2010年后，敏捷在中国发展迅速。2013年开始在IBM接触DevOps，之后一直在中国推广DevOps。记得第一次DevOps讲座是在2013年的深圳科技园，当时很多人甚至不知道DevOps怎么读，不知道DevOps是什么。但随后DevOps也发展迅速。到现在，Agile或者说DevOps在国内发展得如火如荼，大家都耳熟能详。现在说敏捷和DevOps，网上可以搜到很多介绍敏捷的书籍资料，但是你有没有在网上搜过关于敏捷测试的书籍？据我所知，目前市面上比较知名的敏捷测试书籍只有两本，而且出自同一位美国女性敏捷专家LisaCrispin之手。她的两本书是姊妹篇，已由中国译者翻译成中文出版。其他敏捷测试相关书籍不多，所以2015年开始研究敏捷测试这个话题，本来想今天下午分享敏捷测试方法论体系的，结果看到大会大家都想听什么实施了，所以今天下午给大家带来了一个真正的敏捷测试相关的实施案例分享。该项目的客户是一家娱乐公司。我们是2017年联系的，客户已经有了会员管理系统，但是系统比较老，技术也比较落后，但是客户很周到，很激进。据说要开发一个业内最新的技术、最好的方法、最先进的理念的会员管理系统，这也是客户当时的目标。另一个客户的目标是在半年内启动项目，所以这是客户当时交给我们的任务。我们如何处理它？通过对项目风险的分析，我们发现挑战主要体现在三个方面。首先是技术。客户说要采用新的IT技术，那么新的IT技术必然带来很大的技术风险。新技术是否成熟，是否有相应的资源去了解这些技术，是一个很大的风险；二是工期很紧，质量要求高，需要在半年内全部功能上线，把旧系统换掉，用新系统接管。同时，由于会员管理系统涉及会员资金管理，众所周知，如果系统涉及到金额的计算错误或问题，必然会带来非常大的负面影响；三是采用敏捷测试Scrum加BDD的开发模式进行开发，2016年这样的开发模式还处于很多人都在尝试但还不是很成熟的状态。所以，我们当时组建了一个项目组，规模在50人左右，分为5个ScrumTeam，每个Team的规模在8-9人左右。每个团队包括两个BA。这两个BA常驻客户的香港办公室，与客户紧密沟通，获取客户需求。其余6人在广州异地，5人开发，1人负责功能测试。另外，还有两名Shared测试开发工程师，在不同的ScurmTeams之间共享，所以整个项目有40-50人的规模。这个敏捷团队其实是分布式的，因为有香港团队和大陆团队，也包括多个ScrumTeams。本项目的技术架构底层使用亚马逊AWS云，上层使用mongoDB数据库，上层使用容器技术和微服务架构，然后通过暴露的RestfulAPI给到前端，以及前端是用AngularJS实现的。这就是技术层的介绍。同时在开发模型中引用了两种敏捷实践：一种是Scrum，大家耳熟能详，很多人都在使用Scrum；另一种是BDD行为驱动开发。这是另外一种Agile实践，和Scrum不冲突，可以融合在一起，当时就是这样。从整个项目的技术特点和开发特点来看，他们会给测试带来四个风险：第一个风险是技术风险。2017年初，很多测试人员还没有云计算和微服务的知识。如果在这样的技术平台下进行测试，如何保证新技术下的质量是第一个挑战；第二个挑战是进度风险，整个项目计划在半年内完成并上线，每两周一次的迭代速度非常快。大家认为两周内肯定有开发和测试。如何配合节奏确实是一个非常大的挑战；三是质量。风险，刚才提到因为系统涉及金额信息，如果计算有误，会带来很大的负面影响，所以在质量上也有很大的压力；第四点是风险管理，2017年大家可能更熟悉Scrum了，但是BDD是怎么工作的呢？其实项目没有多少经验，尤其是测试人员。如何将测试人员融入到整个敏捷过程中，其实是一个很大的挑战。那么，如何面对这四大挑战呢？总结了测试的难点之后，我们分析寻找对策，最后归纳为两种策略：一是自动化测试，我称之为倚天剑；二是自动化测试。另一个是持续集成，我称之为土龙道。这两个技巧现在看来可能不是太新的亮点，但在3年前却是相当新的尝试。关于自动化测试，很多人会说没有什么特别的，因为我的项目中也在使用自动化测试。那么区别是什么呢？我这里说的自动化测试是分层自动化测试的概念，这是近几年测试的一个流行趋势。什么是分层自动化？就是说我们在做自动化测试的时候不能只关注UI层的自动化测试。为什么我们不能这样做？因为UI层的自动化比较脆弱，不稳定，开发维护成本比较高。这几年以来，包括腾讯在内的很多大厂都逐渐停止了对UI自动化的投入，转而将测试工作下沉到更高的层次，比如API测试，甚至是单元测试。今年上半年和腾讯手机管家的测试负责人聊天。手机管家自动化测试的UI测试占比不到20%，大部分是通过API测试来保证的。可见，分层自动化已经是一种趋势。无论降低风险和节省成本的程度如何，都应该这样做。所以在分层自动化的部分，我们当时想的是如何覆盖UI层、API层和单元测试层，降低风险。关于持续集成，我这里为什么不强调DevOps呢？因为这个项目的Ops运维端当时不是我们控制的，是客户控制的，所以我们没有办法做到端到端的闭环环境。当时我们只覆盖UAT，不覆盖运维，所以叫持续集成。我一直认为，如果所谓的自动化测试撇开CI/CD和DevOps不谈，那么自动化测试的价值就整个项目而言仅限于很小的一部分；要做自动化测试，就必须按照CI/CD或者DevOps做整合，打通从idea到实现再到最终交付市场的整个链条。只有业务端敏捷，自动化测试才能发挥最大价值。那么策略有了，但是怎么去执行才是最重要的。我们的第一种方法是自动化测试。由于项目开发采用BDD方式，所以在自动化框架的选择上我们当然选择了Cucumber这个支持BDD的框架。其实以我的理解，Cucumber并不能称为自动化测试框架。我觉得还是做一个所谓的代码框架比较好用，可以把用自然语言写的需求自动翻译成自动化测试。这是一个非常非常大的好处。如果在座的各位和我年龄相仿，那你一定听说过一个叫ROSE的工具。如果你是开发出身，肯定会知道UML统一建模语言设计，那么统一建模语言设计工具ROSE是2000年左右所有开发者必学的工具，那个工具有一个非常大的优势，就是，可以通过画UML图自动转换成代码框架。事实上，Cucumber类似于ROSE，可以直接将自然语言需求转化为自动化测试代码框架。这种情况下，自动化测试工程师要做的就是在代码框架中填写业务逻辑和验证规则就OK了。从某种意义上说，这样可以加快我们自动化脚本的编写速度，这也是我们当时采用Cucumber框架的原因。大家都知道，在使用BDD开发模式的时候，需求方必须使用标准化或者规定的语法来编写。这种语法叫做Gherkin语言，它要求所有的需求都必须采用一种叫做GWT的方法。在什么样的条件下会出现什么样的场景，就会出现什么样的结果。那么使用GWT方式有什么好处呢？如果用传统的方法在需求阶段做需求分析，肯定会涉及到需要先从业务需求变成系统需求，再从系统需求变成开发需求。需求转换过程中会存在信息传输丢失，也存在翻译错误的风险。我曾经做过一个咨询项目，为一个移动公司的系统做过缺陷分析。上线一年就有400多个缺陷。我一一分析并归类，发现约有15%的缺陷是由于需求不足造成的。清晰度导致开发理解与需求之间的不匹配。BDD方式可以解决这个问题，因为通过BDD方式整个项目中只有一个需求描述，你看不到其他所谓的业务需求、开发需求、系统需求。需求版本没有那么多，你只有一份，不管是需求人，开发人员，还是测试人员，拿到的都是同一份需求。我觉得BDD最大的优势就是减少了项目成员之间在需求理解上的差异和不一致，完美解决了传统项目带来的需求问题。因此，使用BDD的Gherkin语法来描述需求。通过Cucumber框架将需求翻译成自动化测试代码框架。翻译完成后，自动化测试工程师只需要编写一些业务代码逻辑即可。当时除了集成了UI自动化测试工具，我们还集成了API接口测试工具。我们为什么这样做？其实我们要实现所谓的分层自动化能力，就是说框架既可以支持UI层自动化，也可以支持API自动化。很多人会问UT单元测试？单元测试由开发人员通过Junit实现。总之，测试金字塔由三个测试级别覆盖。我们基于Cucumber做了很多二次开发工作。你会看到原来的Cucumber框架就在这里，就是这么个东西。我们在原有的Cucumber框架上做了很多二次开发工作，包括支持Selenium、HttpClient和Appium等的驱动层，通过插件，这样的自动化平台不仅支持Web、API，还支持Mobile。另外，封装是在上层做的。比如我们在管理元素的时候，大家都知道在UI自动化中最头疼的就是对象的变化。对象改变后，很多时候需要调整脚本。这使得我们在做UI自动化的时候，脚本维护的工作量很大。因此，我们也在这方面进行了很多改进。这包括控件优化、封装、配置管理、数据管理等。例如，测试数据可以从数据库和表中导入；包括异常管理，出现问题自动截图，自动获取日志，自动提供信息给开发者。上层集成了Jenkins和email。Jenkins可以安排和管理交付管道，使其能够实现日常构建能力。通过dailybuilds，相当于不仅做UI测试任务，还做单元测试、API测试、UI测试。三个层次。当然，它与电子邮件集成在一起。现在很多人说email很慢，所以除了email之外，我们还可以做更多的实时短信通知，这样一旦有问题就可以有人第一时间跟进。这个框架有五个特点。首先是确保脚本稳定性大大增强。同时，使用Cucumber加速自动化测试脚本的开发，减少开发时间，提高效率。无需使用XPath来定位对象，这非常慢。我们会用更简单的识别方式来实现，在我写脚本的时候可以大大加快速度；三是可读性。Cucumber大家都知道用GWT语法写需求。无论是开发人员、测试人员，甚至是业务人员，都可以轻松看懂你的脚本；四是易于扩展，可以支持APP和WEB。第五是易于维护，它有截图和日志等帮助开发定位。这是我们当时在做自动化测试的一些工作。刚才讲的是自动化实践，但是如何将自动化测试或者测试集成到一个Scrum流程中，我猜在座的很多同学可能会有同样的疑问，如何在敏捷环境下做测试呢？与传统测试有很大的变化吗？这里我给出一张图，比较简单，但是这张流程图我们花了整整两个月的时间才找出来的，其实是通过项目实践找出来的。如果你了解Scrum，我们肯定会在每个Sprint开始的时候开一次迭代计划会议。策划会议期间，所有相关人员都需要参与，无论是BA、行业SME，还是开发测试人员。参加完这个计划会议后，你会确认这个计划要完成哪些用户故事。确认用户故事后，开发人员继续进行开发构建和单元测试。测试人员做什么？测试人员将进行ET，探索性测试。测试开发工程师做什么的？首先，它会检查这个用户故事是否可以自动化测试，如果不能，就停止，如果可以，就需要为自动化测试做准备。其中，可以看到自动化测试任务的进度条被迭代结束时间线分成了两侧，即自动化测试任务跨越了两次迭代。自动化测试任务落后于其他任务。为什么在后面？因为我们当时找到了一个经验，就是在真正开发自动化脚本之前的第二周的周三开始进行自动化测试。为什么会这样？因为我们当时发现，刚开始做自动化脚本开发的时候，因为当时开发人员还没想好思路，开发过程中会看到界面变了，前端很不稳定，所以这时候你在做脚本开发的时候，会发现需要经常做调整。在这种情况下，将浪费自动化工程师的大量精力。所以我们等到相对稳定了再做自动化脚本开发，这也是我们为什么在第二周的周二或者周三开始脚本开发的原因。自动化测试任务会在下一次迭代的第一周周三左右完成，这也是为什么自动化测试任务跨越两次迭代的原因。这里可能有人会问，如果本次迭代的自动化测试没有完成，如何保证质量？因为本次Sprint的质量会由功能测试人员通过探索性测试来保证，而本次上一次Sprint的质量会通过自动化回归测试来覆盖，即N-1的迭代质量由自动化回归来处理.，第N次迭代的质量是通过探索性测试完成的，所以没有问题。当到达N+1次迭代时，第N次迭代开发的自动化脚本会被添加到下一次回归用例库中，成为下一次轮回。这是我们探索了几个Sprint后得出的结论，也是一个关键点。刚才讲的是自动化测试方案。我们实现了分层自动化，实现了API和UI自动化。接下来，我们将其集成到集成CI/CD场景中。这是我们的CI/CD集成场景。可以看到，开发者写完代码后，不会直接提交到代码配置库，而是先在本地做代码。扫一扫，然后做开发的JUnit单元测试，没有问题的时候将代码提交git。提交到GIT后，由CI/CD流程保证。Jenkins开始构建，Jenkins首先在服务器端扫描代码，因为我们刚才做的是在本地。扫描服务端代码后，进行Docker部署。部署完成后，先触发Cucumber做API测试，再触发Cucumber做UI测试。为什么你认为有一个序列？因为API的执行效率是最高的，执行一次API接口测试可以在一两秒内得到结果，然后可能需要几分钟才能运行一个UI脚本。所以一般来说，我们都是先做API，等API没问题的时候再做UI层的自动化。如果API有问题，先停下来再解决。运行UI后没有问题，然后手动做探索性手动测试。人工测试发现问题，然后提交bug，然后回头给前端开发修改代码和单元测试，所以这是一个持续集成的工具链。通过这样一个场景，整个效率可以在两周内测试完，确实可以在两周内测试完，这就是整体的集成测试场景。另外补充一点，有些人认为只要把工具链建好就可以实现DevOps，这是一种误解。我们所说的DevOps不仅仅是一个工具链。DevOps除了工具的实现还有很多方面，包括人、组织和流程。所有这些方面都需要改变才能真正实现。下面是一个持续集成的截图过程。你会看到我们在Jenkins中配置，每天自动触发，然后自动化测试报告如下图。会有不同的执行结果，也会有运行日志和记录截图。信息通过电子邮件或通信发送。短信当然没那么详细，但是有问题的时候会短信通知，比如半夜通知。但是电子邮件更详细。每个开发人员早上来后，找到一封邮件，点击打开查看问题，立即修复。总结一下，整个项目我有三个收获：第一是实现了全栈自动化测试，从单元测试，到API测试，再到UI测试，测试金字塔都覆盖了。单元测试由开发人员完成，但通过Jenkins集成。我们当时做的API自动化测试覆盖率达到80%，UI覆盖率达到65%。二是我们当时处于这样一个所谓比较新的技术环境中，整个项目的质量是有保证的。如何通过自动化一步步保证质量，减少上线后的次品。我们的项目上线后缺陷很少。因此，节省了大量的返工工作量；三是遵循BDD和Scrum开发模式，开发人员和测试人员密切配合，加快整个流程。所以整个案例就是将AgileScrum结合实际使用BDD方法结合自动化和CIC/D的整个过程。这就是我今天要和大家分享的实际案例。
