Teste de software 4

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

Conteudista: Prof. Me. Ariel da Silva Dias
Revisão Textual: Prof.ª M.ª Sandra Regina Fonseca Moreira
 
Objetivos da Unidade:
Compreender as medidas e critérios adotados para teste de
software automatizado;
Reconhecer as principais ferramentas de cobertura de teste;
Compreender o princípio FIRST.
QUESTION B AN KS
 Material Teórico
 Material Complementar
 Referências
Cobertura de Testes Automatizados
Principais Testes Automatizados e Ferramentas
A qualidade do produto é da maior importância em uma indústria B2B (business-to-business,
trata-se de uma forma de transação entre empresas, como uma que desenvolve software e um
atacadista, por exemplo). As organizações buscam sempre uma entrega oportuna e
econômica. Para alcançar a gestão da qualidade e do tempo em um mercado de
desenvolvimento de software, há um conjunto de etapas que devem ser seguidas. No entanto, a
etapa mais importante de todo o ciclo é o teste contínuo e vigoroso antes e durante o
desenvolvimento. Este método de desenvolvimento orientado a testes permite que as equipes
realizem etapas menores com precisão. 
Os recursos em um produto de software são implementados com base nos requisitos
mencionados na Especi�cação de Requisitos do Cliente, Especi�cação de Requisitos de
Software e Especi�cação de Requisitos Funcionais. Uma vez que os recursos documentados
são implementados, o código de teste deve ser escrito para veri�car se tais recursos foram
realmente desenvolvidos.
Para cada ciclo de teste realizado existem várias estratégias que conduzem o sistema a
resultados prováveis. Portanto, a cobertura do teste é administrada para maximizar os termos
do teste.
Ao medir a qualidade dos ciclos de teste realizados pelas equipes durante a entrega do
software, o processo completo é chamado de cobertura de teste. 
Em outras palavras, quando se trata de qualidade de software, queremos testar o máximo de
código humanamente (ou mecanicamente) possível, certo? Na verdade, sim e não. Para cada
1 / 3
 Material Teórico
