1c-Szenariotest 8. Testtools für diejenigen, denen es leid tut, ihre Zeit mit Routine zu verschwenden

1C Test Center 8 ist ein spezialisiertes Softwareprodukt von 1C, mit dem Sie die Systemleistung bewerten und die Engpässe des Informationssystems untersuchen können.

Zuvor haben wir uns eine benutzerdefinierte Konfiguration angesehen. Jetzt lernen wir, wie man Szenarien für Mehrbenutzer-Konfigurationstests durch Benutzer erstellt und den Test selbst durchführt.

Das Testskript im 1C Test Center wird in einer speziell erstellten Verarbeitung geschrieben. Diese Vorlage befindet sich innerhalb der Konfiguration und hat den Namen „TCTestProcessingTemplate“. Um Ihr eigenes Testskript zu erstellen, müssen Sie diese Vorlage kopieren und darauf basierend Ihr eigenes, neues erstellen, nennen wir es „Wareneingang umbuchen“:

Fügen wir der Verarbeitung ein neues Attribut hinzu und zeigen es im Formular an – „DocumentForCopying“, das ist das Dokument, das wir kopieren werden.

Schauen wir uns das Formularmodul genauer an. Sie können darin drei Prozeduren verwenden: TCIinitialize(), TTSExecute(), Delete().

TCIinitialize – wird zum anfänglichen Ausfüllen der Infobase-Einstellungen verwendet, beispielsweise zum Ausfüllen der Rechnungslegungsrichtlinie.
TCExecute ist das Hauptmodul, in dem das Testskript direkt geschrieben wird.
TCUDeleteData ist ein Modul, das das Löschen von Objekten beschreibt, die während des Testprozesses erstellt wurden.

Schreiben wir den einfachsten Code in die Prozedur TCExecute(), die das ausgewählte Dokument fünfmal hintereinander kopiert und das Kopieren und Posten jedes Dokuments misst:

Für th=1 bis 5 Zyklus

Tools = KipExternalComponent.GetTools();
StartTime = KipExternalComponent.TimerValue(Tools);

Holen Sie sich 267 Video-Lektionen zu 1C kostenlos:

CreateDocuments();

EndTime = KipExternalComponent.TimerValue(Tools);
Ausführungsdauer = (Endzeit – Startzeit) / 1000;

TCWriteIndicator("Ausführungszeit", Ausführungsdauer);

EndCycle;

Return TCExecutionResultSuccessfully();

Die Prozedur CreateDocuments() wird auf dem Server ausgeführt:

Prozedur CreateDocuments()

NewDocument = TCObject.DocumentForCopying.Copy();
NewDocument.Date = CurrentDate();
NewDocument.Write(DocumentWriteMode.Post);

EndProzedur

Damit ist die Vorbereitung des Skripts abgeschlossen. Fahren wir mit dem Testcenter fort, um Lasttests durchzuführen.

Einrichten des 1C Test Center 8.3

Nachdem wir die Tests geschrieben haben, beginnen wir mit der Einrichtung des Testcenters selbst. Zur Konfiguration müssen Sie eine Reihe von Nachschlagewerken ausfüllen:

Behandlungen– ein Verzeichnis, das eine Liste der mit dem Testen verbundenen Prozesse enthält. Die Verarbeitung kann sowohl intern als auch extern erfolgen.
Rollen– ein Verzeichnis zum Speichern des Verarbeitungs-Verarbeitungseinstellungen-Links. Bei den Einstellungen handelt es sich um Daten, die für jeden Test individuell sind (Anzahl der Iterationen, kopiertes Dokument usw.).
Benutzer— Liste der Benutzer und ihrer Passwörter.
Computers— eine Liste der Computer, auf denen der Test durchgeführt wird.
Kunden - Festlegen, wo, von wem und in welchem Modus Lasttests gestartet werden.

Testszenarien

Das Hauptnachschlagewerk, das alle Einstellungen konsolidiert: Wie oft, von welchem Benutzer, unter welchem Namen werden Lasttests durchgeführt?

Außerdem können Sie auf der Registerkarte „Parameter“ ein technisches Testszenario konfigurieren:

Nachdem Sie das Skript eingerichtet haben, müssen Sie es nur noch starten.

Beginnen Sie mit dem Testen in 1C: Test Center

Wenn alles fertig ist, müssen Sie nur noch mit dem Testauftrag beginnen.

Dazu müssen Sie mindestens zwei Sitzungen des Programms starten: die erste – in der Rolle des sogenannten. „Agent“ und der zweite als Initiator des Skriptstarts.

Starten des Agenten:

Ausführen des Skripts:

Zum Ausführen wählen Sie einfach das gewünschte Skript aus der Liste aus und klicken auf die Schaltfläche „Ausführen“.

