Curso Técnico em Informática

Testes de Software
Robson Braga de Andrade
Presidente da Confederação Nacional da Indústria

Rafael Lucchesi
Diretor do Departamento Nacional do SENAI

Regina Maria de Fátima Torres

Diretora de Operações do Departamento Nacional do SENAI

Alcantaro Corrêa
Presidente da Federação da Indústria do Estado de Santa Catarina

Sérgio Roberto Arruda

Diretor Regional do SENAI/SC

Antônio José Carradore

Diretor de Educação e Tecnologia do SENAI/SC

Marco Antônio Dociatti

Diretor de Desenvolvimento Organizacional do SENAI/SC
 Confederação Nacional da Indústria
Serviço Nacional de Aprendizagem Industrial

Curso Técnico em Informática

Testes de Software

Carlos Eduardo Carvalho

Florianópolis/SC
2011
É proibida a reprodução total ou parcial deste material por qualquer meio ou sistema sem o prévio consentimento
do editor.

Autor Fotografias
Carlos Eduardo Carvalho Banco de Imagens SENAI/SC
http://www.sxc.hu/
http://office.microsoft.com/en-us/ images/
http://www.morguefile.com/
http://www.bancodemidia.cni.org.br/

Ficha catalográfica elaborada por Luciana Effting CRB14/937 - Biblioteca do SENAI/SC Florianópolis

C331t
Carvalho, Carlos Eduardo
Teste de software / Carlos Eduardo Carvalho. – Florianópolis :
SENAI/SC/DR, 2011.
59 p. : il. color ; 30 cm.

Inclui bibliografias.

1. Software. 2. Software - Controle de qualidade. 3. Software - Testes. 4.

Engenharia de software. I. SENAI. Departamento Regional de Santa
Catarina. II. Título.

CDU 004.415.53

SENAI/SC — Serviço Nacional de Aprendizagem Industrial

Rodovia Admar Gonzaga, 2.765 – Itacorubi – Florianópolis/SC
CEP: 88034-001
Fone: (48) 0800 48 12 12
www.sc.senai.br
Prefácio
Você faz parte da maior instituição de educação profissional do estado.
Uma rede de Educação e Tecnologia, formada por 35 unidades conecta-
das e estrategicamente instaladas em todas as regiões de Santa Catarina.

No SENAI, o conhecimento a mais é realidade. A proximidade com as

necessidades da indústria, a infraestrutura de primeira linha e as aulas
teóricas, e realmente práticas, são a essência de um modelo de Educação
por Competências que possibilita ao aluno adquirir conhecimentos, de-
senvolver habilidade e garantir seu espaço no mercado de trabalho.

Com acesso livre a uma eficiente estrutura laboratorial, com o que existe
de mais moderno no mundo da tecnologia, você está construindo o seu
futuro profissional em uma instituição que, desde 1954, se preocupa em
oferecer um modelo de educação atual e de qualidade.

Estruturado com o objetivo de atualizar constantemente os métodos de

ensino-aprendizagem da instituição, o Programa Educação em Movi-
mento promove a discussão, a revisão e o aprimoramento dos processos
de educação do SENAI. Buscando manter o alinhamento com as neces-
sidades do mercado, ampliar as possibilidades do processo educacional,
oferecer recursos didáticos de excelência e consolidar o modelo de Edu-
cação por Competências, em todos os seus cursos.

É nesse contexto que este livro foi produzido e chega às suas mãos.
Todos os materiais didáticos do SENAI Santa Catarina são produções
colaborativas dos professores mais qualificados e experientes, e contam
com ambiente virtual, mini-aulas e apresentações, muitas com anima-
ções, tornando a aula mais interativa e atraente.

Mais de 1,6 milhões de alunos já escolheram o SENAI. Você faz parte

deste universo. Seja bem-vindo e aproveite por completo a Indústria
do Conhecimento.
Sumário
Conteúdo Formativo 9 26 Unidade de estudo 3 40 Unidade de estudo 6
Processo de teste de Execução dos
Apresentação 11 software testes

27 Seção 1 - Ciclo de vida de de- 41 Seção 1 - Contexto dos

12 Unidade de estudo 1 senvolvimento de software testes
O que é o teste de 28 Seção 2 - Conceito “V” de 42 Seção 2 - Processo de execu-
software? teste ção dos testes
28 Seção 3 - Ciclo de vida do 45 Seção 3 - Relatório de teste
processo de teste segunda a IEEE 829
13 Seção 1 - Metodologia
29 Seção 4 - Preparação do 46 Seção 4 - Gerenciamento de
de desenvolvimento de
ambiente comunicação do projeto de
software
teste
13 Seção 2 - Objetivos do teste
de software
32 Unidade de estudo 4
14 Seção 3 - O que é teste de 48 Unidade de estudo 7
software? Análise de riscos
Teste de aceitação
15 Seção 4 - E se não testar o
software?
16 Seção 5 - Casos de testes 33 Seção 1 - Definição de risco
49 Seção 1 - Definição dos crité-
16 Seção 6 - Tipos de testes 33 Seção 2 - Riscos relativos ao rios de aceitação
teste de software
49 Seção 2 - Elaboração do
33 Seção 3 - Determinação da plano de aceitação
20 Unidade de estudo 2 magnitude dos riscos
50 Seção 3 - Execução do teste
34 Seção 4 - Controle dos riscos
Técnicas de teste de de aceitação
software

36 Unidade de estudo 5 52 Unidade de estudo 8

21 Seção 1 - O que é técnica de
Planejamento dos Estimativas
teste?
testes
21 Seção 2 - Técnicas funcional,
estrutural e baseadas em
53 Seção 1 - Análise do ponto
erros
37 Seção 1 - Plano de teste, o de teste
21 Seção 3 - Critérios para gera- que é isso?
54 Seção 2 - Estimativa baseada
ção de casos de teste
37 Seção 2 - Desenvolvimento no tamanho e complexidade
24 Seção 4 - Níveis de teste do plano de teste do caso de uso
39 Seção 3 - Documentação do
teste
Finalizando 57

Referências 59
8 CURSOS TÉCNICOS SENAI
Conteúdo Formativo
Carga horária da dedicação

Carga horária: 30 horas

Competências

Aplicar testes relacionados ao desenvolvimento de software para validação da

solução computacional.

Analisar os resultados de testes realizados em sistemas computacionais.

Conhecimentos

▪▪ Diário de teste;
▪▪ Especificação de teste;
▪▪ Especificação e relato de teste;
▪▪ Especificações de caso de teste;
▪▪ Especificações de procedimento de teste;
▪▪ Especificações de projeto de teste;
▪▪ Ferramenta de teste;
▪▪ Metodologia de desenvolvimento de programa de computador;
▪▪ Metodologia de teste;
▪▪ Normas técnicas vigentes;
▪▪ Procedimento de teste;
▪▪ Registro de teste;
▪▪ Relato de teste;
▪▪ Relatório de encaminhamento de item de teste;
▪▪ Relatório de incidente de teste;
▪▪ Relatório-resumo de teste;
▪▪ Requisitos de ambiente;
▪▪ Técnicas de teste.

Habilidades

▪▪ Identificar os tipos de teste a serem executados no procedimento;

▪▪ Utilizar o plano de testes;
▪▪ Interpretar as especificações de teste;

TESTES DE SOFTWARE 9
 ▪▪ Testar os programas;
▪▪ Elaborar registros de teste;
▪▪ Identificar defeitos e falhas em programas de computador;
▪▪ Utilizar artefatos de manutenção;
▪▪ Elaborar registros na documentação da manutenção de programas de computa-
dor.

Atitudes

▪▪ Organização e zelo na utilização de equipamentos;

▪▪ Foco no conteúdo trabalhado;
▪▪ Acesso a sítios relacionados ao tema trabalhado;
▪▪ Organização e limpeza dos ambientes coletivos;
▪▪ Dedicação e empenho nas atividades curriculares e extra-curriculares;
▪▪ Capacidade de abstração;
▪▪ Trabalho em equipe;
▪▪ Apresentação de novas soluções para situações problemas;
▪▪ Cumprimento de prazos;
▪▪ Análise crítica da solução proposta.
Apresentação
Caro aluno, Carlos Eduardo Carvalho
imagine a seguinte situação...
Formado em Engenharia Elé-
É início do mês, você recebeu o seu merecido salário e agora vai fazer o trica pela Udesc – Joinville.
pagamento de uma conta por meio do site do banco. Você precisa trans- Atuou em desenvolvimento
ferir R$ 100,00 para poder efetuar este pagamento. Mas, como muitas de software e hardware para
pessoas estão fazendo a mesma coisa que você, o sistema do banco dá equipamentos eletrônicos, em
aquela “travada”. Quinze segundos depois o sistema volta e a sua tran- usinas hidroelétricas. Leciona
sação foi efetuada. No dia seguinte, você vê o seu saldo e percebe que as disciplinas de lógica de pro-
foram debitados R$ 200,00 da sua conta! E agora? O que aconteceu com gramação, microcontroladores,
o sistema? Ele estava preparado para fazer todas aquelas transações ao acionamentos elétricos e proje-
tos elétricos nos cursos técnicos
mesmo tempo? Ele foi testado para verificar se havia problemas caso o
de automação, mecatrônica e
sistema travasse? eletrotécnica. Atua em STT, de-
Esse material didático foi elaborado pensando nestas questões, que de- senvolvendo programas para
verão ser refletidas por você, como um técnico em informática, respon- microcontroladores aplicados
sável por sistemas de banco, de hospitais, de pequenos supermercados e em equipamentos eletrônicos.
de grandes empresas. Neste livro você vai encontrar os diversos tipos e
técnicas para se testar um software de modo a garantir que ele funciona-
rá corretamente nos momentos mais difíceis. Também verá que certos
sistemas não precisam ser testados nos mínimos detalhes. Eles serão
testados apenas até o ponto onde os custos do teste não são maiores do
que a correção. Além de aprender que é mais barato testar no começo
do desenvolvimento do que corrigir no final.
O estudo e pesquisas realizadas para elaborar este material didático fo-
ram demorados e detalhados, mas valeu a pena, pois certamente você
encontrará ao longo da leitura deste livro respostas para muitas pergun-
tas como as que você leu no início desta apresentação e muitas outras
que surgirão ao longo de sua carreira profissional. Então, espero que
você consiga aproveitar o material para se desenvolver profissionalmen-
te e pessoalmente.
É importante considerar que sempre haverão coisas novas para aprender
e você pode pesquisar muito mais e aprender a partir dos livros e blogs
que foram utilizados para preparação deste material. Perceba que muita
gente está estudando, discutindo, e aprendendo e inovando sobre teste
de software todos os dias. Por fim, espero que, daqui a alguns anos, quan-
do você estiver trabalhando em uma grande empresa de desenvolvimen-
to e precisar elaborar um processo de teste, lembre-se desse material
e utilize,o como um ponto de partida para atingir o sucesso nos seus
trabalhos.

