Teste de software 5

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

Conteudista: Prof. Me. Ariel da Silva Dias
Revisão Textual: Prof.ª Dra. Luciene Oliveira da Costa Granadeiro
 
Objetivos da Unidade:
Compreender o conceito de testes funcionais;
Reconhecer as principais ferramentas de testes funcionais;
Aplicar testes de software utilizando a ferramenta Selenium.
 Material Teórico
 Material Complementar
 Referências
Testes Funcionais
Apresentando o Conceito de Testes Funcionais
O teste funcional é o processo pelo qual os QAs (Quality Assurance ou Garantia de Qualidade)
determinam se uma parte do software está agindo de acordo com os requisitos pré-
determinados. Ele usa técnicas de teste de caixa preta, nas quais o testador não tem
conhecimento da lógica interna do sistema. O teste funcional se preocupa apenas em validar
se um sistema funciona como planejado, ou seja, se ele tem um comportamento aceitável ou
não. 
O teste de caixa preta é de�nido como uma técnica de teste na qual a funcionalidade do
aplicativo é testada sem examinar a estrutura interna do código, os detalhes da
implementação e o conhecimento dos caminhos internos do software. Esse tipo de teste é
baseado inteiramente nos requisitos e especi�cações do sistema. No teste de caixa preta,
focamos apenas nas entradas e saídas do sistema de software sem nos preocuparmos com o
conhecimento interno do programa, como ilustrado na Figura 1.
Figura 1 – Estrutura de um teste de caixa preta
A caixa preta da Figura 1 pode ser qualquer sistema de software que você deseja testando. Por
exemplo, um sistema operacional como o Windows, um site como o Google, um banco de dados
1 / 3
 Material Teórico
