Designtests: Top 10 Heisenbug 2018 Piter Talks



Hallo! Wir haben die Videoaufnahmen der Heisenbug 2018 Piter-Berichte geöffnet. Und speziell fĂŒr Habr haben wir nach Meinung der Konferenzbesucher - Experten auf dem Gebiet der Tests - eine Auswahl der zehn besten Berichte getroffen. Der "offtopic" erwies sich plötzlich als der beliebteste Bericht!

Die Berichte in der Auswahl sind in aufsteigender Reihenfolge angeordnet. Dies bedeutet jedoch nicht, dass die „jĂŒngeren“ viel schlechter sind: Mit Ausnahme der Spitzenreiter haben alle ungefĂ€hr die gleiche Bewertung von 4,27 bis 4,52. Daher mĂŒssen Sie wie gewohnt alles beobachten. Triff mich unter dem Schnitt!


Unternehmensautomatisierung mit Selen und warum es sehr wenig mit Selen zu tun hat


Sprecher: Michael Palotas
Ort: 10
Bewertung: 4,3 ± 0,1
PrÀsentation prÀsentieren


Die Oberseite beginnt mit einer PrĂ€sentation von Michael Palotas, dem Erfinder von Selenium Grid. Michael war fĂŒr das Testen bei eBay verantwortlich, entwickelte neue technische Verfahren und arbeitete bei Intel, Ericsson und anderen Unternehmen.

Michael spricht nicht nur ĂŒber das Selenium-Automatisierungstool selbst. Zu Recht stellt er fest, dass Selen bei der Automatisierung und beim Testen ein „geringerer Schmerz“ ist, und gibt viele praktische Beispiele dafĂŒr, wie die Implementierung des Tools in ein vollwertiges Großprojekt umgesetzt wurde, das gewartet und verwaltet werden muss.

Michael zeigt die Hauptprobleme auf, die Entwicklungsteams daran hindern, mit Selen skalierbare und zuverlĂ€ssige Lösungen zu erstellen, und zeigt saubere und kostengĂŒnstige Wege auf, um eine vollstĂ€ndige Testautomatisierung zu erreichen.



Gibt es automatische Tests in mobilen Videospielen?


Sprecher: Dmitry Alekseev / Evgeny Shumakov
Ort: 9
Bewertung: 4,3 ± 0,1
PrÀsentation prÀsentieren


In frĂŒheren Heisenbugs hat Philip Keks bereits das Thema Autotest in Handyspielen angesprochen, aber in seinem Fall war das Spiel sehr einfach zu spielen. In dem Bericht sind Dmitry und Eugene von Zeptolab ĂŒberhaupt nicht einfach: Haben sie Cut the Rope oder King of Thieves gespielt? Wie fĂŒge ich ihnen Autotests hinzu, wenn alle Spieler unterschiedliche GerĂ€te haben, es keine Frameworks gibt und wie man Fehler verfolgt?

Ein Bericht von Dmitry und Eugene zeigt, dass bei der Entwicklung und beim Testen nichts unmöglich ist. Zeptolab-Tester haben mit Testium und Appium eine ziemlich knifflige Methode gefunden, um die Koordinaten und den Speicherauszug von Grafikszenen zu abstrahieren. Der Bericht ist selbst fĂŒr Leute aus einem anderen Bereich leicht zu verstehen und zeigt gut, in welchen Phasen es möglich ist, Zeit und MĂŒhe von Entwicklern in der Entwicklung von Handyspielen zu sparen.



JUnit, gib mir fĂŒnf! Portierungscode fĂŒr JUnit 5-Erweiterungen


Sprecher: Dmitry Tuchs
Ort: 8
Bewertung: 4,3 ± 0,1
PrÀsentation prÀsentieren


Dmitry Tuchs erklĂ€rt zuversichtlich: JUnit wird fĂŒr alle Tests erstellt. Gerade erschien JUnit 5, das eine neue Codebasis, Architektur und API erhielt, aber die Einfachheit und Ausdruckskraft des Frameworks wurden nicht beeintrĂ€chtigt.

In dem Bericht demonstriert Dmitry nicht nur den Migrationsprozess aus der vorherigen Version von JUnit (nur das Ersetzen von Anmerkungen!), Sondern auch die verschiedenen Teststile, die JUnit 5 unterstĂŒtzt, und beantwortet die Frage: Was ist der Grund fĂŒr den Wechsel zu einem neuen Framework im Allgemeinen?

Der Bericht ist nĂŒtzlich fĂŒr alle Java-Tester, die Tests in großen Webprojekten durchfĂŒhren, Funktionen im AAA-Stil schreiben (Anordnen - Handeln - BestĂ€tigen und eine von A am Ende des Berichts wird nicht mehr benötigt) und einfache APIs erstellen möchten, damit AnfĂ€nger arbeiten können mit Testbeschichtungen.



Testen basierend auf Petri-Netzen


