Teste de software 1

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Conteudista: Prof. Me. Ariel da Silva Dias
Revisão Textual: Thalia Feitosa Monteiro
 
Objetivos da Unidade:
Compreender o conceito de teste de software;
Reconhecer os tipos de teste de software;
Aplicar o conceito de teste de software em cenários reais.
 Material Teórico
 Material Complementar
 Referências
Introdução e Conceitos Básicos de Testes de Software
Introdução ao Teste de Software
Os seres humanos são propensos a cometer erros devido à falta de atenção, suposições incorretas, descuidos ou conhecimentos
inadequados do sistema. Essa mesma natureza dos humanos torna o software vulnerável a bugs, defeitos e erros. Para prevenir e
corrigir esses problemas, é necessário fazer o teste de software (TS).
Tradicionalmente, o TS era feito em uma única fase e apenas depois que a implementação ou codi�cação costumava ser concluída. Mas
a complexidade crescente dos aplicativos de software levou à evolução dos testes de software. Portanto, as técnicas de teste foram
evoluídas e as atividades envolvidas em um processo de TS não se limitaram a uma única fase, em vez disso, foram integradas às
diferentes fases do ciclo de vida de desenvolvimento de software. Deste modo, para começar nossos estudos, primeiramente precisamos
compreender conceito de TS e tudo o que o cerca.
Em linhas gerais, o TS é um processo empregado para que possamos avaliar a funcionalidade de um aplicativo de software com a
intenção de descobrirmos se o software desenvolvido atendeu aos requisitos especi�cados ou não e para identi�car os defeitos, de modo
a garantir que o produto esteja livre de problemas, a �m de produzir um produto de qualidade.
Deste modo, o TS se destaca por ser um processo que veri�ca um sistema integralmente, com o objetivo de identi�car quaisquer erros,
lacunas ou requisitos ausentes em relação ao requisito real. O TS pode ser dividido em dois tipos: teste funcional e teste não funcional.
O teste funcional envolve testar o aplicativo em relação aos requisitos de negócios. Ele incorpora todos os tipos de teste projetados para
garantir que cada parte de um software se comporte conforme o esperado, usando casos de uso fornecidos pela equipe de design ou
analista de negócios. Esses métodos de teste são geralmente realizados em ordem e incluem o Teste de Unidade, Teste de Integração,
Teste de Sistema e Teste de Aceitação.
Os métodos de teste não funcionais incorporam todos os tipos de teste focados nos aspectos operacionais de um pedaço de software.
Esses incluí o Teste de Performance, Teste de Segurança, Teste de Usabilidade e Teste de Compatibilidade.
A chave para o lançamento de software de alta qualidade que pode ser facilmente adotado por seus usuários �nais é construir uma
estrutura de teste robusta que implemente metodologias de teste de software funcionais e não funcionais.
Agora que você já sabe o que é o TS, vamos compreender o porquê ele se faz necessário em um processo de desenvolvimento. Observe
então alguns dos principais pontos positivos:
1 / 3
 Material Teórico
