Buscar

RESUMO CCT0427 TESTES DE SOFTWARE AVALIAÇÃO DIA 22 11

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 3, do total de 4 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Prévia do material em texto

Alguns conceitos e afirmativas sobre Testes de Softwares, segundo Michael Fargan e 
Glenford Myers (1976 e 1979): 
• Os testes unitários podem remover entre 30% e 50% dos defeitos dos programas. 
• Os testes de sistema podem remover entre 30% e 50% dos defeitos remanescentes. 
• Desse modo, os sistemas podem ir para produção ainda com aproximadamente 49% 
de defeitos. 
• As revisões de códigos podem reduzir entre 20% e 30% desses defeitos. 
Outros conceitos sobre testes de software: 
• Teste baseado em modelos é uma forma de teste de software onde os casos de teste 
são derivados de um modelo que descreve aspectos (geralmente funcionais) do 
sistema sendo testado. O nível de automação no processo de teste pode ser 
classificado de acordo com as etapas do processo que são automatizadas. 
• Testes de software buscam por erros ou anomalias em requisitos funcionais e não 
funcionais. 
• Quanto aos Testes de Unidade: 
o Possuem como uma tarefa essencial o teste seletivo de caminhos de execução. 
Casos de teste devem ser projetados para descobrir erros devidos a cálculos 
errados, comparações incorretas ou fluxo de controle inadequado. 
o Testam as condições-limite para garantir que o componente/módulo opere 
adequadamente nos limiares conhecidos para limitar ou restringir o 
processamento. 
o Testam a interface do módulo/componente para garantir que a informação 
flua adequadamente para dentro e para fora da unidade de programa que está 
sendo testada. 
o Exercitam todos os caminhos básicos ao longo da estrutura de controle para 
garantirem que todos os comandos do módulo/componente tenham sido 
executados pelo menos uma vez. 
o Testes de unidade são obrigatoriamente executados pelo próprio 
desenvolvedor. 
• No Teste de Validação, o foco está no nível de requisitos e podem ser divididos em 
dois tipos: 
o Teste Alfa; e 
o Teste Beta. 
• São técnicas típicas de Testes de Caixa Preta: 
o Teste de todos os pares; 
o Tabelas de estado de transição; 
o Teste de tabela de decisão; 
o Teste de caso de uso; 
• São técnicas típicas de Testes de Caixa Branca: 
o Teste de integração; 
o Teste de fluxo de dados; 
 
o Teste de ciclo; 
o Teste do caminho básico/lógico; 
o Teste de estrutura de controle; 
Níveis de teste, Modelo V de desenvolvimento de software e Testes de software. 
Níveis de Teste: 
Teste de Unidade: também conhecido como testes unitários. Tem por objetivo explorar a 
menor unidade do projeto, procurando provocar falhas ocasionadas por defeitos de lógica e de 
implementação em cada módulo, separadamente. O universo alvo desse tipo de teste são os 
métodos dos objetos ou mesmo pequenos trechos de código. 
Teste de Integração: visa provocar falhas associadas às interfaces entre os módulos quando 
esses são integrados para construir a estrutura do software que foi estabelecida na fase de 
projeto. 
Teste de Sistema: avalia o software em busca de falhas por meio da utilização do mesmo, 
como se fosse um usuário final. Dessa maneira, os testes são executados nos mesmos 
ambientes, com as mesmas condições e com os mesmos dados de entrada que um usuário 
utilizaria no seu dia-a-dia de manipulação do software. Verifica se o produto satisfaz seus 
requisitos. 
Teste de Aceitação: são realizados geralmente por um restrito grupo de usuários finais do 
sistema. Esses simulam operações de rotina do sistema de modo a verificar se seu 
comportamento está de acordo com o solicitado. 
Modelo V de desenvolvimento de software: 
Através da figura abaixo podemos visualizar que para cada atividade do desenvolvimento uma 
atividade de testes deve ser realizada. 
 
Modelo V descrevendo o paralelismo entre as atividades de desenvolvimento e teste de 
software. (CRAIG e JASKIEL, 2002) 
 
