Database testing Most of the Web sites typically have User profile, stores catalogs, shopping Cart, and order information in the database. Since the database stores lot of information about the site and user so it must be tested thoroughly. The purpose of database testing is to determine how well the database meets requirements. Following are the main reason to test a database: Relevance of Search Results The Search option is one of the most frequently used functions of online databases. Generally users uses the Search results to go directly to other page instead of going stepby-step and also to save the time and effort. It was found that Search option of lots of Web site is not working properly. Which makes a user annoyed. Just to make them happy be sure that the Search option of your Web site is working properly and displaying the proper result. A team of people that are not a part of the development team should carry out testing for Search relevance. This team assumes the role of the online customer and tries out random Search options with different keywords. The Search results are recorded by the percentage of relevance to the keyword. At the end of the testing process, the team comes up with a series of recommendations. This can be incorporated into the database Search options. Query Response Time The query response time is essential in online transactions. The turnaround time for responding to queries in a database must be short. The results from this testing may help to identify problems, such as bottlenecks in the network, specific queries, the database structure, or the hardware. Data integrity A database stores an important data of catalog, pricing, shipping tables, tax tables, order database, and customer information. Testing must verify the correctness of the stored data. Therefore, testing should be performed on a regular basis because data changes over time. Data Validity Errors caused due to incorrect data entry, called data validation errors, are probably the most common data related errors. These errors are also the most difficult to detect in the system. These errors are typically caused when a large volume of data is entered in a short time frame. For example, $67 can be entered as $76 by mistake. The data entered is therefore invalid.

You can reduce data validity errors. Use the data validation rules in the data fields. E.g. the date field in a database uses the MM/DD/YYYY format. A developer can incorporate a data validation rule, such that MM does not exceed 12; DD does not exceed 31. In many cases, simple field validation rules are unable to detect data validity errors. Here, queries can be used to validate data fields. For example, a query can be written to compare the sum of the numbers in the database data field with the original sum of numbers from the source. A difference between the figures indicates an error in at least one data element. Recovery of Data Another test that is performed on database software is the Recovery of data test. This test involves forcing the system to fail in a variety of ways to ensure that the system recovers from faults and resumes processing within a pre-defined period of time. The system is fault-tolerant, which means that processing faults do not halt the overall functioning of the system. Data recovery and restart are correct in case of auto-recovery. If recovery requires human intervention, then the mean time to repair the database is within pre-defined acceptable limits. Database Performance Testing Scalability testing, performance monitoring, pinpointing performance anomalies, validating Service Level Agreements. Database performance problems can make you look bad. In an age where response time and accelerated access to information is quickly becoming a company's most critical issue, slow or poor performing SQL transactions can cause misinformed users to lay the performance blame squarely on you or your application's shoulders. When thousands of SQL transactions and procedures are involved, the performance issues become exponentially difficult to analyze. Pinpointing the problem can be as difficult and time consuming as finding a needle in a haystack. To solve this problem effectively, DBAs and IT staff need to be able to capture, analyze and optimize the SQL that is passed between the database and your application and your users. Furthermore, you want to load and stress test both the database and the application to ensure that the addition of extra users does not introduce other performance problems. ---------------------Database Testing : ---------------------Background The overall objective of database testing is to establish the interoperability capabilities between database servers and their respective clients in different IS systems. Underlying this are the assumptions that within an IS system, data, regardless of how it is accessed or displayed, is stored within a structured database, and that a country might desire to share a portion of this data with another country’s IS. An example of this would be Order of Battle

Data (ORBAT).ORBAT is most often stored as records within a database, representing units and information about them. A client application is in many cases written to access this data across a network, and then to display the data, or to "pass" it off to another (GIS) application for viewing. It is unlikely the different nations’ IS systems would use the same clients or servers to perform this function. However, if an IS system can access the data within a database of another IS system, then operational information can still be successfully passed amongst allies. The basic objective of these tests then is not to standarize data formats or structures (including data dictionaries), but to examine technical options to allow for dynamic sharing of the data within these databases, through means other than their own proprietarily designed architectures. It is worth noting that only two countries and three operational systems are to attempt these tests during CE 99; Sweden (Fenix), US (PIMS & GCCS). Test Procedures To assist testing, a sample schema and database will be provided by the all testers. The databases accessed should be single table (non-relational), and consist of no fewer than 50 records. Each tester will provide a schema of the database table used, together with any other specifics needed by the other testers, such as database name, port, etc, to facilitate connections. Also, as part of preparation for these tests, all testers should identify particular software items they might need to connect to other database systems, and ensure those items are brought to the Exercise. (E.G.ODBC drivers for databases to be tested). The testing will proceed under three loose stages: Attempting to access data in IS A from a client in IS B (through, e.g. ODBC connections). Adding "Gateway" applications to the database server that would facilitate other clients access (e.g. Web Server with Database connectivity). Performing manual dumps of data from IS A, to IS B for importation into another database system. Detailed Tests Test 1. Using any ODBC compatible client application part of the current baseline of IS A, IS A should attempt to access all records within the designated database on IS B. This test should be performed with the existing software configuration of both IS’s (including currently loaded ODBC drivers)