Bons estudos!

TESTES DE SOFTWARE 11
 Unidade de
estudo 1
Seções de estudo

Seção 1 – Metodologia de desenvolvimen-

to de software
Seção 2 – Objetivos do teste de software
Seção 3 – O que é teste de software?
Seção 4 – E se não testar o software?
Seção 5 – Casos de testes
Seção 6 – Tipos de testes
O que é teste de software?

Seção 1
Metodologia de desenvolvimento de software
Você sabia que utilizar uma metodologia para desenvolver um software é Processo de Garantia da Qualida-
o primeiro passo de uma prática profissional? de do Software:
É isso mesmo! Confira a seguir um formato básico de metodologia para
1. Planejamento da Qualidade.
elaboração de um software, de acordo com Bartié (2002, p. 25).
2. Garantia da Qualidade.

3. Controle da Qualidade.
Neste momento você deve estar
se perguntando: mas porque devo
testar um software? Qual o objeti-
vo deste teste? Não seria perda de
tempo, já que na maioria das ve-
zes o tempo de desenvolvimento
de um software é curto?
É sobre este assunto que conver-
saremos na próxima seção de es-
tudo. Vamos em frente!
Figura 1: Ciclo de desenvolvimento de software
Fonte: Bartié (2002, p. 25)
Seção 2
Perceba que o item teste é apenas uma parte da metodologia e aparece Objetivos do teste de
somente no final do projeto.
software
Por isso, o objetivo desta seção de estudo é mostrar à você que as De forma bem básica, o objetivo do
práticas de teste devem iniciar juntamente com o início do projeto, no teste de software é simplesmente
momento em que as primeiras documentações são geradas. Assim, garantir a qualidade do software.
os erros e problemas não são transferidos para as próximas fases, ok?
Para Bartié (2002) o processo de
qualidade de software está decom-
posto em fases e cada fase possui
Quando a cultura da aplicação da metodologia estiver bem entendida e uma numeração que indica a se-
difundida, você verá que os processos e métodos de teste permitirão a quência de execução dos testes a
qualidade dos produtos. Neste momento é importante fazer referência serem aplicados.
ao PMI (Project Management Institute) que fez o PMBOK (Project Manage- Assim, deve-se dividir os testes
ment Body of Knowledge), no qual o processo de gerenciamento da qualida- em duas categorias: testes de ve-
de de software é subdividido em três partes complementares, acompanhe! rificação e testes de validação.
Os testes de verificação visam
garantir a correta elaboração do
software e os testes de validação
estão focados na garantia da qua-
lidade do software.

TESTES DE SOFTWARE 13
Para que você possa verificar as
atividades e avaliar os documen-
tos gerados durante as fases do
processo de engenharia de softwa-
re, deve utilizar os testes de veri-
ficação.
As fases da metodologia que fa-
zem parte dos testes de verifica-
ção são:
▪▪ Modelo de Negócios: verifi-
cação de negócios;
▪▪ Especificação de Requisi-
tos: verificação de requisitos;
▪▪ Análise e Modelagem: verifi-
cação, análise e modelagem;
▪▪ Implementação: verificação
da implementação.
Desta forma, defini-se testes de
validação como:
[...] um processo formal de ava-
liação de produtos tecnológicos
que podem ser aplicados em
componentes isolados, módulos
existentes ou mesmo nos siste-
mas como um todo. Seu objeti-
vo é avaliar a conformidade do
software com os requisitos e
especificações analisadas e revi-
sadas nas etapas iniciais do pro-
jeto (BARTIÉ, 2002, p. 38).
Ou seja, os testes de validação são
aqueles feitos quando já existe
alguma parte do software pronta.
São os testes feitos no software e
não na documentação. Nos testes
de validação, temos as seguintes
fases:
▪▪ Unidade Especificada ou
Modificada: validação da uni-
dade;
▪▪ Integração Especificada
ou Modificada: validação da
integração;
▪▪ Sistema Especificado ou
Modificado: validação do siste-
ma;
14 CURSOS TÉCNICOS SENAI
▪▪ Disponibilização de Solu-
ção: validação do aceite.Lembre- ▪▪ Teste é um processo siste-
-se de que o conhecimento se mático e planejado que tem
adquire por meio de uma cons- por finalidade única a identi-
ficação de erros.
trução significativa da aprendiza-
gem. Então, vamos juntos trilhar
novos caminhos do conhecimen-
to? Esta é considerada a definição
correta sobre os testes. Inde-
pendentemente do teste ser apli-
Seção 3 cado a um documento ou a um
O que é teste de software, o objetivo é criar situa-
software? ções onde o produto pode não
funcionar.
Existem atualmente, duas defini-
ções para teste.
Você sabe quais são? Vamos ver
juntos.
A definição mais comum, que a
maioria das equipes de desenvol-
vimento aplica está simplificada
como:
▪▪ Teste é o processo de de-
monstrar que algo funciona
corretamente.
▪▪ Teste é o processo de pro-
var que determinadas coisas
fazem o que deveriam fazer.
Ou seja, todo mundo vê os tes-
tes como uma forma de mostrar
que está tudo bem. Na verdade, é
mais fácil mostrar que um software
está funcionando do que mostrar
que ele não está funcionando.
Mas, ao colocar uma pessoa que
não está envolvida no desenvolvi- Porém, é preciso sempre lembrar
mento do software e que não tem que você não conseguirá mostrar
nenhuma ligação com este, esta a ausência de erros. Ou seja, por
pessoa criará diversas situações, melhor que seja um processo de
possíveis no dia-a-dia do produto, qualidade, nunca será possível
e conseguirá demonstrar que em cobrir todas as infinitas combina-
determinados cenários, o com- ções existentes em um ambiente
portamento deste produto pode de execução real. Pense sempre
gerar um funcionamento inade- nisso!
quado. Vamos em frente? Na próxima
Neste ponto, é possível chegar à seção você verificar o que pode
segunda definição de teste: acontecer quando um software não
é testado.

Seção 4
E se não testar o
software?
Erros, falhas, incidentes, não con-
formidades e inconsistências são
palavras que representam nature-
zas diferentes de defeitos. Apesar
de ser um pensamento comum,
esses defeitos não vêm apenas
no código – fonte do produto. E
também não são apenas os pro-
fissionais de desenvolvimento,
qualidade e testes, os responsáveis
por um software sem defeitos.
▪▪ ampliam as chances de sucesso do projeto de software e,
▪▪ evitam a propagação de erros.
Interessante, não é mesmo? Bastos et al (2007) cita a regra 10 de Myers,
que estabelece que o custo de correção de um erro aumenta muito com
o passar do tempo.
DICA
Quanto mais tempo demorar para se descobrir um erro, mais caro
será a solução deste erro. Defeitos encontrados na documentação
de modelamento são muito mais baratos do que defeitos encontra-
dos durante a produção. Portanto fique atento!
Confira na imagem a seguir um gráfico que apresenta um aumento do
custo durante as fases do projeto.

Os erros são resultados do

não entendimento dos re-
quisitos do cliente e especi-
ficações mal feitas. Portan-
to, você deve trabalhar mais
tempo nas especificações e
modelagem da solução. Isso
fará com que muitos erros se-
jam eliminados por meio de
um levantamento bem feito.

A falta de testes em todas as etapas

do processo de desenvolvimento Figura 2: Custo da correção dos defeitos.
fará com que os erros passem de
uma fase para a outra. Quando
Finalizando esta seção, você pode ver que os testes são extremamente
o ciclo atingir a fase específica de
importantes no alcance da qualidade do software. Não testar ou fazer
testes, muitos erros serão encon-
testes da forma errada pode trazer custos extremamente altos para a
trados e mesmo assim o produto
empresa.
pode não atingir o esperado.
Você sabia que esse processo de
qualidade de software, do qual os DICA
testes fazem parte, traz diversas
E para alcançar a qualidade desejada pelo cliente, muitas vezes é
vantagens para a organização?
necessário possuir uma equipe de testes, trabalhando em conjunto
Sim, isso mesmo! Ealgumas des- com o desenvolvimento, desde a primeira reunião.
sas vantagens são:
▪▪ os testes tornam o ciclo de
desenvolvimento confiável; Apesar de gerar um custo inicial, após o treinamento e mudança de filo-
▪▪ garantem ações corretivas sofia da empresa, os ganhos serão muito maiores.
durante o desenvolvimento Que tal passar para a próxima seção e conhecer alguns casos de teste?
Siga em frente!

TESTES DE SOFTWARE 15
Seção 5
Casos de testes
De acordo com Bastos et al (2007,
p. 153) um caso de teste é a espe-
cificação mais detalhada do teste,
apresentando os campos de telas,
formulários etc. O caso de teste
estabelece as informações empre-
gadas nos testes dos cenários e
quais são os resultados esperados.
Ou seja, é necessário fazer um de-
talhamento do que será testado,
como será feito o teste, quem é
responsável, quais são as entradas
necessárias e quais são as saídas
esperadas.
Um bom caso de teste deve con-
ter:
▪▪ identificação das condições de
teste;
▪▪ o que testar (identificação dos
casos);
▪▪ detalhamento da massa de
entrada e de saída (dados);
▪▪ critérios especiais, quando
necessários, para gerar os dados
de entrada e saída do teste;
▪▪ especificação das configura-
ções de ambiente no qual o teste
será executado: sistema operacio-
nal, ferramentas necessárias, ori-
gem dos dados etc (onde testar);
▪▪ como testar: automático/ma-
nual (definir o tipo de implemen-
tação do teste);
▪▪ quando testar (cronograma,
em qual fase o teste será execu-
tado);
▪▪ listar as interdependências,
caso existam, entre os casos de
teste.
O quadro a seguir é um exemplo
de caso de teste aplicado a um sis-
tema de uma imobiliária. Veja!
16 CURSOS TÉCNICOS SENAI
Caso de teste Portal de Administração de Sites – Imóveis Carvalho
CT 85 – Buscar para alteração. Botão visualizar o
Caso de teste
calendário de locação.
Ter clicado em “Buscar para alteração” na página
Pré-condições de imóveis e estar com a opção de locação para a
temporada.
1. O ator clica em “Visualizar o calendário de
locação do imóvel”representado pelo terceiro
ícone da esquerda para a direita na parte
Procedimentos superior da descrição do imóvel.
2. O sistema carrega um calendário destacando
os dias de locação do imóvel.
Resultado
Carregar o calendário de locação do imóvel.
esperado
Critérios
Não se aplica.
especiais
Implementação Manual.
Iteração 1ª iteração.
Quadro 1: Exemplo de caso de teste
Neste exemplo você pode ver que os casos de teste são bem detalhados
e devem ser descritos de uma forma criteriosa. Todos os cenários e
casos de uso devem ser criados, verificando todas as funcionalidades do
software. Por isso eles dão bastante trabalho para a pessoa responsável
pela sua elaboração.
Preparado para seguir mais um percurso? Conheça na próxima seção os
tipos de teste.
Seção 6
Tipos de testes
No momento em que você começar a fazer os testes de validação, signi-
fica que já tem um produto computacional, ou seja, um software que pode
ser executado.
Para fazer esta validação você pode utilizar duas abordagens:
▪▪ a estratégia da caixa branca ou,
▪▪ a estratégia da caixa preta.
Figura 3: Estratégias fundamentais dos testes.
Estas estratégias não excluem uma a outra. Na verdade, se você aplicar
as duas, terá um produto com uma qualidade maior. Os testes de caixa
branca são baseados na estrutura interna do software. Ou seja, é preciso
empregar técnicas que trabalhem todas as estruturas utilizadas na codi-
ficação.
Os testes de caixa branca possuem alta eficiência na detecção de erros,
mas também costumam ser difíceis de implementar.

