Extra APT

Estudo das metodologias de Caso de Testes e Ponto de Testes: uma

abordagem prática

Ítalo César Carvalho Pessoa

José Antônio de Carvalho Cançado Lambertucci

José Humberto Cruvinel Resende Júnior

RESUMO

Qualidade é uma das principais preocupações das empresas. Na atualidade, para garanti-la na criação de softwares é de suma importância que se teste o máximo possível antes de uma entrega, pois falhas nesse segmento podem causar prejuízos e perdas, algumas vezes inestimáveis. Além disso, os custos de uma correção costumam ser elevados. Em 1979, Glenford Myers escreveu em seu livro “The Art of Software testing” que quanto mais cedo descobrimos e corrigimos o erro, menor é o seu custo para o projeto. Esse custo em correção de BUGS cresce 10 vezes para cada estágio em que o projeto do software avança.

Utilizando casos de teste pode-se planejar melhor os testes e com a utilização de Pontos de Teste podemos estimar tempo e custo destes.

Demonstraremos nesse trabalho um exemplo de caso de teste e como contar pontos de teste. Para tal utilizaremos um programa simples que valida triângulos após receber os valores dos lados.

Palavras-chave: Teste de Software, Caso de Teste, Ponto de Teste.

1 _{Aluno do Curso de Gestão da Tecnologia da Informação do Centro Universitário de Belo Horizonte.}

E-mail: italocesarpessoa@hotmail.com

2 _{Aluno do Curso de Gestão da Tecnologia da Informação do Centro Universitário de Belo Horizonte.}

E-mail: jlambertucci@msn.com

3 _{Professor de Governança de TI e Engenharia de Software no Centro Universitário de Belo Horizonte e}

Orientador deste estudo. E-mail: jhcruvinel@jhcruvinel.com

ABSTRACT

Quality is a major concern for companies. Currently, to secure it in software design is of paramount importance to test as much as possible before delivery, as failures in this segment can cause damage and loss, sometimes priceless. In addition, the costs of a correction are usually high. In 1979, Glenford Myers wrote in his book "The Art of Software testing" that the sooner we find and correct the error, the lower the cost for the project. This cost of fixing bugs grows 10 times for each stage in the software project progresses.

Using test cases can better plan the tests and the use of test points we can estimate time and cost of these.

Demonstrated in this work an example of test case and how to count test points. They used a simple program that validates the values triangles after receiving side.

Keywords: Software testing, test case, test point.

1 INTRODUÇÃO

No mundo moderno, o software passou a ter fundamental importância no apoio aos negócios da empresa, sendo em algumas delas parte fundamental. Esta importância só tende a crescer com o passar do tempo, onde atividades e produtos dependerão cada vez mais de sistemas informatizados, conforme Emerson Rios (2003).

Desde os primeiros computadores comerciais, os pacotes de software desenvolvidos para o mercado, em geral, tem se caracterizado na sua grande maioria por apresentarem um alto número de defeitos que afetam a usabilidade, a funcionalidade, a segurança e a confiabilidade dos dados. Isto pode causarum impacto decisivo nos negócios, resultando em enormes prejuízos pela perda de participação no mercado ou por danos à imagem dos produtos lançados. (RIOS, 2003, p. 01)

Com a globalização, onde a Interneté fundamental aos negócios, um teste mal feito pode acabar significando um caminho para diversos problemas graves e que podem comprometer

uma organização, como: fraudes, incoerência e indisponibilidade de sites e sistemas. Muitos usuários acabam abandonando sites, insatisfeitos com a funcionalidade e usabilidade do mesmo, causando sérios danos e prejuízos à imagem da organização.

Segundo Emerson Rios (2003), mais de 90% dos sistemas são liberados com graves defeitos. Softwares com problemas de desempenho e com defeitos na execução são custosos.

Para Leonardo Molinari (2003), além de existir pouco costume de efetivação de testes no exterior, no Brasil a situação é ainda pior:

Em pesquisa recente realizada pelo Ministério da Ciência e Tecnologia, cerca de 10% das empresas entrevistadas realizam algum teste de software no Brasil. Isto não quer dizer que seja realizado de forma correta e adequada. A cultura de qualidade de software no Brasil é reativa e não proativa. Mas isto está começando a mudar, o que é um sinal claro de que ou muda a qualidade ou morre o software. (MOLINARI, 2003, p.09)

Os livros e revistas relatam diversos casos de softwares com falhas e seus impactos, sendo que o relatório The Economic Impact of Inadequate Infraestruture for Software Testing (NIST, 2002) estima que o custo total dos softwares com defeitos para as organizações nos EUA corresponde, aproximadamente, a um valor um pouco abaixo de 1% do Produto Interno Bruto (PIB).

2 OBJETIVOS

2.1 Objetivo Geral

O objetivo desse trabalho é apresentar os procedimentos de testes, demonstrando de forma prática as metodologias de casos de testes e de ponto de testes.

2.2 Objetivos Específicos

a) Através de pesquisas bibliográficas, reunir informações sobre software, casos de testes, ponto de testes e suas aplicações;

de testes e ponto de testes.

3 JUSTIFICATIVAS

A realização deste artigo é justificada por ser identificado que há pouca informação disponível sobre este assunto para toda a sociedade; pelo fato desse tema já ter se tornado uma realidade nas empresas do Brasil e pela importância da utilização da metodologia de testes aqui mencionadas, conforme constatado por Pezzè (2008).

Espera-se que esse estudo beneficie os interessados no assunto e motive novos pesquisadores a estudarem sobre esse tema ou novos temas que surgirão em relação a testes de sistema informatizados. Durante a realização desse estudo foram abordados temas como Software, Engenharia de Software, Testes, Processos e Tipos de Testes, Casos de Testes e Pontos de Testes.

4 REVISÃO DE LITERATURA

4.1 Software

Há 20 anos, menos de 1% da população poderia descrever de forma inteligível o que significava “software de computador”. Hoje, a maioria dos profissionais, assim como grande parte da população, acha que entende o que é software.

De acordo com Roger Pressman (1995,p.12):

Software é: (1) instruções (programas de computador) que, quando executadas, produzem a função e o desempenho desejados; (2) estruturas de dados que possibilitam que os programas manipulem adequadamente a informação; e (3) documentos que descrevem a operação e o uso dos programas.

O software tornou-se elemento-chave da evolução dos sistemas e produtos baseados em computador. Nos últimos tempos, o software evoluiu de uma ferramenta de análise de

informações e de resolução de problemas especializada para uma indústria em si mesma. O software é um elemento de sistema lógico, e não físico.

4.2 Engenharia de Software

