Fundamentos

Teste de SoftwareAula 1

Considerações sobre software

Elemento de sistema lógico e único -> desafio

intelectual - probabilidade de falhas é um fato;

Manutenção envolve correção ou modificação no

projeto;

Necessita experiência em gerenciamento de software;

treinamento formal na área fundamental

Qualidade do software objetivo final.

Defeito, engano, erro, falha

estáticos

Defeito – (fault) passo, processo ou definição de dados incorretos

Engano – (mistake) ação humana que produz um defeito

Dinâmicos

erro – (error) estado inconsistente ou inesperado

Falha – (failure) resultado da execução diferente do esperado

A interpretação dependerá do contexto em que ele for utilizado

IEEE 610.12, 1990

http://dictionary.ieee.org/index/f-1.html

Falha nos requisitos

Um padrão IEEE (IEEE 830, 1998), que recomenda práticas paraespecificação de requisitos de software, define atributos de qualidadeque um documento de requisitos deve possuir. Foi considerado que afalta de qualquer um destes atributos constituiria um tipo de defeito.Assim, a seguinte taxonomia foi definida:

Omissão:

(1) Algum requisito importante relacionado à funcionalidade, ao desempenho,às restrições de projeto, ao atributo, ou à interface externa não foi incluído;

(2) não está definida a resposta do software para todas as possíveis situaçõesde entrada de dados;

(3) faltam seções na especificação de requisitos; (4) faltam referências defiguras, tabelas, e diagramas;

(5) falta definição de termos e unidades de medidas.

Ambiguidade: Um requisito tem várias interpretações devido adiferentes termos utilizados para uma mesma característica ou váriossignificados de um termo para um contexto em particular.

Falha nos requisitos

Inconsistência: Dois ou mais requisitos são conflitantes.

Fato Incorreto: Um requisito descreve um fato que não

é verdadeiro, considerando as condições solicitas para o

sistema.

Informação Estranha: As informações fornecidas no

requisito não são necessárias ou mesmo usadas.

Outros: Outros defeitos como a inclusão de um requisito

numa seção errada do documento.

informações Domínio de entrada – conjunto de todos os

possíveis valores que podem ser utilizados para

executar um programa (P);

Domínio de saída – conjunto de todos os possíveis

resultados produzidos pelo programa (P);

Dado de teste = elemento do domínio de entrada

Caso de teste = dado de teste mais resultado

esperado

Conjunto de casos de teste (T)= conjunto dos

dados de teste e seus resultados esperados

D(P) T PSucesso

ou

falha

Em busca da qualidade

Atividades para verificar a qualidade de software:

(presmann., 2011)

Revisões de software;

Testes;

Padrões e procedimentos formais;

Controle de mudanças;

Métricas de software;

Procedimentos para coleção e disseminação de

informações.

Qualidade

controle de qualidade assegurar que o software:

Atenda as necessidades dos clientes e usuários.

Cumpra as especificações do nível de qualidade desejado

do sistema

fazer

verificação e validação

verificação e validação

Verificar é ver se o sistema está sendo construído

corretamente, se esta em conformidade com as normas,

especificações e padrões

Validar é verificar se o sistema que está em construção

é o adequado ou correto

Fatores que interferem

Importância do software para a organização;

Expectativas do cliente e dos usuários;

Preço que o cliente está disposto a pagar;

Cronograma de entrega;

Outros sistemas concorrentes.

Técnicas tradicionais

Revisão (ou inspeção) de produtos de software é uma

técnica baseada no entendimento e análise do que está

sendo visto (ou lido).

Pode ser aplicado a todos os produtos (seja documento,

ou aos códigos de programas, ou arquivos de dados).

Revisão de software

A revisão de software deve ser realizada em todos os

produtos de software (documentos, códigos, dados de

software).

Os objetivos são:

Procurar defeitos;

Possíveis melhorias.

Tipos de defeitos

Por fato incorreto

Exemplo: O DFD representa o sistema de maneira errada.

Por Omissão

Exemplo: Omissão de requisitos.

Por informação estranha

Exemplo: Dado que o sistema não precisa ter no seu BD, mas aparece no modelo de análise.

Por inconsistência

Exemplo: Inconsistência de interface entre dois subsistemas.

Por ambiguidade

Exemplo: Um requisito descrito de maneira que tem diferentes interpretações.

Erros em softwares Em 1996 - Um software com uma exceção não tratada foi

