Testes de Software - Apostila

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!
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.
Para que você possa verificar as ▪▪ Disponibilização de Solu-
atividades e avaliar os documen- ção: validação do aceite.Lembre- ▪▪ Teste é um processo siste-
tos gerados durante as fases do -se de que o conhecimento se mático e planejado que tem
processo de engenharia de softwa- adquire por meio de uma cons- por finalidade única a identi-
ficação de erros.
re, deve utilizar os testes de veri- trução significativa da aprendiza-
ficação. gem. Então, vamos juntos trilhar
As fases da metodologia que fa- novos caminhos do conhecimen-
zem parte dos testes de verifica- to? Esta é considerada a definição
ção são: correta sobre os testes. Inde-
pendentemente do teste ser apli-
▪▪ Modelo de Negócios: verifi- Seção 3 cado a um documento ou a um
cação de negócios; O que é teste de software, o objetivo é criar situa-
▪▪ Especificação de Requisi- software? ções onde o produto pode não
tos: verificação de requisitos; funcionar.
▪▪ Análise e Modelagem: verifi- Existem atualmente, duas defini-
cação, análise e modelagem; ções para teste.
▪▪ Implementação: verificação Você sabe quais são? Vamos ver
da implementação. juntos.
A definição mais comum, que a
Desta forma, defini-se testes de maioria das equipes de desenvol-
validação como: vimento aplica está simplificada
como:
[...] um processo formal de ava-
liação de produtos tecnológicos
que podem ser aplicados em ▪▪ Teste é o processo de de-
componentes isolados, módulos monstrar que algo funciona
existentes ou mesmo nos siste- corretamente.
mas como um todo. Seu objeti-
vo é avaliar a conformidade do
▪▪ Teste é o processo de pro-
var que determinadas coisas
software com os requisitos e
fazem o que deveriam fazer.
especificações analisadas e revi-
sadas nas etapas iniciais do pro-
jeto (BARTIÉ, 2002, p. 38).
Ou seja, todo mundo vê os tes-
Ou seja, os testes de validação são tes como uma forma de mostrar
aqueles feitos quando já existe que está tudo bem. Na verdade, é
alguma parte do software pronta. mais fácil mostrar que um software
São os testes feitos no software e está funcionando do que mostrar
não na documentação. Nos testes que ele não está funcionando.
de validação, temos as seguintes Mas, ao colocar uma pessoa que
fases: 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
▪▪ Unidade Especificada ou nenhuma ligação com este, esta a ausência de erros. Ou seja, por
Modificada: validação da uni- pessoa criará diversas situações, melhor que seja um processo de
dade; possíveis no dia-a-dia do produto, qualidade, nunca será possível
▪▪ Integração Especificada e conseguirá demonstrar que em cobrir todas as infinitas combina-
ou Modificada: validação da determinados cenários, o com- ções existentes em um ambiente
integração; portamento deste produto pode de execução real. Pense sempre
▪▪ Sistema Especificado ou gerar um funcionamento inade- nisso!
Modificado: validação do siste- quado. Vamos em frente? Na próxima
ma; Neste ponto, é possível chegar à seção você verificar o que pode
segunda definição de teste: acontecer quando um software não
é testado.

