ResumoLivroBaseConhecimentoTesteSoftware
37 pág.

ResumoLivroBaseConhecimentoTesteSoftware


DisciplinaTestes de Software676 materiais7.100 seguidores
Pré-visualização9 páginas
\u2022 Teste de contingência ou recuperação;
\u2022 Teste de operação;
\u2022 Teste de conformidade; (processo)
\u2022 Teste de segurança.
 
Os testes estrutural e funcional, podem ser realizados com o emprego de um conjunto pré-determinado de 
técnicas. Selecionada a técnica, é preciso determinar um método de teste para implementá-la, que pode ser 
dinâmico ou estático. As técnicas dinâmicas determinam se o sistema funciona corretamente quando está 
rodando, e o teste estático \u201colha\u201d para o sistema quando este não é executado.
 
A análise dinâmica requer que o programa seja executado.
 
A análise estática, por outro lado, não envolve a execução do programa. Entre as técnicas comuns de análise 
estática temos as tarefas que verificam a sintaxe.
 
Uma ferramenta é um veículo para executar um processo de teste, é um recurso para o testador, mas sozinha, é 
insuficiente para a condução de um teste.
 
Estágio ou nível de teste
 
É uma das dimensões do teste que representa o \u201cquando\u201d, ou melhor, a que fase do desenvolvimento se aplica 
determinado teste.
 
Teste de unidade; Costuma ser feito pelo programador e testa as unidades individuais: funções, objetos e 
componentes.
 
Teste de iteração ou integração; Em geral, é realizado pelo analista de sistemas para um módulo ou conjunto de 
programas.
 
Teste de Sistema; Costuma se feito pelo analista de teste (caso de teste) em ambiente de teste.
 
Teste de aceitação; Sua execução é de responsabilidade do cliente. Em geral é feito pelo usuário em ambiente de 
homologação.
Capítulo 7 \u2013 Execução dos testes
 Segundo Cem Kaner:
 
No teste estático, o código é examinado.
No teste dinâmico, o código é testado.
 
Conforme já definido, os testes devem ser executados em todas as etapas do ciclo de vida do processo de 
desenvolvimento de software, desde os requisitos até o teste de aceitação, na fase de homologar e liberar o 
software para a produção. O projeto de teste deve ser desenvolvido em paralelo e estar integrado ao projeto de 
desenvolvimento.
 
A responsabilidade de cada um na execução dos testes devem ser documentadas no Plano de Teste. Por 
exemplo, os programadores ou desenvolvedores sãoresponsáveis pela execução dos testes unitários, ao passo 
que os testadores são os responsáveis pela execução dos testes de sistema.
 
Responsáveis pelos testes:
 
\u2022 Testes Unitários -- Programadores
\u2022 Testes de Integração -- Analistas de Sistemas
\u2022 Testes de Sistema -- Analistas de Testes
\u2022 Testes de Aceitação -- Usuários com a ajuda dos Analistas de Testes.
 
O plano de teste deve incluir todos os elementos necessários para que os testes sejam executados corretamente. 
Como elementos podemos considerar os procedimentos a serem cumpridos, o ambiente necessário e as 
ferramentas.
 
1.1. Teste Unitário
 
Os testes unitários devem ser feitos pelos programadores e garantir o funcionamento adequado do programa.
 
1.2. Teste de Integração
 
O teste de integração deve ter início quando os componentes a ser integrados já tenham passado pelo teste 
unitário. Esse tipo de teste deve ser executado pelo Analista de Sistemas, restando ao Analista de Teste a 
responsabilidade de testar o sistema.
 
O teste de integração deve garantir que os componentes da aplicação, ou daquele módulo de aplicação, possam 
ser integrados com sucesso para executar determinada funcionalidade.
 
Considerando as aplicações cliente/servidor, o teste de integração deve levar em conta as seguintes camadas:
 
\u2022 Camada de apresentação;
\u2022 Camada de execução;
\u2022 Camada de dados;
\u2022 Camada de rede.
1.3. Teste de Sistema
 
O teste de sistema deverá ter início apenas quando o teste de integração for dado como encerrado, ou seja, 
executado com sucesso. Por outro lado, o teste de sistema será dado como terminado quando a equipe de teste 
perceber que a aplicação está apta a ser liberada para a produção.
 
Para o sucesso na execução dos testes de sistema, algumas atividades devem ser seguidas:
 