Para Pressman (1995,p.31), podemos caracterizar a engenharia de software como:

Um rebento da engenharia de sistemas e de hardware. Ela abrange um conjunto de três elementos fundamentais – métodos, ferramentas e procedimentos – que possibilita ao gerente o controle do processo de desenvolvimento do software e oferece a profissional uma base para a construção de software de alta qualidade produtivamente.

Para esclarecermos bem, a engenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de sistemas de software aplicando tecnologias e práticas de gerência de projetos e outras disciplinas, objetivando a organização, produtividade e qualidade.

O processo de desenvolvimento de software contém três fases genéricas, independentemente do paradigma de engenharia de software escolhido. As três fases definição, desenvolvimento e manutenção são encontradas em todo desenvolvimento de software, independentemente da área de aplicação, tamanho do projeto ou complexidade.

A fase de definição focaliza o “o que”. Ou seja, durante a definição, o desenvolvedor de software tenta identificar quais informações tem de serem processadas, quais funções e desempenho são desejados, quais interfaces devem ser estabelecidas, quais restrições de projeto existem e quais critérios de validação são exigidos para de definir um sistema bem-sucedido. As exigências fundamentais do sistema e do software são identificadas.

A fase de desenvolvimento focaliza o “como”. Ou seja, durante o desenvolvimento, o desenvolvedor de software tenta definir como a estrutura de dados e a arquitetura de software tem de ser projetadas, como os detalhes procedimentais tem de ser implementados, como o projeto será traduzido numa linguagem de programação e como os teste tem de ser realizados.

A fase de manutenção concentra-se nas mudanças que estão associadas à correção de erros, adaptações exigidas à medida que o ambiente do software evolui e ampliações produzidas por

exigências variáveis do cliente. A fase de manutenção reaplica os passos das fases de definição e desenvolvimento, mas o faz no contexto do software existente.

A utilização e implantação de testes é uma fase importante e fundamental da engenharia de software.

4.3 Testes de Software

Para Rios (2003) teste de software é o processo que visa a sua execução de forma controlada, com o objetivo de avaliar o seu comportamento baseado no que foi especificado, sendo a execução de testes um tipo de validação. São utilizados para verificar o encontro dos requerimentos com o produto.

A limitação de sua abordagem, entretanto, é o momento em que ocorre, pois pode ser tarde para construir um produto de qualidade. São aplicados conforme a abrangência, direcionamento e profundidade dos casos de teste. Podem ser inspecionados de modo a garantir que todos os requerimentos sejam testados através de todas as combinações de inputs e estados do sistema.

Para Deutsch (1979, citado por Pressman, 1995, p. 786):

O desenvolvimento de sistemas de software envolve uma série de atividades de produção em que as oportunidades de injeção de falhas humanas são enormes. Erros podem começar a acontecer logo no começo do processo, onde os objetivos podem estar errônea ou imperfeitamente especificados, além de erros que venham a ocorrer em fases de projeto e desenvolvimento posteriores... Por causa da incapacidade que os seres humanos tem de executar e comunicar com perfeição, o desenvolvimento de software é acompanhado por uma atividade de garantia de qualidade.

É importante lembrar que nem todos os defeitos são descobertos durante os testes. Testes de software incluem várias atividades, incluindo verificação e validação das atividades.

Na concepção de Jacobson (1992), normalmente as atividades de teste são divididas em verificação e validação. Verificação checa se os resultados estão de acordo com a especificação, portanto sozinha não dá a garantia de satisfação ao cliente, para isso a

validação checa se o resultado é realmente o esperado pelo cliente. Tem foco na satisfação do cliente.Os dois termos podem ser resumidos em duas frases:

• Verificação: estamos construindo o sistema corretamente?

• Validação: estamos construindo o sistema correto?

Segundo uma estimativa de Beizer (1990), a média do número de defeitos em programas liberados para testes é de 1 a 3 por 100 instruções executáveis.

Jacobson (1992) declara que é importante lembrar que o propósito do teste não é provar que o programa nunca vai falhar, mas sim mostrar se tem ou não erros. Um teste de sucesso é aquele que encontra muitos erros, dessa forma, se fizermos um desenvolvimento de sucesso teremos um teste sem sucesso, não encontrando erros.

Na ótica de Pressman (1995, p.786), “não é comum que uma organização de software gaste 40% do esforço de projeto total em testes”, assim como Pezzè (2008, p.26) diz que “o custo da verificação de software frequentemente corresponde a mais da metade do custo total do desenvolvimento e manutenção”.

4.3.1 O processo de testes

O processo de testes deve basear-se em uma metodologia aderente ao processo de desenvolvimento, como pessoal técnico qualificado, ambiente e ferramentas adequadas.

Rios (2003) afirma que a metodologia de testes deve ser o documento básico para a organização da atividade de testes no contexto da empresa.

Figura 1 – Fases Processo de Testes

Fonte: Projeto e Engenharia de Software: Teste de Software, Emerson Rios, 2003,p.09.

Rios et al. (2003) destaca e descreve as fases de processos, representadas na figura 1, da seguinte forma:

a) Procedimentos iniciais: Elaboração do documento Guia Operacional de Testes (GOT), ou seja, o estabelecimento de um acordo entre as partes envolvidas no projeto de testes (usuário, desenvolvimento, teste e produção) para a definição dos seguintes assuntos: objetivo do projeto de testes, pessoal envolvido (desenvolvimento, equipe de testes e usuários), as responsabilidades de cada um, o plano preliminar de trabalho, a avaliação dos riscos, os níveis de serviços acordados e qualquer item considerado relevante pelo responsável das atividades de testes para garantir o sucesso do projeto.

b) Planejamento: Elaboração e revisão da Estratégia de Testes e do Plano de Testes. c) Preparação: Preparação do ambiente de teste, incluindo equipamentos, rede, pessoal,

software e ferramentas.

d) Especificação: Elaboração e revisão dos Casos de Testes, “scripts” (no caso de uso de ferramentas de automação de testes) e dos Roteiros de Testes e execução dos testes de verificação da documentação do sistema (testes estáticos).

e) Execução: Execução dos testes planejados conforme os Casos de Testes, “scripts” (no caso de uso de ferramentas de automação de testes) e dos Roteiros de Testes com os correspondentes registros dos resultados obtidos.

f) Entrega: Conclusão do processo de testes com a entrega do sistema para o ambiente de produção.

4.3.2 Tipos de Teste

Veja uma lista com os principais tipos de testes utilizados. Rios (2003)esclarece que, muitas vezes, os tipos de testes se sobrepõem, sendo as próprias definições abrangentes ou específicas, conforme a sua execução. A tabela 1.0 apresenta os principais tipos de testes, segundo Molinari (2003).

