质量有保证:测试开源库的实际需求

我们正处于软件开发的黄金时代,开源库是我们现在面临的软件革命的重要组成部分,这就是为什么我觉得有必要现在谈论它。 我作为自动化QA拥有测试开源库的经验,并希望与大家分享我的想法,因为这类项目需要稍微不同的测试方法。

本文显示的所有示例仅基于我对ngx-bootstrap进行测试的经验。 Ngx-bootstrap是由Angular提供支持的一组Bootstrap组件,每个开发人员都可以快速将其集成到他的项目中。 每个UI组件都有特定的可重新配置属性/输入/输出,这对于我们获得测试经验而言,对于我们来说非常有趣。 好的,现在让所有这些属性和输入变得有些混乱,为了使事情变得清楚,让我们首先遍历所有项目角色。

开源Universe中的项目角色

  1. 顾客
    开源库的主要使用者通常是一个简单的开发人员。 在大多数情况下,开发人员尝试实现的不是自己的,而是客户的意愿。 对我们而言,这意味着质量检查不能直接从合适的人那里得到要求,他们100%知道新功能的工作方式。 这产生了一些优点/缺点:

优点:

  • 您有很多客户(在我们的情况下是开发人员),您可以直接与他们联系。
  • 您的客户通常非常聪明,您可能会不时想到他对新功能请求/问题的了解更多。 它为质量保证人员提供了成长和学习很多新东西的可能性,尤其是与开发,不同技术等有关的东西。
  • 您所有的客户都来自不同的国家,他们使用不同的语言,最重要的是,他们有不同的愿望。 所有这些使质量检查人员有可能制作独特且通用的乐器,例如Datepicker语言环境:每个人都需要它,但是我们有许多具有不同参数的不同语言。

缺点:

  • 您有大量的功能请求/问题/错误,所有这些都需要正确构造和实施。
  • 功能请求可能会发生冲突。 他们可能难以实施和测试
  • 客户只需要创建一个问题就可以忽略它。 此错误可能没有任何详细信息,具体描述,澄清信息,而质量检查通常会希望此错误会引起复制错误。 最后,这个错误根本不是一个错误,而只是对如何使用该库的误解。
  1. 开发者
    正如Tracy Lee在我们的讨论之一中所说的,并不是所有开源库都由直接对开发感兴趣的开发人员开发/支持。

现在支持开源的公司。 例如,像Valor一样,因为很多人认为开源只是做它的随机人,但实际上它实际上是由公司支持的

的确如此,这里的重点是主要的开发团队了解质量保证团队,并且我们像通常的项目一样定期进行合作。 但是,您的开发人员有时可能是地球另一端的不确定人物。

优点:

  • 开源项目的增长迅速且呈指数级增长,这取决于参与该项目的开发人员数量。
  • 质量检查人员可以直接与将分享经验的开发人员进行互动。

缺点:

  • 在大多数情况下,为开发人员提供开放源代码只是一项举措,这意味着对问题/评论的响应可能会由于实际和有薪工作的优先级较高而延迟。
  • 您需要有完整描述且易于找到的规则,样式指南,皮棉,BUT,支持通用代码/提交/文档样式的初始设置等,这需要大量时间和精力。 如果您已经有这样的规则或标准化的设置方法,那么这可能不是一件容易的事。
  1. 质量检查
    也许您现在会笑,但是开源库的主要测试人员是开发人员developers是的,那是因为他们是主要用户,并且他们将尝试在不同的OS,环境,浏览器,类型下使用您的库。的应用等

优点:

  • 质量检查人员必须像开发人员一样,在真实的应用程序代码中使用您的lib,在已经准备好的测试项目中测试与库源相关的所有新更改。
  • 首先,质量检查人员需要检查代码,其中部分代码已更改(这些部分可能损坏或行为可能更改)

缺点:

  • 如果质量检查人员仅将自己视为手动测试人员,则此活动可能很无聊且非常困难。
  • 如果库太小,则质量检查工程师可以接管分析师,项目经理甚至开发人员的职责。

测试过程概述

根据项目参与者的差异,从逻辑上可以假设测试过程本身将非常具体。 这也是事实。 我们可以通过以下方式描述测试阶段:

  1. 测试新问题。 在将发布/请求/错误包含到当前迭代/里程碑之前,质量检查人员需要调查所有其他相关的卡(如果存在,将它们链接在一起)并进行需求测试;
  2. 拉取请求测试 。 当开发人员完成新任务时,质量检查人员需要在本地克隆所有新更改,构建库并执行新功能的测试,其中包括:
  • 需求测试;
  • 手动功能测试;
  • 烟气回归测试;
  • 集成测试;

