Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
167 views

Database Testing

The document discusses testing databases and database migrations. It includes questions and answers about validating data, integrity, performance, procedures, triggers, manual vs automated testing, and testing database migrations.

Uploaded by

Shravan Kumar
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
167 views

Database Testing

The document discusses testing databases and database migrations. It includes questions and answers about validating data, integrity, performance, procedures, triggers, manual vs automated testing, and testing database migrations.

Uploaded by

Shravan Kumar
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 17

1.

Q. 1: What we normally check for in the Database Testing? In Database Testing we need to check, 1) The field size validation 2) Check constraints. 3) Indexes are done or not (for performance related issues) 4) Stored procedures 5) The field size defined in the application is matching with that in the db. Q. 2: What is Database testing? Database testing include the following. 1) Data validity testing: For doing data validity testing you should be good in SQL queries. 2) Data Integrity testing: For data integrity testing you should know referential integrity and different constraints. 3) Performance related to database: For performance related things you should have idea about the table structure and design. 4) Testing of Procedure triggers and functions: For this a clear understanding of testing procedure triggers and functions is required. Database testing is all about testing joins, views, imports and exports, testing the procedures, checking locks, indexing etc. Database testing does not refer to testing of the data in the database. Usually Database administrators perform database testing. Q. 3: How can we do manual testing of database? Explain with an example It involves observing operations that are operated on front-end are effected on the back-end or not. The approach can be explained like: While adding a record through the front-end, check back-end that addition of record is effected or not. It applies to delete, update,......etc. For Example: Enter the employee record in database through the front-end and check manually if the record is added or not to the back-end. Q. 4: What is data-driven test? Data driven test is used to test the multi-numbers of data in a data-table. With help of this we can easily replace the parameters at the same time from different locations e.g.: using .xls sheets. Q. 5: While doing database testing, how do we know that a trigger is fired or not? It can be verified by querying the common audit log where we are able to see if the triggers is fired or not. Q. 6: Is a "A fast database retrieval rate" a testable requirement? No. Since the requirement seems to be ambiguous. The SRS should clearly mention the performance or transaction requirements i.e. It should specify clearly like - Database retrieval rate of 5 microseconds. Q. 7: How to test a DTS package created for data insert update and delete? What should be considered in the above case while testing it? What conditions are to be checked if the data is inserted, updated or deleted using a text files? Data Integrity checks should be performed. IF the database schema is 3rd normal form, then that should be maintained. Check to see if any of the constraints have thrown an error. The most important command will have to be the DELETE command. That is where things can go really wrong. It is important to maintain a backup of the previous database. Q. 8: How to test a SQL Query in QTP or winRunner? Without using database checkpoints? By writing scripting procedure we can connect to the database and can test the database and queries. The exact process should be: 1) Connect to the database: db_connect("query1",DRIVER={drivername};SERVER=server_name; UID=uidname;PWD=password;DBQ=database_name "); 2) Execute the query: db_excecute_query("query1","write query u want to execute"); -Condition to be mentioned3) Disconnect the connection: db_disconnect("query"); Q. 9: How do you test whether a database in updated when information is entered in the

front end? It depends upon the application interface. 1) If your application provides view functionality for the entered data, then you can verify that from front end only. This way Black- box test engineers verify the functionality most of the times. 2) If your application has only data entry from front end and there is no view from the front end, then you have to go to Database and run relevant SQL query. 3) You can also use database checkpoint function in QTP. Q. 10: What steps does a tester take in testing Stored Procedures? First the tester should to go through the requirement, as to why the particular stored procedure is written for. Then check whether all the required indexes, joins, updates, deletions are correct comparing with the tables mentioned in the Stored Procedure. And also he has to ensure whether the Stored Procedure follows the standard format like comments, updated by, etc. Then check the procedure calling name, calling parameters, and expected Reponses for different sets of input parameters. Then run the procedure yourself with database client programs like TOAD, or mysql, or Query Analyzer Rerun the procedure with different parameters, and check results against expected values. Finally, automate the tests with QTP. Q. 11: How do we use SQL queries in QTP? By using output database check point and database check point, Select SQL manual queries option And enter the "select" queries to retrieve data in the database and compare the expected and actual results Q. 12: What SQL statements have you used in Database Testing? The most important statement for database testing is the SELECT statement, which returns data rows from one or multiple tables that satisfies a given set of criteria. We can use other DML (Data Manipulation Language) statements like INSERT, UPDATE and DELTE to manage your test data. We can use DDL (Data Definition Language) statements like CREATE TABLE, ALTER TABLE, and DROP TABLE to manage your test tables. We may need some other commands to view table structures, column definitions, indexes, constraints and store procedures. Q. 13: How to test data loading in Data base testing? Following steps are necessary for Data Load testing. 1) You need to know about source data (table(s), columns, data types and Constraints) 2) You need to know about Target data (table(s), columns, data types and Constraints) 3) You need to check the compatibility of Source and Target. 4) You need to Open corresponding DTS package in SQL Enterprise Manager and run the DTS package (If you are using SQL Server). 5) Then you need to compare the column's data of Source and the Target. 6) You have to check the number to rows of Source and Target. 7) Then you need to update the data in Source and see the change is reflecting in Target or not. 8) You have to check about junk character and NULLs. Q. 14: What are the pre-requisites for writing test cases for database testing? Following pre-requisites are necessary before writing the database test cases. 1) First of all we need to understand the related documentation. 2) Understand the functional requirement of the application thoroughly. 3) Then you have to find out the back end tables used, joins used between the tables, cursors used (if any), triggers used(if any), stored procedures used (if any), input parameter used and output parameters used for developing that requirement. 4) After knowing all these things you have to write the test case with different input values for checking all the paths of SP. Q. 15: What is retesting & how it is different from data driven testing?

