Testes Unitrios em PL/SQL

Giovane da Silva Bertol Universidade de Caxias do Sul Centro de Computao e Tecnologia da Informao gsbertol@ucs.br Resumo O presente trabalho apresenta a proposta de uma implantao de melhoria da qualidade de entrega e manuteno de softwares, utilizando tcnicas da Engenharia de Software para testes de unidades. Com o intuito de aumentar a confiabilidade de customizaes realizadas em produtos pr-definidos. Palavras-chaves: Testes de Software,Testes de Unidade.

1. Introduo
A Focco Sistemas de Gesto S/A, atua no ramo de desenvolvimento de sistemas de gesto, visando a criao de solues que se adequam a realidade do cliente. Oferece produtos para segmentos industrias e comerciais, onde os principais e de maior relevncia so: Moveleiro, Metal-Mecnico e Distribuidoras. Ainda, a Focco preza por valores institucionais bem definidos como Parceria e Resultado, onde tanto os clientes e colaboradores esto inseridos e colocados a eles toda a valorizao, a ponto de chegar aos melhores resultados possveis. A organizao funcional da Focco dividida em duas grandes reas: rea de produto que responsvel pelos produtos desenvolvidos pela empresa e rea de servios, subdividida em trs menores reas (Consultoria, Customizao, Infraestrutura) que prestam servios a fim de atender as necessidades especficas do cliente. Neste caso o tema ser com nfase rea de customizao. O setor de customizao responsvel pelo atendimento as demandas especficas do clientes, na qual o produto no contempla. Estas podem ser desenvolvidas especificamente para o cliente ou com modificaes simples porm necessrio no processo requerido pelo cliente. Este estgio tem por finalidade a proposta e a criao de um modelo para testes unitrios, visando melhorar a qualidade da entrega de softwares e consequentemente reduzir a manuteno dos sistemas j em produo.

2. Levantamento da Situao Atual

A rea de customizao da Focco organizada em equipes, divididas por (FAST, Projetos e Chamados) onde cada um possui responsveis organizados por mdulos das reas abrangidas pelo FoccoERP, que o principal produto desenvolvido pela Focco. Os mdulos so as reas de negcio no FoccoERP, por exemplo: Comercial, Suprimentos, Manufatura, entre outros dos sistema A equipe FAST responsvel por pequenos projetos, poucas horas de estimativa e nesta rea os recursos humanos so divididos por mdulos de conhecimento. O atendimento deve ser rpido visando sanar as solicitaes com a maior agilidade possvel. A equipe de Projetos tem por finalidade o atendimento a solicitaes onde

existe a modificao em larga escala do processo padro do sistema. A anlise deve ser criteriosa e o tempo utilizado para atendimento maior. Tambm dividida por nveis de conhecimento dentro dos mdulos. A equipe de Chamados responsvel por atender as solicitaes de correes, realizando desde a anlise, correes de bugs e esclarecimentos aos usurios de customizaes. Est equipe atende a todos os mdulos. As demandas de customizao possuem um fluxo de entrada bem definido, onde normalmente atravs de consultoria prestada pela Focco, o cliente abre uma solicitao para desenvolvimento de um processo especfico, no qual ir representar ganho significativo de produtividade ou lucratividade. Pode-se verificar o processo para requisio, aprovao e desenvolvimento de novas customizaes, conforme figura 1. No anexo A est disponvel o fluxograma completo da customizao.
Figura 1 Recorte do Fluxograma do processo de customizao atual.
Gerao do Cronograma

Analisar / Desenvolver e Testar

Atualizao em Base de Testes

Corrigir

Atualizar em Base de Produo

No

Validado?

Sim

Fonte: Processo de customizao da Focco, adaptado pelo Autor.

Neste processo, o foco para proposta deste estgio, refere-se a melhoria nos processos de: Analisar / Desenvolver e Testar. A anlise do projeto tem por objetivo a avaliao e incremento da descrio dos requisitos do projeto, visando o que dever ser alterado para que os objetivos do cliente sejam alcanados. O desenvolvimento dos requisitos realizado aps a anlise efetivada pelo analista de sistemas, e os testes referente ao o que foi desenvolvido, so realizados posteriormente. Estes testes so realizados pelo desenvolvedor dos componentes e aps pelo analista de sistemas do projeto, sendo manuais e dispendem muito tempo. Aps verificao e validao gerado pacote de atualizao para base de testes do cliente, onde o cliente responsvel por validar e atualizar em testes e

produo, atravs do atualizador automatizado. A tecnologia utilizada para o desenvolvimento de software baseada na arquitetura cliente-servidor, onde existe o banco de dados, Oracle, e processamento da aplicao no cliente. Emprega-se a linguagem de programao PL/SQL, juntamente com Oracle Forms, ferramenta aplicada para o desenvolvimento de aplicaes grficas e Oracle Reports, utilizada para criao de relatrios. Hoje no setor de customizao, no existe processo de testes de software definido, sendo de responsabilidade do desenvolvedor e analista do projeto. Estes testes so manuais e visam manipular as partes do sistema que foram modificadas de acordo com as especificaes do projeto.

3. Objetivos e Proposta de Soluo

Com o espoco dirigido a rotinas da rea de customizao, no produto FoccoERP, busca-se o resultado de melhoria na qualidade de entrega das customizaes no cliente, bem como a reduo de solicitaes abertas para correes de erros, causados por falta de verificao e validao dos requisitos levantados pelo cliente. O objetivo deste trabalho a elaborao de uma proposta de implantao de testes unitrios no processo de desenvolvimento. Estes testes sero baseados em testes de defeitos, validando os componentes dos projetos, tambm haver a obrigatoriedade do vnculo entre os testes e projeto, gerando documentao tcnica com fim de facilitar a preveno de erros em novas agregaes do sistema ou na manuteno do software. 3.1. Metodologia Para a proposta de implantao de testes de unidade, este trabalho ser baseado na metodologia de melhorias de processos de acordo com Sommerville(2011) e para definio de aes na metodologia dos 5Ws. 3.1.1. Melhorias de processos Conforme Sommerville(2011) muitas empresas de software buscam melhorias de processo de software como forma de melhorar a qualidade de seu software, reduzindo custos ou acelerando o processo de desenvolvimento. Somerville(2011) relata que deve ser considerado quais aspectos deseja-se melhorar. De acordo com o objetivo necessrio decidir quais atributos do processo em si, podem ser alvos de melhorias. Conforme mostrado na figura 2, pode-se analisar uma lista de exemplos de atributos, os quais podem ser considerados em um processo de melhoria de software. Estes atributos so definidos de acordo com as caractersticas do processo, ou seja, deve-se escolher o que de interesse na melhoria do processo. O processo de melhoria de software considerado cclico, pois envolve trs subprocessos estes: Medio de processo, anlise de processo e mudanas de processo, Sommerville(2011).

