Problems of stress testing of components of billing systems

Problems of testing in general and stress testing in particular is well known among software vendors (software). It is known that, in contrast to the functional and regression testing, which focuses on testing the completeness of coverage of all branches of the algorithm of the subsystems (applications) and the backward compatibility of the functional testing services with older versions, a "headache" departments exercise testing is precisely the perspective of the approximate simulation to the reality of the load relatively few resources (both hardware and human), as well as finding bottlenecks in the functioning of the whole system.

All compounded by the fact that the process of issuing new versions or patches of errors in relation to billing systems, looks a little different than any other software. Here, the traditional process of "Staging - Development - SoftwareTesting Services- Implementation - Support comes in a very large number of relatively small components (subsystems). Since the billing system - a product of a living, constantly changing, the number of subsystems produced per day can be measured in tens.

Attempt to "integrate with" business-process software release identified a number of conflicting objectives, where it is necessary to seek a compromise.

First, each scenario is the use of billing separately (in the image and likeness, as is done at the customers) for stress testing is impossible to recreate (the number of clients is steadily growing volumes of data to be processed grows geometrically). On the other hand, make a universal stand on which to try to fully test the load all the functionality of billing and not simply because there is mutual exclusion as the algorithms within the same subsystem and the mutual exclusion of subsystems as a whole.

Second, as practice shows, the complexity of the preparations for the load testing, in contrast to the functional (regression), estimated totally different scale. By the degree of complexity of preparation for exercise testing, the software can be divided as follows:

·         "Light". Subsystems are loaded with the stream of input data (pre-filled table, a set of files, etc.). In this case, often preserved continuity tests (once prepared the input data, and then you can use them by simply changing the version of the application on the newer ones). Of course, if the format of the input data is changing (increasing), this leads to an alteration of the script. But this usually does not happen very often. Most often, the category of "light" fall batch jobs and background processes of billing systems that run directly on the server (or database or application servers).

·         "Average." Subsystems have the user interface. In this case, the client application is written "properly" - so that there is no logic in the client application is not concentrated - "light" client. In this case, the initial preparation for the stress testing can be very serious. To simulate the mass of customers, using special software tools, such as Rational Perfomance Testing services and Mercury LoadRunner, you want to create scripts from the context-related scripts written in a special language. But at the same scripts themselves are fairly simple, because contain only calls to server-side logic. In addition, in the future, the same script can be used again as a changed server-side logic (or have expanded the functional, not affecting the existing one).

·         "Heavy". Typically, these are supplements that contain the logic on the client site. Simulate the mass work with clients in such an application (especially if the tests claim accuracy) are either very difficult or impossible. For example, in the used Rational Perfomance Tester language VU Language simply does not provide floating-point operations. Ie, any such "client" the calculation involves, at least, the establishment of special libraries (DLL), allowing to make the appropriate calculations on floating point numbers, to pass a string. Thus, the tester should be in a certain sense also a good programmer! Not to mention that without the source code analysis of the simulation of such an application is simply not possible.
Thus, not every problem can be tested under load without serious "artillery preparation", and what, alas, will just have to close my eyes …

Third, a separate task is profiling loads. It is no secret that every application can work well individually. However, in view of "interprocess" correlation, the results of groupware applications, can be very unpredictable. Hence - the more accurate the profiling done loads for each of the applications, the better will stress test, and as a consequence, the conclusions drawn. There is also an application can be divided into "light" and "heavy." By the light, in terms of profiling, include those whose input flow measure (for example, the number of processed records for some period), or, if it comes to client workstations, a set of operations leading to the appearance of a certain amount of information per unit time . By "heavy" in terms of profiling, are those applications whose work poses a serious burden and, thus, leaves no "footprints" of their "life" (for example, the work «Call Center» - a group of users, giving information on telephone and, accordingly, only viewing information). Another example is a batch job (or set), process the data generated by other processes. Here, for example, there may be an avalanche effect, where due to imbalances in any of the grounds, the subsystem does not behave like in a real operation.

