在持续交付阶段中的测试覆盖率（译）

Posted 2020-11-13 fengye151

测试覆盖率是一项帮助我们在恰当优先级下使用稀少测试时间的一项策略。当最后东西被测试完，我们有多少自动化覆盖，用户使用这特性多经常，并且对应用程序来说这特性有多关键这些都是要考虑的因素。这儿有一些在你转向持续交付时保持高质量的主意。

在过去糟糕的日子里，我们有一个测试持续数周或者数月的测试阶段。我们开始只是测试和寻找问题，但是最后，我们不得不开始有一个足够固定的考虑发布的版本。

测试者们云集在候选中，并且我们从没有足够的时间去在软件上跑遍我们的想法。即使我们做了，为了确保所有的特性我们想要测试一个使用的平衡——或者用户用例的核心，或者组件，或者需求——为了这个版本而被测试覆盖到。

覆盖率的想法诞生了。

20年后，我共事过的团队很多不再有“测试阶段”。如果他们有，它是半天或者一天，可能最多一个星期。一些大的企业从多个团队强调了测试集成控件的本质，但是他们趋向把这个堪称是一个传统活动，而不是一个结束状态。

测试也比之前惯有的复杂得多。我们有单元测试覆盖，集成测试覆盖，自动化测试覆盖，并且，是的，真实人为探索和调研覆盖。

在那优先的是我们有一个三维：时间。很多我工作过的软件机构至少有一个日常版本，不是一个持续版本。为发版测试一周候选人几乎不工作，因为人们忙于提交修复，经常在主要分支上——版本候选人被推自的相同地方。持续部署上演，合适的我们正在测试的开发服务器在实时变化。

使用产品的持续交付，每一个修复单独滚给产品——没有“等待和测试每一个东西”时间。

改变“部署”意味的什么

当窗口程序到来，他们实际上习惯运送，在箱子里或者在一张碟上。我们能收集当前所有文件的版本并把它们作为一束部署。网站改变了所有：突然，我们只推送一个简单网页，以及可能一些图片，一次给产品。假如网页被孤立并且唯一的风险是它会出错，我们不需要重启整个应用。

一些最有名的早期持续交付的用例确实只能单独推送静态php文件或者在小群里。只要代码不改变一个代码库或者数据库，程序员会更早地回滚一个错误，突然不再需要一个长期，涉及回归测试流程了。

微服务提供给我们一个类似的利益。只要服务被关联并且我们知道主应用程序在哪里呼叫服务，然后我们能阶段测试服务，那儿它与用户接口交互，并且滚动出来——没有一个整个应用程序的大型整顿。

转变到持续交付

我共事过的许多团队正在尝试移向微服务，但是事情并没有那么简单。他们没有在恰当位置的技术去做推送——按钮，被关联到部署。假如他们做了，然后他们当然不会轻易回滚。

回滚经常由做人为改变和向前部署组成。它要求相当的结构去关联一个变化和前滚而不滚出其他提交晚的。我工作过的一个公司有过这种问题，并且测试者只评论所有的来自最后推进的变化。

不要那样做。

同时，覆盖率的想法丢了。我们假装我们生活在这个完美的独立服务的世界，但是失败的需求依然很高。对一个特性或者组件的修复很容易暴露另一些特性。直到这些“波纹变化”被淘汰，持续交付将只意味着快速滚出一束被破坏的代码。

底部一行：团队需要一个当他们转向持续交付时如何测试的游戏计划。

追踪风险和特性

今天我说看到的是团队有所有自动测试主意的列表并且在部署前恰当地执行它们——所有的Selenium测试，所有单元测试，等等。

那带来的问题是所有的主意对自动化来说太多了而没法做，就像切换命令，打印，浏览器改变大小——那些被忽略了。可能他们为每一个故事测试一次，然后忘记。并且，当然，它成为被遗忘的东西以至于结束咬我们。

在团队的最后烧毁流程，你可以使用一个基于产品特性的低技术的测试板，指派每一个特性一个分数从1到5（或者哭脸到笑脸）关于他们如何很好地测试。对下一个发布，当决定谁去指派，看一看之前的发布并且覆盖这版被触及的东西，对产品关键的，或者只是没有很好覆盖的。

你也能在固定笔记上写出紧急风险并把它们放到墙上，按优先级排序。任何人能添加他们想要的任一东西到墙上，最严重的问题排在底部。每一天，团队每个成员从墙上推掉这些风险中至少一个，测试它，并且把笔记移向其他地方并约定日期。最后你加上那些卡片回到将要被测的栈顶端。这个策略甚至能为持续交付工作——只一直推卡片。你可能甚至在产品里开始测试！

关注优先级

覆盖率是一个帮助我们花稀有的测试时间在恰当优先级的策略。当最后东西被测了，我们有多少自动化覆盖率，客户多频繁使用这个特性，并且这个特性对应用程序多关键是所有要考虑的因素。

取代提供给你们一些伪科学规则推出如何好地测试每个地方，我尝试提供一对主意去寻找可视化的方法并且以创造出共用的理解方式去抓住问题。

一些团队会忽略覆盖率的经典问题并且能独立部署小的组件。对其他每个人：我们最好去工作。