Testes Unitários em PL/SQL

Giovane da Silva Bertol

Universidade de Caxias do Sul

Centro de Computação e Tecnologia da Informação

gsbertol@ucs.br

Resumo

O presente trabalho apresenta a proposta de uma implantação de melhoria da qualidade de entrega e manutenção de softwares, utilizando técnicas da Engenharia de Software para testes de unidades. Com o intuito de aumentar a confiabilidade de customizações realizadas em produtos pré-definidos.

Palavras-chaves: Testes de Software,Testes de Unidade.

1. Introdução A Focco Sistemas de Gestão S/A, atua no ramo de desenvolvimento de

sistemas de gestão, visando a criação de soluções que se adequam a realidade do cliente. Oferece produtos para segmentos industrias e comerciais, onde os principais e de maior relevância são: Moveleiro, Metal-Mecânico e Distribuidoras. Ainda, a Focco preza por valores institucionais bem definidos como Parceria e Resultado, onde tanto os clientes e colaboradores estão inseridos e colocados a eles toda a valorização, a ponto de chegar aos melhores resultados possíveis.

A organização funcional da Focco é dividida em duas grandes áreas: área de produto que é responsável pelos produtos desenvolvidos pela empresa e área de serviços, subdividida em três menores áreas (Consultoria, Customização, Infraestrutura) que prestam serviços a fim de atender as necessidades específicas do cliente. Neste caso o tema será com ênfase à área de customização.

O setor de customização é responsável pelo atendimento as demandas específicas do clientes, na qual o produto não contempla. Estas podem ser desenvolvidas especificamente para o cliente ou com modificações simples porém necessário no processo requerido pelo cliente.

Este estágio tem por finalidade a proposta e a criação de um modelo para testes unitários, visando melhorar a qualidade da entrega de softwares e consequentemente reduzir a manutenção dos sistemas já em produção.

2. Levantamento da Situação Atual A área de customização da Focco é organizada em equipes, divididas por

(FAST, Projetos e Chamados) onde cada um possui responsáveis organizados por módulos das áreas abrangidas pelo FoccoERP, que é o principal produto desenvolvido pela Focco.

Os módulos são as áreas de negócio no FoccoERP, por exemplo: Comercial, Suprimentos, Manufatura, entre outros dos sistema

A equipe FAST é responsável por pequenos projetos, poucas horas de estimativa e nesta área os recursos humanos são divididos por módulos de conhecimento. O atendimento deve ser rápido visando sanar as solicitações com a maior agilidade possível.

A equipe de Projetos tem por finalidade o atendimento a solicitações onde

existe a modificação em larga escala do processo padrão do sistema. A análise deve ser criteriosa e o tempo utilizado para atendimento é maior. Também é dividida por níveis de conhecimento dentro dos módulos.

A equipe de Chamados é responsável por atender as solicitações de correções, realizando desde a análise, correções de bugs e esclarecimentos aos usuários de customizações. Está equipe atende a todos os módulos.

As demandas de customização possuem um fluxo de entrada bem definido, onde normalmente através de consultoria prestada pela Focco, o cliente abre uma solicitação para desenvolvimento de um processo específico, no qual irá representar ganho significativo de produtividade ou lucratividade.

Pode-se verificar o processo para requisição, aprovação e desenvolvimento de novas customizações, conforme figura 1. No anexo A está disponível o fluxograma completo da customização.

Figura 1 – Recorte do Fluxograma do processo de customização atual.

Analisar / Desenvolver e

Testar

Atualização em Base de Testes

Validado?

Atualizar em Base de Produção

Corrigir

Não

Sim

Geração do Cronograma

Fonte: Processo de customização da Focco, adaptado pelo Autor.

Neste processo, o foco para proposta deste estágio, refere-se a melhoria

nos processos de: Analisar / Desenvolver e Testar. A análise do projeto tem por objetivo a avaliação e incremento da descrição

dos requisitos do projeto, visando o que deverá ser alterado para que os objetivos do cliente sejam alcançados. O desenvolvimento dos requisitos é realizado após a análise efetivada pelo analista de sistemas, e os testes referente ao o que foi desenvolvido, são realizados posteriormente. Estes testes são realizados pelo desenvolvedor dos componentes e após pelo analista de sistemas do projeto, sendo manuais e dispendem muito tempo.

Após verificação e validação é gerado pacote de atualização para base de testes do cliente, onde o cliente é responsável por validar e atualizar em testes e

produção, através 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 aplicação no cliente. Emprega-se a linguagem de programação PL/SQL, juntamente com Oracle Forms, ferramenta aplicada para o desenvolvimento de aplicações gráficas e Oracle Reports, utilizada para criação de relatórios.

Hoje no setor de customização, não existe processo de testes de software definido, sendo de responsabilidade do desenvolvedor e analista do projeto. Estes testes são manuais e visam manipular as partes do sistema que foram modificadas de acordo com as especificações do projeto.

3. Objetivos e Proposta de Solução Com o espoco dirigido a rotinas da área de customização, no produto

FoccoERP, busca-se o resultado de melhoria na qualidade de entrega das customizações no cliente, bem como a redução de solicitações abertas para correções de erros, causados por falta de verificação e validação dos requisitos levantados pelo cliente. O objetivo deste trabalho é a elaboração de uma proposta de implantação de testes unitários no processo de desenvolvimento. Estes testes serão baseados em testes de defeitos, validando os componentes dos projetos, também haverá a obrigatoriedade do vínculo entre os testes e projeto, gerando documentação técnica com fim de facilitar a prevenção de erros em novas agregações do sistema ou na manutenção do software.