1C hat eine Testversion der Anwendungslösung „Scenario Testing“ veröffentlicht (siehe http://www.1c.ru/news/info.jsp?id=8893)

Tatsächlich handelt es sich hierbei um ein Funktionstestsystem für Konfigurationen auf der 8.1-Plattform.

Es besteht aus zwei externen Prozessen „RecordTests.epf“ und „RunTests.epf“.

Tests werden als XML-Dateien gespeichert.

Eigenschaften von „1C: Szenariotest 8“

Hauptmerkmale

Mit „1C: Scenario Testing 8“ können Sie Tests schreiben und ausführen, um die Funktionalität jeder Konfiguration des „1C: Enterprise 8“-Systems zu überprüfen. Das Tool besteht aus zwei externen Behandlungen. Eine Verarbeitung dient der Aufzeichnung des Tests, die zweite Verarbeitung dient der Durchführung des Tests. Der aufgezeichnete Test kann entweder manuell oder automatisch durchgeführt werden.
Um Tests mit diesem Tool zu entwickeln, sind keine Kenntnisse über die Funktionsweise der zu testenden Konfiguration auf Benutzerebene erforderlich.
Ein Test ist eine Reihe von Aktionen, die der Benutzer in einem Programm ausführen muss. Dies können beispielsweise Aktionen sein, das Erstellen neuer Elemente von Verzeichnissen, Dokumenten, das Ausfüllen von Daten in einem Formular oder das Drücken von Schaltflächen. Wenn ein solcher Test automatisch ausgeführt wird, wird die Arbeit des Benutzers bei der Eingabe von Informationen simuliert. Wichtig ist, dass die Ausführung von Testbefehlen zum interaktiven Erstellen von Objekten und Ausfüllen von Formularen von der 1C:Enterprise 8-Plattform genauso verarbeitet wird, als ob der Benutzer diese Daten über die Tastatur eingegeben hätte.
Ein ähnliches Testprinzip existiert in anderen Programmen, aber im Gegensatz zu diesen implementiert dieses Tool Testentwicklungsfunktionen, die die Besonderheiten des Testens von 1C:Enterprise 8-Konfigurationen widerspiegeln. Zu diesen Möglichkeiten gehören:

Erstellen von Vorlagen zum Ausfüllen von Formularen für verschiedene Konfigurationsobjekte (sie können angepasst und für verschiedene Tests derselben Konfiguration verwendet werden);

Analyse, welche Objekte in der Referenzkonfigurationsbasis welchen Testschritten zugeordnet sind;

Analyse der Korrektheit des aufgezeichneten Tests vor seiner Durchführung;

die Möglichkeit, den Fehler beim Ausführen eines automatisierten Tests manuell zu umgehen und den Test im automatischen Modus weiter auszuführen;

automatischer Vergleich von Dokumentenbewegungen mit Referenzdatenbankdaten;

erforderlicher Vergleich der durch den Test erstellten Objekte mit den Daten der Referenzdatenbank;

die Möglichkeit, Schritte beim Aufzeichnen eines Tests zu debuggen;

Analyse der Testabdeckung von Konfigurationsobjekten.

Zur Durchführung des Tests ist keine besondere Vorbereitung der zu testenden Konfiguration erforderlich.

Verwendung von 1C: Szenariotest 8

Im selben Test können Sie Schritte erstellen, um verschiedene Geschäftstransaktionen zu testen. Die Logik des Tests wird laut Benutzerdokumentation durch die Regeln zur Abbildung von Geschäftsvorfällen im Programm beschrieben. Somit kann das Tool zum Szenario- oder Funktionstest von Konfigurationen eingesetzt werden.
Die Notwendigkeit einer solchen Prüfung entsteht, wenn sichergestellt werden muss, dass bei einer Änderung der Konfigurationsfunktionalität oder der Behebung von Fehlern die unverändert gebliebene Konfigurationsfunktionalität betriebsbereit bleibt. Dies ist vor allem in den Organisationen gefragt, in denen die Entwicklung neuer Konfigurationsversionen, deren Tests und Veröffentlichung iterativ erfolgen. In diesem Fall sind die Kosten für das Schreiben von Tests und deren weitere automatisierte Ausführung geringer als beim manuellen Regressionstest für jede neue Konfigurationsversion.
In der Regel werden solche Tests für die von Benutzern am häufigsten verwendeten Szenarien für die Arbeit mit einer Anwendungslösung geschrieben und auf jeder neuen Version der geänderten Konfiguration oder Plattform ausgeführt. Tests können komplexer oder weniger komplex gestaltet werden, je nachdem, wie kritisch die Fehler in einer bestimmten Funktionalität der Anwendungslösung sind und wie viel Zeit die Organisation bereit ist, für Tests aufzuwenden.
„1C: Szenariotest 8“ kann verwendet werden von:

Partner – Entwickler von Zirkulationslösungen;

Partner oder Benutzer, die die Aufgabe haben, die Konfiguration zu testen, bevor sie die Arbeitsdatenbank aktualisieren.

Kaufen

Zeile aus der 1C-Preisliste vom 05.01.2010

Produktzusammensetzung und Verkaufsablauf
Das Softwareprodukt 2900000998513 „1C: Szenariotest 8 NFR“ umfasst:

Verarbeitung zur Vorbereitung und Durchführung von Tests;

eine Reihe von Tests für typische Konfigurationen von „1C:Enterprise 8“;

Meldebescheinigung;

Dokumentationsbuch „1C: Scenario Testing 8. Benutzerhandbuch“.

Das Produkt 2900000998513 „1C: Scenario Testing 8 NFR“ wird in Anträgen zum Kauf von NFR-Produkten, ein Set pro Organisation, an Franchisenehmer verkauft, die mindestens einen Spezialisten für die Plattform oder für eine beliebige Anwendungslösung „1C: Enterprise 8“ im Personal haben ". Damit das Produkt funktioniert, muss der Partner über eine NFR-Lieferung verfügen, einschließlich der 1C:Enterprise 8-Plattform und eines Sicherheitsschlüssels.
Das Produkt 4601546061393 „1C: Scenario Testing 8“ wird an Benutzer von Softwareprodukten der PROF-Version „1C:Enterprise 8“ über Franchisepartner verkauft, die mindestens einen Spezialisten für die Plattform oder eine beliebige Anwendungslösung „1C:Enterprise 8“ haben.
Zweck und Nutzungsbedingungen der Produkte
Das Produkt 2900000998513 „1C: Szenariotest 8 NFR“ dient der Untersuchung der Leistungsfähigkeit der vorgeschlagenen Tools durch Partner, der uneingeschränkten Nutzung in den internen Entwicklungen des Partners sowie für Implementierungsarbeiten, die für den Kunden auf dem Territorium des Partners durchgeführt werden. Mit der Lizenz können Sie das NFR-Produkt zum Testen verwenden:

eigene, zum Verkauf entwickelte Produkte;

Änderungen an Standardkonfigurationen;

im Rahmen der Arbeit zur Einführung von Produkten bei Kunden, wenn diese Arbeit im lokalen Netzwerk des Partners durchgeführt wird.

Die Lizenz erlaubt nicht, das Produkt zum Testen einer Konfiguration direkt vor Ort beim Kunden oder zum Testen einer vom Kunden oder einer anderen Organisation entwickelten und replizierten Konfiguration zu verwenden. Um solche Arbeiten durchzuführen, ist es notwendig, für den Kunden das Produkt 4601546061393 „1C: Scenario Testing 8“ zu erwerben.
Das Produkt 4601546061393 „1C: Scenario Testing 8“, das von der Organisation erworben wurde, in der die Implementierung durchgeführt wird, kann nicht zum Testen der Konfiguration in der Organisation des Partners verwendet werden, der die Implementierung durchführt. Zur Durchführung dieser Arbeiten muss der Partner das Produkt 2900000998513 „1C: Szenariotest 8 NFR“ erwerben.

Für die Entwicklung und das Debuggen eines Skripts in ST gibt es eine spezielle Verarbeitung. Die Verarbeitung kann von ST mit dem Befehl im Abschnitt „Verwaltung“ heruntergeladen werden – „Verarbeitung in Datei speichern“.

Um ein neues Skript zu entwickeln, müssen Sie „Mit der zu testenden Anwendung verbinden und ein neues Skript erstellen“ auswählen.

Um Skripte aufzuzeichnen und zu debuggen, müssen Sie zwei Datenbanksitzungen starten: „Test Manager“ (im Folgenden „MT“) und „Testing Client“ (im Folgenden „CT“).

MT steuert die CT, zeichnet Benutzeraktionen auf und ermöglicht Ihnen die Änderung des Skripts. CT wird benötigt, um das Szenario selbst zu reproduzieren und Benutzeraktionen auszuführen.

Beim Starten von CT müssen Sie die Startparameter angeben (Typ der 1C-Verbindung, Benutzer usw.):

Nachdem der CT gestartet wurde, können Sie mit der Aufzeichnung von Benutzeraktionen beginnen. Dazu binden wir einen Datensatz in die MT-Verarbeitung ein.

Sie können Aktionen im CT reproduzieren.

Klicken Sie nach Abschluss der Aktionen in CT auf Aufzeichnung in MT stoppen:

Mit dem Befehl „Aufzeichnen und schließen“ werden die aufgezeichneten Aktionen in das Skript übertragen:

Ergebnis: Mit der Konfiguration „Scenario Testing 3.0“ können Sie mit dem richtigen und geschickten Ansatz schnell und effektiv interaktive Benutzeraktionen aufzeichnen und die Skripte einfach ändern und debuggen. Um interaktive Skriptschritte zu entwickeln, müssen Sie kein qualifizierter Programmierer sein. Es reicht aus, zu wissen und zu verstehen, wie man eine vorgefertigte Lösung verwendet.

P.S.: Es ist besser, keine Skripte unter der „Taxi“-Schnittstelle auszuführen, da das Skript sonst möglicherweise nicht richtig funktioniert.

Das Thema Szenariotests wird seit langem behandelt und fast jedes Unternehmen ist sich der Notwendigkeit bewusst, TDD und BDD in einem gewissen Umfang zu nutzen. Unsere kleine Gruppe von 1C-Entwicklern war keine Ausnahme. Vom Moment des Verständnisses der Notwendigkeit bis zum tatsächlichen Einsatz der Technologie vergeht jedoch Zeit, und auf diesem Weg beginnen fragile Geister wie zum Beispiel der Autor dieses Artikels, über die Wirksamkeit dieser gesamten Idee nachzudenken. Wenn Sie daran interessiert sind, wie eine Gruppe kluger Köpfe etwas Ähnliches wie Szenariotests in ihre Arbeit eingeführt hat, sind Sie herzlich willkommen.

Hintergrund

Es gibt sehr leistungsstarke und ausgereifte UI-Testtools auf dem Markt. Es gibt spezielle Sprachen zur Beschreibung von Skripten, viele Dokumentationen und Methoden. Mit anderen Worten: „Gibt es ein Problem? Es gibt eine Lösung!“

Andererseits muss die Energie, die für die Lösung eines Problems aufgewendet wird, irgendwie mit der Energie übereinstimmen, die das Team als Ganzes produziert. Aber in der Praxis: Wenn große Unternehmen es sich leisten können, einzelne QA-Spezialisten und Tester im Personal zu behalten und die Prozesse vollständig zu entwickeln, sind kleine Büros dazu nicht immer in der Lage, einige der Funktionen müssen zugewiesen werden selbst, und die Philosophie des Prozesses selbst ist leicht verzerrt.

Gegeben ist also: eine geografisch verteilte Gruppe von 1C-Entwicklern von bis zu 10 Personen, durchschnittlich bis zu 5 aktive Projekte, hauptsächlich die Entwicklung kundenspezifischer Lösungen ohne Verwendung von Standard-1C-Produkten.

Ziel: Entwicklungstestprozesse so effizient wie möglich implementieren, einschließlich des Testens der Funktionsweise der Schnittstelle und der Geschäftslogik. Unter Effizienz versteht man das Gleichgewicht, bei dem die für das Testen aufgewendete Zeit im Hinblick auf das Endergebnis noch sinnvoll ist. Ich gebe zu, dass diese Aussage sehr subjektiv ist und vielleicht den Ausdruck „ein Versuch, warm mit weich zu vergleichen“ völlig rechtfertigt. Ich denke, der Leser weiß noch besser als der Autor, welchen Zweck das Testen von Szenarios als solches erfüllt.

Nachdem wir eine Reihe von Toolsystemen westlicher Anbieter sowie Szenariotests von 1C Version 3.0 und xUnitFor1C untersucht hatten, schien es, dass wir geistig noch nicht reif genug waren, um diese Technologien zu implementieren. Die Zeit ist vergangen, aber wir können immer noch nicht erwachsen werden. Gleichzeitig verlangte mein Bauch immer wieder nach einer Lösung.

Auf der Grundlage alter Aufzeichnungen wurde noch einmal eine Liste mit Anforderungen an ein potenzielles Softwareprodukt erstellt:

Die Lösung muss cloudbasiert sein
Die Testdatenbank für alle Entwicklungen muss einheitlich sein
Es muss eine Zugriffskontrolle auf Anwendungen geben (jeder Programmierer hat seinen eigenen Entwicklungspool)
Die Testentwicklung und -ausführung sollte in einer IDE erfolgen
Skripte sollten programmiert und nicht durch Benutzeraktionen aufgezeichnet werden
Es ist wünschenswert, dass die Testprogrammiersprache der 1C-Sprache ähnelt
Tests sollten mit einem Knopfdruck gestartet werden, ohne vorherige Manipulationen, Zusammenstellungen, Assemblierungen, Uploads, Downloads usw.
Beim Schreiben eines Tests sollte es möglich sein, die Struktur von Fenstern und Details der zu testenden Anwendung im Hinblick auf das verwaltete 1C-Schnittstellenmodell zu analysieren, und zwar in dem Programm, in dem der Test selbst entwickelt wird. Es sollte möglich sein, die Eigenschaften der Felder der zu testenden Anwendung abzurufen, wenn man den Steuerbaum der Testbasis durchläuft – die zu testende Anwendung sollte antworten und anzeigen, wo sich dieses Steuerelement befindet.
Eine Referenzbasis sollte nicht zum Testen der Geschäftslogik verwendet werden
Um einen Test zu entwickeln, sollte keine speziell vorbereitete Basis vorhanden sein; alle Tests sollten in der Lage sein, alles, was sie benötigen, selbst zu erstellen

Natürlich ist die Liste bei weitem nicht vollständig und in anderen Softwareprodukten in gewissem Maße vorhanden. Es mag wie jugendlicher Maximalismus erscheinen, aber nur wenn alle diese Bedingungen in einem Produkt erfüllt wären, hätten wir es für möglich gehalten, Szenariotests in unserer Situation einzuführen. Kollegen sind vielleicht anderer Meinung als ich, aber ich bin der Meinung, dass eine der Schlüsselfragen bei der Qualität und Quantität von Tests als solchen darin besteht, wie schnell und bequem diese Tests während der kontinuierlichen Entwicklung der Anwendung durchgeführt werden können.

Wahrscheinlich vergingen weitere sechs Monate, und schließlich beschloss ich, in einem langsamen, optionalen Modus mit der Entwicklung des nächsten Testrads (im Folgenden Tester genannt) zu beginnen, und das ist dabei herausgekommen.

Wie sieht es aus

Als Ergebnis entstand eine 1C-basierte Anwendung, in der Szenariotests für 1C-basierte Lösungen geschrieben und ausgeführt werden. Der tägliche Einsatz sieht etwa so aus: Der Programmierer hat den Tester den ganzen Tag über auf seinem zweiten Monitor geöffnet. In der Projektabrechnungsdatenbank gibt der Manager einen obligatorischen Satz von Tests an, die das Projekt abdecken müssen.

Darüber hinaus gibt es eine Reihe standardmäßiger, obligatorischer Tests, die der Programmierer für jede Aufgabe durchführen muss. Wenn beispielsweise ein Dokument auf Grundlage erfasst wird, muss eine Prüfung auf Grundlage der Eingabe erfolgen. Mit anderen Worten: Der Programmierer weiß, welche Tests erstellt werden sollen.

Wann werden Tests geschrieben?

In der Praxis erfolgt das Schreiben von Tests in der Hälfte der Fälle während des Entwicklungsprozesses (sehr praktisch für die Automatisierung von Routinen, wenn Sie bei jedem Neustart der Anwendung dieselben Aktionen wiederholen müssen). In der anderen Hälfte - danach. Wie ein erfahrener Leser wahrscheinlich bemerkt hat, kann man diese Situation kaum als klassische BDD bezeichnen.

Beispieltest

Nehmen wir an, es gibt ein Projekt „Ein Dokument entwickeln, einen Bausatz zusammenstellen“. Dieses Dokument erfordert ein Listenformular mit einem Lagerfilter. Das allgemeine Konzept der Funktionsweise von Listen in der betrachteten Lösung wird wie folgt übernommen: Wenn ein Filter installiert ist, ist es zusätzlich zur Auswahl von Dokumenten nach Filterwert erforderlich, dass der Auswahlwert als Standardwert bei der Eingabe eines neuen Dokuments dient diese Form. Wenn also ein Lager installiert ist, sollte es automatisch installiert werden, wenn ein neuer Beleg erfasst wird.

Nur auf den ersten Blick scheint es, dass für ein solches Szenario kein Test nötig ist, allerdings kann das Feld Lager aufgrund der vielfältigen Möglichkeiten zur Dokumentenerfassung unterschiedliche Werte annehmen. Schließlich kann das Dokument kopiert werden, oder der Benutzer hat in den Standardeinstellungen ein anderes Unternehmen angegeben und das im Filter ausgewählte Lager ist nicht seine Organisationseinheit. So oder so wird der Test so aussehen (wir haben Ausländer in unserem Team, daher ist der Tester selbst auf Englisch verfasst und die betreffende Anwendungslösung ist für amerikanische Kunden gedacht):

Oben steht die zu entwickelnde Anwendung, unten der Tester, im Thin-Client-Modus die Testdatenbank in der Cloud. Der angezeigte Code ist in der 1C-Sprache geschrieben. Der Skriptcode interagiert mit der laufenden Clientanwendung über Methoden-Wrapper der getesteten 1C-Anwendung. So sieht beispielsweise die Methode Choose (...) aus;

Ich habe versucht, fast alle Schnittstellenoperationen im Tester zu implementieren, aber selbst wenn Sie etwas Bestimmtes benötigen, können Sie jederzeit das Objekt des zu testenden Felds abrufen und darauf alle im Modell der zu testenden Anwendung implementierten Methoden ausführen.

Kommen wir zu interessanteren Szenarien.

Testbeziehung

Um ein Szenario zum Erstellen und Buchen eines Montagedokuments wie im vorherigen Beispiel zu entwickeln, müssen wir über viele zusätzliche Daten verfügen: die erforderliche Zusammensetzung der Verzeichnisse, verbleibende Materialien im Lager, was zumindest das Vorhandensein einiger davon bedeutet Art der Ankunft im Lager. Wie ich bereits sagte, haben wir selbst entschieden, dass Tests unter Bedingungen durchgeführt werden sollten, in denen es keine Referenzbasis gibt, sondern nur ein anfängliches Bild der Anwendung, in dem es mindestens einen Benutzer mit Administratorrechten, ausgefüllten Klassifikatoren und Standardwerten gibt für komfortable Einsteiger.

Es wird jedoch wirkungslos sein, jedes Mal ein komplettes Skript zu schreiben, das alle notwendigen Daten „nebenbei“ erstellt. Ich möchte einen parametrisierten Test entwickeln, der nicht nur weiß, wie man etwas macht, sondern auch Parameter akzeptiert. Um beispielsweise eine Quittung in der Datenbank zu erstellen, muss es einen Test geben, der diese erstellt. Und nichts hindert uns daran, diesen Test zu parametrisieren und alle notwendigen Daten darin zu übergeben, zum Beispiel, auf welches Datum wir die Ankunft festlegen sollen, in welches Lager wir gehen sollen und welche Materialien/Dienstleistungen wir erhalten sollen. Der Test zum Erstellen einer Quittung wiederum verwendet Tests zum Erstellen eines Lagers, Materialien, die in den Parametern Art der Verpackung, Typ, Umrechnungsfaktoren usw. erwartet werden.

Da unsere Anwendung cloudbasiert ist und die Testbasis einheitlich ist, kann jeder Programmierer bei der Entwicklung eines bestimmten Tests, während er direkt einen Test für etwas schreibt, ihn parametrisieren und ihn für die breite Nutzung durch andere Programmierer öffnen.

Hier ist ein Beispiel, wie der Assembling-Erstellungstest auf die Zulassung vorbereitet wird:

(Preise, Summen und Mengen werden als Zeichenfolgen angegeben, um Probleme mit falsch positiven Ergebnissen der Testprüfung zu vermeiden, wenn sie in einem anderen Gebietsschema ausgeführt wird, wo beispielsweise die Triade und das Bruchtrennzeichen unterschiedlich sein können.)

Im Zuge der Durchführung dieses Tests werden eine Reihe weiterer Tests durchgeführt, die alles Notwendige schaffen, um Assembling als solches testen zu können. Das Ergebnis wird in der Datenbank ungefähr so aussehen:

Geschäftslogik testen

Abgesehen davon, dass alle Schaltflächen angeklickt und die Felder ausgewählt wurden, hätte das Testereignis eine tiefe Narbe in meinem Herzen hinterlassen, wenn ich nicht die Ergebnisse der Dogetestet und die aktuelle Abrechnungssituation in der Datenbank beurteilt hätte.

Ich muss zugeben, dass ich mir lange den Kopf zerbrochen habe, wie ich das am besten so umsetzen kann, dass es ohne Referenzbasis einfach und unkompliziert ist. Mir ist nichts Besseres eingefallen, als einfach Dokumentbewegungen in Verbindung mit Berichtstests zu überprüfen.

Hier ist ein Beispiel für einen Bericht über Dokumentbewegungen in der getesteten Anwendung:

So prüft der Tester diese Bewegungen:

Rote Bereiche müssen unbedingt überprüft werden. Zusätzlich zu den Bereichen kann der Tester anhand einer Vorlage zu prüfende Felder festlegen.

Standardprüfungen

Oftmals stellt sich die Aufgabe, gleichartige Objekte zu prüfen. Beispielsweise haben Dokumentformulare in der Hälfte der Fälle einen tabellarischen Teil und es kommt häufig zu Programmfehlern beim Kopieren von Zeilen, beim Löschen der ersten Zeile oder beim Eingeben und Verweigern der Eingabe der ersten/weiteren Zeilen. Zu diesem Zweck ist es möglich, eine Testmethode zu entwickeln, die über kein eigenständiges Skript verfügt, sondern nur für den lokalen Aufruf verwendet wird. Dies ist sehr praktisch, da solche Tests im Laufe der Zeit durch das Hinzufügen anderer Testelemente erweitert werden können, was aufgrund der weit verbreiteten Verwendung solcher Tests eine automatische Erweiterung der Anwendungsabdeckung mit sich bringt.

Fehlerkontrolle

Es gibt mindestens drei Arten von Fehlern, die wir kontrollieren möchten. Bei der ersten Art handelt es sich um Codierungsfehler, z. B. Division durch Null oder Zugriff auf eine nicht vorhandene Eigenschaft oder Methode. Die zweite Art von Fehlern sind Fehler in der Logik. Wenn Sie beispielsweise auf eine Schaltfläche klicken, sollte das Formular geschlossen werden, dies geschieht jedoch nicht, oder wenn Sie ein Kontrollkästchen aktivieren, sollte ein Teil des Formulars unzugänglich oder unsichtbar werden. Und bei der dritten Art von Fehlern, Geschäftslogikfehlern, konnte beispielsweise beim Abschreiben von Material aus einem Lager nicht festgestellt werden, ob es in der Datenbank vorhanden ist. Alle drei Fehlerarten können im Tester herausgearbeitet werden. Beim Auslösen registriert der Tester eine Ausnahme, schreibt sie in das Protokoll und kann den Aufrufstapel beispielsweise so anzeigen:

Außerdem wurden eine Reihe von Methoden zur Behandlung von Fehlern in der Geschäftslogik implementiert. Beispielsweise möchte Ihr Test bewusst mehr Material herausschreiben und Sie möchten prüfen, ob die Nachricht richtig oder überhaupt gebildet wird.

Hier ist ein Beispiel für die Implementierung einer solchen Prüfung in einem der Tests:

Elementbaumanalyse

Der Tester kann visuelle Objekte der zu testenden Anwendung lesen. Dies ist praktisch und manchmal einfach notwendig, um ein Skript zu schreiben, insbesondere bei mehrsprachigen Lösungen, bei denen die Namen der Schaltflächen von der Sprache des Benutzers abhängen und Sie zum Entwickeln der Schnittstelle einen internen Bezeichner verwenden müssen (es sei denn natürlich, die Aufgabe besteht darin, die Syntax der Beschriftungen auf den Schaltflächen zu überprüfen. Hier ist ein Beispiel dafür, wie der Tester die gelesenen Daten darstellt:

Abschluss

Insgesamt stellte sich heraus, dass es sich um ein kleines Fahrrad handelte, das dem 1C-Programmierer helfen sollte. Als positive Eigenschaften des Programms sind zu nennen:

Der Tester ist einfach zu installieren und zu konfigurieren
Es ist zunächst mehrbenutzerfähig (Benutzer werden auch im Tester im Verwaltungssubsystem erstellt).
Zum Schreiben von Tests sind keine besonderen Kenntnisse erforderlich
Ermöglicht die Implementierung komplexer Geschäftslogikszenarien
Ermöglicht Ihnen, Tausende von Tests für verschiedene Projekte in einer Datenbank zu speichern und diese „wiederzuverwenden“. Sie können beispielsweise einen Test zum Durchsuchen eines Dokuments in einer Liste nach Nummer erstellen, der allen Projekten gemeinsam ist. Oder wenn der Kundenstamm auf der Grundlage einer Standardlösung implementiert ist, für die es bereits Tests gibt, können Sie den Kundenstamm überprüfen, indem Sie alle übergeordneten Tests sowie speziell für den Kunden entwickelte Tests aufrufen

Und vieles ist natürlich noch nicht umgesetzt:

Kein Testlaufplan
Es gibt kein erweitertes Analysesystem, keine Grafiken und keine Berichte zu Testergebnissen
Es gibt keine automatischen Mailings oder Benachrichtigungen darüber, was kaputt ist, wer es kaputt gemacht hat und warum
Es besteht kein Zusammenhang mit Repositories und Versionierung von Tests

Der Tester ist offen und kostenlos. Es wird empfohlen, ihn ab 8.3.8 auszuführen. Er funktioniert jedoch auch unter 8.3.7, wenn Sie den Kompatibilitätsmodus aktivieren. Es gibt eine kleine Hilfe darin (aus dem Internet heruntergeladen), Methoden-Wrapper sind auch auf Russisch, das dt-Buch kann hier heruntergeladen werden. Es gibt einige Beispiele für die Unternehmensbuchhaltung 3.0.

Viel Glück bei Ihren Tests, Freunde, und vielen Dank für Ihre Aufmerksamkeit!

Stichworte:

BDD
Szenariotests

Tags hinzufügen

Viele Spezialisten und einfache Benutzer von Produkten auf Basis von 1C Enterprise 8 dürften bereits von der Veröffentlichung eines neuen Softwareprodukts zum Testen beliebiger (nach offiziellen Angaben) Konfigurationen gehört haben, und es heißt 1C Scenario Testing 8. Lassen Sie mich das gleich klarstellen Das Tool wird direkt von der Firma 1C und nicht von Drittaktivisten entwickelt. Ich konnte keine Informationen zu diesem Produkt finden (abgesehen von endlosen Nachdrucken auf der 1C-Website), woraus ich schließen kann, dass es einfach nicht existiert. Und das Testprodukt selbst ist nicht leicht zu finden, zumindest für diejenigen, die keine 30.000 US-Dollar für eine Lizenz bezahlen möchten oder diese nicht bereits zusammen mit der Instrumentierung haben8. Auf die eine oder andere Weise gelang es mir nach einigem Hin und Her, dieses Instrument in die Hände zu bekommen. Und von diesem Moment an werde ich detaillierter beginnen.

Installation.

Im Moment kenne ich die folgenden offiziellen Möglichkeiten, dieses Tool zu erhalten:

a) Es ist im Lieferumfang von „1C: Corporate Tool Package 8“ enthalten.
b) Kann von der 1C-Benutzersupport-Website heruntergeladen werden.
c) Auf der ITS-Diskette war eine frühe Version vorhanden, die offenbar aus Oktober stammte.

