Script Library zur Wiederverwendung von Modulen und Erstellung mehrerer Test Suites in einem Projekt


#1

Hallo zusammen,
nach meinem aktuellen Wissenstand kann man im XLT Script Developer immer nur eine Test Suite aktiv haben. Das wird über das Drop-down-Menü oben links abgebildet.
Jetzt ist es aber durchaus üblich für ein Projekt mehrere Test Suites zu haben, sodass diese beliebig ausgeführt werden können.

Wenn ich Tests für eine Web-Anwendung erstelle, mehrere Test Suites benötige und das auch richtig umsetzen will, müsste ich immer zwischen dieses Test Suites im XLT Script Developer umschalten.
Leider ist es dann aber auch nicht möglich,auf die Module, die ich in Test Suite 1 erstellt habe, auch für Test Suite 2 zu verwenden. Es fehlt somit ein gemeinsames Projekt, eine Script Library
und die Anlage / Verwaltung von Test Suites im XLT SD.

Aktuell haben wir Testfälle für die einzelnen Test Suiten angelegt und dann die einzelnen Testfälle als Modulaufrufe eingebunden. Das Problem hierbei ist, dass sobald ein Testschritt fehlschlägt,
sozusagen die restliche “Test Suite” (also die anderen Modulaufrufe - Testfälle) nicht mehr ausgeführt werden.
Mir ist klar, dass das nur eine Art Hack ist um das abzubilden, aber wir wissen gerade sonst nicht, wie man die o.g. Problemstellung mit aktuellen Mitteln von XLT sauber umsetzen müsste.

Ist das derzeit mit der Art und Weise, wie XLT konfiguriert wird und arbeitet, vereinbar?
Falls ja, gibt es eine Anleitung / Best Practices wie das aufzusetzen ist?
Wenn nicht, habt ihr euch bzgl. dieses Themas schon einmal Gedanken gemacht, ob es möglich wäre, das umzusetzen?
Inwieweit würde dann auch hier die Lasttestkonfiguration anders sein müssen / beeinflusst werden?

Mein Ziel wäre ein Projekt zu definieren, Testfälle aus Modulen zu erstellen und die Testfälle bestimmten Test Suites zuzuweisen,
sodass nur noch die Test Suite ausgewählt und gestartet werden muss. Bezüglich Lasttests wäre noch fraglich wie die Konfiguration vorgenommen werden muss,
wenn alle Tests der Suite ausgeführt werden sollen.
Momentan muss man die auszuführenden Testfälle einzeln in der project.properties bekanntmachen und in der test.properties als Lasttests kennzeichnen.

Gruß,
Patrice


#2

Hi Patrice,

Probably the term “TestSuite” is a bit confusing here since a test suite in the ScriptDeveloper would match what you describe as a “Project”. Within a test suite you can have certain sets of test cases and run them at once as batch test what would match your definition of “TestSuite”. When running them as batch test then each test case will be executed also if one of the previous ones failed.

Probably the easiest way would be to have separate packages for each “TestSuite” including the corresponding test cases. See the screen shot below for an example. Here we have a “testSuite” package with a sub package called “full” which includes all tests and a sub package “regression” with a limited set of tests. To run the regression tests just right click on the package and select “Run as Batch Test”. When the batch test is finished you can also export an HTML result page of this run.

When configuring the load test there is no special way to do this. Export your tests or wrapper classes and define the test case mapping for all of your test cases in the project properties. Then create a test.properties file for each test suite you want and define which scenarios should be included. For the above example we would have a “fullTest.properties” file and a “regressionTest.properties” file. If you now want to run the regression scenarios then just change the “com.xceptance.xlt.testPropertiesFile” property in the project properties and start the load test. Or use the master controller command line property to select the test properties file.

Hope that helps, otherwise just let us know.

Regards,
Randolph


#3

HI @rstraub,
thank you for your detailed explanation!

We will refactor our configuration to represent this.
Would it be possible to map all available test at once in the project properties and by the package in test.properties?
Currently, this is done for single tests but if you have a large number of tests and you add new ones you always have to edit project.properties and the test.properties for the according test suites.

Regards,
Patrice


#4

Unfortunately there is no short cut to create the project.properties mapping and also no possibility to refer the scenarios by it’s package in the test.properties. Usually the mapping would not change frequently and the changes are not that big for the most times. But of course it is after a large refactoring :frowning:


#5

That’s a pity but thanks anyway :smile:


#6

Hi Randolph,
I have following question to this subject.

In script developer tests are organised and executed alphabetically. In my case I have package suites.regression and for executing it outside the script developer, I want to set specific sequence. Do you have any suggestion how to do it?

Cheers -
Kristine


#7

Hi Kristine,

Usually test cases should be executable independend of each other and should not require a specific order. That the script developer executes it alphabetically is just a coincidence. I assume you are running the JUnit test wrappers from within your Java IDE or something like that. JUnit expect that each test is atomar and self contained (as all other Unit test tools too) and so does not guarantee a certain execution order. Out of the box there seems to be no way to force JUnit to run test cases orderd.

You should create a module that does the common test setup steps and use this module at the beginnign of each test case and after the test steps use a clean up module to restore the original state of the system under test.

Maybe your use case is very specific so could you explain why you have to rely on a specific order or what the tests do in general?

Thanks,
Randolph