3.1. Metodologia

Para a proposta de implantação de testes de unidade, este trabalho será baseado na metodologia de melhorias de processos de acordo com Sommerville(2011) e para definição de ações 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 é necessário 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 são definidos de acordo com as características do processo, ou seja, deve-se escolher o que é de interesse na melhoria do processo.

O processo de melhoria de software é considerado cíclico, pois envolve três subprocessos estes: Medição de processo, análise de processo e mudanças de processo, Sommerville(2011).

Figura 2 - Atributos de processo

Fonte:Sommerville(2011).

3.1.2. Medição de Processos

Medição conforme Somerville(2011) é uma forma de encontrar evidências sobre um processo e mudanças de processos.

No entanto as mudanças precisam ser interpretadas com informações qualitativas, onde devem ser avaliadas com as pessoas envolvidas no processo, com o objetivo de receber suas impressões sobre a eficácia da mudança, bem como identificar de que forma estas pessoas adotaram estas mudanças e como estas tem afetado na prática real.

Para aplicação da proposta de testes de unidade no processo da Focco, as seguintes questões serão 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 correção de erros após a implantação do novo processo.

A qualidade das informações geradas pelo casos testes para

possíveis manutenções de software, portanto, o quanto será útil estes testes de unidade, no momento de sua utilização para correção de erros.

A avaliação do tempo despendido por todos os envolvidos no desenvolvimento de testes, vai seguir alguns critérios para mensuração. Devem ser levados em consideração, 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 fórmula, para avaliação do custo do teste de unidade em um projeto:

Esforço = ((( Tempo Total testes de unidade * 100) / Tempo Total do projeto ) / 100)

Onde o esforço é retornado em percentual, utilizando um cálculo 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 esforço para o desenvolvimento de testes de unidade é de 2% do total do projeto.

Quadro 1 - Exemplo de cálculo para custo de um projeto para testes de unidade

Esforço = ((( 7h * 100) / 40h) / 100)

Fonte: Autor.

Na utilização de métricas para a avaliação 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 evolução do processo, através de um cálculo de proporção conforme abaixo:

PropErros = ((Erros encontrados em um período* 100) / Tempo Total dos projetos em um período )

A meta utilizada para esta métrica é a diminuição de 5% trimestralmente dos erros encontrados, mostrando assim a qualidade do desenvolvimento, baseado na experiência com os testes de unidade.

Com este cálculo é possível mensurar se os erros estão diminuindo conforme a experiência com a utilização de testes de unidade. No gráfico 1 é demonstrado um exemplo de medição de erros em um determinado período.

Gráfico 1 – Proporção de erros por horas de projeto

Fonte: Autor.

Para avaliar o tempo para correção de erros após a implantação dos testes de unidade, será necessário somar a quantidade de solicitações de correções solucionadas em um mês, antes da implantação de testes, e comparar com a quantidade de resolução de solicitações em um mês após a implantação dos testes de unidade. Por exemplo, no mês de janeiro foram corrigidas 40 solicitações e após a implantação foram corrigidas 50 no mesmo espaço de tempo.

É necessário avaliar um maior espaço de tempo, pois a complexidade das solicitações não serão avaliadas.

A medição de processo é um item essencial para analisar e julgar se uma melhoria de processo realmente foi satisfatória. Com a utilização destas métricas, será possível avaliar se o processo pode ser utilizado e aprimorado ou se deve ser abandonado por não obter os resultados esperados.

3.1.3. Análise do Processo

Segundo Sommerville(2011) a análise de processo é o estudo dos processos com o intuito da compreensão de suas principais características e como estes processos são executados na prática pelas pessoas envolvidas. Sommerville sugere que a análise de processo siga as medições, onde a análise e as medições são intercaladas. É necessário realizar algumas análises para saber o que medir e a partir das medições, inevitavelmente será desenvolvido uma melhor compreensão do processo a ser medido.

Os objetivos da análise de processo, tem vários objetivos específicos, como:

O entendimento das atividades envolvidas e seus relacionamentos.

O entendimento das atividades do processo e suas medições.

Relacionar o processo específico ou processo em análise com processos que possam ser comparáveis em outro lugar na organização, ou com processos do mesmo gênero.

Periodo

0,00

5,00

10,00

15,00

20,00

1

2

3

17,24

13,28

12,86

Proporção de Erros por Horas de projeto

Periodo

Durante a análise do processo, procura-se levantar informações sobre problemas e ineficiência do processo e como este processo é influenciado por restrições organizacionais. Alguns aspectos são identificados por Sommerville(2011) para investigação e análise do processo.

Entre os aspectos apontados por Sommerville(2011), foram selecionados dois como base para a proposta deste estágio: A prática de engenharia de software e as restrições organizacionais.

As práticas de Engenharia de Software tem a finalidade de avaliar se existem boas práticas aplicadas ao processo e as restrições organizacionais, avaliam quais as restrições que afetam o processo atual.

3.1.4. Mudança de processo

As mudanças de processo implicam em realizar modificações no processo existente. As mudanças podem ser realizadas em várias atividades ou métodos do processo existente.

“...Como sugeri, você pode fazer isto por meio da introdução de novas práticas, métodos e ferramentas; mudando a ordem das atividades do processo; melhorando as comunicações; ou introduzindo novos papéis ou responsabilidades”. (Sommerville,2011)