responsável pela explosão do foguete Ariane-5, quando a 40 segapós a iniciação da sequência de voo, o foguete se desviou de sua rota, partiu e explodiu, tendo um prejuízo de 500 milhões de dólares.

http://www.ime.uerj.br/~demoura/Especializ/Ariane/

Therac-25 era uma máquina de radioterapia controlada por computador, muito moderna para sua época, por permitir a utilização do mesmo equipamento para a aplicação de diversas doses de radiação nos pacientes. Houve uma série de pelo menos 6 acidentes entre 1985 e 1987, nos quais os pacientes receberam overdose de radiação. Pelo menos cinco mortes aconteceram devido aos acidentes, causados por erros no software que controlava a máquina. Este acidente mostrou o perigo que reside em softwares que controlam operações de segurança.Estadao.com.br

Custo do defeito

Mitos sobre testes

O testador é inimigo do desenvolvedor

Os testadores devem ser os desenvolvedores menos

qualificados

O sistema esta pronto quando o desenvolvedor termina

de codificar

Um programador consegue testar eficientemente seu

próprio código

Possíveis etapas

O líder de revisão define os membros revisores;

O autor do produto apresenta suas ideias e perspectivas utilizadas;

Cada revisor familiariza-se individualmente com o produto e o revisa;

O líder convoca a reunião de revisão;

Na reunião o autor apresenta o produto e os revisores identificam os defeitos;

Uma lista de possíveis defeitos é preparada e enviada para o autor;

O autor corrige os defeitos ou explica os motivos que levam alguns deles a não representar problemas reais.

Reunião de revisão

DINÂMICA DE GRUPO PARA A REVISÃO

MODERADOR NAS REUNIÕES DE REVISÃO

REVISÃO DE PRODUTOS DE ESPECIFICAÇÃO E DE ANÁLISE

ENTREVISTAS

REVISÕES DAS ESPECIFICAÇÕES

CHECK LIST PARA AS REVISÕES

TÉCNICAS DE LEITURA

EXEMPLO: CHECK LIST PARA REVISÃO

DE CÓDIGOS DE PROGRAMA Relativos aos dados:

1) Todas as variáveis são inicializadas?

2) O limite superior de dados do vetor é menor do que o tamanho do vetor?

3) Existe a possibilidade de “over flow” de buffer?

Relativo ao controle de execução:

1) Para cada instrução condicional, a condição está correta?

2) Cada loop terminará corretamente?

3) Nas instruções CASE, todos os casos aparecem?

Relativo à interface

1) Todas as chamadas de rotinas têm o número correto de parâmetros?

2) Os tipos de parâmetro combinam?

3) A ordem dos parâmetros está correta ?

Relativo à entrada e saída de dados

1) Todas as variáveis de entrada são utilizadas ?

2) Todas as variáveis de saída recebem atribuições antes do final da execução ?

3) Dados de entrada inesperadas podem causar erros ?

Relativos a situações de erros e exceções

1) Todas as condições de erros/exceções foram levadas em conta?

Técnicas de leitura

Leitura de artefatos com foco voltado para uma

perspectiva distinta e relacionada a uma classe de

usuário na revisão de requisitos.

OORT (Object Oriented Reading Techniques) - leitura

orientada a objetos propõem a leitura comparativa de

artefatos em processos horizontais de leitura para os

diagramas e com processos verticais de leitura para a

verificação da consistência desses artefatos com os

requisitos do sistema.

Leitura horizontal

L

e

i

t

u

r

a

v

e

r

t

i

c

a

l

Teste de software

“The process of operating a system or component under

specified conditions, observing or recording the results,

and making an evaluation of some aspect of the system

or component.”

Tipos de teste de software

Teste de Caixa – Branca – Estrutural

Teste de unidade

Teste de integração

Teste de Caixa – Preta - Funcional

Teste funcional

Teste de aceitação

Teste exploratório

Teste de caixa – cinza

Teste de regressão

Teste de cobertura

Níveis de teste

Nível de testes

Atributos

Nível dos testes

unitários integração De sistema De aceitação

Escopo unidades Conjunto de

unidades

agrupadas

Sistema todo Sistema todo

Equipe desenvolvedores Desenvolvedore

s e analistas de

sistema

Analista de

teste e

testadores

Analista de

testes,

testadores e

usuários

Origem dos

dados

Criação manual Criação manual Criação

automática

dados reais

Dados reais

Volume dos

dados

pequeno pequeno grande grande

Interfaces não não Simuladas/reais Reais

ambientes desenvolvimento desenvolviment

o

testes Testes/produçã

o