Die Anwendung selbst wiegt etwa 2 MB, aber es ist noch zu früh, um sich zu freuen – um sie zu installieren, müssen Sie den Pfad zum Ordner mit den Vorlagen angeben. Soweit ich weiß, ist dieses Verzeichnis in den Grundkonfigurationen oder in der Testkonfiguration, die dem Programm beiliegt, verfügbar. Es sollte zuerst installiert werden (~90 MB), dann installieren wir das Dienstprogramm sicher und löschen die unnötigere Konfiguration.

Nach diesen einfachen Manipulationen erhalten wir einen Katalog mit dem Werkzeug, an dem wir interessiert sind. Das Programm selbst besteht aus zwei externen *.epf-Verarbeitungen, zusätzlich ist eine kurze Beschreibung und ein Demotest für eine von uns entfernte indikative Konfiguration beigefügt.

Lassen Sie mich klarstellen, womit ich arbeiten musste. Ich habe Version 1.2.2.1, offensichtlich nicht die primäre. Als Testkonfiguration habe ich eine Konfiguration basierend auf 1C Enterprise 8.1 verwendet.

Nachbesprechung.

Wie ich bereits erwähnt habe, besteht das Testen von 1C-Szenarien aus zwei externen Verarbeitungen: RecordTests und RunTests.

