TESTES DE SOFTWARE

1
 SUMÁRIO

QUALIDADE E DEFEITOS ................................................................ 3

O CUSTO DA QUALIDADE ............................................................... 6

A GARANTIA DA QUALIDADE DE SOFTWARE (GQS) ................... 8

TESTES DE SOFTWARE: FUNDAMENTOS DE TESTE ................. 9

PRÉ-CONCEITOS DOS TESTES.................................................... 10

A IMPORTÂNCIA DOS TESTES ..................................................... 11

PRINCÍPIOS DE TESTE.................................................................. 13

TÉCNICAS DE TESTE .................................................................... 14

ESTÁGIOS DOS TESTES ............................................................... 19

EXECUÇÃO DOS TESTES ............................................................. 27

RELATÓRIOS DE TESTE ............................................................... 30

FERRAMENTAS DE TESTE ........................................................... 33

REFERÊNCIAS ............................................................................... 39

1
 NOSSA HISTÓRIA

A nossa história inicia com a realização do sonho de um grupo de empresários, em

atender à crescente demanda de alunos para cursos de Graduação e Pós-Graduação. Com
isso foi criado a nossa instituição, como entidade oferecendo serviços educacionais em nível
superior.

A instituição tem por objetivo formar diplomados nas diferentes áreas de conhecimento,
aptos para a inserção em setores profissionais e para a participação no desenvolvimento da
sociedade brasileira, e colaborar na sua formação contínua. Além de promover a divulgação de
conhecimentos culturais, científicos e técnicos que constituem patrimônio da humanidade e
comunicar o saber através do ensino, de publicação ou outras normas de comunicação.

A nossa missão é oferecer qualidade em conhecimento e cultura de forma confiável e

eficiente para que o aluno tenha oportunidade de construir uma base profissional e ética. Dessa
forma, conquistando o espaço de uma das instituições modelo no país na oferta de cursos,
primando sempre pela inovação tecnológica, excelência no atendimento e valor do serviço
oferecido.

2
QUALIDADE E DEFEITOS

Defeitos de software são os principais motivos que geram retrabalho, custos,

não cumprimento de prazos, redução da produtividade e insatisfação do Cliente.
(BARTIÉ, 2002)

E estes defeitos encontrados nos softwares recebem muitos nomes e

definições, como “problemas, falhas, ocorrências, incidentes, não conformidades e
inconsistências. Também podemos empregar palavras existentes na língua inglesa
como bugs, crash e abends”. (BARTIÉ, 2002)

Qual a melhor palavra para descrever que um software “travou” ou não está
agindo de forma correta?

Erro, Defeito e Falha

“É importante distinguir falha, erro e defeito para que se crie uma linguagem
comum entre os membros de uma equipe e para que se possa fazer uma análise de
causa raiz quando um problema ocorre.”

O erro significa que algo não está funcionando corretamente no software,

gerando inconsistências na aplicação. É conseqüência de uma falha, mas não são
todas as falhas que resultam em um erro, pois, a seqüência de execução pode não
gerá-los. [16]

Um defeito no software pode ser originado por omissão de alguma informação,

declaração de dados, controles incorretos ou vários outros motivos. Caso um defeito
não seja identificado ele passa a ser uma falha na execução do software.

A falha é quando um software não se comporta da forma esperada, ou não

retorna os resultados esperados.

3
 Figura 1 - Erros, defeitos e falhas

Bug

É um erro no funcionamento comum de um software,

também chamado de falha na lógica programacional de um
programa de computador, e pode causar discrepâncias no
objetivo, ou impossibilidade de realização, de uma ação na
utilização de um programa de computador ou apenas uma trava
no sistema.

O termo é utilizado para descrever problemas que não tem explicação, e esta
presente no mundo da informática a muito tempo. Tomas Edison em seus circuitos
elétricos já mencionava os bugs.

O Bug pode ser designado como um erro na execução de um software,

possivelmente resultando em inconsistências nos resultados esperados de um
programa. Abaixo a figura demonstra um exemplo da definição de Bug durante a criação
do código de um sistema, que quando é executado pelo usuári o não se comporta da
forma correta, resultando em uma falha.

Figura 2 - Erro de código: "If" sem "End If"

4
 Há uma imagem de que os bugs são encontrados somente no código fonte.
Assim como, entendem que somente o desenvolvedor e a equipe de qualidade são os
responsáveis pelos bugs. Nas duas afirmações a visão esta errada, pois os e bugs
podem ser gerados em todo o processo no desenvolvimento, como por exemplo,
resultados de uma especificação de requisito, análise, modelo de dados ou interface
do sistema feito de forma incorreta. (BARTIÉ, 2002)

Figura 3 - Exemplo de erro na especificação

Os erros estão em todas as etapas do processo, porém, estudos reforçam que

a maior parte está presente nas fases iniciais do projeto. No produto final são
encontrados muitos erros que resultaram da má especificação e clareza dos objetivos
que deveriam ser cumpridos. Se a qualidade fosse aplicada desde a definição do
projeto muita erros seriam identificados prematuramente evitando que fossem migrados
para as outras fases. (BARTIÉ, 2002)

5
 Figura 4 - Incidência de defeitos nas etapas de desenvolvimento

Fonte: (BARTIÉ, 2002)

O CUSTO DA QUALIDADE

“O custo da qualidade inclui todos os custos decorrentes da busca da qualidade