como o Oracle ou até seu próprio aplicativo personalizado. No teste de caixa preta, você pode
testar esses aplicativos apenas concentrando-se nas entradas e saídas sem conhecer sua
implementação de código interno.
Aqui estão as etapas genéricas seguidas para realizar qualquer tipo de teste de caixa preta:
Deve haver algo que de�na o que é um comportamento aceitável e o que não é. Isso é de�nido
em uma especi�cação funcional ou de requisito. Trata-se de um documento que descreve o
que um usuário tem permissão para fazer, para que ele possa determinar a conformidade do
aplicativo ou sistema com ele. Além disso, às vezes, isso também pode implicar que os
cenários reais do lado do negócio sejam validados.
Portanto, o teste de funcionalidade pode ser realizado por meio de duas técnicas populares:
Etapa 1: Inicialmente, os requisitos e especi�cações do sistema são examinados;
Etapa 2: O testador escolhe entradas válidas (cenário de teste positivo) para
veri�car se o sistema as processa corretamente. Além disso, algumas entradas
inválidas (cenário de teste negativo) são escolhidas para veri�car se o sistema é
capaz de detectá-las;
Etapa 3: O testador determina as saídas esperadas para todas essas entradas;
Etapa 4: O testador de software constrói casos de teste com as entradas
selecionadas;
Etapa 5: Os casos de teste são executados;
Etapa 6: O testador de software compara as saídas reais com as saídas esperadas;
Etapa 7: Se ocorrer algum bug ou defeito, ele será corrigido e testado novamente.
Teste com base em requisitos: Contém todas as especi�cações funcionais que
formam a base para todos os testes a serem realizados;
Os testes e a garantia de qualidade são uma grande parte do processo SDLC (Software
Development Life Cycle ou Ciclo de Vida de Desenvolvimento de Sistemas). Como testadores,
precisamos estar cientes de todos os tipos de teste, mesmo que não estejamos diretamente
envolvidos com eles diariamente.
Como o teste é um leque muito amplo, seu escopo é muito vasto, e temos testadores dedicados
que realizam diferentes tipos de teste. Provavelmente, todos nós devemos estar familiarizados
com a maioria dos conceitos, mas não fará mal organizar tudo aqui.
A Figura 2, a seguir, apresenta uma hierarquia em tabela dos tipos de testes funcionais.
Figura 2 – Tipos de testes funcionais
Teste com base em cenários de negócios: Contém as informações sobre como o
sistema será percebido a partir de uma perspectiva de processos de negócios.
A partir da Figura 2, observe a descrição de cada um dos tipos de testes a seguir.
Teste de Unidade
O teste de unidade geralmente é realizado por um desenvolvedor que escreve unidades de
código diferentes que podem estar relacionadas ou não para atingir uma funcionalidade
especí�ca. Isso geralmente envolve escrever testes de unidade que chamariam os métodos em
cada unidade e os validariam quando os parâmetros exigidos fossem passados e seu valor de
retorno fosse o esperado. 
A cobertura do código é uma parte importante do teste de unidade, onde os casos de teste
precisam existir para cobrir os três abaixo:
Teste de Sanidade
O objetivo principal deste teste é determinar se as alterações ou a funcionalidade proposta
estão funcionando conforme o esperado. Se o teste de sanidade falhar, a construção é
rejeitada pela equipe de teste para economizar tempo e dinheiro. É executado somente após a
construção ter passado no teste de fumaça e ser aceita pela equipe de garantia de qualidade
para testes adicionais. O foco da equipe durante este processo de teste é validar a
funcionalidade do aplicativo e não o teste detalhado.
Nesse ponto, é importante adicionar que o teste de sanidade geralmente é feito no �nal de um
ciclo de teste de software em que a construção do software é estável. Por esse motivo, essa
forma de teste costuma ser improvisada. É executado para veri�car se a funcionalidade foi
corrigida onde havia erros anteriores. Portanto, não é uma forma ampla de teste que requer
documentação intensiva. Porém, possui três etapas bem de�nidas, são elas:
Cobertura de linha;
Cobertura de caminho de código;
Cobertura de método.
Teste de Fumaça
Também conhecido como “Build Veri�cation Testing”, é um tipo de teste de software que
compreende um conjunto não exaustivo de testes que visa garantir o funcionamento das
funções mais importantes. O resultado desse teste é usado para decidir se uma construção
(build) é estável o su�ciente para continuar com os testes. Também pode ser usado para
decidir se deve anunciar um lançamento de produção ou reverter. O termo "teste de fumaça"
veio para o teste de software a partir de um tipo semelhante de teste de hardware, no qual um
dispositivo passa no teste se não pegar fogo (fumegou ou saiu fumaça) na primeira vez em
que foi ligado.
O teste de fumaça ajuda a expor a integração e os principais problemas no início do ciclo. Pode
ser conduzido tanto em software recém-criado quanto em software aprimorado. O teste de
fumaça é realizado manualmente ou com a ajuda de ferramentas/scripts de automação. Se as
compilações forem preparadas com frequência, é melhor automatizar o teste de fumaça.
Conforme e quando um aplicativo se torna maduro, com adição de mais funcionalidades, o
teste de fumaça precisa ser mais expansivo. Às vezes, é necessário apenas um caractere
incorreto no código para tornar um aplicativo inteiro inútil.
Etapa 1 – Identi�cação: A primeira etapa ao realizar o teste de sanidade, como
com qualquer outro tipo de teste, é estabelecer exatamente o que precisa ser
testado. Isso inclui todas as funcionalidades, recursos e modi�cações que foram
introduzidos no código relevante;
Etapa 2 – Avaliação: Nessa etapa, os testadores veri�carão e avaliarão todas as
funcionalidades, recursos e modi�cações identi�cados na etapa anterior. Isso é
para ver se eles funcionam como deveriam;
Etapa 3 – Teste: Nesta etapa, os testadores veri�carão todas as funcionalidades,
parâmetros e elementos relevantes associados à funcionalidade avaliada acima.
Isso garantirá que todas as suas bases sejam cobertas no que diz respeito ao
funcionamento correto do software. 
 