O TS fornece garantias às partes interessadas de que o produto funciona conforme a especi�cação inicial;
Defeitos evitáveis que vazam para o usuário �nal/cliente sem os testes adequados adicionam uma má reputação à
empresa de desenvolvimento;
Observe este exemplo: o fabricante de automóveis testa o carro quanto à velocidade máxima, economia de combustível e segurança
contra acidentes. Após obtido os dados do teste, o seu resultado poderá ser utilizado, mais tarde, como parte da estratégia de
publicidade para vendas de automóveis ou para propor limites seguros de direção.
O desenvolvimento de um novo software pode ser muito complexo. A�nal, você vai querer ter certeza de que tudo está absolutamente
perfeito desde o início. Se você não realizar uma quantidade adequada de testes, há uma boa chance de que seu software seja lançado
com grandes falhas e erros.
Exemplo clássico de TS: uma verdade universal é que todas as empresas estão sujeitas a bugs de software. Na verdade, algumas das
empresas mais con�áveis e respeitadas enfrentaram sérios problemas. Veja a NASA como exemplo: O Mars Climate Orbiter da empresa
caiu porque pousou muito rápido (FERRONI, 1999). No �nal, descobriu-se que a agência havia utilizado unidades não métricas.
Infelizmente, o software precisava de unidades métricas. Esse simples lapso custou à empresa US$ 125 milhões!
Outro caso emblemático é o bug do ano 2000 (FERREIRA, 2017). No �nal de 1999, todos tinham medo de que seus computadores
funcionassem mal quando chegasse ao ano 2000. O bug era incrivelmente simples. O desenvolvedor decidiu que era uma boa ideia
armazenar anos como dois dígitos. Felizmente, o problema foi �nalmente corrigido, mas não antes de bilhões de dólares serem
desperdiçados para empresas do setor de software. 
A fase de teste separada adiciona um fator de con�ança para as partes interessadas em relação à qualidade do software
desenvolvido;
Os defeitos detectados na fase anterior do ciclo de vida de desenvolvimento de software resultam em menor custo e
utilização de recursos para resolução de defeitos;
A equipe de teste adiciona outra dimensão ao desenvolvimento de software, fornecendo um ponto de vista diferente
para o processo de desenvolvimento do produto;
Um software não testado não apenas torna o software sujeito a erros, mas também custa ao cliente o fracasso
comercial.
Você Sabia? 
Problemas de software também podem custar vidas, por exemplo, no caso do Therac 25, muitas
pessoas morreram devido a erros de programação simultâneos em que os pacientes receberam doses
de radiação centenas de vezes maiores do que o normal, resultando em morte ou ferimentos graves.
Entidades Envolvidas no Teste de Software
Um TS pode ser realizado por todas as pessoas (sejam elas técnicas ou não técnicas) associadas ao desenvolvimento do software. Deste
modo, o teste em suas várias fases é feito:
Funções e Responsabilidades do Testador
Muitas pessoas não estão completamente cientes das funções e responsabilidades de um testador de software. A seguir, você aprenderá
sobre essas funções e responsabilidades.
Pelo desenvolvedor: o desenvolvedor faz o teste de unidade do software e garante que os métodos individuais
funcionem corretamente;
Pelo testador: os testadores são a cara do TS. Um testador veri�ca a funcionalidade do aplicativo como um Testador
Funcional, veri�ca o desempenho do aplicativo como um Testador de Desempenho, automatiza os testes funcionais e
cria scripts de teste como um Testador de Automação;
Pelos gerentes de teste/líder/arquitetos: responsáveis por desenvolver e de�nir a estratégia de como será
implementado o teste, bem como os documentos do plano de teste;
Pelos usuários �nais: um grupo de usuários �nais faz o Teste de Aceitação do Usuário do aplicativo para garantir que
o software funcione no mundo real.
Analisar as especi�cações de requisitos do sistema e entender as necessidades para o cliente e para o teste;
Determinar uma estimativa para o teste;
Preparar ou compreender o plano de teste;
Reunir casos de teste;
Reunir dados de teste;
Testar e encontrar defeitos no software;
Relatar os defeitos imediatamente para tornar mais fácil para o desenvolvedor corrigir;
Testar novamente após o problema inicial ter sido corrigido;
Realizar teste de regressão;
Oferecendo sugestões para melhorar os processos do ciclo de vida de desenvolvimento de software;
Oferecer suporte aos clientes que estão testando o software;
Participar da implementação do software;
A importância do TS é imensa. É por isso que mais e mais empresas continuarão a gastar mais dinheiro em testes de software. Na
verdade, em breve poderá se tornar a maior despesa em que qualquer empresa de tecnologia poderá incorrer. No entanto, também é
verdade que os custos valerão a pena no longo prazo.
Como Fazer o Teste e Quando Isso Deve Acontecer?
O teste pode ser feito tanto manualmente quanto usando ferramentas de automação. Quando executado manualmente,
é chamado de
Teste Manual. Inclui veri�cação de requisitos, desenvolvimento de estratégia e plano de teste; preparação de casos de teste, execução de
casos de teste, criação de defeitos, reteste de defeitos e, �nalmente, compartilhamento de relatórios de teste com todas as partes
interessadas relevantes.
Quando ferramentas automatizadas são usadas, é chamado de teste de automação. Inclui preparação de script de teste e geração de
relatório de teste usando diferentes ferramentas como – Selenium, Katalon Studio, QTP, entre outras.
Com base na seleção de diferentes modelos de Ciclo de Vida de Desenvolvimento de Software, as atividades de teste podem ser realizadas
nas diferentes fases deste ciclo de vida.
Existe um mito de software de que o teste é feito apenas quando alguma parte do software é construída, mas o teste pode (deve) ser
iniciado antes mesmo de uma única linha de código ser escrita. Isso pode ser feito em paralelo com a fase de desenvolvimento. A Tabela
1 a seguir apresenta uma relação simpli�cada da fase de desenvolvimento e a atividade de teste que deve ser empregada.
Tabela 1 – Fase de Desenvolvimento x Atividade de Teste
Fase de Desenvolvimento Atividade de Teste
Levantamento dos Requisitos do Projeto Criação de Teste de Aceitação 
Especi�cação Funcional Criação de Caso de Teste Funcional 
Implementação Criação de Caso de Teste de Unidade 
Código Completo Execução de Caso de Teste 
Observe pela Tabela 1 que, já no início do ciclo de vida de desenvolvimento do software, a equipe de desenvolvimento e de testes já
devem se preocupar com as atividades a sempre empregadas em cada uma das fases.
Teste de Software Manual
Fornece suporte após a conclusão da implementação.
Como o nome sugere, o Teste Manual é aquele em que o teste do aplicativo acontece manualmente. Os casos/cenários de teste são
executados um a um pelos testadores manualmente, sem usar nenhuma ferramenta pronta, e então os resultados são veri�cados.
Portanto, o Teste Manual é um processo no qual comparamos o comportamento de um pedaço de software (pode ser um componente,
módulo, recurso, entre outros) com o comportamento esperado prede�nido que de�nimos durante as fases iniciais do ciclo de vida de
desenvolvimento de software.
A veri�cação manual é a forma mais primitiva de TS. Um novato pode fazer isso sem nenhum conhecimento de nenhuma ferramenta
em particular. Mesmo um aluno, que tem um conhecimento básico da aplicação ou teste de um sistema, pode realizar a veri�cação
manual. No entanto, é uma etapa essencial no ciclo de TS. Qualquer novo sistema ou aplicativo deve ser testado manualmente antes de
automatizar o teste.
Então, até aqui você compreendeu o que é o teste manual, porém, �ca a dúvida de quando exatamente devemos fazer o teste manual ou
quais são os cenários que nos obrigam a optar por esse tipo de teste. Vejamos mais explicações em cada um dos seguintes cenários:
Tabela 2 – Tipos de Testes Manuais
Teste Descrição
Teste de Unidade 
A validação de um componente ou módulo de software individual é
chamada de Teste de Unidade. Geralmente, os desenvolvedores o
executam, pois requer conhecimento detalhado do design e do código
interno do programa. 
Teste de Integração 
O teste de integração é o teste de um subsistema que compreende dois ou
mais componentes de integração. É executado depois que os componentes
individuais foram testados no teste de unidade e estão funcionando
conforme o esperado. É realizado para encontrar defeitos nas interfaces e
nas interações entre os componentes integrados. 
Teste Adhoc: o Teste Adhoc, como o nome sugere, é um teste não planejado. Não tem uma abordagem especí�ca
de�nida nem tem qualquer documentação associada a ele. O Teste Adhoc é totalmente informal e o único fator
importante é o conhecimento e a percepção do testador. Portanto, em tais casos, o teste manual é uma boa opção;
Teste de Usabilidade: outro cenário em que o teste manual é necessário é o caso do teste de usabilidade. Realizamos
testes de usabilidade para avaliar o quão conveniente, e�ciente e amigável o produto se tornou para os usuários �nais.
Para esta avaliação, exigimos a mais alta intervenção manual e não podemos contar com ferramentas para avaliá-la
para nós. Portanto, para avaliar o produto do ponto de vista do usuário �nal, optamos pelo teste manual;
Teste Exploratório: quando a documentação do teste é pobre, e temos pouco tempo para execução, nesses casos, este
teste exploratório requer habilidade analítica e criatividade do testador e também o conhecimento do produto do
testador. Quando temos que realizar testes exploratórios, vamos para a veri�cação manual, pois não podemos usar
ferramentas com pouco conhecimento e documentação.
Teste Descrição
Teste de Sistema 
Teste do sistema signi�ca testar o sistema em sua totalidade. Todos os
componentes desenvolvidos são testados no teste de unidade e, em
seguida, integrados em um aplicativo. Depois de concluído, testamos todo
o sistema rigorosamente para garantir que a aplicação atenda a todos os
padrões de qualidade. 
Teste de Aceitação 
Teste de Aceitação do Usuário é um tipo de teste realizado pelo Cliente
para certi�car o sistema quanto aos requisitos acordados anteriormente.
Realizamos esse teste na fase �nal de teste antes de mover o aplicativo de
software para o ambiente de mercado ou produção. O cliente executa este
tipo de teste em um ambiente separado (semelhante ao ambiente de
produção) e con�rma se o sistema atende às especi�cações dos requisitos. 
Teste de Caixa Preta 
No método Teste de Caixa Preta ou Black Box Testing, o teste ocorre sem o
conhecimento dos códigos internos e da estrutura do programa. O teste
ocorre do ponto de vista do cliente, e o testador conhece apenas as
entradas e as saídas esperadas do aplicativo. O testador não está ciente de
como as solicitações estão sendo processadas pelo software e fornecendo
os resultados de saída. 
Teste de Caixa
Branca 
O Teste de Caixa Branca é o método de teste no qual o testador conhece os
códigos internos e a estrutura do software. O testador escolhe as entradas e
executa o teste fornecendo entradas ao sistema por meio dos códigos e
determina as saídas apropriadas. O foco principal do Teste da Caixa
Branca é fortalecer a segurança e melhorar o design e a usabilidade do
software. 
Independentemente de qual teste manual for escolhido, é necessário compreender que existem seis etapas a serem seguidas, são elas:
Etapa 1 – Análise de Requisitos: Seus valiosos testadores de software precisam visualizar, estudar e analisar as
especi�cações e requisitos disponíveis. Certos requisitos produzem resultados alimentando-os com dados de entrada.
Esses requisitos são requisitos testáveis. Os testadores estudam os requisitos funcionais e não funcionais. Depois
disso, eles precisam escolher os requisitos testáveis. Depois de reunir e entender os requisitos, sabemos qual é o
comportamento esperado e o que precisamos testar, e quando dizemos que encontramos o defeito. Podemos resumir
esta etapa em quatro frases:
Compreenda a saída esperada do produto;
Identi�que quaisquer lacunas nas especi�cações;
Colete prioridades;
Realize veri�cações de viabilidade de automação.
Todas as seis fases de um ciclo de vida de TS têm critérios de entrada ou saída associados a eles. Os testadores precisam terminar de
executar os casos de teste dentro de um tempo �xo. Além disso, eles precisam manter a qualidade, funcionalidade e e�ciência do
Etapa 2 – Planejamento de Testes: uma vez que entendemos os requisitos, identi�camos e elaboramos os casos de
teste que cobrirão todos os requisitos contidos na documentação do projeto. Além disso, os casos de teste nos ajudam
a seguir uma sequência para testar as funcionalidades e os vários cenários de teste, de forma a cobrir todo o aplicativo
e veri�car os resultados esperados. A entrega mais importante gerada nesta etapa é o plano de teste, que é um
documento que descreve a motivação e os detalhes das atividades de
teste para um determinado projeto. Podemos
resumir esta etapa em três frases:
Prepare a documentação do plano de teste;
Faça uma estimativa de tempo e esforços;
Identi�que os requisitos de treinamento.
Etapa 3 – Projeto e desenvolvimento de casos de teste: Com base no plano de teste, os testadores projetam e
desenvolvem casos de teste. Os casos de teste devem ser extensos e cobrir quase todos os casos possíveis. Uma vez
que os casos de teste estão prontos, o testador deve revisá-los com o líder da equipe e com o cliente, se necessário.
Examinando os casos de teste, encontraremos falhas, se houver, e as corrigiremos antes de executar os casos de teste.
Podemos resumir esta etapa em três frases:
Pesquise e reúna possíveis ações sobre o produto;
Crie casos de teste;
Prepare scripts automatizados para casos de teste.
Etapa 4 – Con�guração do ambiente de teste: As atividades de teste precisam de certos fatores ambientais – como
servidores, estruturas, hardware e software – para executar casos de teste desenvolvidos. Podemos resumir esta etapa
em três frases:
Liste o software e o hardware necessários para os diferentes níveis de desempenho;
Con�guração do ambiente de teste;
Entenda os requisitos mínimos.
Etapa 5 – Execução do teste: Uma vez que os casos de teste estão prontos e o ambiente de teste é de�nido,
executaremos os casos de teste um por um. Cada caso de teste terá um dos seguintes estados:
Aprovado: se o cenário em teste funcionar conforme o esperado;
Falha: se o funcionamento não for o esperado;
Ignorado: se o caso de teste não puder ser concluído. Pode ser devido a algumas limitações
ou circunstâncias imprevistas.
Etapa 6 – Encerramento do teste: Por �m, criamos um relatório de teste detalhado que incluirá informações
detalhadas sobre quantos defeitos ou bugs encontramos, quantos casos de teste precisam ser executados novamente,
quantos casos de teste falharam e quantos foram ignorados. Assim que consertarmos os bugs e defeitos, execute os
casos de teste que não puderam veri�car os bugs corrigidos.
produto �nal. Portanto, de�nir os critérios de entrada e saída é uma obrigação.
Podemos a�rmar que os critérios de entrada de�nem quais requisitos a equipe deve atender antes de iniciar o procedimento de teste.
Antes de começar o teste, é obrigatório riscar todos os requisitos.
Existem algumas atividades e condições em andamento que devem estar presentes antes do início do teste. Primeiro, você precisa da
opinião da equipe de desenvolvimento. Você também vai querer examinar o plano de teste, casos de teste e dados, o ambiente de teste e
seu código.
Por outro lado, os critérios de saída de�nem os requisitos e ações a serem concluídas antes do término do teste. Em outras palavras,
eles incluem itens a serem eliminados da lista de tarefas e processos a serem concluídos antes que o teste seja interrompido.
Os critérios de saída incluirão a identi�cação de defeitos de alta prioridade. Você precisará consertá-los imediatamente. Os testadores
precisam passar por diferentes casos de teste e garantir uma cobertura funcional completa.
Teste de Software Automatizado
O teste de software automatizado é um processo no qual uma ferramenta de automação é usada para executar casos de teste pré-
programados. O objetivo de automatizar um teste é o de simpli�car e aumentar a e�ciência no processo de teste.
Se uma forma especí�ca de teste consumir uma grande porcentagem de garantia de qualidade, pode ser um bom candidato para
automação. O teste de aceitação, o teste de integração e o teste funcional são todos adequados para esse tipo de TS. Um bom exemplo
para usar o teste de automação é na veri�cação dos processos de login.
Usar o teste automatizado é, sem dúvida, mais rápido do que o teste manual. Se você deseja acelerar o ciclo de vida de desenvolvimento
de software, pode ser um investimento que vale a pena. Em termos de execução de teste, aumentará a produtividade e reduzirá o tempo
de teste para a maioria dos aplicativos/sites. Mesmo que os custos de con�guração sejam altos, os testes automatizados podem
economizar dinheiro a longo prazo.
Tarefas repetitivas são ine�cientes quando feitas manualmente, especialmente quando ocorrem novamente. Também há uma chance
maior de erro humano. Os testes automatizados podem erradicar isso, dependendo da qualidade e do escopo dos casos de teste.
Embora o teste automatizado seja ótimo para tipos de teste, como teste de estresse e teste de fumaça, não é adequado para tudo. A
análise da interface do usuário, a documentação, a instalação, a compatibilidade e a recuperação costumam ser mais adequadas para
testes manuais. Mesmo se você optar por automatizar, alguma forma de teste manual será necessária.
Os custos de con�guração inicial (compra de ferramenta de automação, treinamento e tutoriais, manutenção de scripts de teste) são
caros. Além disso, se seu aplicativo ou site mudar regularmente, o custo e o tempo associados à manutenção do script aumentarão
consideravelmente.
A Tabela 3 a seguir, apresenta alguns tipos de testes que podem ser aplicados.
Tabela 3 – Tipos de Testes Manuais
Teste Descrição
Teste de API 
O teste de interfaces de programação de aplicativos (API) signi�ca
veri�car as APIs diretamente. Uma API é um recurso que permite que um
aplicativo interaja e se comunique com outros aplicativos. Ele determina
se as APIs atendem às expectativas de funcionalidade, con�abilidade,
desempenho e segurança. Isso não cobre usabilidade ou teste de interface
do usuário ou UX (User Experience ou Experiência do Usuário). O teste de API
envolve o envio de chamadas a uma API, o recebimento de uma saída e o
registro de uma resposta. 
Teste de Regressão
Automatizado 
Por natureza, o teste de regressão requer repetição constante. Pode ser
executado manualmente ou por meio de um método automatizado. O teste
de regressão deve sempre ser realizado depois que as falhas e bugs foram
corrigidos. Esse tipo de teste garante que as correções anteriores foram
adequadas e que não causaram mais problemas. 
Automatizar seus testes permite que as equipes saibam se seu software está quebrado em questão de segundos e minutos, em vez de
dias e semanas.
Pirâmide de Teste de Software: Uma Introdução a
Automação
Considere todos os tipos de aplicações com as quais você interage no dia a dia. Observe que o software se tornou uma parte essencial do
mundo onde vivemos. Para as empresas, o software as tornou mais digitais, facilitando seus negócios. Para os usuários comuns (você e
eu), o software facilita nossas vidas, trazendo soluções e agilidade para nossas tarefas cotidianas. As rodas da inovação estão girando
mais rápido.
Deste modo, é possível a�rmar que as rodas da inovação estão girando cada vez mais rápido e, com isso, você precisa encontrar
maneiras de entregar seu software com mais rapidez e, principalmente, sem sacri�car sua qualidade.
A entrega contínua, uma prática em que você garante automaticamente que seu software pode ser colocado em produção a qualquer
momento, pode ajudá-lo com isso. Com a entrega contínua, você usa um pipeline de construção para testar automaticamente seu
software e implantá-lo em seus ambientes de teste e produção.
Construir, testar e implantar uma quantidade cada vez maior de software manualmente logo se torna impossível – a menos que você
queira gastar todo o seu tempo com trabalho manual e repetitivo em vez de entregar software funcional (FOWLER, 2018). 
Sendo assim, a automatização de tudo, ou seja, da construção do software, passando pelos testes, implantação e gerenciamento da
infraestrutura, é o melhor caminho a seguir.
Do Teste Manual Para a Automação
Tradicionalmente, o TS era um trabalho excessivamente manual feito ao implantar seu aplicativo em um ambiente de teste e, em
seguida, realizar alguns testes do tipo caixa preta, por exemplo, clicando em sua interface de usuário para ver se algo está quebrado.
Frequentemente, esses testes são especi�cados por scripts de teste para garantir
que os testadores façam veri�cações consistentes
(FOWLER, 2018).
Agora, imagine testar cada alteração do software manualmente. Isso é um trabalho um tanto quanto demorado, repetitivo e tedioso.
Felizmente, existe um remédio para tarefas repetitivas: automação.
A escolha por automatizar os testes manuais repetitivos, trará uma grande mudança para a equipe de desenvolvimento e de testes, não
sendo mais necessário seguir os protocolos de clique para veri�car se o software ainda funciona corretamente ou não.
Pirâmide de Teste
Se você deseja levar a sério os testes automatizados de seu software, há um conceito-chave que você deve conhecer: a pirâmide de teste.
Mike Cohn propôs esse conceito em seu livro Succeeding with Agile. Trata-se de uma ótima metáfora visual que diz a você para pensar
sobre diferentes camadas de teste. Ele também informa quanto teste deve ser feito em cada camada (FOWLER, 2018). A Figura 1 nos
apresenta a pirâmide.
Figura 1 – Pirâmide de Testes 
Fonte: Adaptada de FOWLER, 2018
O nível inferior da pirâmide consiste em testes de unidade. Os testes de unidade são escritos por desenvolvedores e cobrem métodos e
comportamentos de funções, usando testes duplos para simular entradas, saídas e dependências externas.
Usando conceitos de código limpo, esses testes são fáceis de criar e manter. Dessa forma, todos os desenvolvedores podem executar
esses testes localmente e veri�car os impactos das alterações no código.
O nível médio consiste em testes de serviço para APIs e integrações gerais, esses testes cobrem a composição de unidades de código e
sua comunicação com o mundo externo (banco de dados, serviços web, entre outros).
O topo da pirâmide consiste em testes automatizados de UI, �uxos de usuários �nais em todo o sistema. Normalmente, esses testes são
lentos e difíceis de manter.
De modo geral, temos:
O conceito sempre pareceu um pouco simplista, mas a ideia principal ainda está viva e em um mundo de entrega contínua é mais
importante do que nunca, pois mesmo com esse conceito difundido, é muito comum ver testes automatizados escritos de forma errada.
Níveis, Técnicas e Tipos de Testes
Agora que você já compreendeu o que é um TS, bem como a relação entre testes automatizados e manuais, chegou a hora de
discutirmos os quatro níveis ou quatro tipos diferentes de testes, são eles: teste de unidade/componente, teste de integração, teste de
sistema e teste de aceitação.
Teste de Unidade/Componente
O tipo mais básico de teste é o teste de unidade ou componente. O objetivo do teste de unidade é de veri�car cada parte do software
isolando-o e, em seguida, realizar testes para demonstrar que cada componente individual está correto em termos de cumprimento dos
requisitos e da funcionalidade desejada.
Esse tipo de teste é executado nos estágios iniciais do processo de desenvolvimento e, em muitos casos, é executado pelos próprios
desenvolvedores antes de entregar o software à equipe de teste.
Testes separados com granularidade diferente;
Quanto mais alto nível você obtém, menos testes você deve ter.
Teste escrito em uma camada errada (Testes de UI, veri�cação de lógica de negócios), pode resultar em testes que
raramente são executados, pois demoram muito e muitas vezes falham devido a problemas que não estão relacionados
a algo importante para o usuário �nal;
Testes de unidade escritos apenas para cobertura e não para testar a lógica de negócios;
Testes de integração (serviço) que apenas veri�cam os resultados das APIs (entrada e saída) e não cobrem a
composição entre elas.
A vantagem de detectar quaisquer erros no software no início do dia é que, ao fazer isso a equipe minimiza os riscos de desenvolvimento
de software, bem como o tempo e o dinheiro desperdiçados em ter que voltar e desfazer problemas fundamentais no programa quando
ele estiver quase concluído.
Teste de Integração
O teste de integração visa testar diferentes partes do sistema em combinação, a �m de avaliar se funcionam corretamente em conjunto.
Ao testar as unidades em grupos, quaisquer falhas na maneira como elas interagem podem ser identi�cadas.
Existem muitas maneiras de testar como os diferentes componentes do sistema funcionam em sua interface; os testadores podem
adotar um método de integração ascendente ou descendente.
No teste de integração ascendente, o teste se baseia nos resultados do teste de unidade, testando combinações de unidades de nível
superior (chamadas de módulos) em cenários sucessivamente mais complexos.
Recomenda-se que os testadores comecem com essa abordagem primeiro, antes de aplicar a abordagem de cima para baixo, que testa
os módulos de nível superior primeiro e estuda os mais simples depois.
Teste de Sistema
Continuando em nossa análise, no próximo nível temos o teste do sistema que, como o nome indica, todos os componentes do software
são testados como um todo, garantindo assim que o produto geral atenda aos requisitos especi�cados.
O teste do sistema é uma etapa muito importante, pois o software está quase pronto para ser lançado e pode ser testado em um
ambiente semelhante ao que o usuário experimentará quando for implantado.
O teste de sistema permite que os testadores garantam que o produto atenda aos requisitos de negócios, bem como determinem se ele
funciona sem problemas em seu ambiente operacional. Esse tipo de teste é normalmente executado por uma equipe de teste
especializada.
Teste de Aceitação
Finalmente, o teste de aceitação é o nível no processo de TS em que um produto recebe luz verde ou não. O objetivo desse tipo de teste é
avaliar se o sistema atende aos requisitos do usuário �nal e se está pronto para implantação.
A equipe de teste utilizará uma variedade de métodos, como cenários pré-escritos e casos de teste para testar o software e usar os
resultados obtidos com essas ferramentas para encontrar maneiras de melhorar o sistema.
O escopo dos testes de aceitação vai desde a simples localização de erros ortográ�cos e cosméticos, até a descoberta de bugs que podem
causar um erro grave no aplicativo.
Ao realizar testes de aceitação, a equipe de teste pode descobrir como o produto será executado quando for instalado no sistema do
usuário. Existem também várias razões legais e contratuais pelas quais os testes de aceitação devem ser realizados.
Esses quatro tipos de teste não podem ser executados ao acaso durante o desenvolvimento. Há uma sequência lógica que deve ser
seguida para minimizar o risco de bugs surgirem pouco antes da data de lançamento.
Qualquer equipe de teste deve saber que o teste é importante em todas as fases do ciclo de desenvolvimento.
Testando progressivamente os componentes mais simples do sistema e avançando para os agrupamentos maiores e mais complexos,
os testadores podem ter a certeza de que estão examinando o software da maneira mais e�ciente possível.
Os quatro níveis de teste não devem ser vistos apenas como uma hierarquia que se estende do simples ao complexo, mas também como
uma sequência que abrange todo o processo de desenvolvimento, dos estágios iniciais aos posteriores. Análise com atenção o grá�co da
Figura 2.
Figura 2  Níveis de Teste 
 