Tabela 1.0 – Tipos de Testes

FONTE: Testes de Software: Produzindo Sistemas Melhores e Mais Confiáveis, Leonardo Molinari, 2003.

Tipo de Teste Descrição

Teste de Unidade Teste em nível de componente ou classe. É o teste cujoobjetivo é um “pedaço do código”.

Teste de Integração

Garante que um ou mais componentes combinados (ou unidades) funcionam corretamente.

Teste de Sistema A aplicação tem que funcionar como um todo. Neste momento a aplicação tem de “fazer aquilo que diz que faz”.

Teste Operacional

Garante que a aplicação pode “rodar” muito tempo sem falhar.

Teste Negativo-Positivo

Garante que a aplicação vai funcionar no “caminho feliz” de sua execução e vai funcionar no seu fluxo de exceção.

Teste de Regressão

Um dos mais importantes testes. “Para irmos para o futuro, temos de voltar ao passado, sempre”. Toda vez que formos inserir uma característica nova na aplicação, devemos testar toda a aplicação. Afinal ao “consertar algo, pode quebrar outro”.

Teste de caixa-preta ou Black-Box Test

Testar todas as entradas e saídas desejadas. Não se está preocupado com o “código”.

Teste de caixa-branca ou White-Box Test

O objetivo é testar o código, pois às vezes existem partes do código que nunca foram testadas.

Teste Beta O Objetivo é testar a aplicação em produção. Teste de

Verificação de Versão

Toda vez que se libera uma nova versão da aplicação, existem condições mínimas que validam se a versão liberada está OK. Este teste é usado durante o processo de construção da aplicação, Pode querer testar às vezes apenas uma parte da aplicação.

Teste Funcional Testar se as funcionalidades presentes na documentação funcionam como especificadas. Incluem-se as regras de negócio.

Teste de Interface Testar se navegabilidade e objetos da tela funcionam corretamente, em conformidade com padrões vigentes (em nível de interface).

Teste de Performance

Verifica se o tempo de resposta é o desejado para “momento” de utilização da aplicação e suas respectivas telas envolvidas.

Teste de Carga Verifica se a aplicação suporta a quantidade de usuários simultâneos requeridos.

Teste de Aceitação do Usuário

A meta é clara. É um teste exploratório voltado para validar aquilo que o usuário deseja, tendo um objetivo claro: dar o aceite ou não.

Teste de estresse Testar a aplicação até se atingir o seu limite.

Teste de Volume Testar a quantidade de dados envolvidos (pode ser pouca, normal, grande ou além de grande).

Teste de Configuração

Testa se a aplicação funciona corretamente em diferentes ambientes de hardware e de software.

Teste de Instalação

Verificar se a instalação da aplicação (hardware e software) deu certo.

Teste de Documentação

A Documentação existe? Mostra o que o software faz efetivamente? Falta algo na documentação?

Teste de Integridade

O objetivo é testar a integridade dos dados armazenados.

Teste de Segurança

Testar a segurança da aplicação nas mais diversas formas.

Teste de aplicações Mainframe

Teste de aplicações mainframe que requer um formalismo e um forte planejamento de testes.

aplicações Client interface e a performance do que com outras coisas. Teste de

aplicações Server

Neste momento se está mais preocupado com o desempenho dos processos que com a integridade dos dados.

Teste de

aplicações WEB

O Teste de Segurança a Aplicações Web executado pela equipe de testes capta todas as partes relevantes da aplicação Web e, através de ferramentas especializadas, pode-se automatizar dezenas de milhares de casos de testes.

Teste de Monitoração

São, na realidade, testes funcionais, que visam verificar o status e disponibilidade de diversas funcionalidades e da aplicação em si.

Teste de Ameaça Semelhante ao de segurança, mas em escala mais em nível de falhas. Monkey Test Testa o aplicativo de forma aleatória e inesperada. O teste do “macaco” é

antes de tudo “sem planejamento”.

Teste de Módulo Teste de um módulo, porém em nível menor. Semelhante ao de unidade, porém é mais abrangente que este.

4.4 Casos de Teste

A partir do objeto (ou parte do sistema) definido no Plano de Teste devem ser elaborados os Casos de Testes. O Caso de Teste desce ao nível de detalhe de campos de formulários, arquivos, telas, páginas e outros. Cada item de teste deve ter um critério de avaliação e de teste, conforme declara Rios (2003):

a) Itens ou campos: Relacionar os itens que serão testados e como serão executados esses testes.

b) Entradas: Definir como serão feitas as entradas dos casos de testes e os itens ou campos a serem testados. Estas entradas poderão ser feitas manualmente ou através de arquivos. Devem ser também listados os arquivos ou tabelas que servirão de consulta para a execução dos testes.

c) Resultados esperados: Definir os resultados esperados pelos testes em termos de relatórios, telas e arquivos atualizados ou criados, campos, etc.

e) Necessidades de Ambiente: Especificar as necessidades adicionais de equipamentos, ferramentas e pessoal (além daquelas já disponíveis) para a execução dos casos de testes ou “Scripts” de testes.

f) Datas: Informar as datas de início e de término da elaboração e execução dos documentos Casos de Testes.

Segundo Jacobson (1992),quando identificados os sub-testes que precisam ser feitos, especifica-os em um nível funcional, onde é descrito exatamente como o caso de teste será executado. A última parte inclui uma descrição procedural completa de cada passo do teste.

Lembrando que as descrições de caso de uso são ferramentas poderosas. Para o autor supracitado, o propósito das especificações de teste é dar uma instrução detalhada de execução, para que pessoas que não estejam familiarizadas com a aplicação, ou até mesmo com o sistema possam executar o caso de teste.

No caso ideal, as especificações de desenho devem agir também como especificações de teste. Cada teste, com exceção das de mais baixo nível de unidade, devem ser documentados, lembrando que serão usados no teste de regressão, possivelmente, em outras versões do sistema.

As condições para o teste devem ser especificadas, por exemplo, se o teste deve ser feito no desenvolvimento ou, num ambiente especifico “testbeds”, sistemas, hardware, equipamentos de teste e versões diferentes destes. Isso inclui também como estes testes devem ser realizados, em que ordem o retorno é esperado, e o critério de um teste aprovado.

Quando se escreve a especificação de testes, preparam-se também os relatórios que devem ser reportados nos resultados dos testes. Os relatórios são usados para notificar que o teste está sendo feito.

Deve ser possível documentar o relatório atual juntamente à especificação, embora devam ser tratadas separadamente, desde que queiramos reutilizar a especificação.

