Database Stored Procedures

Mary R.
Sweeney
msweeney@sammamishsoftware.com
Copyright Sammamish Software

Services 2003. All rights reserved. 1
Class files and resources
Prerequisites
Knowledge of:
fundamental programming,
basic ANSI SQL, relational database design
testing concepts

Module 1: Creating and testing basic stored
procedures
Module 2: Testing stored procedures using
SQL
Module 3: Using stored procedures for
testing
Module 4 : Introduction to database triggers
Module 5 : Testing for database hacks: the
SQL Injection attack

Creating and testing basic
stored procedures

What are stored procedures?
Why do developer’s use them?
Performance optimization by the DBMS
Security: access can be limited
Robustness against hacks
Why test stored procedures?
Aren’t there test tools out there that can
handle this?

Data access routines reside within the
application source
Routines for
accessing
App source code data
C++, Java, etc.

Data access routines are Routines for
moved to the database accessing
data
backend
App source code

C++, Java, etc.

A. Debugging Stored White box – access to code.
Procedures (Largely a development
effort.)
B. Testing an app’s White box (Unit Test).
Stored Procedures in the
DB Backend
C. Creating and using Black or white box.
Stored Procedures for
Testing
create procedure UpdateProducts
as
update products
set unitprice = unitprice * 1.1;

Create procedure uspValidateUser
(@userName varchar(50),
@userPass varchar(20))
as
select * from users
where userName = @userName and
userPass=@userPass;
create PROCEDURE CustOrderHist2 @CustomerID nchar(5)
AS
if exists (select customerid from customers
where @customerid = customerid)
begin
SELECT ProductName, SUM(Quantity) as Total
FROM Products P join [Order Details] OD
on p.productid = od.productid
join orders o
on O.OrderID = OD.OrderID
join customers c
on C.CustomerID = O.CustomerID
where c.customerid = @customerid
GROUP BY ProductName
end
Create Procedure procedurename as
Begin
SQL-Statements
End;

SELECT text FROM USER_SOURCE
WHERE name = 'INPUTCOMMERCIAL2';
You can also check the status of the stored
procedure, such as whether or not it compiled
properly and is runnable by using this statement:
SELECT object_name, object_type,
status
FROM user_objects
WHERE object_name ='INPUTCOMMERCIAL2';
T-SQL:
EXEC SP_HELPTEXT INPUTCOMMERCIAL;

CREATE Procedure procedurename
(parametername datatype, …)
as
Begin
SQL-Statements
End;

SQL> execute inputCommercial2
(&propid, &propname, &propdesc,
&loan);
Enter value for propid: 99
Enter value for propname: 'prop1'
Enter value for propdesc: 'desc'
Enter value for loan: 50000

declare
cursor get_prop_data is
SELECT id, name, description
from COMMERCIAL_PROPERTY;
for cl_rec in get_prop_data loop

/* code goes here */
end loop
Demo 1: Creating and testing a Simple Stored
Procedure

Testing stored
procedures using
SQL

Set up a test harness/ test bed which bypasses
the front End
GUI or Web
Front End
SQL Harness/
Test Bed

Creating Test harnesses for
Ad hoc testing
You can set up your tests for database values and
objects using Structured Query Language within the
SQL*Plus and/or Query Analyzer environments.
To do this you create independent SQL statements.
In PL/SQL these are called anonymous, or unnamed, blocks.

Using nocount:
Set nocount on|off

Stops the message indicating the
number of rows affected by a
Transact-SQL statement from being
returned as part of the results.

set nocount on
select 'Starting Tests: ',
current_timestamp;
delete commercial_property;
exec inputCommercial2 10, ‘TestProp1',
‘Test Description1', 22;
select * from Commercial_Property;
select 'Ending Tests: ',
current_timestamp;
set nocount off

Using the declare statement:
In PL/SQL variables are declared like this:
Declare
e_empno NUMBER := &Empnum;
e_exists varchar2(3) := 'NO ';
T-SQL:
declare @e_expected char(3),
@e_exists char(3) ;
set @e_expected = 'YES';
set @e_exists = 'NO ';
Declare
/* variable declarations */
Begin
/* code */
End;

if exists
(select * from COMMERCIAL_PROPERTY
where ID = 192)
select 'Test Pass: Property exists ';
else
select 'Test Fail: Property doesn’’t exist ';