Observe pela Figura 2 que mais tarde não signi�ca que o teste de aceitação seja feito somente após, digamos, 6 meses de trabalho de
desenvolvimento. Em uma abordagem mais ágil, o teste de aceitação pode ser realizado a cada 2-3 semanas, como parte da
demonstração do sprint (entregas). Em uma organização que trabalha de maneira mais tradicional, é bastante comum ter de 3 a 4
lançamentos por ano, cada um seguindo o ciclo descrito anteriormente.
Nesta aula você pode compreender o conceito de teste e sua importância no ciclo de vida do desenvolvimento de software. Pode
conhecer a de�nição de teste manual e teste automatizado, o qual é muito utilizado principalmente quando trabalhamos com
metodologias ágeis e DevOps. Por �m, pode conhecer os diferentes níveis de TS.
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
Livros  
Introdução ao Teste de Software 
No livro “Introdução ao Teste de Software”, os autores apresentam no capítulo 1 uma introdução aos conceitos básicos de teste de
software. Partindo da validação, veri�cação, fases e técnicas para o desenvolvimento de um teste. Trata-se de uma leitura indicada para
compreender, principalmente, as fases e critérios de um teste de software. 
DELAMARO, M.; MALDONADO, J.; JINO, M. Introdução ao Teste de Software. São Paulo: Elsevier. 2007
Engenharia de Software Moderna 
No livro “Engenharia de software moderna”, o autor dedica o capítulo 8 para falar sobre os principais conceitos de testes de software,
apresentando inclusive um modelo adaptado de pirâmide de teste, bem como exemplos. Trata-se de uma leitura indicada para quem
deseja se aprofundar nos conceitos sobre teste de software. 
VALENTE, M. Engenharia de Software Moderna. Editora independente. 2020.
Teste de Software 
No livro “Testes de Software”, o autor apresenta no capítulo 1 uma introdução ao conceito de testes e, em seguida, no capítulo 2, ele
mostra uma visão geral sobre os processos de testes de software. Trata-se de uma literatura recomendada para iniciantes e para
usuários intermediários. 
RIOS, E. Teste de Software. Rio de Janeiro: Alta books. 2013. 
  Leitura  