ou da execução das atividades relacionadas à qualidade.” (PRESSMAN R. , 2002)

Os custos investidos em qualidade são todos aqueles investimentos em um

produto ou serviço para que atendam a qualidade total e podem ser divididos em
custos da conformidade e custos da não conformidade. (BARTIÉ, 2002)

Os custos da conformidade são aplicados para alocar pessoas, processos e

ferramentas que previnam e detectem os erros do processo durante o desenvolvimento.
E os custos da não conformidade são aqueles ligados ao processo de reparação de
falhas ocorrido no decorrer do processo ou após a entrega do produto. (BARTIÉ, 2002)

A cada uma das fases está determinado um custo. Todos somados resultam no
custo total da qualidade contemplando o custo da construção.

6
 Figura 5 - Custo da Qualidade

Custo de Falhas – Envolve todos os custos associados a

produtos defeituosos, que já foram entregues aos usuários ou
disponibilizados em produção e que geraram algum tipo de falha.
Esses custos referem-se ao retrabalho para reparação de produtos
defeituosos, ou a prejuízos decorrentes das falhas no software.
Incluem-se nesta categoria, também os custos associados à
manutenção de um Help Desk.
Custo de Avaliação – Esse custo refere-se ao que é gasto
em procedimentos de verificação e em testes dos produtos de
software para identificação de defeitos, após a sua construção e
antes que sejam disponibilizados para uso ou implantados em
produção. Contempla tanto produtos intermediários, como
documentos de requisitos, modelos de dados ou especificações,
como também o produto de software final.

Custo de Prevenção – Mais que um custo, é um

investimento realizado para se evitar erros e fazer o trabalho certo
na primeira tentativa. É um investimento com retorno a médio ou
longo prazo e que contempla a criação de métodos e
procedimentos, a melhoria de processos, a capacitação dos
profissionais, a aquisição de ferramentas e o planejamento da
qualidade. Esse custo ocorre antes da criação do produto.

O custo da qualidade passa a ser sempre investimento quando realizado com o

intuito de melhorar e garantir o correto desenvolvimento de um produto. Porém, para que
este processo seja aplicado corretamente deve ser aplicado um montante de dinheiro,
profissionais e tempo. Para reduzir estes investimentos é importante identificar as
atividades com maior importância e criticidade. (BARTIÉ, 2002)

Para demonstrar a evidente vantagem de se manter um processo de qualidade

Bartié exibe o gráfico da Regra 10 de Myers5 demonstrando que identificar os erros nas
fases iniciais do processo custam menos dos que os ocorridos nas fases finais.

7
 Figura 6 - Regra 10 de Myers

Fonte: (BARTIÉ, 2002)

A GARANTIA DA QUALIDADE DE SOFTWARE (GQS)

O grupo de Garantia do Software tem como principal papel representar o Cliente,

quanto às avaliações sobre o software desenvolvido, analisando se o software atende
de forma correta os padrões de qualidade, se a parte técnica respeitou
adequadamente os papéis para cada atividade dentro do desenvolvimento.
(PRESSMAN, 2002)

O objetivo da GQS é fornecer resultados sobre a eficiência das etapas utilizadas

pelo desenvolvimento e sobre a qualidade do produto que será entregue. Para exibir
estes resultados, a equipe realiza um exame meticuloso no software buscando encontrar
se existem desvios de padrões e especificações determinadas ou que necessite de
melhorias.

Esta verificação deve ocorrer em todas as etapas do processo de

desenvolvimento com o intuito de prever defeitos antes do produto ser finalizado.

Todo processo de desenvolvimento por muitas vezes gera produtos defeituosos,

é importante obter um processo que descubra esses defeitos e garanta o bom

8
funcionamento do projeto. Estes defeitos geram problemas tanto para a imagem da
empresa quanto para o negócio. E para garantir que não impactem no projeto e que
sejam corrigidos foi criada a área a de Testes de Software. (BASTOS, A. et. al., 2007)

“A atividade de teste de software combina uma estratégia de múltiplos passos

com uma série de métodos de projeto de casos de testes6 que ajudam a garantir uma
detecção de erros efetiva”. (PRESSMAN, 2002)

TESTES DE SOFTWARE: FUNDAMENTOS DE TESTE

A atividade de teste é um ponto importante no processo de garantia da

qualidade e tem como responsabilidade representar a avaliação final da
especificação, projeto e processo de codificação. (PRESSMAN, 2002)

A atividade de teste constitui uma anomalia interessante

para o engenheiro de software. Durante as fases de definição e
desenvolvimento anteriores, o engenheiro tenta construir o software,
partindo de um conceito abstrato para uma implementação tangível.
Agora, surge a fase de testes. O engenheiro cria uma série de casos
de teste que têm a intenção de “demolir” o software que ele
construiu. De fato, a atividade de teste é um passo do processo de
engenharia de software que poderia ser visto (psicologicamente,
pelo menos) como destrutivo, em vez de construtivo. (PRESSMAN,
2002 p.787)

Os testes são executados na maioria das empresas como etapa do

desenvolvimento, e por muitas vezes é realizado pelos desenvolvedores ou usuários.
O objetivo é reduzir os defeitos originados pelo desenvolvimento. (BASTOS, A. et. al.,
2007)

Em um novo formato, os testes começam a ser realizados por profissionais

especializados para esta função, com uma metodologia apropriada e não mais por um
desenvolvedor. Pois, nem analistas, nem desenvolvedores, nem usuários possuem
capacidade técnica para execução dos testes. (BASTOS, A. et. al., 2007)