Para isso é necessário que o profissional de testes conheça a tecnolo-

gia usada no software. Assim como, tenha acesso a fontes, estruturas
dos bancos de dados etc.

Confira a seguir a imagem que representa um teste de caixa branca.

Figura 4: Teste de caixa branca.

Você pôde observar na imagem anterior que o teste de caixa branca

mostra um software que tem um processamento inicial, representado pelo
retângulo 1, uma tomada de decisão, representada pelo losango 2. A
partir desta decisão, o software pode passar por dois caminhos, o caminho
A ou o caminho B.
Importante: o software nunca vai passar pelos dois caminhos ao mesmo
tempo.
Independente do caminho percorrido, o software chega ao processamen-
to final, retângulo 3. Após este processamento, o software é finalizado.

Perceba que para fazer este teste, é importante que o profissional

conheça o que cada processamento faz e que resultado cada tomada
de decisão deverá dar.

Neste momento você deve estar se perguntando: mas e a caixa preta,

qual a sua função?

TESTES DE SOFTWARE 17
 O teste de caixa preta não tem o objetivo de verificar como ocorrem
internamente os processamentos, mas se o algoritmo utilizado produz
os resultados necessários. A vantagem desta estratégia é que não é ne-
cessário conhecer os conceitos de implementação aplicados no software.
Dessa forma é muito mais fácil encontrar um profissional capacitado a
modelar os testes de caixa preta da aplicação.
Veja a seguir a imagem que representa um teste de caixa preta.

Figura 5: Teste de caixa preta.

Esta estratégia é muito encontrada nas organizações, em forma de testes
manuais executados por profissionais ou usuários.
Ao estudar os testes de software, é possível perceber que existem diversos
tipos de teste que devem ser feitos nos softwares. Muitas vezes, você não
terá tempo para fazer todos os testes e criar todos os cenários. Assim,
é importante conhecer os tipos e priorizar aqueles que podem encontrar
erros mais preocupantes.
Bartié (2002) cita alguns testes que devem ser feitos:

1. Teste de funcionalidade: tem por objetivo simular os cenários de

negócio e garantir que todos os requisitos funcionais sejam imple-
mentados.

2. Teste de usabilidade: a ideia desse teste é medir o nível de facilida-

de da aplicação, de modo a deixar o software mais simples e intuitivo.
Também é possível avaliar se o software avisa sobre ações que podem
danificar ou perder dados pertencentes ao usuário.
Por exemplo, botão “desfazer alteração” e “cancelar operação”, além da
mensagem “Esta operação excluirá seu histórico. Deseja continuar?”

3. Teste de volume: tem por objetivo determinar os limites de proces-

samento do software e de toda a infra-estrutura da solução. Esse tipo
não focaliza oscilações, mas o aumento contínuo dos parâmetros de
execução.

18 CURSOS TÉCNICOS SENAI

4. Teste de configuração (ambiente): o objetivo desta categoria é
executar o software sobre diversas configurações de softwares e hardwa-
res. Desta forma, é preciso garantir que a solução “rode” sobre os
mais diversos ambientes. Para aplicá-los deve-se variar os sistemas
operacionais, browsers e hardwares.

5. Teste de compatibilidade: a ideia é garantir que as novas versões

estão suportando antigas interfaces, submetendo a aplicação trocar
informações com componentes que utilizam os protocolos de ver-
sões anteriores.

6. Teste de segurança: esta categoria de teste tem por objetivo detec-

tar falhas de segurança que podem comprometer o sigilo das infor-
mações. Sendo assim, é importante que você simule situações que
provocam a quebra de protocolos de segurança, expondo os pontos
frágeis.

7. Teste de performance (desempenho): nesta categoria você deve

determinar se o desempenho do software está de acordo com os requi-
sitos definidos, nas situações de pico máximo de acesso. Para estes
testes deve-se especificar claramente o cenário que você deseja obter.
Omitir informações significa a criação de um cenário irreal, que im-
possibilita a avaliação do desempenho.

8. Teste de confiabilidade e disponibilidade: nessa categoria, deve-se

monitorar o software por um determinado tempo e coletar informa-
ções para identificar se ocorrem falhas na infra-estrutura (confiabili-
dade), e quanto tempo é necessário para a resolução desse problema
(disponibilidade).

A próxima unidade vem cheia de novidades. Veja o que preparamos para

você.

TESTES DE SOFTWARE 19
 Unidade de
estudo 2
Seções de estudo

Seção 1 – O que é técnica de teste?

Seção 2 – Técnicas funcional, estrutural e
baseada em erros.
Seção 3 – Critérios para geração de casos
de teste.
Seção 4 – Níveis de teste.
Técnicas de teste de software
Seção 1
O que é técnica de
teste?
De acordo com Bastos et al (2007,
p. 86) a técnica de teste é um pro-
cesso que assegura o funciona-
mento adequado de alguns aspec-
tos do sistema ou da unidade.
Já as ferramentas de teste são re-
cursos para o testador. Utilizar
apenas a ferramenta, sem a técni-
ca adequada, não é suficiente para
conduzir todo o teste.
DICA
Por exemplo, um serrote é
apenas uma ferramenta, que
se não for usada com a técni-
ca adequada, pode não cor-
tar a madeira e sim a pessoa.
Enfim, são poucas as técnicas e
muitas as ferramentas existentes.
Na próxima seção você verá as
principais técnicas de teste. Va-
mos em frente!
Seção 2
Técnicas funcional,
estrutural e baseada em
erros
Os testes funcionais são aqueles
que verificam o funcionamento
do software e se ele atende os re-
quisitos. Ou seja, se o código faz
aquilo que foi pedido pelo cliente
e que está na documentação. Nor-
malmente é necessária a criação
de condições de teste que serão
usadas na avaliação da correção
da aplicação.
Já os testes estruturais verificam
se o software possui uma estrutura
robusta, ou seja, se ele se mantém
funcionando quando ocorrem
condições adversas. Nesses tipos
de teste, não há preocupação com
o atendimento aos requisitos e
sim se a tecnologia foi usada de
modo adequado e se os com-
ponentes montados funcionam
como uma unidade.
Quando você usa uma técnica de
teste baseada em erros, deverá in-
serir erros no software e verificar o
seu funcionamento. Na verdade,
esta é uma variação da técnica fun-
cional, pois ele testa os requisitos.
Mas serve para encontrar aqueles
defeitos que já são esperados.
Agora que você já conheça algu-
mas técnicas de teste, veja os cri-
térios utilizados para geração de
casos de teste!
Seção 3
Critérios para geração
de casos de teste
Para que você possa garantir certa
qualidade no software é necessário
que teste certa quantidade de pos-
sibilidades, ou cenários.
Quanto maior a quantidade
de cenários testados, maior
a qualidade do produto. Lem-
bre-se que não será possível
chegar ao software perfeito,
sem defeitos. Portanto, você
deve determinar quais serão
os cenários necessários para
atingir a qualidade desejada,
ok?
A ênfase dos testes de validação
está nos métodos que identificam
todos os possíveis cenários de
testes, chamados casos de testes.
Como você possuí duas técnicas
para lidar com os testes de software
(testes estruturais e funcionais), a
obtenção dos casos de teste estará
associada a uma dessas técnicas.
Para Bartié (2002, p. 122),
TESTES DE SOFTWARE 21
 “Um dos maiores desafios de um processo de garantia da qualidade é
conseguir medir o grau de qualidade alcançado nos testes de software.
Se em nosso entendimento os cenários estiverem adequadamente simu-
lados e garantidos, então devemos buscar todas as alternativas possíveis
e inseri – las em nosso processo de teste de software, de forma a refinar
e ampliar o nível de cobertura alcançado.”

Assim, os casos de teste se tornam extremamente importantes no pro-

cesso de teste de um software e, consequentemente, no processo de ga-
rantia da qualidade.
A imagem a seguir considerou o método da caixa preta para a obtenção
dos casos de testes, confira!

Figura 6: Método da caixa preta para geração dos casos de teste.

Se você utilizar o método da caixa preta para gerar os casos de teste,

irá criar testes funcionais. Ou seja, testará cada requisito que aparece na
documentação inicial do software.
Assim, você cria um caso de teste para o requisito A (Caso A1). Aplica
este caso ao software e verifica se o resultado apresentado pelo software
atende aquele requisito. Depois, você criará o próximo caso (Caso A2) e
assim por diante. Até que todos os casos de todos os requisitos tenham
sido testados.
Desta forma, quando você for fazer testes estruturais, deverá utilizar o
método da caixa branca para gerar os casos de teste.
Lembre-se que os testes estruturais verificam o código do software e devem
percorrer todos os caminhos possíveis, passando por cada parte do proces-
samento e das tomadas de decisão.

22 CURSOS TÉCNICOS SENAI

Figura 7: Obtenção dos casos teste através do método da caixa branca.

De acordo com a fig. 7, você pode ver que o software em questão tem 2
caminhos possíveis para chegar ao fim do processamento: ABCDEF ou
AGHF. Seguindo o método da caixa branca, você deve criar casos de
teste que obriguem o software a percorrer os dois caminhos.
Vendo estas duas abordagens, caixa preta e caixa branca, você pode pen-
sar “Mas, qual das duas eu devo utilizar?”
Na verdade, em uma aplicação real, as duas abordagens devem ser uti-
lizadas de modo a gerar os casos de testes necessários ao processo de
teste.

Mas, lembre-se sempre: cmo você viu anteriormente, não será

possível eliminar todos os defeitos. Também não é economica-
mente viável que se faça todos os testes possíveis e imagináveis no
software.

