许多项目都面临片状测试的问题，而在Habré上已经多次提出了这个话题。 尚未决定其条件的测试不仅会持续占用机器时间，还会占用开发人员和测试人员的时间。 而且，如果在一家商业公司中您可以分配一定的资源来解决此问题并任命负责人，那么在开源社区中，事情就不是那么简单了。 尤其是涉及大型项目时，例如Apache Ignite，其中有近6万种不同的测试。
实际上，在这篇文章中，我们将告诉您如何在Apache Ignite中解决此问题。 我们是GridGain的首席软件工程师/社区经理Dmitry Pavlov，以及Sberbank Technologies的IT工程师Nikolai Kulagin。
下面写的所有内容并不代表任何公司的情况，包括Sberbank。 这个故事完全来自Apache Ignite社区的成员。Apache Ignite和测试
Apache Ignite的故事始于2014年，当时GridGain向Apache Software Foundation捐赠了内部产品的第一个版本。 从那时起已经过去了4年多，在此期间，测试数量已接近6万。
我们将JetBrains TeamCity用作持续集成服务器-感谢JetBrains的支持开源运动的人。 我们所有的测试均分布在各个套件中，其中，主分支的数量接近140。在套件中，将测试按某些条件分组。 这可以仅测试机器学习[RunMl]的功能，仅测试缓存[RunCache]或整个[RunAll]的功能。 将来，运行测试将完全意味着[RunAll]-全面检查。 大约需要55个小时的机器时间。
Junit被用作主库，但是单元测试很少。 在大多数情况下，我们所有的测试都是集成测试，因为它们包含一个或多个节点的启动（这需要几秒钟）。 当然，集成测试很方便，因为这样的测试涵盖了许多方面和相互作用，而使用单个单元测试很难做到。 但这也有缺点：在我们的情况下，这是一个相当长的交货时间，而且很难发现问题。
片状问题
这些测试的一部分是片状的。 现在，根据TeamCity分类，大约有1,700个测试被标记为不稳定-即状态更改而无需更改代码或配置。 此类测试不可忽略，因为存在生产中存在错误的风险。 因此，必须仔细检查并重新启动它们，有时还要几次，以分析跌倒的结果-这需要花费大量的时间和精力。 如果社区中现有的成员能够完成这项任务，那么对于新的贡献者而言，这将成为真正的障碍。 您必须承认，对Java Doc进行更改时，您不会遇到崩溃，但是不会崩溃，而是几十次。
谁该怪？
片状测试的一半问题是由于设备的配置和安装的大小而引起的。 而后半部分则与错过并没有修复其错误的人员直接相关。
按照惯例，所有社区成员可以分为两类：
- 热心者以自己的自由意志进入社区并为他们的空闲时间做出贡献。
- 为以某种方式使用或与此开源产品相关联的公司工作的全职贡献者。
来自第一组的贡献者可以进行单个编辑并离开社区。 并且要在发现错误的情况下达到此目标几乎是不可能的。 与第二类人互动更容易，他们更有可能对打破的测试做出反应。 但是碰巧，以前对某种产品感兴趣的公司已经不再需要它了。 她正在离开社区，她的贡献者员工也在身边。 或者，贡献者可以离开公司，也可以离开社区。 当然，在进行了此类更改之后，仍有一些人继续参与社区活动。 但不是全部。
谁来解决？
如果我们谈论的是离开社区的人，那么他们的错误当然会归给当前的贡献者。 值得注意的是，对于导致该错误的修订版，审阅者也应负责，但他也可能是一个狂热者-也就是说，他将不会总是有空。
碰巧，事实证明是要与一个人接触，告诉他：这就是问题所在。 但是他说：不，这不是我的修复程序引入的错误。 由于master分支的完整运行是在相对空闲的队列中自动执行的，因此这种情况通常发生在晚上。 在此之前，可以在一天内将多次提交注入分支。
在TeamCity中，任何代码修改都被视为变更日志。 如果在三个更换者之后我们有了一个新的秋天，那么三个人会说这不是由于他们的犯错。 如果有五个转换器，那么我们将收到五个人的来信。
另一个问题：在每次检查之前，通知贡献者必须运行测试。 有些人不知道在哪里，什么以及如何运行。 还是运行了测试，但是贡献者没有在票证中写下它。 在这个阶段也有问题。
来吧 假设已运行测试，并且故障单中有指向结果的链接。 但是，事实证明，这不能保证对贯穿测试的分析。 贡献者可以查看自己的跑步情况，在那里看到一些下落，但是可以写“ TeamCity看起来不错”。 审稿人-尤其是如果他熟悉撰稿人或之前已经成功审阅过该审稿人-可能看不到结果。 我们得到了“ TeamCity看起来不错”的信息：
“好”在这里不清楚。 但是显然，作者至少知道需要运行测试。
我们如何战斗
方法1.单独的测试
我们将测试分为两组。 首先，“干净”-稳定测试。 在第二-不稳定。 这种方法相当明显，但是即使两次尝试也都没有奏效。 怎么了 因为具有不稳定测试的套件会变成贫民窟，在那里某些东西开始必然超时，崩溃等。 结果，每个人都开始简单地忽略这些有问题的测试。 通常，将考试除以成绩是没有意义的。
方法2。分离和通知
第二个选项类似于第一个选项-分配更稳定的测试，并在晚上运行其余的PR测试。 如果某个稳定组中出现问题，则会使用标准TeamCity工具将一条消息发送给贡献者，指出需要修复某些问题。
... 0个人对这些消息作出了反应。 所有人都忽略了他们。
方法3。每日监视
我们将套件分为几个“观察员”，这是社区中最负责任的成员，并签署了它们以防摔倒。 结果，在实践中证实了热情倾向于结束。 贡献者放弃了这项冒险，并停止定期检查。 然后我错过了，看着那里-再次有东西爬进了主人。
方法4.自动化
在采取另一种不成功的方法之后，GridGain的人员还记得以前开发的实用程序，该实用程序当时在TeamCity上添加了缺少的功能。 即，具有查看跌倒次数的一般统计数据的能力：第二天跌落的次数和幅度，恶化或改善的程度。 该实用程序逐步开发，添加了报告并重命名。 然后他们添加了通知，并重新命名。 事实证明，TeamCity Bot。 现在它有将近500个提交和7个贡献者，并且在补充的Apache存储库中。
机器人做什么？ 它的功能可以分为两类：
- 项目监视-通过查看运行结果以及即时通讯程序中的自动通知（例如，松弛）来进行视觉监视
- 分支机构检查-PR测试分析，以及在机票中签发签证。
TeamCity Bot工作流程
在Apache Ignite Teamcity Bot之前，向社区“贡献”的过程如下：
- 在JIRA中，选择并固定了一张票证；
- 创建拉取请求；
- 运行可能受到所做更改影响的测试；
- 如果测试通过，则提交者可以预览和调整拉取请求。
它看起来很简单，但实际上，第三点可能会成为某些贡献者的障碍。 例如：社区的新来者决定通过选择最简单的票来做出自己的第一笔贡献。 这可能是编辑Java Doc或更新Maven依赖版本。 在分析自己的小程序中的运行结果后，他突然发现大约30个测试下降了。 失败测试的数量从何而来以及如何进行分析-他不知道。 可以预料，贡献者将永远不会再回到这里。
社区中经验丰富的成员也容易遭受片刻的困扰-他们花时间分析偶然发现的测试，从而阻碍了产品开发。
TeamCity Bot的贡献计划随着自动程序的出现，反击的步骤增加了，但是分析失败的测试所花费的时间却大大减少了。 现在可以运行测试了，通过测试之后，请查看相应的漫游器页面。 如果有可能的阻止程序（丢弃的测试不被认为是不稳定的），则只需进行两次检查就可以了，然后您可以在JIRA中以评论的形式获得签证以及测试结果。
功能概述
检查贡献-所有未关闭PR的列表，其中包含每个信息的摘要：上次更新的日期，PR编号，名称，作者和JIRA中的票证 。
对于每个拉动请求，都有一个带有更详细信息的选项卡：正确的PR名称，否则，机器人将无法在JIRA中找到所需的票证； 是否运行测试； 测试结果是否准备就绪； 在JIRA发表了评论。测试结果分析：
这是有关测试同一PR的两个报告。 首先是来自机器人。 第二个是关于Teamcity的标准报告。 信息量上的差异是显而易见的，并且这没有考虑到以下事实：要查看TC测试运行的历史记录，还必须进行多次过渡到相邻页面。
让我们回到机器人报告。 该报告在视觉上分为两个表：可能的阻止程序和所有崩溃。 阻止程序包括以下测试：
- 主机故障率低于4％（100次失败中有4次失败）；
- 根据TeamCity的分类不为片状；
- 由于超时，内存不足，退出代码，JVM故障而掉线。
例如，在上面的屏幕截图中，两个套件被指示为可能的阻止者-第一个套件是测试失败，第二个套件是超时。
要最终了解什么是片状测试以及什么是错误，请考虑上图。 单杠为100行。 垂直绿色条-成功通过测试，红色-下降。 如果出现错误，运行历史看起来很自然：最后一个绿色的普通条将颜色更改为红色。 这意味着在该位置出现了错误，并且测试开始不断下降。 如果我们面前有片状测试，那么他的跑步经历就是绿色和红色的连续交替。
测试结果分析
例如，我们在上面的屏幕快照中分析通过测试的结果。 根据bot版本，由于错误可能会导致两次崩溃-它们在“可能的阻止程序”表中列出。 但这很可能是失败率低的易碎测试。 要排除此选项，只需单击“重新运行可能的阻止程序”按钮，这两个套件将进行仔细检查。 为了使任务更加轻松，您可以单击“重新运行可能的阻止程序并评论JIRA”，并在检查完成后从机器人获取评论（并通过电子邮件发送通知）。 然后进去看看是否有问题。
对于审稿人来说，这非常酷。 您可以忘记没有通过任何检查的编辑，而只需单击许多编辑，然后单击绿色的“重新运行”大按钮，然后等待字母即可。
完美报告：未检测到任何阻碍
机器人的绿色签证（评论）。 未找到阻止者。
红色签证-仔细检查和/或编辑错误碰巧有些错误仍会泄漏到“主机”中。 正如我们所说，这是通过个人通知进行的。 或有人确保一切都没有发生。 现在，我们使用一个更简单的解决方案：
当检测到新的错误时，将向开发人员列表发送一条消息，指示贡献者及其更改者，这可能是导致错误的原因。 因此，整个社区将找出导致一切发生的原因。
因此，我们能够增加修补程序的数量，并大大减少解决问题所需的时间。
监视向导状态
该机器人的另一个功能是使用最新启动的统计信息监视向导的状态。
掌握趋势
“主趋势”页面会比较特定时间段内的两个“主”选项。 对于表中的每个项目，显示最大值，最小值和中位数。
除了整个样本的总体结果之外，该表还包含每个指标的图表，并显示每个构建的值。 通过单击一个点，可以转到TeamCity上的运行结果。 此外，可以从统计信息中删除结果。 当由于严重故障而导致异常值发生时，这很有用，而造成该故障的原因可能不应该归咎于此。 此类结果应排除在外，以便在计算相同的薄片测试时不将其考虑在内。 此外，还可以区分构建以跟踪每个指标的结果。
Apache Ignite Teamcity Bot现在拥有65个以上的注册成员。 在使用该漫游器的整个过程中，签证共收到400多个请求请求，平均每天发出5个签证。
TeamCity Bot结构
该漫游器托管在单独的服务器上，前往ignite.apache.org获取数据，在开发人员列表上公开通知每个人（这是我们为Ignite开发人员提供的主要平台），并通过JIRA API向票证写入签证。
它使用了Jetty服务器，Jersey servlets，以及许多具有机器人自身复杂的业务逻辑的服务，其中包括可访问Ignited Integration服务的Teamcity，JIRA和GitHub服务。 在此用于http请求的Pure Integration之上。 作为存储-Apache Ignite自己的产品处于单节点配置嵌入式模式，具有持久性。 除了将Ignite用作数据库的明显优势之外，它还帮助我们找到Ignite的各个应用领域，并了解什么是方便的，什么不是。
该机器人实现的第一个版本的灵感来自一篇有关REST缓存的文章，它是REST缓存以及GitHub和Teamcity服务。 从服务器返回的Teamcity xml和json由Pure Java Objects解析，然后进行缓存。 起初它起作用了，而且很快。 但是随着数据量的增加，结果开始恶化。
值得注意的是，TeamCity会删除一个超过2周的故事，但该漫游器不会删除。 最终，通过这种方法，出现了大量难以管理的数据。
TeamCity Bot开发
新方法实现了紧凑的数据存储选项，并选择了少量的缓存分区。 一个节点上的大量分区会对与磁盘的数据同步速度产生负面影响，并增加群集的启动时间。
所有主要数据更新都是异步执行的，因为否则，由于TeamCity数据返回缓慢，我们有可能会得到不良的UX。
对于很少更改其值的字符串（例如，测试名称），将在id中完成一个简单的映射，该映射是由原子序列生成的。 这是此类条目的示例：
长测试名称与存储在所有内部版本中的int编号相对应。 这样可以节省大量资源。 返回此行的方法之上是Guava内存中缓存拦截器。 多亏了缓存注释，即使在堆中，我们也不会通过按ID从Ignite中读取行来选择行。 通过id我们总是得到同一行，这对性能有好处。
对于“不可预测的”行（例如，堆栈跟踪日志），使用了各种类型的压缩-gzip压缩，快速压缩或未压缩，取决于哪种更好。 所有这些方法有助于在内存中容纳最大的数据，并迅速对客户端做出响应。
为什么TeamCity Bot更好
这并不是说TeamCity不具有上面列出的功能。 它们是，但是分散在不同的地方。 在漫游器中，所有内容都收集在一页上，您可以快速了解问题所在。
机器人在检测到问题时在开发表上发送的一封信是一个不错的补充。 社区中立即有一个机会开始讨论：“让我们吧，也许我们现在会扭转？”。 这增加了审阅者的信心。
使用该机器人，新贡献者可以更轻松地加入开发流程。 进行第一次修复时，您并不总是知道所做的更改可能会带来什么。 深入研究TeamCity的测试结果，您很容易失去对进一步开发的热情。 Apache Ignite TeamCity Bot将帮助您快速了解是否存在问题并保持热情。
我们希望该机器人可以简化当前贡献者的生活，并吸引新人加入社区。 最后，我们建议当然要防止出现大量片状测试，因为这很难处理。 和信任机器人-他们没有偏好，也没有接受人们的信任。