Se os testes forem realizados com sucesso serão identificados erros no

software. A área de testes exibe que o software desenvolvido atende as especificações
determinadas pelos requisitos. Além disso, a atividade de teste proporciona
confiabilidade no produto. (PRESSMAN, 2002)

9
 É importante saber que a atividade de teste não garante que os bugs não
existirão, ela apenas demonstra se há defeitos presentes no software. (PRESSMAN,
2002)

PRÉ-CONCEITOS DOS TESTES

Para que os testes sejam aplicados de forma correta é necessário eliminar

alguns pré-conceitos existentes em muitas equipes:

 A equipe de testes é inimiga da área de desenvolvimento: não há o

objetivo de demonstrar que alguns são mais competentes que os outros,
ou que erram constantemente. Existe apenas o intuito de produzir produtos
com qualidade.

 Desenvolvedores com pouca qualidade podem testar sistemas:

para que os testes tenham a correta funcionalidade é necessário ter uma
equipe capacitada, e que por muitas vezes necessitem até de certificados
para comprovar sua qualificação.

 Após terminar o desenvolvimento de software a equipe de teste

realizará seu papel: os testes devem ser executados desde o principio
do projeto, os testes executados no final do desenvolvimento são os
realizados pelo cliente, para apenas validar que o produto atende suas
necessidades. (BASTOS, A. et. al., 2007)

Outros pré-conceitos, segundo Davidson (2011):

 “...Implemente, se der tempo a gente testa.”

 “o importante é entregar... os testes, deixa que o cliente faz para

gente...”

 “o prazo vai estourar... Então sacrifique os testes..”

 “entregue com bugs, mas entregue em dia, depois agente arruma…”

 “sabemos que nosso software está cheio de bugs, então vamos

cobrar uma manutenção mensal do nosso cliente para consertá-

10
 los…”

 “testar não é uma atividade importante…”

 ”…como vamos testar se não temos tempo?”

 “…testar pra que? perda de tempo.”

 “pra desenvolver sem teste é X, com teste é X2…“

Por mais absurdas que pareçam ser estas afirmações, muitas empresas
aplicam ainda estes conceitos. (BASTOS, A. et. al., 2007)

A IMPORTÂNCIA DOS TESTES

Para que um software seja de alta qualidade é imprescindível que os testes

sejam realizados. Há um descuido quando isso não ocorre, já que não são analisados
os impactos de um produto com má qualidade. O negócio ou mesmo vidas (em caso
de software para aparelho médico, aviões e etc.) podem sofrer as consequências de
um software sem testes ou que não foram buscados os bugs adequadamente.

Exemplo disso:

Três anos atrás, o Station Casinos idealizou uma ótima

promoção para atrair clientes: oferecer 25 dólares de jogo gratuito
em máquinas caça-níqueis a partir de seus cartões de fidelidade
eletrônicos. Funcionou como mágica, apostadores afluíram ao
cassino em bandos. Era para ser uma boa estratégia de negócios.
Porém, em uma sexta-feira, logo depois de iniciada a
promoção, quando os jogadores inseriram seus cartões nas
máquinas, nada aconteceu. O grande número de pessoas tentando
acessá-las e ao mesmo tempo em que o departamento de
contabilidade rodava diversas aplicações financeiras travou os
servidores que armazenavam toda a informação promocional.
Irados, jogadores atiraram seus cartões de fidelidade no chão e
iniciaram um tumulto. Uma reação nada boa.

O problema foi causado devido à falta de testes para um volume de acessos tão
grande, fazendo com que a empresa deixasse de ganhar dinheiro e tivesse que criar
outra promoção para se redimir do erro e os clientes ficaram insatisfeitos com o
ocorrido.

11
 Outros exemplos:
A empresa Symantec proprietária do software antivírus Norton
que em junho de 2007 teve de compensar 50 mil vítimas de uma
atualização que retirava arquivos de sistema de uso, dando a
elas uma extensão de 12 meses da licença do Norton e uma cópia
da ferramenta Norton Save & Restore 2.0. (LOPES & CARNEIRO)
Em 1988, o navio US Vicennes derrubou um Airbus 320 causando
a morte de 290 pessoas, a falha foi atribuída ao software de
reconhecimento do navio que confundiu o avião com um F-14.

Todo software desenvolvido tem como objetivo atender demandas, e para que
seja garantida a eficácia dos programas é necessário testar os softwares, pois, sempre
existirá a probabilidade de se existirem defeitos, bem como reduzir custos e identificar
as qualidades dos softwares como: “confiabilidade, qualidade, desempenho,
usabilidade, portabilidade, segurança, recuperabilidade e outras.”

Segue abaixo um modelo de relacionamento entre o desenvolvimento do

software os testes.

Figura 7 - Modelo de relacionamento entre desenvolvimento e testes

Fonte: (BASTOS, A. et. al., 2007)

12
PRINCÍPIOS DE TESTE

Os testes devem ser executados em todas as etapas do projeto, mas, é

importante saber identificar até que momento os testes poderão ser executados, para
isto há duas situações a serem analisadas. (BASTOS, A. et. al., 2007)

Cobranças sobre prazos de projeto, onde os testes são interrompidos antes do

tempo definido, ou seja, não foram realizados todos os testes pré-definidos e o risco
de ocorrerem defeitos é muito maior.