É importante que o profissional de testes avalie quais são os testes ne-

cessários para validar determinado produto.

DICA
Por exemplo: um software de um banco é testado de forma diferente
de um software para fazer pedido de pizza na internet, portanto
devem possuir testes específicos para cada um deles.

As bibliografias especializadas apresentam diversos tipos de testes que

estão dentro das técnicas estruturais (teste de carga, de execução, de
recuperação, de conformidade etc) e das técnicas funcionais (teste de
requisitos, de regressão, de interconexão, de controle etc).

TESTES DE SOFTWARE 23
 Bartié (2002, p. 112) recomenda que os testes de cada software sejam
organizados em categorias e que em uma reunião com a equipe, cada
categoria receba um peso relativo a sua prioridade. Normalmente, todos
querem colocar alta prioridade para a sua área. Então deve ser definido
que apenas 3 categorias poderão ter alta prioridade. Assim, todos devem
entrar em acordo para determinar quais são as categorias mais importan-
tes para testar determinado produto.
E por falar em peso, prioridade, que tal conhecer os níveis de teste? É
sobre este assunto que conversaremos a seguir, vamos lá!

Seção 4
Níveis de teste
Como você estudou no início deste livro, de forma geral existem duas
fases no processo de qualidade dos softwares. A fase de verificação (tes-
tes estáticos - documentação) e a fase de validação (testes dinâmicos
- software).
Dentro da fase de verificação, você pode encontrar algumas das ativida-
des que estão descritas no quadro a seguir, acompanhe!

Fase de
Principais Atividades
Verificação

▪▪ Revisar contexto do mercado e necessidade do

Modelo de cliente.
negócios ▪▪ Revisar riscos do projeto.
▪▪ Revisar estudo de viabilidade.
▪▪ Revisar especificação de requisitos funcionais e
Especificação de não – funcionais.
requisitos ▪▪ Auditar rastreabilidade de requisitos.
▪▪ Revisar priorização de requisitos.

▪▪ Revisar arquitetura da aplicação.

▪▪ Revisar nível de componentização. Saiba mais so-
bre componentização de software no artigo escrito
Análise e
pelo professor Antonio Mendes da Silva filho, dis-
modelagem
ponível em: <http://www.espacoacademico.com.
br/087/87amsf.htm>
▪▪ Revisar nível de reutilização.

▪▪ Revisar código fonte.

▪▪ Avaliar complexidade do código fonte.
Implementação
▪▪ Auditar rastreabilidade entre componentes.
▪▪ Revisar manual do usuário.

Quadro 2: Fases dos testes de verificação

24 CURSOS TÉCNICOS SENAI

Quando você chegar à fase de validação, encontrará 2 níveis de teste:
baixo e alto nível. Os testes de baixo nível exigem um profissional com
bastante conhecimento da estrutura do produto. Já os testes de alto ní-
vel não exigem conhecimento da estrutura interna e possibilitam testes
com maior nível de abstração.
No quadro a seguir você pode ver algumas características destes testes,
confira!

Fase da Validação Características

▪▪ Estratégia caixa branca e caixa preta.

▪▪ Testa partes do software.
Teste de unidade
Teste de baixo nível

▪▪ Executada pelo desenvolvedor ou profis-

sional de teste.
▪▪ Estratégia caixa branca e caixa preta.
▪▪ Teste integrações entre as partes do sof-
Teste de integração tware.
▪▪ Executada pelo desenvolvedor ou profis-
sional de teste.

▪▪ Estratégia de caixa preta.

▪▪ São aplicados no software como um
todo.
Teste de sistema ▪▪ Requer ambiente semelhante ao da pro-
dução.
Teste de alto nível

▪▪ Executado por um grupo de testes inde-

pendente.

▪▪ Estratégia de caixa preta.

▪▪ São aplicados no software como um
todo.
Teste de aceitação
▪▪ Requer ambiente semelhante ao da pro-
dução.
▪▪ Executado pelos usuários finais.
Quadro 3: Características do testes de validação

Uma nova unidade lhe convida a explorar novos conceitos. Vamos lá?

TESTES DE SOFTWARE 25
 Unidade de
estudo 3
Seções de estudo

Seção 1 - Ciclo de vida de desenvolvimen-

to de software
Seção 2 – Conceito “V” de teste
Seção 3 – Ciclo de vida do processo de
teste
Seção 4 – Preparação do ambiente
Processo de teste de software
Seção 1
Ciclo de vida de desen-
volvimento de software
(CVDS)
De forma geral, os ciclos de vida
de desenvolvimento de software
(CVDS) são bastante diferentes,
pois em todos haverá atividades
específicas dos testes aplicados. A
seguir você verá um ciclo de vida
básico que demonstrará as princi-
pais atividades que acontecem du-
rante o desenvolvimento de um
software. Acompanhe!
Segundo Bastos et al (2007, p. 33)
as seguintes fases fazem parte de
um CVDS.
▪▪ Fase 1 – Estudo preliminar:
Essa fase começa com o reco-
nhecimento de um problema ou
identificação de uma necessida-
de. Durante essa fase o projeto
é justificado e aprovado no alto
nível da organização. As alterna-
tivas de solução são exploradas e
seleciona-se a solução mais viável
e que atenda melhor às necessida-
des identificadas. Muitas vezes,
realiza-se um estudo de custo-
-benefício para apoiar o processo
de decisão.
▪▪ Fase 2 – Análise de requi-
sitos:
Agora, os requisitos são definidos,
coletados, validados e aprovados.
Também nesta fase são levantadas
as informações necessárias para
realização dos testes.
Os requisitos geralmente são
modificados nas fases seguintes,
quando se adquire um melhor en-
tendimento do problema.
Ainda nesta fase é preparado o
Plano de Projeto, que inclui cro-
nograma, recursos, orçamento,
produtos intermediários, ativida-
des de gestão, análise de riscos e
os planos previstos no modelo do
Project Management Institute (PMI).
Deve-se incluir o plano de testes,
com os recursos e prazo para rea-
lizar as atividades de teste.
Este plano do projeto não é fixo
e deve ser atualizado sempre que
certos eventos ocorram, como
uma mudança no escopo do pro-
jeto.
▪▪ Fase 3 – Desenho do siste-
ma:
As atividades desta fase resultam
no detalhamento da solução para
os aspectos que compõem um
sistema: funcionalidade, dados e
técnica. O Plano de Projeto deve
ser revisto para refletir as novas
informações.
▪▪ Fase 4 – Construção:
Nesta fase os modelos devem
ser transformados em realidade e
suas atividades resultam em pro-
gramas prontos e testados. Nes-
ses programas devem ser aplica-
dos os testes unitários conforme
os planos de teste e os casos de
teste preparados.
Os manuais de treinamento, de
manutenção e do usuário também
são preparados nesta fase, além
do Plano de Instalação.
▪▪ Fase 5 – Implantação:
Agora é o momento de efetuar os
testes de integração e de sistema.
O sistema tem de receber certi-
ficação quanto a sua adequação
aos requisitos de segurança antes
da instalação. E antes de ser cer-
tificado, todos os resultados das
verificações e validações devem
ser documentados e comparados
com o antes e o depois. Por fim,
o sistema deve ser aceito pelo
usuário.
▪▪ Fase 6 – Operação:
Nesta fase o Modelo de Operação
do sistema deve ser implemen-
tado, incluindo a expansão para
a instalação em outros locais. O
sistema deve iniciar a operação
continuada e todas as mudanças
devem ser controladas de forma a
manter e modificar o ciclo de vida
durante o restante de sua vida.
Relatórios dos problemas e soli-
citações de mudanças são usados
para facilitar a correção de forma
sistemática e a evolução do siste-
ma.
Também devem ser executadas
medições de desempenho e ava-
liação das atividades para garantir
que o sistema continuará atenden-
do a seus requisitos.
TESTES DE SOFTWARE 27
 Você já ouviu falar sobre o conceito “V” de teste? Caso ainda não tenha
tido a oportunidade de conhecer este conceito, não se preocupe, pois na
próxima seção você verá uma figura que ilustra exatamente o que seria o
chamado conceito “V” de teste. Vamos!

Seção 2
Conceito “V” de teste
Observe na imagem a seguir que os procedimentos de fazer e conferir
convergem do início ao fim do projeto. Ou seja, os testes devem fazer
parte de todo o processo de desenvolvimento.

Figura 8: Conceito “V” de teste de software.

DICA
Lembre-se: testar o produto durante todo o desenvolvimento dimi-
nui o custo da correção dos defeitos.

Na próxima seção você conhecerá o ciclo de vida do processo de teste.

Siga em frente!

Seção 3
Ciclo de vida do processo de teste
De acordo com Rios (2003, p. 29) o ciclo de vida do processo de teste
é composto por diversas etapas e é conhecido como Modelo 3Px3E.
Confira na imagem a seguir um modelo de ciclo de vida do processo de
teste.

28 CURSOS TÉCNICOS SENAI

 Script: está relacionado
à programas executados
dentro de outros programas de
forma a estender a funcionali-
dade deste programa ou con-
trolá-lo.

Figura 9: Modelo de ciclo de vida do processo de teste.

Conheça agora cada uma das etapas do modelo.

Na etapa de procedimentos iniciais, os requisitos do negócio serão
aprofundados.Isso garantirá que o sistema de informação a ser desen-
volvido esteja completo. Claro que esta abordagem deve ser restrita ao
projeto de teste.
No planejamento serão elaborados a estratégia de teste e o plano de
teste, os quais serão utilizados posteriormente.

DICA
Você estudará sobre a estratégia e o plano de teste mais para frente.

O ambiente de teste será organizado na etapa de preparação, de forma

que os testes sejam executados corretamente. Esta etapa corre em pa-
ralelo com as outras.
O objetivo básico da etapa de especificação é elaborar/revisar os casos
de teste e os roteiros de teste.
Na fase de execução os testes deverão ser executados de acordo com os
casos de testes e roteiros de teste. Devem ser usados scripts de teste,
caso alguma ferramenta de automação seja empregada.
Na etapa de entrega oprojeto de teste é finalizado. Toda a documenta-
ção será concluída e arquivada e todas as ocorrências importantes deve-
rão ser relatadas.

Agora que você já conhece o ciclo de vida do processo de teste, que

tal conhecer mais detalhadamente um ambiente de teste? Então, vamos
juntos!

Seção 4
Ambiente de Teste
Nesta seção você estudará sobre ambiente de teste, o qual é preparado
em uma das etapas do ciclo de vida do processo de teste.

TESTES DE SOFTWARE 29
 O ambiente de teste é a estrutura onde o teste será executado.
