This action might not be possible to undo. Are you sure you want to continue?
between the application and the database. It is checking the changes made in the database is getting reflected in the application Back end Testing means ensuring that, 1 If you enter data in the front end, the data should be stored properly in the back end. 2 If you call that stored record from front end it should display properly. What is Database? The Collection of Interrelated Data is called Data Base. Relational Database Concepts RDBMS= DBMS +Referential Integrity (It is achieved through Foreign Key). Referential Integrity: The existence of a value in one dataset is dependent on the existence of the same value in another linked dataset Ex: Oracle, Sqlserver, Mysql follow RDBMS model. What should we Test in Data Base? Database testing basically include the following. 1) Data validity testing. 2) Data Integrity testing 3) Performance related to data base. 4) Testing of Procedure, triggers and functions. Data validity testing: Testing the correctness and reasonableness of data. Ex: Account no falling within range, numeric data being all digits, dates having valid months Note: Data validity errors are more common and most difficult to detect. Errors in data validity are caused by End user/ by who enters Ex: 13/25/2006 Date integrity is nothing but enforcing the business rules (facts/data) into database table is called data integrity Types of Data Integrity: Entity Integrity: can be achieved through Primary Key and Unique Key Constraints. Should be tested: whether it is taking duplicate values, Whether it is taking null values.
checking the values in the column. Many front ends log on to a single SQL server. database testing phases There are several phases in back end testing. It is relatively difficult to find testers who understand both SQL server and SQL testing. This causes a shortage of back end testers. Back end testing phases. Referential Integrity: can be achieved through Foreign Key. Many bugs in a back end cannot be easily discovered without direct testing. Check. Data integrity and protection is critical. tables. a tester must have strong background in SQL server and SQL language. data corruption. The test specification design should contain information concerning component testing (individual pieces of the system). SQL language is mainly a testing tool. Differences between back end testing and front end testing It is not easier to understand and verify a back end than a front end because a front end usually has friendly and intuitive user interfaces. The first step is to acquire design specifications for an SQL server. regression testing (previously known bugs). Slowness in operation can be vital to the project’s future. The second step is test specification design. To be able to do back end testing. A back end has its own objects. Too many bugs in a back end will cost tremendous resources to find and fix bugs and delay the system developments.Domain Integrity: can be achieved through Not null. it may cause system deadlock. Should be tested: Checking Whether "child" rows are deleted or not when a parent row is deleted from parent table. There are no sufficient tools for back end testing. integration testing (several . The next step is to implement the tests in this design with SQL code. For performance related Testing in DB: Indexes are used to increase the performance. Ex: age column should take < 60. such as. Default. It is very likely that many tests in a front end only hit a small portion of a back end. stored procedures and triggers. Why back end testing is so important? A back end is the engine of any client/server system. It is nothing but ordered list of values taken from one or more columns in the tables and organized in to b_tree structure Need to test: whether we have created index on column for particular table or not. Should be tested: Whether it is taking default values even though if we won’t give. If the back end malfunctions. data loss and bad performance. A problem in a back end may put serious impact on the whole system. Performance and multi-user support are big issues.
Integration and system tests (including interfaces to front ends and nightly processes) are performed after the component tests pass. the value cannot be less than zero and cannot be greater than 100%. Tests will verify each and every object in a type of structure. as it only exercised by the front end during the beta test period. we need to start as many machines as possible and run the tests over and over. The last step is to deliver users a quality product. For incidence. The test focus is on functionality of input and output but not on the implementation and structure. The back end usually does not have an independent beta test. We list a few below.pieces of the system put together). They are overlapped in some test cases. We should find out these types of boundary conditions and test them. Boundary testing Many columns have boundary conditions. and then the entire system (which will include both front and back ends). We strongly recommend testers to do both types of testing. in a column for percentages. Functional testing A back end can be broken down into a finite number of testable pieces based on application’s functionality. Regression testing will be performed continuously throughout the project until it is finished. Different projects may have different ways to break down. However. There are many other test methods that can be applied to back end testing. many users heavily access the same table that has a large number of records. Stress testing It involves subjecting a database to heavy loads. . Back end test methodology Structural testing and functional testing are more effective approaches in back end testing. For example. Component testing will be done early in the development cycle. Structural testing A back end can be broken down into a finite number of testable pieces based on a back end’s structure. To simulate this situation. the two methods may discover different bugs.
too. Columns often have default values defined for them. Relationship Testing in Relational Databases Referential integrity (RI).) Data invariants. Columns often have invariants. in the right order? . Views often implement interesting business logic. These invariants should be tested. (Someone could have accidentally removed this part of the table definition. or not View definitions. and can be easily tested. Data Quality Testing in Relational Databases Default values. Is the field size defined in the application is matching with that in the db. For example. Stored procedures and triggers should be tested just like your application code would be. Access time for queries involving several tables. must exist before the row can be inserted into the Account table. Validate the attribute size. Existence test for an index. Things to look out for include: Does the filtering/select logic work properly? Do you get back the right number of rows? Are you returning the right columns? Are the columns. in particular cascading deletes in which highly coupled "child" rows are deleted when a parent row is deleted.DATABASE TESTING Functionality Testing in Relational Databases Stored procedures and triggers. implemented in the forms of constraints. Existence rules. and rows. We can check whether all the data from the application is being inserted into the database properly. Access time for common queries returning multiple rows. Does the expected index exist or not? Structural Testing in Relational Databases Table existence. should also be validated. Are the default values actually being assigned. Performance Testing of Relational Databases Access time to read/write/delete a single row. defined for them. a number column may be restricted to containing the values 1 through 7. such as a customer row corresponding to an account row. RI rules.
This action might not be possible to undo. Are you sure you want to continue?