Excesso de testes, quando são executados mais testes do que o previsto,

ultrapassando o tempo estimado e com um gasto maior do que o necessário.
(BASTOS, A. et. al., 2007)

Figura 8- Ponto de equilíbrio dos testes

Fonte: (BASTOS, A. et. al., 2007)

13
 O custo das falhas que possam vir a ocorrer num
ambiente de produção não compensa o gasto adicional de
dinheiro para tentar evitá-las. No caso de um software usado
nos controles de um avião, o ponto de equilíbrio ficará
bastante à direita, ao passo que, no caso de um site Web de
páginas estáticas, esse ponto estará bem a esquerda. Quanto
mais critico for o software, mais testes serão gastos para
garantir a qualidade desse produto. Isso equivale a dizer que
quem define a quantidade de testes é a criticidade do negócio.
(BASTOS, A. et. al., 2007)

TÉCNICAS DE TESTE

Durante o processo de desenvolvimento de um software serão aplicados dois

tipos de teste, o de verificação e o de validação. O teste de verificação é responsável
por certificar a qualidade de todos os pontos do desenvolvimento, concentrando-se
em duas formas de avaliação, a Revisão voltada para a documentação e a Auditoria
que garante a qualidade das atividades realizadas. Já o teste de Validação após
receber o software finalizado, é responsável por apontar os erros gerados em
processos isolados ou no produto completo, para que estes testes abordem todas as
áreas do software são definas algumas técnicas para a execução dos mesmos.
(BASTOS, A. et. al., 2007)

Testes de Caixa Branca

O teste de caixa branca é responsável por avaliar a parte interna do software,

atuando diretamente no código fonte avaliando os testes de condição, fluxo de dados,
ciclos, caminhos lógicos.

O objetivo principal é apontar defeitos utilizando a simulação de condições que

realizem corretamente a estrutura feita durante a codificação. Possuem grande
eficiência na identificação de erros, porém, são mais difíceis de implantar. (BARTIÉ,
2002)

14
 Figura 9 - Execução Testes Caixa Branca

Fonte: (BARTIÉ, 2002)

Para a realização dos testes de caixa branca foram definidos testes específicos
para cada situação. (BASTOS, A. et. al., 2007)

Teste de Estresse

O teste de estresse é executado para forçar situações extremas de utilização do

software, avaliando até que ponto exigir em memória, espaço em disco e CPU. É
importante analisar a quantidade de dados que recebe acima da média estipulada.
(BASTOS, A. et. al., 2007)

Teste de Execução

É responsável por analisar o tempo de resposta, da execução e de performance

do software em produção. Em um software feito por etapas e por equipes diferentes
este teste seria responsável por executar o teste por completo. [26]

Teste de Recuperação

Este teste analisa a capacidade do software de recuperar as informações ao ser

reiniciado após uma perda da integridade. Exige que o software retorne em uma etapa
do processo onde a continuidade não seja afetada. (BASTOS, A. et. al., 2007)

Teste de Operação

São testes utilizados no ambiente de operação em que atuará, com usuários que
irão executar a ação e com os procedimentos determinados verificando se a aplicação
irá funcionar adequadamente. (BASTOS, A. et. al., 2007)

Teste de Conformidade

Verifica se o produto final atende a todas as especificações de padrão, normas,

15
procedimentos e as guias de TI.

Teste de Segurança

É um procedimento importante para se avaliar a segurança das informações do

software, garantindo a confidencialidade e proteção dos dados. Este teste tem o
objetivo de evitar que informações sejam acessadas por pessoas não autorizadas
comprometendo o negócio ou fornecendo informações para empresas concorrentes.
(BASTOS, A. et. al., 2007)

Testes de Caixa Preta

É responsável por analisar o comportamento externo do software, sem se

preocupar se internamente os processos estão sendo executados corretamente. Para
executar são inseridos dados de entrada, os testes são executados e o resultado da
execução é comparado ao resultado esperado. Para que o teste seja cada vez mais
funcional é importante fornecer todas as entradas de dados possíveis.

O teste de caixa preta não exige que o responsável tenha conhecimento lógico
da tecnologia aplicada, os testes são mais simples do que o de caixa branca. A única
dificuldade de realizar este tipo de teste é exigir que a equipe responsável pela
homologação realize um planejamento detalhado e apurado para que seja possível
identificar todos os cenários possíveis. (BARTIÉ, 2002)

Figura 10 - Execução Teste Caixa Preta

Fonte: (BARTIÉ, 2002)

16
 Teste de Requisitos

Os testes de requisitos analisam se o software esta executando de forma correta

as funcionalidades e se possui capacidade de continuar eficiente após ser utilizado por
um período contínuo. (BASTOS, A. et. al., 2007)

Teste de Regressão

Tem o objetivo de analisar se algo foi alterado de como era realizado antes da
nova funcionalidade ser aplicada, ou seja, é retestar etapas já testadas após uma
alteração no software. São executados tanto no software quanto na documentação.
(BASTOS, A. et. al., 2007)

Teste de Tratamento de Erros

Estes testes são executados forçando os erros no sistema, para analisar a

capacidade do software de lidar com informações incorretas. Exigindo que o
responsável pelo teste pense de forma negativa e informe dados de entrada
incorretos, analisando a forma de resposta do software.

Teste de Suporte Manual

Analisa se os manuais e guias para os usuários estão sendo feitos de forma

correta, se estão completos.