Para este ambiente é preciso considerar a criação da massa de dados de
teste, o modelo de dados e a configuração dos softwares usados.
É importante que você não confunda o ambiente com a configuração do
hardware, ok?
Veja na lista a seguir alguns itens que fazem parte de um ambiente de
teste:

1. Pessoal: usuários, desenvolvedores, testadores.

2. Hardware: plataforma, impressora, scanners.

3. Software: software a ser testado, sistema operacional, software de teste,

procedimentos de teste.

4. Suprimentos: papel, formulários.

5. Interface: interna, externa.

6. Rede: protocolos, conexões, gateways.

7. Ambiente físico: local, segurança, estrutura.

8. Documentação: requisitos, design, usuários.

Para preparar um ambiente de teste você pode usar o seguinte fluxogra-

ma:

30 CURSOS TÉCNICOS SENAI

Figura 10: Fluxograma de teste.

Perceba que a figura apresentada anteriormente é um ciclo, ou seja, deve

ser aplicada continuamente até que os testes estejam concluídos.
Mas, como toda ação geralmente possui um risco, a ação de testar um sof-
tware não poderia ser diferente, não é mesmo? Por isso, na próxima uni-
dade você estudará sobre a análise destes riscos, desde sua definição até
como controlá-los. Gostou deste novo assunto? Então, siga em frente!

TESTES DE SOFTWARE 31
 Unidade de
estudo 4
Seções de estudo

Seção 1 – Definição de risco

Seção 2 – Riscos relativos ao teste de
software
Seção 3 – Determinação da magnitude
dos riscos
Seção 4 – Controle dos riscos
Análise de risco
Seção 1
Definição de risco
Você sabe o que significa a pala-
vra risco?
Segundo o dicionário da língua
portuguesa Michaelis, risco é a
possibilidade de perigo, incerto,
mas previsível, que ameaça de
dano a pessoa ou a coisa.
Quando falamos de software, es-
tamos procurando aqueles fatos
cujas ocorrências poderão acarre-
tar perdas para a empresa. No
entanto, um risco presente nem
sempre vai gerar uma perda.
Se uma empresa faz todo o seu
negócio na internet, por exem-
plo, venda de produtos, existe um
grande risco de perda de dinheiro,
se os computadores pararem de
funcionar. Mas se você pensar no
mercadinho da esquina, não existe
nenhum problema se o computa-
dor do caixa parar.
Mas, o que isso tem haver com o
teste de software? Encontre a res-
posta para este questionamento
na próxima seção.
Seção 2
Riscos relativos ao teste de software
A atividade de testar o software está bastante ligada ao risco. Você já
estudou como o custo dos testes influencia no desenvolvimento de um
software. Também já viu que os defeitos encontrados tardiamente aumen-
tam bastante o custo da correção.
Por isso, as equipes de teste devem procurar um nível de cobertura que
minimize a possibilidade de defeitos graves, principalmente por causa da
existência de prazos. Ou seja, apesar de existirem riscos relativos a de-
terminados defeitos, é necessário um tempo maior de teste com aqueles
que podem gerar os maiores problemas.
DICA
Ao fazer a análise de riscos, leve em consideração a probabilidade
de ocorrência do risco e o impacto e perda associados a esse risco.
Neste momento possivelmente você esteja se perguntando: mas, como
analisar e avaliar os riscos que possam surgir? É sobre isso que conver-
samos a seguir.
Seção 3
Determinação da magnitude dos riscos
Você precisa lembrar que, quando se trata de riscos, é necessário avaliar
o custo da ocorrência do risco e o custo dos mecanismos de controle
para evitar que o risco ocorra.
Para fazer uma análise preliminar da qualificação do risco você pode usar
a tabela a seguir. Confira!
TESTES DE SOFTWARE 33
 Probabilidade de ocorrência
Impacto que o risco causa
Alta Média Baixa
Alto AA AM AB
Médio MA MM MB
Baixo BA BM BB
Quadro 4: Qualificação dos riscos (probabilidade x impacto).

Considerando o quadro apresentado anteriormente , perceba que você

deve dar prioridade àquele teste que vai causar o maior problema e que
pode ocorrer com mais facilidade (AA).
E como controlar os riscos? Confira a seguir.

Seção 4
Controle dos riscos
Considere uma loja que vende livros, CD’s e DVD’s pela internet e que
mantém uma base de dados num ambiente de grande porte (legado).
Você pode encontrar alguns riscos associados a operação dessa loja.
Imagine os seguintes riscos:
▪▪ Facilidade de uso do site, pois se a navegação não for bastante ami-
gável, pode ser que o cliente desista de comprar.
▪▪ Tempo de resposta muito longo para as páginas abrirem, também
pode fazer com que o cliente desista.
▪▪ A conectividade tem que ser confiável, para que o sistema não caia e
interrompa o processo de compra.

O primeiro risco pode ser controlado fazendo um teste de usabilidade

bem rigoroso. Uma das possibilidades é criar um protótipo para ser
avaliado por um público externo. O sistema só será liberado quando um
grupo de usuários concordar que o sistema está amigável.
Para contornar o segundo risco é preciso submeter o sistema a um teste
de carga e comparar os tempos de resposta com os requisitos do negó-
cio. Por exemplo, os requisitos poderiam ser:

34 CURSOS TÉCNICOS SENAI

 Deve ser prevista uma média de 6 mil acessos por dia, com pico de 8
mil. O tempo de resposta não deve ser superior a 4 segundos e, no
pico, a 8 segundos.

No controle desse risco é necessário utilizar uma ferramenta de auto-

mação que faça o teste de carga, adicionando novos usuários pouco a
pouco até que o sistema comece a se degradar, ou seja, apresentar um
tempo de resposta maior do que o requisitado.
Com este exemplo pode-se perceber que é preciso relacionar todos os
possíveis riscos que podem ocorrer com a implantação do software e
posteriormente analisar cada um deles buscando uma resposta ou até
mesmo solução prévia para que o risco não se torne realmente um “pro-
blema”. Então fique atento também aos riscos durante o processo de
teste do software, ok?
Na próxima unidade você estudará sobre como fazer um plano de teste.
Vamos em frente!

TESTES DE SOFTWARE 35
 Unidade de
estudo 5
Seções de estudo

Seção 1 – Plano de teste, o que é?

Seção 2 – Desenvolvimento do plano de
tese
Seção 3 – Documentação do teste
Planejamento dos testes
Seção 1
Plano de teste, o que é?
Se você trata os testes como um
processo contínuo, que faz parte
do desenvolvimento do software,
torna-se necessário fazer um pla-
no para estes testes, não é mesmo?
Da mesma forma que qualquer
coisa que é executada em um am-
biente industrial, é extremamente
importante que haja um planeja-
mento dos testes.
Imagine que você vai viajar de
avião. Você sabe que o software
de controle do avião foi testado.
Mas e se não foi feito um plane-
jamento e alguém se esqueceu de
testar alguma coisa?
Segundo Bastos et al (2007, p.
113) o plano de teste é uma ma-
neira de documentar o projeto de
testes e desse modo, permitir que
os mesmos testes possam ser re-
petidos e controlados. Quando,
posteriormente, o software passar
por algum tipo de manutenção e
precisar voltar para ser testado,
esse documento será um ótimo
guia para orientar a repetição ou
servir de base para executar os
testes de regressão.
Confira a seguir as etapas que fa-
zem parte de um plano de teste.
▪▪ Repetibilidade: uma coisa que torna qualquer sistema confiável
é a repetibilidade, ou seja, se você executar o sistema com as mesmas
entradas ele deverá apresentar as mesmas saídas. O plano de testes
permite a repetibilidade da aplicação dos testes.
▪▪ Controle: como você saberá se os objetivos do teste foram atingi-
dos ou se todos os elementos críticos foram testados? A única forma
de fazer controle sobre os testes é possuir um plano que determine
quais são os passos a serem seguidos na hora de testar.
▪▪ Cobertura: o plano de teste também determinará o nível de cober-
tura dos testes. Essa cobertura deve atingir os elementos mais críticos,
seja pelo risco que representa para o negócio, seja por sua importância
para o projeto.
Em resumo, o plano de testes é extremamente importante para o pro-
cesso de teste. Ele estabelece o que vai ser testado, durante quanto
tempo e quando os testes serão interrompidos.
O plano de teste descreve como o teste deverá ser executado e traça uma
linha mestra a ser seguida.
Confira na seção seguinte como desenvolver um plano de teste. Siga
adiante!
Seção 2
Desenvolvimento do plano de teste
Para que você possa desenvolver um plano de teste existe um padrão
que é mundialmente aceito. Este padrão foi definido pelo Institute of
Electrical and Electronics Engineeres (IEEE). Nele está a lista com o conte-
údo do plano de teste.
O Quality Assurance Institute (QAI) segue basicamente este mesmo pa-
drão, apenas com algumas características próprias.
TESTES DE SOFTWARE 37

Para relembrar significa: PM-
BOK (Project Management
Body of Knowledge).
Para lembrar significa: PMI =
Project Management Institu-
te, criadores do PMBOK.
38 CURSOS TÉCNICOS SENAI
Além desses dois formatos de
plano, existe o Plano Global do
Projeto, definido pelo PMBOK,
que foi citado na primeira unidade
de estudos deste livro.
Este último trata o teste como um
projeto, por isso você irá estudálo
com mais detalhes a seguir.
Os itens do PMBOK são os se-
guintes:
▪▪ Escopo: o escopo define
exatamente a extensão do projeto
de teste, até suas interfaces com
outros softwares, componentes,
elementos de rede ou demais ele-
mentos. Deve definir o que será e
o que não será coberto pelo teste.
▪▪ Custo: para saber quanto
o projeto de teste vai custar é
preciso medir o seu tamanho,ou
seja, é preciso fazer a métrica de
teste. É possível adaptar algumas
métricas existentes, como análise
de pontos de caso de teste. Mas
normalmente isso leva tempo e a
métrica deve ser ajustada gradati-
vamente.
▪▪ Tempo: a elaboração do cro-
nograma está ligada ao tamanho
do projeto, que servirá de base
para o cálculo dos custos. Você
pode imaginar, por exemplo, um
projeto com 180 pontos de teste.
Por meio de indicadores da em-
presa é possível transformar este
número de pontos em horas (por
exemplo, 220 horas). Depois,
transformar horas em custo é
simples. Como tempo é dinheiro,
você deve também estabelecer
o momento de encerramento
dos testes. Ficar testando uma
aplicação por muito tempo pode
aumentar demais o custo do
projeto.
▪▪ Qualidade: você sempre
deve lembrar que o produto a ser
entregue deve estar de acordo
com as necessidades de qualidade
estabelecidas pelo cliente. Então,
a medição da qualidade tem que
ser acompanhada por um progra-
ma de indicadores, implementado
no decorrer do projeto.
▪▪ Integração: a principal inte-
gração do projeto de teste é com
o processo de desenvolvimento.
Além disso, como normalmente
o projeto de teste é segmentado
em etapas, por isso é preciso
manter a integração entre elas.
▪▪ Recursos humanos: a quanti-
dade de homens/hora imaginada
para o projeto é estabelecida após
a estimativa de seu tamanho.
Porém, é necessário definir os re-
cursos envolvidos em cada etapa
do projeto.
▪▪ Comunicação: a função dessa
etapa é garantir a maneira como
as partes envolvidas no projeto
receberão as informações de que
precisam para tomar decisões.
Todo material produzido deverá
estar disponível para consulta de
maneira clara em algum ambiente
criado pelo projeto. As regras
de gerenciamento de projetos
determinadas pelo PMI definem
a necessidade de um gerencia-
mento de comunicação para dar
suporte aos projetos.
▪▪ Riscos: o projeto de teste
implica seus riscos específicos,
como o uso de uma nova ferra-
menta de automação para a qual
os testadores ainda não tenham
sido treinados. Se você é o líder
do projeto de teste, tome cuidado
para não confundir os riscos do
projeto de teste com os riscos do
negócio.
▪▪ Suprimentos: é importante ▪▪ Especificação de caso de teste: define os casos de teste, com
que as necessidades de compra todas as características que você estudou nas seções anteriores.
de bens ou serviços sejam aten- ▪▪ Especificação do procedimento de teste: identifica todos os
didas no momento certo. Talvez passos necessários para a operação do sistema e o exercício dos casos
algumas ferramentas precisem ser de teste especificados. Os procedimentos de teste devem ser seguidos
compradas ou um ambiente de passo a passo, sem imprevistos. Esta especificação forma um docu-
teste tenha de ser configurado. mento separado.
▪▪ Conclusão: independen-
temente de qual modelo você
seguirá na elaboração do plano
de teste, o importante é que este
planejamento seja feito com
cuidado e precisão.