Die meisten Informationen finden Sie in der integrierten Hilfe. Allerdings hätte ich keine großen Hoffnungen darauf gesetzt; es wurde nach dem Prinzip „Lasst uns das Offensichtliche auspacken und nichts anderes“ geschrieben. Dennoch können Sie es zur allgemeinen Entwicklung lesen.

Zunächst werde ich in meinen eigenen Worten die Hauptfunktionalität dieses Tools beschreiben und dann versuchen, mich mit der Implementierung einzelner Funktionen zu befassen.

Mit 1C Scenario Testing können Sie ganz einfach automatisch Dokumente, Verzeichnisse und Register gemäß einem vorgefertigten Skript erstellen, sie mit Referenzobjekten usw. vergleichen, sowohl im visuellen Modus als auch vor den Augen des Testers verborgen. Ein Beispiel für ein typisches Szenario ist im ersten Screenshot zu sehen.

Jeder Punkt im Skript wird als Schritt bezeichnet. Im Allgemeinen ist auf den ersten Blick alles offensichtlich und einfach und leider teilweise trügerisch. Wir werden jedoch im nächsten Abschnitt auf die Fallstricke eingehen, konzentrieren uns jedoch zunächst auf die grundlegenden Funktionen.

Reis. 1 Verarbeitung von RecordTests.

