Um das Offensichtliche zu sagen: Nicht alle von uns können in Forschung und Entwicklung arbeiten. Aber wir können immer noch etwas von der Fachsprache lernen. Hier ist ein Satz: JSL Unit Testing Framework. Was ist es? Wie kam es dazu? Und warum ist es wichtig?
Lassen Sie uns das JSL Unit Testing Framework entmystifizieren.
Danke an Nicole Jones ( @Nicole_Jones ), Sr. Manager of Advanced Analytics Testing, für diese Erklärung:
"Der Begriff Einheit bezieht sich auf die kleinste testbare Komponente eines Softwareprodukts und die Phrase Unit-Tests ist der Prozess der Validierung, um sicherzustellen, dass die Einheiten wie erwartet funktionieren. Der Satz Unit-Testing-Framework bezieht sich auf den Mechanismus, der verwendet wird, um automatisierte Komponententests zu erleichtern.“
Leitender Forschungsstatistiker Joseph Morgan ( @Joseph Morgan ) führte diese Begriffe bei JMP ein, als er 2005 anfing, als Statistical Tester zu arbeiten. (Er arbeitet jetzt in der DOE-Gruppe.) Josephs Hintergrund liegt in Softwareentwicklung und Informatik sowie diskreter Mathematik und Statistik.
„Er konzipierte das gesamte Konzept, ein zentrales Test-Framework“, sagt Sr. Manager of Test Engineering Audrey Shull ( @Audrey_Shull ). „Er hat viele große Ideen, und das war eine davon.“
„Sobald er sich mit JMP und JSL vertraut gemacht hatte, konnte er das JSL-Komponententest-Framework entwickeln und dabei die statistische Natur der Software berücksichtigen“, sagt Nicole.
Joseph Morgan erklärt (4:38)
„Unseren eigenen Champagner trinken“
Ein Unit-Testing-Framework kann in anderen Sprachen geschrieben werden, aber welches Tool wäre besser als unser eigenes JSL?
Mit dem JSL Unit Testing 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 tun kann, um das Framework zu unterstützen. Das ist etwas ganz Besonderes. Und das Framework selbst dient als riesiger Regressionstest für die JSL-Abwärtskompatibilität.
„Wenn das Entwicklungsteam die Funktionsweise von Skripten ändert, findet die Testgruppe es zuerst, weil wir der erste Kunde der JSL-Sprache sind.
„Alle Unternehmen versuchen, Automatisierung zu nutzen, aber oft verwenden sie dafür andere Tools von Drittanbietern. Sie werden nicht immer den Luxus haben, ihre eigene Software zu verwenden."
Ein erweiterbarer Rahmen
A screenshot of the original dialog.Ein Screenshot des ursprünglichen Dialogs. Das JSL Unit Testing Framework wird auf allen JMP-Plattformen verwendet. Beispielsweise kann es verwendet werden, um die Drag-and-Drop-Funktionalität im Graph Builder zu testen. Oder die roten Dreiecksmenüs. Oder eine beliebige Codeeinheit in der Distributionsplattform.
„Wir können es nicht nur zum Testen von JSL selbst verwenden, sondern wir können das Framework auch zum Testen aller anderen Plattformen verwenden“, sagt Audrey.
Nicole führt aus:
„Als Joseph das Framework entwickelte, lag sein Hauptaugenmerk darauf, einen Weg zu finden, eine Regressionstestsuite für die Statistikplattformen in JMP zu erstellen. Dennoch war er in der Lage, ein erweiterbares Framework zu erstellen – die Regressionstestsuite umfasst sowohl Statistikplattformen als auch Grafikplattformen, sie funktioniert sowohl auf Macintosh als auch auf Windows, sie testet Datentabellenbefehle sowie Berichtsstrukturen.“
Arbeiten mit „einem Sicherheitsnetz“
Das Framework kann manuell ausgeführt werden – Tester und Entwickler können es starten, darauf zeigen und klicken und ausführen. Automatisierung ist jedoch der Schlüssel zur kontinuierlichen Verbesserung.
Das Framework wird durch Perforce (ein Arbeitsspeicher) automatisiert, wo die Arbeit der Entwickler lebt, wo Code implementiert wird. JMP-Tester schreiben Testfälle und laden sie in einen speziellen 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 von Principal Systems Developer 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 auf 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 die Ungeheuerlichkeit der stattfindenden Tests: 2,4 Millionen Tests werden jede Nacht durchgeführt. Und das passiert auf jedem Betriebssystem (z. B. Windows, Catalina, BigSur) sowohl für JMP 17 als auch für JMP 16.2. Der Vorgang zum Ausführen der Tests auf einer einzelnen Maschine dauert 6-10 Stunden, je nachdem, wie schnell die Maschinen laufen.
„Das ist die Regressionstest-Suite – ohne dieses Framework müssten wir diese Dinge jeden Tag testen, um zu sehen, ob sie kaputt gehen oder nicht“, sagt Audrey. „Es kann nicht manuell sein. Die Reihe von Tests ist automatisiert, sodass das System uns benachrichtigt, wenn ein Fehler aufgetreten ist.
„Wir nennen es manchmal gerne ein Sicherheitsnetz. Ich weiß, dass es das letzte Mal funktioniert hat, als ich es getestet habe, ich habe einen Testfall geschrieben, und wenn es kaputt geht, lässt es mich das System wissen. Ich kann mich anderen Dingen zuwenden. Wir versuchen zu testen, was neu ist, kommt und zur Software hinzugefügt wird.“
Der JSL-Test-Framework-Workflow
Finden eines Apple-Bugs
Joseph erzählt eine frühe Anekdote, die den Wert des Unit-Testing-Frameworks festigte.
„Kurz nachdem die anfängliche Implementierung des JSL Unit Testing Frameworks in Betrieb genommen wurde, wurde sein Wert auf ziemlich ungewöhnliche Weise dramatisch deutlich. Interessanterweise war es keine Regression von JMP, die es entdeckte, sondern es war der Schlüssel zur Isolierung eines ziemlich schwerwiegenden Fehlers in MacOS.
„Anfang 2006 begann Apple damit, die Macintosh-Reihe von PowerPC-CPUs auf Intel-CPUs umzustellen, und um diesen Übergang zu unterstützen, bündelte es einen Emulator mit MacOS namens Rosetta. 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-Testing-Framework konnte ich das Problem auf einen Fehler in der Implementierung der Quadratwurzelfunktion in Rosetta ( siehe Fehler S0351925 ).
„Michael Hecht und ich hatten mehrere Telefonkonferenzen mit Apple-Ingenieuren, um das Problem zu erklären, aber die Ingenieure bestanden darauf, dass es sich um einen JMP-Bug handelte. Erst als Michael mir vorschlug, eine sehr einfache C++-App zu schreiben, die im Wesentlichen einen der Komponententests nachahmte, 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 eine Korrektur für den Rosetta-Fehler in Mac OS X 10.4.8.“
Wer profitiert?
„[Das Framework] wurde mit Blick auf Tester entwickelt, hat sich aber auch als nützlich für Entwickler erwiesen“, sagt Nicole. „Ich schätze Josephs Fähigkeit, einen Rahmen zu schaffen, der den Bedürfnissen so vieler von uns gerecht wird.“
Tester in Cary und Peking verteilen Funktionen und überwachen bestimmte Bereiche von JMP. Aber egal für welchen Teil von JMP sie für das Testen verantwortlich sind, jeder testet im Wesentlichen auch die Skriptsprache.
Audrey sagt: „Je mehr wir JMP und JSL verwenden, desto mehr denken wir an „nice-to-haves“. 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 Power-JSL-Benutzer möchten vielleicht einige der Dinge tun, die wir tun. Es veranlasst uns, darüber nachzudenken, wie wir robustere Skripte erstellen können.“
Viele Schnickschnack, die hinzugefügt wurden, wurden aus der Entwicklung, dem Testen und dem Release-Engineering-Team gesammelt.
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
Xan Gregg @XanGregg
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, weitere Geschichten wie diese hervorheben zu können. Wenden Sie sich mit Ideen an Jessica Marquardt.
Möchten Sie weitere Informationen?
JMP-Test-Dashboard
Dieser Artikel des China R&D Newsletter von Test Engineering Manager Nala Sun ( @Nala ) hat mich zu diesem Beitrag inspiriert: Automatisierungsframework von JSL-Komponententests
So werden JSL-Unit-Testergebnisse ausgegeben, verarbeitet und für die nächtlichen Unit-Testläufe verwendet: JSL Framework-Datenpipeline
Ein Artikel von Joseph Morgan: JSL-Einheit: Automatisiertes JSL-Testen
Orso, Alessandro und Gregg Rothermel. „Softwaretest: ein Forschungsreisebericht (2000–2014).“ Zukunft des Software-Engineering-Verfahrens. 2014. 117-132.
Die berufliche Seite von Alex Orso: https://www.cc.gatech.edu/home/orso/
Und dank @shannon_conners für die Bereitstellung von Hintergrundinformationen und Anleitungen.