\u2022 O ambiente de teste deve ser semelhando ao de produção;
\u2022 Devem ser criados casos de teste, de preferência com uso de ferramentas;
\u2022 Devem ser definidos os casos de testes que serão executados;
\u2022 Preparar os scripts ou procedimentos a serem seguidos pelos testadores;
\u2022 Avaliar os resultados e identificar problemas encontrados;
\u2022 Registrar defeitos, de preferências em um sistema de gestão de defeitos;
\u2022 Re-testar defeitos corrigidos. Fechar ou reabri o defeito, se não corrigido;
\u2022 Garantir que os ciclos de testes foram cumpridos.
 
O teste de sistema precisa garantir que os requisitos do software foram cumpridos, e implementados 
corretamente. Posteriormente, a aplicação ainda passará pelo teste de aceitação, que será conduzido pelos 
próprios usuários com o apoio da equipe de teste.
 
1.4. Teste de Aceitação
 
O teste de aceitação é realizado pelos usuários ou gestores do software para garantir que tudo que foi definido 
por eles nos requisitos tenha sido incluído no produto que lhes está sendo entregue. Muitas vezes recebem 
auxílio dos testadores.
 
1.5. Quando o teste termina?
 
Algumas métricas podem auxiliar o gerente de teste a tomar a decisão de liberar ou não a aplicação para 
produção. Podemos destacar:
 
\u2022 Tempo médio entre defeitos encontrados;
\u2022 Porcentagem de cobertura alcançada na aplicação do teste;
\u2022 Número de defeitos encontrados e ainda não corrigidos por grau de severidade;
\u2022 Avaliar os riscos envolvidos com a liberação da aplicação para produção, comparando tias riscos com os riscos 
da não-liberação.
 
1.6. Considerações
 
Existem algumas considerações ou preocupações que os testadores devem sempre levar em conta durante a 
execução dos testes:
 
\u2022 O software ainda não está em condições de ser testado adequadamente;
\u2022 Os recursos ou o prazo são insuficientes;
\u2022 Problemas importantes não serão revelados durante os testes;
\u2022 Atenção com o que vai ser testado.
1.7. Processo de execução de testes
 
Para que seja bem sucedida, a etapa de execução dos testes, dentro do ciclo de vida dos testes, vai depender de 
tudo que foi feito anteriormente e que servirá de base para o cumprimento dessa etapa.
 
Um pré-requisito para o início desta etapa é o Plano de Teste.
 
1.7.1. Teste segundo as características de qualidade de software
 
Tendo como base algumas características ou sub-características da norma ISO 9126-1, listamos alguns tipos de 
testes que se enquadram para atender as características listadas:
\u2022 Funcionalidade
\u2022Teste de Autorização;
\u2022Teste de Integridade dos arquivos;
\u2022Teste de Trilha de auditoria;
\u2022Teste de Conformidade com a metodologia;
\u2022Teste Negativo
\u2022 Continuidade
\u2022Teste de Recuperação;
\u2022Segurança
\u2022Teste de Segurança
\u2022Performance
\u2022Teste de Estresse;
\u2022Teste de Performance;
\u2022Usabilidade
\u2022Teste Manual;
\u2022Manutenibilidade
\u2022Inspeções
\u2022Portabilidade
\u2022Teste de Desastre;
\u2022Conectividade
\u2022Teste de Regressão;
\u2022Teste de Conexão;
\u2022Operacionalidade
\u2022Teste Operacional.
Capítulo 8 \u2013 Gestão de Defeitos
 
Erro: resultado de uma falha humana.
Defeito: resultado de um erro existente num código ou num documento.
 
O processo de gestão de defeitos se baseia nos seguintes princípios:
 
\u2022 O objetivo primordial é evitar defeitos;
\u2022 Um dos princípios básicos para evitar defeitos é minimizar riscos, não só do projeto de desenvolvimento, mas 
também do projeto de teste;
\u2022 Integração entre desenvolvedores e testadores através de uma ferramenta de gestão de defeitos;
\u2022 Automação da gestão de defeitos é um fator muito importante para o sucesso;
\u2022 Melhoria contínua e
\u2022 Utilizar práticas de modelos de processo (Ex: CMMI).
 1.8. Conceito de defeito 
O Defeito ocorre em função de algum desvio em relação ao requisito:
 
\u2022 Defeitos decorrentes de falta de concordância com a especificação do produto As especificações dizem uma \uf0e0
coisa e o software faz outra.
\u2022 Defeitos decorrentes de situações inesperadas, mas não definidas nas especificações do produto O gestor ou\uf0e0 
usuário não definiu nada nas especificações, porém o software age de maneira inesperada em determinadas 
situações.
 
No entanto, defeitos