Bacharelado em Sistemas de Informação

Disciplina: Qualidade de Software

Professora: Michelle Maria Freitas Neto
Aluno: _______________________________________________ Data: _____/_____/______

TESTES DE SOFTWARE

1. Introdução

Testes de software são atividades de grande importância para buscar a qualidade de

software. De acordo com Delamaro, Maldonado e Jino (2016) o teste é uma atividade dinâmica
e seu objetivo é verificar se um sistema ou modelo tem o comportamento de acordo com o
esperado. Bartié (2002) menciona que entender que o objetivo dos testes é “provar que algo
não funciona” é um avanço significativo na compreensão de um processo de qualidade de
software. Uma das definições apresentada por Rios(2007) é que teste de software é “avaliar se
o software está fazendo o que deveria fazer a partir de seus requisitos e não está fazendo o que
não deveria fazer.”
Para entender melhor sobre testes vamos observar a figura abaixo:

Figura 1 – Dimensão dos Testes (RIOS, 2007)

Segundo Rios(2007) as técnicas de teste (como testar) são duas:

• Testes de Caixa Preta (Black Box): “visam verificar a funcionalidade e a aderência
aos requisitos, em uma ótica externa ou do usuário, sem se basear em qualquer
conhecimento do código e da lógica interna do componente testado.”
• Testes de Caixa Branca (“White Box”): “visam avaliar o código, a lógica interna do
componente codificado, as configurações e outros elementos técnicos.”
Complementando essa definição, Bartié (2002) descreve que para realização dos testes
de caixa branca é preciso que o profissional de testes conheça a tecnologia usada no software e
sua arquitetura interna e tenha acesso a fontes, estruturas dos banco de dados e realize testes
previstos em componentes de software. Esses testes podem também ser realizados pela própria
equipe de desenvolvimento, mas podem adicionar uma nova carga de trabalho a esses
profissionais que na verdade têm como meta a construção do software.
Em relação aos testes de caixa preta pode-se dizer que a técnica visa garantir que os
requisitos do sistema sejam atendidos pelo software construído. Os profissionais que o executam
não precisam ter conhecimento da tecnologia empregada ou dos conceitos utilizados na
implementação, mas sim dos requisitos, características e comportamentos esperados, para
avaliação dos resultados gerados pelo software (BARTIÉ, 2002).
Há autores que também relatam a existência dos testes de caixa cinza que misturam as
duas técnicas (caixa preta e caixa branca).
Em relação aos estágios ou níveis de teste, ou seja quando testar, Delamaro, Maldonado
e Jino (2016) descrevem que a atividade de testes tem fases com níveis distintos:
• Testes de Unidade (testes unitários): são testes que focam nas menores unidades
de um software como classes, funções, métodos ou procedimentos. Tais testes
não precisam de um sistema finalizado para serem realizados e geralmente são
feitos pelo próprio desenvolvedor.
• Teste de Integração: após os testes unitários, as diversas partes do sistema são
colocadas para trabalharem em conjunto. Rios (2007) descreve que essas diversas
partes podem ser trechos de código, módulos, aplicações distintas ou até mesmo
clientes e servidores.
• Teste de Sistema: geralmente são realizados por uma equipe independente que
verifica se as funcionalidades previstas nos documentos de requisitos estão
corretamente implementadas quando se tem um sistema completo. Rios (2007)
exemplifica que neste estágio deve ser feita uma simulação das funções do
sistema com dados e situações de teste mais próximos possível do que irá ocorrer
no ambiente de produção.
Além dos testes apresentados acima, Rios(2007) também destaca o nível de Testes
de Aceitação que por sua vez, são realizados pelos próprios usuários com suporte da
equipe de projeto e de testes com intuito de verificar se a solução atende aos requisitos
e verificar à usabilidade e funcionalidades.
Por fim, sobre os Tipos de Teste que relacionam-se a “O que testar” podemos citar
alguns exemplos extraídos da obra de (Rios, 2007):
• Testes Funcionais: “avaliam se o que foi especificado foi implementado,
normalmente servindo de base a um processo de verificação automática. Neste
teste devem ser considerados os valores extremos que avaliam os limites do
sistema.”
• Testes de Usabilidade: ”verificam o nível de facilidade de uso do software pelos
usuários.”
• Testes de Segurança: “validam a capacidade de proteção do software contra
acesso interno ou externo não autorizado.”
 • Testes de Configuração: “verificam se o software está apto a rodar em