ciclo de teste é importante considerar várias estratégias para medir a cobertura do teste e
colocar um sistema em funcionamento onde ele também possa ser maximizado a longo prazo
(CANDIDO, 2019).
O teste abrange diferentes tipos de metodologias de teste, como teste de usabilidade, teste
responsivo, teste entre navegadores e muito mais. A cobertura do teste é calculada com base
no número de recursos cobertos pelo código de teste.
Por exemplo, você recebe a tarefa de escrever testes para veri�car uma página de login. A
cobertura do teste deve veri�car as diferentes condições que podem ser encontradas em uma
página de login, ou seja, login bem-sucedido, login malsucedido, nome de usuário/senha em
branco, entre outras condições, a�nal, quanto mais recursos cobertos, melhor é a cobertura
do teste.
A cobertura do teste é uma das medidas da qualidade do teste que nos informa quanto do
aplicativo em teste foi testado. Você pode pensar nisso como varrer o chão de uma casa.
Imagine se você incluísse apenas a varredura dos quartos para seus critérios de cobertura de
varredura. Com esse critério, se você varresse 100% dos quartos, isso signi�caria que toda a
casa está limpa? Não, porque você deixou de lado a cozinha, a sala de jantar, banheiros, entre
outros. Portanto, devemos sempre ter cuidado com a cobertura de teste e reconhecer que, às
vezes, ela tem suas limitações.
A cobertura de teste é útil para de�nir certas partes do software a �m de cobri-las com testes.
Também nos informa quando testamos o su�ciente, nos dá ideias sobre o que mais testar
(expandindo assim a cobertura) e nos ajuda a saber quantitativamente a extensão de nossos
testes. Trata-se de uma ótima medida, mas mesmo com 100% de cobertura de teste, não
temos garantia de que nosso aplicativo seja 100% livre de bugs.
Mesmo que você consiga atingir apenas 20% de cobertura, pode não ser necessariamente uma
coisa ruim. A quantidade ideal de cobertura de teste a ser atingida deve ser baseada em suas
prioridades e análise de risco.
Existem muitas maneiras de considerar a cobertura de teste. Aqui, examinaremos a cobertura
de código, a cobertura orientada a dados e a abundância de outras técnicas à disposição do
testador (CANDIDO, 2019).
Cobertura de Código
A cobertura de código é a métrica mais popular para medir a cobertura de teste. Ela mede o
número de linhas cobertas pelos casos de teste, relatando o número total de linhas no código
e o número de linhas executadas pelos testes. Essencialmente, é o grau em que o código-
fonte de um programa é executado quando um conjunto de testes é executado (CANDIDO,
2019). Quanto mais cobertura de código, menor a chance de bugs não detectados chegarem à
produção. Essa medição também pode ser dividida em diferentes níveis; não apenas linhas de
código cobertas, mas também existem rami�cações, decisões dentro de construtores lógicos,
entre outros.
Figura 1 – Cobertura de código
Fonte: Freepik
A cobertura de código vem sob o teste de caixa branca, onde o programa não executado por
um conjunto de casos é relatado e o sistema coleta informações relevantes do programa em
execução.
A cobertura é ainda dividida em muitos subtipos: cobertura de função, cobertura de
rami�cação, cobertura de condição, cobertura de loop, cobertura de instrução e cobertura de
valor de parâmetro.
Por exemplo, suponha que um código tenha uma estrutura if ... else. A cobertura do código
será de 100% se a lógica implementada sob if e else for coberta (ou atravessada) pelo código de
teste. Por outro lado, a cobertura será de 50% se a lógica sob if (ou else) for coberta pelo
código de teste.
Código não testado pode resultar em problemas de qualidade. Portanto, é importante
maximizar a cobertura do código com 100%, considerado como a cobertura ideal.
Algumas considerações:
No caso ideal, para a cobertura da condição ser 100%, todas as condições com todas as
combinações possíveis de parâmetros de condição são testadas. A cobertura do valor do
parâmetro é veri�cada passando todos os valores comuns para os parâmetros na chamada de
função.
Formas de Cobertura de Código
Os testes de unidade são ótimos e funcionam bem para testar os recursos do produto em nível
de unidade (ou módulo). No entanto, a cobertura do código será calculada com base nos testes
Se os testes cobrirem todas as chamadas de função em código, a cobertura da
função é considerada 100%;
Da mesma forma, se todas as rami�cações no código, ou seja, todas as condições
if - else forem testadas com todas as entradas possíveis, então a cobertura da
rami�cação é considerada 100%;
Se todas as instruções de loop no código forem executadas, a cobertura de loop e a
cobertura de instrução serão 100%, respectivamente.
usados para veri�car essa unidade de código. Para melhorar a cobertura do código do ponto
de vista do produto, torna-se essencial solidi�car os conjuntos de teste que contêm cenários
de teste para veri�car diferentes módulos no produto (CANDIDO, 2019).
Isso é possível se as suítes de teste têm testes que veri�cam cada parte do código
implementado em detalhes. Isso ajuda a melhorar a cobertura do código, o que por sua vez
ajuda a melhorar a qualidade do código.
Resumindo, quanto maior a cobertura do código, menores são as chances de os clientes
encontrarem bugs em seu produto.
Cobertura Orientada a Dados
Com a cobertura orientada a dados você tem parâmetros de entrada e saída, cada um deles
com seu próprio domínio (o espectro de valores possíveis que eles podem ter). Se você pensar
em todas as possibilidades, acabará com um produto cartesiano porque pode testar todas as
combinações possíveis.
Cobertura funcional: a cobertura é calculada em uma função (ou nível de API). As
funções devem ser testadas contra diferentes combinações de entrada, incluindo
aquelas que cobrem as condições de nível de limite;
Cobertura de linha (ou instrução): esse tipo de cobertura é calculado com base
nos testes que cobrem instruções
executáveis no código;
Cobertura condicional: testa se diferentes instruções condicionais no código são
cobertas usando o código de teste relevante. Exemplo – Teste criado para veri�car
uma instrução switch ... case deve percorrer todas as condições implementadas sob
switch e case;
Cobertura de Loop: esta cobertura garante que todos os loops implementados no
código sejam testados pelo menos uma vez. Os loops que são acionados usando
valores de tempo de execução também devem ser testados quanto à cobertura do
loop.
Por outro lado, você pode testar menos e ir com a cobertura de cada escolha, o que signi�ca
que você escolhe em cada valor possível pelo menos uma vez. Há também todos os pares, que
empiricamente se diz ter a melhor relação custo-benefício, sendo o melhor mix entre cada
escolha e todas as combinações.
Outros Tipos de Cobertura
Existem muitas outras maneiras de cobrir os produtos de teste que usam uma teoria comum
– a “teoria do erro”, que explica os erros típicos que os programadores podem cometer.
Poucos estão listados abaixo: 
Algo muito importante de observar é que cada técnica é suportada por uma teoria do erro. A
teoria do erro leva em consideração os erros típicos que os programadores cometem. Por
Tabelas de decisão: onde as regras de negócios ou colunas da tabela de decisão
são testadas;
Valor Limite: é uma técnica de design de teste de caixa preta, que é usada para
encontrar os erros nos limites do domínio de entrada (testa o comportamento de
um programa nos limites de entrada), em vez de encontrar esses erros no centro
da entrada. Portanto, a ideia básica no teste de valor limite é selecionar os valores
das variáveis de entrada em seus: mínimo, logo acima do mínimo, logo abaixo do
mínimo, um valor nominal, logo abaixo do máximo, máximo e logo acima do
máximo. Ou seja, para cada intervalo, existem dois limites, o limite inferior (início
do intervalo) e o limite superior (�nal do intervalo), e os limites são o início e o
�m de cada partição válida. Devemos projetar casos de teste que exercitem a
funcionalidade do programa nos limites e com valores dentro e fora dos limites.
Considerando um conjunto de valores entre A e B, então projete casos de teste
para A, A + 1, A-1 e B, B + 1, B-1.  Por exemplo, suponha que um campo de texto
chamado idade deve aceitar apenas valores entre 18 e 56. Logo, um conjunto de
valores projetados para o teste são: 17, 18, 19 e 55, 56, 57;
Transição de estado: pode incluir a porcentagem de estados visitados, a
porcentagem de pares de transições válidas exercidas ou a porcentagem de
transições inválidas exercidas (da tabela de estado).
exemplo, os valores de limite consideram o erro de usar um “<” em vez de um “<=”.
Além disso, existem outros tipos de cobertura de teste que não estão relacionados a linhas de
código ou à entrada de dados de teste. Uma coisa que devemos cobrir é a fragmentação móvel
fazendo uma pergunta: estamos cobrindo os principais dispositivos móveis, sistemas
operacionais e tamanhos de tela? Quando se trata de navegadores e sistemas operacionais,
devemos considerar como nosso sistema web se comportará em qualquer combinação de
sistemas operacionais e navegadores, e quantas combinações devemos testar. Também é
necessário considerar o ambiente de teste, contexto, entre outros fatores que implicam na
execução da aplicação.
Cobertura de Código e Cobertura de Teste
A cobertura do código é a medida do grau em que o código do software foi executado. Ele cobre
testes automatizados e manuais e fornece a porcentagem de código que foi executado. Com
base nessas informações, você pode implementar testes adicionais para o produto e torná-lo
muito mais abrangente.
A principal diferença entre a cobertura de teste e a cobertura de código é que, embora a
cobertura de teste seja uma medida qualitativa, a cobertura de código é mais sobre medida
quantitativa em termos de teste. 
A cobertura de código ajuda a determinar quanto do código é executado enquanto o aplicativo
está em execução, por sua vez, a cobertura de teste é útil para descrever casos de teste que
podem ser escritos em relação ao documento de requisitos.
Análise de Código: Estática e Dinâmica
Vamos começar com uma analogia esportiva para ajudar a ilustrar a diferença entre essas duas
metodologias. 
Considere, por exemplo, que você é um goleiro e está treinando cobrança de pênaltis. Em um
primeiro caso, existe uma máquina que arremessa a bola, mecanicamente, sempre na mesma
posição programada por você. O primeiro arremesso pode lhe surpreender, mas o restante
(como são todos no mesmo local), incorre em surpresas mínimas. Bem, a análise de código
estático é semelhante a praticar pênalti com uma máquina de arremesso. Depois de algumas
defesas, você sabe exatamente onde a bola vai estar todas as vezes. Isso ajuda a trabalhar os
fundamentos e a garantir que você tenha uma boa forma. Embora isso ajude a melhorar seu
jogo, só pode levar você até certo ponto.
A análise de código estático é um método de depuração feito examinando-se o código-fonte
de um aplicativo antes que um programa seja executado. Isso geralmente é feito analisando o
código em relação a um determinado conjunto de regras ou padrões de codi�cação.
Ainda neste exemplo, considere que você deixou a máquina de lado e agora quem está te
treinando é o preparador de goleiros, um humano. A análise dinâmica de código é como
praticar seu treino contra uma pessoa ou um jogador real, com variação nos tipos, forças e
localizações de cada chute. Ele testa não apenas seus fundamentos, mas sua capacidade de
reagir a situações diferentes e inesperadas. 
A análise dinâmica de código é o método de depuração que examina um aplicativo durante ou
após a execução de um programa. Uma vez que o código-fonte pode ser executado com uma
variedade de entradas diferentes, não existe um determinado conjunto de regras que possa
abranger esse estilo.
Métricas e Ferramentas de Cobertura
As métricas de cobertura de teste medem o esforço do teste e ajudam a responder pergunta
como: "Quanto do aplicativo foi testado?". As métricas de cobertura de teste podem ser
divididas em três partes: métricas de nível de código, métricas de teste de recursos e métricas
de nível de aplicativo. Existem várias fórmulas de cobertura de teste para calcular esses
resultados e gerar relatórios de cobertura de teste. Por exemplo, “Destes testes que estão
passando ou falhando, quais são os artefatos ou área de minha aplicação que são projetados
para garantir que meus produtos sejam produzidos em alta qualidade?”. Abaixo estão 5
principais métricas de cobertura de teste.
Métricas de Nível de Código
A primeira métrica é a porcentagem de cobertura de execução de teste, trata-se da
porcentagem de testes aprovados ou executados em relação ao número total de testes.
Observe a fórmula a seguir:
Onde:
A vantagem é que você obtém uma visão geral do progresso do teste, contando o número de
testes aprovados e reprovados.
A desvantagem é que a contagem dos casos de teste aprovados não diz nada sobre a qualidade
desses testes. Por exemplo, alguns testes podem ser aprovados porque veri�ca-se a condição
trivial ou algum erro no código de teste enquanto não está funcionando de acordo com o
requisito.
Métricas de Nível de Recursos
TE: Testes executados ou porcentagem de cobertura de execução de teste;
NTE: Número de testes executados;
NTTE: Número total de testes a serem executados.
Existem duas principais métricas de nível de recurso: a cobertura de requisitos e os casos de
teste pelo requisito.
A cobertura de requisitos é usada para determinar quão bem os casos de teste cobrem os
requisitos de software. Para isso, basta dividir o número de requisitos cobertos pelo número
total de requisitos com escopo para um sprint, release ou projeto.
Onde:
A cobertura de teste avalia o impacto de uma mudança no teste ou requisito. Em vez de cobrir
cada requisito apenas no nível do teste, você pode cobrir
um requisito por meio de
con�gurações de teste. Uma con�guração de teste representa um caso de uso especí�co de
um teste. Cobrir con�gurações de teste com requisitos fornece granularidade mais �na,
abrangendo vários casos de uso.
No entanto, certos processos são mais adequados para automação do que outros. Existem
sinais indicadores a serem observados, os quais indicam que um processo está preparado para
a automação, conforme podemos ver a seguir.
Os benefícios da automação são bem documentados; aumenta a produtividade, reduz custos e
minimiza erros. Elimina tarefas manuais repetitivas, liberando-nos para sermos mais
CR: Cobertura de requisitos;
NRC: Número de requisitos cobertos;
NTR: Número total de requisitos.
inovadores. Por essa lógica, com certeza, devemos automatizar tudo o que for possível, certo?
Então, tentar automatizar tudo é uma meta sensata – até mesmo viável? Em uma palavra: não.
Se os processos são de baixo volume, requerem poucas pessoas no seu desenvolvimento, não
têm prazo, não se conectam com outros sistemas e não precisam de transparência, aplicar a
automação pode ser uma perda de tempo e um investimento perdido, pois demoraria muito
para ver qualquer ROI (retorno sobre o investimento) nesses itens de �uxo de trabalho.
Os casos de teste pelo requisito são usados para ver quais recursos estão sendo testados e o
número de testes alinhados a um requisito (Tabela 1). A maioria dos requisitos contém vários
casos de teste. É muito importante saber quais casos de teste falharam para um requisito
especí�co para reescrever os casos de teste para requisitos especí�cos.
Tabela 1 – Casos de Teste
Requisitos Caso a testar Resultado
Requisito 1 Caso de teste 1 Passou
Requisito 2 Caso de teste 2 Falhou
Requisito 3 Caso de teste 3 Incompleto 
Essa métrica é muito importante para as partes interessadas (stakeholders), pois mostra o
andamento do desenvolvimento do aplicativo/software.
Métricas de Nível de Aplicativo
Existem duas principais métricas de nível de aplicativo: o teste sem cobertura de requisitos e a
métrica de densidade de defeitos.
A densidade de defeito é uma medida do total de defeitos conhecidos, dividida pelo tamanho
da entidade de software que está sendo medida. Observe a fórmula a seguir.
Onde:
Nesta métrica é importante considerar a prioridade do defeito (baixa ou alta) ao avaliá-los. Por
exemplo, vários defeitos de baixa prioridade podem ser aprovados porque os critérios de
aceitação foram satisfeitos. Por outro lado, apenas um defeito de alta prioridade pode impedir
que os critérios de aceitação sejam satisfeitos. Defeitos de prioridade alta geralmente são
ponderados mais fortemente como parte dessa métrica.
Depois de calcular a cobertura de requisitos, você encontrará alguns requisitos que não são
cobertos. Agora, é importante saber sobre cada requisito que não foi coberto e em que estágio
o requisito se encontra.
Tabela 1 – Nome da Tabela
DD: densidade de defeito;
NRC: número de defeitos conhecidos;
NTR: tamanho da entidade de software. 
É usada para identi�car as áreas que requerem automação. Se a densidade do
defeito for alta para a funcionalidade especí�ca, será necessário um novo teste.
Para reduzir os esforços de reteste, casos de teste para defeitos conhecidos podem
ser automatizados.
Requisitos Nome do requisito Status
Requisito 1 Requisito A A fazer
Requisito 2 Requisito B Feito
Essa métrica ajuda os engenheiros de teste e desenvolvedores a identi�carem e eliminarem os
requisitos não cobertos dos requisitos totais antes de enviá-los para a fase de produção.
Limitações e Benefícios dos Testes
Automatizados
Feita estas considerações, é importante destacar que realizar testes 100% automatizados é
muito difícil. Por natureza, os testes automatizados são limitados aos casos de teste que são
escritos para eles. Eles não são capazes de testar nenhum bug fora desse escopo.
Um software em um ponto de venda (PDV) ou uma máquina registradora em um
supermercado podem possuir uma e�ciência de tempo. Mas quando necessitam de um
humano para intervir e tomar uma decisão, por exemplo, para veri�car se um cliente está
acima da idade legal para beber, eles perdem um de seus principais benefícios.
Somado a isso, a implementação e manutenção contínua da automação exigem um
investimento signi�cativo de tempo e dinheiro.
Um equívoco comum sobre automação é que ela elimina completamente o elemento humano.
Mas quem escreve os casos de teste ou scripts? O teste automatizado requer intervenção
humana para funcionar. É por isso que qualquer estratégia de teste de software deve ter uma
abordagem integrada.
Os desenvolvedores e testadores internos nem sempre criam os melhores casos de teste. Isso
é ainda mais verdadeiro para áreas menos comuns de um aplicativo que são mais difíceis de
automatizar – por exemplo, ter um testador interagindo pessoalmente com um aplicativo na
localização geográ�ca em que você deseja testar.
Isso também vale para casos de teste que são executados várias vezes. Novos bugs podem ser
introduzidos em seu aplicativo após cada melhoria ou correção do produto. Os casos de teste
em automação tornam-se ine�cazes sem a intervenção humana contínua.
Princípios FIRST
Em qualquer aplicação que resolve problemas do mundo real, ter problemas em seus testes de
unidade é a coisa menos desejável. Os bons testes escritos são ativos, enquanto os testes mal
escritos são um fardo para a sua aplicação. 
Ao escrever testes de unidade, os desenvolvedores tentam seguir o princípio FIRST tanto
quanto possível, o qual é uma combinação de vários princípios (RAHMAN, 2019).
Fast (Rápido)
A primeira letra do princípio FIRST signi�ca – Fast ou Rápido. Os testes de unidade são
pequenos pedaços de código que executam uma tarefa especí�ca. Os testes de unidade são
pequenos e, ao contrário dos testes de integração, os testes de unidade não se comunicam
pela rede e não executam operações de banco de dados. Como os testes de unidade não se
comunicam com servidores ou bancos de dados remotos, eles são executados muito
rapidamente. Os desenvolvedores que praticam o desenvolvimento orientado a testes,
executam testes de unidade com muita frequência à medida em que implementam recursos do
aplicativo (RAHMAN, 2019).
Uma das principais causas de testes lentos é a dependência que deve lidar com necessidades
malignas externas, como bancos de dados, arquivos e chamadas de rede. Eles levam milhares
de milissegundos. Portanto, para tornar a suíte mais rápida, você deve evitar a criação dessas
dependências, usando testes de simulação.
Independent (Independente)
A próxima letra no princípio FIRST signi�ca – Independente. Os testes de unidade devem ser
independentes uns dos outros. Um teste de unidade não deve depender do resultado
produzido por outro teste de unidade. Na verdade, na maioria das vezes, os testes de unidade
são executados em uma ordem aleatória. O código que você está testando ou o sistema em
teste também deve ser isolado de suas dependências. Para garantir que o bug em uma
dependência não in�uencie em um teste de unidade, as dependências geralmente são
simuladas ou fragmentadas com dados prede�nidos. Dessa forma, um teste de unidade pode
testar um sistema em teste isolado de suas dependências e produzir um resultado preciso
(RAHMAN, 2019).
Fazendo testes independentes é fácil manter seus testes focados apenas em uma pequena
quantidade de comportamento. Quando esse teste falha, você sabe exatamente o que deu
errado e onde. Não há necessidade de depurar o próprio código.
Se lá em orientação a objetos as classes são de�nidas como unidades que devem ser pequenas
e de �nalidade única, isso também pode ser aplicado aos seus testes. Se um de seus métodos
de teste pode falhar por mais de um motivo, considere dividi-lo em testes separados.
Repeatable (Repetível)
A próxima letra no princípio FIRST signi�ca – Repetível. Um teste de unidade deve ser repetido
e, se executado várias vezes,
deve produzir o mesmo resultado. Se um teste de unidade for
executado em um computador diferente, também deverá produzir o mesmo resultado. É por
isso que os testes de unidade são feitos independentemente do ambiente e de outros testes de
unidade (RAHMAN, 2019).
Os parâmetros de entrada que a função em teste requer são geralmente prede�nidos e
codi�cados. E se a função no teste precisar ser testada com parâmetros de entrada válidos e
inválidos, dois ou três testes de unidade diferentes serão criados. Cada teste de unidade testa a
função nos testes com seu próprio conjunto de parâmetros prede�nidos. Dessa forma, o teste
de unidade se torna repetível e pode ser executado várias vezes em ambientes diferentes e
ainda produzirá o mesmo resultado a cada vez que for executado.
Self-Validating (Auto-Validação)
A próxima letra signi�ca Auto-validação. Isso signi�ca que para saber se um teste de unidade
foi aprovado ou não, o desenvolvedor não deve fazer nenhuma veri�cação manual adicional
após a conclusão do teste (RAHMAN, 2019). 
O teste de unidade validará o resultado que a função em teste produziu, e ele próprio decidirá
se passa ou falha. Após a conclusão do teste, o resultado será claro.
Timely (Imediatamente e Completo)
Praticamente, você pode escrever testes de unidade a qualquer momento. Você pode esperar
até que o código esteja pronto para a produção, ou é melhor se concentrar em escrever testes
de unidade em tempo hábil (RAHMAN, 2019).
Como sugestão, você deve ter diretrizes ou regras rígidas sobre os testes de unidade. Você
pode usar processos de revisão, ou mesmo ferramentas automatizadas para rejeitar código
sem testes su�cientes.
Quanto mais você testa a unidade, mais você descobrirá que vale a pena escrever pedaços
menores de código antes de realizar um teste de unidade correspondente. Em primeiro lugar,
será mais fácil escrever o teste e, em segundo lugar, o teste será recompensado
imediatamente quando você detalhar o resto dos comportamentos no código circundante.
Nesta unidade, você pôde compreender o conceito de cobertura de teste. Como apresentado,
atualmente o desenvolvimento de software é mais sistemático e as organizações buscam
medidas de integridade e e�cácia do teste para mostrar os critérios de conclusão. De todos
eles, a cobertura de teste é considerada especialmente valiosa. 
Você também conheceu um pouco mais sobre as métricas de cobertura de testes e, por �m,
pôde compreender o conceito dos princípios FIRST.
Indicações para saber mais sobre os assuntos abordados
nesta Unidade:
  Livros  