Teste de Interconexão

São executados quando o software em questão possui conexão com outros

softwares, analisando se os dados estão sendo transferidos de forma correta.
(BASTOS, A. et. al., 2007)

Teste de Controle

Assegura que o processamento seja realizado conforme sua intenção. Entre os

controles estão a validação de dados, a integridade dos arquivos, as trilhas de auditoria,
o backup e a recuperação, a documentação, entre outros.

Teste Paralelo

Realizar uma comparação dos dados gerados pela nova versão do software com
a versão anterior, exigindo que os dados de entrada sejam os mesmos executando em
duas versões do mesmo software, caso os requisitos sejam os mesmo apenas as

17
versões foram alteradas os resultados devem ser iguais nas duas. (BASTOS, A. et. al.,
2007)

Testes de Caixa Cinza

Os testes de caixa cinza utilizam tanto os testes de caixa preta quanto os testes
de caixa branca, envolvendo a estrutura dos dados e os algoritmos. Fornecendo dados
de entrada e verificando a execução interna destes dados validando a saída dos
mesmos.

18
ESTÁGIOS DOS TESTES

Figura 11 - Fases dos Testes

Fonte: (BARTIÉ, 2002)

Teste de Unidade

É realizado em unidades menores do sistema, analisando métodos e partes pequenas

do código em busca de falhas de execução. Verificando individualmente estas pequenas etapas
para garantir que cada uma está sendo executada corretamente.

Teste de Integração

Este teste garante que não haverá erros quando todas as etapas individuais do sistema
forem executadas de forma integrada. Normalmente são encontrados erros de transição de
dados. Não faz parte deste teste avaliar a conexão com outros sistemas (teste de interconexão).

19
 Teste de Sistema

Realiza a execução do sistema como um todo para verificar as funções seguindo os

cenários criados para os testes.

Teste de Aceitação

Esta fase é realizada pelos usuários do sistema, validando se o que foi desenvolvido
atende as especificações solicitadas. É um teste a ser realizado pelo cliente solicitante de forma
formal para que avalie se irá aceitar ou não o sistema.

Elaboração dos Testes

Documentação dos Testes

Na etapa de Testes de um projeto, o tempo gasto com a documentação dos testes é de

50% a 60%. (BASTOS, A. et. al., 2007)

Através da Norma IEEE 829-19987 foram definidos documentos para a equipe de testes,
entre eles o documento de elaboração dos testes. O Plano de Teste é o documento que será
origem para os demais documentos. (BASTOS, A. et. al., 2007)

Plano de Teste: Documenta todo o planejamento para a realização dos testes,

apontando os itens que serão testados, quais atividades serão executadas e os riscos dos
testes. Identifica também quais serão os ambientes a serem testados.

Durante a fase de Elaboração dos Testes serão utilizados três documentos:

 Especificação do projeto de Teste: Documento detalhado sobre o plano de

teste, identificando também os casos de teste e procedimentos que serão
utilizados, apresentando os critérios para aprovação. (BASTOS, A. et. al., 2007)

 Especificação de casos de Teste: Serão descritos os casos de teste,

identificando quais os dados de entrada a serem utilizados, quais serão os
resultados, ações e formas de execução dos testes. Este documento pode também
ser chamado de Plano de Caso de Testes. (BASTOS, A. et. al., 2007)

 Especificação do procedimento de Teste: Demonstra todas as necessidades

para operar o software e os casos de teste com objetivo de atender o
planejamento de testes. Este documento tem por objetivo ser seguido sem
nenhum imprevisto. (BASTOS, A. et. al., 2007)

20
 Figura 12- Modelo IEEE STD 829-1998

Fonte: (BASTOS, A. et. al., 2007)

Plano de Casos de Teste

É o documento que aponta o planejamento dos testes elaborados de acordo com os

requisitos determinados no desenvolvimento do sistema. Determinando os itens a serem
testados, o principal objetivo deste documento é registrar a maior quantidade de cenários
possíveis. Os cenários serão representados por um grupo de casos de testes que serão
verificados de acordo com uma listagem de procedimentos. (BARTIÉ, 2002)

Casos de Teste

A melhor definição para casos de teste é o maior detalhamento possível de um teste, com
especificações de telas e formulários. São identificadas as informações que serão utilizadas
durante o teste e quais serão os resultados retornados. Um caso de teste considerado bom deve
conter: (BASTOS, A. et. al., 2007)

21
  Identificação das condições de testes:
 Pré-condições;
 Pós-condições;
 Critério de aceitação.
 Identificação dos casos de testes (o que testar).
 Detalhamento da massa de entrada e de saída.
 Critérios especiais, caso necessário, para a geração da
massa de teste.
 Especificação das configurações de ambiente no qual o
teste será executado: sistema operacional, ferramentas
necessárias, origem dos dados etc. (onde testar)
 Definir o tipo de implementação do teste:
automática/manual (como testar).
 Listar as interdependências, caso existam, entre os casos
de teste. (BASTOS, A. et. al., 2007)

Derivação do Caso de Teste

Para os testes funcionais um caso de teste costuma ser derivado de um caso de uso. É
necessário criar um caso de teste que atenda a cada caso de uso. (BASTOS, A. et. al., 2007)

Na metodologia RUP os casos de uso possuem vários caminhos refletindo, os possíveis

fluxos básicos e alternativos, sendo identificados pelas setas. (BASTOS, A. et. al., 2007)