Die Idee dieses Tools basiert auf dem Vergleich von Objekten in der Referenzdatenbank mit Objekten in der getesteten Datenbank. Dies ist im Hauptfenster zur Verarbeitung von RecordTests gut sichtbar, auf der linken Seite befinden sich Daten aus der Referenzdatenbank, auf der rechten Seite befinden sich Tests, die auf Daten der linken Seite basieren. Die Referenzdatenbank ist diejenige, in der der Test erstellt wurde.

Neben der Hauptfunktion des oben beschriebenen Tools gibt es noch eine Reihe weiterer, primitiverer, aber manchmal nicht weniger nützlicher. Das Tool kann beispielsweise nur zum automatischen Ausfüllen von Formularen, zum Klicken auf Schaltflächen, zum Ausfüllen von tabellarischen Teilen usw. verwendet werden; diese Schritte simulieren die Arbeit des Benutzers im interaktiven Modus. Und da die Rolle des Benutzers vom Tester übernommen wird, handelt es sich um eine Art Ad-hoc-Test im automatischen Modus.

Es gibt ein Muster typischer Schritte, die je nach Testobjekt automatisch generiert werden. Hier ist ein typisches Beispiel: Wählen Sie auf der linken Seite ein bestimmtes Dokument (Verzeichnis usw.) aus und ziehen Sie es auf die rechte Seite. Anschließend wird automatisch eine Vorlage mit typischen Schritten erstellt. Anschließend können Sie diese nach Ihren Wünschen bearbeiten.