Teste de Software 
No capítulo 11 do livro “Testes de Software”, o autor apresenta uma extensa e importante
descrição das características e conceitos relacionados ao teste em aplicações web para
internet. Trata-se de uma literatura recomendada para iniciantes e também para usuários
intermediários. 
RIOS, E. Teste de Software. Rio de Janeiro: Alta books, 2013, p. 179.
Introdução ao Teste de Software 
No capítulo 8 do livro “Introdução ao Teste de Software”, os autores apresentam uma
introdução aos conceitos de testes para aplicações web. Partindo do teste estrutural, bem
como teste baseado em modelos de especi�cação e apresentação de ferramentas. 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
2 / 3
 Material Complementar
Engenharia de Software Moderna 
No livro “Engenharia de software moderna”, o autor dedica o capítulo 8 para falar sobre testes,
explicando a de�nição de teste de integração e teste de unidade, além de abordar os testes
automatizados. 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.
  Leitura  
Um Pouco Sobre Cobertura de Código e Cobertura de Testes 
No artigo “Um pouco sobre cobertura de código e cobertura de testes”, o autor relaciona e
diferencia estes dois tipos de coberturas, apresentando exemplos durante sua descrição. O
autor prende a atenção ao destacar detalhes importantes dos testes automatizados, bem como
cita bons exemplos.
Clique no botão ao lado para conferir o conteúdo.
ACESSE
https://medium.com/liferay-engineering-brazil/um-pouco-sobre-cobertura-de-c%C3%B3digo-e-cobertura-de-testes-4fd062e91007/
BRAGA, P. H. C. (org.). Teste de Software. São Paulo: Pearson Education do Brasil, 2016. (e-
book)
CANDIDO, A. Um pouco sobre cobertura de código e cobertura de testes. 2019. Disponível em:
<https://medium.com/liferay-engineering-brazil/um-pouco-sobre-cobertura-de-
c%C3%B3digo-e-cobertura-de-testes-4fd062e91007/>. Acesso em: 20/11/2021.
DELAMARO, M. E.; MALDONADO, J. C.; JINO, M. Introdução ao teste de software. Rio de
Janeiro: Elsevier, 2016. (e-book)
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.
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.
FOWLER, M. The Practical Test Pyramid. Disponível em:
<https://martinfowler.com/articles/practical-test-pyramid.html>. Acesso em: 01/10/2021.
MCGOVERN, G. O que é teste de automação. Disponível em:
<https://www.guru99.com/automation-testing.html>. Acesso em: 20/10/2021. 
RAHMAN, T. FIRST: Princípios de teste. 2019. Disponível em:
<https://medium.com/@tasdikrahman/f-i-r-s-t-principles-of-testing-1a497acda8d6>.
3 / 3
 Referências
Acesso em: 20/11/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.