De acordo com Sommerville(2011), existem cinco estágios principais no processo de mudanças de processo: Identificação de melhorias, priorização de melhorias, introdução de mudanças de processo, treinamento de processo e ajuste de mudança.

Para desenvolvimento da proposta, baseando-se nos estágios citados por Sommerville(2011), serão seguidas as atividades descritas abaixo:

Levantamento de melhorias e viabilidade. o Observações de melhoria no processo da customização, bem

como a análise de viabilidade da proposta com o cenário atual.

Estudo e levantamento de informações sobre testes de software. o Leituras complementares e baseadas em autores da

engenharia de software, com o objetivo de nortear os princípios a serem utilizados.

Análise de frameworks para implantação. o Análise de frameworks já desenvolvidos e validados para uso

como facilitador no processo de implantação.

Instalação do framework selecionado o Instalação do framework na base de dados.

Implementação piloto da proposta. o Implementação da proposta, sendo utilizada em pequenos

projetos com média de trinta horas de desenvolvimento.

Ajustes do processo e modelo o Correções e ajustes do modelo conforme maturidade.

Avaliação das mudanças o Mensuração do valor agregado no processo.

O quadro 2 demostra o cronograma das principais atividades em ordem sequencial, definidas com data de início e término para o desenvolvimento da

proposta.

Quadro 2 - Cronograma da Proposta

Atividade Envolvidos Início Término

Levantamento de melhorias e viabilidade

Analista 14/08/2013 20/08/2013

Estudo e levantamento de informações sobre testes de software

Analista 20/08/2013 10/10/2013

Análise de frameworks para implantação

Analista e Desenvolvedor 10/10/2013 20/10/2013

Instalação do framework selecionado

Infraestrutura e Desenvolvedor

20/10/2013 30/10/2013

Implementação piloto da proposta

Analista e Desenvolvedor 30/10/2013 10/11/2013

Ajustes do processo e modelo

Analista e Desenvolvedor 10/11/2013 11/11/2013

Avaliação das mudanças

Gerência da Equipe 11/11/2013 20/11/2013

Fonte: O autor(2013). Os benefícios esperados com os testes unitários serão a possibilidade de

validar os requisitos descritos pela análise do projeto, de forma ágil sendo um facilitador para testar separadamente cada unidade que compõe o requisito, apontando onde ocorreu falha no processo proveniente de alterações.

3.2. Metodologia de planejamento 5 Ws

O método 5 Ws é uma ferramenta utilizada para planejamento, facilitando a visualização das responsabilidades para cada tarefa, devendo ser elaborada as respostas as questões:

Quadro 3 – Os 5Ws

What O que? Que ação será executada?

Who Quem? Quem irá realizar ou participar da ação?

Where Onde? Onde será executada esta ação?

When Quando? Quando será executada esta ação?

Why Por Que? Porque foi definida esta ação?

Fonte: Os 5 Ws serão utilizados para atribuição de tarefas e no modo como serão

planejadas no decorrer deste trabalho.

4. Desenvolvimento da proposta

Na elaboração 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 são apresentadas em sequência, 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 inclusão de um novo processo, para a melhoria de qualidade de entrega de customizações no sistema.

Neste estágio foi discutido a possibilidade de incluir no fluxo da customização, uma ação de testes de unidade. Tendo aval da empresa, foi inicializado o estudo de métodos para aplicação de melhorias em um processo existente.

O fluxo atual da customização, demonstrado na figura 1, é considerado rígido, por manter agilidade e resultados financeiros como meta. Por este fato, a inclusão de ações para utilização de testes de unidade, devem ser mensuradas de forma qualitativa, onde não devem demandar muito tempo para seu desenvolvimento.

Após análise do fluxo existente, foi identificado a necessidade de modificação deste fluxo, para que se adeque a proposta. Esta alteração pode ser visualizada abaixo na figura 3, onde pode ser observado a inserção de duas novas ações: A escrita de testes de unidade e rodar testes unitários. O fluxograma completo está disponível no anexo B deste projeto.

Figura 3 – Fluxograma simplificado do processo customização proposto

Fonte: O autor. Com esta modificação no processo de customização é possível 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 validação de testes de defeito buscando testar os atributos que estão descritos em acordo com o quadro 2.

4.2. Estudo e levantamento de informações sobre testes de software

Para o prosseguimento da proposta, após a identificação da melhoria a ser realizada com a implantação de testes de unidade, foi necessário o embasamento teórico 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 unitários, também chamados de testes de componentes, são 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 especificações de criação de testes unitários, utilizando facilitadores para a realização do processo. Será necessário o entendimento dos conceitos e vantagens obtidas com a utilização de testes.

Com base em Pressman(2006), “os testes de unidade enfocam a lógica 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 condições para o teste de um módulo. São estes: Interface, Estruturas lógicas de dados, condições limites, caminhos independentes e caminhos de manipulação de erros:

a. A interface é testada com o objetivo de garantir que a informação flui de acordo tanto no entrada como na saída.

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 execução do algoritmo.

c. Todos os caminhos independentes ao longo da estrutura devem ser exercitados.

d. As condições-limites são testadas a fim de garantir que o módulo opere corretamente nos limites estabelecidos.

e. Todos os caminhos de manipulação 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 máximo ou mínimo especificado nos componentes, pois assim provavelmente descobrirão erros.

4.3. Análise de frameworks para implantação

