在这篇文章中，我想分享一下Heisenbug会议的15份报告，以告诉您公司展台上有什么有趣的事情，并分享Artyom Eroshenko报告中有关为IntelliJ IDEA创建动作插件的视频材料，这些视频材料将帮助您快速更改测试项目的代码。
关于HeisenBug的信息
Heisenbug-测试专家技术会议。 基本上，对于测试人员，测试中的软件开发工程师，自动化和负载测试专家而言，这很有趣。
JUG.RU团队是
组织者 ，其背后是Joker，HolyJS，SmartData，DevOops，DotNext，Mobius等会议。
会场
第五次会议在莫斯科Kievskayaskaya地铁站的Slavyanskaya Radisson酒店举行。 接近酒店时，可以看到带有会议徽标的电子横幅。 此外，在酒店大堂的入口处，与会人员伴随着签到登机柜台和衣柜的标志。 不可能迷路。 与会者和演讲者的注册发生在底层，会议的主要大厅中有合作伙伴的摊位，会议厅，带茶歇和晚餐的大厅。 保安人员的水平感到高兴，以至于不能得到“偷渡兔”。 总共有大约500多名参与者参加了该活动，其中大多数人在比赛开始前两周进行了注册。
程序
该程序可以在
这里找到。 我想指出的是，
JUG.RU一直在努力使该程序实用，没有多余的水，并且与知名的外国专家在一起。 报告分为以下符号：
如果这是您第一次打算在Heisenbag担任演讲者，请查看
演讲者的备忘录 -该
备忘录包含很多有用的信息。
沟通与志愿服务
为了使与会人员不会错过重要的会议，我们组织了电报频道和电报聊天。 顺便说一句，在后者中，他们正在寻找志愿者观看视频，并为此免费赠送了会议门票。
如果您决定成为志愿者，请尽早向组织者表明您的决定。 会议的筹备工作很早在会议之前进行。 视情况而定，您将被分配给团队。
公司展台
这次会议吸引了十几家大型IT公司的展台，例如德意志银行，阿尔法银行，Raiffeisen，Badoo，Luxoft，SKB Kontur，Gett等。每个公司都以自己的方式与参与者进行互动组织。 ，因此在表演之间不必感到无聊。 可以解决一些难忘的纪念品，玩视频和棋盘游戏以及参加彩票的问题。
Raiffeisen提供了一个在线解决方案，可以解决各种难题，而且，不朽经典的鉴赏家也可以在世嘉玩《真人快打3》。 Alfa-Bank的同事制作了一个带有任务的电报机器人，并在彩票中播放了大量的Lego Mindstorms。 我要赞扬德意志银行的摊位，现场交流的开发人员在那里进行任务分配并参与讨论，与其他摊位不同，他们只检查答案。
许多公司毫不客气地聘请专家，派发小册子描述职位空缺（从事慈善活动并非都是一样）。
报告概述
1.我们有DevOps。 让我们解雇所有测试人员 -Baruch Sadogursky。
该会议由JFrog的开发倡导者Baruch Sadogursky主持开幕，JFrog是与Java和Devops有关的会议的知名发言人。 在该报告中，Baruch解决了面对频繁发布的软件质量问题，这些问题是由于业务需求不断增长，由于体系结构差而导致的代码测试复杂以及现代敏捷团队中测试人员角色的现代化所造成的。 该报告从头到尾都很有趣，幽默很多，有趣的事实和比较。
好吧，该报告的主要思想可以放到一张幻灯片中，它说明了自动化测试和DevOps实践可以减少例行过程的时间成本，并允许您将更多的时间用于执行新任务。
2.是否需要重构项目？ 有想法！ -Artem Eroshenko。
Artyom在他的报告中谈到了为IntelliJ IDEA创建
动作插件，这将帮助您快速更改测试项目的代码。
他给出了主要类的解释（AnAction，PsiClass，PsiAnnotation，AnActionEvent，JavaCodeStyleManager），它们是Plugin Actions的输入点。
考虑了如何解决以下任务：
a）在项目上什么是自动化的，什么不是。 与Jira自动同步。
根据注释文本，@ DisplayName到达了Jira，收到了必要的票证，并使用@TmsLink断开了所有必要的连接。
b）从Jira上下文自动附加@Tags。
最喜欢的 退票中有某些标签。 我们去测试，有@TmsLink批注，我们使用插件，有新的@Tags批注，然后借助Junit，我们可以在这些标签上运行测试。
c）在测试中检查了什么？
有一个自动测试，有步骤，我们要导出，在测试中要有步骤。 视频中也有两个测试的示例。
Artyom还演示了如何快速从魅力1切换到魅力2。
对于那些正在考虑优化代码编写过程的人来说，这是一个非常实用的报告。 插件的源代码可以在
这里找到。
3. Java和Reactor项目？ -那测试呢？ -Kirill Merkushev。
西里尔分享了他在开发国际医疗创业公司Vivy方面的经验。 他讲述了如何使用微服务和Reactor库解决单片系统的可伸缩性问题。 这个库，它的基本原理，测试反应系统的方法，杀手级功能（例如请求链中的检查点和日志，Hooks和重复请求（重试））引起了很多关注。
就我个人而言，我没有处理反应系统的测试，因此对我而言这是新的且有趣的。
4.在编写用于搜索JS Sergey Dokuchaev中的
内存泄漏的Sealant框架时 。
这篇演讲是关于单页Web应用程序上的内存泄漏（可以从代码访问但不再需要的对象）。 Sergey将任务设置为在产品的发行版本中自动查找所有严重的内存泄漏。 他谈到了查找此类错误的困难以及如何使用Google Chrome浏览器工具手动进行操作。 接下来，我研究了
SeaLant工具，他是该工具的作者。 SeaLant通过使用Chrome DevTools协议与Chrome进程进行交互来自动执行泄漏检测。 该报告的最后一个事实是，如果页面可以运行循环脚本（从一台设备通过一个会话进行一次会话，而无需重新加载页面），那么很可能通过测试它们，可以消除大多数内存泄漏。
5.界面的可视化测试功能 -Anmini Usmansky，Gemini工具（可视化测试工具）和Hermione（下一代的，更通用的，可以执行屏幕截图声明的工具）的领先开发商。
该报告对于正在考虑在其项目中实施视觉测试工具的人员很有用。 那些已经使用过Gemini和Hermione的人可能也很感兴趣-它使人们了解了工具在内部的布置方式。 在某些地方，作者处理相当基本的事情。
6. Selenium WebDriver中的问题 -Alexey Barantsev。
阿列克谢谈到了硒项目的问题及其发生的原因。 他使用
Bazel收集器共享了单存储库程序集的详细信息。 他谈到了元素可见性的主题（在W3C WebDriver标准中，没有检查元素是否可见的操作），并解释了getProperty，getDomAttriubute，getAttribute函数之间的区别。
了解故障将使用户能够将功能与错误区分开，并在测试项目中开发有效的“拐杖”。
7.从零开始创建和开发负载测试系统的食谱-Anatoly Plaskovsky。
Anatoly代表Yandex.Money性能研究小组。 在他的报告中，他分享了有关如何确定绩效研究的需求，在哪里找人进行这些活动以及如何建立研究过程的实践。 作者关注的事实是性能研究！=负载测试，只有在生产中进行测试才能显示相关结果。 同时，可以通过选择测试路线和数据，监视和预测方案的可能结果来为客户进行毫无问题的实验。
Anatoly创建了一个电报聊天区，其中讨论了负载测试以及您可以在哪里寻求帮助和建议。
8.设备制造商的史诗失败 -Valentine Wylsacom Petukhov。
第一天因臭名昭著的Wylsacom的报告而关闭，公众对此表示（昧（根据电报中的heisenbag参与者的聊天来判断：）。
就我自己而言，我没有从有关设备和应用程序Beta测试的报告中获得任何有趣的东西，但也许粉丝们喜欢它。 讨论区排队等候拍照，因此PR成功。
9.使用全球短信平台 （Andrew Markelov）
为例，使用TestContainers和JUnit 5对微服务动物园进行优雅的集成测试 。
作者介绍了如何使用Testontainers+ Junit 5 + MockServer软件包在他的公司中测试微服务。 该报告听起来很有趣，但是这种方案不适用于大量微服务。 链接到
源代码。
10.测试人员的偷窥狂
，或监视用户将如何帮助您 -Antonina Khisametdinova。
一个非常有趣的报告，尽管它与Web设计比与测试有关。 它讨论了在设计客户端界面时要避免的UX实践和陷阱。
Antonina在诸如禁用按钮，使用加载程序，工具提示，熟悉的组件等UI解决方案中观察用户时，确定了主要错误。
还应注意报告的图形设计以及来自实际项目的直观示例（如关于UX的报告）。
11.测试具有外部依赖性的系统：问题，解决方案，Mountebank -Andrey Glazkov。
作者谈到了在其项目中润湿阶段的演变。 在代码级别考虑了更改的利弊。 他分享了他的经验，在这种情况下，创建一个伪造的服务实现是很好的。 但是，如果您想即时重建伪造的服务，将其代理并同时输入传入请求的日志，则Andrey建议仔细研究
Mountebank工具。
主要优点：
- mounteBank-在TCP级别工作；
- JavaScript注入；
- 开箱即用的可靠性和速度；
- 优秀的文档；
- docker容器化支持。
确定的工具限制：
- 具有数据存储的外部系统；
- WebSocket-不支持；
- 负载测试（> 150 rps），但可以使用平衡器。
12.为什么要介绍移动应用程序的端到端测试 -Vyacheslav Frolov。
维亚切斯拉夫（Vyacheslav）在报告中谈到了Badoo的自动测试状态，即自动测试如何解决并行化1,500个移动UI测试的问题，在一个模拟器上运行该测试需要30个机器小时。 结果，他们设法达到了30分钟的结果，这使他们每天可以运行8万次测试。 除了功率的线性增加之外，还应用了优化来清除应用程序缓存，而不是重新启动模拟器。 报告中还提到了探查器，以及探查器如何用于检测测试中的特殊瓶颈：例如，ios 11.0中的long_press（）方法运行了5秒钟，优化后它开始运行了一秒钟，或者如何在http-header的帮助下运行-alive”，您可以避免重新建立连接，从而显着加快所有测试的速度。 作者还介绍了如何使用FlameGraph和FlameChart工具显示探查器结果。
13.单元测试：从理论到实践 -Vadim Pushtaev。
作者分享了他在开发UnitTests方面的经验。 该报告包括三个部分。
- 我们要从UT→回归（更改的代码，已检查），对体系结构的影响（当开发人员编写测试时，代码会变得更好），理解（处理遗留代码）；
- 原则→瓦迪姆（Vadim）回忆说，理论不如实践好。 拒绝“测试接口而不是实现”的原理，因为实现中可能包含很多逻辑。 另外，原则“单元测试不是测试机制”。 他认为这是一种强大且非常有用的架构技术，但这不是检查和正确代码的机制。
- 实现→有关作者在工作中使用的技术的故事（每个类都有一个测试类，创建自己的匹配器，使用外部依赖项（如有必要，等等）。
14.使用Spring Boot Test进行测试和哭泣 -Kirill Tolkachev
Cyril决定让我们回到IoC，DI和Spring的世界，并告诉他们如何使用JUnit 5和SpringBoot编写单元和组件测试。
该报告的一大优点是，演讲者实时编写了大部分测试，即 清楚地演示了使用Spring注释包装测试的分步过程。 但是，由于大量的代码，很难将所有显示的技术都放在我的脑海中。 Cyril检查了Spring特性，以用于配置文件，模拟和间谍Bean以及设置上下文配置。 对我而言，Spring是执行此类任务的相当繁重的框架，只有有经验的用户才能在开发单元测试时步入正轨。
15.我们进行移动自动测试-Ekaterina Bateeva。
在报告中，作者检查了用于自动执行iOS应用程序的XCTest工具。 在其他项目上复制此工具很不方便。
即，确定了以下缺点：
- 难以读取启动设置；
- 难以配置组件；
- 难以与各种服务集成；
- 管理屏幕截图不方便；
- 不方便配置测试重新启动。
接下来，Catherine讨论了开源
Fastlane框架，该框架解决了他们的问题。
总结
总的来说，我喜欢这次会议。 收到了情绪和感兴趣的问题的答案。 在BoF会议上，大多数参与者脱下了“面具”，并在BoF主题框架内进行了热烈的讨论。 茶歇和晚餐都很完美，总有东西可以吃。 我还想指出事件的组织方式-JUG.RU团队每次都使Heisenbug越来越好。 最后-参加会议，分享获得的知识并提高技能！
PS：我感谢Alexei Rumyantsev参与本文的准备工作，并感谢Artem Eroshenko的视频材料。