▪▪ ampliam as chances de sucesso do projeto de software e,
Seção 4
▪▪ evitam a propagação de erros.
E se não testar o Interessante, não é mesmo? Bastos et al (2007) cita a regra 10 de Myers,
software? que estabelece que o custo de correção de um erro aumenta muito com
o passar do tempo.
Erros, falhas, incidentes, não con-
formidades e inconsistências são
palavras que representam nature- DICA
zas diferentes de defeitos. Apesar
de ser um pensamento comum, Quanto mais tempo demorar para se descobrir um erro, mais caro
será a solução deste erro. Defeitos encontrados na documentação
esses defeitos não vêm apenas
de modelamento são muito mais baratos do que defeitos encontra-
no código – fonte do produto. E dos durante a produção. Portanto fique atento!
também não são apenas os pro-
fissionais de desenvolvimento,
qualidade e testes, os responsáveis
por um software sem defeitos. 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!
Seção 5 Caso de teste Portal de Administração de Sites – Imóveis Carvalho
Casos de testes
CT 85 – Buscar para alteração. Botão visualizar o
Caso de teste
calendário de locação.
De acordo com Bastos et al (2007,
p. 153) um caso de teste é a espe- Ter clicado em “Buscar para alteração” na página
cificação mais detalhada do teste, Pré-condições de imóveis e estar com a opção de locação para a
apresentando os campos de telas, temporada.
formulários etc. O caso de teste
1. O ator clica em “Visualizar o calendário de
estabelece as informações empre- locação do imóvel”representado pelo terceiro
gadas nos testes dos cenários e ícone da esquerda para a direita na parte
quais são os resultados esperados. Procedimentos superior da descrição do imóvel.
Ou seja, é necessário fazer um de-
talhamento do que será testado, 2. O sistema carrega um calendário destacando
os dias de locação do imóvel.
como será feito o teste, quem é
responsável, quais são as entradas Resultado
Carregar o calendário de locação do imóvel.
necessárias e quais são as saídas esperado
esperadas.
Critérios
Um bom caso de teste deve con- Não se aplica.
especiais
ter:
Implementação Manual.
▪▪ identificação das condições de
teste; Iteração 1ª iteração.
▪▪ o que testar (identificação dos Quadro 1: Exemplo de caso de teste
casos);
▪▪ detalhamento da massa de Neste exemplo você pode ver que os casos de teste são bem detalhados
entrada e de saída (dados); e devem ser descritos de uma forma criteriosa. Todos os cenários e
▪▪ critérios especiais, quando casos de uso devem ser criados, verificando todas as funcionalidades do
necessários, para gerar os dados software. Por isso eles dão bastante trabalho para a pessoa responsável
de entrada e saída do teste; pela sua elaboração.
▪▪ especificação das configura- Preparado para seguir mais um percurso? Conheça na próxima seção os
ções de ambiente no qual o teste tipos de teste.
será executado: sistema operacio-
nal, ferramentas necessárias, ori-
gem dos dados etc (onde testar); Seção 6
▪▪ como testar: automático/ma- Tipos de testes
nual (definir o tipo de implemen-
tação do teste); 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
▪▪ quando testar (cronograma,
ser executado.
em qual fase o teste será execu-
tado); Para fazer esta validação você pode utilizar duas abordagens:
▪▪ listar as interdependências, ▪▪ a estratégia da caixa branca ou,
caso existam, entre os casos de ▪▪ a estratégia da caixa preta.
teste.
O quadro a seguir é um exemplo
de caso de teste aplicado a um sis-
tema de uma imobiliária. Veja!
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?
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.

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ê.
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 Seção 2 Seção 3