Se a documentação de desenho é escrita na forma de especificações, estes podem ser usados como especificações de teste. Uma especificação de teste, algumas vezes é também a própria

especificação de desenho. Isso também ajuda a encontrar os defeitos. Se há um defeito nesse nível, este deve ser corrigido no mesmo, não apenas no código. Quando se escreve uma especificação de teste, deve-se refletir como o sistema deve funcionar durante a operação. Então fraquezas talvez sejam descobertas no modelo, e isso, deve obviamente ser antecipado aos designers, quanto antes um erro no modelo é detectado, mais barato é para consertá-lo.

O ideal é que se alcance um número de erros próximo à zero, segundo Jacobson um a cada 1000 linhas é um bom número.

4.4.1 Particionamento de equivalência

O particionamento de equivalência é um método de teste de caixa preta que divide o domínio de entrada de um programa em classes de dados a partir das quais os casos de teste podem ser derivados. Um caso de teste ideal descobre sozinho uma classe de erros (por exemplo, processamento incorreto de todos os dados do tipo caractere) que, de outro modo, poderia exigir que muitos casos fossem executados antes que o erro geral fosse observado. O particionamento de equivalência procura definir um caso de teste que descubra classes de erros, assim reduzindo o número total de casos de teste que devem ser desenvolvidos.

O projeto de casos de teste para o particionamento de equivalência baseia-se numa avaliação de classes de equivalência para uma condição de entrada. Uma classe de equivalência representa um conjunto de estados válidos ou inválidos para condições de entrada. Tipicamente, uma condição de entrada é um valor numérico, um intervalo de valores, um conjunto de valores relacionados ou uma condição booleana. As classes de equivalência podem ser definidas de acordo com as seguintes diretrizes:

1. Se uma condição de entrada especificar um intervalo, uma classe de equivalência válida e duas classes de equivalência inválidas são definidas.

2. Se uma condição de entrada exigir um valor específico, uma classe de equivalência válida e duas classes de equivalência inválidas são definidas.

3. Se uma condição de entrada especificar um membro de um conjunto, uma classe de equivalência válida e uma classe de equivalência inválida são definidas.

Aplicando-se as diretrizes para a derivação de classes de equivalência, os casos de teste para cada item de dados do domínio de entrada poderiam ser desenvolvidos e executados. Os casos de teste são selecionados de forma que o maior número de atributos de uma classe de equivalência seja exercitado de uma só vez.

4.4.2 Análise de valor limite

Por razões que não são completamente claras, um número maior de erros tende a ocorrer nas fronteiras do domínio de entrada do que no “centro”. Por isso é que a análise de valor de limite (Boundary Value Analysis – BVA) foi desenvolvida como uma técnica de teste. A análise de valor de limite leva à escolha de casos de teste que põem à prova os valores fronteiriços.

A análise de valor de limite é uma técnica de projeto de casos de teste que complementa o particionamento de equivalência. Em vez de selecionar qualquer elemento de uma classe de equivalência, a BVA leva à seleção de casos de teste nas “extremidades” da classe. Em vez de se concentrar somente nas condições de entrada, a BVA deriva os casos de teste também do domínio de saída.

Sob muitos aspectos, as diretrizes para a BVA são semelhantes àquelas apresentadas para o particionamento de equivalência:

1. Se uma condição de entrada especificar um intervalo delimitado pelos valores a e b, os casos de teste devem ser projetados com valores a e b, logo acima e logo abaixo de a e b, respectivamente.

2. Se uma condição de entrada especificar uma série de valores, os casos de teste que ponham à prova números máximos e mínimos devem ser desenvolvidos. Valores logo acima e logo abaixo do mínimo e do máximo também são testados.

3. Aplique as diretrizes 1 e 2 às condições de saída. Por exemplo, suponhamos que uma tabela de temperatura versus pressão seja exigida como saída de um programa de análise de engenharia. Os casos de teste devem ser projetados para criar um relatório de saída que produza um número máximo (e mínimo) permissível de entradas na tabela.

4. Se as estruturas internas de dados do programa tiverem prescrito fronteiras (por exemplo, um array tem um limite definido de 100 entradas), certifique-se de projetar um caso de teste para exercitar a estrutura de dados em sua fronteira.

A maioria dos engenheiros de software executa a BVA intuitivamente em certo grau. Aplicando-se as diretrizes acima, o teste de valor de limite será mais completo, tendo, portanto, uma probabilidade maior de revelar erros.

4.5 Pontos de Teste

Existe pouco material sobre estimativas para medir o processo de teste. Para Rios (2003), o processo de estimar, muitas vezes está intimamente ligado ao nível de produtividade interno da organização e se faz necessário a criação de uma base de informações com um histórico de medições para que se chegue a resultados mais precisos.

A grande vantagem da análise de pontos de teste é usar como ponto de partida à medição do sistema em análise de pontos de função, que é a mais comum medida de sistemas usada atualmente no mercado.

4.5.1 Visão Geral

A técnica de medição do tamanho de sistemas utilizando-se a metodologia de análise de pontos de função (APF ou PF) é bastante usada no mercado e de amplo conhecimento entre os profissionais da área de sistemas. Usando a APF como base, Martin Pol, Ruud Tennissen e Erik van Veenendaal desenvolveram uma unidade de mensuração da atividade de teste chamada análise de pontos de teste (APT), publicada no livro “Software Testing, A Guide to Tmap Approach”, que faz parte da metodologia Tmap, bastante utilizada nos Estados Unidos e na Europa.

A atividade de testar sistema ou software foi muito enriquecida, com a utilização de metodologias próprias, ferramentas de automação e equipes independentes de testes. Além disso, conforme Rios (2003), as metodologias de desenvolvimento de sistemas, normalmente, não separam a etapa de testar sistemas, que usualmente fica embutida na etapa de construir ou homologar o sistema. Esta é, talvez, a principal discrepância entre as estimativas e as

medições reais, pois a etapa de teste demora na prática muito mais do que o previsto, demandando, logicamente, de métricas específicas, conclui o autor supracitado.

A atividade de testar sistemas passou a ser tratada como um projeto de teste independente, com gerência e controles próprios, embora ligada diretamente ao projeto do sistema em questão.

4.5.2 Filosofia

De acordo com Rios (2003), a análise de Pontos de Teste considera como base da sua análise o tamanho do sistema, em pontos de função, a ser testado a partir das informações coletadas junto à equipe de desenvolvimento.

Além disso, esse autor lista os seguintes fatores como aqueles que afetam os testes:

a) O grau de complexidade do processo de teste: Com isto queremos dizer que sistemas muito complexos tendem a consumir mais horas de teste do que aqueles mais simples como era de se esperar.