diferentes versões ou configurações de ambientes (hardware e software),
como por exemplo, diversos browsers ou versões de browsers.”
• Testes de Carga: “visam avaliar a resposta de um software sob uma pesada
carga de dados ou uma grande quantidade de usuários simultâneos para
verificar o nível de escalabilidade, ou seja, o momento onde o tempo de
resposta começa a degradar ou a aplicação começa a falhar.”
• Testes de Desempenho: ”visa garantir que o sistema atende aos níveis de
desempenho e tempo de resposta acordados com os usuários e definidos nos
requisitos. São também chamados de testes de performance.”
• Testes de Regressão: “visam garantir que o software permaneça intacto depois
de novos testes serem realizados. Um conjunto de dados e scripts deve ser
mantido como “baseline” e executado opara verificar que mudanças
introduzidas posteriormente não danificarão testes códigos já considerados
bons e aceitos.”

2. Processo de Testes

Pezzé e Young (2008) reforçam que projetar testes desde o início vantajoso, ou seja,
realizar os testes independentemente do código. Os mesmos autores descrevem que ao se
projetar casos de teste com antecedência permite corrigir especificações e evitar que erros se
propaguem para outros estágios de desenvolvimento.
Delamaro, Maldonado e Jino (2016) descrevem que as atividades de teste possuem
etapas: planejamento, projeto de casos de teste e execução e análise. Corroborando com essa
afirmação Rios (2007) destaca que um processo de teste deve existir e basear-se em uma
metodologia aderente ao processo de desenvolvimento envolvendo um ambiente adequados
pessoas e ferramentas, além desse processo interagir com o processo de desenvolvimento.
A Figura 2 mostra as fases de um ciclo de vida de um processo de testes segundo o
“modelo 3PX3E”.

Planejamento

Procedimentos Especificação Execução Entrega

Iniciais

Preparação

Figura 2 – Fases de um ciclo de vida num processo de testes (RIOS, 2007)

 Segundo Rios (2007) na etapa de Procedimentos Iniciais é estabelecido um acordo por
meio de um documento (Guia Operacional de Testes – GOT) entre as partes envolvidas no projeto
de teste (usuário, desenvolvimento, teste e produção) para definir o objetivo do projeto de teste,
pessoal envolvido, responsabilidades, plano preliminar de trabalho, avaliação dos riscos, os
níveis de serviço acordados e itens considerados relevantes para garantir o sucesso do projeto
de testes.
Ainda segundo Rios (2007), o Planejamento diz respeito à elaboração e revisão de uma
estratégia de testes e do Plano de Teste, enquanto a etapa de Preparação refere-se à preparação
de um ambiente de testes, considerando equipamentos, rede, pessoas, software e ferramentas.
Dando continuidade, o mesmo autor descreve que a Especificação diz respeito à
elaboração de Caos de Teste, scripts e dos Roteiros de Teste e execução dos testes estáticos
(verificação da documentação do sistema). Já a Execução refere-se à execução dos testes de
acordo com o planejamento e os registros dos resultados obtidos. Por fim, a Entrega é a
finalização do processo de testes com a entrega do sistema para o ambiente de produção.
Uma outra questão a ser considerada num processo de testes é a automatização.
Geralmente se gasta muito tempo com as atividades de teste, portanto buscar ferramentas para
ajudar no gerenciamento das atividades e até mesmo na execução é muito relevante.
Por fim, é preciso saber a hora de começar e de terminar os testes.
Segundo Pezzé e Young (2008) “o melhor indicador para prever o custo de corrigir um
defeito de software é o tempo entre sua introdução e sua detecção. Um defeito introduzido na
sua codificação é muito mais fácil de ser corrigido durante o teste unitário do que mais tarde,
durante o teste de integração ou de sistema, e muito mais caro ser detectado por um usuário
do sistema em campo.”
Sabemos que na prática não se consegue garantir que um software estará 100% livre de
bugs, portanto, é preciso analisar o custo-benefício e determinar o momento certo de parar.
Enfim, testar software não é uma atividade simples, portanto fazer um bom processo de
testes é fundamental para liberação de softwares com qualidade.

REFERÊNCIAS BIBLIOGRÁFICAS:

BARTIÉ, A.. Garantia da Qualidade de Software: adquirindo maturidade organizacional. 1. ed.

Rio de Janeiro. Campus, 2002.

DELAMARO, M.E. MALDONADO, J.C., JINO, M. Introdução ao Teste de Software. 2. Ed. Rio de
Janeiro. Elsevier Editora LTDA, 2016.

PEZZÉ, M. YOUNG, M. Teste e Análise de Software: processos, princípios e técnicas. 1. ed.

Porto Alegre: Bookman, 2008.

RIOS, E. Documentação de Teste de Software – Dissecando o padrão IEEE 829. 1. ed. Niterói.
Imagem art studio, 2007.