Teste de Regressão
Trata-se de uma parte do teste de software projetado para determinar se um sistema é
resistente a falhas e funcional após uma alteração de código. Nesse estágio, um testador
executa novamente
um conjunto de casos que executou durante o estágio inicial de
desenvolvimento para garantir que não haja impacto negativo. Observe que é importante
testar não apenas a parte do código que foi modi�cada ou um recurso recém-adicionado, mas
todo o sistema.
Existem várias abordagens para o teste de regressão. Aqui está um breve resumo das técnicas
mais amplamente utilizadas.
Teste tudo novamente: Essa abordagem implica que todos os testes do sistema
devem ser executados novamente. Embora seja a maneira mais segura de garantir
que o projeto esteja livre de bugs, é preciso muito tempo e muito empenho para
executar um conjunto completo de testes. É por isso que a prática de "reteste
tudo" raramente é usada entre os testadores e, no caso em que uma equipe decida
continuar com ela, as sessões provavelmente serão automatizadas;
Seleção do teste de regressão: Ao selecionar um subconjunto de casos de teste
existentes, um especialista em QA pode cortar os custos operacionais
tremendamente em comparação com o novo teste de todo o sistema. Existem
várias práticas que os testadores usam para selecionar um caso de sessões de
teste de regressão. Para começar, você só pode testar um conjunto que produza
cobertura para a seção modi�cada do programa original. Outra abordagem popular
é uma técnica segura, em que um testador trabalha com o número de casos que
expõem uma ou várias falhas no programa modi�cado. Outras abordagens para
seleção de teste incluem técnicas de cobertura de �uxo de dados e técnicas
aleatórias;
Priorização de casos de teste: Essa abordagem permite que um especialista em QA
se concentre em testar as funcionalidades e casos usados com mais frequência
que têm um impacto comercial crucial, enquanto coloca temporariamente todos
os recursos secundários de lado. Ao priorizar os casos de teste, você reduzirá
enormemente o tamanho do conjunto de testes e terá mais tempo para avaliar
completamente o desempenho das partes cruciais do sistema.
Para reduzir o custo e o número de horas necessárias para o teste de regressão completo, a
maioria das empresas executa sessões automatizadas. Dessa forma, eles são capazes de
manter uma maior precisão e reduzir o erro humano, bem como executar testes ininterruptos
24 horas por dia, 7 dias por semana.
Teste de Integração
Se um sistema requer vários módulos funcionais para funcionar de maneira e�caz, o teste de
integração é feito para garantir que os módulos individuais funcionem conforme o esperado
ao operar em combinação uns com os outros. Ele valida se o resultado de ponta a ponta do
sistema atende a esses padrões necessários. Por tanto, o teste de integração é um tipo de teste
destinado a veri�car as combinações de diferentes unidades, suas interações, a forma como
os subsistemas se unem em um sistema comum e a conformidade do código com os
requisitos.
O teste de integração é executado usando o método da caixa preta. Esse método implica que
uma equipe de teste interaja com um aplicativo e suas unidades por meio da interface do
usuário – clicando em botões e links, rolando, deslizando, entre outros. Eles não precisam
saber como o código funciona ou considerar a parte de back-end dos componentes.
O teste de integração e o teste de unidade são dois níveis de teste de software, em que a
unidade é a básica e a integração é a sequencial.
O teste de unidade implica veri�car as menores partes funcionais do código separadamente. O
teste de integração vai além: procuramos erros que acontecem quando as unidades começam
a interagir. O fato de as unidades terem passado com sucesso nos testes dos estágios
anteriores não garante que funcionem bem juntas. 
Portanto, quaisquer problemas que surjam quando montamos várias partes menores em um
subsistema podem estar associados às particularidades da interação entre essas unidades.
Quanto mais cedo notarmos algo anormal, menor será o custo de um erro.
Teste de Usabilidade
O Teste de Usabilidade é feito durante o processo de design de uma aplicação, com o objetivo
de testar se o aplicativo desenvolvido é conveniente e fácil de usar.
O teste de usabilidade oferece muita �exibilidade para alterações no design do aplicativo que
está sendo desenvolvido.
Por exemplo, quando um novo site de comércio eletrônico está sendo projetado, uma equipe
de teste inicia o Teste de usabilidade antes mesmo de o site terminar. Essas pessoas
veri�carão sua usabilidade para saber como é conveniente e rápido pesquisar itens diferentes,
obter opções diferentes, pesquisar por palavras-chave, fazer login, navegar, colocar itens em
um carrinho e modos de pagamento.
O objetivo desse tipo de teste é revelar áreas de confusão e descobrir oportunidades para
melhorar a experiência geral do usuário. A seguir, estão 3 dos principais testes de usabilidade:
Teste de guerrilha: trata-se da forma mais simples de teste de usabilidade. Neste
teste, um moderador vai até um local público como shopping, mercado, entre
outros, para apresentar seu protótipo às pessoas e questioná-las sobre ele. Essas
pessoas são escolhidas aleatoriamente entre diversas pessoas no local e, em
seguida, são convidadas para realizar um teste de usabilidade. No �nal do
processo, como agradecimento, essas pessoas recebem algum tipo de presente;
Teste de laboratório: Trata-se de um teste que é feito em um ambiente especial
(laboratório) e é supervisionado por um moderador, que é o pro�ssional que
deseja obter feedback do usuário. Durante um teste moderado, os moderadores
estão facilitando os participantes do teste por meio de tarefas, respondendo às
suas perguntas e respondendo aos seus comentários em tempo real;
Teste remoto não moderado: Diferente do teste de laboratório onde existe um
moderador que acompanha todo o processo, o teste de usabilidade remota não
moderado ocorre sem um moderador, adicionando ainda uma outra característica
de que pode ser feito a distância. Desse modo, todos aqueles que participam do
teste devem concluir tarefas que são desempenhadas a distância, sejam elas em
seus próprios computadores ou smartphones, sem a presença ou orientação de um
Teste Usabilidade Moderado Versus o Não Moderado
Como você pode observar, temos sessões de teste moderada e não moderada. No primeiro
caso, toda a sessão do teste é administrada (seja pessoalmente ou remotamente) por um
membro da equipe de desenvolvimento ou de teste. Por outro lado, um teste não moderado
não possui acompanhamento ou supervisão de alguém, permitindo que os participantes
estejam em laboratórios, em suas próprias casas e em seus próprios dispositivos.
Como, durante uma sessão de teste moderado, o participante está em contato direto com o
pesquisador, então, como saída, temos resultados mais detalhados. Por outro lado, por haver a
necessidade de reservar um espaço e prepara todo o ambiente, esse tipo de teste acaba sendo
mais caro de se organizar e também de realizar a sua execução.
Qual teste usar então? Bem, o teste moderado deve ser empregado para analisar o
comportamento do usuário, bem como o raciocínio para desempenhar tarefas na aplicação.
Por outro lado, os testes não moderados são usados para analisar os padrões de
comportamento do usuário.
Teste Usabilidade Remoto Versus o Pessoalmente
Até aqui você pode compreender que os testes podem ser com ou sem moderador. Além disso,
o teste pode ser feito a distância (remoto) ou pessoalmente. Os testes, quando são feitos pela
internet, são chamados de testes remotos. Agora, quando o teste exige a presença do
participante �sicamente no laboratório ou no ambiente de teste, chamamos de teste pessoal.
Cada um desses testes tem seus objetivos bem de�nidos. Quando há a necessidade de analisar
a linguagem corporal e/ou expressões faciais, torna-se fortemente recomendável que o tipo
de teste seja presencial. A desvantagem é que os testes presenciais são caros e demorados.
A�nal, é necessário preparar um local adequado e realizar o pagamento para os participantes
(muitas vezes lanches
e bebidas).
moderador. Devido a isso, o custo de testes não moderados acaba sendo bem
menor, porém, gera resultados com poucos detalhes.
O teste remoto não possibilita uma análise profunda do raciocínio do participante, porém,
permite que um grande número de participantes estejam disponíveis para o teste,
independente da área geográ�ca em que se encontram.
Muitos testes funcionais serão projetados em torno de determinadas especi�cações de
requisitos  atender aos requisitos de negócios é uma etapa vital no projeto de qualquer
aplicativo. Por exemplo, um requisito para um site de comércio eletrônico é a capacidade de
comprar mercadorias.
Um exemplo prático disso é: quando um cliente �naliza a compra de uma cesta de compras,
ele deve ser encaminhado para uma página de pagamento segura, a seguir, para a veri�cação
de segurança do banco e, em seguida, deve receber um e-mail de con�rmação. O teste
funcional veri�ca se cada uma dessas etapas funciona.
Estudo de Caso
Para compreender melhor o teste funcional, considere o seguinte caso: um portal on-line
possibilita que o usuário efetue login com sua conta de usuário e senha. A página de
login possui dois campos de texto, sendo um para nome de usuário e outro para senha.
Também possui dois botões: Login e Cancelar.
Quando bem-sucedido, a página de login direciona o usuário para a página inicial do portal. O
botão cancelar cancela o login.
Primeiramente, precisamos levantar as especi�cações desta aplicação:
O campo de identi�cação do usuário requer um mínimo de 6 caracteres, um
máximo de 10 caracteres, números (0-9), letras (az, AZ), caracteres especiais
(apenas são permitidos sublinhado, ponto �nal e hífen). O campo não pode ser
deixado em branco. O ID do usuário deve começar com um número/caractere. Não
pode incluir caracteres especiais;
O campo de senha requer um mínimo de 6 caracteres, um máximo de 8
caracteres, números (0-9), letras (az, AZ), todos os caracteres especiais. Não
O cenário de caso de uso apresentado pode ser testado por meio de uma variedade de técnicas
de teste funcional.
A automação pode certamente reduzir o tempo e o esforço na execução de testes funcionais. O
erro humano também pode ser reduzido, evitando que os bugs passem da fase de teste.
Principais Ferramentas
Com o avanço das tecnologias de desenvolvimento de software, muitas ferramentas são
criadas com o objetivo de melhorar a produtividade, qualidade, principalmente, melhorar o
tempo de entrega de cada produto, trazendo assim a satisfação do cliente. Desse modo, o teste
pode �car em branco.
Teste de sistema: teste o sistema para avaliar se todos os componentes estão
funcionando perfeitamente em combinação. No exemplo, isso envolveria testar a
jornada do cliente – carregamento do aplicativo web, inserção de credenciais
precisas, direcionamento para a página inicial, execução de tarefas, logout do
sistema. Esse teste garante que o �uxo de trabalho prossiga e seja concluído sem
erros;
Teste de equivalência: os dados de teste são segregados em partições chamadas
casos de dados de equivalência. Nesse teste, os dados em cada partição devem
responder da mesma maneira. Consequentemente, você só precisa testar uma
condição em todas as partições. Se a condição não funcionar em uma partição,
não funcionará em nenhuma das outras. No exemplo, como o campo de id do
usuário pode acomodar no máximo 10 caracteres, ele deve se comportar da
mesma forma sempre que forem inseridos mais que 10 caracteres;
Teste de valor limite: esses testes são usados para veri�car como o sistema se
comporta quando os limites de dados são implementados. No exemplo, uma vez
que a id do usuário requer um mínimo de 6 caracteres, esse teste será usado para
veri�car como o sistema responde quando menos de 6 caracteres são inseridos.
de software, apoiado por suas ferramentas, contribuem para que as empresas de
desenvolvimento atinjam esses objetivos.
Existem diversas ferramentas para testes, sendo assim, a seguir, estão elencadas as principais
e mais utilizadas no mercado.
Selenium
Selenium é uma ferramenta que permite automatizar aplicações web. Se você estiver testando
um aplicativo em um navegador e quiser acelerar o processo e talvez se livrar de alguns erros,
pode automatizar o processo com o Selenium.
O Selenium fala a linguagem do navegador, o que signi�ca que pode ser usado para orientar o
comportamento do navegador, como digitar em uma barra de pesquisa, clicar em um botão,
rolar uma página para baixo e assim por diante.
O Selenium consiste em uma série de ferramentas que fazem coisas diferentes: 
Selenium IDE: Selenium IDE é uma ferramenta de gravação e reprodução que pode
ajudá-lo a criar e editar casos de teste e suítes de teste. O IDE é um plugin do
Firefox que é usado para criar e executar casos de teste. Ele permite que você crie
casos de teste registrando suas interações com o navegador. Suas interações são
transformadas em etapas na própria linguagem da Selenium. Essas etapas podem
ser exportadas em diferentes linguagens de programação, incluindo Java, Python e
Ruby, que podem ser executadas posteriormente. O resultado �nal é o script de
teste completo na linguagem de sua escolha; 
Selenium WebDriver: Selenium WebDriver é uma interface de programação que pode
ser usada para criar e executar casos de teste. O WebDriver permite que você teste
todas as principais linguagens de programação, navegadores e sistemas
operacionais;
Selenium Grid: O Selenium Grid permite que você execute vários testes ao mesmo
tempo em várias máquinas, também conhecido como teste paralelo. Trata-se de
um ambiente com vários sistemas, mas um sistema mestre (o hub) que controla
Essas ferramentas suportam vários navegadores, sistemas operacionais e linguagens de
programação, de modo que o Selenium se adapta essencialmente às necessidades de muitos
testadores de software. Selenium também é de código aberto, o que signi�ca que você pode
baixá-lo gratuitamente, estender e modi�car o código-fonte como quiser e obter ajuda de
uma grande comunidade de usuários.
Após compreender os conceitos básicos do Selenium, vamos dar uma olhada mais de perto em
como usá-lo. 
os sistemas �lhos (os nós). Os sistemas �lhos podem ser, por exemplo, Nó 1:
Windows 10 rodando Chrome, Nó 2: MAC rodando Safari, Nó 3: Linux rodando
Chrome e assim por diante.
Existem seis etapas básicas na criação de um script Selenium para
testar um aplicativo da web:
Crie uma instância WebDriver;1
Navegue para uma página da web;2
Localize um elemento HTML na página da web;3
Execute uma ação no elemento HTML;4
Antecipe a resposta do navegador;5
Conclua o teste.6
Para executar essas etapas no Selenium, torna-se necessário escrever scripts de teste na
linguagem de programação de escolha da equipe. Depois que o script é escrito, a equipe de
teste pode executá-lo para testar qualquer aplicativo da web.
TestComplete
TestComplete é uma ferramenta automatizada de teste de IU desenvolvida pela
SmartBear Software. TestComplete tem a capacidade de criar testes funcionais automatizados
para aplicativos de desktop, web e móveis. Os recursos de plataforma cruzada do TestComplete,
abrangendo Desktop, Mobile e Web, uni�cam sua pilha de automação oferecendo uma
abordagem dedicada. Se o objetivo é: necessidade de uma ferramenta comum em toda a
organização para teste; consolidação de relatórios de várias tecnologias diferentes;
implementação de uma abordagem uni�cada para automação de teste. Seja qual for o objetivo,
ter uma ferramenta para aprender, uma ferramenta para implementar com uma abordagem
comum e uma plataforma com suporte pro�ssional para automação simpli�ca e melhora a
e�ciência do desenvolvimento e execução de testes automatizados.
TestComplete é uma ferramenta sem script que não requer habilidades de programação
obrigatórias para começar, além de ser muito fácil de usar e, desse modo, ajuda na criação de
scripts robustos. 
Outra característica é que o TestComplete
é muito mais poderoso e rico em recursos em
comparação com o Selenium. Mas o custo do TestComplete é mais alto e as empresas optam
por ferramentas de código aberto como o Selenium, o qual oferece mais oportunidades de
crescimento e aprendizado na carreira, pois você precisa ser bom em programação. 
Portanto, o TestComplete é mais adequado para uma equipe de habilidade média e restringe os
projetos de cronograma para a criação mais rápida de scripts de teste. O orçamento do projeto
pode ser ajustado reduzindo o número de recursos necessários.
Watir
Watir é um grupo de bibliotecas Ruby para navegadores da web automatizados. Permite
escrever testes de fácil leitura e manutenção. Em outras palavras, é uma ferramenta simples e
�exível.
Watir manipula os navegadores da mesma forma que as pessoas, veri�cando os resultados,
garantindo, assim, a aparência do texto esperado na página. Watir oferece suporte a qualquer
aplicativo – não importa a tecnologia em que seja desenvolvido, suportando apenas Internet
Explorer no Windows. O Watir-WebDriver oferece suporte a diferentes navegadores, como o
navegador Chrome, Firefox, Internet Explorer e Opera.
Escolhendo a Melhor Ferramenta
A seleção de ferramentas geralmente é baseada em critérios que não são ideais. 
Sendo assim, veremos a seguir cinco critérios principais os quais devem ser considerados na
escolha de uma ferramenta para teste funcional. 
Não existe uma ferramenta que resolva todos os problemas, bem como
não existe uma ferramenta que é a melhor ou a pior. Cada ferramenta
é desenvolvida para casos especí�cos. 
De Acordo com o Defeito
Quais são os bugs bloqueadores que aparecem e onde eles aparecem? Essa é uma pergunta
fácil de fazer; a maioria das equipes com um rastreador de bugs pode encontrar a resposta na
hora do almoço. Esse tipo de pesquisa pode encontrar a maioria dos bugs na lógica de
negócios, na camada de banco de dados ou na interface grá�ca do usuário (GUI).
Se os bugs mais importantes estiverem na GUI, a automação de teste da lógica de negócios por
meio de testes de unidade não agregará muito valor. Certamente não será o primeiro lugar por
onde começar.
Embora esta seja a primeira pergunta, também pode ser a última. Depois de selecionar uma
ferramenta, volte a esta questão. Reveja os defeitos recentes que importam, encontrados tanto
no teste quanto na produção, e pergunte se a ferramenta pode realmente detectar esses tipos
de defeitos. Se a resposta for "provavelmente não" ou pior, reinicie o processo de seleção da
ferramenta.
Ajuste da Equipe
A próxima pergunta é provavelmente: "Quem fará a automação?". Se a automação for feita por
programadores ou programadores/testadores, a ferramenta provavelmente deve ser uma
biblioteca de código ou pacote. Da mesma forma, um grupo de testadores não técnicos �cará
mais confortável se a ferramenta tiver um front-end de gravação/reprodução.
Algumas ferramentas gravam ações e, em seguida, criam código ou criam um front-end visual
que permite aos programadores entrarem para ver o código por trás da visualização. Eles
oferecem o melhor dos dois mundos.
O principal problema aqui é que as pessoas que devem aprender a ferramenta precisam estar
dispostas e capazes de fazer isso e também ter tempo para fazê-lo. Se o processo de teste
estiver atrasado, designar testadores para aprender uma nova ferramenta adicionará trabalho,
retardando ainda mais o processo de entrega do software.
Se o processo de teste de regressão levar dias ou semanas para ser executado, automatizá-lo,
especialmente no front-end, tornará o teste mais lento, criando um acúmulo de trabalho até
algum ponto de equilíbrio. Mesmo após o ponto de equilíbrio, em que a ferramenta não está
mais atrasando os testadores, o antigo acúmulo de pedidos precisará ser eliminado.
Claro, se o projeto for novo, ou se a empresa pretende contratar uma nova pessoa para fazer o
trabalho da ferramenta de teste, essas objeções podem não se aplicar. Então, faça uma análise
de como a ferramenta será adicionada à equipe, o que ela atrapalhará, quem fará o trabalho e
se essas pessoas têm capacidade e tempo para fazer o trabalho.
Linguagem de Programação
Se a ferramenta tiver uma linguagem de programação, existem duas abordagens: use uma
linguagem de alto nível incrivelmente poderosa e fácil de aprender, como Ruby, ou escreva na
mesma linguagem que os programadores de produção.
Se o teste for escrito na mesma linguagem do código de produção e executado durante a
execução da integração contínua (CI), pode ser possível falhar no commit e fazer com que os
programadores corrijam o bug. Melhor ainda, a ferramenta poderia ser executada como um
plug-in dentro do ambiente de desenvolvimento integrado (IDE) do desenvolvedor,
minimizando a quantidade de troca que os programadores precisam fazer.
Se a ferramenta for executada fora do IDE e usar uma linguagem de programação diferente, é
improvável que os programadores aprendam a nova ferramenta ou façam o trabalho de
suporte da ferramenta quando ela relatar falhas.
Gerenciamento de Dados de Teste
Uma empresa �ctícia comprou uma ferramenta de automação de teste popular com um
período de avaliação de 30 dias. A empresa tinha três ambientes de teste diferentes, usava
contas de usuário de teste compartilhadas e não tinha uma maneira fácil de excluir pedidos
depois de criados. Os pedidos podiam ser cancelados, mas continuavam a aparecer como
pedidos cancelados na tela principal dos "pedidos de hoje", com os primeiros aparecendo
primeiro. Depois que o sistema criou 10 pedidos, os novos pedidos não apareciam mais na
página inicial.
O processo de teste de fumaça criou três pedidos, o que signi�cava que só podia ser executado
três vezes por dia.
Foi realizado um grande progresso nos dias anteriores ao término do teste e gasto vários
milhares de dólares comprando a ferramenta e realizando o treinamento. O problema era que
não tinha como limpar os dados ou criar novas contas a partir da linha de comando  tudo era
conduzido por telas de administração.
Nesse caso, as ferramentas certas provavelmente envolveriam recursos para criar contas,
limpar pedidos, exportar uma conta e pedidos associados como "dados de teste válidos
conhecidos" e, em seguida, importá-los novamente. Isso permitiria que os testes comecem
sempre com uma con�guração válida.
Isso aceleraria imediatamente todo o processo de teste, incluindo os humanos fazendo o
trabalho.
Outra área comum de melhoria é a capacidade de criar servidores de teste sob demanda de
acordo com um branch ou commit. As equipes que buscam o IC e que desejam que a veri�cação
de ponta a ponta seja executada como parte do IC geralmente precisam criá-lo de qualquer
maneira.
 Se o maior gargalo no processo de teste for a con�guração, ou se a veri�cação repetível for