b) O nível de qualidade que se pretende alcançar com os testes: Evidentemente que a exigência de níveis de qualidade muito altos vão demandar um esforço maior de teste. c) O grau de envolvimento dos usuários com os testes: Quanto maior for o envolvimento

dos usuários na atividade de teste ou homologação, tanto melhores serão os resultados alcançados e muitas vezes, menores serão os esforços de testar.

d) As interfaces que as funções que estão sendo testadas têm com os arquivos: Quanto maior o número de arquivos envolvidos em um Caso de Teste, mais difícil será testar o sistema ou software.

e) A qualidade do sistema que está sendo testado (o ciclo de reincidência de defeitos): Quando o sistema tem defeitos de desenvolvimento ou de projeto, certamente, o trabalho de testá-lo será muito oneroso. Neste caso vale também a máxima que os custos dos defeitos crescem em progressão geométrica quanto mais tarde forem sendo encontrados. Defeitos de produção são muito mais caros que defeitos de projeto. f) O nível de cobertura esperado com os testes: Os requisitos do sistema normalmente

g) A experiência e a produtividade da equipe de testes (medidos através de indicadores históricos): Evidentemente que a qualidade da equipe de teste e de sua gestão estão ligados ao esforço despendido para a execução dos testes. Existem organizações que utilizam bases históricas para estimar e avaliar o seu processo de teste. Estas informações servem de base também para medir a produtividade da equipe.

h) O grau de automação dos testes: As ferramentas de automação permitem níveis maiores de produtividade, pois facilitam a repetição de testes já executados, tantas vezes quantas forem necessárias, além de facilitar a documentação dos casos de teste. i) A qualidade do ambiente de teste, inclusive a sua capacidade de simular o ambiente de

produção: O ambiente de teste deve estar bastante próximo ou ser igual ao ambiente de produção, pois com isso evitam-se muitos problemas provenientes da compatibilidade entre ambiente. Isto será especialmente importante para os testes de estresse, carga e desempenho.

j) A qualidade da documentação do sistema, e, especialmente, dos requisitos: Como os requisitos são a base para o desenvolvimento do sistema, teremos um processo em cadeia, pois o teste apenas indica a ocorrência de defeitos, porém não resolve o problema decorrente de um projeto mal feito. Neste caso os custos de correção tendem a ser muito altos e o esforço de teste também será muito maior.

A utilização da análise de pontos de teste vai permitir que o processo de teste tenha uma medida própria para determinar o seu tamanho, o que se justifica quando o teste for tratado como uma atividade independente, mantendo-se a ligação com o tamanho do sistema em pontos de função.

Segundo Jacobson (1992) quando identificamos o que se deve testar, podemos estimar os recursos necessários para esse teste.

Na ótica de Ton Dekkers e Erik Van Veenendaal (1999), definir o que fazer, como fazer, quanto tempo será necessário, quanto vai custar e outros cálculos cria a possibilidade de uma estimativa para todos esses marcadores.

Assim como os pontos de função, os pontos de testes têm suas unidades de medida, são eles número de arquivos lógicos, número de funções transacionais definidas por usuário, produtividade e influencias.

4.5.3 Total dos Pontos de Testes (PT)

O número total de pontos de teste (PT) é dado pela soma dos pontos de teste dinâmicos (PTDf) e pontos de teste estáticos (PTE), considerando-se o tamanho do sistema em pontos de função e uma constante de 500, que representa o tamanho mínimo em pontos de função, conforme demonstrado na equação 1.1. Adiante será detalhado como encontrar cada um destes subtotais. Cabendo ressaltar, no entanto, que toda métrica deve ser adequada ao ambiente de teste da organização, através da criação de bases históricas, de forma a alcançar uma precisão mais próxima da sua realidade.

500 / ) (PF PTE PTDf PT=

∑

4.5.3.1 Pontos de teste dinâmicos (PTD)

Os pontos de teste dinâmicos são calculados com base nas funções do sistema, conforme tratadas pela análise de pontos de função. Cada funcionalidade medida, como, por exemplo, uma entrada externa, tem uma contra-partida em pontos de teste, ou seja, uma outra medida para fins de medição dos testes. A funcionalidade, por exemplo, Atualizar Cadastro, medida em pontos de função terá uma contra-partida em pontos de teste.

As funções medidas em pontos de função e tratadas em pontos de teste são:

• Entradas Externas (EE – External Inputs)

• Saídas Externas (SE – External Outputs)

• Consultas Externas (CE – ExternalInquiries)

Os pontos de teste dinâmicos tomam como base também os seguintes elementos:

• Funções dependentes (FDf)

• Qualidade dos requisitos relacionados com as características de qualidade a serem testadas dinamicamente (QRd).

4.5.3.1.1 Fatores das funções dependentes (FDf)

Diversos fatores compõem o que chamamos de funções dependentes. As funções dependentes são assim chamadas em razão do grau de dependência que têm das funções correlatas medidas pela teoria de pontos de função. Nesta relação vamos considerar a importância que o usuário dá ao processo de testes, a intensidade do uso da função, as interfaces com os arquivos, a complexidade do código e a uniformidade do material de teste.

Importância do usuário (Ue): Este fator mede o grau de importância que o usuário dá à função a ser testada, que pode ser capturado e definido através de entrevistas com os usuários do sistema, ou até mesmo com os próprios desenvolvedores, representado em valores conforme na tabela 2.0.

Tabela 2.0 – Importância do usuário (Ue)

FONTE: Testes de Software, Emerson Rios, 2003.

3 Baixa

6 Normal (Valor médio)

12 Alta

Intensidade de uso (Uy): Deve ser levantado o nível de utilização da função por intervalo de tempo (por exemplo, um dia). Neste espaço de tempo, existem funções que são muito usadas e outras cuja utilização é eventual. O usuário deverá ter condições de estabelecer a intensidade de uso da função, conforme representada na tabela 2.1.

Tabela 2.1 – Intensidade de uso (Uy)

FONTE: Testes de Software, Emerson Rios, 2003.

2 Baixa

4 Normal (Valor médio)

8 Alta

Interface (I): O fator de interface mede o nível de inter-relacionamento entre os “data-sets” (arquivos) e as funções que estão sendo medidas. Deve-se levar em consideração o número de “data-sets” (arquivos) afetado pela função que está sendo medida e o número de funções que afetam um “data set” específico, conforme representado na tabela 2.2. Por exemplo, uma

função atualiza 5 arquivos, e estes arquivos, por sua vez, são acessados por outras 10 funções, então, de acordo com a tabela abaixo, teremos uma interface alta.

Tabela 2.2 – Interface (I)

FONTE: Testes de Software, Emerson Rios, 2003.

Arquivos Funções

(data sets) 1 2-5 >5

1 Baixa Baixa Normal

2-5 Baixa Normal Alta

>5 Normal Alta Alta

Se a função não modificar nenhum arquivo, deve ser dada para ela uma interface Baixa.

Complexidade (C): O grau de complexidade da função é dado pelo seu algoritmo, ou o algoritmo da parte do programa que executa a função. Isto é medido pela quantidade de comandos de condição, tais como IF ou CASE existentes no algoritmo. Por exemplo, um IF conta uma vez, um IF a AND b THEN conta duas vezes, um CASE com n cases conta n-1 vezes.

Como, na maioria das vezes, os analistas de teste não têm acesso à documentação dos programas ou nem sempre ela está disponível para avaliação, é razoável utilizar-se o nível normal na ausência dessas informações, conforme representado na tabela 2.3.

Tabela 2.3 – Complexidade (C)

FONTE: Testes de Software, Emerson Rios, 2003.

3 Baixa – até 5 condições

6 Normal – entre 6-11

12 Alta – mais de 11

Uniformidade (U): O grau de uniformidade mede o nível de reutilização do material de teste. Esta medição varia entre 0,6 ou 1,0. Normalmente, este valor será sempre 1,0, a não ser nos casos específicos nos quais o material de teste, por algum motivo, possa ser aproveitado de uma para outra função, seja por semelhança ou por se tratar de uma função clone. O nível de utilização é que vai indicar o valor, sendo 0,6 a completa utilização do material de teste.

Fórmula de cálculo (funções dependentes), conforme demonstrada na equação 1.2. U C I Uy Ue FDf =(( + + + )/20)× _(1.2)

Nesta expressão, Ue é a importância do usuário, Uy é a intensidade de uso, I é a interface, C é a complexidade e U é a uniformidade.

4.5.3.1.2 Características de qualidade dinâmica (QRd)

As características de qualidade dinâmica (QRd) medem como a qualidade dos requisitos pode afetar a qualidade dos testes. Para esta medição são consideradas medidas explícitas e medidas implícitas, conforme destacado na equação 1.3.

CI CE

QRd= + (1.3)

Para Características Explícitas (CE), temos os seguintes:

a) Funcionalidade (F) b) Performance (P) c) Segurança (S)