Criteria : Green : The client application of IS A successfully connects to the database of IS B, and the data is available for view or transfer. Amber : The client application of IS A successfully connects to the database of IS B, but the particular database to be accessed is unavailable for view due to security, or other constraints. Red : The client application of IS A cannot open a connection to the database system of IS B. Note : If no applications currently resident on IS A are ODBC capable, this test should not be attempted. Test 2. Repeat Test 1, after attempting to load any other ODBC drivers required by IS A or B, and after making other configuration changes (e.g. creating additional database log in accounts) as deemed to be required. Criteria : Green : The client application of IS A successfully connects to the database of IS B, and the data is available for view or transfer. Amber : The client application of IS A successfully connects to the database of IS B, but the particular database to be accessed is unavailable for view due to security, or other constraints. Red : The client application of IS A cannot open a connection to the database system of IS B. Note : If no applications currently resident on IS A are ODBC capable, this test should not be attempted. Test 3 This test proceeds under the assumption that the server of a particular IS either has a constituent web server application, or is capable of adding one to its configuration. The test will highlight the ability to provide database access from one IS to another, utilizing on a client a web browser, and on a server a web server in conjunction with a database. To proceed with this test, any method of web to database access (API, CGI, etc) will be permitted, as long as local technical support to create these interfaces is available, and all actions can be fully documented.

Step 1 : Add a web server application to IS of country A. Criteria : Green : A web server can be added, and is accessible from a web browser using a TCP/IP connection. Amber : A web server can be added, but it’s performance and accessibility across a TCP/IP network is intermittent. Red : A Web server cannot be added, or it cannot be accessed across a TCP/IP network. Step 2 : Add a web client (browser) to IS of country B. Criteria : Green: A web browser is already part of the current baseline of Country B’s IS, or the browser is added without problem. Amber : A web browser is added to a client on IS B, but needs additional configuration to connect to a web server of IS A. Red : A browser cannot be added to a client of IS B, or is added but cannot connect to a web server of IS A. Step 3 : Add either an API (Application Programming Interface), CGI (Common Gateway Interface), or other proprietary package to enable web server connections to the database of IS on country A. Create a series of HTML pages that utilize these interfaces and connections to provide for performing a query of the sample database on Country A’s IS. Have a web browser on Country B’s IS open this page and attempt to perform a query. Criteria : Green : The web browser on Country B’s IS can open the page, input a desired query, execute it, and receive a valid number of returns from the database of Country A’s IS. Amber : The web browser on Country B’s IS can open the page, input a desired query, execute it, and receives an incorrect return from the database of Country A’s IS. Red : Either the page does not appear, or the interface does not open a database connection at all.

Test 4. The object of this test is to demonstrate lowest common denominator interoperability between database systems of differing IS’s. If no automated process exists for accessing data through combinations of clients, servers, or third party middleware, this test should demonstrate the ability for an IS database to perform regular "extracts" from its system of designated data to pass onto another nation’s IS, which could then, given a valid schema for this data, import it into it’s own database, providing access through it’s own client system. This method is currently in use by several differing IS systems, especially of different classification levels, to provide for the basic ability to exchange information. Step 1 : Perform a dump or extraction of the data in the database of IS A in a structured format (IDBTF, text delimited, etc), and provide this information, along with a full schema for the data, to Country B. Country B should attempt to load this information into either an existing database, or to create a new database for its storage. A client on Country B’s IS should then try to access the information. Criteria : Green : The data format can be analysed and manipulated as necessary by Country B, to enable it’s importation into a database on Country B’s IS. This data can be accessed without difficulty from a Client application on Country B’s IS. Amber : The data can be successfully imported into Country B’s IS database, but is unavailable from a client on Country B’s IS, due to differences in the nature of the data. Red : The data can not be imported into a database on Country B’s IS.

Sign up to vote on this title
UsefulNot useful