Proceedings of the XII SIBGRAPI (October 1999) 101-104

QUALIDADE DE SOFTWARE

Texto base

1.1
Introdução ao Teste de Software

Marco Túlio Jeunon

Resumo
A busca por software, cada dia se torna mais presente no nosso cotidiano, em todos as
nossas atividades e áreas, porém como satisfazer as necessidades de qualidade dos
mesmos? Nesta aula o objetivo é introduzir o aluno no contexto de teste de software,
fazendo com que entenda a necessidade da sua realização estruturada, bem como
conhecer as principais atividades relacionadas a ele, assim será capaz de atingir os
objetivos de qualidade requeridos.

1.1. O que é teste de Software?

Teste de ​software é parte do processo de desenvolvimento de ​software​, que tem como
objetivo encontrar falhas ou defeitos, antes que o produto de software seja implantado
em produção ou seja tenta garantir a qualidade com base nos requisitos esperados pelo
solicitante, tanto os funcionais quanto os não funcionais.

1.2. Por que é necessário testar?

Cada vez mais softwares estão sendo necessários a nossa vida cotidiana, tanto para
empresas quanto para pessoas e em todas as áreas. O software tem uma natureza muito
complexa, pois além de terem os aspectos funcionais, temos os não funcionais, que são
as restrições estabelecidas para o seu desenvolvimento. O dissabor no encontro de
falhas e defeitos em um software é uma experiência que em alguma medida já nos
deparamos. A falha o software poderá gerar muitos problemas e gerar graves
consequências. Portanto devemos nos preocupar na realização estruturada dos testes.

Núcleo de Educação a Distância | Faculdade Impacta

 QUALIDADE DE SOFTWARE

1.3. Principais consequências da falta de teste

A falta do teste ou a sua baixa cobertura na execução podem levar a graves
consequências, dentre as quais podemos destacar:
● Perdas Financeiras​, tanto pelo lado do contratante do software, quanto para o
fornecedor do mesmo;
● Perda de Produtividade​, pois um software com problemas, pode paralisar
algumas atividades durante um longo período, ocasionando perda de horas e
horas de trabalho ou acesso de clientes, que não se consegue recuperar
posteriormente;
● Perda de Qualidade​, ou seja para se ter qualidade devemos atender aos
requisitos ou até mesmo superá-los, uma dos requisitos mais desejáveis do
software é que ele esteja disponível no tempo certo e na hora certa para que
cumpra a sua missão e seja utilizado.
● Perda de Confiança​, uma das conquistas mais importantes de um fornecedor de
software, é que ele passe confiança ao contratante. Essa relação ganha ganha faz
com que vários negócios possam ser realizados, porém quando se perde a
confiança se perde o cliente, que certamente custou para conseguir;
● Lesões corporais ou morte​, dependendo do tipo de aplicação sendo
desenvolvida, podemos ter risco de lesões e ou até morte, em virtude da falta de
teste.
● Desastres tecnológicos​, podem acontecer .

1.4. Principais causas de falhas no software

As principais causas de falhas no software, são muitas porém destacamos :

● Produto de software escrito e desenvolvido por pessoas;
● Pressão do tempo ou seja prazo requerido para desenvolvimento menor do que
seria necessário para se garantir a qualidade do mesmo;
● Complexidade do software;
● Falha na comunicação, entre os envolvidos;
● Estabilidade dos requisitos, ou seja muita alteração nos requisitos funcionais e
não funcionais, ocasionando muitas manutenções na aplicação;
● Processo de desenvolvimento imaturo, sem se ter maturidade e processo de
desenvolvimento.

1.5. Devemos testar tudo?

Normalmente não se tem tempo e recursos suficientes para se realize uma cobertura de
100% dos testes necessários, em virtude disso devemos priorizar os testes levando
primeiramente em conta os riscos. Em segundo lugar devemos testar as restrições do
projeto.

Núcleo de Educação a Distância | Faculdade Impacta

 QUALIDADE DE SOFTWARE

1.6. Principais atividades de teste