d) Aderência e Efetividade (A)

Para cada uma das características supracitadas, temos valores definidos, conforme tabela 2.4.

Tabela 2.4 – Características Explícitas (CE) FONTE: Testes de Software, Emerson Rios, 2003.

0 A qualidade dos requisitos não é importante para o resultado dos testes. 3 A qualidade dos requisitos não é importante, mas precisa ser considerada

para o resultado dos testes.

4 A qualidade dos requisitos tem importância média (normalmente é escolhido este índice).

6 A qualidade dos requisitos é extremamente importante.

Devem ser também considerados os seguintes pesos:

• Funcionalidade = 0,75 • Performance = 0,10 • Segurança = 0,05 • Aderência/Efetividade = 0,10 Por exemplo: 4 / 75 , 0 ) ( ( ×

= ValorAtribuídotabela

F (1.4)

O mesmo procedimento, demonstrado na equação 1.4, deve ser repetido para todas as características, ou seja, performance, segurança e aderência.

A S P F

CE= + + + (1.5)

Características Implícitas são utilizadas quando houver coleta de dados e/ou indicadores, para futuras medições quanto à qualidade dos testes. Estes indicadores servirão para fornecer uma média ou medida padrão para servir de comparação com o projeto em andamento. Por exemplo, um teste de performance poderá ser medido através da coleta de dados para futuro processamento. Neste caso deverá ser adicionado um valor de 0,02 para cada uma das características consideradas, conforme demonstrado na equação 1.6.

02 , 0 × =n

CI _{(onde n varia entre 0 e 4) (1.6)}

Sempre que houverem indicadores que sejam utilizados para avaliar uma dessas características explícitas (funcionalidade, performance, segurança e aderência), considera-se que pode existir uma característica implícita associada, mantendo-se o limite de 4, sendo admitido 1 para cada característica explícita.

A QRd será a soma dos fatores explícitos (equação 1.3), cada um multiplicado pelo seu respectivo peso, adicionados de cada uma das características explícitas utilizadas, no limite de 4.

CI CE

QRd= + (1.3)

4.5.3.1.3 Fórmula de cálculo para o ponto de teste dinâmico

QRd FDf PFf

PTDf = × × (1.7)

A equação 1.7 demonstra como é calculado o ponto de teste dinâmico, sendo que PFf é o número de pontos de função da função testada, FDf é o total das funções dependentes e QRd é o total das características explícitas e implícitas.

4.5.3.2 Pontos de teste estáticos (PTE)

Os pontos de teste estáticos levam em consideração o sistema como um todo, diferentemente dos pontos de teste dinâmicos, que consideram cada uma das características isoladamente.

Os testes estáticos somente devem ser considerados quando a equipe de teste adotar processos de revisão de documentação e de códigos usando checklists, caso contrário deve ser descartado e terá valor nulo.

O cálculo dos pontos de teste estáticos toma como base os critérios de qualidade para a avaliação das características anteriormente citadas (funcionalidade, performance, segurança, aderência). Normalmente esta avaliação é feita a partir de checklists, um para cada característica. Para cada checklist usado são adicionados 16 pontos de teste, conforme é demonstrado na equação 1.8.

n

Sendo n o número de checklists usados para avaliar as características de qualidade do sistema, sendo menor ou igual a 4.

4.5.3.3 Número total de pontos de teste

500 / ) (PF PTE PTDf PT=

∑

Retomando a equação 1.1, identificados a somatória de PTDf como a soma dos pontos de teste de todas as funções, PF como o tamanho do sistema todo em pontos de função e PTE como o total dos pontos de teste estáticos.

Lembrando que a segunda parte da fórmula terá valor nulo, caso a organização não adote procedimentos de teste estático.

4.5.4.1 Qualificação da equipe de teste (QET)

Normalmente, este valor é determinado por uma base histórica e deve variar entre 0,7 e 2,0, onde devem ser consideradas a experiência e a qualificação da equipe de teste. Estes fatores estão diretamente ligados à produtividade da equipe de testes.

Quanto melhor e mais qualificada for a equipe tanto menor será QET.

4.5.4.2 Ambiente de teste (AT) (Fatores ambientais)

21 ÷ =SomaFatores

AT (1.9)

Conforme demonstrado na equação 1.9, para encontrar o grau de ambiente de teste é necessário a soma de todos os fatores ambientais, mencionados abaixo.

Ferramentas de teste, conforme representada na tabela 2.5. Tabela 2.5 – Ferramentas de teste (AT)

1 Existe uma ferramenta de automação para as fases de especificação e execução dos testes.

2 Existe uma ferramenta de automação para as fases de especificação ou para a fase de execução.

4 Não existe ferramenta de automação de teste.

Teste de precedência, conforme representada na tabela 2.6.

Se um teste de integração for bem executado, os resultados do teste seguinte, no caso o teste de sistema, terão resultados melhores. Para cada etapa do processo de teste, a atividade imediatamente anterior deve produzir bons resultados para que a atividade seguinte possa ser bem executada. A melhor forma de conduzir este trabalho é através de um plano de testes com resultados palpáveis.

Tabela 2.6 – Teste de precedência (AT)

FONTE: Testes de Software, Emerson Rios, 2003.

2 Existe um plano para o teste precedente e a equipe está familiarizada com ele, assim como com os respectivos casos de teste e resultados de teste. 4 Existe um plano para o teste precedente.

8 Não existe um plano para o teste precedente.

Documentação de teste, conforme representada na tabela 2.7. Tabela 2.7 – Documentação de teste (AT)

FONTE: Testes de Software, Emerson Rios, 2003.

3 Durante o desenvolvimento do sistema são usados padrões de documentação e templates. Acontecem revisões periódicas da documentação.

6 Durante o desenvolvimento do sistema são usados padrões de documentação e templates. Acontecem revisões esporádicas da documentação.

12 A documentação não segue nenhum padrão nem templates são usados.

Tabela 2.8 – Ambiente de desenvolvimento (AT) FONTE: Testes de Software, Emerson Rios, 2003.

2 O sistema foi desenvolvido usando uma linguagem de 4º geração integrada a um sistema de gerência de banco de dados.

4 O sistema foi desenvolvido usando uma combinação de linguagens de 4º

e 3º geração.

8 O sistema foi desenvolvido em uma linguagem de 3º geração como COBOL, PASCAL, C++, Delphi, ASP, Html, etc.

Testware, conforme representada na tabela 2.9. Tabela 2.9 – Testware (AT)

FONTE: Testes de Software, Emerson Rios, 2003.

1 Existem materiais de testes, tais como bases de dados, tabelas, casos de teste, e outros, que poderá ser reutilizado.

2 Existem apenas tabelas e base de dados disponíveis para reutilização. 4 Não existe testware disponível.

4.5.4.3 Fórmula para cálculo das horas de teste primárias

AT QET PT

HTP= × × _(1.10)

A equação 1.10 demonstra como é calculada as horas de teste primárias, sendo que PT é o número de pontos de tese, QET é a qualificação da equipe de teste e AT é o ambiente de teste.

4.5.5 Número total de horas de teste (THT)

As horas primárias de teste devem ser corrigidas através da inclusão das atividades de planejamento e controle, cujo percentual é dado pelos fatores abaixo listados:

• Tamanho da equipe (TE)

• Ferramentas de gerência (FG)

IPC HTP

THT= × (1.11)

4.5.5.1 Método de cálculo do IPC

) (

1 TE FG

IPC= + + _(1.12)

A soma dos dois fatores dará um valor percentual que deverá ser acrescido ao total de horas primárias de teste e farão parte do total de horas da fase de Planejamento e Controle, conforme demonstrada na equação 1.12.

Tamanho da equipe (TE), conforme representada na tabela 2.10. Tabela 2.10 – Tamanha da equipe (TE)

FONTE: Testes de Software, Emerson Rios, 2003. 0,03 Entre 3 e 4 técnicos (inclusive). 0,06 Entre 5 e 10 técnicos (inclusive). 0,12 Mais de 10 técnicos (inclusive).

Ferramentas de gerência (FG), conforme representada na tabela 2.11. Tabela 2.11 – Ferramentas de gerência (FG)

FONTE: Testes de Software, Emerson Rios, 2003.

0,02 Existem ferramentas de registro de tempo e de gerência de defeitos, além de ferramentas de gerência de configuração.

0,04 Apenas uma das ferramentas citadas acima está disponível. 0,08 Não existem ferramentas disponíveis.

5 METODOLOGIA

Segundo Yin (2001), o estudo de caso é a pesquisa preferida quando predominam questões dos tipos "como?" e "por quê?", ou quando o pesquisador detém pouco controle sobre os eventos e ainda quando o foco se concentra em fenômenos da vida real.

Este autor afirma também que, o estudo de caso é um modo de pesquisa empírica que investiga fenômenos contemporâneos em seu ambiente real, quando os limites entre o

fenômeno e o contexto não são claramente definidos; quando há mais variáveis de interesse do que pontos de dados; quando se baseia em várias fontes de evidências; e quando há proposições teóricas para conduzir a coleta e a análise dos dados. Em suma, para este autor não é um método fácil de ser aplicado, entretanto é um dos métodos mais árduos de pesquisa.

Para Ludke e André (apud Marconi e Lakatos, 2004), as características fundamentais ao estudo de caso são:

a) Visar à descoberta.

b) Enfatizar a interpretação do contexto. c) Retratar a realidade de forma ampla.

