MS-Access oder MS-SQL?

[hoika]

Hallo,

Zitat:

Da ist alles verteilt, auch die Testdatenbanken.

Super, das ist die beste Lösung!

[jobo]

Also das "Entweder/Oder" sehe ich auch nicht. Man muss die Konstellationen testen, die man anbietet. Gerade MS Access ist in meinen Augen relativ weit von "einem" (1) sowieso-nicht-existenten SQL Standard entfernt.

Zu den Ressourcen:
Wenn die Tests komplett gescriptet sind, sehe ich keine Problem in den Größen.
Der Test erzeugt das passende Endsystem, macht den Workload und alles geht wieder in den Müll.
Oder wollt Ihr jeden Test (jede Instanz) als Beweis aufheben?

Und auch wenn es nicht gefragt war:
https://info.microsoft.com/top-six-r...-register.html
Am besten gleich noch eine dritte Möglichkeit vorsehen (z.B. Firebird) und die beiden MS Varianten langsam ausschleichen, bspw. durch höhere Preise- die sie ja schon von allein haben. ;)

[Delphi.Narium]

Wenn man alles per Script löst, braucht man keine Datenbank (wo auch immer) ablegen. Die kann man auch per Script erstellen.

Zu Beginn des Testes hat man nichts, außer den Scripten und dem zu testenden Programm (auf einem möglichst jungfräulichen System).

Mit den Scripten wird die Datenbank (mit komplettem, für den Test benötigten, Inhalt, der erforderlichen Konfiguration, ...) erstellt und dann der Programmtest durchgeführt.

[freimatz]

Zitat:

Zitat von Schokohase (Beitrag 1437051)

Die eigentliche Frage ist doch was du eigentlich testen willst.

Wenn du mit echten Datenbanken herumhantierst, dann ist es auf jeden Fall schon mal kein Unit-Test sondern ein Integration-Test.

Wenn du diesen mit der Access-Datenbank durchführst, dann kannst du nachher auch nur sagen, dass es mit der Access-Datenbank funktioniert hat. Mehr nicht. Einen Rückschluss auf die Funktionalität mit dem SQL-Server lässt das nicht zu.

Also, was genau soll dieser Test an Erkenntnis bringen, bzw. was genau willst du damit testen?

Dann können wir die Frage auch sinnvoll beantworten.

Hallo,
die eigentliche Frage für mich ist die ob es sinnvoll ist wenn ich bei unseren Test die Access-DB durch MS-SQL ersetze. Wenn es für die Beantwortung diese Frage wichtig ist, was getestet wird dann ok.

Ich schrieb "ich habe eine Anwendung, die unterstützt MS-Access oder MS-SQL. Für automatische Tests gibt es Testdatenbanken.". Es geht mir hier um den Test der Anwendung, nicht um den Test der Datenbanken. Und ja, es geht auch nicht um unit-tests. Es sind hier das was manche Coded-UI-Tests nennen.

Ein vereinfachtes Beispiel für einen Test:
- Öffne Anwendung mit DB "Bla"
- Öffne in der DB Bereich "7162"
- Aktiviere Action "Fu"
- Warte bis Menüband (Ribbon) erscheint
- Fülle in die Eingabefelder b1,b2,b3 die Elemente von der DB x001, x002 bzw. x003 ab
- Prüfe ob in der DropDown-Liste Z003 die Einträge M und L drin sind.
Ob die Elemente x001, x002 bzw. x003 von einer Access oder MS-SQL DB stammen ist für den Test völlig egal.

(Und ja, es gibt auch Tests die spezifisch das Verhalten der DB bei Access und bei MS-SQL testen, aber um diese geht es mir hier nicht.)

@jobo:
Ja, der Access-Dialekt ist sehr ungewöhnlich.
Bislang haben wir es nicht geschafft den Inhalt der Access-DB in ein Script (z.B. SQL oder XML) zu überführen.
Die Ergebnisse der Tests werden schon eine Zeitlang aufbewahrt. Das sind irgendwelche Logs, aber keine DBs.
Für eine dritte Variante (SQLite war mal mein Favorit) ist derzeit kein Bedarf. Den Anwendern ist das Format egal (ausser ganz wenigen die die Daten auf Ihrem zentralen MS-SQL-Server haben wollen)