Dentre as principais atividades de teste, destacamos :
● Planejamento e controle
Nessa atividade devemos elaborar o Plano de Testes, que de acordo com o
padrão IEE 829 (Padrão para documentação de teste de software), deverá conter:
○ Identificador do plano de testes;
○ Introdução (sumário)
○ Itens de teste (versões de programas, meio onde estão armazenados,
acesso a bibliotecas, ambientes, dentre outros)
○ Módulos ou ​features do software (projeto de teste para cada módulo ou
combinação de módulos) a serem testados;
○ Módulos que não serão testados;
○ Abordagem de teste (métricas, metodologias, ferramentas);
○ Critério de identificação de defeito;
○ Critérios de interrupção e finalização dos testes;
○ Documentação de teste;
○ Identificação dos testes que serão realizados e como serão executados;
○ Necessidade de equipamentos ou software;
○ Responsabilidade da equipe envolvida;
○ Definição da equipe de teste e das suas necessidades;
○ Cronograma de atividades de teste;
○ Riscos e contingências;
○ Critérios de aprovação dos testes pelas áreas envolvidas.
● Seleção das condições de teste;
Identificação das condições de teste e a priorização deles junto a área gestora ou
usuários.
● Modelagem das condições de teste;
Elaboração dos casos de teste, de acordo com a IEEE 829 deverá conter:
○ Identificador da especificação do caso de teste;
○ Especificação de entrada;
○ Especificação de saída;
○ Necessidade de ambiente;
○ Requerimentos de procedimentos especiais;
○ Dependência de outro caso de teste.
● Execução dos testes;
Efetiva execução dos casos de teste e sua efetiva coleta de evidências de
realização.
● Verificação dos resultados;
Avaliar de acordo com critérios estabelecidos, se o resultado está de acordo ou
não e sua sinalização.

Núcleo de Educação a Distância | Faculdade Impacta

 QUALIDADE DE SOFTWARE

● Avaliação dos critérios de conclusão;

Avaliar de acordo com critérios estabelecidos no Plano de Teste, se os testes
atingiram ou não os critérios de conclusão;
● Atividades de Encerramento;
Reunir e documentar as atividades realizadas, bem como registrar sua execução
na base histórica e lições aprendidas, se for o caso.

Núcleo de Educação a Distância | Faculdade Impacta

 QUALIDADE DE SOFTWARE

1.7. Referências

PEZZE, M.& YOUNG, M. Teste e Análise de Software: processos, princípios e

técnicas. Porto Alegre: Bookman, 2008. ISBN: 978-85-778-0262-3.

BARTIE, A. Garantia da Qualidade de Software. Rio de Janeiro: Elsevier, 2002. ISBN:

978-85-352-1124-5.

DELAMARO, M. E.; MALDONADO, J.C. & JINI, M. Introdução ao teste de software,

Rio de Janeiro: Elsevier, 2007. ISBN: 978-85-352-2634-8.

HUMBLER, J. & FARLEY, D. ​Entrega contínua​. Porto Alegre: Bookman, 2014.

https://integrada.minhabiblioteca.com.br/#/books/9788582601044

Núcleo de Educação a Distância | Faculdade Impacta

Proceedings of the XII SIBGRAPI (October 1999) 101-104
 QUALIDADE DE SOFTWARE

Texto base

1.2
Estratégias de Teste de Software

Marco Túlio Jeunon

Resumo
O melhoramento do processo que busca a garantia do produto de software se dá
através de um processo robusto e que lhes dê domínio sobre as técnicas a serem
utilizadas. Nesta aula o objetivo é apresentar alguns conceitos importantes, verificação
e validação, para que em conjunto com as estratégias de teste caixa branca e caixa
preta, permita ao aluno entender quais são os testes que deverão ser realizados nas
diversas fases do ciclo de vida de desenvolvimento e manutenção de um software.

1.1. Entendendo o conceito de Verificação