Como a empresa não tem interesse em aumentar muito, os custos para o desenvolvimento das customizações e também para aquisição de softwares para testes de unidade em PL/SQL, foi necessário estudar ferramentas gratuitas e com estabilidade de versão. Após a realização da análise destas ferramentas, uma foi escolhida por aderir-se à proposta deste trabalho, o framework de testes de unidade utPLSQL.

1 Sommerville(2007), teste de defeito são conceituados para a validação de

comportamentos indesejáveis no sistema.

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 fácil, assim definindo um processo padrão para a instalação, configuração e utilização do framework.

Ainda o utPLSQL é independente de plataforma sendo instalado por scripts SQL, tendo a necessidade de configuração manual.

Para utilização do framework são necessários 4 etapas:

Instalação do utPLSQL.

Escolher programa a ser testado e identificar os casos de teste.

Desenvolver o pacote de teste.

Executar os testes. No momento da elaboração deste trabalho, a versão disponível do

utPLSQL é a 2.2, estando disponível para download2 no endereço http://sourceforge.net/projects/utplsql/files/.

4.3.1.1. Instalação do utPLSQL

A instalação do framework é composta por dois passos simples: A criação de um usuário com privilégios suficientes para instalação através de um script PL/SQL e a configuração do framework. A criação de um usuário é de escolha facultativa, porém deve-se garantir que o usuário utilizado, tenha as permissões no banco de dados conforme quadro 5:

Quadro 4 - Tabela de Comandos de Permissão SQL

Descrição Comando SQL

Criar Sessão Create Session

Criar Tabela Create Table

Criar Procedimento Create Procedure

Criar Sequências Create Sequence

Criar Visões Create View

Criar Sinônimos Publicos Create Public Synonym

Fonte: O autor.

Para definir uma ou várias permissões a um usuário, conforme as descritas acima no quadro 3, pode ser utilizado um script conforme exemplo abaixo:

Figura 4 – Exemplo de script de permissão

Fonte: Documentação utPLSQL 2.2.

2 Download – Copiar arquivo de um computador remoto para a máquina local.

Após a definição de um usuário é necessário inicializar o instalador do utPLSQL, com o comando @ut_i_do install, em um ambiente de administração de banco de dados, por exemplo o SQL Plus3, onde ut_i_do é o scritpt a ser executado, enquanto o install é o parâmetro enviado. O script encontra-se disponível 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 instalação, devem possuir conhecimento e permissões específicas, onde a empresa precisará do apoio da equipe de infraestrutura de banco de dados, responsável pela criação dos usuários necessários, bem como a instalação do utPLSQL.

Tabela 1- Perguntas e respostas para definição de caso de teste

Pergunta Resposta

O quê? Instalação do utPLSQL

Quem? Infraestrutura técnica

Onde? Infraestrutura interna da Focco

Quando? Entre os dias 20 e 30 de Novembro de 2013

Por Que? Necessidade de instalação do framework para desenvolvimento de testes de unidade.

Fonte: Autor

4.3.1.2. Identificar casos de teste

Conforme Sommerville(2011) um teste é custoso e demorado, por isso é necessário escolher casos efetivos de teste unitário. 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.

Serão utilizados dois tipos de casos de testes, um que vai validar o comportamento do componente, ou seja, se realmente ele faz o que se propõe e outro que será baseado em diretrizes que, refletirão a experiência anterior com base nos erros frequentes dos desenvolvedores.

4.3.1.2.1. Validação do comportamento do componente

Na validação 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 especificação proveniente do cliente, analisada e complementada por um analista de sistemas da equipe de customização da Focco.

Tabela 2 - Exemplo de Especificação após análise

1. Requisito 1 Assunto: Cálculo da Margem de Contribuição

Detalhamento: Será tratado por IDE para que os seguintes campos tenham suas

3 Ferramenta de consulta interativa e processamento em lote, para conexão a um banco

de dados Oracle.

fórmulas alteradas: Percentual Faturamento Líquido = 100% (Sempre) Percentual da Matéria Prima = Valor Matéria Prima / Faturamento

Líquido Os demais processos permanecem inalterados.

Tipo de Alteração: Por IDE Específica

Fonte: Equipe de customização, FoccoERP, adaptado pelo autor.

Nesta tabela pode ser observado que, é necessário realizar alteração do cálculo da margem de contribuição. A fim de validar o comportamento do componente que, realiza este cálculo e retorna o valor final do percentual da matéria prima, deve-se prever valores numéricos de entrada e saída, para o cálculo da formula:

%MP = (MP / FAT) * 1004 Estes valores de entrada devem incluir classes numéricas que indicam grupos passíveis de entrada na rotina, como:

Tabela 3 – Grupos de entrada de dados

Grupos Possíveis valores

Números negativos < 0

Zero 0

Números positivos >= 1

Valores nulos Nulo

Tratamento de exceções

Mensagem de Retorno

Fonte: Autor

Através destes grupos, deve-se identificar os valores de retorno da rotina e caso estes valores saírem de acordo com o esperado, o comportamento do componente é valido.

Na tabela 3, existe um grupo de tratamento de exceção, que também deve ser validado e treinado, por exemplo, para o cálculo da margem de contribuição, uma das especificações esperada é que o percentual da matéria prima nunca seja menor que 0, logo se um valor de entrada ser um número negativo, uma exceção deve ser lançada informando a existência de invalidade da operação.

Se o valor de entrada para a variável do valor de faturamento ser 0, a rotina irá lançar uma exceção indicando a existência de uma divisão por 0, devendo ser tratada e esperada pelo grupo de tratamento de exceções.