O que é técnica de Técnicas funcional, Critérios para geração
teste? estrutural e baseada em de casos de teste
erros
De acordo com Bastos et al (2007, Para que você possa garantir certa
p. 86) a técnica de teste é um pro- Os testes funcionais são aqueles qualidade no software é necessário
cesso que assegura o funciona- que verificam o funcionamento que teste certa quantidade de pos-
mento adequado de alguns aspec- do software e se ele atende os re- sibilidades, ou cenários.
tos do sistema ou da unidade. quisitos. Ou seja, se o código faz
Já as ferramentas de teste são re- aquilo que foi pedido pelo cliente
cursos para o testador. Utilizar e que está na documentação. Nor- Quanto maior a quantidade
apenas a ferramenta, sem a técni- de cenários testados, maior
malmente é necessária a criação
ca adequada, não é suficiente para a qualidade do produto. Lem-
de condições de teste que serão bre-se que não será possível
conduzir todo o teste. usadas na avaliação da correção chegar ao software perfeito,
da aplicação. sem defeitos. Portanto, você
Já os testes estruturais verificam deve determinar quais serão
DICA se o software possui uma estrutura os cenários necessários para
robusta, ou seja, se ele se mantém atingir a qualidade desejada,
Por exemplo, um serrote é
funcionando quando ocorrem ok?
apenas uma ferramenta, que
se não for usada com a técni- condições adversas. Nesses tipos
ca adequada, pode não cor- de teste, não há preocupação com
tar a madeira e sim a pessoa. o atendimento aos requisitos e A ênfase dos testes de validação
sim se a tecnologia foi usada de está nos métodos que identificam
modo adequado e se os com- todos os possíveis cenários de
ponentes montados funcionam testes, chamados casos de testes.
Enfim, são poucas as técnicas e
como uma unidade. Como você possuí duas técnicas
muitas as ferramentas existentes.
Quando você usa uma técnica de para lidar com os testes de software
Na próxima seção você verá as (testes estruturais e funcionais), a
teste baseada em erros, deverá in-
principais técnicas de teste. Va- obtenção dos casos de teste estará
serir erros no software e verificar o
mos em frente! associada a uma dessas técnicas.
seu funcionamento. Na verdade,
esta é uma variação da técnica fun- Para Bartié (2002, p. 122),
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!
“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.

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).
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

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

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.
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:

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!
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 Seção 2
Definição de risco Riscos relativos ao teste de software
Você sabe o que significa a pala- A atividade de testar o software está bastante ligada ao risco. Você já
vra risco? estudou como o custo dos testes influencia no desenvolvimento de um
Segundo o dicionário da língua software. Também já viu que os defeitos encontrados tardiamente aumen-
portuguesa Michaelis, risco é a tam bastante o custo da correção.
possibilidade de perigo, incerto, Por isso, as equipes de teste devem procurar um nível de cobertura que
mas previsível, que ameaça de minimize a possibilidade de defeitos graves, principalmente por causa da
dano a pessoa ou a coisa. existência de prazos. Ou seja, apesar de existirem riscos relativos a de-
Quando falamos de software, es- terminados defeitos, é necessário um tempo maior de teste com aqueles
tamos procurando aqueles fatos que podem gerar os maiores problemas.
cujas ocorrências poderão acarre-
tar perdas para a empresa. No
entanto, um risco presente nem DICA
sempre vai gerar uma perda. Ao fazer a análise de riscos, leve em consideração a probabilidade
Se uma empresa faz todo o seu de ocorrência do risco e o impacto e perda associados a esse risco.
negócio na internet, por exem-
plo, venda de produtos, existe um
grande risco de perda de dinheiro,
se os computadores pararem de Neste momento possivelmente você esteja se perguntando: mas, como
funcionar. Mas se você pensar no analisar e avaliar os riscos que possam surgir? É sobre isso que conver-
mercadinho da esquina, não existe samos a seguir.
nenhum problema se o computa-
dor do caixa parar.
Mas, o que isso tem haver com o
Seção 3
teste de software? Encontre a res- Determinação da magnitude dos riscos
posta para este questionamento
na próxima seção. 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!
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:

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

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

Pré - requisitos
▪▪ Garantir que o arquivo Simula-01.TXT já tenha sido processado.
▪▪ Mensagem “Este arquivo já foi anteriormente processado!”.
Conferências ▪▪ Confirmar se a operação foi cancelada.
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

▪▪ Mensagem “Alguns pedidos estão em análise há dois dias ou mais!”.
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

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

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

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!
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.
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

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.
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.
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.
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
Revisão e Fechamento de Arquivos

Juliana Vieira de Lima
Revisão Ortográfica e Normatização

FabriCO

Testes de Software - Apostila

Enviado por

Direitos autorais:

Formatos disponíveis

Testes de Software - Apostila

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Testes de Software - Apostila

Enviado por

Direitos autorais:

Formatos disponíveis

Curso Técnico em Informática

Regina Maria de Fátima Torres

Sérgio Roberto Arruda

Antônio José Carradore

Marco Antônio Dociatti

Curso Técnico em Informática

Carlos Eduardo Carvalho

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

SENAI/SC — Serviço Nacional de Aprendizagem Industrial

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

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

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

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

36 Unidade de estudo 5 52 Unidade de estudo 8

Carga horária: 30 horas

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

Analisar os resultados de testes realizados em sistemas computacionais.

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

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

Seção 1 – Metodologia de desenvolvimen-

14 CURSOS TÉCNICOS SENAI

Os erros são resultados do

A falta de testes em todas as etapas

Figura 3: Estratégias fundamentais dos testes.

16 CURSOS TÉCNICOS SENAI

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

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

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

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

Figura 5: Teste de caixa preta.

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

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

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

18 CURSOS TÉCNICOS SENAI

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

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

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

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

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

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

Seção 1 Seção 2 Seção 3

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

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,

22 CURSOS TÉCNICOS SENAI

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

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

As bibliografias especializadas apresentam diversos tipos de testes que

▪▪ Revisar contexto do mercado e necessidade do

▪▪ Revisar arquitetura da aplicação.

▪▪ Revisar código fonte.

Quadro 2: Fases dos testes de verificação

24 CURSOS TÉCNICOS SENAI

Fase da Validação Características

▪▪ Estratégia caixa branca e caixa preta.

▪▪ Executada pelo desenvolvedor ou profis-

▪▪ Estratégia de caixa preta.

▪▪ Executado por um grupo de testes inde-