É definido como um processo de avaliação dos artefatos gerados nas fases iniciais de
um projeto de software. A verificação deve ser utilizada para validar todos os
documentos, gráficos, manuais, códigos fonte, gerados em cada fase do ciclo de vida de
um software, para que não gere nenhuma dúvida ou questão mau resolvida propague
para outra fase. A verificação não envolve nenhum recurso de execução do software no
computador, portanto tenta garantir que algum erro de definição ou criação seja
propagado para outra fase. Exemplo de fases a serem verificadas:

● Requisito;
● Análise;
● Arquitetura;
● Desenvolvimento.

Núcleo de Educação a Distância | Faculdade Impacta

 QUALIDADE DE SOFTWARE

Dentre as validações a serem realizadas, podemos destacar:

● Reuniões de inspeções, também chamadas de revisões técnicas, baseando em

reuniões de revisão do documento de análise, procurando identificar possíveis
erros. É uma reunião formal e os participantes devem se preparar previamente
para realização da mesma;
● Reuniões de acompanhamento, não é tanto formal quanto a reunião de inspeção,
pois não precisam de preparação prévia dos participantes. O objetivo principal é
a disseminação do conteúdo entre os participantes, para que todos tenham
entendimento comum, a identificação de algum erro é um objetivo secundário;
● Revisão por outro profissional, ou seja trata se de uma revisão individual do
profissional diferente do autor, com o objetivo da identificação de algum
problema.
● Checklist​, é um poderoso instrumento de verificação, através do qual são
checados vários pontos devidamente estruturados, para que seja identificada a
sua completude ou não.

1.2. Entendendo o conceito de Validação

É definido como um processo de avaliação de uma aplicação (sistema) ou seus
componentes de software, a fim de validar se seu desenvolvimento está de acordo com
as especificações de requisitos funcionais e não funcionais, validado nas fases iniciais
do projeto. Na validação será necessária a execução do software desenvolvido. Nestas
fases é que são identificados os principais erros sistêmicos. Exemplo dos testes que
devem ser efetuados para que se tenha a validação:
● Teste Unitário é o teste do desenvolvedor do software, requer conhecimento das
estruturas internas, com esse teste ele tenta garantir que nenhum erro seja
propagado para as próximas fases de teste;
● Teste Integrado é o teste que é realizado para se garantir que os componentes ou
programas testados individualmente, sejam testados se integrando com as outras
partes, requer conhecimento da arquitetura interna da aplicação.
● Teste de homologação, esses testes são realizados no sistema como um todo,
requer uma ambiente similar ao de produção e são realizados por uma equipe
independente da equipe de desenvolvimento.
● Teste de aceitação, teste similar ao teste de homologação, porém normalmente
são executados pelos usuários finais ou eles indicam quais as situações de teste
devam ser evidenciadas para que eles validem e são executadas pela equipe de
testes.

Núcleo de Educação a Distância | Faculdade Impacta

 QUALIDADE DE SOFTWARE

1.3. Entendendo o Modelo V

Figura 1.3.1. Modelo V

A figura 1.3.1 representa o modelo “V” que relaciona as fases do ciclo de vida com os
testes a serem realizados. Como estratégia da verificação, devemos realizar a
verificação de cada artefato do ciclo de vida, requisito, análise, arquitetura e
desenvolvimento, bem como a execução da validação, que é a execução dos testes
unitários, de integração, homologação e aceitação.

Núcleo de Educação a Distância | Faculdade Impacta

 QUALIDADE DE SOFTWARE

1.4. Estratégia Caixa Branca

Figura 1.4.1. Estratégica Caixa Branca (Fonte: própria)

A figura 1.4.1, representa a estratégia caixa branca. Essa estratégia deve ser aplicada aos
testes unitários e testes integrados e tem como objetivo identificar defeitos nas partes
internas dos programas, procurando localizar algum código inalcançável, loop infinito
ou erros no código.

1.5. Estratégia Caixa Preta

Figura 1.4.2. Estratégica Caixa Preta (Fonte própria)

