Wie ich bereits im letzten Teil sagte , sind bei der Entwicklung eines IoT-Projekts die Protokolle für die Interaktion mit Geräten ziemlich instabil, und die Wahrscheinlichkeit, nach dem Aktualisieren der Firmware den Kontakt zu Testgeräten zu verlieren, war ziemlich groß. An der Entwicklung waren mehrere Teams beteiligt, und es bestand eine strikte Anforderung, die Fähigkeit zum Testen der Geschäftsschicht der Anwendung nicht zu verlieren, selbst wenn das Flashen der Geräte den gesamten Arbeitsfluss mit Sensoren unterbricht.
Damit Geschäftsanalysten ihre Hypothesen an Daten testen können, die der Realität mehr oder weniger ähnlich sind, haben wir ein Simulationsmodell des Geräts erstellt. Wenn das Gerät aufgrund einer neuen Firmware ausfiel und die Daten dringend empfangen werden mussten, haben wir ein Simulationsmodell anstelle eines realen Geräts im Netzwerk gestartet, das die Daten im alten Format verfolgte und das Ergebnis lieferte.Der Vorteil des Modells bestand auch darin, dass das Unternehmen niemals eine große Menge von Geräten kaufen würde, nur um eine Hypothese zu testen. Das Geschäftsanalyseteam entschied beispielsweise, dass die Vorhersage der Behälterfüllzeit anders funktionieren sollte. Und um ihre Hypothese zu testen, wird niemand laufen, um 10.000 Sensoren zu kaufen.Entwicklung eines Simulationsmodells
Das Simulationsmodell selbst war wie folgt: Der
Zustand und das Verhalten der Mülltonne werden von einer regulären Zustandsmaschine beschrieben. Zuerst initialisieren wir die Zustandsmaschine mit dem Zustand "LEER (Ebene = 0)" und können einige Aktionen ausführen, dh Müll in den Container werfen. Jetzt müssen Sie entscheiden, ob der Container leer bleibt (Ebene? MAX_LEVEL) oder voll ist (Ebene> = MAX_LEVEL). Wenn der zweite, ändert sich der Status in "FULL".Jemand kann den Müll aus einem vollen Container entladen, oder der Hausmeister ist gekommen, um sein Chaos zu beseitigen, und wir müssen entscheiden, in welchen Zustand wir wechseln sollen. Der Status "CHOICE" ist für die Auswahl einer Aktion verantwortlich - in der Terminologie einer Zustandsmaschine, ähnlich einem if-Block.Ein anderer Container kann brennen, und dann ändert sich der Zustand der Zustandsmaschine in "FEUER". Außerdem kann der Container herunterfallen und sein Zustand wird zu "FALL" (in dem Bericht habe ich darüber gesprochen, welche unerwarteten Gründe das Fallenlassen von Containern verursachen können). Es gibt jedoch einen anderen "LOST" -Zustand, der von jedem anderen Zustand aus gültig ist - er wird festgelegt, wenn die Verbindung unterbrochen wird.Eine solche Zustandsmaschine beschreibt fast das gesamte Verhalten des Behälters und des darauf befindlichen Sensors. Dies reicht jedoch nicht aus, um ein Simulationsmodell zu erstellen, da wir die möglichen Zustände und Übergänge kennen, aber nicht wissen, wie wahrscheinlich diese Ereignisse sind und wann sie auftreten werden.Tatsächlich stellte sich heraus, dass die Wahrscheinlichkeit von Ereignissen von der Tageszeit abhängt, weil:- Träger arbeiten nachts nicht;
- Menschen werfen zu bestimmten Zeiten mehr Müll (morgens vor der Arbeit und abends).
Daher haben wir es dem Business Analysis Team ermöglicht, das Simulationsverhalten anzupassen. Es war möglich, die Wahrscheinlichkeit eines Ereignisses zu einer bestimmten Tageszeit einzustellen.Einfacher und intuitiver Stresstest
Nachahmung selbst hat viele Vorteile, und einer davon ist das Testen billiger Belastungen. Es ist billig, da Nachahmung in der Tat ein separater Thread ist, der die Zustandsmaschine startet, Ereignisse darauf anwendet und die Ereignisse selbst an den realen Server gesendet werden.Daher unterscheidet sich die Simulation für das Backend nicht vom realen Sensor. Und wenn wir 1000 Sensoren ausführen müssen, führen Sie 1000 Threads aus und arbeiten Sie. Darüber hinaus skaliert die Simulation perfekt.
Einerseits ist es ziemlich unhöflich, die Last zu testen, andererseits ermöglichte die Simulation, viele Daten für das gesamte Projekt realitätsnah zu steuern. Und vergessen Sie nicht begabte chinesische Entwickler, die Standardprotokolle wie MQTT ignorierten und ihr Protokoll auf Sockets absägten. Daher mussten wir unsere eigene Implementierung eines Servers durchführen, der Daten auf Sockets unter diesem proprietären Protokoll akzeptiert.Ein solcher Server musste Multithreading sein, da es viele Eingangssensoren gibt. und dieser Teil muss auch separat unter Verwendung von Leistungstests getestet werden. Sie können JMeter (ein typisches Testskript schreiben), JMH / JCStress (einzelne Teile testen und einen dünneren Benchmark erstellen) oder etwas anderes nehmen. Wenn Sie in einer ähnlichen Situation eine Entscheidung treffen, empfehle ich Ihnen, Fachleuten zuzuhören, zum Beispiel Alexei Shipilev. Bei JPoint 2017 sprach er sehr cool darüber, wie man verschiedene Dinge bewertet und woran man denken muss, wenn man Leistungstests durchführt.Wir haben uns für die Option entschieden, etwas Eigenes zu tun, da das Projekt einen atypischen Ansatz für die Qualitätssicherung hatte - wir haben kein separates Testerteam, und das Backend-Team selbst hat die Funktionalität getestet. Das heißt, die Person, die den Socket-Server geschrieben hat, musste den Code mit normalen Einheiten, Integrations- und Leistungstests abdecken.Wir hatten ein kleines Tool, mit dem wir das Lastszenario schnell beschreiben und in der richtigen Anzahl paralleler Threads ausführen konnten:StressTestRunner.test()
.mode(ExecutionMode.EXECUTOR_MODE)
.threads(THREADS_COUNT)
.iterations(MESSAGES_COUNT)
.timeout(5, TimeUnit.SECONDS)
.run(() -> sensor.send(MESSAGE));
Awaitility.await()
.atMost(5, TimeUnit.SECONDS)
.untilAsserted(() ->
verifyReceived(MESSAGES_COUNT)
);
Wir geben an, wie viele Threads Sie ausführen müssen, wie viele Nachrichten gesendet werden müssen, wie lange es dauern sollte und senden Daten an den Socket in jedem Thread. Es bleibt nur zu warten, bis unser Server alle diese Daten korrekt verarbeitet hat. Es wurden nur wenige Codezeilen veröffentlicht, die von jedem Backend-Entwickler geschrieben werden können.Emulation von Netzwerkproblemen
Mit Hilfe der Nachahmung konnten wir sowohl minderwertige als auch spezifische Arbeiten mit Steckdosen simulieren. GSM-SIM-Karten in den Sensoren haben keine „weißen“ IP-Adressen, und wir können 50 Mal am Tag Daten von verschiedenen IPs empfangen. Und es kam oft vor, dass die Verbindung geöffnet wurde, wir begannen, Daten zu übertragen, dann änderte sich die IP-Adresse und der Server öffnete eine neue Verbindung, ohne die alte zu schließen. Wenn wir dies nicht berücksichtigen würden, würden uns in ein paar Tagen die freien Ports auf dem Server ausgehen.
Es gab auch ein Problem mit verschiedenen Geschwindigkeitssensoren. Ein langsames Gerät kann eine Verbindung öffnen und für eine Weile einfrieren, während ein schnelles Gerät etwas sendet. Und das alles muss richtig verarbeitet werden. Bei der Nachahmung ist es einfach, eine ähnliche Situation mithilfe von Pausen zu simulieren.
Dies ist nur ein Teil der Szenarien, die in das Modell integriert werden können.Ergebnisse
Es scheint mir, dass genau die Möglichkeit der Simulation das Internet der Dinge stark von anderen Projekten unterscheidet. Das Simulieren des Geräteverhaltens ist einfacher als menschliches Verhalten. Bei der Eingabe erhalten wir deterministische Werte, die gut mit unserem Modell korrelieren, und keine zufälligen menschlichen Handlungen. Weil das Verhalten von Geräten logisch einfacher zu beschreiben ist als das Verhalten von Personen, und das Testen des Systems einfacher wird.Wir haben uns einige verschiedene Aspekte der Entwicklung im Internet der Dinge angesehen.
Wenn Sie die beiden vorherigen Teile dieses Artikels übersprungen haben, finden Sie sie hier:IoT, auf das Sie nicht gewartet haben (Teil 1) - Der Themenbereich und die Probleme desIoT, auf die Sie nicht gewartet haben (Teil 2) - Anwendungsarchitektur und IoT-Tests bestimmter DingeGithub mit den fraglichen Testwerkzeugen.. , Heisenbug , IoT. , ! JPoint, . Heisenbug JPoint 6 . !