d) Valer-se de fontes diversas de informações. e) Permitir substituições.

f) Representar diferentes pontos de vista em dada situação. g) Usar linguagem simples.

Seguindo essas características, o presente estudo empenhou-se em analisar por meio de estudo de caso, os aspectos referentes aos processos e metodologias de testes, assim como casos e pontos de testes.

6 ANÁLISE DE RESULTADOS

O estudo de caso prático consiste em testar um sistema que valida um triângulo através das medidas de seus lados, informados pelo usuário, conforme demonstra a figura 2. Após serem fornecidos, o software faz os cálculos com os dados e retorna mensagens dizendo se o triângulo é válido e qual o seu tipo (Apêndice A).

O cálculo se baseia na fórmula de existência de um triângulo, ou seja, para que ele possa existir é necessário que a medida de qualquer um dos lados seja menor que a soma das medidas dos outros dois e maior que o valor absoluto da diferença entre essas medidas, conforme demonstrada na equação 1.13.

c b a c

Figura 2 – Sistema de Teste: Triângulo Fonte: Criado pelo autor.

6.1 Casos de teste

6.1.1 Casos de teste do caso de uso: Validar triângulo Item a testar Caso de Uso Validar Triângulo

6.1.2 Procedimentos de Testes [PT01]

Procedimentos

1. Usuário abre o Sistema Triângulo 2. Usuário informa os lados do triângulo 3. Usuário clica no botão Validar

Dependências Necessidade de um usuário para fornecimento dos dados de entrada.

6.2 Ponto de teste