A figura 1.4.2 representa a estratégia caixa preta, ou seja não importa a estrutura interna
do software. Essa estratégia deve ser aplicada aos testes de homologação e aceitação do
sistema e tem como objetivo principal garantir que os requisitos do sistema sejam
plenamente atendidos. Para execução desses testes não há necessidade de conhecimento
tecnológico e normalmente são executados pelas equipes de teste e usuários do sistema.

Núcleo de Educação a Distância | Faculdade Impacta

 QUALIDADE DE SOFTWARE

1.6. Teste progressivo

A medida que um software evolui, ou seja adquire ou necessita de manutenção nas
funcionalidades existentes, um novo conjunto de testes devem ser criados ou revistos
para que garanta que não tenham falhas ou defeitos, portanto somente as inovações são
testadas.

1.7. Teste regressivo

A medida que um software evolui, mesmo que algumas funcionalidades do sistema não
tenham sido impactadas pela manutenção, devemos assegurar que as novas
implementações não produziram falhas ou defeitos. Para tanto para garantir que o
software continua funcionando normalmente, devemos retestar essas funcionalidades.

1.8. Referências

PEZZE, M.& YOUNG, M. Teste e Análise de Software: processos, princípios e

técnicas. Porto Alegre: Bookman, 2008. ISBN: 978-85-778-0262-3.

BARTIE, A. Garantia da Qualidade de Software. Rio de Janeiro: Elsevier, 2002. ISBN:

978-85-352-1124-5.

DELAMARO, M. E.; MALDONADO, J.C. & JINI, M. Introdução ao teste de software,

Rio de Janeiro: Elsevier, 2007. ISBN: 978-85-352-2634-8.

BECK, K. TDD - Desenvolvimento Guiado por Testes. Porto Alegre: Bookman, 2010.
ISBN: 978-85-778-0724-6.

HUMBLER, J. & FARLEY, D. ​Entrega contínua​. Porto Alegre: Bookman, 2014.

https://integrada.minhabiblioteca.com.br/#/books/9788582601044

Núcleo de Educação a Distância | Faculdade Impacta

Proceedings of the XII SIBGRAPI (October 1999) 101-104
 QUALIDADE DE SOFTWARE

Texto base

1.3
Tipos de Teste

Marco Túlio Jeunon

Resumo
Tanto requisitos funcionais quanto não funcionais, são requeridos pelo usuário do
sistema ou aplicação. Nesta aula vamos entender os mais diversos tipos de teste
existentes para atender justamente aos requisitos do usuário e aprender a derivar
casos de teste a partir de cenários identificados.

1.1. Testes para Requisito funcional

São testes que validam o requisito funcional requerido pelo sistema ou aplicação. Pode
ser utilizada a estratégia caixa branca ou preta, de acordo com a fase de teste que está
sendo realizada, por exemplo:
● Teste caixa branca, deverá ser executado nas etapas de teste unitário e teste de
integração, ou seja analisa a estrutura interna do software, com vista a validar os
requisitos funcionais;
● Teste caixa preta, deverá ser utilizado nas etapas de teste de homologação e teste
de aceitação, com vista a validar o que é solicitado pelos requisitos funcionais.
Como exemplo de teste funcional temos, simular um saque bancário acima do limite do
saldo de uma determinada conta corrente, ou seja existe uma regra no negócio bancário
que não permite saldo acima do limite.

Núcleo de Educação a Distância | Faculdade Impacta

 QUALIDADE DE SOFTWARE

1.2. Testes de Requisitos não funcionais

Requisitos não funcionais de uma aplicação são aquelas restrições no qual são
requisitadas pela aplicação ou sistema, para validação. Os testes realizados analisam e
verificam a operação correta do sistema e devem ser preparados testes específicos para
que o software garanta o que foi solicitado. Para tanto identificamos os principais testes:

● Teste de Performance​, que mede e avalia o tempo de resposta, número de