Re-execution of a test with different input values is called Re-testing. To validate the project calculations, the test engineer follows retesting method through an automation tool. Retesting is also called Data Driven Testing.

Q. 16: What are the types of data driven tests? There are four types of data driven tests. 1) Dynamic Input submission (key driven test): Sometimes a test engineer conducts retesting with different input values to validate the calculation through dynamic submission. For this input submission, test engineer uses this function in TSL scriipt-- create_input_dialog ("label"); 2) Data Driven Files Through FLAT FILES ( .txt,.doc): Sometimes test engineer conducts re-testing depending upon the contents of the flat file. He collects these files from Old Version databases or from customer side. 3) Data Driven Tests From FRONTEND GREAVES: Sometimes a test engineer creates automation scripts depending upon the front-end objects values such as (a) list (b) menu (c) table (d) data window (e) ocx etc., 4) Data Driven Tests From EXCEL SHEET: sometimes a test engineer follows this type of data driven test to execute the script for multiple inputs. These multiple inputs reside in columns of an excel sheet. We have to collect this test data from the backend tables. Q. 17: Write a query to find the second largest value in a given column of a table To find the second largest salary amount from employee table select max(salary) from employees where pin < (select max(salary) from employees) Select Max(sal) from Emp where Sal < (select Max(sal) from Emp) Q. 18: Now suppose i have 50 records of employee table. 1) I want to find the person who is having 22nd highest salary. 2) I want to delete a person with position number 39 with commission < 100 3) Update record no 45 select emp_id,emp_name, sal from employee a where &n = (select count(distinct(salary)) from employee b where a.sal <=b.sal) &n=22 ( U will be asked to enter the number and then enter for which record u want to retrieve) a.sal <=b.sal (this can be used to retrieve max record) a.sal >=b.sal( this can be used to retrieve min record) select min(sal) from (select distinct sal from employee order by sal desc) where rownum<23 Q. 19: How can we write test cases from Requirements? Do the Requirements represent exact Functionality of AUT Yes, Requirements should represent exact functionality of AUT. First of all you have to analyze the requirement very thoroughly in terms of functionality. Then you have to think about suitable test case design techniques (Black Box design techniques like Equivalence Partitioning, Boundary Value Analysis, Error Guessing and Cause Effect Graphing) for writing the test case. By these concepts you should write a test case which should have the capability of finding the absence of defects. Q. 20: What are the test scenarios to test a database migrated from SQL Server 2005 to SQL Server 2008? We need to check out what was all the enhancement the SQL Server 2008 has in it. We need to design our test case considering the following points. 1) Data type used 2) Length of the data field it should be same as it was in SQL 2005 3) All the jobs should be scheduled properly

Extending IBM Rational Functional Tester with Open Source Tools: Part 1: Using SQuirreL SQL for Database Testing
Setting up Rational Functional Tester Daniel Gouveia (dgouveia@us.ibm.com), Software Technical Sales Specialist, IBM Dan Gouveia is a sales engineer for IBM, primarily focusing is on Rationals functional and performance testing tools. He works with customers on implementing these tools in the most

