Testing Client Server Applications


To test the server based applications, you need to perform typical tests like Volume Testing, Stress Testing, Performance Testing, Recovery Testing, Back up and Restore Testing, Security Testing etc.
The Stress Testing shows that the system has the capacity to handle large numbers of processing transactions during peak periods. An example of a peak period is when everyone is logging back onto an on-line system after it has been down.

You will need to perform Volume Testing to find weaknesses in the system with respect to its handling of large amounts of data during short time periods. Basically, this kind of testing ensures that the system will process data across physical and logical boundaries such as across servers or across disk partitions on one server.

To assess performance under all load conditions, you will need to perform Performance Testing parallel with Volume and Stress testing. System performance is generally assessed in terms of response times and throughput rates under differing processing and configuration conditions.

If you have identified any business processing cycles like month-end or Quarter-end etc., the system performance should be tested under emulations of each processing cycle.

Also, Performance testing should cover performance under all hardware and software system configurations.

One myth about the Client / Server performance problems is that “This problem can be fixed by simply plugging in a more powerful processor." As a tester you will need to convey the truth that performance degradation may be related to other system components not just the processor. Problem may be the network, the computer, the application logic itself. Whatever it is, as a good tester, you'll want to know it before it happens.

Before starting testing the interaction between the application and the network, look at cache settings, disk I/O, and network cards. From the development team ask the questions like:
  • How much application logic should be remotely executed?
  • How much updating should be done to the server database over the network from the client workstation?
 Look at all of the processes running on the machine and all of the resources each process receives.

One suggestion for developers is that they should design the applications that most of the processing should be on client machine (90% or even more).

 Regardless of performance testing strategy, it is important to have the right tools. Sometimes, we need to have multiple tools to do performance testing (Form performance testing, I mean to say testing the performance of application and analyzing the database performance).

As performance testing tools are very costly and performance testing is not necessary for every application. So many companies do not buy these tools. Now, what can be done if you don't have any automated tool.

In such situations, you can take some help from developers. You can ask them to write some driver programs in Java or .net. The program should initiate each of 10 or 20 or 50 SQL queries or classes designed for the application. Each program should also be able to display the name of each query or class and compile time etc. This approach is bit tricky. I will explain it in some of my other article. The best approach, however, is to use good test tools like LoadRunner etc.

Apart from performance testing, the other tests can be like Data Security Testing, Data Backup Testing and data recovery testing.

For Data Security Testing, controlled tests with third party tools needs to be conducted separately or as part of the system test. For example tools such as SQLEYE can be used to monitor and restrict database access with third party tools.

As you might know that Error Trapping logic can record the problem, by-pass the corrupt data, and continue processing as an alternative to a system shut down. It is your responsibility to assure that the system can properly trap errors.

The defined backup and restore procedures should be tested as part of server testing. While testing these procedures, some of the following points need to be considered:
  • How often and when should the backups be done?
  • What is the backup medium (cartridge, disk)?
  • Will the backups be manual or automated?
  • How will it be verified that the backups occur without errors?
  • How long and where will backups be saved? How long will it take to restore the last backup?
The data layer of Client-Server applications can be difficult to test because their functionality is "hidden" from direct testing through the GUI. Stored procedures and data base triggers are best tested using counters and profilers.

Also See:

No comments:

Post a Comment