Академический Документы
Профессиональный Документы
Культура Документы
The database persists data that your application (and organization) depends on. The data
thus persisted is most often of mission-critical nature and a key asset for the organization.
Also, many of today's data-enabled applications implement a fair amount of their
functionality and business logic in the database itself. For an enterprise class application,
the data in the database would be accessed and updated (insert/modify/delete)
simultaneously by a large number of users (think thousands to millions depending on the
scale of your application's usage).
The above statements highlight a few areas where database testing is needed. One, to
validate the quality of data being persisted. Two, if we plan to test the application code, it
is imperative that we also test the code in the database which implements the business
functionality and three, we should plan for non-functional database testing to support the
usage of the database in a real-world deployment scenario.
Testing the quality of the data may be approached in three ways - data validity testing,
data integrity testing and data format testing.
a) Data validity testing - is done to verify the validity of the data that is stored in the
database. When data is entered via the front end application, check if the data is correctly
updated in the back-end database. Apart from the positive checks, look for other behavior
such as data truncation, verify how null/empty field values are handled, verify how
special characters or code snippets are handled in the database. Check that the right
columns in the right tables are being updated. Data validity testing normally involves use
of SQL queries to validate the data.
c) Data format testing - involves verifying the size and type of fields that store data in the
database with those that accept data in the application. This can help identify mismatches
between the type or size of data that is accepted by the front-end vs what the database can
store. Example: the application may accept text data but try to store in a numeric or date
field in the database or else the application may accept data of greater length than the
max length for the corresponding field in the database. This may not throw errors during
routine application usage but may store incorrect or erroneous data in the database which
could have repercussions elsewhere or at a later stage
2. Database code testing - involves testing the code in the database which implements
business logic and functionality. Examples of such code include, stored procedures,
views (read-only/updateable) and event driven items such as triggers. Each stored
procedure is tested distinctly for its functionality. When a stored procedure implements
multiple functions, each function is tested separately. Stored procedure testing would
look at testing the arguments that are passed to the stored procedure in terms of the
number, type and order of arguments plus the return value. Both positive and negative
tests can be devised to test stored procedures. Views both read only and updateable are
tested either as stored queries that dynamically retrieve values from the database and/or
allow updates to the database. In case where updates are allowed, data validity and
integrity testing is done. Event driven items are tested by verifying the events that could
trigger actions and the actions themselves for functional correctness