Figura 13 - RUP – Caso de Uso

Fonte: (BASTOS, A. et. al., 2007)

O fluxo básico ou principal, representado pela linha preta e retilínea, é o caminho mais

22
simples através do caso de uso. Cada fluxo alternativo começa no fluxo principal e depois, de
acordo com uma condição especifica, é executado. Os fluxos alternativos podem retornar ao
fluxo básico (como, por exemplo, os fluxos alternativos 1 e 3 da imagem acima), podem se
originar de outro fluxo alternativo (fluxo alternativo 2) ou terminar o caso de uso sem retornar a
um fluxo (fluxos alternativos 2 e 4). (BASTOS, A. et. al., 2007)

Com os caminhos exibidos na figura é possível identificar os cenários de uso.

Possibilitando a criação dos cenários de teste. (BASTOS, A. et. al., 2007)

Exemplos de Caso de Teste

Casos de Teste elaborados de acordo com a visão de Bastos, A.et. al. (2007).

Apresentação do Software

O software exibirá dois campos: Login e Senha.

O software exibirá as seguintes opções de confirmação: Ok e Limpar.

Caso o usuário acione a opção Limpar:

O software deverá excluir as informações de Login e Senha.

Caso o usuário acione a opção Ok:

O software verifica o preenchimento do Login e Senha que são campos obrigatórios.

O software valida as informações inseridas nos campos Login e Senha.

Exceções do Software

E1 – Campos de preenchimento obrigatório.

Se o usuário não preencher um dos campos ou os dois:

O software exibirá uma mensagem informativa: “O(s) <<campo>> deve(m) ser

preenchido(s)” e retorna para a tela inicial.

E2 – Verificação de login e senha.

Caso um dos campos não tenha sido preenchido corretamente o software apresentará a
mensagem informativa: “O dados não são válidos” e retorna para a tela inicial.

E3 – Login bloqueado

23
 O software valida se o login informado esta bloqueado, exibe a mensagem informativa:
“Login bloqueado” e retorna para a tela inicial.

Regras de Negócio

RN01 – Bloqueio de Login

Caso o usuário realize três tentativas incorretas de acesso ao software, o mesmo irá
bloquear o acesso deste login.

Regras de Usabilidade

US01 – Formatação

O campo Login não deverá realizar a diferenciação de letras maiúsculas e minúsculas

(case insensitive), já o campo senha deverá realizar esta diferenciação (case sensitive).

Protótipo da Tela

SISTEMA EMPRESARIAL

Login:
Senha:

Definição Casos de Teste

CT01 – Campos Obrigatórios

24
*PA: Passo do Autor

**PS: Passo do Software

CT02 – Login incorreto

25
CT03 – Senha incorreta

CT04 – Login bloqueado

26
 CT05 – Login efetuado corretamente

EXECUÇÃO DOS TESTES

Segundo Bastos, A.et. al. (2007) após ser desenvolvido o plano de testes a próxima etapa
será a execução dos testes, importante que quanto mais detalhado e fiel ao sistema o plano de
testes estiver, mais fácil será o trabalho do testador. Para cada etapa dos testes há um
responsável por eles, sendo:

 Testes Unitários – Programadores

 Testes de Integração - Analistas de Sistemas
 Testes de Sistema – Analistas de Teste
 Testes de Aceitação – Usuários com a ajuda dos analistas de teste.

Quem irá executar os testes e como serão executados deve estar registrado no Plano de
Testes.bem como os resultados de cada. (BASTOS, A. et. al., 2007)

Abaixo segue figura que exibe como devem ser realizados os testes:

27
Figura 14 - Fluxo dos Testes

Fonte: (BASTOS, A. et. al., 2007)

Execução de Testes Unitários

Os testes unitários são os primeiros a serem executados, e devem ser executados pelos
programadores, os testes são criados durante a etapa de desenvolvimento. O principal objetivo
é testar isoladamente cada parte do software para garantir que irão funcionar corretamente.

28
 Execução dos Testes de Integração

Para Bastos, A.et. al. (2007) após serem executados todos os testes unitários, os
analistas devem executar os testes de integração e garantir que os componentes integrados
funcionarão com sucesso. Os itens a serem testados são:

 Validação de todos os links entre as diversas camadas;

 Controles de Segurança;

 Teste de carga e de desempenho / performance dos

diversos componentes, considerando-se os bancos de
dados e a rede;
 Sequência de inclusão, exclusão, consulta e alteração;

 Execução completa de uma transação;

 Testes para situações especiais, como, por exemplo, um

banco de dados vazio ou uma parte da rede fora do ar;
 Acurácia dos dados de saída.

Execução dos Testes de Sistema

Após todos os testes de integração serem finalizados e realizados com sucesso,

começam os testes de sistema. O teste de sistema tem como papel garantir que todos os
requisitos do sistema foram atendidos e implantados corretamente. E serão executados pela
equipe de testes. (BASTOS, A. et. al., 2007)

Execução dos Testes de Aceitação

Serão executados pelos usuários ou gestores do sistema utilizando os próprios requisitos

definidos para validar. A equipe de testes pode participar desta validação para auxiliar os
usuários.

29
RELATÓRIOS DE TESTE

A norma IEEE 829-1998 define alguns relatórios para acompanhar o processo

de teste dos projetos:

 Log de Teste;

 Incidentes de Teste;

 Sumário de Teste;

Figura 15 - Documentos necessários para o processo de Teste