Jeder Schritt kann in dieser Verarbeitung direkt durch Drücken von F12 ausgeführt werden. Diese Funktionalität stellt die Notwendigkeit einer zweiten Verarbeitung von RunTests in Frage; ich denke, es wäre logisch, sie in Zukunft zu kombinieren.

Reis. 2 RunTests verarbeiten.

Der fertige Test wird in ein XML-Dokument geschrieben, das wir über die RunTest-Verarbeitung in der zu testenden Datenbank öffnen und beobachten, wie bei uns alles hervorragend funktioniert.

Die Funktionalität der zweiten Verarbeitung ist nicht anders, wenn man bedenkt, dass der Lauf auch mit der ersten Verarbeitung durchgeführt werden kann. Zu den nützlichen Funktionen gehören das Führen eines Ausführungsprotokolls und das Markieren abgeschlossener Schritte.

Mit Blick auf die Zukunft möchte ich sagen, dass ich sofort überrascht war, um nicht noch einmal auf diese Verarbeitung zurückzukommen. Bei all der Vielfalt notwendiger und weniger notwendiger Optionen gab es keinen Platz für einen Testlaufmodus, der Fehler ignoriert. Das macht die Durchführung negativer Tests und Tests im Allgemeinen äußerst unangenehm. Wenn die geringste Diskrepanz auftritt, gerät unsere „automatische“ Verarbeitung in eine Betäubung.