effective manner, often dealing with topics such as keyword-driven testing, developing automation frameworks, etc. Summary: The typical scenario to test the database side of your application is to perform some sort of insert or delete action within your application, and then verify that the database was properly updated. Because IBM Rational Functional Tester does not provide a native means to work with databases, SQuirreL SQL is a great tool to satisfy your database testing needs. It is an open-source tool written in Java, which makes it an ideal candidate for Rational Functional Testers record and playback automation capabilities. Part 1 of this article shows you how to set up Rational Functional Tester, and Part 2 helps you create scripts. Database testing Many testers are interested in testing the database-side of their application. The typical scenario is that you perform some sort of insert or delete action within your application, and then verify that the database was properly updated. As test groups turn towards automation, this database testing becomes a natural desire. Unfortunately, IBM Rational Functional Tester does not provide a native means to work with databases. SQuirreL SQL is a great tool to satisfy your database testing needs. Upon hearing this, you may develop a sudden case of "Yet Another Tool Syndrome". After all, it is in fact another tool that you do need. The good news is that it is an open-source tool. This gives you the ability to download and use this tool for free. Further, it does provide a level of support, in case you run into issues with the tool. Lastly, it is written in Java. This makes it an ideal candidate for Rational Functional Testers record and playback automation capabilities. This article represents an adaptation of a "getting started" tutorial that has helped customers adopt the use of SQuirreL SQL into their Rational Functional Tester automation. SQuirreL SQL provides a plethora of functionality for the aspiring database-guru. Nonetheless, the intent of this series is to keep things simple while ensuring that it conveys certain key concepts, such as running a query and verifying the result-set. It does not address the numerous remaining capabilities, leaving them for the exploration of inquiring minds like yours. Please note that you should have Rational Functional Tester experience (at least record and playback) before performing the exercises in this article.

Back to top First things first: the prerequisites Before getting started, make sure that you have Rational Functional Tester installed, licensed, and ready to run! This is pretty obvious, but quite critical for you to successfully complete the tasks in this article. Rational Functional Tester

Launch your ODBC Administrator to confirm that you have a System DSN called ClassicsAccess. This should get set up when you install Rational Functional Tester, including IBM Rational Manual Tester. If you do not see it there, you can follow the steps below to acquire the Access database (ClassicsData.mdb) and set up an ODBC DSN for it. The following steps will allow you to acquire the ClassicsDatabase.mdb file and set up a System DSN, using your ODBC Administrator. 1. Download ClassicsData.mdb here. 2. Save it in C:\Temp\ClassicsDatabase. 3. Launch the ODBC Administrator on your computer. (On Microsoft Windows XP, select Start > Control Panel > Administrative Tools > Data Sources (ODBC).) 4. Click the System DSN tab, as shown in Figure 1.

Figure 1. System data sources

5. Click the Add button. 6. Select Microsoft Access Driver (*.mdb), as shown in Figure 2.

Figure 2. Selecting the driver

7. Click the Finish button. 8. Enter ClassicsAccess in the Data Source Name field, as shown in figure 3. Figure 3. Setting up Microsoft Access

9. Click the Select button. 10. Browse to C:\Temp\ClassicsDatabase and select ClassicsData.mdb, as shown in Figure 4.

Figure 4. Selecting the database

11. Click the OK button. 12. Click the OK button (on the ODBC Microsoft Access Setup window) You should now see your ClassicsAccess System DSN in the list, as shown in Figure 5.

Figure 5. A list of system data sources

13. You can click the OK button to close out of the ODBC Data Source Administrator. Java and SQuirreL SQL

You will need to install Java V1.5. You can try Java V1.6, but it may produce inconsistent results. This tutorial was developed with V1.5. Prior versions of Java will not work with SQuirreL SQL. Once you have installed and configured the proper version of Java, you will need to install SQuirreL SQL. The following steps will allow you obtain this software: 1. Browse to http://squirrel-sql.sourceforge.net/ 2. Select Download and Installation. 3. Select Install jars (and source) of SQuirreL <version> for Windows/Linux/others. 4. Select squirrel-sql-<version>-install.jar 5. Save to desired location (for example, C:\Temp\Installs\SQuirreL SQL). To install SQuirreL SQL, run the following command: 1. java -jar squirrel-sql-<version>-install.jar 2. This will take you through a wizard to get things set up. You can simply take the defaults on each page. 3. If you do have certain databases (for instance, DB2, Oracle, MySQL, and so on), there will be a section that asks if you want to install plugins to support those databases. Feel free to choose the ones that you want. The wizard will add extra support, specific to your databases, into the SQuirreL SQL install. This will be functionality that you can explore at a later time.