Você sabe quais são os documen-

tos necessários às atividades de
um projeto de software? É sobre
este assunto que você estudará na
sequência. Siga em frente!

Seção 3
Documentação do teste
Segundo Bastos et al (2007, p.
150), em torno de 50% a 60% do
tempo do analista de teste é gas- Figura 11: Documentação IEEE 829.
to na documentação do teste. A
norma IEEE 829 descreve um Na próxima unidade você verá como deve ser executado o teste de um
conjunto de documentos neces- software. Como já mencionado nas unidades anteriores todos os testes
sários às atividades de um projeto devem ser executados buscando a qualidade do software. Mas, muitas ve-
de software. Veja! zes, os requisitos dos softwares não exigem essas características. E como
teste custa dinheiro, será preciso conversar com os usuários sobre a ne-
▪▪ Plano de teste: identifica os cessidade de alguns tipos de teste.
itens e as funcionalidades a serem
testadas, os riscos associados ao
teste, as tarefas a serem realizadas Ficou curioso(a) para saber mais sobre o assunto? Vamos lá, siga em
e apresenta o planejamento para frente nos estudos!
a execução do teste.
▪▪ Especificação de projeto de
teste: trata-se de um detalhamen-
to da abordagem apresentada no
plano de teste que identifica as
funcionalidades e as característi-
cas a serem testadas pelo projeto.
Este documento também aponta
os casos e os procedimentos de
teste e apresenta os critérios de
aprovação.

TESTES DE SOFTWARE 39
 Unidade de
estudo 6
Seções de estudo

Seção 1 – Contexto dos testes

Seção 2 – Processo de execução dos testes
Seção 3 – Relatório de teste segunda a
IEEE 829
Seção 4 – Gerenciamento de comunicação
do projeto de teste
Execução dos testes

Seção 1
Contexto dos testes
De acordo com Bastos (2007, p. 169 apud CEM KANER, 1999), teste
estático e teste dinâmico são definidos da seguinte forma:
▪▪ No teste estático, o código é examinado.
▪▪ No teste dinâmico, o código é testado.
Para que os testes possam ser executados é necessário que exista o Plano
de Teste.

É muito importante que o plano de testes esteja atualizado e bem

detalhado, pois isso facilitará o trabalho dos testadores na hora de
elaborar os casos de teste e de executar os testes.

A responsabilidade de cada pessoa durante a execução dos testes deve

estar no plano de teste. No quadro a seguir você pode verificar o que
cada agente da equipe de teste deve fazer. Confira!

Responsáveis pelos testes

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
Quadro 5: Responsabilidade de cada pessoa da equipe de teste.

Você deve analisar os resultados dos testes a cada etapa de teste executa-
da. Todo s os registros da execução dos testes devem ser guardados sob
ferramentas de gestão dos testes. Desse modo, o gestor de teste poderá
saber o que ainda precisa ser corrigido pela equipe desenvolvimento, o
que está em processo de teste e o que já foi dado como concluído, ou
seja, já foi testado, corrigido, retestado e aprovado.
Que tal conhecer como acontece o processo de execução dos testes?
Este é o nosso póximo assunto!

TESTES DE SOFTWARE 41
 Seção 2
Processo de execução dos testes
Nesta seção, você vai ver que o processo de teste que deve ser cumprido
na fase de execução. Esse processo está apresentado na figura a seguir.
O Plano de Teste de teste é o documento mais importante deste fluxo.

Figura 12: Fluxo de execução dos testes

DICA
Se ele não for elaborado, não é possível executar cada etapa correta-
mente, ok? Lembre-se disso!

Você vai ver agora os diversos métodos para testar uma aplicação, se-
gundo as características de qualidade dos softwares.
▪▪ Teste de autorização (funcionalidade): visa garantir que as regras
de autorização sejam cumpridas. Ninguém pode executar, por exem-
plo, uma funcionalidade para a qual não está habilitado.
▪▪ Teste de integridade dos arquivos (funcionalidade): garante que
as atualizações de arquivos foram feitas corretamente após a execução
de um módulo do software.
▪▪ Teste de recuperação (continuidade): você deve testar os
procedimentos que permitem que o sistema seja reiniciado após uma
falha. Todos os procedimentos que mostram como reiniciar o sistema
deverão passar por inspeção.
▪▪ Teste de estresse (performance): o teste deve colocar a aplicação
sobre estresse para verificar se o software consegue funcionar correta-
mente sob grande carga de processamento.

42 CURSOS TÉCNICOS SENAI

▪▪ Teste manual (usabilidade):
os sistemas devem ser amigá-
veis, fáceis de utilizar, para que
possam fazer sucesso com os
usuários finais. Normalmente,
é difícil avaliar se uma aplica-
ção é amigável, apenas usando
um ambiente de teste. Então, é
melhor fazer o teste manual num
ambiente mais próximo possível
do ambiente de produção.
▪▪ Teste de segurança (segu-
rança): este tipo de teste deve
verificar se é possível que pessoas
não autorizadas violem as infor-
mações. Em geral, o testador
não é especialista em segurança,
então em alguns casos é necessá-
rio contratar técnicos especialis-
tas para a execução deste teste.
▪▪ Inspeções (manutenibilida-
de): é muito importante testar se
será fácil efetuar a manutenção
da aplicação no futuro. Para a
pessoa que desenvolveu o softwa-
re, é fácil fazer alterações, pois ela
conhece bem a aplicação. Mas
se esta aplicação for mantida por
outro técnico, é necessário que
ela seja simples de entender.
▪▪ Teste de conexão (conec-
tividade): estes testes devem
garantir que a aplicação está se
comunicando corretamente com
outra.
▪▪ Teste de performance
(performance): muitas vezes, as Manutenibilidade é uma me-
aplicações apresentam alguns cri- dida para mostrar se o sof-
térios de desempenho que preci- tware é fácil de consertar ou
ser melhorado.
sam ser atendidos, como número
de clientes ativos ou transações
executadas por hora. Batch: a tradução direta é
lote. No caso de software,
▪▪ Teste operacional (ope- essa palavra está relacionada
racionalidade): neste tipo de
com um arquivo de lote (.bat)
teste, toda a documentação de utilizado para automatizar tare-
operação do software será avaliada. fas.
Ele deve ser feito pela equipe de
produção ou pela equipe que irá
operar a aplicação.
O quadro a seguir é um exemplo
de checklist que pode ser utiliza-
do na execução dos testes. Este
exemplo foi retirado do livro Ga-
rantia da Qualidade de Software do
autor Alexandre Bartié. O quadro
mostra vários procedimentos de
teste para integrações batch em
um sistema de vendas, que cole-
ta todas as entradas de pedidos
realizadas pelos vendedores, nas
quais são informados os produtos
e suas quantidades, descontos e as
condições de pagamento negocia-
das com o cliente.
Normalmente, nas integrações ba-
tch, se você deseja provocar uma
situação no sistema, é necessário
interagir com outros softwares de
forma produzir o resultado dese-
jado.
TESTES DE SOFTWARE 43
 Processo: importa resultado da análise de crédito

Cenário #1

Executar a importação sem a existência do arquivo

Pré - requisitos ▪▪ Garantir que não exista arquivo – texto de importação.

Ações ▪▪ Executar importação da análise de crédito.

Conferências ▪▪ Mensagem “Não foi encontrado o arquivo de Análise de Crédito”.

Cenário #2

Executar a importação com o arquivo disponível

▪▪ Garantir que existam pedidos que aguardam análise de crédito.

Pré - requisitos
▪▪ Garantir que exista arquivo de simulação Simula-01.TXT.

Ações ▪▪ Executar importação da análise de crédito.

▪▪ Mensagem “Importação da Análise de Crédito realizada com sucesso”.

▪▪ Confirmar se o arquivo foi excluído.
Conferências
▪▪ Confirmar se as situações dos pedidos foram alteradas corretamente.
▪▪ Confirmar os motivos para os pedidos com recusa de crédito.

Cenário #3

Executar a importação com arquivo já processado

▪▪ Garantir que exista arquivo de simulação Simula-01.TXT.

Pré - requisitos
▪▪ Garantir que o arquivo Simula-01.TXT já tenha sido processado.
Ações ▪▪ Executar importação da análise de crédito.
▪▪ Mensagem “Este arquivo já foi anteriormente processado!”.
Conferências ▪▪ Confirmar se a operação foi cancelada.
▪▪ Confirmar se o arquivo foi excluído.
Cenário #4

Executar a importação de pedidos com dois dias em pendência de análise de crédito

▪▪ Garantir que existam pedidos aguardando análise de crédito há dois dias.

Pré - requisitos
▪▪ Garantir que exista arquivo de simulação Simula-02.TXT.

Ações ▪▪ Executar importação da análise de crédito.