impossível sem automatizar a con�guração, a ferramenta de teste funcional certa pode ser
apenas automatizar a con�guração do teste use
Relatórios
Sem uma saída signi�cativa que alguém possa usar, uma ferramenta de teste é um mau
investimento. Painéis e grá�cos podem ser recursos poderosos – a menos que a equipe
planeje enviar os resultados para outro sistema com relatórios melhores.
O rastreamento de execuções de teste ao longo do tempo também pode ser um recurso
poderoso. As partes interessadas em diferentes níveis se preocupam com diferentes tipos de
resultados. Os executivos em um nível alto o su�ciente podem nem mesmo querer saber as
taxas de aprovação/reprovação tanto quanto as tendências. Os gerentes de nível médio
desejam entender o �uxo do processo. O pessoal técnico vai querer detalhar exatamente o que
deu errado em um determinado teste, assistindo a um vídeo da execução, se possível.
Em Síntese 
Nesta Unidade, você pode compreender o conceito de teste funcional,
bem como os diferentes tipos de testes relacionados a este. Você
também conheceu um pouco mais sobre as principais ferramentas de
teste funcional, dentre elas, o Selenium,
uma poderosa ferramenta de
teste que é utilizada por diversas empresas por todo o mundo devido à
sua facilidade de uso e por ser gratuita.
Indicações para saber mais sobre os assuntos abordados nesta
Unidade:
  Livros  
Engenharia de Software Moderna 
No livro 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. São Paulo: Editora
Independente, 2020.
Introdução ao Teste de Software 
No livro  os autores apresentam no capítulo 8 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
2 / 3
 Material Complementar
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.
Teste de Software 
No livro o autor apresenta no capítulo 11 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.
  Leitura  
Um Pouco Sobre Cobertura de Código e Cobertura de Testes 
No artigo 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 para conferir o conteúdo.
ACESSE
https://ggle.io/4Ztb
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.
FOWLER, M. The Practical Test Pyramid. Disponível em:
<https://martinfowler.com/articles/practical-test-pyramid.html>. Acesso em 01/10/2021.
LEAPWORK. Na Introduction to Codeless Selenium Test Automation. Disponível em:
<https://www.leapwork.com/selenium-testing>. Acesso em: 22/11/2021.
MCGOVERN, G. O que é teste de automação. Disponível em:
<https://www.guru99.com/automation-testing.html>. Acesso em: 20/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:
3 / 3
 Referências
Acesso em: 04/05/2021.