A seguir a tabela 4 demonstra, os valores de entrada passados a rotina de cálculo da margem de contribuição e seus resultados esperados, dando-se pela fórmula:

%MP = (MP / FAT) * 100

4 Percentual da Matéria Prima = (Valor Bruto Matéria Prima / Valor de Faturamento) *

100

Tabela 4 – Possíveis entradas e saídas esperadas para cálculo da margem de contribuição

Grupos Entrada MP

Entrada FAT

Saída Esperada %MP

Números negativos - 5 2 Exceção de Valor Negativo

Números negativos 1000 - 5000 Exceção de Valor Negativo

Zero 10 0 Exceção de divisor igual a 0

Números positivos 50 20 2,5 %

Números positivos 1000 10000 10 %

Valores nulos Nulo 1000 0 %5

Valores nulos 100 Nulo 10 %6

Fonte: Autor.

Conforme Sommerville(2011) este grupos numéricos podem ser classificados como, a estratégia de partições de equivalência de entrada e saída, onde é necessário identificar um conjunto de partições em um componente, para que seja possível escolher os casos de testes.

No anexo C é apresentado um diagrama com as características de partições de equivalência, 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 saídas esperadas para este teste.

4.3.1.2.2. Validação com base em diretrizes

Segundo Sommerville(2011), diretrizes encapsulam conhecimento de tipos de casos de testes que são eficazes a descobrir erros. Estas diretrizes refletem experiências anteriores, dos tipos de erros cometidos com frequência 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 não force o lançamento de uma exceção, toma-se como uma diretriz a inclusão de grupos de valores inválidos de entrada, para um caso de teste, forçando assim o lançamento de um exceção que deve ser tratada pelo componente e retornar mensagem ou um valor esperado para um valor inválido.

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 série inúmeras vezes; d) Obrigue a geração de saídas inválidas; e) Obrigue os resultados de cálculos a serem muito grandes ou muito

pequenos; Conforme a experiência adquirida na elaboração de caso de teste for

5 O valor nulo deve ser tratado no caso de cálculo. 6 O valor nulo deve ser tratado no caso de cálculo.

crescendo, pode-se criar diretrizes próprias que se adequem a organização.

4.3.1.2.3. Definição de caso de teste

Para a definição da ação da elaboração de caso de teste, deve-se descrever as repostas as questões 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 informações importantes, adquiridas com a experiência no desenvolvimento de testes de unidade.

A definição de um caso de teste, é executada posteriormente ao levantamento, análise e complemento de requisitos, levantados pelo analista junto ao cliente, com o objetivo de deliberar o desenvolvimento de teste de unidade.

Na elaboração de uma caso de teste é necessário levantar o que deverá ser testado e como. Para isto, precisa-se estar claro que tipos de dados serão utilizados em cada componente, quais caminhos poderão ser seguidos pela rotina.

Tabela 5- Perguntas e respostas para definição de caso de teste

Pergunta Resposta

O quê? Definição de caso de teste.

Quem? Analista de sistema e desenvolvedor

Onde? No levantamento, análise e complemento de requisitos e especificações, realizada por analista da Focco

Quando? Após definição de especificações de cada projeto

Por Que? Desenvolvimento de testes de unidade, baseado em especificações

Fonte: Autor

Para identificar que tipos de dados ou o que ser testado, deve-se considerar a estrutura interna do componente, seja cálculos, persistência de dados ou validações de informações. Uma consideração muito importante é validar o maior número possível de caminhos que um componente poderá seguir, reconhecendo diferentes entradas para que retornem os valores esperados.

Os testes de unidade, poderão exercitar testes conforme demonstrado no quadro 5. Também é possível escolher outros testes que forem julgados como importantes.

Quadro 5 – Testes Exercitados por Unidade

Testes Exercitado

Erros de Cálculo Precedência Aritmética Inicialização Incorreta Falta de Precisão

Comparação de Dados Tipos de Dados diferentes Operadores ou operação lógica incorretos Expectativa de igualdade quando um erro de precisão torna a igualdade improvável Terminação de ciclos inadequada

ou inexistente Falha na saída, quando iteração divergente

Fonte: Autor, baseado em Pressman(2006). Quanto a precedência aritmética, o teste de unidade pode mostrar

facilmente um erro, pois o valor de entrada deverá resultar em um saída esperada, e no caso de precedência incorreta, este valor será divergente, assim resultando em falha do componente.

O analista ou desenvolvedor também poderá analisar a inicialização de variáveis, por exemplo na execução de um teste de um componente, o desenvolvedor poderá esquecer de declarar uma variável ou atribuir a ela um valor incorreto, portanto testando todos os caminhos possíveis, os erros de inicialização de variáveis poderão ser identificados.

Em outra situação em que um caso de teste pode ser utilizado, é o teste de precisão de variáveis. 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 também deverá prever, dados de entrada que forcem, a iteração dos laços existentes no componente. Estes dados precisam validar os limites dos índices que o laço atua, para que assim seja testado as possíveis situações que possam gerar erros.

Com este planejamento é possível determinar um caso de teste para uma especificação, que deve identificar todos os testes necessários para a qualidade da entrega do software.

4.3.1.3. Desenvolver um pacote de teste

Para a utilização do utPLSQL, será necessário criar um pacote de teste contendo os testes unitários. Este pacote deve seguir as especificações 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 Explicação

Procedimento de setup Registrar um teste de unidade e inicializar a estrutura de dados necessária para o teste.