Função dependente (FDf): 0 , 1 0 , 1 ) 20 / ) 6 4 4 6 (( ) 20 / ) (( = × + + + = × + + + = FDf FDf U C I Uy Ue FDf Funcionalidade (F): 75 , 0 4 / ) 75 , 0 4 ( 4 / ) 75 , 0 ( = × = × = F F Atribuído F Performance (P): 10 , 0 4 / ) 10 , 0 4 ( 4 / ) 10 , 0 ( = × = × = P P Atribuído P Segurança (S): 05 , 0 4 / ) 05 , 0 04 ( 4 / ) 05 , 0 ( = × = × = S S Atribuído S Aderência (A): 10 , 0 4 / ) 10 , 0 4 ( 4 / ) 10 , 0 ( = × = × = A A Atribuído A

Características Explícitas (CE):

1 10 , 0 05 , 0 10 , 0 75 , 0 = + + + = + + + = CE CE A S P F CE

Características Implícitas (CI):

02 , 0 02 , 0 1 02 , 0 = × = × = CI CI n CI Qualidade dinâmica (QRd): 02 , 1 02 , 0 1 = + = + = QRd QRd CI CE QRd

Ponto de teste dinâmico (PTDf):

06 , 3 02 , 1 1 3 = × × = × × = PTDf PTDf QRd FDf PFf PTDf

Ponto de teste estático (PTE): 0 (Não existem checklist) Ponto de Teste (PT): 06 , 3 1 / 06 , 3 1 / ) 0 4 ( 06 , 3 1 / ) ( = = × + = × + = PT PT PT PTE PF PTDf PT

Considerando os valores acima calculados, podemos calcular a estimativa de tempo necessário para a realização de implementação de testes deste sistema, conforme abaixo:

Índice de Planejamento e Controle (IPC): 11 , 1 11 , 0 1 ) 08 , 0 03 , 0 ( 1 ) ( 1 = + = + + = + + = IPC IPC IPC FG TE IPC

Hora de Teste Primária (HTP):

06 , 3 1 1 06 , 3 = × × = × × = HTP HTP AT QET PT HTP

Total de Horas de Teste (THT):

4 , 3 11 , 1 06 , 3 = × = × = THT THT IPC HTP THT

A estimativa de tempo necessário para a realização de implementação de testes deste sistema seriam de 3,40 horas.

7 CONSIDERAÇÕES FINAIS

Podemos observar que apesar de ser um assunto já difundido, ainda não há uma maturidade da maioria das organizações, suficiente para que se quebrem velhos tabus e costumes e se passe a utilizar os testes como ferramenta primordial e essencial ao invés de secundária e de uso remoto.

Pode-se concluir também que para testar, casos de teste e pontos de teste, são ferramentas de importante utilização. Um caso de teste, por exemplo, não só ajuda no tratamento dos testes como também pode servir de guia para criação dos scripts de teste. Os pontos de teste são muito úteis para se estimar os custos do teste e o tempo necessário para sua execução, informações importantes que trazem benefícios para gestores e também ao controle do custo final do software.

Ao testar com eficácia um software, evitamos possíveis problemas que poderiam causar prejuízos, perda de tempo e custariam caro para serem corrigidos. É claro que um software nunca será perfeito e a prova de falhas, mas pode-se reduzir e muito esses defeitos até se alcançar um nível que possa ser aceito pela organização e seus clientes.

Como apresentado, a técnica de Análise de Pontos de Teste é bastante sólida e passível de ser usada como ferramenta de medição e estimativa de projetos deteste de software. Entretanto, alguns cuidados devem ser tomados ao transformar-se tamanho em esforço. Para isso é necessário fazer uma calibragem gradativa que permita adequar a técnica ao ambiente de cada empresa. Regras de correlação entre pontos de teste e horas de esforço não podem ser generalizadas. De qualquer forma esta técnica é uma ferramenta bastante útil para medir o tamanho e estimar o esforço, mesmo nos estágios iniciais do projeto. Neste caso, sugere-se o uso dos valores médios, desde que seja possível apurar-se também o tamanho estimado do software em pontos de função.

8 REFERÊNCIAS

BEIZER, Boris. Software Testing Techniques. 2nd ed. Hardcover, 1990.

DEKKERS, Ton; VEENENDAAL, Erik Van.Test point analysis:A method for estimatingtesteffort. ESCOM, 1999.

JACOBSON, Ivar; CHRISTERSON, Magnus; JOHSSON, Patrik.Object-Oriented Software Engineering:A use case driven approach. 1th ed. Addison Wesley, 1992.

MARCONI, Marina de A.; LAKATOS, Eva Maria. Metodologia Científica. 4. ed. São Paulo: Atlas, 2004.

MOLINARI, Leonardo. Testes de Software: Produzindo Sistemas Melhores e Mais Confiáveis. 1th ed. São Paulo: Érica, 2003.

Myers, Glenford J.Theartof software testing. 2nd ed. New Jersey: John Wiley&Sons,Inc, 2004.

PEZZÈ, Mauro; YOUNG, Michal. Teste e Análise de Software: Processos, Princípios e Técnicas. 1th ed. Porto Alegre: Bookman, 2008.

PRESSMAN, Roger S.Engenharia de Software. 3. Ed. São Paulo: Makron Books, Pearson Education do Brasil, 1995.

Relatório “The Economic Impact of Inadequate Infraestruture for Software Testing” (NIST, May 2002).

RIOS, Emerson; MOREIRA FILHO, Trayahu. Teste de Software. 1th ed. Rio de Janeiro: Alta Books, 2003.

YIN, Robert K. Estudo de Caso: Planejamento e Métodos. 2. ed. Porto Alegre: Bookman, 2001.

APÊNDICE A – Cenário dos Casos de Testes [CT01] Procedimento PT01 Entradas Campo Valor Lado A 12 Lado B 13 Lado C 17

Saídas Esperadas Triângulo Escaleno.

[CT02] Procedimento PT01 Entradas Campo Valor Lado A 0 Lado B 13 Lado C 17

Saídas Esperadas Triângulo Inválido

[CT03] Procedimento PT02 Entradas Campo Valor Lado A 4 Lado B 4

Lado C 4 Saídas Esperadas Triângulo Equilátero

[CT04] Procedimento PT02 Entradas Campo Valor Lado A 4 Lado B 4 Lado C 7

Saídas Esperadas Triângulo Isósceles

[CT05] Procedimento PT02 Entradas Campo Valor Lado A -2 Lado B 6 Lado C 7

Saídas Esperadas Triângulo Inválido

[CT06]

Procedimento PT02

Lado A

Lado B 4

Lado C 9