Fonte: (BASTOS, A. et. al., 2007)

Relatório Log de Teste

Todas as informações que forem relevantes durante a etapa de testes devem ser
registradas neste relatório, é composto pelos seguintes itens:

30
 Identificador: identificador único e específico para o relatório, por
exemplo, o nome do sistema com número do release mais data e hora
do teste;

 Descrição: identificar o que foi testado e o ambiente em que o teste foi

executado incluindo hardware, quantidade de memória utilizada, etc;
 Atividades e eventos: para cada evento, identificar data/hora, tempo
utilizado e responsável;
 Descrição da execução: descrever o que foi feito e identificar os
responsáveis pela atividade incluindo testadores, observadores e
operadores;
 Resultados dos procedimentos: para cada execução, descrever os
resultados encontrados podendo ser sucesso ou não;
 Informações sobre ambiente de teste: informar qualquer condição
específica do ambiente de teste, caso seja necessário;
 Eventos imprevistos: descrever detalhadamente o que aconteceu antes
e depois de uma atividade ou evento inesperado.

31
 Relatório Incidentes de Teste

O relatório de incidentes registra todas as informações de diferenças que ocorreram entre

o resultado determinado e o realizado durante a realização dos casos de teste. Os itens
apontados devem ser detalhados o máximo possível para repassar à equipe de desenvolvimento,
é composto pelos itens:

 Identificador do relatório: identificador único e específico para o

relatório, por exemplo, release testado mais o identificador de um caso
de teste;
 Sumário da ocorrência: uma breve descrição do incidente; Identificar
os itens de teste envolvidos indicando sua versão, caso seja
necessário; adicionar referência para a especificação do caso de teste,
assim o desenvolvedor que for corrigir o defeito terá uma base de
documento de teste além do documento de requisitos e adicionar
também o relatório de log de teste, se necessário;
 Descrição do incidente: prover uma descrição do incidente Incluindo os
seguintes itens:
 Entradas;

 Resultados esperados;

 Resultados encontrados;

 Problemas;

 Data e hora do incidente;

 Procedimentos para reproduzir o problema;

 Ambiente;

 Tentativas para repetir o problema;

 Testadores;

 Observadores.

Vale lembrar que outras informações podem ser incluídas sempre que
necessário e nem sempre todos os campos acima serão necessários.
Impacto: indicar qual o impacto que o incidente terá no plano de teste
de execução podendo falhar, bloquear o(s) testes(s) ou até mesmo uma
possível mudança no caso de teste ou requisitos. Se possível, informar
a prioridade e severidade do incidente.Os incidentes de teste devem
ser armazenados em um repositório e, caso necessário, revisar o
relatório de incidentes de teste com as partes interessadas.

32
 Relatório Sumário de Teste

O objetivo deste relatório é resumir todas as informações relacionadas aos estes. É

composto pelos itens:

 Identificador: identificador único e específico para o relatório, por

exemplo, release e/ou projeto testado;
 Sumário: sumarizar a evolução das atividades de teste identificando os
itens testados e o ambiente utilizado para execução dos testes;
 Variações: informar qualquer procedimento diferente do que estava
especificado no plano de teste e procedimentos de teste; especificar o
motivo da utilização do procedimento alternativo;
 Avaliações do processo: avaliação resumida do processo adotado
contra o especificado no plano de teste; identificar as funcionalidades
ou combinações de teste que não foram exercitadas explicando a
razão; qualquer ocorrência que possa impactar na qualidade do
software/produto deve ser considerada;
 Sumário dos resultados: sumarizar os resultados de teste
identificando o número de casos de teste executados, número de
defeitos encontrados, número de defeitos fechados e abertos, etc;
 Avaliação do(s) teste(s): proporcionar uma avaliação global de cada
item, incluindo suas limitações. Essa avaliação deve ser baseada nos
resultados dos casos de teste e nos critérios de aprovação/reprovação;
 Sumário de atividades: resumir os recursos envolvidos no projeto de
teste, número total de horas utilizadas no projeto, tempo total utilizado
para cada atividade principal, etc;
 Aprovações: listar o nome e títulos das pessoas responsáveis pela
aprovação do projeto de teste incluindo os relatórios.

Ferramentas de Teste

Testes em Aplicações Web

Selenium: É um software que permite criar scripts de execução dos testes automatizados.
Funciona como uma continuação do Firefox e possibilita salvar, alterar e depurar todos os testes.

33
 Figura 16 - Ferramenta Selenium

Watir: Foi desenvolvido para criar testes automatizados para ambiente web. Para realizar
os testes o ambiente é realizado diretamente no navegador simulando a utilização do usuário.
Pode ser usado nos browsers Internet Explorer, Firefox, Linux e Mac.

BadBoy: É uma ferramenta criada em C++, que armazena todas as atividades realizadas
em um browser, permitindo modificar parâmetros, inserir textos, cor e etc.

34
 Figura 17 - Ferramenta BadBoy

Canoo WebTest: É uma ferramenta que possui o código aberto para a criação de testes
de automação em ambiente web.

Figura 18 - Ferramenta Canoo WebTest

Testes de Desempenho

JMeter: É uma ferramenta da Apache que permite a execução de testes de carga e stress

35
do sistema.

Figura 19 - Ferramenta JMeter

Gerenciar Casos de Teste

TestLink: É uma ferramenta que gerencia os casos de teste e execução dos casos