SQL 2000’s T-SQL does not include exception
handling however you can check for system errors
using the @@Error global variable.
If a system error is generated during a test, the
@@Error variable is automatically loaded with the
error number.
You can check this value and take appropriate action
such as roll back a transaction, if necessary.
For testers this allows you to check for certain
expected kinds of errors.

inputCommercial2 10, 'Yet another property', 'a
description', 22;
if @@error = 2627
select 'Test failure: Duplicate PK not handled by
Proc'

Declare
Begin
/* code */
Exception
when NO_DATA_FOUND then
/* code */
End;

SQL> spool emptestresults.txt
SQL> select * from emp;
SQL> spool off
SQL>

Demo 2: Testing stored procedures using a SQL
script

Using stored procedures
for testing

Can be stored within the target database or
within a linked database
Can use test data stored within the database
for a data driven test
Stored
Procedure
tests

Simply preface your existing tests with
a Stored procedure Create statement:
Create Procedure
Tst_InputCommercial2
As
/* your test code goes here! */

SQL cursors:
DECLARE tnames_cursor CURSOR
FOR
SELECT au_lname FROM authors
OPEN tnames_cursor
DECLARE @authname varchar(40)
FETCH NEXT FROM tnames_cursor INTO
@authname

/*testing using testdata table
values: */
for test_rec in get_test_data

loop
inputCommercial2
(test_rec.id, test_rec.name,
test_rec.description,
test_rec.primary_loan_id);
end loop;
Demo 3:
Testing a stored procedure with a stored procedure

Basic functionality: Test input and output parameters using
standard techniques (boundary analysis, parameter
validation, etc.)
Should have error-handling and existence checks
Triggered stored procedure functionality
Stored procedures which include queries that cover the
entire table i.e., table scans (performance)
SPs which return nothing (performance)
System/application errors returned to the user (Incomplete
or ineffective or no error-handling)
Corrupt data results
Tester’s checklist:
What to look for (cont)
No use of transactions
Excess use of temp tables and cursors
No data validation for required
parameters
No return of status
Parameters:
Precision mismatches;
lack of default values
Susceptibility to deliberate, destructive
attacks, such as SQL Injection attacks
DevPartner by CompuWare (DB2, Oracle,
SQL Server)
Visual Studio .Net (for SQL Server)
SQL Navigator by Quest (for Oracle)
Quest “Code Tester” (Steven Feuerstein)
NUnit(Windows) JUnit (Unix) csUnit
DbUnit

Scripting languages can be effectively utilized
to exercise stored procedures.
VBScript
Perl
Ruby
Javascript/Jscript
Data access languages: PHP or ADO

