Test automation of web services
Automation of testing has long been something you wanted to reach very hot. Many times you have failed when it tried to automate testing of graphical interfaces, for example. Web interface. A major reason for the failure is that the interface changes and requires much hand finishing to get the existing testscripten work. In addition, it requires great effort to get good test scripts. Regarding testing of Web services is much easier and more efficient to automate tests. The work that needs to be done to automate testing of a web service is relatively small and because it is ultimately often get very many services to be tested when you install new versions, it is cost effective to make these testautomatiseringar.
The test cases created in SoapUI, or similar tool, during the manual testing can then be used to automate tests for regresssionstest. When creating regression tests should be remembered that there will be many test cases. For every Web service should create some positive tests and no negative tests. These are filled with different test data. This means that there will be many test cases in an SOA solution with perhaps hundreds of web services. So that there will be an excessive effort to keep the tests up to date, it is good if you can separate test data from the call. It is an effective way to build on their tests if there are a few files with test data that you can work with instead of having to go into testscripten and change in hard-coded values. Consider also modular, ie a test track used by multiple test suites, rather than creating multiple times. For example, be good to have a call to make an issue against the database to verify that it had to save through a webservice. This call can be used by several tests using similar verifications to be done in the same database (or perhaps in other databases if parameterised call database and database query).