大家好！
今天我要说的是，面试的测试任务如何成为图书馆的
图像比较 。 这是一个开源库，托管在GitHub上。
在开始之前，让我自我介绍。 我的名字叫罗马。 我是丈夫和父亲。 我是Epam Systems的软件工程师，具有4年的IT经验。
这个主题的主要思想是告诉我们，创建一个开源产品并不会浪费时间，不会！ 这是一个令人惊奇的体验，它来自所有开源社区。 这是您成为一名开发人员，项目经理，产品经理的时候。
随着这个图书馆的成长，我一直在与来自10多个（!!）国家的人们合作，例如美国，德国，中国，印度，俄罗斯，乌克兰等。
让我们从这个故事的开头继续前进...
测试任务到面试。 2017年8月。
2017年8月初，我在一家IT公司进行了一次采访，第一步是执行测试任务。
任务是用Java创建程序，以比较任何两个相同大小的图像，并通过绘制矩形直观地显示差异。 在
这里可以找到详细的要求。
我决定要尽力而为。 为此，我决定将测试任务托管在GitHub上。 我想用一块石头杀死两只鸟：提供解决方案，该解决方案是开源的，并研究GitHub的工作方式。
一段时间后，我在GitHub上找到了Marketplace，它提供了很多与GitHub存储库一起使用的服务。 对于开源项目，全部免费。 这是我第一次知道开源是最好的社区。
我添加了以下服务：
- 编码-是一种代码质量服务。
- Travis CI-持续集成工具。
- 工作服-测试覆盖率历史记录和统计数据
- BetterCodeHub-代码质量服务。
这些服务的结果可以作为插入添加到README中。 我认为阅读自述文件变得更加有趣。
测试任务完成后，我已将其发送并等待反馈。 我遇到了一些重要的问题，这些问题已添加到存储库的“发行”部分中。
其中之一-重叠的矩形...
矩形可以重叠，并且可以一对一地包含在内。 此行为导致生成的图像上出现一些垃圾。 所需的效果：合并包含一对一的矩形的矩形。作为库测试任务。 2018年七月
一段时间后，我发现很多人都在GitHub上访问我的图书馆。 真的，我认为没有人对我的测试项目感兴趣。
商标
接下来，我发现有人提出了徽标。 那是一名平面设计师。 我以前不在开源社区，这个建议对我来说真的很奇怪。 为什么有人要免费这样做。 但是他告诉我，他喜欢为开源项目做贡献。 一种生活目标的东西。 真的很棒
该项目的徽标-这是一个很棒的主意，我接受了。 有很多选择。
来自
到
决赛
这是我第一次在开源社区中交流。 新的经验，新的相识。
来自社区的第一个错误
一段时间后，我发现了该bug的GitHub公开问题。 它是来自中国的开发商。
该错误是关于大图像的问题。 他使用大图像，并出现StackOverflowError。 让我感到惊讶的是，有人使用了我的代码并发现了该错误，此外，开发人员创建了一个问题。
这是我的第一个挑战。 挑战以了解如何解决此错误。
一段时间后，来自俄罗斯的QA自动化工程师提出了对此错误的解决方案，但我拒绝了，因为“拉取请求”未按要求进行准备。 这是我的错，我需要查看并尝试了解解决方案。 它可以帮助我更快地解决它。
到那时，我已经遇到了两个关键问题。
命令行用法。 2018年秋季
开发的下一个阶段是与Renato Athaydes一起工作，他是瑞典斯德哥尔摩的软件开发人员。
他通过允许使用图像比较作为传统的CLI提出了更改建议。 听到如此令人兴奋的消息，有人想扩展图像比较的用途并在开发中打开一个新的市场。
Renato解决了我创建的所有注释，并添加了新版本-v2.0。 我开始在GitHub存储库中创建发布。 由于这个原因，这真的很有用，因为我可以快速获得特定版本中的所有更改，该版本的所有说明，贡献者等等。
接下来，Renato要求我在Maven Central中添加图像比较。 我没有向Maven Central发布库的任何经验，而Renato很高兴将所有必要的更改添加到项目中以进行发布。 发布到Maven Central允许将库添加为依赖项而没有任何问题。 一个大问题是要发布它。
但是在发布之前，我不得不修复系统中的两个主要错误。 我花了很多时间来修复它们，并在2019年4月添加了新版本-v.2.0.2。
在Maven Central中发布。 2019年四月
要正确发布库，您需要处理版本控制。 在研究了此问题之后，我开始遵循以下方案：MAJOR.MINOR.PATCH
其中：
主要 -进行不兼容的API更改时的版本
MINOR-以向后兼容的方式添加功能的版本
PATCH-进行向后兼容的错误修复的版本。
下一步是了解如何正确配置artifactId和groupId。
我更新了所有软件包：
来自 ua.comparison.image
到 com.github.romankh3.image.comparison
它使代码库所在的位置的搜索更加容易理解。
结果是发布-v2.1.0。
来自瑞典的新贡献者。 2019年五月
我收到了一封电子邮件，其中有独立顾问和承包商要求我查看Mika的新贡献。 它是瑞典的开发商。
他说，视力不好的人如果太细则很难看到diff矩形。 我喜欢这个想法，并将其添加到项目中。
通过这些更改，我的一个朋友为我提供了一个贡献，该人想练习使用GitHub流。
结果，我发布了新版本v2.2.0。
库的新步骤。 2019年五月
我来自德国卡尔斯鲁厄的TobseF发了一个问题。 他想将图像比较用作测试库。 但是他想要更多的功能。
当时，该库具有主要方法compareImages（），该方法返回了新图像。
TobseF提出了更新compareImages（）方法的返回值，以返回带有正在比较的图像的CompareResults（匹配，未匹配，sizemiss匹配）的CompareResult对象。 这将有助于在测试中使用。
此外，他建议添加一些配置选项，这将对他有所帮助。
我喜欢这些建议，但是更改不向后兼容，因此删除了部分代码库，我想保持原样。 这就是为什么我拒绝更改。
尽管如此，我还是决定自己实施。 这是改善图像比较的好主意。
此外，Mika提出了新的更改-添加区域，在比较中可以忽略这些区域。 这对于测试也很有帮助。 这就是为什么还要添加这些更改的原因。
结果，v3.0.0已发布。
3.0.0版成为真正的库，对开发人员可能有用。 我真是太棒了，图像比较越来越大。
在生产中使用。 2019年六月
6月初，我收到了自动化质量检查工程师的一封电子邮件，其中有一些关于图像比较的问题。 他说，他想在生产的自动化QA测试中使用它。
生产测试！ 我很高兴听到它。 这不是GitHub上的宠物项目，而是真正的产品。 太好了！ 我尽我所能。
他说，图像比较是他发现的唯一库，该库可以将两个图像与排除区域进行比较。 但是排除区域的功能无法按他的要求进行。
我们一直在一起工作了两个月，以使图像比较更好。
结果，它是v3.1.1版本。
利基搜索。 2019年七月
我知道，图像比较对于自动化质量检查工程师在测试中使用它很有用。
这就是为什么我找到aqa论坛的原因，在那里我发表了一篇有关图像比较的文章。 我得到了有用的反馈，并发布了v3.2.0和v3.3.0。
请，如果您知道另一个论坛，可以在此处显示图像比较-在评论上写下它。 这将有助于图像比较更好。
接下来，我找到了GitHub存储库，其中包含指向库的有用链接，并向它们添加了图像比较。
现在 2019年十一月
图像比较在Github上有60个开始，33个派生，10个用法作为依赖项。
我认为这是开源社区的一项伟大成果，它帮助我带来了一个新图书馆。
这是很长的路要走，我相信这仅仅是开始。
我要感谢所有与我建立图像比较的贡献者。
感谢您的阅读。
最好的问候
罗曼