Figura 20 - Ferramenta TestLink

Gerenciar Defeitos

36
 Bugzilla: É uma ferramenta que se baseia em Web aplicando suporte ao Mozilla,
identificando defeitos.

Figura 21 - Ferramenta Bugzilla

Mantis: É uma ferramenta que gerencia defeitos encontrados pela equipe de testes, foi
desenvolvida em linguagem PHP e possui o código aberto.

37
Figura 22 - Ferramenta Mantis

38
REFERÊNCIAS

ANDRADE, Gabriel. O que é um Bug. 2007. Disponível

em:<http://www.infoescola.com/informatica/bug/>. Acessado em 12 de Novembro de 2019.

BARTIE, Alexandre. Garantia da Qualidade de Software. Rio de Janeiro: Elsevier, 2002.

BASTOS, Anderson; RIOS, Emerson; CRISTALLI, Ricardo; MOREIRA, Trayahú. Base de

conhecimento em teste de software. São Paulo: Martins, 2007.

BARTIÉ, Alexandre. Garantia da qualidade de software. Elsevier, 2002.

BLANCO, Mariana. Documentação de teste baseado na Norma IEEE 829, 2012. de

Projeto, P. R. G., de Configuração, J. M. G., de Qualidade, M. S. E., & de Negócios, P. A. C.
A. Plano de Testes., 2013

CAMPOS, Fábio Martinho. Qualidade, Qualidade de Software e Garantia da Qualidade de

Software são as mesmas coisas?. 2008. Disponível em:<
http://www.linhadecodigo.com.br/artigo/1712/Qualidade-Qualidade-de-Software-e-Garantia-
da-Qualidade-de-Software-s%C3%A 3o-as-mesmas-coisas.aspx>. Acessado em 29 de
Setembro de 2019

CAROCA, Caio. UM PROCESSO DE VERIFICAÇÃO E VALIDAÇÃO PARA O

MIDDLEWARE GINGA, 2010.

CROSBY, Philip B. Quality is free: The art of making quality certain. Signet, 1980.

FLEISCHER, Deborah et al. Evaluation of Open Source Tools for Test Management and
Test Automation. Seminararbeit DHBW Stuttgart, 2012.

FIORINI, Soeli T.; STAA, Arnlt Von; BAPTISTA, Renan Martins. Engenharia de Software com
CMM. Rio de Janeiro: Brasport, 1998

GARVIN, David A. What does product quality really mean. Sloan management review, v.
26, n. 1, 1984.

HÜBNER, Marcos L. F.; BAPTISTA, Michele M.; BERTÉLI, Michele O. Guia para elaboração
de trabalhos acadêmicos. Caxias do Sul: UCS, 2012. 83 p. : il. ; 30 cm.

JUNIOR, Walteno; PRADELA, Izaura; OLIVEIRA, Lucineida. O USO DA NORMA 14598 NA

AVALIAÇÃO DE SOFTWARE. 2009.

KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de software. 2006.

TESTLINK (Org.). Testlink User Manual. 19. ed. San Franscisco: Gnu, 2010. 52 p.

LOURENÇO. Qualidade de Software: Um Compromisso da Empresa Inteira. 1997.

Disponível em:<http://qualidade-de-software.blogspot.com/2010/03/qualidade-de-software-
um-compromisso- da.html>. Acessado em 25 de Setembro de 2019.

39
MAFRA, S. N., & Travassos, G. H., Técnicas de leitura de software: Uma revisão
sistemática. XIX Simpósio Brasileiro de Engenharia de Software, SBES, 5. 2005.

MOLINARI, Leonardo. Testes de software: produzindo sistemas melhores e mais

confiáveis: qualidade de software: soluções, técnicas e métodos. Érica, 2008.

MYERS, Glenford J.; SANDLER, Corey; BADGETT, Tom. The art of software testing. John
Wiley & Sons, 2011.

NITA, E. F., Melhoria da Qualidade de Produto e de Processo de Software a partir da Análise

de Indicadores de Teste. Simpósio Brasileiro de Engenharia de Software. Gramado, RS.
2002.

PRESSMAN, Roger. Engenharia de Software. São Paulo: Makron Books, 2002.

PRESSMAN, Roger S. Engenharia de software. McGraw Hill Brasil, 2011. PROJECT

MANAGEMENT INSTITUTE, Um Guia do conhecimento em gerenciamento de projetos –
Quarta edição. 2008.

REDMINE. User Guide. Disponível em: <

http://www.redmine.org/projects/redmine/wiki/User_Guide> Acessado em outubro de 2015.

REZENDE, Denis Alcides, Engenharia de Software e Sistemas de Informação. 2005.

RIOS, Emerson; MOREIRA FILHO, Teste de Software. 2013.

SOMMERVILLE, Ian. Engenharia de software. São Paulo: Addison Wesley, 2011. SILVA,
Monique, MORENO Autran. Automação Em Testes Ágeis. 2011.

TAVARES, Anderson. Qualidade, Processos e Teste de Software. 2010. Disponível

em:<http://qualidadeeteste.blogspot.com/2011/05/qualidade-de-software-parte-i.html>.
Acessado em: 25 de Setembro de 2019.
VASCONCELOS, Alexandre, Plano de Teste - Um Mapa Essencial para Teste de Software.
2012.

WAZLAWICK, Raul, Análise e Design Orientados a Objetos para Sistema de Informação,

3ª Edição. 2010.

40