Sprecher: Alexey Rodionov
Ort: 7
Bewertung: 4,35 ± 0,05
PrÀsentation prÀsentieren


Stellen Sie sich vor, Ihre Tests können keine Fehler finden, die unter ungewöhnlichen Bedingungen auftreten, und es ist nicht mehr möglich, immer mehr Tests zu erstellen, da die AusfĂŒhrungszeit alle möglichen Grenzen ĂŒberschreitet.

Was zu tun ist? Gehen Sie zum mathematischen Apparat und suchen Sie nach alternativen Möglichkeiten, um Tests mithilfe von Diagrammen zu entwickeln. Das Programmkomitee nannte es "Testing 2.0".

Ein Hardcore-Ruby-Code-Bericht von Alexei Rodionov darĂŒber, wie Toptal von herkömmlichen Tests zu Tests auf der Grundlage mathematischer Modelle gewechselt ist, was gut und was schlecht auf dem Weg zu finden ist und warum Sie Petri-Netze beachten sollten, um das Testen zu optimieren.



Wenn Geschwindigkeit und Skalierung benötigt werden: Server von verteilten iOS-GerÀten


Sprecher: Nikolay Abalov
Ort: 6
Bewertung: 4,4 ± 0,2
PrÀsentation prÀsentieren


UI-Testentwickler sind möglicherweise mit dem Problem der TestlĂ€ufe unter iOS vertraut. Nikolai fĂŒhrt Badoo als Beispiel an - als er mit der Erstellung des Berichts begann, gab es 1200 End-to-End-Tests. Nach Abschluss - 1300. Auf der Konferenz wurde die Anzahl der Tests auf 1400 erhöht. Dies entspricht einer Maschinenzeit von 35 bis 40 Stunden im Simulator oder 1,5 Stunden in Echtzeit.

In dem Bericht erzĂ€hlt Nikolai, wie er es geschafft hat, die Testzeit auf 30 Minuten zu reduzieren, indem er zum GerĂ€teserver gegangen ist, und wie dies die Skalierung und Wartung der Infrastruktur und Tests vereinfacht hat. Nikolay spricht darĂŒber, wie man einen Knoten aus Tests und Infrastrukturen „entwirrt“ und wie man mithilfe des neuen Parallelisierungsmodells Prozesse parallel ausfĂŒhrt. FĂŒr diesen Bericht haben wir eine Textversion ĂŒber HabrĂ© erstellt, damit Sie sie nicht nur sehen, sondern auch lesen können.

Zum Schluss - ein halbkomischer Rat von Nikolai: Wenn Sie die Zeit fĂŒr das Bestehen von Tests verkĂŒrzen mĂŒssen, löschen Sie einfach das Teil. Die Zeit wird verkĂŒrzt und es gibt keine unzuverlĂ€ssigen Tests mehr. Die Skalierung ist einfach! Wenn Sie es ernsthafter brauchen - lesen Sie den Bericht selbst.



Konfigurationstests fĂŒr Java-Entwickler: Praktische Erfahrung


Sprecher: Ruslan Cheremin
Ort: 5
Bewertung: 4,4 ± 0,1
PrÀsentation prÀsentieren


Auf einer frĂŒheren Heisenbug-Konferenz sprach Andrei Satarin darĂŒber, wie Tests nicht nur mit Code, sondern auch mit Konfiguration behandelt werden können. Ruslan Cheremin arbeitete in einem Team mit Andrei und war inspiriert, diesen Ansatz fĂŒr seine eigenen Zwecke zu verwenden.

Ruslan erklĂ€rt in einer zugĂ€nglichen Form, was als Konfiguration angesehen werden kann (alles!), Wie man die Verlegenheit beim Schreiben von Konfigurationstests beseitigt und warum dies wichtig, nĂŒtzlich und recht einfach ist. Tolle PrĂ€sentation mit einfachen Beispielen, vielen Code-EinfĂŒgungen und einer einfachen ErklĂ€rung, was passiert.



Tester als ihre eigenen schlimmsten Feinde


Sprecher: Michael Bolton
Ort: 4
Bewertung: 4,46 ± 0,07
PrÀsentation prÀsentieren


Der legendÀre Michael Bolton mit der letzten Keynote, die jeder Tester sehen sollte.

Er wird nicht ĂŒber Methoden, Werkzeuge, Frameworks und vieles mehr sprechen. Michael spricht ĂŒber das Wesentliche des Testers, seine Rolle in der IT-Welt, die Bedeutung des Berufs und die Interaktion mit Menschen, nicht mit Anwendungen. Beim Testen geht es nicht um Tests. Beim Testen geht es um Menschen.

Michael enthĂŒllt die Probleme des Berufs der Tester und schlĂ€gt vor, wie man berufliche, soziale und mentale FĂ€higkeiten entwickelt, die nicht nur die EffektivitĂ€t eines Spezialisten erhöhen, sondern auch den Respekt unter den Kollegen. Sehr peppiger, aufrichtiger und wichtiger Bericht.