they typically have a light footprint, i.e., are easy
on the test system.
they can directly and quickly emulate the calls
being used by the application, especially if you
use the same scripting language as the
application! (Be careful to avoid replicating
application development.)
test scripts are smaller, more focused and are
able to isolate bugs better than using the
application to do the test.
Dim conn, rsTestData, i, strMsg
Set conn = CreateObject("ADODB.Connection")
conn.Open
"Provider=MSDAORA.1;Password=tiger;User
ID=scott"
Set rsTestData =
CreateObject("ADODB.Recordset")
rsTestData.CursorType = 1
rsTestData.Open "select * from EMP", conn
rsTestData.MoveFirst
<Job ID="PerlTest1">
<script language=PerlScript runat=server>
my $conn =
$Wscript->CreateObject('ADODB.Connection');
$conn->Open('NWDsn');
if($conn->{State} == 1) {
$WScript->Echo("Connection Successful!")}
else {$WScript->Echo("Connection Failed");}
my $adOpenKeySet_CursorType = 1;
my $rst = $WScript->CreateObject('ADODB.Recordset');
my $rst2 = $WScript->CreateObject('ADODB.Recordset');
$rst->Open('SELECT * FROM TestData', $conn,
$adOpenKeySet_CursorType);
$WScript->Echo("There are ".$rst->{RecordCount}."
records in the Recordset");

Php/Perl: ADO/VBScript
Open source software Runs only on all
Can run on Linux, Windows OS
Windows, Unix Freely downloadable;
systems pre-installed on
Widely used; lots of Windows
documentation Widely used; lots of
Perl Oracle module documentation
has issues My best choice for
Windows

Introduction to database
Triggers

Triggers are a special type of stored procedure
that is applied to tables.
Complex procedural data integrity methods and
business logic can be added to a database using
triggers.
A trigger is a set of actions that execute
automatically whenever a specified event occurs
to a specified table.
Events can be an insert, update, delete, or read operation.
The trigger can run before or after the event.

Referential Integrity Constraints should be
used before Triggers
Complex procedural data integrity methods
and business logic can be added to a database
using triggers.
A single trigger can run multiple actions, and it
can be fired by more than one event. For
example, you can create a single trigger that
runs when any valid event, INSERT, UPDATE,
or DELETE occurs.

Triggers cannot be fired manually.
An important feature of triggers is that

unsuccessful transactions are automatically
rolled back.

CREATE TRIGGER reminder
ON Orders
FOR UPDATE
AS
select 'A row was just modified in the Orders
table';

The main clauses in a CREATE TRIGGER statement can be
summarized as follows:
CREATE TRIGGER trigger_name

ON table_name or v
FOR trigger_class and trigger_type(s)
AS SQL statements

Triggers are an important way that business
logic is implemented in a database
Triggers have automatic behavior that can be
complex and can cause significant damage if
incorrect
Triggers are “expensive” and should be used
judiciously

Graph trigger effects
Trigger effect graph
Table Trigger Events Affected Affected
Customers trgOrdUpd U Orders
trgCustLog U, D, I CustLogtbl
Orders trgOrdLog U, D, I OrdLogtbl
Design Test cases for each trigger effect

Customer table test cases:
TC1: Add record to cust; Check custlog
TC2: Update cust record; Check custlog; check Orders
table
TC3?

Map out trigger effects
Trigger effect map
Customers
table Orders
Table
TrgOrdUp
d TrgOrdLog
TrgCustLog
Custome Orders
r log
log table
table

Create a log table to track trigger effects
Encourage developers to do this if you don’t have
permission:
Create Table Custlogtbl
(Eventtime DATETIME not null, SQL Server
Eventtype VARCHAR(20) not null,
CustID varchar(5));
Create Table Custlogtbl
(Eventtime DATE not null,
Eventtype VARCHAR2(255) not null, Oracle
CustID varchar(5));

Sweeney:
Sweeney:
Demo
Demo
triggerlogexample.sql
triggerlogexample.sql
A trigger for logging table changes:
Create Trigger trgCustLog

on Customers
after update
as
begin
insert into custlogtbl
select current_timestamp, 'Updated', customerid from
deleted;
end;
Triggers can be tested manually and/or
tracked by using log tables
Add the Trigger effect graph and Trigger effect
map to your documentation artifacts

Database Security: Testing
for database hacks

ABC Corp. Login Form:
Username: ‘or 1=1; drop table user; --
Password:
Turns this query:
Select username from user where username = ‘someuser’
and pass = ‘somepass’
Into this query:
Select username from user where username = ‘’ or 1 = 1;
drop table user; -- and pass = ‘’
Demo 5:
Develop at least two test cases to test for a SQL Injection
attack

Review
Where do we go from here?

Module 1: Creating and testing basic stored
procedures
Module 2: Testing stored procedures using
SQL
Module 3: Using stored procedures for
testing
Module 4 : Introduction to Triggers
Module 5 : Testing for database hacks: the
SQL Injection attack
Course on scripting language
Advanced RDBMS courses
Resources in Appendix A
STQE www.sqe.com
QA forums
Yahoo group: Agile databases


Database Stored Procedures

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Database Stored Procedures

Hochgeladen von

Copyright:

Verfügbare Formate

Mary R.

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

App source code

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

for cl_rec in get_prop_data loop

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Set nocount on|off

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

for test_rec in get_test_data

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

An important feature of triggers is that

Copyright Sammamish Software

Copyright Sammamish Software

CREATE TRIGGER trigger_name

Copyright Sammamish Software

Copyright Sammamish Software

Design Test cases for each trigger effect

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

A trigger for logging table changes:

Create Trigger trgCustLog

Copyright Sammamish Software

Copyright Sammamish Software

Username: ‘or 1=1; drop table user; --

Copyright Sammamish Software

Copyright Sammamish Software

Copyright Sammamish Software

Das könnte Ihnen auch gefallen