Figura 2 - Atributos de processo

Fonte:Sommerville(2011).

3.1.2. Medio de Processos Medio conforme Somerville(2011) uma forma de encontrar evidncias sobre um processo e mudanas de processos. No entanto as mudanas precisam ser interpretadas com informaes qualitativas, onde devem ser avaliadas com as pessoas envolvidas no processo, com o objetivo de receber suas impresses sobre a eficcia da mudana, bem como identificar de que forma estas pessoas adotaram estas mudanas e como estas tem afetado na prtica real. Para aplicao da proposta de testes de unidade no processo da Focco, as seguintes questes sero avaliadas: O tempo de desenvolvimento dos testes de unidade entre todos os envolvidos. A quantidade de defeitos encontrados pelos testes de unidades. O tempo de correo de erros aps a implantao do novo processo. A qualidade das informaes geradas pelo casos testes para

possveis manutenes de software, portanto, o quanto ser til estes testes de unidade, no momento de sua utilizao para correo de erros. A avaliao do tempo despendido por todos os envolvidos no desenvolvimento de testes, vai seguir alguns critrios para mensurao. Devem ser levados em considerao, o total de horas estimadas para o desenvolvimento do projeto e o tempo utilizado para o desenvolvimento de todos os testes de unidade do projeto. Ser utilizada a seguinte frmula, para avaliao do custo do teste de unidade em um projeto:
Esforo = ((( Tempo Total testes de unidade * 100) / Tempo Total do projeto ) / 100)

Onde o esforo retornado em percentual, utilizando um clculo de proporcionalidade. Por exemplo, um projeto que tem uma estimativa de 40 horas e para o desenvolvimento dos testes foram utilizadas 7 horas, chega -se ao custo total de 17,5% utilizados para os testes de unidade. A meta de esforo para o desenvolvimento de testes de unidade de 2% do total do projeto.
Quadro 1 - Exemplo de clculo para custo de um projeto para testes de unidade

Esforo = ((( 7h * 100) / 40h) / 100)

Fonte: Autor.

Na utilizao de mtricas para a avaliao dos erros encontrados pelos testes de unidade, deve-se considerar o tamanho do projeto e a quantidade de erros que foram encontrados pelos testes de unidade desenvolvidos, para os mesmos. Isto ser utilizado para avaliar dentro de um linha de tempo, a evoluo do processo, atravs de um clculo de proporo conforme abaixo:
PropErros = ((Erros encontrados em um perodo* 100) / Tempo Total dos projetos em um perodo )

A meta utilizada para esta mtrica a diminuio de 5% trimestralmente dos erros encontrados, mostrando assim a qualidade do desenvolvimento, baseado na experincia com os testes de unidade. Com este clculo possvel mensurar se os erros esto diminuindo conforme a experincia com a utilizao de testes de unidade. No grfico 1 demonstrado um exemplo de medio de erros em um determinado perodo.

Grfico 1 Proporo de erros por horas de projeto

Proporo de Erros por Horas de projeto

20,00 15,00 10,00 5,00 0,00 1 2 3 Periodo 17,24 13,28 12,86

Periodo

Fonte: Autor.

Para avaliar o tempo para correo de erros aps a implantao dos testes de unidade, ser necessrio somar a quantidade de solicitaes de correes solucionadas em um ms, antes da implantao de testes, e comparar com a quantidade de resoluo de solicitaes em um ms aps a implantao dos testes de unidade. Por exemplo, no ms de janeiro foram corrigidas 40 solicitaes e aps a implantao foram corrigidas 50 no mesmo espao de tempo. necessrio avaliar um maior espao de tempo, pois a complexidade das solicitaes no sero avaliadas. A medio de processo um item essencial para analisar e julgar se uma melhoria de processo realmente foi satisfatria. Com a utilizao destas mtricas, ser possvel avaliar se o processo pode ser utilizado e aprimorado ou se deve ser abandonado por no obter os resultados esperados. 3.1.3. Anlise do Processo Segundo Sommerville(2011) a anlise de processo o estudo dos processos com o intuito da compreenso de suas principais caractersticas e como estes processos so executados na prtica pelas pessoas envolvidas. Sommerville sugere que a anlise de processo siga as medies, onde a anlise e as medies so intercaladas. necessrio realizar algumas anlises para saber o que medir e a partir das medies, inevitavelmente ser desenvolvido uma melhor compreenso do processo a ser medido. Os objetivos da anlise de processo, tem vrios objetivos especficos, como: O entendimento das atividades envolvidas e seus relacionamentos. O entendimento das atividades do processo e suas medies. Relacionar o processo especfico ou processo em anlise com processos que possam ser comparveis em outro lugar na organizao, ou com processos do mesmo gnero.

Durante a anlise do processo, procura-se levantar informaes sobre problemas e ineficincia do processo e como este processo influenciado por restries organizacionais. Alguns aspectos so identificados por Sommerville(2011) para investigao e anlise do processo. Entre os aspectos apontados por Sommerville(2011), foram selecionados dois como base para a proposta deste estgio: A prtica de engenharia de software e as restries organizacionais. As prticas de Engenharia de Software tem a finalidade de avaliar se existem boas prticas aplicadas ao processo e as restries organizacionais, avaliam quais as restries que afetam o processo atual. 3.1.4. Mudana de processo As mudanas de processo implicam em realizar modificaes no processo existente. As mudanas podem ser realizadas em vrias atividades ou mtodos do processo existente.
...Como sugeri, voc pode fazer isto por meio da introduo de novas prticas, mtodos e ferramentas; mudando a ordem das atividades do processo; melhorando as comunicaes; ou introduzindo novos papis ou responsabilidades. (Sommerville,2011)

De acordo com Sommerville(2011), existem cinco estgios principais no processo de mudanas de processo: Identificao de melhorias, priorizao de melhorias, introduo de mudanas de processo, treinamento de processo e ajuste de mudana. Para desenvolvimento da proposta, baseando-se nos estgios citados por Sommerville(2011), sero seguidas as atividades descritas abaixo: Levantamento de melhorias e viabilidade. o Observaes de melhoria no processo da customizao, bem como a anlise de viabilidade da proposta com o cenrio atual. Estudo e levantamento de informaes sobre testes de software. o Leituras complementares e baseadas em autores da engenharia de software, com o objetivo de nortear os princpios a serem utilizados. Anlise de frameworks para implantao. o Anlise de frameworks j desenvolvidos e validados para uso como facilitador no processo de implantao. Instalao do framework selecionado o Instalao do framework na base de dados. Implementao piloto da proposta. o Implementao da proposta, sendo utilizada em pequenos projetos com mdia de trinta horas de desenvolvimento. Ajustes do processo e modelo o Correes e ajustes do modelo conforme maturidade. Avaliao das mudanas o Mensurao do valor agregado no processo. O quadro 2 demostra o cronograma das principais atividades em ordem sequencial, definidas com data de incio e trmino para o desenvolvimento da

