Es ist offensichtlich: Nicht jeder von uns kann in der Forschung und Entwicklung arbeiten. Aber wir können uns trotzdem etwas von der Fachsprache aneignen. Hier ist ein Satz: JSL-Unit-Test-Framework. Was ist das? Wie ist es entstanden? Und warum ist es wichtig?
Lassen Sie uns das JSL-Unit-Test-Framework entmystifizieren.
Vielen Dank an Nicole Jones ( @Nicole_Jones ), Sr. Manager of Advanced Analytics Testing, für diese Erklärung:
„Der Begriff Unit bezeichnet die kleinste testbare Komponente eines Softwareprodukts und der Begriff Unit-Test bezeichnet den Validierungsprozess, der sicherstellt, dass die Einheiten wie erwartet funktionieren. Der Begriff Unit-Test-Framework bezeichnet mittlerweile den Mechanismus, der zur Durchführung automatisierter Unit-Tests verwendet wird.“
Der leitende Forschungsstatistiker Joseph Morgan ( @joseph_morgan ) führte diese Begriffe in JMP ein, als er im Jahr 2005 seine Arbeit als Statistiktester aufnahm. (Heute arbeitet er in der DOE-Gruppe.) Joseph hat einen Hintergrund in Softwareentwicklung und Informatik sowie diskreter Mathematik und Statistik.
„Er hat das gesamte Konzept eines zentralen Test-Frameworks entwickelt“, sagt Audrey Shull ( @Audrey_Shull ), Senior Manager of Test Engineering. „Er hat viele großartige Ideen und dies war eine davon.“
„Nachdem er sich mit JMP und JSL vertraut gemacht hatte, konnte er das JSL-Unit-Test-Framework entwickeln und dabei die statistische Natur der Software im Auge behalten“, sagt Nicole.
Joseph Morgan erklärt (4:38)
„Wir trinken unseren eigenen Champagner“
Ein Unit-Test-Framework kann in anderen Sprachen geschrieben werden, aber welches Tool wäre besser geeignet als unser eigenes JSL?
Mit dem JSL-Unit-Test-Framework „verwenden wir JMP, um JMP zu testen“, erklärt Audrey. Mit anderen Worten: „Wir trinken unseren eigenen Champagner.“ Und das ist nicht mit allen Tools möglich.
„Wir können unsere Software zum Testen unserer Software verwenden, weil wir diese vielseitige JSL-Sprache haben“, fährt Audrey fort. „Wir erweitern die Grenzen dessen, was JSL leisten kann, um das Framework zu unterstützen. Das ist etwas ganz Besonderes. Und das Framework selbst dient als riesiger Regressionstest für die Abwärtskompatibilität von JSL.“
„Wenn das Entwicklungsteam die Funktionsweise der Skripterstellung ändert, bemerkt die Testgruppe dies zuerst, da wir der erste Kunde der JSL-Sprache sind.
„Alle Unternehmen versuchen, Automatisierung zu nutzen, aber oft verwenden sie dazu Tools von Drittanbietern. Sie haben nicht immer den Luxus, ihre eigene Software zu verwenden.“
Ein erweiterbares Framework
A screenshot of the original dialog. Ein Screenshot des ursprünglichen Dialogs. Das JSL-Unit-Test-Framework wird auf allen JMP-Plattformen verwendet. Es kann beispielsweise verwendet werden, um die Drag-and-Drop-Funktionalität im Graph Builder zu testen. Oder die roten Dreieckmenüs. Oder jede beliebige Codeeinheit in der Distribution-Plattform.
„Wir können es nicht nur zum Testen von JSL selbst verwenden, sondern das Framework auch zum Testen aller anderen Plattformen“, sagt Audrey.
Nicole führt aus:
„Als Joseph das Framework entwickelte, lag sein Hauptaugenmerk darauf, eine Möglichkeit zu finden, eine Regressionstestsuite für die Statistikplattformen in JMP zu erstellen. Dennoch gelang es ihm, ein Framework zu erstellen, das erweiterbar war – die Regressionstestsuite umfasst sowohl Statistikplattformen als auch Grafikplattformen, sie funktioniert sowohl auf Macintosh als auch auf Windows, sie testet sowohl Datentabellenbefehle als auch Berichtsstrukturen.“
Arbeiten mit „Sicherheitsnetz“
Das Framework kann manuell ausgeführt werden – Tester und Entwickler können es starten, zeigen und klicken und ausführen. Automatisierung ist jedoch der Schlüssel zur kontinuierlichen Verbesserung.
Das Framework wird durch Perforce (ein Arbeitsrepository) automatisiert, wo die Arbeit der Entwickler gespeichert ist und Code implementiert wird. JMP-Tester schreiben Testfälle und laden sie in einen dedizierten Abschnitt in Perforce hoch.
Screenshot of the testing dialog as it looks today.Screenshot des Testdialogs, wie er heute aussieht.
Ein nächtlicher automatisierter Prozess, der vom leitenden Systementwickler Jim Borek ausgeführt wird, erfasst alle an diesem Tag hochgeladenen Tests, erfasst den gesamten an diesem Tag gepushten Code, führt die Testfälle mit dem aktualisierten Code aus und benachrichtigt das Team, wenn etwas fehlschlägt. Jim spielt eine zentrale Rolle bei der Automatisierung dieses Prozesses und der Wartung der Maschinen.
Audrey beschrieb den enormen Umfang der durchgeführten Tests: Jede Nacht werden 2,4 Millionen Tests ausgeführt. Und das geschieht auf jedem Betriebssystem (z. B. Windows, Catalina, BigSur) sowohl für JMP 17 als auch für JMP 16.2. Der Vorgang, die Tests auf einer einzelnen Maschine auszuführen, dauert 6 bis 10 Stunden, je nachdem, wie schnell die Maschinen sind.
„Das ist die Regressionstestsuite – ohne dieses Framework müssten wir diese Dinge jeden Tag testen, um zu sehen, ob sie kaputt gehen oder nicht“, sagt Audrey. „Das geht nicht manuell. Die Testsuite ist automatisiert, sodass das System uns benachrichtigt, wenn ein Fehler aufgetreten ist.“
„Manchmal nennen wir es gerne ein Sicherheitsnetz. Ich weiß, dass es beim letzten Test funktioniert hat. Ich habe einen Testfall geschrieben, und wenn das System kaputt geht, lasst es mich wissen. Ich kann mich dann anderen Dingen zuwenden. Wir versuchen zu testen, was neu ist und der Software hinzugefügt wird.“
Der JSL Test Framework-Workflow
Einen Apple-Fehler finden
Joseph erzählt eine frühe Anekdote, die den Wert des Unit-Test-Frameworks untermauerte.
„Kurz nachdem die erste Implementierung des JSL-Unit-Test-Frameworks einsatzbereit war, wurde sein Wert auf eher ungewöhnliche Weise deutlich. Interessanterweise wurde keine Regression von JMP erkannt, sondern es war der Schlüssel zur Isolierung eines ziemlich schwerwiegenden Fehlers in MacOS.
„Anfang 2006 begann Apple mit der Umstellung der Macintosh-Reihe von PowerPC-CPUs auf Intel-CPUs und um diesen Übergang zu erleichtern, wurde MacOS mit einem Emulator namens Rosetta ausgestattet. Dieser Emulator ermöglichte die Ausführung von PowerPC-Anwendungen auf Intel-Macs und wurde daher von Apple als Schlüsselsoftware angesehen.
„Wie sich herausstellte, gab es einen Fehler im Rosetta-Emulator, der zu mehreren ungewöhnlichen Anomalien im Verhalten von JMP führte. Mit dem Unit-Test-Framework konnte ich das Problem auf einen Fehler in der Implementierung der Quadratwurzelfunktion in Rosetta eingrenzen ( siehe Defekt S0351925 ).
„Michael Hecht und ich haben mehrere Telefonkonferenzen mit Apple-Ingenieuren abgehalten, um das Problem zu erklären, aber die Ingenieure bestanden darauf, dass es sich um einen JMP-Fehler handelte. Erst als Michael mir vorschlug, eine sehr einfache C++-App zu schreiben, die im Wesentlichen einen der Unit-Tests nachahmt, die den Fehler aufzeigten, war Apple davon überzeugt, dass es sich um einen Rosetta-Fehler handelte. Ein Jahr später, im März 2007, veröffentlichte Apple einen Fix für den Rosetta-Fehler in Mac OS X 10.4.8.“
Wer profitiert?
„[Das Framework] wurde für Tester entwickelt, hat sich aber auch für Entwickler als nützlich erwiesen“, sagt Nicole. „Ich schätze Josephs Fähigkeit, ein Framework zu erstellen, das die Bedürfnisse so vieler von uns erfüllen kann.“
Tester in Cary und Peking teilen Funktionen auf und überwachen bestimmte Bereiche von JMP. Doch egal, für welchen Teil von JMP sie verantwortlich sind, im Grunde testet jeder auch die Skriptsprache.
Audrey sagt: „Je mehr wir JMP und JSL verwenden, desto mehr denken wir über ‚Nice-to-haves‘ nach. Auch wenn wir nicht diejenigen sind, die Dinge implementieren, sind wir manchmal diejenigen, die fragen: ‚Können Sie bitte dies oder das hinzufügen?‘“
Und die ständige Verbesserung kommt natürlich den Kunden zugute.
„Unsere erfahrenen JSL-Benutzer möchten vielleicht einige der Dinge tun, die wir tun. Das regt uns dazu an, darüber nachzudenken, wie wir Skripte robuster erstellen können.“
Viele der hinzugefügten Schnickschnack-Elemente wurden per Crowdsourcing aus den Bereichen Entwicklung, Test und Release Engineering zusammengetragen.
Ein großes Lob an die wichtigsten Akteure, die im Laufe der Jahre Funktionen hinzugefügt haben:
Joseph Morgan @joseph_morgan
Melanie Drake @Melanie_J_Drake
Jim Borek
Markus Schröder @MarkusSchröder
Michael Hecht @hecht_jmp
Justin Chilton @Justin_Chilton
Evan McCorkle @EvanMcCorkle
Nick Holmes @nickholmes13
Dies ist nur eines von vielen Beispielen für den Einfallsreichtum, die Zusammenarbeit und das Engagement der JMP-Abteilung für kontinuierliche Verbesserung. Wir hoffen, noch mehr Geschichten wie diese hervorheben zu können. Wenden Sie sich mit Ideen an Jessica Marquardt.
Lust auf mehr?
JMP-Test-Dashboard
Dieser Artikel im China R&D Newsletter von Test Engineering Manager Nala Sun ( @Nala ) diente als Inspiration für diesen Beitrag: Automatisierungsframework für JSL-Unit-Tests
So werden JSL-Unit-Testergebnisse ausgegeben, verarbeitet und für die nächtlichen Unit-Testläufe verwendet: JSL Framework Data Pipeline
Ein Artikel von Joseph Morgan: JSL-Einheit: Automatisiertes JSL-Testen
Orso, Alessandro und Gregg Rothermel. „Softwaretests: ein Forschungsreisebericht (2000–2014).“ Future of Software Engineering Proceedings. 2014. 117-132.
Alex Orsos professionelle Seite: https://www.cc.gatech.edu/home/orso/
Und danke an @shannon_conners für die Hintergrundinformationen und Anleitung.