O planejamento do software e o projeto dos testes devem ocorrer de cima para baixo, ou seja: 
1. Inicialmente é planejado o teste de aceitação a partir do documento de requisitos; 
2. Após isso, é planejado o teste de sistema a partir do projeto de alto nível do software; 
3. Em seguida, ocorre o planejamento dos testes de integração a partir o projeto detalhado; 
4. E por fim, o planejamento dos testes a partir da codificação. 
Já a execução ocorre no sentido inverso, ou seja, de baixo para cima. 
Outros tipos de Testes 
Teste de recuperação: no contexto da engenharia de software, é um teste utilizado para 
verificar a robustez e também a capacidade de um determinado software para retornar a um 
estado operacional após estar em um estado de falha. 
Teste de Requisitos: Verifica se o sistema é executado conforme o que foi especificado. São 
realizados através da criação de condições de testes e cheklists de funcionalidades. 
Teste de Regressão: Testa se algo mudou em relação ao que já estava funcionando 
corretamente, ou seja, é voltar a testar segmentos já testados após uma mudança em outra 
parte do software. Os testes de regressão devem ser feitos tanto no software quanto na 
documentação. 
Teste de Tratamento de Erros: Determina a capacidade do software de tratar transações 
incorretas. Esse tipo de teste requer que o testador pense negativamente e conduza testes 
como: entrar com dados cadastrais impróprios, tais como preços, salários, etc., para 
determinar o comportamento do software na gestão desses erros. Produzir um conjunto de 
transações contendo erros e introduzi-los no sistema para determinar se este administra os 
problemas. 
Teste de Suporte Manual: Verifica se os procedimentos de suporte manual estão 
documentados e completos, determina se as responsabilidades pelo suporte manual foram 
estabelecidas. 
Teste de Interconexão: Garante que a interconexão entre os softwares de aplicação funcione 
corretamente. Pois, softwares de aplicação costumam estar conectados com outros softwares 
de mesmo tipo. 
Teste de Controle: Assegura que o processamento seja realizado conforme sua intenção. Entre 
os controles estão a validação de dados, a integridade dos arquivos, as trilhas de auditoria, o 
backup e a recuperação, a documentação, entre outros. 
Teste Paralelo: Comparar os resultados do sistema atual com a versão anterior determinando 
se os resultados do novo sistema são consistentes com o processamento do antigo sistema ou 
da antiga versão. O teste paralelo exige que os mesmos dados de entrada rodem em duas 
 
versões da mesma aplicação. Por exemplo: caso a versão mude e os requisitos não, os dados 
de saída das duas versões devem ser iguais. 
 
Teste de Software e as Normas ISO 
Norma ISO / IEC 9126 
Esta norma aborda os seguintes aspectos para determinar a qualidade de um 
aplicativo de software: 
• modelo de qualidade 
• métricas externas 
• métricas internas 
• Métricas de qualidade em uso 
Esta norma apresenta um conjunto de atributos de qualidade para qualquer 
software, tais como: 
• Funcionalidade 
• Confiabilidade 
• Usabilidade 
• Eficiência 
• Manutenibilidade 
• Portabilidade 
Norma ISO / IEC 9241-11 
Parte 11 desta norma trata da medida em que um produto pode ser usado por 
usuários específicos para atingir metas especificadas com eficácia, eficiência e satisfação em 
um contexto de uso especificado. 
Este padrão proposto um quadro que descreve os componentes de usabilidade e a 
relação entre eles. Neste padrão, a usabilidade é considerada em termos de desempenho e 
satisfação do usuário. De acordo com a ISO 9241-11, usabilidade depende do contexto de uso 
e o nível de usabilidade vai mudar como o contexto muda. 
Norma ISO / IEC 25000: 2005 
ISO / IEC 25000: 2005 é comumente conhecido como o padrão que fornece as 
diretrizes para Requisitos de Qualidade de Software e Avaliação. Esta norma ajuda a organizare realçar o processo em relação aos requisitos de qualidade de software e suas avaliações. Na 
realidade, ISO-25000 substitui as duas normas ISO antigos, ou seja, ISO-9126 e ISO-14598.

Outros materiais