Procedimento de desmontagem Remover toda a estrutura de dados criada para os testes.

Os testes de unidade Procedimentos contendo os testes identificados por um caso de teste.

Nomenclatura A nomenclatura deve seguir a um padrão pré-definido pela ferramenta.

Fonte: 1documentação utPLSQL 2.2, modificado pelo autor

Na elaboração dos pacotes de testes de unidades, foram definidas as

7 Application programmatic interface = Interface de programação de aplicação

questões como base no método 5Ws, conforme tabela 6.

Tabela 6 - 5 Ws desenvolvimento de testes de unidade

Pergunta Resposta

O quê? Desenvolvimento de testes de unidade.

Quem? Analista de sistema e desenvolvedor.

Onde? Na Focco, área de customização.

Quando? Antes do desenvolvimento.

Por Que? Base para desenvolvimento de componentes. Fonte: o autor

4.3.1.3.1. Procedimento de Setup

Os testes serão chamados pelo procedimento de setup, que inicializa os dados necessários para a execução de um teste de unidade. Este procedimento é executado antes de qualquer teste.

O utPLSQL específica um cabeçalho 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 - Cabeçalho de um pacote e procedimento de setup

CREATE OR REPLACE PACKAGE <prefix><package> IS PROCEDURE <prefix>setup; Fonte: Documentação utPLSQ 2.2

A nomenclatura padrão 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 criação de pacote

CREATE OR REPLACE PACKAGE ut_<program> IS PROCEDURE ut_setup; Fonte: Documentação utPLSQL 2.2

Para definir uma estrutura de dados no procedimento de setup, pode-se criar tabelas de dados temporárias, para armazenar informações para comparação, preencher coleções ou mesmo registros em uma variável global.

Abaixo na figura 7 é exibido um exemplo de inicialização de uma estrutura de dados.

Figura 7 - Exemplo de inicialização 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: Documentação utPLSQL 2.2

No exemplo acima, são inicializados uma estrutura para três procedimentos de testes de unidade. Para cada um dos testes é criada uma tabela temporária que armazena valores da tabela employee, para que sejam comparadas pelo procedimentos. Também é possível 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 temporários gerados pelos testes de unidade.

Abaixo na figura 8 é demonstrado a criação 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: Documentação utPLSQL 2.2

Este procedimento é declarado dentro de um pacote de testes, onde é chamado normalmente no início 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 validação 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: Documentação 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: Documentação utPLSQL 2.2

Pode-se analisar a chamada do procedimento de setup, que inicializa os dados, como também suporte a chamada de procedimentos desenvolvidos para o sistema. Através do procedimento “utAssert” é possível verificar os resultados dos dados.

Para que o teste registre uma falha, deve ser tratado as exceções, onde é necessário utilização o procedimento “utAssert” com segundo parâmetro como FALSE.

4.3.1.4. Executar os testes

Após ter definido um pacote de testes com cabeçalho e corpo é necessário executar o pacote. Para a execução 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 declaração DBMS_OUTPUT para retornar o resultado dos testes.

No anexo D é demostrado um exemplo da criação de um pacote de testes como o espelho, corpo e execução. Onde para criação é necessário definir uma PKS que é uma definição do pacote, após o corpo do pacote que irá conter as procedures de inicialização de dados, a de desmontagem e finalmente os testes de unidade e suas especificações.

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 três parâmetros onde:

O primeiro é a mensagem que identifica o pontos de teste;

O segundo que executa uma função com retorno;

O terceiro que valida a igualdade de valor do retorno do segundo parâmetro.

A função de retorno betwn que está presente na especificação do pacote str, deve estar disponível nos procedimentos armazenados na base de dados do Oracle(Store Procedures) ou declarado no próprio corpo do teste no pacote ut_str.

A rotina betwn que tem por função retornar o valor conforme parâmetros passados, quando o primeiro parâmetro indica o início de posição de um conjunto de caracteres e o fim de posição retornando o valor entre estes pontos.

Para executar o teste de unidade, será necessário a utilização do seguinte comando:

Quadro 7 - Comando para execução de um pacote de teste

exec utPLSQL.test('str', recompile_in => FALSE) Fonte: Documentação utPLSQL 2.2, adaptado pelo autor.

O comando exec é nativo do banco de dados Oracle para execução de

processos, o comando utPLSQ.test executa um pacote de teste registrado com a nomenclatura “ut_...”. No comando utPLSQ.test foram passados dois parâmetros o primeiro indicando o pacote de teste e o segundo indicando a não recompilação de todas as rotinas do pacote de teste.

Por fim para o fluxo de execução de testes de unidade, serão atribuídas as seguintes questões para o setor de customização.

Tabela 7 - 5 Ws para execução de testes de unidade

Pergunta Resposta

O quê? Execução de um teste de unidade.

Quem? Analista de sistema e desenvolvedor.

Onde? Na Focco, área de customização.

Quando? Na Antes do desenvolvimento e depois do desenvolvimento.

Por Que? Validação de componentes. Fonte: o autor

4.4. Implementação do piloto da proposta

A implementação foi iniciada com um projeto de 51 horas de desenvolvimento e análise acoplados. Este projeto contou com 3 envolvidos, o analista de sistemas e dois desenvolvedores. Conforme a proposta deste artigo, iniciou-se a análise do projeto, pelo analista de sistemas, que identificou os requisitos e elaborou um especificação técnica, discriminando quais objetos seriam necessários para o atendimento da solicitação. A especificação técnica é um documento contendo as informações necessárias para o desenvolvimento, como: Componentes a serem criados e quais requisitos funcionais deverão atender. Na tabela 8 pode ser observado a especificação criada:

Tabela 8 - Especificação Técnica após análise

Requisito 1

Assun-to:

Complemento solicitação de bloqueio de pagamento de títulos CP

Deta-lha-mento:

Baixa Manual Será adicionado um parâmetro novo (IDE155086_1_ZEN- USU_LIB_PAG)

na IDE já existente com a opção de seleção dos usuários liberados para efetivar o pagamento de Títulos DUPs quando utilizando o Tipo de Movimento (DIFERENTE do informado na IDE) que contenham títulos DEV em aberto. Os usuário(s) aqui informados serão os únicos que conseguiram baixar os títulos do contas a pagar com tipo de movimento DIFERENTE da IDE.

Quando for ser efetivada a baixa manual do(s) titulo(s), o sistema deve verifi-car se o usuário tem permissão para fazer a baixa, e:

o Se SIM: Será apresentada uma mensagem ao usuário, “fornecedor com títu-los de devolução em aberto, deseja efetuar a baixa? (sim/não)”

Se o usuário clicar em sim deve fazer o tratamento padrão do Focco-ERP – traz a mensagem de Fornecedor tem títulos de devolução em aberto, deseja – Escolher automático Cancelar, se não para o processo.

o Se NÃO: deve trazer a mensagem que o usuário não pode efetivar a baixa do título, devida a não ter permissão para baixar títulos de fornecedores que con-tenham títulos em aberto com tipo de movimento diferente do “XX” – informa-

do na IDE Utilizar a mesma rotina do projeto 155086:

ZEN_FIN_ANALISA_BLOQUEIO_PAG Nota de Entrada O processo que é realizado na baixa manual também será realizado na

emissão 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 parâmetro de IDE (IDE155086_1_ZEN- TP_MOV), não deixa realizar a baixa.

Os usuários que tem permissão para baixar com outros tipos de movimen-tos também devem ser validados, se não tiverem permissão para baixar a duplicata com tipo de movimento diferente da resposta do parâmetro, deixa emitir a nota mas não baixar a duplicata.

Utilizar a mesma rotina do projeto 155086:

ZEN_FIN_ANALISA_BLOQUEIO_PAG Procedure FREC0200: QUITAR_ADIANTAMENTOS_CP Pagamento Escritural Quando for gerar uma Remessa de Títulos para Pagamento Escritural, o

sistema deve verificar se os títulos dos fornecedores que se está selecionando, tem valores em aberto com tipo de documento informado nos parâmetros por IDE (IDE155086_1_ZEN- TP_DOC), caso contenham deve trazer a mensagem:

“ Alguns títulos selecionados para envio do arquivo contem Titulos de

“DEV” em aberto, deseja realmente envia-los nessa Remessa. ESCOLHER SIM NÃO ENVIAR”

Se escolhida a opção NÃO deve desconsiderar todos os títulos desses for-necedores.

Se escolhida a opção SIM deve levar todos os títulos.

Se for escolhida a opção escolher, deve trazer tela com os títulos dos for-necedores que contem DEV informados e um check-box para seleção. Programa: FZEN_FIN001

Empresa

Título

Parcela

Fornecedor

Data Emissão

Data Vencimento

Valor

Tabela Temporária: W_ FZEN_FIN001 IDE para alterar a query dos títulos: FI-

NAL_EXECUTA_BUTTON(FPAG0210) Ao final deve ser executado um relatório: Selecionados: títulos que entraram nas opções SIM e ESCOLHER Não considerados: títulos que entraram na opção NÃO Relatório: RZEN_FIN001

Selecionados o Empresa o Título o Parcela o Fornecedor o Data Emissão o Data Vencimento o Valor

Não Considerados o Empresa o Título o Parcela o Fornecedor o Data Emissão o Data Vencimento o Valor

Incluir um totalizador de valores por quebra. Essa seleção deve ser realizada antes de selecionar as opções de tela Re-

latório, Consulta e Envia, respeitando que se já foram selecionados os títulos, ao clicar em Relatórios, por exemplo, ao clicar em Consulta ou ENVIA não faz mas a consistência, visto que já foi selecionada a opção desejada.

Nesta etapa do pagamento escritural também deve ser verificado os usuá-

rios que tem permissão para “pagar” duplicatas. Se o usuário não tiver permissão já

desconsidera os títulos e emite o relatório para verificação.

Tipo de altera-ção:

IDE Específica

Fonte: Focco, adaptado pelo autor.

Conforme a especificação técnica foi identificado a necessidade da criação

de um componente que pode ser testado pelo processo. Existindo está situação, foi necessário a elaboração de casos de testes, para posteriormente iniciar a escrita do teste e desenvolvimento do componente.

Na elaboração do caso de teste, viu-se a necessidade de criar uma tabela com as entradas possíveis e as saídas esperadas, conforme pode ser analisado no anexo E. Com estas informações foi possível iniciar o desenvolvimento dos testes.

O desenvolvimento dos testes foi baseado na tabela gerada pela elaboração dos casos de testes. Foi criado um teste para cada sequência dos casos de testes.

No final do desenvolvimento foram avaliados: O tempo de gasto de cada envolvido, quantidade de erros encontrados, na rotina após o desenvolvimento e melhorias identificadas no processo.