Schauen wir uns nun die Vor- und Nachteile des Einsatzes dieses Systems im Feld an.

Nutzungsmerkmale.

Nach offiziellen Angaben soll das 1C-Szenario-Testen ein universelles Werkzeug im Hinblick auf die Kompatibilität mit verschiedenen Konfigurationen sein. Ich denke, meine Konfiguration ist ein hervorragender Prüfstand für diese Aussage.

Ich sage gleich, dass die Arbeit mit diesem Tool nicht als einfach und ruhig bezeichnet werden kann. Bei fast jedem Schritt (in jeder Hinsicht) muss man mit scheinbar offensichtlichen Dingen experimentieren.

Hier sind einige Dinge, mit denen ich zu kämpfen hatte:

Aus irgendeinem Grund gibt es bei all den verschiedenen Optionen für Testschritte keinen Schritt zum Löschen des verarbeiteten Objekts. Zuerst musste ich den Schritt „Verarbeitung“ verwenden und manuell Code schreiben, um Objekte zu löschen. Letztendlich habe ich mich entschieden, vorerst darauf zu verzichten und mit vorhandenen Daten zu arbeiten.
Einer der nützlichsten ist meiner Meinung nach der Schritt „Bewegung mit einem Standard vergleichen“. Das ist es, was gefehlt hat. Jetzt ist es möglich, alle Änderungen in Transaktionen zu verfolgen, die nicht geplant waren.
Dieser Schritt erfordert eine sehr feine Abstimmung. Beispielsweise müssen wir die Bewegung eines Dokuments über vier Register hinweg verfolgen, und jedes davon verfügt über einen eigenen Satz an Feldern und Analysen. Es gibt Werte, die sich ändern, wenn sich das Objekt ändert, und dies ist kein Fehler. Zum Beispiel ein Feld wie TimeStamp, das den Zeitpunkt der Bearbeitung des Dokuments aufzeichnet, oder die Dokumentnummer, wenn diese automatisch vergeben wird. Alle diese Momente führen zu einem Fehler beim Ausführen des Tests. Gut, dass die Entwickler dies berücksichtigt und die Möglichkeit geschaffen haben, die Prüfung für ein nicht konstantes Feld zu deaktivieren. Wir müssen nur solche Felder finden.
Allerdings gibt es auch hier einige Fallstricke. Wenn beispielsweise in meinem Schritteinstellungsformular aus irgendeinem Grund mehr als ein Register angezeigt wird, werden die Bewegungen für sie nicht angezeigt. Ich muss die zusätzlichen ausschalten und jedes Register einzeln konfigurieren.
Und was mir überhaupt nicht gefallen hat. Soweit ich nachvollziehen konnte, werden von Registern nur die Bewegungen überprüft, die im Standard stehen. Wenn es beispielsweise eine Transaktion im Standard und drei in der getesteten Datenbank gibt, treten beim Vergleich KEINE Fehler auf. Weil Das gesamte Register wird nach Einträgen mit den Referenzparametern durchsucht; wenn alles in Ordnung ist, wird das Vorhandensein weiterer Einträge zum gleichen Objekt im Register nicht verfolgt.
Schritte zum automatischen Ausfüllen von Formularen basierend auf einem Skript funktionieren nicht immer korrekt. Bei Referenzfeldern und Datumsangaben treten häufig Fehler auf. Dabei handelt es sich eher nicht um einen Toolfehler, sondern um eine Eigenschaft der Felder, an deren Einstellungen Sie dennoch herumbasteln müssen.
Mögliche Schrittoptionen sind bestimmten Konfigurationsobjekten zugeordnet. Was für Verzeichnisse verfügbar ist, ist möglicherweise nicht für Register usw. verfügbar. Genauer wäre es zu sagen, dass die Bindung eher nicht an Gegenstände, sondern an deren Merkmale erfolgt. Wenn das Register beispielsweise kein Formular hat, gibt es keinen Schritt, es auszufüllen.
Aber es gibt auch Fehler, zum Beispiel ist der Schritt „Knopf drücken“ für mich oft nicht verfügbar, oder besser gesagt, die Auswahl selbst kann getroffen werden, aber es passiert nichts.
Es bleiben einfach viele Fragen zur Testautomatisierung in einigen besonders komplizierten Fällen offen. Dies gilt insbesondere für Dokumente, die mit Residuen arbeiten, bei denen nahezu alle Aspekte eine wichtige Rolle spielen, von denen einige in der aktuellen Implementierung des Tools nur sehr problematisch umzusetzen sind. Für die Erstellung von Dokumenten zum gleichen Datum, mit der gleichen Nummer usw. gibt es in der Konfiguration eine Reihe von Einschränkungen. Bisher habe ich mich darauf festgelegt, vorhandene Objekte zu verwenden, ohne neue zu erstellen.