transações, usuários e outros requisitos sensíveis ao tempo, no qual o critério de
aceite deverá ser o tempo de resposta de uma operação ou a operação num
determinado período de tempo. Como por exemplo, avaliar se a duração de uma
transação de saque bancário dura 30 segundos, num universo de 40 milhões de
contas e 100 milhões de movimentações diárias.
● Teste de Carga​, que submete o sistema a uma variação de carga de trabalho
para medir e avaliar os comportamentos de ​performance e sua habilidade de
continuar funcionando apropriadamente. Como por exemplo, simular 100.000
acessos simultâneos.
● Teste de Estresse​, tipo teste de performance implementado e executado para
entender o comportamento do sistema durante a condições limite ou a tolerância
esperada, ou seja o critério de aceito é avaliar até onde o sistema aceita, se os
limites forem excedidos.
● Teste de recuperação e falhas​, que assegura que o sistema pode, com sucesso,
recuperar dados após uma falha no funcionamento do hardware, do software ou
rede, quando existir perda de dados e da integridade do mesmo. Como por
exemplo, retornar o valor sacado em um caixa eletrônico, quando o dispensador
de notas dê algum problema.
● Teste de configuração​, assegura que os mais dispositivos de hardware,
funcione corretamente quando da utilização do sistema. Como por exemplo,
vários tipos de scanners para obtenção de algum documento digitalizado.
● Teste de usabilidade​, que assegura que todos o usuário tenha facilidade no uso
do sistema. Como por exemplo, um portal funcione corretamente nos multi
browser: Internet explorer, Edge, Opera, Firefox, Google Chrome, dentre outros,
ou que possuam ajuda nas telas.
● Teste de segurança​, assegurando que o sistema possa operar dentro das regras
de segurança impostas pela legislação ou que possa detectar alguma invasão das
políticas definidas. Como por exemplo simular um saque com cartão com data
de validade vencida.

Núcleo de Educação a Distância | Faculdade Impacta

 QUALIDADE DE SOFTWARE

1.3. Exemplo de cenários de teste, para transferência Bancária, utilizando

internet banking
● Teste funcional:
○ Simular transferência eletrônica (TED);
○ Simular transferência (DOC);
○ Simular transferência para contas do mesmo banco;
○ Simular transferência para contas de outro banco;
○ Transferência com limite superior ao saldo da conta corrente;
○ Transferência através de conta poupança;
○ Transferência com limite superior diário cadastrado para conta;
○ Transferência de conta corrente para conta poupança;
○ Transferência de conta poupança para conta corrente;
○ Simular TED, fora do expediente bancário;
○ Simular DOC, acima do limite permitido.
● Teste de Performance:
○ Garantir que cada interação entre a validação e o usuário não leve mais
que 4 segundos;
○ Garantir que a transferência não passe de 45 segundos, num universo de
6 milhões de correntistas e 100 milhões de movimentações diárias;
● Teste Segurança:
○ Avaliar se a senha do cartão tenha sido informada corretamente;
○ Simular acesso ao sistema através de biometria.
○ Simular acesso ao sistema através de token;
○ Simular acesso ao sistema através de senha de 6 dígitos;
○ Avaliar se a senha randômica tenha sido informada corretamente;
○ Simular tranferência com cartão vencido;
○ Simular transferência fora do expediente bancário.
● Teste Usabilidade:
○ Verificar se nas telas possuem ajuda;
○ Verificar se existe auxílio de voz para deficientes visuais;
○ Verificar a navegabilidade entre as telas ida e volta;
○ Avaliar se as mensagens são claras e objetivas;
○ Avaliar se o padrão visual determinado pelas normas administrativas
estão sendo seguidos;
○ Verificar se em o caminho existem saídas da funcionalidade;
○ Verificar se existem helps de campo;
○ Verificar se as funcionalidades da aplicação funciona corretamente nos
mais diversos tipos de multi browsers,
● Teste de carga e concorrência:
○ Simular duas transferências simultâneas na mesma conta corrente,
através de transferência eletrônica (TED);
○ Simular 20.000 transferências ao mesmo tempo;
○ Simular 1.000.000 de transferências dia.