3.自动化测试 。 PR测试还可以包括任何类型的自动测试(如果未包含在CI中,那么)。 如果新的PR无法通过自动测试,则质量检查人员会与开发人员紧密合作,以调查并修复故障。 质量检查有助于通过单元测试涵盖新功能。

4.仅在创建新版本之前执行集成预发布测试 。 包括整个DEMO应用程序的烟雾检查,所有组件的全部可工作性检查以及整个库的集成测试(包括与其他测试项目集成的库的新版本测试)。 这是一个非常有用的技巧。

5.仅在发布发布后才执行集成发布后测试 (可以是@ latest,@ next,有/无重大更改)。 通常在使用当前库的最新版本的测试库(可以通过兼容性进行测试的TODO-APP或HELLO WORLD应用)中执行。

开源库的文档示例

在项目上进行新质量检查的主要目标是-在最短的时间内使它具有最大的质量(因为它可能是:D)。 定性研究的第一步是文档。 理想情况下,文档集应包括:

  • 问题模板-帮助新贡献者以标准化方式创建问题,并描述在创建新问题之前/现在/之后应该做什么。
  • 拉取请求模板-帮助新的参与者使用相同的代码样式,方法和描述规则对代码库进行适当的更改。
  • 投稿指南-描述存在的问题/功能请求/拉动请求的类型,如何拉动/提交/推动更改,包含有用的链接和常见问题的解答。
  • 自述文件—包含重要的链接,以及有关如何克隆,安装,构建,使用和更改库的信息。 该信息始终显示在GitHub存储库主页面上,因此它应包含尽可能多的有用信息,将其视为您的登录页面。 我们的建议是遵循makeareadme.com上有关如何为项目维护良好自述文件的说明。
  • 变更日志-包含有关版本,发行版和每个发行版中包含的更改的信息。 Changelog对等待某些修复/功能的开发人员非常重要,因此,它不应为空。 我们的建议是遵循keepachangelog.com关于如何为您的项目维护出色的变更日志的说明。
  • Wiki-积累所有链接和其他有用信息的好地方。
  • 不同流程的图形示例:
  1. 公关流程
  2. 发行流程
  3. 开发流程
  • 测试设计/用例/测试用例-帮助每个用户了解特定功能的工作方式,帮助质量检查人员使用自动测试覆盖应用程序并检查测试覆盖率并手动测试库,然后准备包含测试结果的摘要。

用于自动测试的Tech Stack

单元测试-Karma + Jasmine是我们自动化测试的首选工具。 我们的方法包括两个主要规则:

  1. 对于每个新更改,应编写单元测试;
  2. 未经测试,不应将Pull Requests合并到Development分支;

这两个简单的规则使开发团队至少有某种信心可以使代码正常运行(对其开发,我们永远无法确定某些代码能否100%正确地工作)。 如果新的贡献者在没有单元测试的情况下创建PR,那么其他参与者或QA可以(应该在一个完美的世界中)帮助并以正确的方式做所有事情。 Codecov是GitHub的一种机器人,可帮助摆脱开发人员PR而无需附加任何测试,而karma-coverage-istanbul-reporter是一种代码覆盖工具。

E2E测试-赛普拉斯。 这种类型的测试涵盖了每个演示页面和演示组件的用户行为。 此类测试的全面覆盖有助于减少手动发布前和发布后测试的时间。

质量检查还需要注意什么? 当然!

  • 不要花很多时间来重现描述欠佳的问题。 更好的方法是直接询问作者详细信息。 许多贡献者忽略了任何建议和问题模板,仅提供了很少的信息而没有确认。
  • 使用Stackblitz,Plunker或任何其他在线IDE(数十个!),它们可以轻松地在人与人之间共享项目以再现问题/请求。
  • 根据存储库中最流行的问题/请求,为下一个版本建立优先级,因为解决用户要求的问题会大大提高使用听觉。
  • 在创建具有重大更改/新功能的新版本之前,请确保它不会破坏其他组件/服务。 在您的公共渠道(Slack,Twitter,Telegram等)中询问您的合作者和用户
  • 许多付费服务/库/工具都可以为开源提供免费计划。 它为开发团队提供了更多的晋升机会。 不要害怕向相关团队寻求合作,我们都在同一条船上。

PS:

测试开源库与测试其他项目有点不同,至少需要基于当前lib中使用的那些技术的附加知识。 但这给每个参与的工程师提供了比其他项目更快增长的可能性。

PPS

谢谢您为开源做出的贡献。 在一起我们可以使世界变得更美好