proposta.
Quadro 2 - Cronograma da Proposta

Atividade Levantamento de melhorias e viabilidade Estudo e levantamento de informaes sobre testes de software Anlise de frameworks para implantao Instalao do framework selecionado

Envolvidos Analista Analista Analista e Desenvolvedor Infraestrutura Desenvolvedor

Incio Trmino 14/08/2013 20/08/2013 20/08/2013 10/10/2013 10/10/2013 20/10/2013

e 20/10/2013 30/10/2013 30/10/2013 10/11/2013 10/11/2013 11/11/2013 11/11/2013 20/11/2013

Implementao piloto da Analista e Desenvolvedor proposta Ajustes do processo e Analista e Desenvolvedor modelo Avaliao das mudanas Gerncia da Equipe

Fonte: O autor(2013). Os benefcios esperados com os testes unitrios sero a possibilidade de validar os requisitos descritos pela anlise do projeto, de forma gil sendo um facilitador para testar separadamente cada unidade que compe o requisito, apontando onde ocorreu falha no processo proveniente de alteraes. 3.2. Metodologia de planejamento 5 Ws O mtodo 5 Ws uma ferramenta utilizada para planejamento, facilitando a visualizao das responsabilidades para cada tarefa, devendo ser elaborada as respostas as questes:
Quadro 3 Os 5Ws

What Who

O que? Quem? ao?

Que ao ser executada? Quem ir realizar ou participar da

Where Onde? Onde ser executada esta ao? When Quando? Quando ser executada esta ao? Why Por Que? Porque foi definida esta ao? Fonte: Os 5 Ws sero utilizados para atribuio de tarefas e no modo como sero planejadas no decorrer deste trabalho. 4. Desenvolvimento da proposta Na elaborao do presente trabalho, foram utilizadas algumas etapas baseadas na melhoria de processo citado por Sommerville(2011), conforme pode ser verificado no cronograma apresentado no quadro 1. Estas etapas so apresentadas em sequncia, conforme desenvolvimento deste trabalho.

4.1. Levantamento de melhorias e viabilidade O desenvolvimento da proposta iniciou-se com o estudo e levantamento da viabilidade de incluso de um novo processo, para a melhoria de qualidade de entrega de customizaes no sistema. Neste estgio foi discutido a possibilidade de incluir no fluxo da customizao, uma ao de testes de unidade. Tendo aval da empresa, foi inicializado o estudo de mtodos para aplicao de melhorias em um processo existente. O fluxo atual da customizao, demonstrado na figura 1, considerado rgido, por manter agilidade e resultados financeiros como meta. Por este fato, a incluso de aes para utilizao de testes de unidade, devem ser mensuradas de forma qualitativa, onde no devem demandar muito tempo para seu desenvolvimento. Aps anlise do fluxo existente, foi identificado a necessidade de modificao deste fluxo, para que se adeque a proposta. Esta alterao pode ser visualizada abaixo na figura 3, onde pode ser observado a insero de duas novas aes: A escrita de testes de unidade e rodar testes unitrios. O fluxograma completo est disponvel no anexo B deste projeto.
Figura 3 Fluxograma simplificado do processo customizao proposto

Fonte: O autor.

Com esta modificao no processo de customizao possvel realizar os testes de unidade anterior ao desenvolvimento, pois a partir deste, pode -se analisar o que dever retornar de cada rotina envolvida em um projeto, com fim de validar o retorno de valores esperados, bem como a validao de testes de defeito buscando testar os atributos que esto descritos em acordo com o quadro 2.

4.2. Estudo e levantamento de informaes sobre testes de software Para o prosseguimento da proposta, aps a identificao da melhoria a ser realizada com a implantao de testes de unidade, foi necessrio o embasamento terico com base em dois autores, Sommerville(2011) e Pressman(2006). 4.2.1. Teste de Unidade Conforme Pressman(2006), o teste de unidade o ponto inicial para testes e se concentra em cada componente do software testando -os individualmente, garantido que o mesmo funcione unitariamente. Segundo Sommerville(2007) os testes unitrios, tambm chamados de testes de componentes, so utilizados nos processos de testes de defeito1 onde sua meta expor os erros nestes componentes. O objetivo ser atingido com o desenvolvimento de um modelo para especificaes de criao de testes unitrios, utilizando facilitadores para a realizao do processo. Ser necessrio o entendimento dos conceitos e vantagens obtidas com a utilizao de testes. Com base em Pressman(2006), os testes de unidade enfocam a lgica interna de processamento e as estrutura de dados dentro dos limites de um componente, ou seja, deve ser testado com uma estrutura de dados que possa retornar valores corretos. Para o desenvolvimento de um modelo de testes, Pressman(2006) inclui de forma procedimental condies para o teste de um mdulo. So estes: Interface, Estruturas lgicas de dados, condies limites, caminhos independentes e caminhos de manipulao de erros: a. A interface testada com o objetivo de garantir que a informao flui de acordo tanto no entrada como na sada. b. A estrutura de dados, por sua vez, verificada em modo que garanta que os dados armazenados temporariamente mantenham sua integridade durante todos os passos de execuo do algoritmo. c. Todos os caminhos independentes ao longo da estrutura devem ser exercitados. d. As condies-limites so testadas a fim de garantir que o mdulo opere corretamente nos limites estabelecidos. e. Todos os caminhos de manipulao de erros devem ser testados. De acordo com Pressman(2006), Testes nos limites uma das mais importantes tarefas do teste de unidade. Isto se d pela necessidade de utilizar valores para testes conforme o mximo ou mnimo especificado nos componentes, pois assim provavelmente descobriro erros. 4.3. Anlise de frameworks para implantao Como a empresa no tem interesse em aumentar muito, os custos para o desenvolvimento das customizaes e tambm para aquisio de softwares para testes de unidade em PL/SQL, foi necessrio estudar ferramentas gratuitas e com estabilidade de verso. Aps a realizao da anlise destas ferramentas, uma foi escolhida por aderir-se proposta deste trabalho, o framework de testes de unidade utPLSQL.
Sommerville(2007), teste de defeito so conceituados para a validao de comportamentos indesejveis no sistema.
1