▪▪ Mensagem “Alguns pedidos estão em análise há dois dias ou mais!”.
▪▪ Confirmar se o arquivo foi excluído.
Conferências ▪▪ Confirmar exibição da lista de pedidos com dois dias em análise ao usuário.
▪▪ Confirmar e-mail para o Gerente de Vendas e de Crédito e Cobrança.
▪▪ Confirmar se e-mail possui lista de todos pedidos com dois dias em análise.
Quadro 6: Checklist para execução de testes

44 CURSOS TÉCNICOS SENAI

Na próxima seção você conhe-
cerá modelos de relatório de tes-
te segundo a IEEE 829. Siga em
frente!
Seção 3
Relatório de teste se-
gundo a IEEE 829
O líder do projeto deverá elaborar
um relatório sobre os testes, ao fi-
nal do projeto. Nesta seção você
estudará alguns relatórios de teste
definido pela norma IEEE 829.
Estes documentos são:
▪▪ relatório de Log de teste;
▪▪ relatório de Incidentes de
teste;
▪▪ relatório de Sumário de teste.
DICA
Nas próximas páginas desta
seção você estudará cada
um desses relatórios.
Relatório de log de tes-
te
O log pode ser considerado como
um diário de ocorrências da ativi-
dade de execução dos testes. O
propósito básico é descrever tudo
de relevante que ocorre durante o
projeto de teste.
Confira os itens que devem estar
no log de teste:
▪▪ identificação;
▪▪ descrição;
▪▪ atividade e eventos;
▪▪ descrição da execução;
▪▪ resultados;
▪▪ informação sobre o ambiente
de teste;
▪▪ eventos imprevistos.
Exemplo:
▪▪ 28 de setembro de 2001.
▪▪ 10h: Nilton começou a testar
o módulo M do sistema L.
▪▪ 10h15: Nilton usou os dados
de teste já existentes conforme o
documento AAA.
▪▪ 10h30: ocorreu um cancela-
mento anormal que foi registrado
no documento correspondente
e encaminhado ao desenvolvi-
mento.
▪▪ 10h40: Nilton interrompeu o
teste, pois está aguardando o pa-
recer da área de desenvolvimento.
Relatório de incidentes
de teste
Qualquer ocorrência no projeto
de teste que requeira algum tipo
de investigação deverá ser regis-
trada no relatório de incidentes.
O uso mais comum deste relató-
rio é quando você encontra um
defeito ocorrido e tem que trans-
mitir para a equipe de desenvolvi-
mento, para que ela tome alguma
providência.
O relatório de incidente de teste
deve ter o seguinte conteúdo bá-
sico:
▪▪ identificador do relatório -
deve ser único em todo o projeto
ou processo de teste;
▪▪ sumário da ocorrência - des-
crever em detalhes o que estava
sendo feito quando ocorreu o
incidente;
▪▪ descrição do incidente - o
IEEE sugere que você coloque
na descrição os seguintes itens:
entradas, resultados esperados,
resultados encontrados, proble-
mas, data e hora da ocorrência,
sugestões de procedimentos a
serem tomados, ambiente, tenta-
tivas de contornar o problema,
testadores envolvidos e observa-
dores.
Relatório de sumário
de teste
Neste relatório você deve apre-
sentar as atividades de teste rea-
lizadas durante um determinado
projeto e mostrar resumidamente
as ocorrências durante todas as
atividades. Este relatório costuma
fechar o projeto de teste.
A seguir conheça o conteúdo des-
se relatório.
▪▪ Identificador: código que
identifica o relatório. Deve ter
uma referência ao projeto de
teste em questão.
▪▪ Sumário: devem ser mos-
trados o escopo do trabalho e
os documentos básicos usados
no projeto, descrevendo resu-
midamente o trabalho de teste
executado.
▪▪ Variações: se algum procedi-
mento foi feito de forma diferen-
te do que está previsto no plano
de teste, deve ser listado neste
item.
▪▪ Avaliações do processo:
qualquer ocorrência que possa
causar impacto na qualidade do
software liberado para a produção
deve ser relatada. Por exemplo,
se algum teste foi interrompido
por falta de prazo.
▪▪ Sumário dos resultados:
neste campo você deve colocar
todos os parâmetros que possam
quantificar o projeto de teste.
Por exemplo, número de casos
de teste, número de execuções
de cada caso, número de defeitos
encontrados etc.
▪▪ Avaliação do teste: você deve
avaliar o projeto de teste e veri-
ficar se alguns riscos ainda não
resolvidos podem causar proble-
mas no momento da produção.
TESTES DE SOFTWARE 45
 ▪▪ Sumário de atividades: neste sumário você deve listar as pessoas
envolvidas no projeto de teste, o número de horas consumidas no
projeto por atividade, tempo total consumido pelo projeto e outras
informações relevantes.
▪▪ Aprovações: nome das pessoas responsáveis pela aprovação do
projeto de teste.

A partir do que você já estudou, percebeu a importância da sua dedi-

cação para percorrer a trajetória de aprendizagem? Então, vamos em
frente.

Seção 4
Gerenciamento de comunicação do projeto de
teste
De acordo com o PMBOK, o gerenciamento de comunicação de um
projeto deve incluir os processos necessários para garantir a geração, a
coleta, a disseminação, o armazenamento e o descarte de todas as infor-
mações do projeto. Assim, o gerenciamento de comunicação se divide
nas seguintes atividades:
▪▪ planejamento das comunicações;
▪▪ distribuição das informações;
▪▪ relatório de desempenho;
▪▪ encerramento.

E cada uma dessas atividades tem o seguinte conteúdo:

▪▪ entradas;
▪▪ ferramentas e técnicas;
▪▪ saídas.

46 CURSOS TÉCNICOS SENAI

Figura 13: Gerenciamento de comunicações

Em resumo, você pode entender que:

▪▪ as entradas são todos os artefatos necessários para realizar a ativida-
de;
▪▪ as ferramentas e técnicas correspondem a tudo o que é feito sobre
as entradas;
▪▪ as saídas correspondem ao resultado final da atividade.

Com este assunto você encerra os estudos desta unidade. Porém, a busca
por novos conhecimentos não acabou. Pesquise sobre os temas, conver-
se com o professor, discuta com seus colegas, enfim, explore todas as
oportunidades de aprendizagem.
Agora prepare-se para uma nova jornada.

TESTES DE SOFTWARE 47
 Unidade de
estudo 7
Seções de estudo

Seção 1 – Definição dos critérios de aceitação

Seção 2 – Elaboração do plano de aceitação
Seção 3 – Execução do teste de aceitação
Teste de aceitação
Seção 1
Definição dos critérios
de aceitação
O teste de aceitação é de respon-
sabilidade do usuário do softwa-
re (teste beta). Segundo Bartié
(2000, p. 157)
“[...] é o último estágio do pro-
cesso de validação. Trata-se do
último processo formal de de-
tecção de erros no sistema, an-
tes de sua disponibilização no
ambiente de produção. Nessa
etapa, o software é disponibi-
lizado para clientes e usuários
com o objetivo de estes valida-
rem todas as funcionalidades
requisitadas no início do proje-
to. Os usuários terão a oportu-
nidade de interagir com um sis-
tema completo, exaustivamente
testado pela equipe de testes.”
Esta validação não precisa ser fei-
ta apenas no final do processo.
Ela pode acompanhar todo o de-
senvolvimento do projeto.
Dessa forma é possível que o pró-
prio usuário detecte problemas
mais cedo, podendo negociar no-
vos prazos.
Para tanto, tá no início do projeto,
quando são elaborados os requi-
sitos, o usuário deve definir quais
critérios serão utilizados para a
aceitação do software. Ou seja, o
que ele irá avaliar no momento do
aceite.
Normalmente, os requisitos a que
o software deve atender podem ser
divididos em três categorias:
▪▪ requisitos de funcionalida-
de: relatam as regras de negócio
a que o software deverá obedecer;
▪▪ requisitos de performance:
retratam requisitos operacionais,
como por exemplo, tempo de
resposta, número de transações
por hora e outras restrições que
deverão ser cumpridas;
▪▪ requisitos de qualidade:
definem atributos de confiança,
testabilidade, correção e usabili-
dade etc.
DICA
A testabilidade indica o quão
fácil é escrever os casos de
teste para o software.
Você já ouviu falar em plano de
aceitação? Vamos ver juntos o
que a próxima seção reserva para
a contuidade dos seus estudos!
Seção 2
Elaboração do plano de
aceitação
O plano de aceitação é um do-
cumento que define os passos
necessários ao teste de aceitação,
como estes testes devem ser feitos
e diversos requisitos e responsabi-
lidades.
O ideal é que o plano de aceita-
ção seja escrito simultaneamente
ao plano geral do projeto e à ela-
boração dos requisitos. O teste de
aceitação vai depender da libera-
ção do software pelos desenvolve-
dores e testadores.
O plano do projeto deverá ter um
cronograma de desenvolvimento
e teste, para indicar quando os
testes de aceitação terão início.
O plano de aceitação deve conter
as informações seguintes.
▪▪ Descrição do projeto: devem
ser especificados o ambiente
operacional e as interligações
com outros software ou ambientes,
além de incluir uma descrição
detalhada do projeto, com suas
fases e a metodologia utilizada no
desenvolvimento.
▪▪ Responsabilidades dos usu-
ários: definir as atividades que os
usuários devem fazer durante os
testes. Deve incluir sua participa-
ção nas etapas do projeto.
▪▪ Procedimentos administra-
tivos: incluir todos os relatórios
gerados durante o trabalho de
teste. Identificar as áreas envolvi-
das. Definir critérios de comuni-
cação entre as partes envolvidas.
▪▪ Requisitos cobertos: iden-
tificar a lista dos requisitos que
serão cobertos pelos testes de
aceitação.
▪▪ Responsável pela elabora-
ção: nomear o responsável pela
elaboração do plano.
TESTES DE SOFTWARE 49
 Agora que você já sabe o que é um plano de aceitaçao, assim como as
informações que ele deve conter, que tal aprender a executá-lo? Siga em
frente!

Seção 3
Execução do teste de aceitação
Os testes de aceitação são executados sobre os produtos entregues du-
rante o ciclo de vida do processo de desenvolvimento. Esses testes se-
rão as últimas oportunidades do usuário para verificar se o produto que
encomendou à equipe de desenvolvimento é de fato o produto que lhe
está sendo entregue. Assim, você pode empregar o aceite como uma
estratégia para reduzir riscos de uma implantação maciça, na qual um
erro vital não detectado pode comprometer a imagem da solução como
um todo.
Os testes de aceitação podem ser divididos em três partes: aceite formal,
alpha – teste e o beta – teste. Confira!

Figura 14: Estágios do processo de aceite de um software.

▪▪ Aceite formal: nesta parte do teste de aceitação, os clientes plane-