Back to top SQuirreL SQL configuration: Configuring Database Access Once you have SQuirreL SQL installed, go ahead and launch it. You should configure it for the ClassicsData database. If the Help window appears (Figure 6), close it (or feel free to read through it).

Figure 6. SQuirreL Help window

You need to configure an alias, prior to accessing a database. Since this tutorial is using an Access database (.mdb) file (which has an associated ODBC DSN), you will want to set up the driver using the JDBC-ODBC Bridge driver, as shown in Figure 7. Note: A blue check mark will appear next to drivers that were successfully loaded.

Figure 7. List of drivers

Configuring a database driver The following steps will take you through configuring a database driver in SQuirreL SQL:

1. Click the Add (+) button in the Aliases window, as shown in Figure 8.

Figure 8. Aliases window

2. Fill in the pertinent alias information, as shown in Figure 9. Figure 9. Supply Name, Driver, and so on

Note: You only need to supply the following for your JDBC ODBC Bridge: a. The Name (call it Classics Database) b. The correct Driver (select the JDBC ODBC Bridge driver) c. The correct URL (add ClassicsAccess in place of <alias>, where <alias> = ODBC System DSN (Data Source Name). You do not need to provide a username and password for this ODBC System DSN.

3. Click the Test button. 4. Click the Connect button, as shown in Figure 10 (dont worry about the User name and Password).

Figure 10. Connecting to the Classics Database

5. Click the OK button in the Connection Successful dialog, as shown in Figure 11.

Figure 11. Connection successful

6. Click the OK button in the Alias window. 7. You should now have an alias called: Classics Database, as shown in Figure 12.

Figure 12. Aliases

You are going to want to test out the Classics Database alias to verify that you can see the contents of the Access database (ClassicsData.mdb). To access your database: 1. Double-Click Classics Database in Aliases list. 2. Click the Connect button in the connection window, as shown in Figure 13.

Figure 13. Connecting to the database

3. Verify that you are now connected to the database (you should see information about your database similar to that shown in Figure 14).

Figure 14. Database connection information

Note: You may see a Session Startup dialog that discusses startup performance (Figure 15). You can simply close this. Feel free to explore the Alias Schema Properties on your own at a later point in time. Make sure to select the Don't show this message again checkbox.

Figure 15. Startup dialog

4. After you verify your connection to the database (Figure 16), close the session (click the X in the upper right of the database session window).

Figure 16. Closing the database session window

Back to top A perfect combination: Configuring Rational Functional Tester to use SQuirreL SQL It is now time to configure Rational Functional Tester for use with SQuirreL SQL. To do so, follow the steps below: 1. Launch Rational Functional Tester. 2. Select Configure > Configure Applications for Testing. This will open the Application Configuration Tool, as shown in Figure 17.

Figure 17. Edit the application information

3. Click the Add button. 4. Select the Executable or Batch File radio button, as shown in Figure 18.

Figure 18. Add the application

5. Click the Next button. 6. Browse to the squirrel-sql.bat file, as shown in Figure 19. This launches SQuirreL SQL.

Figure 19. Preparing to launch SQuirreL SQL

7. Click the Finish button. 8. Click the Finish button (in the Application Configuration Tool window, as shown in Figure 20).

Figure 20. Edit the configuration information

Back to top Next Steps This concludes the first article of this two-part series. The next article shows you how to create four scripts against SQL SQuirreL: three specific tasks and one shell to aggregate those tasks. Download ClassicsData.mdb from the downloads section below.

Back to top Download Description Download Name ClassicsData.zip Size 15 KB Download method HTTP

Information about download methods

Resources Learn
y

In the Rational Functional Tester area on developerWorks, get the resources you need to advance your skills with this tool. Browse the technology bookstore for books on these and other technical topics.

Get products and technologies


y

Download a free trial version of Rational Functional Tester.

Discuss
y

Check out developerWorks blogs and get involved in the developerWorks community.

You might also like