SĂ€gen Sie noch Ihren Bericht? Dann gehen wir zu dir!


Sprecher: Artyom Eroshenko
Ort: 3
Bewertung: 4,52 ± 0,06
PrÀsentation prÀsentieren


Der Hauptslogan des Berichts lautet „Welches Problem lösen wir?“. Artyom beschreibt klar und deutlich die Änderungen in der lang erwarteten Version von Allure 3 und erklĂ€rt, warum neue Funktionen benötigt werden - Visualisierung, neue Tools, eine einzige Konfiguration und vieles mehr.

Der Bericht ist einfach, interessant und intuitiv und wird sowohl fĂŒr diejenigen nĂŒtzlich sein, die schon lange auf Allure sitzen und mit Berichten dieser Art nicht vertraut sind.



Fuzzing-Tests: Suchen Sie nach Fehlern im JIT-Compiler und nicht nur


Referent: Maxim Kazantsev
Ort: 2
Bewertung: 4,6 ± 0,1
PrÀsentation prÀsentieren


Es gibt ein Problem. Menschen erkennen möglicherweise nicht, dass ein Fehler in der Anwendung möglicherweise mit dem Compiler zusammenhÀngt, und die Wahrscheinlichkeit von Fehlern im Compiler selbst ist schwer vorherzusagen, und es ist noch schwieriger, einen Fehler zu finden und zu beheben.

Wenn in einigen Berichten die Sammlungen dafĂŒr plĂ€dierten, die Anzahl der Tests zu reduzieren, dann haben die Compiler beim Testen ihre eigene AtmosphĂ€re und ihre eigenen Regeln. Maxim Kazantsev von Azul Systems berichtet in einem zweitplatzierten Bericht darĂŒber, wie das Leben sowohl fĂŒr diejenigen, die mit Compilern arbeiten, als auch in völlig andere Richtungen mithilfe von Fuzzing-Tests vereinfacht werden kann.

Es ist ganz einfach: Wenn ein „guter“ Test einen Fehler mit einer Wahrscheinlichkeit von 10-6 findet, findet er keinen Fehler mit einer Wahrscheinlichkeit von 0,999999. Und fĂŒnf Millionen Tests werden KEINEN Fehler mit einer Wahrscheinlichkeit von 0,9999995000000 ≈ 0,007 finden. Es gibt also einen Fehler mit einer Wahrscheinlichkeit von mehr als 99%!

Dies ist eine Art von Test, bei dem Millionen von zufĂ€lligen Tests generiert werden, die das gesamte Projekt durchlaufen und alles, worauf sie stoßen, sinnlos ĂŒberprĂŒfen. Und seltsamerweise hilft diese Methode perfekt, Probleme zu finden, bei denen Sie sowohl Geschwindigkeit als auch ein hohes Maß an ZuverlĂ€ssigkeit benötigen.

Hardcore, hochwertiger Bericht mit Codebeispielen. Achten Sie darauf, zumindest nach einer nicht standardmĂ€ĂŸigen und interessanten Methode zu suchen, um Probleme im Code zu suchen (und zu finden!).



Testen bis zuletzt: Smart Responsive Interface Design Patterns


Sprecher: Vitaliy Fridman
Ort: 1
Bewertung: 4,72 ± 0,06
PrÀsentation prÀsentieren


Und hier ist der AnfĂŒhrer unserer Shortlist, bei der es seltsamerweise ĂŒberhaupt nicht ums Testen geht. Vitaliy Fridman, bekannt unter Webdesignern und Webentwicklern, sprach hier vor einem atypischen Publikum und eroberte es!

Vitaly durchlĂ€uft systematisch alle Phasen von UX und spricht ausfĂŒhrlich ĂŒber die Komponenten der Schnittstelle und die damit verbundenen Probleme, die beim Testen verwendet werden können. Dies beinhaltet die Implementierung von "Karussells" in verschiedenen LĂ€ndern und Tipps fĂŒr wirklich bequeme Vergleiche der Eigenschaften von Waren (und nicht wie immer) sowie eine Checkliste, die bei der Erstellung eines "Akkordeons" nĂŒtzlich ist. Viele Zuschauer sagten: "Ja, hier geht es nicht ums Testen, aber es war erstaunlich." Schöne Aussicht!

Und fĂŒr diejenigen, die nicht wenige Dutzend sind, geben wir einen Link zur Wiedergabeliste , wo es weitere Auftritte mit Heisenbug 2018 Piter gibt.

Wenn Sie an den Berichten interessiert sind, beachten Sie bitte: Der Heisenbug 2018 in Moskau findet vom 6. bis 7. Dezember statt, zu dem der Entwickler des Selenium WebDriver Alexei Barantsev kommen wird, der seit 1994 testet.

Die aktuellsten Informationen zum Programm finden Sie immer auf der Konferenzwebsite. Dort können Sie Tickets kaufen (deren Preis allmÀhlich steigt).

Source: https://habr.com/ru/post/de425207/


All Articles