4.3.1. utPLSQL O utPLSQL um framework de testes de unidade para desenvolvimento Oracle, criado por Steven Feuerstein, autor de diversos livros de treinamento em PL/SQL. O utPLSQL foi baseado na metodologia de desenvolvimento gil, XP(Extreme Programming) oferecendo um conjunto de pacotes que podem ser utilizados para testes de unidades de forma eficiente e fcil, assim definindo um processo padro para a instalao, configurao e utilizao do framework. Ainda o utPLSQL independente de plataforma sendo instalado por scripts SQL, tendo a necessidade de configurao manual. Para utilizao do framework so necessrios 4 etapas: Instalao do utPLSQL. Escolher programa a ser testado e identificar os casos de teste. Desenvolver o pacote de teste. Executar os testes. No momento da elaborao deste trabalho, a verso disponvel do utPLSQL a 2.2, estando disponvel para download2 no endereo http://sourceforge.net/projects/utplsql/files/. 4.3.1.1. Instalao do utPLSQL A instalao do framework composta por dois passos simples: A criao de um usurio com privilgios suficientes para instalao atravs de um script PL/SQL e a configurao do framework. A criao de um usurio de escolha facultativa, porm deve -se garantir que o usurio utilizado, tenha as permisses no banco de dados conforme quadro 5:
Quadro 4 - Tabela de Comandos de Permisso SQL

Descrio Criar Sesso Criar Tabela Criar Procedimento Criar Sequncias Criar Vises Criar Sinnimos Publicos
Fonte: O autor.

Comando SQL Create Session Create Table Create Procedure Create Sequence Create View Create Public Synonym

Para definir uma ou vrias permisses a um usurio, conforme as descritas acima no quadro 3, pode ser utilizado um script conforme exemplo abaixo:
Figura 4 Exemplo de script de permisso

Fonte: Documentao utPLSQL 2.2. Download Copiar arquivo de um computador remoto para a mquina local.

Aps a definio de um usurio necessrio inicializar o instalador do utPLSQL, com o comando @ut_i_do install, em um ambiente de administrao de banco de dados, por exemplo o SQL Plus3, onde ut_i_do o scritpt a ser executado, enquanto o install o parmetro enviado. O script encontra-se disponvel na pasta: utplsql22\Code\ e deve-se garantir que est localizado em uma pasta de trabalho do banco de dados. Os envolvidos neste processo de instalao, devem possuir conhecimento e permisses especficas, onde a empresa precisar do apoio da equipe de infraestrutura de banco de dados, responsvel pela criao dos usurios necessrios, bem como a instalao do utPLSQL.
Tabela 1- Perguntas e respostas para definio de caso de teste

Pergunta O qu? Quem? Onde? Quando? Por Que?

Fonte: Autor

Resposta Instalao do utPLSQL Infraestrutura tcnica Infraestrutura interna da Focco Entre os dias 20 e 30 de Novembro de 2013 Necessidade de instalao do framework para desenvolvimento de testes de unidade.

4.3.1.2. Identificar casos de teste Conforme Sommerville(2011) um teste custoso e demorado, por isso necessrio escolher casos efetivos de teste unitrio. Os casos de testes devem demonstrar que, quando utilizado como o esperado, o componente deve retornar o que ele proposto a realizar e se houver defeitos devem ser observados pelos casos de testes. Sero utilizados dois tipos de casos de testes, um que vai validar o comportamento do componente, ou seja, se realmente ele faz o que se prope e outro que ser baseado em diretrizes que, refletiro a experincia anterior com base nos erros frequentes dos desenvolvedores. 4.3.1.2.1.Validao do comportamento do componente Na validao do comportamento do componente, ser analisado se os resultados que se esperam do componente foram atingidos, baseado em retorno dos testes de unidade. Para exemplificar, a tabela 2 representa uma especificao proveniente do cliente, analisada e complementada por um analista de sistemas da equipe de customizao da Focco.
Tabela 2 - Exemplo de Especificao aps anlise

1. Requisito 1
Assunto: Detalhamento: Ser tratado por IDE para que os seguintes campos tenham suas Ferramenta de consulta interativa e processamento em lote, para conexo a um banco de dados Oracle.
3

Clculo da Margem de Contribuio

frmulas alteradas: Percentual Faturamento Lquido = 100% (Sempre) Percentual da Matria Prima = Valor Matria Prima / Faturamento Lquido

Os demais processos permanecem inalterados. Tipo de Alterao: Por IDE Especfica

Fonte: Equipe de customizao, FoccoERP, adaptado pelo autor.

Nesta tabela pode ser observado que, necessrio realizar alterao do clculo da margem de contribuio. A fim de validar o comportamento do componente que, realiza este clculo e retorna o valor final do percentual da matria prima, deve-se prever valores numricos de entrada e sada, para o clculo da formula: %MP = (MP / FAT) * 1004 Estes valores de entrada devem incluir classes numricas que indicam grupos passveis de entrada na rotina, como:
Tabela 3 Grupos de entrada de dados

Grupos Nmeros negativos Zero Nmeros positivos Valores nulos Tratamento de excees
Fonte: Autor

Possveis valores <0 0 >= 1 Nulo Mensagem de Retorno

Atravs destes grupos, deve-se identificar os valores de retorno da rotina e caso estes valores sarem de acordo com o esperado, o comportamento do componente valido. Na tabela 3, existe um grupo de tratamento de exceo, que tambm deve ser validado e treinado, por exemplo, para o clculo da margem de contribuio, uma das especificaes esperada que o percentual da matria prima nunca seja menor que 0, logo se um valor de entrada ser um nmero negativo, uma exceo deve ser lanada informando a existncia de invalidade da operao. Se o valor de entrada para a varivel do valor de faturamento ser 0, a rotina ir lanar uma exceo indicando a existncia de uma diviso por 0, devendo ser tratada e esperada pelo grupo de tratamento de excees. A seguir a tabela 4 demonstra, os valores de entrada passados a rotina de clculo da margem de contribuio e seus resultados esperados, dando-se pela frmula: %MP = (MP / FAT) * 100
4

Percentual da Matria Prima = (Valor Bruto Matria Prima / Valor de Faturamento) *

100

Tabela 4 Possveis entradas e sadas esperadas para clculo da margem de contribuio

Grupos Nmeros negativos Nmeros negativos Zero Nmeros positivos Nmeros positivos Valores nulos Valores nulos
Fonte: Autor.

Entrada MP -5 1000 10 50 1000 Nulo 100

Entrada Sada Esperada FAT %MP 2 Exceo de Valor Negativo - 5000 Exceo de Valor Negativo 0 Exceo de divisor igual a 0 20 2,5 % 10000 10 % 1000 0 %5 Nulo 10 %6