Estudo e Implementação de Testes de Software em Desenvolvimento Ágil 
Na dissertação intitulada “Estudo e Implementação de Testes de Software em Desenvolvimento Ágil”, o autor apresenta a importância
dos testes de software bem como sua aplicação no desenvolvimento ágil de software. Nos estudos, ele considerou três testes diferentes
de software, os quais merecem atenção especial por parte do aluno, contribuindo vastamente com sua formação.
2 / 3
 Material Complementar
Clique no botão para conferir o conteúdo.
ACESSE
https://bit.ly/3xrSkfh
BRAGA, P. H. C. Teste de Software. São Paulo: Pearson Education do Brasil, 2016. (e-book)
DELAMARO, M. E.; MALDONADO, J. C.; JINO, M. Introdução ao teste de Software. Rio de Janeiro: Elsevier, 2016. (e-book)
FERRONI, M. Erro da Nasa Pode ter Destruído Sonda. 1999. Disponível em:
<https://www1.folha.uol.com.br/fsp/ciencia/fe0110199905.htm>. Acesso em: 01/10/2021.
FERREIRA, V. Apocalipse ou Enganação: o que foi o Bug do Milênio? 2017. Disponível em:
<https://www.uol.com.br/tilt/noticias/redacao/2017/08/20/apocalipse-ou-enganacao-o-que-foi-o-bug-do-milenio.htm>. Acesso em:
01/10/2021.
FOWLER, M. The Practical Test Pyramid. Disponível em: <https://martinfowler.com/articles/practical-test-pyramid.html>. Acesso em:
01/10/2021.
VALENTE, M. T. Engenharia de Software Moderna: princípios e práticas para desenvolvimento de software com produtividade.
Disponível em: <https://engsoftmoderna.info/>. Acesso em: 04/05/2021.
3 / 3
 Referências