jam e realizam os testes. É muito utilizado em projetos desenvolvidos
para atender a um grupo de empresas, possibilitando a criação de um
comitê que atestará a aderência do software às necessidades do grupo.
Assim, o processo de aceitação torna-se uma continuação natural dos
testes funcionais do sistema.
▪▪ Alpha – teste: o objetivo deste teste é permitir que o usuário atue
naturalmente no software, de forma a encontrar defeitos em alguns
procedimentos implantados. Para isso, você deve convidar os clientes
a operar o software em um ambiente localizado na empresa criadora do
software. Neste teste não há formalidades quanto à validação, mas é
importante criar um conjunto reduzido de procedimentos. Pode ser
que os clientes não sigam completamente estes procedimentos, mas
eles funcionarão como um checklist do aceite.
▪▪ Beta – teste: neste tipo de teste de aceitação é feita uma implan-
tação em paralelo. Os clientes vão operar o produto utilizando suas
próprias instalações físicas para que o software seja utilizado no ambien-
te real do dia-a-dia. Você não deve confundir o Beta – teste com a
implantação definitiva.

50 CURSOS TÉCNICOS SENAI

Este teste pode ocorrer até que o cliente se sinta seguro em realizar a
mudança de aplicativo e durante toda a sua execução, ele contará com
o apoio da empresa. Dessa forma a imagem do produto e da empresa
não será prejudicada.
Agora, você já sabe por que alguns sistemas na internet possuem a pala-
vra “beta”, pequenininha, junto com o nome do sistema.
A etapa que trata de “Todos os clientes” indica que o software será im-
plantado definitivamente. Se todas as fases do processo de teste foram
bem planejadas e executadas, nesta etapa o software estará atendendo
corretamente todos os requisitos funcionais e estruturais indicados pelo
cliente.
Confira o que preparamos para você na próxima unidade de estudos!

TESTES DE SOFTWARE 51
 Unidade de
estudo 8
Seções de estudo

Seção 1 – Análise do ponto de teste

Seção 2 – Estimativa baseada no tamanho e
complexidade do caso de uso
Estimativas
Seção 1
Análise do ponto de
teste
Segundo Bastos et al (2007, p. ▪▪ a qualidade do sistema testado
243), a análise de ponto de teste (o ciclo de reincidência de defei- Saiba mais sobre análise de
(APT), é uma técnica de medição tos); ponto de teste em:
de projetos de teste de software. http://www.testexpert.com.
▪▪ o nível de cobertura esperado br/?q=taxonomy/term/8
com os testes; http://qualidadebr.word-
▪▪ a experiência e a produtividade press.com/2009/11/22/esti-
DICA mativa-de-testes-apt/.
da equipe de teste (medidos por
Lembre - se que toda técni- meio de indicadores históricos);
ca de medição e estimativa
deve levar em consideração ▪▪ o grau de automação dos
o ambiente onde está sendo testes;
usada. ▪▪ a qualidade do ambiente de
teste, até mesmo a sua capaci-
dade de simular o ambiente de
produção;
Você nunca deve esperar obter
resultados exatos na primeira vez ▪▪ a qualidade da documentação
que empregar esta análise. Mas do sistema e, especialmente dos
com o tempo e o ajuste do mode- requisitos.
lo, a tendência é que os resultados A figura a seguir mostra as etapas
ficarão cada vez mais precisos. necessárias para se chegar ao ta-
O objetivo da APT é determinar manho do sistema em pontos de
o tempo necessário à etapa de tes- teste. Veja!
tes. Esta técnica leva em conside-
ração o tamanho do sistema a ser
testado a partir das informações
coletadas com as equipes de de-
senvolvimento. Os testes também
são afetados pelos seguintes fato-
res:
▪▪ o grau de complexidade do
processo de teste;
▪▪ o nível de qualidade que se
pretende alcançar com os testes;
▪▪ o grau de envolvimento dos
usuários com os testes;
▪▪ as interfaces que são as
funções testadas têm com os
arquivos;
Figura 15: Visão geral da Análise de Pontos de Teste.

TESTES DE SOFTWARE 53
 Seção 2
Estimativa baseada no tamanho e complexidade
do caso de uso
De acordo com Bastos et al (2007, p. 246) este tipo de estimativa é
simples e necessita de pouco conhecimento em cálculos. Ela utiliza as
seguintes entradas:
▪▪ contagem do número de fluxos de um determinado caso de uso;
▪▪ média de passos de cada fluxo (passo do ator e reação do sistema);
▪▪ contagem do número de exceções;
▪▪ contagem das regras de negócios, classificadas como simples, médias
e complexas.

Você deve calcular o esforço de teste combinando a complexidade e o

tamanho do caso de uso.
Por exemplo, quanto tempo é necessário para testar um caso de uso
pequeno e de complexidade simples?
Esse valor de tempo deve ser corrigido periodicamente (histórico asso-
ciado à experiência e à maturidade da equipe de teste). Quando existem
pessoas com diferentes níveis de experiência, você pode atribuir um fa-
tor de correção. Veja a tabela a seguir.

Tamanho Complexidade Horas

Pequeno Simples 6
Pequeno Média 8
Pequeno Complexa 10
Médio Simples 8
Médio Média 12
Médio Complexa 16
Grande Simples 12
Grande Média 18
Grande Complexa 20
Muito grande Simples 16
Muito grande Média 20
Muito grande Complexa 28
Tabela 1: Esforço de teste em horas

54 CURSOS TÉCNICOS SENAI

A complexidade deve ser informada pela área de negócio, responsável
pela elaboração do caso de uso.
Esse valor em horas (complexidade/tamanho) deve ser dividido pelas
diferentes fases do ciclo de teste (elaboração, execução, reteste etc). Bas-
tos et al (2007, p. 249) cita os seguintes valores:
▪▪ planejamento + projeto de teste = 35% do tempo total;
▪▪ execução do teste = 60%;
▪▪ 5% restante destinado para o reteste e a conclusão do teste.

É importante que você saiba que estes valores podem variar muito de
um caso para outro. Eles não são valores fixos, precisam de um ajuste
gradativo. E as técnicas, apesar de sólidas, devem ser aplicadas com
cuidado, principalmente na hora de transformar tamanho em esforço.

Estamos falando de estimativas, então nada é completamente preciso.

Ou seja, é necessário que você entenda que esta análise deve ser aplicada,
mas não espere que na primeira vez o resultado será perfeito. Você pre-
cisará fazer a análise novamente para o mesmo sistema e para sistemas
diferentes, até que a sua prática e conhecimento na área consiga chegar
em um valor bastante aproximado da realidade.
Neste caso, não se preocupe em acertar da primeira vez. Preocupe- se
sim, em continuar melhorando a cada dia.

TESTES DE SOFTWARE 55
Finalizando
Parabéns, você chegou ao final de mais uma etapa!
Agora você já sabe da importância da busca pela qualidade de software. Também sabe que para
atingir a qualidade, é necessário utilizar uma metodologia adequada e principalmente, dentro dessa
metodologia, como um processo. Ou seja, deve acompanhar o desenvolvimento desde o início até
quando o sistema está rodando na versão beta.
Tipos e técnicas existem aos montes para você escolher. É importante que você saiba distinguir o
que é melhor para o sistema que está sendo desenvolvido. Lembre-se que testar custa dinheiro e
corrigir problemas também. Principalmente se estes problemas são encontrados lá no final do ciclo
de vida do desenvolvimento.
Então você precisa equilibrar a quantidade de testes com os riscos existentes. Testar o programa do
mercado do Seu Zé é diferente de testar o programa de gerenciamento de recursos de um hospital.
Lembre- se: você está destinado a ser um ótimo profissional, mas para isso precisa estar preparado
em todos os campos. Ser um bom desenvolvedor de software não é apenas fazer um software que
funcione. E sim é fazer um software que seja fácil de testar, fácil de se fazer manutenção e que possa
ser adaptado à várias condições de uso.

TESTES DE SOFTWARE 57
Referências
▪▪ AGAPITO, Robson. Estimativas de teste. 01 mar. 2010. Disponível em: <http://www.tes-
texpert.com.br/?q=taxonomy/term/8>. Acesso em: 31 out. 2010.

▪▪ BARTIÉ, Alexandre. Garantia da qualidade de software. Rio de Janeiro, RJ: Campus, 2002.
ISBN 8535211241.

▪▪ BASTOS, Aderson et al. Base de conhecimento em teste de software. 2. ed. rev. São Paulo,
SP: Martins, 2007. 263 p. ISBN 9788599102893.

▪▪ CAMPOS, Fabricio F. de. Estimativa de teste (APT). 22 nov. 2009. Disponível em: <http://
qualidadebr.wordpress.com/2009/11/22/estimativa-de-testes-apt/>. Acesso em: 31 out.
2010.

▪▪ PALMA, Fernando F. O processo de teste de software. 20 out. 2009. Disponível em:

<http://testesdesoftware.blogspot.com/>. Acesso em: 31 out. 2010.

▪▪ RIOS, Emerson. Gerência do projeto de testes segundo o modelo PMI. 01 out. 2007.
Disponível em: <http://www.testexpert.com.br/?q=node/224>. Acesso em: 31 out. 2010.

▪▪ RIOS, Emerson; MOREIRA FILHO, Trayahú R. Teste de software. 2. ed. rev. e ampl. Rio de
Janeiro, RJ: Alta Books, c2006. 222 p. ISBN 8576081288.

▪▪ SILVA Filho, Antonio M. da. Componentes de software: componentização no desen-

volvimento de software. Ago 2008. Disponível em: <http://www.espacoacademico.com.
br/087/87amsf.htm>. Acesso em: 31 out. 2010.

▪▪ SOMMERVILLE, Ian. Engenharia de software. 8. ed. São Paulo, SP: Addison-Wesley, 2007.
xiv, 552 p. ISBN 9788588639287.

TESTES DE SOFTWARE 59
Equipe de Desenvolvimento de Recursos Didáticos

Coordenação de Educação a Distância

Beth Schirmer

Coordenação Projetos EaD

Maristela de Lourdes Alves

Coordenação de Desenvolvimento de Recursos

Didáticos
Gisele Umbelino

Projeto Educacional
Angela Maria Mendes
Israel Braglia

Projeto Gráfico
Daniela de Oliveira Costa
Jordana Paula Schulka
Juliana Vieira de Lima

Design Educacional
Gisele Umbelino

Capa, Ilustrações, Tratamento de Imagens

D’imitre Camargo Martins
Diego Fernandes
Luiz Eduardo Meneghel

Diagramação
Daniela de Oliveira Costa

Revisão e Fechamento de Arquivos

Daniela de Oliveira Costa
Juliana Vieira de Lima

Revisão Ortográfica e Normatização

FabriCO