Conforme Sommerville(2011) este grupos numricos podem ser classificados como, a estratgia de parties de equivalncia de entrada e sada, onde necessrio identificar um conjunto de parties em um componente, para que seja possvel escolher os casos de testes. No anexo C apresentado um diagrama com as caractersticas de parties de equivalncia, demostrando o conceito. Portanto, para que um componente seja validado quanto a sua funcionalidade, um teste de unidade deve prever entradas de dados e comparar as sadas esperadas para este teste. 4.3.1.2.2.Validao com base em diretrizes Segundo Sommerville(2011), diretrizes encapsulam conhecimento de tipos de casos de testes que so eficazes a descobrir erros. Estas diretrizes refletem experincias anteriores, dos tipos de erros cometidos com frequncia pelos programadores no desenvolvimento de componentes. Por exemplo, um programador que realiza seus testes em um componente, normalmente fornece valores de entrada que sejam validos, esperando sempre que o resultado esperado seja retornado. Assim com base em erros encontrados em um casos de testes anteriores, onde o programador no force o lanamento de uma exceo, toma-se como uma diretriz a incluso de grupos de valores invlidos de entrada, para um caso de teste, forando assim o lanamento de um exceo que deve ser tratada pelo componente e retornar mensagem ou um valor esperado para um valor invlido. Sommerville(2011) apud Whittaker(2002), inclui alguns exemplos de diretrizes que podem ser usadas no projeto de caso de teste: a) Escolha entradas que forcem o sistema gerar todas as mensagens de erro; b) Projete entradas que causem overflow de buffers de entrada; c) Repita a mesma entrada ou uma srie inmeras vezes; d) Obrigue a gerao de sadas invlidas; e) Obrigue os resultados de clculos a serem muito grandes ou muito pequenos; Conforme a experincia adquirida na elaborao de caso de teste for
5 6

O valor nulo deve ser tratado no caso de clculo. O valor nulo deve ser tratado no caso de clculo.

crescendo, pode-se criar diretrizes prprias que se adequem a organizao. 4.3.1.2.3. Definio de caso de teste Para a definio da ao da elaborao de caso de teste, deve-se descrever as repostas as questes dos 5Ws, para assim construir o planejamento do processo. Na tabela 5 pode-se visualizar que ser definido o caso de teste pelo analista em conjunto com o desenvolvedor. Onde o desenvolvedor poder fornecer informaes importantes, adquiridas com a experincia no desenvolvimento de testes de unidade. A definio de um caso de teste, executada posteriormente ao levantamento, anlise e complemento de requisitos, levantados pelo analista junto ao cliente, com o objetivo de deliberar o desenvolvimento de teste de unidade. Na elaborao de uma caso de teste necessrio levantar o que dever ser testado e como. Para isto, precisa-se estar claro que tipos de dados sero utilizados em cada componente, quais caminhos podero ser seguidos pela rotina.
Tabela 5- Perguntas e respostas para definio de caso de teste

Pergunta O qu? Quem? Onde? Quando? Por Que?

Fonte: Autor

Resposta Definio de caso de teste. Analista de sistema e desenvolvedor No levantamento, anlise e complemento de requisitos e especificaes, realizada por analista da Focco Aps definio de especificaes de cada projeto Desenvolvimento de testes de unidade, baseado em especificaes

Para identificar que tipos de dados ou o que ser testado, deve-se considerar a estrutura interna do componente, seja clculos, persistncia de dados ou validaes de informaes. Uma considerao muito importante validar o maior nmero possvel de caminhos que um componente poder seguir, reconhecendo diferentes entradas para que retornem os valores esperados. Os testes de unidade, podero exercitar testes conforme demonstrado no quadro 5. Tambm possvel escolher outros testes que forem julgados como importantes.
Quadro 5 Testes Exercitados por Unidade

Erros de Clculo Comparao de Dados

Testes Exercitado Precedncia Aritmtica Inicializao Incorreta Falta de Preciso Tipos de Dados diferentes Operadores ou operao lgica incorretos Expectativa de igualdade quando um erro de preciso torna a igualdade improvvel Terminao de ciclos inadequada

ou inexistente Falha na sada, quando iterao divergente Fonte: Autor, baseado em Pressman(2006). Quanto a precedncia aritmtica, o teste de unidade pode mostrar facilmente um erro, pois o valor de entrada dever resultar em um sada esperada, e no caso de precedncia incorreta, este valor ser divergente, assim resultando em falha do componente. O analista ou desenvolvedor tambm poder analisar a inicializao de variveis, por exemplo na execuo de um teste de um componente, o desenvolvedor poder esquecer de declarar uma varivel ou atribuir a ela um valor incorreto, portanto testando todos os caminhos possveis, os erros de inicializao de variveis podero ser identificados. Em outra situao em que um caso de teste pode ser utilizado, o teste de preciso de variveis. Este teste pode avaliar se passando valores, com casas decimais, o componente utiliza formas de arredondamento equivalentes em todo o processo, retornando o valor esperado. Um caso de testes tambm dever prever, dados de entrada que forcem, a iterao dos laos existentes no componente. Estes dados precisam validar os limites dos ndices que o lao atua, para que assim seja testado as possveis situaes que possam gerar erros. Com este planejamento possvel determinar um caso de teste para uma especificao, que deve identificar todos os testes necessrios para a qualidade da entrega do software. 4.3.1.3. Desenvolver um pacote de teste Para a utilizao do utPLSQL, ser necessrio criar um pacote de teste contendo os testes unitrios. Este pacote deve seguir as especificaes e regras do API7, para que o utPLSQL rode corretamente os testes automaticamente. Todos os pacote necessitam ter a seguinte estrutura:
Quadro 6 - Estrutura de um pacote de teste

Estrutura Procedimento de setup Procedimento de desmontagem Os testes de unidade Nomenclatura

Explicao Registrar um teste de unidade e inicializar a estrutura de dados necessria para o teste. Remover toda a estrutura de dados criada para os testes. Procedimentos contendo os testes identificados por um caso de teste. A nomenclatura deve seguir a um padro pr-definido pela ferramenta.

Fonte: 1documentao utPLSQL 2.2, modificado pelo autor

Na elaborao dos pacotes de testes de unidades, foram definidas as

7

Application programmatic interface = Interface de programao de aplicao

questes como base no mtodo 5Ws, conforme tabela 6.

Tabela 6 - 5 Ws desenvolvimento de testes de unidade

Pergunta O qu? Quem? Onde? Quando? Por Que?

Fonte: o autor

Resposta Desenvolvimento de testes de unidade. Analista de sistema e desenvolvedor. Na Focco, rea de customizao. Antes do desenvolvimento. Base para desenvolvimento de componentes.