Núcleo de Educação a Distância | Faculdade Impacta

 QUALIDADE DE SOFTWARE

● Teste configuração:
○ Simular que a aplicação funcione corretamente nos mais diversos tipos
de hardware que acessam a internet.
● Teste Recuperação:
○ Simular queda de acesso a internet no momento da realização de uma
transferência eletrônica (TED);

1.4. Priorizando os tipos de teste

Em virtude de termos recursos e tempo finitos para execução dos testes, devemos
priorizar os testes tendo em vista os riscos e as restrições do projeto, portanto devemos
avaliar na etapa de planejamento, quais deverão ser os testes que devem ser realizados.
A título de exemplo devemos listar os mais diversos tipos de teste e avaliar se são
essenciais, se tem alto, médio ou baixo impacto:

Tabela - Priorização dos Testes

Tipos Importância

Funcional Essencial

Performance Alto impacto

Segurança Essencial

Usabilidade Médio impacto

Carga e Concorrência Baixo impacto

Configuração Médio impacto

Recuperação Baixo impacto

Estresse Médio impacto

Fonte: Própria

Núcleo de Educação a Distância | Faculdade Impacta

 QUALIDADE DE SOFTWARE

1.5. Estágios de teste

Dentre o ciclo de testes devemos elencar quais serão os tipos de teste que deverão ser
realizados, exemplo:
Quadro - Estágios de Teste

Fonte: própria

1.6. Elaborando casos de teste

Devemos elaborar casos de teste selecionando os cenários a serem testados:
Diagrama Casos de Teste - Teste Caixa Branca

Fonte: própria

Núcleo de Educação a Distância | Faculdade Impacta

 QUALIDADE DE SOFTWARE

Diagrama Casos de Teste - Teste Caixa Preta

Fonte: própria

Devemos sempre elaborar os casos de teste, tendo em vista os cenários positivos ou

aquele caminho feliz, que cumpre o requisito do usuário e também os cenários
negativos que são as exceções.

Diagrama Casos de Teste - Testes Positivo e Negativo

Fonte Própria

Núcleo de Educação a Distância | Faculdade Impacta

 QUALIDADE DE SOFTWARE

Tabela - Cenários de teste Login

Cenário Login Senha Caso de Teste Tipo de Cenário

1 Válido Válida CT01 positivo

2 Válido Inválido CT02 negativo

3 Inválido Válido CT03 negativo

4 Inválido Inválido CT04 negativo

Fonte: Própria

1.7. Exemplo de caso de teste, referente ao cenário 1:

1 - Identificador do Caso de Teste: CT01

2 - Especificação de Entrada

Login - Válido
Senha - Válida

3 - Especificação de Saída (resultado esperado)

Autorizar a entrada do usuário, apresentando o menu

4 - Necessidade de Ambiente
Não se aplica

5 - Requerimentos de procedimentos especiais

Não se aplica

6 - Dependência de outro caso de teste

Caso de teste de cadastramento de usuário

Núcleo de Educação a Distância | Faculdade Impacta

 QUALIDADE DE SOFTWARE

1.8. Referências

PEZZE, M.& YOUNG, M. Teste e Análise de Software: processos, princípios e

técnicas. Porto Alegre: Bookman, 2008. ISBN: 978-85-778-0262-3.

BARTIE, A. Garantia da Qualidade de Software. Rio de Janeiro: Elsevier, 2002. ISBN:

978-85-352-1124-5.

DELAMARO, M. E.; MALDONADO, J.C. & JINI, M. Introdução ao teste de software,

Rio de Janeiro: Elsevier, 2007. ISBN: 978-85-352-2634-8.

BECK, K. TDD - Desenvolvimento Guiado por Testes. Porto Alegre: Bookman, 2010.
ISBN: 978-85-778-0724-6.

HUMBLER, J. & FARLEY, D. ​Entrega contínua​. Porto Alegre: Bookman, 2014.

https://integrada.minhabiblioteca.com.br/#/books/9788582601044

Núcleo de Educação a Distância | Faculdade Impacta