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
Recommended