Yes Sunny request can be debuged 1.schema validation Assertion while creating a test case this allows to validate the request. 2. you can try sending the request without the mandatory parameters and test the response correspondingly similarly u can test wheather any of the optional parameter is behaving as mandatory.
If ure Service uses SOAP protocol it must be having a wsdl view. so u can map the request parameters to the WSDl verifying the optional and mandatory scenario manually or for ease u can use the SOAP UI Assertions which automatically fethes u the result
I want to export xml tag parametrized during load testing to Excel sheet to verify what all data was send across.
So the steps should be groovy script to initialize file (excel sheet) ->first iteration i=1 -> Load test run (thread 1) -> write output to excel -> i=i+1-> Load test run (thread 2)->write output to excel and so on till I = threadcount. So I need the code to initialise excel and then append to excel during load test.
I would recommend you to use Apache POI as a third party API as it allows opening the excel sheet in append mode and writing to the excel sheet.Jexcel API wouldn't work as it doesn't open file in append mode.
One important factor in imbibing a new model of Software Architecture is the ever-changing business model. Modern day business constantly needs to adapt to new customer bases. The ability to quickly adapt to the new customer base and new business partners is the key to success. Sharing IT systems with other organizations is a new trend in the business. For example, businesses like online auctions are opening their systems to third party organization in an effort to better reach their customer base. In this context, Service Oriented Architecture offers benefit and cost-effectiveness to the business. The process of adapting to the changing business model is not an easy task. There are many legacy systems, which are difficult to make available to the new business partners. These legacy systems might need to change to support the new business functions and integrate to the newly developed IT systems or integrate to the IT systems of its partners'. The complexity of the whole thing is what makes it a constant challenge to organizations.
Imagine a government department has some legacy Sales Tax management system which interacts with the legacy Trader Management system. Suddenly, the government needs to incorporate a new Green House tax. Now the new Green House Tax system will also interact with the legacy Trader Information system and also affect the existing Sales Tax for the Traders who are paying Green House Tax, In essence, because of the introduction of the new Green House Tax system, both the legacy systems need to be readjusted to deal with the new type of Traders and Tax information. This is costly as all the existing legacy systems will have to be modified and will need to be re-tested.
This sort of complexity scenarios can be resolved by adopting SOA. Services are defined as a set of well-defined interfaces, which are generic in nature. Services also define a schema for the input to be supplied to the Service by its consumer. The inherent nature of SOA is that Services work with an extendible Schema and thereby can cope with various different types of entities that the Service is dealing with. For example, a Customer Management system works with a XML based data passed into it and it is capable of processing any type of Customer without needing to know the difference between a Corporate Customer and a Household Customer. This aspect of SOA resolves the above mentioned complexity scenario without having to change.
Essentially, Services operate as an independent entity. An Organizational IT system is composed of a collection of Services. Each of these Services can evolve and change in its own right.
Another example might be, a bank. Imagine that several areas of banking applications will deal with the current balance of an existing customer. More than often, the “get current balance” functionality is repeated in various application softwares written within a banking environment. This gives rise to a redundant programming scenario. The focus should be towards finding this sort of common, reusable functionality and implement them as a service, so that all banking applications can reuse the service as and when necessary.
We have briefly discussed the case for SOA. We have seen that SOA is mostly driven by the business model of an organization. The real benefit lies in the reduced cost to fit into changing and reusable business model. Now let us try to define what do we mean by a “Service”.
Early Identification of defects : As you are the first team to which service is thrown at without getting integrated to the UI “Unit testing” the services can lead.
Cost of defect fixing is less: Early identification of defects leads to less fixing cost .
Easy to Identify the root cause: We know which is the service are we testing and which methods does the service invoke , hence if something goes wrong the faulty method can easily be noticed.
Less design Issues: Design Issues are captured early while testing the web service against web service design.
Compatibility Issues are found early : While testing end to end flows compatibility between different systems is monitored.
can we debug the request?
ReplyDeleteYes Sunny request can be debuged
ReplyDelete1.schema validation Assertion while creating a test case this allows to validate the request.
2. you can try sending the request without the mandatory parameters and test the response correspondingly similarly u can test wheather any of the optional parameter is behaving as mandatory.
I just have input xml request. is there any option to debug directly?
ReplyDeleteIf ure Service uses SOAP protocol it must be having a wsdl view. so u can map the request parameters to the WSDl verifying the optional and mandatory scenario manually or for ease u can use the SOAP UI Assertions which automatically fethes u the result
ReplyDeleteGot ya!! thanks much!
ReplyDeleteHey Pranai,
ReplyDeleteNice Initiative,
keep Up the Good Work.
Regards,
DSP
Thanks Diggi
ReplyDeleteIf any error pops out, I want to display the error description. So that I can find the root cause of the failure.
ReplyDeleteHi murali create a db connection to the error details tables and fetch the error deatails corresponding to the accnt number
ReplyDeleteHello Pranai,
ReplyDeleteI want to export xml tag parametrized during load testing to Excel sheet to verify what all data was send across.
So the steps should be groovy script to initialize file (excel sheet) ->first iteration i=1 -> Load test run (thread 1) -> write output to excel -> i=i+1-> Load test run (thread 2)->write output to excel and so on till I = threadcount.
So I need the code to initialise excel and then append to excel during load test.
Thanks a lot in advance
Ki
Hi Kiran,
ReplyDeleteI would recommend you to use Apache POI as a third party API as it allows opening the excel sheet in append mode and writing to the excel sheet.Jexcel API wouldn't work as it doesn't open file in append mode.
Why do we need SOA?
ReplyDeleteOne important factor in imbibing a new model of Software Architecture is the ever-changing business model. Modern day business constantly needs to adapt to new customer bases. The ability to quickly adapt to the new customer base and new business partners is the key to success. Sharing IT systems with other organizations is a new trend in the business. For example, businesses like online auctions are opening their systems to third party organization in an effort to better reach their customer base. In this context, Service Oriented Architecture offers benefit and cost-effectiveness to the business. The process of adapting to the changing business model is not an easy task. There are many legacy systems, which are difficult to make available to the new business partners. These legacy systems might need to change to support the new business functions and integrate to the newly developed IT systems or integrate to the IT systems of its partners'. The complexity of the whole thing is what makes it a constant challenge to organizations.
Imagine a government department has some legacy Sales Tax management system which interacts with the legacy Trader Management system. Suddenly, the government needs to incorporate a new Green House tax. Now the new Green House Tax system will also interact with the legacy Trader Information system and also affect the existing Sales Tax for the Traders who are paying Green House Tax, In essence, because of the introduction of the new Green House Tax system, both the legacy systems need to be readjusted to deal with the new type of Traders and Tax information. This is costly as all the existing legacy systems will have to be modified and will need to be re-tested.
This sort of complexity scenarios can be resolved by adopting SOA. Services are defined as a set of well-defined interfaces, which are generic in nature. Services also define a schema for the input to be supplied to the Service by its consumer. The inherent nature of SOA is that Services work with an extendible Schema and thereby can cope with various different types of entities that the Service is dealing with. For example, a Customer Management system works with a XML based data passed into it and it is capable of processing any type of Customer without needing to know the difference between a Corporate Customer and a Household Customer. This aspect of SOA resolves the above mentioned complexity scenario without having to change.
Essentially, Services operate as an independent entity. An Organizational IT system is composed of a collection of Services. Each of these Services can evolve and change in its own right.
Another example might be, a bank. Imagine that several areas of banking applications will deal with the current balance of an existing customer. More than often, the “get current balance” functionality is repeated in various application softwares written within a banking environment. This gives rise to a redundant programming scenario. The focus should be towards finding this sort of common, reusable functionality and implement them as a service, so that all banking applications can reuse the service as and when necessary.
We have briefly discussed the case for SOA. We have seen that SOA is mostly driven by the business model of an organization. The real benefit lies in the reduced cost to fit into changing and reusable business model. Now let us try to define what do we mean by a “Service”.
Need FOR SOA TESTING !!!!
ReplyDeleteEarly Identification of defects : As you are the first team to which service is thrown at without getting integrated to the UI “Unit testing” the services can lead.
Cost of defect fixing is less: Early identification of defects leads to less fixing cost .
Easy to Identify the root cause: We know which is the service are we testing and which methods does the service invoke , hence if something goes wrong the faulty method can easily be noticed.
Less design Issues: Design Issues are captured early while testing the web service against web service design.
Compatibility Issues are found early : While testing end to end flows compatibility between different systems is monitored.