4.3.1.3.1.Procedimento de Setup Os testes sero chamados pelo procedimento de setup, que inicializa os dados necessrios para a execuo de um teste de unidade. Este procedimento executado antes de qualquer teste. O utPLSQL especfica um cabealho para este procedimento, que deve ter a forma como o exemplo da figura 5, onde o <prefix> o prefixo do teste de unidade e o <package> o nome do pacote para teste.
Figura 5 - Cabealho de um pacote e procedimento de setup

CREATE OR REPLACE PACKAGE <prefix><package> IS PROCEDURE <prefix>setup;

Fonte: Documentao utPLSQ 2.2

A nomenclatura padro do utPLSQL que tanto o nome do pacote, como o nome do procedimento de teste de unidade, tenha como prefixo o ut_, que pode ser visualizado na figura 6.
Figura 6 - Exemplo de criao de pacote

CREATE OR REPLACE PACKAGE ut_<program> IS PROCEDURE ut_setup;

Fonte: Documentao utPLSQL 2.2

Para definir uma estrutura de dados no procedimento de setup, pode -se criar tabelas de dados temporrias, para armazenar informaes para comparao, preencher colees ou mesmo registros em uma varivel global. Abaixo na figura 7 exibido um exemplo de inicializao de uma estrutura de dados.
Figura 7 - Exemplo de inicializao de dados

PROCEDURE ut_setup IS BEGIN ut_teardown; EXECUTE IMMEDIATE 'CREATE TABLE ut_employee AS SELECT * FROM employee'; EXECUTE IMMEDIATE 'CREATE TABLE ut_DEL1 AS SELECT * FROM employee'; EXECUTE IMMEDIATE 'CREATE TABLE ut_DELBY_EMP_DEPT_LOOKUP AS SELECT * FROM employee';

END;
Fonte: Documentao utPLSQL 2.2

No exemplo acima, so inicializados uma estrutura para trs procedimentos de testes de unidade. Para cada um dos testes criada uma tabela temporria que armazena valores da tabela employee, para que sejam comparadas pelo procedimentos. Tambm possvel identificar a chamada para o procedimento ut_teardown, que realiza a desmontagem dos dados, antes de inicializa -los. 4.3.1.3.2.Procedimento de desmontagem O procedimento de desmontagem deve ser chamado antes de rodar todos os testes de unidade. Este procedimento utilizado para limpar dados temporrios gerados pelos testes de unidade. Abaixo na figura 8 demonstrado a criao de um procedimento de desmontagem:
Figura 8 - Exemplo de procedimento de desmontagem

PROCEDURE teardown IS BEGIN mycollection.DELETE; EXECUTE IMMEDIATE 'TRUNCATE TABLE ' || workspace_tab; DBMS_SESSION.FREE_UNUSED_USER_MEMORY; END;
Fonte: Documentao utPLSQL 2.2

Este procedimento declarado dentro de um pacote de testes, onde chamado normalmente no incio do procedimento de setup, para garantir que a estrutura de dados est limpa e pode ser chamada no final de todos os testes de unidade. 4.3.1.3.3. Procedimento de testes de unidade O procedimento de testes de unidade o que vai realizar a validao de um componente. Ele declarado da seguinte forma:
Figura 9 - Exemplo de estrutura de prodimento de testes de unidade

-- Test package for stand alone program CREATE OR REPLACE PACKAGE ut_<package> IS PROCEDURE ut_setup; PROCEDURE ut_teardown; PROCEDURE ut_<program>; END;
Fonte: Documentao utPLSQL 2.2

O corpo de um teste de unidade tem o seguinte formato:

Figura 10 - Exemplo corpo de um procedimento de teste de unidade

PROCEDURE <myprogram> IS BEGIN <run package.myprogram or set up for test> -- call a utAssert assertion to check results: utAssert.<assertion> (...);

<repeat of the above for different test cases> EXCEPTION WHEN OTHERS THEN utAssert.this ( 'Unknown failure of <package.myprogram>: ' || SQLERRM, FALSE); END;
Fonte: Documentao utPLSQL 2.2

Pode-se analisar a chamada do procedimento de setup, que inicializa os dados, como tambm suporte a chamada de procedimentos desenvolvidos para o sistema. Atravs do procedimento utAssert possvel verificar os resultados dos dados. Para que o teste registre uma falha, deve ser tratado as excees, onde necessrio utilizao o procedimento utAssert com segundo parmetro como FALSE. 4.3.1.4. Executar os testes Aps ter definido um pacote de testes com cabealho e corpo necessrio executar o pacote. Para a execuo deste pacote deve -se utilizar um ferramenta de desenvolvimento Oracle, como o SQL Plus, para chamada do comando utPLSQL.test command. Onde o comando utPLSQ.test a rotina do framework e o command o nome do pacote ou procedimento a ser testada. Deve ser ativado a declarao DBMS_OUTPUT para retornar o resultado dos testes. No anexo D demostrado um exemplo da criao de um pacote de testes como o espelho, corpo e execuo. Onde para criao necessrio definir uma PKS que uma definio do pacote, aps o corpo do pacote que ir conter as procedures de inicializao de dados, a de desmontagem e finalmente os testes de unidade e suas especificaes. No exemplo do anexo D testado o retorno de caracteres, com o procedimento de teste de unidade ut_betwn. Este procedimento de teste utiliza a rotina Asserts.eq, que aceita trs parmetros onde: O primeiro a mensagem que identifica o pontos de teste; O segundo que executa uma funo com retorno; O terceiro que valida a igualdade de valor do retorno do segundo parmetro. A funo de retorno betwn que est presente na especificao do pacote str, deve estar disponvel nos procedimentos armazenados na base de dados do Oracle(Store Procedures) ou declarado no prprio corpo do teste no pacote ut_str. A rotina betwn que tem por funo retornar o valor conforme parmetros passados, quando o primeiro parmetro indica o incio de posio de um conjunto de caracteres e o fim de posio retornando o valor entre estes pontos. Para executar o teste de unidade, ser necessrio a utilizao do seguinte comando:
Quadro 7 - Comando para execuo de um pacote de teste

exec utPLSQL.test('str', recompile_in => FALSE)

Fonte: Documentao utPLSQL 2.2, adaptado pelo autor.

O comando exec nativo do banco de dados Oracle para execuo de

processos, o comando utPLSQ.test executa um pacote de teste registrado com a nomenclatura ut_.... No comando utPLSQ.test foram passados dois parmetros o primeiro indicando o pacote de teste e o segundo indicando a no recompilao de todas as rotinas do pacote de teste. Por fim para o fluxo de execuo de testes de unidade, sero atribudas as seguintes questes para o setor de customizao.
Tabela 7 - 5 Ws para execuo de testes de unidade