O tempo utilizado para a implantação dos testes no projeto, foram lançados em tarefas no gerenciador de projetos utilizado pela Focco.

Tabela 9 - Tempo demandando no componente

Projeto Responsável Tarefa Data

Lançamento Hora Inicial

Hora Final

Tempo Lançado

Analista Elaboração Caso

de teste

17/11/2013 18:00 18:30 30 minutos

Desenvolvedor 1 Desenvolvimento

dos testes

18/11/2013 20:00 23:00 180 minutos

Desenvolvedor 2 Desenvolvimento

Componente

18/11/2013

Fonte: O autor.

A tabela 9 ilustra a quantidade de minutos despendido para o desenvolvimento dos casos de testes. Este tempo inclui a execução dos testes.

4.5. Ajustes do processo

Foi implementado em apenas um projeto. Neste projeto pôde-se identificar a necessidade da criação de uma tabela, contendo as entradas e saídas possíveis do objeto. A partir desta tabela foi realizado a escrita dos testes.

Além deste ajuste, foi criado um modelo (template) para a criação dos testes, facilitando o desenvolvimento de novos testes. O exemplo da tabela gerada pode ser analisado no anexo E e o modelo para criação do pacote de teste no anexo F.

4.6. Avalição do processo

Conforme descrição deste projeto, foram definidas métricas de avaliação. Para a avaliação do tempo de desenvolvimento da implantação do projeto, conforme tabela 9, foram utilizadas 3 horas e 30 minutos. Sendo assim o cálculo para a métrica do tempo de desenvolvimento dos testes é demostrado abaixo:

Tabela 10 - Métrica de testes

Projeto Tempo Fórmula Esforço Total 50 horas 3 horas e 30 minutos ((( 210 mi * 100) / 2400 mi) / 100) 8,75% Total Projeto

Fonte: Autor.

O objetivo é a utilização de 2% do tempo total do projeto, porém para este projeto, foram utilizados 8,75% do total do projeto para a criação dos testes de unidade, valor bem acima do esperado. Deve ser levado em consideração por ser o primeiro projeto a ser implementado. Após a execução dos testes, foi identificado apenas 3 erros no componente testado, estes ambos de falta de tratamento de exceção. Para melhor avaliação é necessário, desenvolver testes em novos projetos, para ter dados em forma temporal e comparativas, porém até o fim deste artigo não foi possível a implantação e mais projetos.

A métrica para medição da qualidade das informações geradas pelo casos testes, na manutenções de software, não pode ser avaliada pelo fato de não ter surgido situações onde já existiam o testes gerados.

5. Conclusões

Este projeto agregou uma base de conhecimento na empresa entre os colaboradores envolvidos, referente a testes de unidade. Pois foi embasado em referências bibliográficas expressivas na engenharia de software. Além de propor uma melhoria de processo, existem vários objetivos atrelados ao projeto, nos quais a empresa visualiza e pretende-os alcança-los.

A proposta foi implantada em um projeto apenas, e com este, foi possível analisar algumas das métricas propostas. Estas métricas não foram alcançadas da forma esperada, porém observou-se o apoio e a dedicação da equipe envolvida, mostrando que o processo pode ser seguido e aprimorado.

O setor de customização para o planejamento de 2014, tem como um dos objetivo melhorar a qualidade dos projetos desenvolvidos e para dar continuidade no processo de implantação é necessário aprimorar os atividades manuais, treinar a equipe explanando os benefícios x o esforço e demonstrar com clareza as métricas a serem alcançadas.

Por fim este projeto teve a finalidade de demostrar uma estrutura para criação de testes de unidade, no desenvolvimento com a linguagem PL/SQL, demostrando os conceitos, trazendo um material prático explanatório e propondo uma melhoria no processo da empresa, objetivando agregar valor aos projetos desenvolvidos tanto na visão do cliente como de todos os envolvidos no processo.

Anexo A – Fluxograma do processo atual do setor de Customização

Anexo B – Fluxograma do processo proposto na customização

Anexo C - Exemplo de partição de equivalência

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 – Elaboração de caso de teste.

Nome do pacote de teste: ut_zen_fin_analisa_bloq_pag

Parâmetros de Entrada Saídas Esperadas

Seq pi_tp_cp_id pi_tp_mov_pg_dev pio_sit_tit Título Aberto UsuarioLogin pio_sit_tit po_mensagem po_tp_msg po_raise_msg

1 1 null 1 Título Aberto 1 <> '''' S' null

2 1 null 1 Não Aberto 1 "' null null

3 1 null 0 Não Aberto 0 '' null null

4 1 null 0 Título Aberto 0 '' null null

5 null <> PARAM(IDE155086_1_ZEN','TP_MOV) 1 null Sem Permis-são 0

O fornece-dor... I TRUE

6 null <> PARAM(IDE155086_1_ZEN','TP_MOV) 0 null Com Permis-são null

O fornece-dor... S' TRUE

7 null ='PARAM(IDE155086_1_ZEN','TP_MOV) 1 null null 1 '' I null

8 null null 1 null null 1 '' null null

9 null null 0 null null 0 '' null null

Referências

SOMMERVILLE,Ian, Engenharia de Software, 8° edição.São Paulo: Pearson Addison –

Wesley, 2007.

PRESSMAN, Roger S.,Egenharia de Software / Roger S. Pressamn; tradução Rosângela

Delloso Penteado, revisão técnica Fernão Stella R. Germano, José Carlos Maldonato,

Paulo Cesar Masiero. – 6.ed. – São 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.