Diese Liste lässt sich endlos fortsetzen, aber überlassen Sie dies den Testern dieses Produkts. Das Wichtigste, was ich verstanden habe und zu vermitteln versuche, ist, dass „es keine Gratisgeschenke geben wird.“ Um die Testautomatisierung mit diesem Produkt in der Führungsrolle umzusetzen, müssen Sie mehr als einen Tag hart arbeiten. Natürlich ist meine Analyse rein subjektiv, und mangelnde Erfahrung im Umgang mit dem Produkt und den Konfigurationsfunktionen kann sich auch darauf auswirken, aber wie heißt es so schön: Wir haben, was wir haben, und es gibt kein Entrinnen davor.

Anwendungsmöglichkeiten.

Zur Einführung des jeweiligen Tools in den Testprozess habe ich mich derzeit für folgendes Konzept entschieden.

Aufgrund der aktuellen Betriebserfahrung bin ich davon überzeugt, dass die Referenzbasis und die Testbasis datentechnisch identisch sein sollten. Natürlich, wenn es sich um Skripte handelt, die vorhandene Objekte verwenden, ohne sie zu ändern, und keine neuen erstellen. Erstens erhalten wir dadurch in beiden Basen einheitliche Salden, was für die Umsatzprüfung sehr wichtig ist. Zweitens bietet dies eine gewisse Zuverlässigkeit und einen gewissen Schutz vor unnötigen Fehlern, denn Ich verstehe den Zusammenhang zwischen Referenzdaten und Datenbanken, verschiedenen Links usw. immer noch nicht ganz. Mich quält der vage Verdacht, dass es irgendwelche Verbindungen geben könnte, die sich eines Tages in ein Gewirr toter Links verwandeln, die nicht mehr sein können entwirrt.

Wir verfügen also über eine Referenzbasis, auf deren Grundlage wir Szenarien für alle Gelegenheiten erstellt haben. In einigen Dokumenten der Entwicklungskonfiguration wurden Korrekturen vorgenommen, die getestet werden müssen. In der Regel manuell. Anschließend wird die Konfiguration mit den Änderungen in die Testdatenbank geladen und es werden Skripte für alle oder nur benachbarte Objekte ausgeführt, um herauszufinden, ob die Änderung im Dokument Auswirkungen auf andere Objekte hatte. Danach gilt die Konfiguration als realisierbar und wird in der Arbeitsdatenbank installiert. Danach wird das Testskript für das geänderte Dokument aus der Arbeitsdatenbank auf einen neuen Standard geändert.

Mit anderen Worten: Wir führen mit diesen Szenarien Regressionstests durch. Und dies ist eine der wichtigsten und am schwierigsten manuell zu implementierenden Testarten in 1C Enterprise. Schließlich ändert sich sehr oft nicht nur der Beleg, sondern beispielsweise auch die Funktion der Belegbuchung, die mit allen Belegen des Systems verbunden ist, und hier spielen unsere Skripte die Rolle eines Netzwerks, in das alle Belege eingebunden werden werde fallen.

Eine weitere gute Verwendung könnte darin bestehen, die Arbeitsdatenbank auf zufällige Fehler zu überprüfen. Dazu wird ein Backup davon erstellt, in eine Testdatenbank geladen und ein vollständiger Testzyklus ausgeführt. Es wäre schön, diesen Vorgang automatisch durchzuführen, aber 1C Scenario Testing sieht keine planmäßige Durchführung von Tests vor, zumindest noch nicht.

Damit ist der Anwendungsbereich dieses Tools natürlich noch nicht erschöpft; ich habe nur die ersten Optionen genannt, die mir in den Sinn kamen.

Abschluss.

Dieses Tool hat zweifellos eine Zukunft. Es scheint mir, dass der Großteil seines Potenzials in späteren Versionen noch nicht zum Vorschein kommt, und zweifellos wird das Produkt seinen Benutzer finden, der meiner Meinung nach, der offenbar nicht mit der Meinung des Herstellers übereinstimmt, höchstwahrscheinlich dies tun wird Seien Sie kein gewöhnlicher Benutzer ohne spezifische Kenntnisse im IT-Bereich, und die Person kommt aus der Entwicklungsabteilung. Weil Der effektive Einsatz dieses Tools ist nicht die einfachste Aufgabe, insbesondere bei komplexen Konfigurationen.