Pergunta O qu? Quem? Onde? Quando? Por Que?

Fonte: o autor

Resposta Execuo de um teste de unidade. Analista de sistema e desenvolvedor. Na Focco, rea de customizao. Na Antes do desenvolvimento e depois do desenvolvimento. Validao de componentes.

4.4. Implementao do piloto da proposta A implementao foi iniciada com um projeto de 51 horas de desenvolvimento e anlise acoplados. Este projeto contou com 3 envolvidos, o analista de sistemas e dois desenvolvedores. Conforme a proposta deste artigo, iniciou-se a anlise do projeto, pelo analista de sistemas, que identificou os requisitos e elaborou um especificao tcnica, discriminando quais objetos seriam necessrios para o atendimento da solicitao. A especificao tcnica um documento contendo as informaes necessrias para o desenvolvimento, como: Componentes a serem criados e quais requisitos funcionais devero atender. Na tabela 8 pode ser observado a especificao criada:
Tabela 8 - Especificao Tcnica aps anlise

Requisito 1 Assunto: Complemento solicitao de bloqueio de pagamento de ttulos CP

Baixa Manual Ser adicionado um parmetro novo (IDE155086_1_ZEN- USU_LIB_PAG) na IDE j existente com a opo de seleo dos usurios liberados para efetivar o pagamento de Ttulos DUPs quando utilizando o Tipo de Movimento (DIFERENTE do informado na IDE) que contenham ttulos DEV em aberto. Os usurio(s) aqui informados sero os nicos que conseguiram baixar os ttulos do contas a pagar com tipo de movimento DIFERENTE da IDE.

Detalhamento:

Quando for ser efetivada a baixa manual do(s) titulo(s), o sistema deve verificar se o usurio tem permisso para fazer a baixa, e: Se SIM: Ser apresentada uma mensagem ao usurio, fornecedor com ttulos de devoluo em aberto, deseja efetuar a baixa? (sim/no) Se o usurio clicar em sim deve fazer o tratamento padro do FoccoERP traz a mensagem de Fornecedor tem ttulos de devoluo em aberto, deseja Escolher automtico Cancelar, se no para o processo. Se NO: deve trazer a mensagem que o usurio no pode efetivar a baixa do ttulo, devida a no ter permisso para baixar ttulos de fornecedores que contenham ttulos em aberto com tipo de movimento diferente do XX informa-

do na IDE Utilizar a mesma rotina ZEN_FIN_ANALISA_BLOQUEIO_PAG do projeto 155086:

Nota de Entrada O processo que realizado na baixa manual tambm ser realizado na emisso da nota fiscal entrada, ou seja, se o tipo de movimento parametrizado para baixar duplicata (CONTAS_PAGAR-TP_MOV_PG_DEV) for diferente do que est no parmetro de IDE (IDE155086_1_ZEN- TP_MOV), no deixa realizar a baixa. Os usurios que tem permisso para baixar com outros tipos de movimentos tambm devem ser validados, se no tiverem permisso para baixar a duplicata com tipo de movimento diferente da resposta do parmetro, deixa emitir a nota mas no baixar a duplicata.

Utilizar a mesma rotina do projeto ZEN_FIN_ANALISA_BLOQUEIO_PAG Procedure FREC0200: QUITAR_ADIANTAMENTOS_CP

155086:

Pagamento Escritural Quando for gerar uma Remessa de Ttulos para Pagamento Escritural, o sistema deve verificar se os ttulos dos fornecedores que se est selecionando, tem valores em aberto com tipo de documento informado nos parmetros por IDE (IDE155086_1_ZEN- TP_DOC), caso contenham deve trazer a mensagem: Alguns ttulos selecionados para envio do arquivo contem Titulos de DEV em aberto, deseja realmente envia-los nessa Remessa. ESCOLHER SIM NO ENVIAR

Se escolhida a opo NO deve desconsiderar todos os ttulos desses fornecedores. Se escolhida a opo SIM deve levar todos os ttulos. Se for escolhida a opo escolher, deve trazer tela com os ttulos dos fornecedores que contem DEV informados e um check-box para seleo. Programa: FZEN_FIN001 Empresa

Ttulo Parcela Fornecedor Data Emisso Data Vencimento Valor

Tabela Temporria: W_ FZEN_FIN001 IDE para alterar a query NAL_EXECUTA_BUTTON(FPAG0210) Ao final deve ser executado um relatrio:

dos

ttulos:

FI-

Selecionados: ttulos que entraram nas opes SIM e ESCOLHER No considerados: ttulos que entraram na opo NO Relatrio: RZEN_FIN001 Selecionados o Empresa o Ttulo o Parcela o Fornecedor o Data Emisso o Data Vencimento o Valor No Considerados o Empresa o Ttulo o Parcela o Fornecedor o Data Emisso o Data Vencimento o Valor Incluir um totalizador de valores por quebra. Essa seleo deve ser realizada antes de selecionar as opes de tela Relatrio, Consulta e Envia, respeitando que se j foram selecionados os ttulos, ao clicar em Relatrios, por exemplo, ao clicar em Consulta ou ENVIA no faz mas a consistncia, visto que j foi selecionada a opo desejada. Nesta etapa do pagamento escritural tambm deve ser verificado os usurios que tem permisso para pagar duplicatas. Se o usurio no tiver permisso j desconsidera os ttulos e emite o relatrio para verificao.

Tipo de alterao:
Fonte: Focco, adaptado pelo autor.

IDE

Especfica

Conforme a especificao tcnica foi identificado a necessidade da criao

de um componente que pode ser testado pelo processo. Existindo est situao, foi necessrio a elaborao de casos de testes, para posteriormente iniciar a escrita do teste e desenvolvimento do componente. Na elaborao do caso de teste, viu-se a necessidade de criar uma tabela com as entradas possveis e as sadas esperadas, conforme pode ser analisado no anexo E. Com estas informaes foi possvel iniciar o desenvolvimento dos testes. O desenvolvimento dos testes foi baseado na tabela gerada pela elaborao dos casos de testes. Foi criado um teste para cada sequncia dos casos de testes. No final do desenvolvimento foram avaliados: O tempo de gasto de cada envolvido, quantidade de erros encontrados, na rotina aps o desenvolvimento e melhorias identificadas no processo. O tempo utilizado para a implantao dos testes no projeto, foram lanados em tarefas no gerenciador de projetos utilizado pela Focco.
Tabela 9 - Tempo demandando no componente

Projeto

Responsvel
Analista Desenvolvedor 1 Desenvolvedor 2

Tarefa
Elaborao Caso de teste Desenvolvimento dos testes Desenvolvimento Componente