@Delphi.Narium:
Ja so stelle ich mir das ungefähr vor. Als die DB aus einem versionierten Script erzeugen und nicht eine vorhandene DB benutzen.

[hoika]

Hallo,

Zitat:

Ja so stelle ich mir das ungefähr vor. Als die DB aus einem versionierten Script erzeugen und nicht eine vorhandene DB benutzen.

Du solltest du aufpassen.
Beim Kunden ist ja nie eine neue DB, sondern immer eine alte mit einem DB-Update.
Aber genau das ist ja wahrscheinlich in Euren Tests auch mit drin.

PS:
Wir hatten auch schon Kunden mit einer 5 Jahre alten DB-Struktur, wo unser DB-Update fehlgeschlagen ist, weil wir nur 4.9 Jahre ( ;) ) zurückgeschaut hatten.

[mkinzler]

Zitat:

Für eine dritte Variante (SQLite war mal mein Favorit) ist derzeit kein Bedarf. Den Anwendern ist das Format egal (ausser ganz wenigen die die Daten auf Ihrem zentralen MS-SQL-Server haben wollen)

Vorteil von FireBird wäre aber, dass eine Lösung sowohl embedded wie auch mit einem zentralen Server funktioniert.
Es werden nicht 2 verschiedene Varianten benötigt.

[freimatz]

Für DB-Updates haben m.W. unit tests.
Überdies bin ich der Meinung dass das den jeweiligen Tests egal sein muss (https://de.wikipedia.org/wiki/Single...bility-Prinzip).
Natürlich muss man neben den konkreten syntetischen Test auch allgemeine Tests möglichst nahe am Kunden haben.

[jobo]

Zitat:

Zitat von freimatz (Beitrag 1437061)

Überdies bin ich der Meinung dass das den jeweiligen Tests egal sein muss

Ja, bei einem GUI Test sieht es vielleicht anders aus, vielleicht.
Es soll ja immer das gleiche abgespult/getestet werden. Irgendwo in der Anwendung ist aber das Mapping auf eine spezifische DB, das kann halt mal schief gehen.

[freejay]

Also ich habe früher (vor 20 Jahren...) sehr viel mit Access gemacht, fand es - für damalige Verhältnisse - ein tolles System, inklusive Oberflächenentwicklung und so. Auch die Performance war erstaunlich gut: Wie ich später die Daten auf MySQL umgezogen habe, musste ich viele Abfragen umgestallten, weil MySQL in machen Fällen - bei gleicher Datenmenge, Tabellen- und Query-Definition - wesentlich langsamer als Access war! :shock:

Damals war - in meinem Arbeitsumfeld - eine "echte" Datenbank meist noch ein Großrechnerthema, also waren die Alternativen dünn gesäht...

Aber heutzutage käme ich im Bereich Anwendugsentwicklung nie mehr auf die Idee, statt einer "richtigen" Datenbank Access zu benutzen. Die Zeiten von Access sind einfach vorbei.

[MichaelT]

Liest die Anwendung den Inhalt der DB ein? Sprich ist solche eine kleine DB eine andere Form von Testscript?

Ihre emuliert das Scripting gegenüber einer Automation Schnittstelle.

Prinzpiell wäre es klüger das 'Testscript' in dem Format anzubieten in dem der bestehende Test'mechanismus' die Tests heute schon liest.

Wenn dem noch nicht so ist muss man mal den Testprozess ein wenig durchleuchten.

a) Testet die Anwendung selbst oder ein eigenes Testprogramm
b) Hältst du eine DB auf SQL Server bei dir und erzeugst aus einer Tabelle welche für eine kleine Access DB (Testscript praktisch) jeweils on the fly eine aktuelle Version usw...
c) Weder die 'Testscripts' gepushed oder kann sich der User die Daten selbst ziehen
d) Modifzierbarkeit der Testsequenz nach der Auslieferung
e) ...

[QUOTE=freimatz;1437057]

Zitat:

Zitat von Schokohase (Beitrag 1437051)

@Delphi.Narium:
Ja so stelle ich mir das ungefähr vor. Als die DB aus einem versionierten Script erzeugen und nicht eine vorhandene DB benutzen.