Currently, the group exercise testing "Peter-Service", based on the developed test methods of billing system «PETER-SERVICE BIS», was seeking answers to a rather narrow range of issues. Among the tasks we have set, such as the answer to the question of raising / lowering the productivity of key business flows billing with the upgrade version of ORACLE with the existing (9 Release 2) to the new (10 Release 2) or a comparison of hardware from different vendors at the same load scenarios. And to answer such questions today is quite simple. However, fully integrate into the business process of software production is not yet possible because of the complexity of solving the problems voiced above. Nevertheless, we are looking forward with optimism.

 Visit: Software Testing Companies

Testing Philosophy

Software Testing covers a wide range of species activity, very similar sequence of development processes software. This includes setting objectives for the test designing, writing tests, testing, testing, and finally execution of tests and examination of test results. 

Plays a crucial role designing the test. Chance of a range of approaches to the development of philosophy,or the strategy of designing tests, shown in Figure 2. To oriented strategies in the design of tests is to consider two extreme approaches, which are at the boundaries of the spectrum. It is also noteworthy that many of those who work in this area, often throw in one or other extreme.

Supporter (or supporter), an approach consistent with the left boundary spectrum, design their tests, exploring the outer sheet or specification interface of the program or module that they test.Program he sees as a black box. Position it as follows: "I do not interested in looks like this program and I fulfilled all the commands, or all way. I’ll be satisfied if the program will behave as describe din the specifications. " His ideal - to test all possible combinations and value sat the entrance.

He likes the approach consistent with the other end of the spectrum,designing their own tests, studying the logic of the program. He begins with the fact that seeks to prepare a sufficient number of tests to ensure that every command was executed at least once. If it is a bit more tempted, he is designing the tests so that each team is a conditional jump performed in each direction at least once. His ideal - to check every way, each branch of the algorithm. In this case, it completely (or almost) no interested in the specification.

Neither of these extremes is not a good strategy. Reader,however, have probably noticed that the first of these, namely the one in according to which the program is seen as a black box,preferable. Unfortunately, it suffers the disadvantage that completely feasible. 

Consider a trivial attempt to test the program,receiving input three numbers and calculates their average.Testing of this program for all values ??of the input data is impossible.Even for machines with relatively low accuracy of calculations oftests would be counted in billions. Even If we had the computing power,sufficient to perform all tests in a reasonable time, we would spend on several orders of magnitude more time to prepare these tests, and then check. 

Programs such as real-time systems,operating systems and data management programs that preserve"Memory" of previous input data, is even worse. We would need software testing services program not only for each input value, but also for each sequence, each combination of input data. Therefore,exhaustive testing of all input data of any reasonable program impracticable.

These considerations lead to the second fundamental principle testing: testing - the problem is largely economic.Since exhaustive testing is impossible, we must restrict ourselves to something anything less. Each test should give the maximum benefit in comparison withour costs. This return is measured toyu probability that the test detect snot detected before the error. 

Costs are measured in time and cost preparation, implementation and verification of test results. Considering that the cost limited budget and schedule, one could argue that attesting, in essence, represents the art of selection tests maximum potential. Furthermore, each test should be representative certain class of input values, so that a correct implementation created some of our conviction that a certain class of input program is executed correctly. This usually requires some knowledge of the algorithm and the structure of the program, and we thus shifted to the right end of the spectrum.

Module Integration

The second important aspect of the test (after the design of tests) is a sequence of merging all modules in the system or program. This aspect of the problem usually does not receive sufficient attention and often considered too late. 

The choice of this sequence, however, is one of the most vital decision taken at stage testing, since it determines the form in which written tests, types of tools necessary testing sequence programming modules as well as the thoroughness and efficiency of all stages testing. For this reason, such decision should be made at the level of project as a whole and at a sufficiently early stage.

There is a wide range of possible approaches that can be used for the merge modules into larger units. In most general they can be considered as options for the six main approaches described in the following six sections. Immediately behind them is a section where proposed approaches are compared by their impact on software reliability software qa services.