Data Lanamento
17/11/2013 18/11/2013 18/11/2013

Hora Inicial
18:00 20:00

Hora Final
18:30 23:00

Tempo Lanado
30 minutos 180 minutos

Fonte: O autor.

A tabela 9 ilustra a quantidade de minutos despendido para o desenvolvimento dos casos de testes. Este tempo inclui a execuo dos testes. 4.5. Ajustes do processo Foi implementado em apenas um projeto. Neste projeto pde -se identificar a necessidade da criao de uma tabela, contendo as entradas e sadas possveis do objeto. A partir desta tabela foi realizado a escrita dos testes. Alm deste ajuste, foi criado um modelo (template) para a criao dos testes, facilitando o desenvolvimento de novos testes. O exemplo da tabela gerada pode ser analisado no anexo E e o modelo para criao do pacote de teste no anexo F. 4.6. Avalio do processo Conforme descrio deste projeto, foram definidas mtricas de avaliao. Para a avaliao do tempo de desenvolvimento da implantao do projeto, conforme tabela 9, foram utilizadas 3 horas e 30 minutos. Sendo assim o clculo para a mtrica do tempo de desenvolvimento dos testes demostrado abaixo:
Tabela 10 - Mtrica de testes

Projeto
50 horas Fonte: Autor.

Tempo
3 horas e 30 minutos

Frmula
((( 210 mi * 100) / 2400 mi) / 100)

Esforo Total
8,75% Total Projeto

O objetivo a utilizao de 2% do tempo total do projeto, porm para este projeto, foram utilizados 8,75% do total do projeto para a criao dos testes de unidade, valor bem acima do esperado. Deve ser levado em considerao por ser o primeiro projeto a ser implementado. Aps a execuo dos testes, foi identificado apenas 3 erros no componente testado, estes ambos de falta de tratamento de exceo. Para melhor avaliao necessrio, desenvolver testes em novos projetos, para ter dados em forma temporal e comparativas, porm at o fim deste artigo no foi possvel a implantao e mais projetos. A mtrica para medio da qualidade das informaes geradas pelo casos testes, na manutenes de software, no pode ser avaliada pelo fato de no ter surgido situaes onde j existiam o testes gerados. 5. Concluses Este projeto agregou uma base de conhecimento na empresa entre os colaboradores envolvidos, referente a testes de unidade. Pois foi embasado em referncias bibliogrficas expressivas na engenharia de software. Alm de propor uma melhoria de processo, existem vrios objetivos atrelados ao projeto, nos quais a empresa visualiza e pretende-os alcana-los. A proposta foi implantada em um projeto apenas, e com este, foi possvel analisar algumas das mtricas propostas. Estas mtricas no foram alcanadas da forma esperada, porm observou-se o apoio e a dedicao da equipe envolvida, mostrando que o processo pode ser seguido e aprimorado. O setor de customizao para o planejamento de 2014, tem como um dos objetivo melhorar a qualidade dos projetos desenvolvidos e para dar continuidade no processo de implantao necessrio aprimorar os atividades manuais, treinar a equipe explanando os benefcios x o esforo e demonstrar com clareza as mtricas a serem alcanadas. Por fim este projeto teve a finalidade de demostrar uma estrutura para criao de testes de unidade, no desenvolvimento com a linguagem PL/SQL, demostrando os conceitos, trazendo um material prtico explanatrio e propondo uma melhoria no processo da empresa, objetivando agregar valor aos projetos desenvolvidos tanto na viso do cliente como de todos os envolvidos no processo.

Anexo A Fluxograma do processo atual do setor de Customizao

Anexo B Fluxograma do processo proposto na customizao

Anexo C - Exemplo de partio de equivalncia

Anexo D Exemplo de pacote de teste

CREATE OR REPLACE PACKAGE ut_str IS PROCEDURE ut_setup; PROCEDURE ut_teardown; -- For each program to test... PROCEDURE ut_betwn; END ut_str; / CREATE OR REPLACE PACKAGE BODY ut_str IS FUNCTION betwn ( string_in IN VARCHAR2, start_in IN PLS_INTEGER, end_in IN PLS_INTEGER ) RETURN VARCHAR2 IS l_start PLS_INTEGER := start_in; BEGIN IF l_start = 0 THEN l_start := 1; END IF; RETURN (SUBSTR ( string_in, l_start, end_in - l_start + 1 ) ); END; PROCEDURE ut_setup IS BEGIN NULL; END; PROCEDURE ut_teardown IS BEGIN NULL; END; PROCEDURE ut_betwn IS BEGIN utAssert.eq ( 'Typical Valid Usage', str.betwn ('this is a string', 3, 7), 'is is' ); utAssert.eq (

'Test Negative Start', str.betwn ('this is a string', -3, 7), 'ing' ); utAssert.isNULL ( 'Start bigger than end', str.betwn ('this is a string', 3, 1) ); END; END ut_str; /

Anexo E Elaborao de caso de teste.

Nome do pacote de teste: ut_zen_fin_analisa_bloq_pag Parmetros de Entrada Ttulo pi_tp_mov_pg_dev pio_sit_tit Aberto UsuarioLogin pio_sit_tit Ttulo null 1 Aberto 1 No null 1 Aberto 1 No null 0 Aberto 0 Ttulo null 0 Aberto 0 Sem Permis<> PARAM(IDE155086_1_ZEN','TP_MOV) 1 null so 0 Com Permis<> PARAM(IDE155086_1_ZEN','TP_MOV) 0 null so null ='PARAM(IDE155086_1_ZEN','TP_MOV) 1 null null 1 null 1 null null 1 null 0 null null 0 Sadas Esperadas po_mensagem po_tp_msg po_raise_msg <> '''' "' '' '' O fornecedor... O fornecedor... '' '' '' S' null null null I S' I null null null null null null TRUE TRUE null null null

Seq 1 2 3 4

pi_tp_cp_id 1 1 1 1

5 null 6 7 8 9 null null null null

Referncias
SOMMERVILLE,Ian, Engenharia de Software, 8 edio.So Paulo: Pearson Addison Wesley, 2007. PRESSMAN, Roger S.,Egenharia de Software / Roger S. Pressamn; traduo Rosngela Delloso Penteado, reviso tcnica Ferno Stella R. Germano, Jos Carlos Maldonato, Paulo Cesar Masiero. 6.ed. So Paulo : MCGraw-Hill,2006. 720 pp.
http://www.oreillynet.com/pub/a/oreilly/oracle/utplsql/ acessado em 15/09/2013 s 21:20. http://www.portaldomarketing.com.br/Dicionario_de_Marketing/M.htm acessado em 05/10/2013 s 22:30.