Make your oracle careers in testing using SQL
There are some general test requirements issues for SQL server back-end testing and also for providing test methodology which has test design and that is what this article is all about.
Forecast LRS, Delta, KENAI, KBATS and so on are the systems that are designed by ITG have client-server architectures. Completely tested projects are only with back end and they are only few in number.
1.1 Importance of back end assessments
Any client or server system is called back end. If there are problems with the back end then it may lead to dataloss, system deadlock, corrupt data, and bad efficiency. Single SQL server are logged on by various front end systems. The whole program will collapse if there is a small bug in the back end of the system. It will cost you more if there are many bugs in the back end
It is clear that various tests done in the front end doesnt affect much of back end and for back end there is a need for direct testing.
Benefits for back end testing:
Testers need not worry about the back end and it is not a black box. They have in depth control of test coverage and detail. Many bugs can be effectively found and corrected in the beginning of development stage.
If you consider Forecast LRS as an example; the amount of bugs in a back-end was more than 30% of count of bugs in the venture.
When back-end bugs are set, the program top quality is considerably increased.
1.2 Variations between back-end testing and front end testing
It is not easier to know and check a back-end than a front end end because a front side end this is because of user friendly interfaces.
Tables, saved procedures and triggers are the objects that back end has. Data reliability and protection is important.
There are some big problems like multiuser and performance. The project’s future needs operation that are slow and it is vital to be so.
There is hardly any testing tool for back end and SQL is one of the testing tool which is widely used. MS Access and MS Excel can be used to confirm information but they are not perfect for testing.
But on the contrary there are wide range of tools for front end testing.
The professional must know the balance between SQL Server and SQL testing and thus there are
not many testers available.
1.3 Back end testing phases
Let us look at the various stages of back end testing.
- Requirements gathering for design patterns for an SQL.
- Analyze the requirements of the design.
- Application of testing in this pattern with SQL Query.
- The information concerning component testing (individual components of the system), regression testing (previously known bugs), integration testing (several items of the program put together), and then the entire program (which will include both front end and back ends).
In the development cycle, an early stage, component testing will be done. After the component testing, integrating and program testing will be initiated.
Throughout the project, regression testing will be done.
There is no independent testing for back end as it is governed by the front end
Final stage is quality product delivery.
1.4 Back again end testing methodology
There are things common between back end testing and front end testing and API testing.
Many testing techniques can be used for back-end testing.
Functional testing and Structural testing are the more effective techniques at the back end testing.
They are combined in some test cases.
This testing may find more bugs and therefore it is recomended for the testers to do both the testing.
And to be a tester you should join a dba institute now.
Back end testing has various options of testing and here is a list of them:
A back-end can be split into a limited number of testable items centered on application’s efficiency.
Functionality and input will be the test focus and not implementation and structure. Different tasks may have different ways to split down.
There are many columns with boundary conditions.
You can consider the column percentage where the range is between 0 and 100.
This testing will be used for such boundary analysis.
As the name says, heavy data is to be submitted. For instance there are many users who use the same table to access loads of data and in such cases repeated stress test is required.
2 STRUCTURAL BACK END TESTS
There are some test places that will cover major test specifications but not all the databases are the same.
There are three different categories based on structure of SQL database:
Schema comprises of codes, database design, tables, table columns, column types, keys, indices, defaults. Saved Procedures are designed on the top of a SQL database.
Front end communicates to API in DLL. Stored Procedures are used for communication in SQL database. Stored Procedures are database. Triggers are also a kind of stored procedures.
Following are the structural back end test:
2.1 Database schema testing
2.2 Stored procedure tests
2.3 Trigger tests
2.4 Integration tests of SQL server
2.5 Server setup scripts
3 FUNCTIONAL BACK END TESTS
As said earlier, fucntionality and features are the prime focus for this testing. Each venture has different test cases.
There are many things common in project.
The following, speaks about the most similar things. Project specific test cases are to be added in the functional test design.
It is not a wise decision to analyze a server information source as a single entity at initial stage.
We have to split it into functional segments.
If we cannot do the partition, either we do not know that venture deep enough or the design and style is not modulized well.
How to split a server information source is essentially dependent on the project features.
Asking for project features.
For each major feature, pick up portion of schema triggers and saved procedures that apply the function and make them into a functional team.
Each team can be examined together. For example, the Forecast LRS venture had four services: forecast, product lite, reporting, and system. This was the key for functional partitioning:
If the boundary of functional groups in a back end is not apparent, we may watch information flow and see where we can examine the data:
Begin from the front end.
When a service has a demand or saves data, some saved procedures will get called.
Table updates will take place. Those saved procedures will be the starting point testing and those tables will be the best spot to evaluate and analyze results.
Following are the functional back end testing:
3.1 Test functions and features
3.2 Checking data integrity and consistency
3.3 Login and user security
3.4 Stress Testing
3.5 Test a back end via a front end
3.6 Benchmark testing
3.7 Common bugs
For more information join the best oracle training.