MATERIAL COMPLETO - TESTES DE SOFTWARE

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Testes de Software/CCT0204 - Aula 1.ppt
*
TESTES DE SOFTWARE – AULA 1
Prof. Ulisses Sperle Graça
Revisão/2014
*
CONTEÚDO
Unidade 1 – Importância do teste de software 
O teste nas fases de desenvolvimento de um software. 
O teste na engenharia de sistemas e de programas
Unidade 2 - Teste no projeto de sistema 
Revisões Técnicas Formais
Validação pelo usuário 
*
*
Unidade 3 – Teste no programa
Depuração
Teste de caixa branca
Teste de caixa preta
Teste de ambiente Web
*
CONTEÚDO
*
Unidade 4 – Teste na implantação do sistema
Teste de Unidade
Teste de Integração
Teste de Validação
Teste de Sistema
Teste na Migração
*
CONTEÚDO
*
Unidade 5 – Teste de software em sistema em produção 
Teste de software nos diversos tipos de manutenção
Confiabilidade
Disponibilidade
Unidade 6 – Ferramentas de teste de software
Ferramentas de teste no desenvolvimento de sistema
Ferramentas de teste para o programa
Ferramentas de teste para o ambiente Web
Ferramentas de teste para sistemas em produção
*
CONTEÚDO
*
O desenvolvimento de sistemas envolve uma série de atividades em que as oportunidades de injeção de falhas são muito grandes. Estes erros podem começar a aparecer logo no início do processo, onde os objetivos podem estar erroneamente especificados, além de erros que venham a ocorrer em fases de projeto e desenvolvimento posteriores.
*
A IMPORTÂNCIA DO TESTE
*
Por causa da inabilidade humana de realizar e de se comunicar com perfeição, o desenvolvimento é acompanhado de garantia de qualidade.
A atividade de teste de software é um elemento crítico da garantia de qualidade de software e representa a última revisão de especificação, projeto e codificação.
*
A IMPORTÂNCIA DO TESTE
*
CUSTO DO REPARO
*
Custo
Estágio de
desenvolvimento
Requisitos
Codificação
Entrega
*
A IMPORTÂNCIA DO TESTE
Não é raro gastarmos entre 30 e 40% do esforço total do projeto no Teste de Software.
O Teste de Software para ambientes críticos (ex.: controle de voo, monitoramento de reatores nucleares e etc.) pode custar de três a cinco vezes mais do que todos os outros passos de engenharia de software combinados.
*
*
*
*
DEFININDO O TESTE DE SOFTWARE
Avaliar se o software está fazendo o que deveria fazer, de acordo com os seu requisitos, e não está fazendo o que não deveria fazer;
Qualquer atividade que, a partir da avaliação de um atributo ou capacidade de um programa ou sistema, seja possível determinar se ele alcança os resultados desejados. (Bill Hetzel – 1988).
Processo de executar um programa ou sistema com a intenção de encontrar defeitos (Glen Myers – 1979);
*
*
Segundo Pressman, o teste de software é um conjunto de atividades que podem ser planejadas com antecedência e executadas sistematicamente. 
 
Uma estratégia de teste de software deve acomodar testes de baixo nível, necessários para verificar se um pequeno segmento de código fonte foi implementado corretamente, bem como testes de alto nível, que validam as funções principais do sistema de acordo com os requisitos do cliente.
*
DEFININDO O TESTE DE SOFTWARE
*
A atividade de teste é um passo do processo de Engenharia de Software que visa encontrar/corrigir erros ao longo do software que foi construído.
Testes podem ser usados para descobrir a presença de erros, mas não para mostrar a sua ausência.
Testes de software é o processo de executar o software de uma maneira controlada com o objetivo de descobrir dife-renças entre o comportamento previsto e o comportamento observado.
*
DEFININDO O TESTE DE SOFTWARE
*
Todas estratégias fornecem um modelo para o teste e têm basicamente as seguintes características:
 Para executar um teste eficaz, proceder a revisões técnicas eficazes. Fazendo isso, muitos erros serão eliminados antes do começo do teste.
O teste começa no nível do componente e progride em direção à integração do sistema computacional como um todo.
*
ESTRATÉGIAS DE TESTE
*
Todas estratégias fornecem um modelo para o teste e têm basicamente as seguintes características:
 Diferentes técnicas de teste são apropriadas para diferentes abordagens de engenharia de software e em diferentes momentos
 O teste é feito pelo desenvolvedor do software e (para grandes projetos) por um grupo independente de teste.
 O teste e a depuração são atividades diferentes, mas a depuração ocorre em consequência de um teste.
*
ESTRATÉGIAS DE TESTE
*
A atividade de teste é o processo de executar um programa com a intenção de descobrir um erro.
Um bom caso de teste é aquele que possui uma elevada probabilidade de revelar um erro ainda não descoberto.
Um teste bem-sucedido é aquele que revela um erro ainda não descoberto.
*
ESTRATÉGIAS DE TESTE
*
DIRETRIZES PARA O TESTE
Determinar quando o teste deve ser interrompido.
Atribuir a responsabilidade do teste a um testador.
Descrever os resultados esperados para cada caso de teste.
Escrever casos de teste para condições de entrada válidas e inválidas.
Inspecionar o resultado de cada teste por completo.
Alocar os programadores mais criativos para teste.
*
*
O PROCESSO DE TESTE
O processo de teste de software deve basear-se em uma metodologia aderente ao processo de desenvolvimento, com pessoal técnico qualificado, ambiente e ferramentas adequadas.
Esta metodologia de teste deve ser o documento básico para organizar a atividade de testar aplicações no contexto da empresa. Assim como o processo de desenvolvimento de software, teste de software também possui um ciclo de vida: 
*
*
O PROCESSO DE TESTE
*
Procedimentos
Iniciais
Especificação
Execução
Entrega
Planejamento
Preparação
*
O PROCESSO DE TESTE
Planejamento: Elaboração e revisão da Estratégia de teste e do plano de teste;
 
Preparação: Preparação do ambiente de teste, incluindo equipamentos, rede, pessoal, software e ferramentas.
*
*
O PROCESSO DE TESTE
Procedimentos iniciais: Consiste na elaboração de documento com o estabelecimento de um acordo entre as partes envolvidas no projeto de teste (usuários e técnicos):  
Objetivo do projeto de teste,
Pessoal a ser envolvido,
As responsabilidades de cada um;
O plano preliminar de trabalho;
Avaliação dos riscos;
Os níveis de serviços acordados e etc.
*
*
O PROCESSO DE TESTE
Especificação: Elaboração e revisão dos casos de teste , “scripts” ( no caso de ferramentas de automação de testes) e dos roteiros de Teste e execução dos testes de verificação da documentação do sistema (testes estáticos).
 Execução: Execução dos testes planejados conforme os Casos de Teste, “scripts” e dos roteiros de Teste com os correspondentes registros dos resultados obtidos.
 Entrega: conclusão do processo de testes com a entrega do sistema para o ambiente de produção.
*
*
INTERAÇÃO ENTRE OS CICLOS DE VIDA
*
*
O PROCESSO DE TESTE
Há muitas estratégias que podem ser utilizadas para testar um software. Uma das estratégias de teste que é preferida pela maioria das equipes é a visão incremental do teste, começando com o teste das unidades individuais de programa, passando para os testes destinados a facilitar a integração de unidades e culminando com testes que usam o sistema concluído. 
Verificação: Nesta etapa são realizadas inspeções/revisões sobre os produtos gerados. 
*
*
O PROCESSO DE TESTE
Testes Unitários: São realizados no estágio mais baixo da escala de testes e são aplicados nas menores componentes de códigos criados, visando garantir que estes atendem as especificações, em termos de garantia e de funcionalidade. Verificam
o funcionamento de um pedaço do sistema ou software isoladamente ou que possam ser testado separadamente.
Normalmente é feito pelos desenvolvedores.
*
*
O PROCESSO DE TESTE
Testes de integração: São executados em uma combinação de componentes para verificar se ele funcionam corretamente juntos, conforme as especificações. Componentes podem ser pedaços de código, módulos, aplicações distintas, clientes servidores. Normalmente é feito pelos desenvolvedores.
*
*
O PROCESSO DE TESTE
Teste de sistema: São realizados pela equipe de testes, visando a execução do sistema como um todo ou um subsistema (parte de um sistema), dentro de um ambiente operacional controlado, para validar a exatidão e perfeição na execução de suas funções. Neste estágio de teste deve ser simulada a operação normal do sistema, sendo testadas todas as suas funções de forma mais próxima possível do que irá ocorrer no ambiente de produção. Esses testes são feitos pela equipe de teste de software.
*
*
O PROCESSO DE TESTE
Teste de aceitação: São os testes finais de execução do sistema, realizados pelos usuários, visando verificar se a solução atende aos objetivos do negócio e aos seus requisitos, no que diz respeito À funcionalidade e usabilidade, antes da sua utilização no ambinete de produção.
*
*
O PROCESSO DE TESTE
Ao tratar os testes como um processo organizado e muitas vezes paralelo e integrado ao processo de desenvolvimento, os custos de manutenção serão reduzidos. Segundo Myers, o custo de correção de defeitos tende a aumentar quanto mais tarde o defeito é detectado. Defeitos encontrados durante a produção tendem a custar muito mais que defeitos encontrados em modelos de dados e em outros documentos do projeto do software.
*
*
O PROCESSO DE TESTE
Os testes unitários podem remover entre 30% e 50 % dos defeitos dos programas;
 Os testes de sistemas podem remover entre 30% e 50% dos defeitos remanescentes.
 Desse modo, os sistemas podem ir para produção ainda com aproximadamente 49% de defeitos.
 Por últimos, as revisões de códigos podem reduzir entre 20% e 30% desses defeitos.
*
*
Testes de Software/CCT0204 - Aula 10.ppt
*
TESTES DE SOFTWARE – AULA 10
Ulisses Sperle Graça
Rio de Janeiro, outubro de 2011
FERRAMENTAS 
DE TESTE DE SOFTWARE
*
Estudar as técnicas de teste automatizado de software e suas limitações;
Analisar o uso de ferramentas de teste automatizado no desenvolvimento de sistema;
Analisar as principais ferramentas de teste automatizado de software;
Resumo da Disciplina.
*
OBJETIVOS DESTA AULA
*
Por muitos anos os testes de software foram feitos com simulação das situações criadas pelos programadores e/ou analistas utilizando dados fictícios ou amostra dos dados reais.
Estes dados eram gerados manualmente ou através da utilização de programas temporários preparados especificamente para este fim.
*
INTRODUÇÃO
*
Com o avanço das tecnologias como o advento das interfaces gráficas (GUI) e da Internet, por exemplo, os sistemas tornaram-se muito mais complexos. 
 Nesta aula serão abordadas as diferenças entre teste e automação de testes. Será discutida a limitação dos testes automatizados e apresentada as diferentes técnicas utilizadas na automatização. 
*
INTRODUÇÃO
*
Analisaremos o uso de ferramentas de teste automatizado no desenvolvimento de sistema e as principais ferramentas de teste automatizado de software utilizadas atualmente.
*
INTRODUÇÃO
*
Vale lembrar que nas aulas anteriores estudamos que as revisões e testes são os instrumentos de controle de qualidade de um projeto de desenvolvimento de software.
Estudamos também que o processo de teste está inserido em todo o ciclo de vida do desenvolvimento da aplicação, desta forma, serão apresentadas diversas ferramentas de apoio a tais atividades, que variam quanto a parâmetros e técnicas implementadas, e ainda, pelas linguagens suportadas. 
*
INTRODUÇÃO
*
O que é Automação de teste?
A diferença entre testes e automação de testes, é que no primeiro você realiza a tarefa de testar, e no segundo você usa um software que imita a interação com a aplicação no que se refere ao teste tal qual um ser humano faria (Graham e Fewster,1999).
*
AUTOMAÇÃO DO TESTE DE SOFTWARE
*
O conceito de testes manuais é a utilização de recursos humanos para realizar todos os procedimentos de testes especificados. Este tipo de teste requer um número grande de profissionais e um controle eficiente de documentos em circulação. O risco inerente a esse tipo de teste é a grande incidência de erros humanos no processo devido a:
A não execução dos procedimentos na ordem estabelecida.
A valores digitados erradamente.
*
AUTOMAÇÃO DO TESTE DE SOFTWARE
*
Os testes automatizados utilizam ferramentas de testes que possibilitem simular usuários ou atividades humanas de forma a não requerer procedimentos manuais no processo de execução dos testes. Entretanto requerem profissionais especializados e tempo no desenvolvimento da automação dos testes.
*
AUTOMAÇÃO DO TESTE DE SOFTWARE
*
Teste Regressivo
Quando temos nova versão de software e comparamos com a versão anterior, o teste é em função de algo do passado.
Teste Progressivo
Quando utilizamos um script de teste de desempenho para simular a quantidade de 1.000 usuários virtuais e depois reexecutamos numa nova versão do sistema usando agora 2.000, desejamos ver o comportamento futuro do sistema.
*
TIPOS DE TESTE AUTOMATIZADO
*
Para agilizar e automatizar o processo de teste a maioria das ferramentas de automação de testes apresentam como principais características:
 
Gravador: Quase todas as ferramentas possuem de alguma forma um gravador que, uma vez acionado, grava, na forma de uma linguagem interna (seja visual ou não) tudo que o usuário fizer, ficando armazenado no script de teste.
 
Script de teste: Uma vez acionado pelo executor de testes, o script entra em execução, pois o que foi gravado vai sendo repetido.
*
TÉCNICAS DE TESTE AUTOMATIZADO
*
Para agilizar e automatizar o processo de teste a maioria das ferramentas de automação de testes apresentam como principais características (cont.):
 
Executor de teste ou playback: recurso da ferramenta que executa o que foi gravado ou registrado no script de teste. Cada ferramenta implementa este recurso de uma forma, porém todas fazem a mesma coisa.
 
Data-driven test ou teste dirigido a dados: Consiste em criar um script e depois fazer isso de uma massa de dados que será executada no script, dirigindo a forma como será executado assim como a quantidade de vezes que ele será executado.
*
TÉCNICAS DE TESTE AUTOMATIZADO
*
Segundo Graham e Fewster (1999), existem diferentes estratégias consideradas ao se projetar e escrever scripts de teste:
Scripts lineares;
Acripts estruturados e scripts compartilhados;
Data-driven scripts(técnica orientada a dados);
Keyword-driven scripts(técnica orientada a palavras chave).
*
TÉCNICAS DE TESTE AUTOMATIZADO
*
Scripts lineares
 
É uma técnica que faz gravação ou replicação direta das ações do teste sem nada acrescentar. Esta técnica consiste em gravar as ações executadas por um usuário sobre a interface gráfica de uma aplicação e converter estas ações em scripts de teste que podem ser executadas quantas vezes for necessário.
*
TÉCNICAS DE TESTE AUTOMATIZADO
*
Scripts estruturados ou scripts compartilhados
Esta técnica aciona mais de um comando simulando a execução em paralelo de diversas ações. Na técnica de scripts compartilhados os scripts podem ser utilizados em mais de uma caso de teste e tendem a ser scripts genéricos como login e
logout, por exemplo. Ambas as técnicas são uma extensão da técnica de scripts lineares possibilitando que os scripts de teste gravados sejam, alterados para que desempenhem um comportamento diferente.
*
TÉCNICAS DE TESTE AUTOMATIZADO
*
Data-driven scripts (técnica orientada a dados)
 
É uma técnica que separa os dados usados pelo script do script em si. Consiste em extrair dos scripts de teste os dados de teste e armazená-los em arquivos separados da lógica de execução devido ao alto volume de dados. Uma das vantagens na utilização desta técnica é a possibilidade da utilização do mesmo script com diferentes arquivos de dados, em diferentes formatos. 
*
TÉCNICAS DE TESTE AUTOMATIZADO
*
Keyword-driven scripts (técnica orientada a palavras chave)
 
Técnica muito semelhante ao data-driven script, porém neste caso utiliza palavras-chaves ou ações específicas que são usadas constantemente em mais de um script. Consiste em extrair dos scripts de teste, o procedimento de teste que representa a lógica de execução.    
*
TÉCNICAS DE TESTE AUTOMATIZADO
*
As revisões e testes são instrumentos de controle de qualidade de um projeto. Existem diversas ferramentas de apoio a tais atividades, que variam tanto quanto a parâmetros como técnicas implementadas e linguagens suportadas: 
Ferramentas de Planejamento de testes;
Ferramentas de Revisões e Inspeções;
Ferramentas de Modelagem e Automação;
Ferramentas de Suporte aos Testes;
Ferramentas de execução e conferência;
Ferramentas de Revisões e Inspeções.
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de Planejamento de Testes
Esta categoria de ferramenta apoia o processo de planeja-mento dos trabalhos de testes, definindo escopos, abordagens, agendando reuniões e programando atividades.
Auxiliam no processo de documentação inicial, possibilitando gerar planejamentos padronizados e na elaboração de estimativas de tempo e custo, além de dimensionar as equipes de acordo com o tempo disponível.
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de Planejamento de Testes (cont.)
Estas informações são geradas a partir da coleta inicial de requisitos de software que irão possibilitar dimensionar o esforço e complexidade envolvida no processo de desenvolvimento. As principais características destas ferramentas são a análise de criticidade e a geração de documentos.
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de Planejamento de Testes (cont.)
A análise de criticidade permite direcionar esforços de forma eficiente, através da priorização dos sistemas, indicando quais sistemas devem ser testados inicialmente. Permite também estimar tempo, custos e equipes através da análise da complexidade de cada software, baseando-se nos requisitos a serem cumpridos.
 
A geração de documentos facilita o processo de documentação, através da utilização de parametrizações e modelos de documentos. Permitem também gerenciar as versões dos modelos e ainda possibilitam organizar workflow de preparação, elaboração, inspeção e aceite dos documentos. 
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de Revisões e Inspeções
 
Auxiliam nas revisões de documentos e inspeções técnicas que podem ser aplicadas em todas as etapas do processo de desenvolvimento. Principais características:
 
 
 Fonte: Bartié, 2002
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de Revisões e Inspeções (cont.)
A análise de complexidade auxilia a identificar onde estão as áreas mais complexas e quais possuem maior risco de introduzir novos erros, além de quantificar o esforço e os custos dos testes a serem empregados.
 
A análise sintática e de semântica localiza erros na sintaxe e na semântica dos comandos empregados no código, os quais o compilador não acusaria, sendo possível detectar defeitos antes de os testes formais serem iniciados.
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de Revisões e Inspeções (cont.)
A compreensão de código auxilia a inspecionar os códigos-fontes, possibilitando avaliar a aderência a padrões de programação estabelecidos pela organização. Exemplos:
Padrão de nome,
Utilização de rotinas corporativas,
Variáveis não utilizadas, 
Sub-rotinas internas não acionadas, 
APIs incompatíveis com determinados SOs.
 
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de Modelagem e Automação
As ferramentas de modelagem auxiliam no processo de construção e documentação de como serão testados todos os requisitos de negócio, possibilitando registrar todos os procedimentos de teste a cada cenário estabelecido e ainda o processo de conferência dos dados. 
Estas ferramentas possibilitam o desenvolvimento de scripts automatizados.
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de Modelagem e Automação (cont.)
As principais características destas ferramentas são:
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de Modelagem e Automação (cont.)
 
A modelagem de testes auxilia nos processos de planejamento e construção dos testes, identificado os diversos cenários estabelecidos para cada requisito a ser testado. Determina as informações que devem ser empregadas em cada procedimento de teste, atingindo o menor nível de detalhamento. 
Lembre que a modelagem dos testes é um processo mental, assim nenhuma ferramenta substituirá a expe-riência e abstração de um bom analista de testes, porém estas ferramentas auxiliam na estruturação das ideias.
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de Modelagem e Automação (cont.)
 
A geração de massa de dados possibilita a geração automática de massa de dados baseada no planejamento dos testes e critérios estabelecidos de forma a garantir uma massa diferenciada e nas circunstâncias desejadas.
 
A automação de scripts possibilita a interação entre as rotinas automatizadas e os softwares a serem testados através da captura de valores em telas, arquivos, relatórios ou mesmo em banco de dados. Permitem automatizar não somente as atividades de entrada, como o processo de conferência (análise da saída das informações).
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de Execução e Conferência
 
Possibilitam o gerenciamento e o controle do processo de execução, reexecução e medição dos testes planejados. Possibilitam integra-ção entre as demais fases, de forma a executar os testes seleciona-dos no planejamento. Suas principais características são:
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de Execução e Conferência (cont.)
A análise de cobertura possibilita estabelecer uma métrica de cobertura do teste através do monitoramento das linhas de código executadas. Os testes de caixa branca requerem esse tipo de ferramenta, pois possibilita visualizar áreas do código não cobertas pelos testes em execução.
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de Execução e Conferência (cont.)
Como estas ferramentas são normalmente integradas aos softwares de planejamento de testes e desenvolvimento de scripts, o executor de scripts permite executar os procedimentos na ordem e frequências preestabelecidas. Permite também a gestão do ciclo de testes como um todo, com o controle de execução de cada caso de testes, o controle da reexecução dos testes e os desvios de testes provocados por erros inesperados.
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de Execução e Conferência (cont.)
Os testadores de memória auxiliam no processo de detecção de problemas em relação ao uso e alocação de memória pela aplicação. Sendo assim devem ser específicas para cada linguagem e ambiente.
 
Os simuladores e medidores de performance estão diretamente ligados aos testes de sistema, como os testes de carga, de volume
e de performance, já que nessa categoria é impossível conceber a ideia de realizar testes sem empregar ferramentas específicas.
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de suporte aos testes
Estas ferramentas apoiam atividades que não estão diretamente ligadas ao processo de testes, porém garantem que determinados itens fundamentais desse processo estão sendo bem gerenciados. Suas principais características são:
Gerenciamento de defeitos;
Gerenciamento de configurações.
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de suporte aos testes (cont.)
O gerenciamento de defeitos tem como objetivo acompanhar e controlar os defeitos identificados durante o ciclo de vida do software e monitorá-los até a sua solução final, através da produção de um grande número de indicadores de qualidade.
Também é conhecido por: gerenciamento de erros, gerenciamento de problemas, registro de ocorrências, controle de incidências.
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Ferramentas de suporte aos testes (cont.)
O gerenciamento de configurações permite controlar e coordenar as mudanças efetuadas em documentações, fontes e ambientes físicos. Estabelece a relação entre os artefatos de software e identifica-los através de um único controle de versão enquanto ocorre modificações de fontes de uma versão anterior.
*
FERRAMENTAS DE TESTE AUTOMATIZADO
*
Qual ferramenta utilizar?
Agora iremos descrever de uma forma resumida alguma das principais ferramentas utilizadas no mercado:
 Junit;
Jmeter;
RFT (IBM Rational Functional Tester);
Mercury Quality Center;
JaBUTi (Java Bytecode Understanding na Testing).
*
FERRAMENTAS COMERCIAIS DE TESTE
*
Framework de código aberto que tem o objetivo de facilitar a automatização de testes unitários em aplicações que utilizam a linguagem Java e possui integração com várias IDEs.
 
Para acessar maiores informações: http://www.junit.org/index.htm 
 
*
JUnit
*
A IDE (Integrated Development Environment ou Ambiente Integrado de Desenvolvimento), é um programa de computador que reúne uma série de características e ferramentas de apoio ao desenvolvimento de software com o objetivo de agilizar este processo.
*
JUnit
*
Ferramenta de código aberto para aplicações Java projetada inicialmente para testes funcionais e de performance para aplicações web. 
Para acessar maiores informações consulte: http://jakarta.apache.org/jmeter/ 
*
JMeter
*
RFT (IBM Rational Functional Tester)
Ferramenta de propriedade da empresa IBM para automação de testes de regressão, funcional, de interface gráfica (GUI) e data driven. 
Para acessar maiores informações consulte: 
http://www-01.ibm.com/software/awdtools/tester/functional/ 
*
IBM Rational Functional Tester
*
Conjunto de ferramentas de propriedade da empresa HP que abrange diferentes tipos de testes, linguagens e arquitetura.
Possui uma interface integrada baseada na Web para teste e gerenciamento de qualidade  de software em diversos ambientes de aplicação.
Para acessar maiores informações consulte: http://www8.hp.com/br/pt/home.html 
*
Mercury Quality Center
*
JaBUTi (Java Bytecode Understanding na Testing)
Ferramenta de suporte ao teste estrutural para programas Java, desenvolvida pela USP. O seu diferencial entre as outras ferramentas existentes com a mesma função de teste é que toda a análise estática necessária para a realização do teste é feita sobre o programa objeto, ou seja, sobre o bytecode Java e não sobre o programa fonte.
Maiores informações: http://ccsl.icmc.usp.br/pt-br/projects/jabuti-0 
*
JaBUTi
*
Um projeto de automação de teste é um investimento alto e de longa duração, e por isso mesmo os dirigentes das organizações obviamente tem expectativas em relação a custos e aos benefícios trazidos pela sua implementação. Por isso um projeto de automação de testes deve ser cercado de alguns cuidados: 
*
Projeto de Automação de Teste
*
Ferramenta: Seleção da ferramenta certa, adequada à tecnologia usada e que possa integrar com as metodologias de desenvolvimento e teste.
Metodologia: Existência de metodologias de desenvolvimento e testes consolidadas e usadas, que possam se integrar com a ferramenta escolhida.
*
Projeto de Automação de Teste
*
Infraestrutura: Disponibilidade de máquina e seus recursos, um projeto em desenvolvimento (em fase de testes) dedicado para o projeto de automação de testes. 
Recursos: Garantia por parte dos dirigentes da organização quanto à disponibilidade de recursos humanos capacitados e financeiros para o projeto, apoio para as mudanças requeridas nos processos de desenvolvimento e testes, assim como nas ferramentas de desenvolvimento.
*
Projeto de Automação de Teste
*
Quais casos de testes são candidatos a automatização?
A cada nova versão de um software torna-se necessário realizar um novo conjunto de teste, visando ampliar as melhorias implementadas.
Desta forma também é necessário reexecutar um conjunto de casos de testes (todos ou partes) de forma a avaliar se as mudanças realizadas danificaram outras partes do software que já funcionava. 
*
Quando usar a Automação de Teste?
*
Os custos relativos à execução dos testes de progressão não são importantes. Porém são importantes os custos de execução dos testes de regressão, pois estes devem ser reexecutados ao longo do ciclo de vida do software. 
*
Quando usar a Automação de Teste?
*
Devemos considerar que os testes automatizados visam a otimização da execução dos testes, mas deve ser feito preventivamente um estudo de viabilidade técnica  e um estudo de custo beneficio para sua utilização ou não.
Os testes automatizados não substituem os testes manuais, eles são complementares e para isso devemos levar em consideração que todo caso de teste é naturalmente candidato à automação, mas naturalmente nem todos são recomendáveis para automação:
*
Quando usar a Automação de Teste?
*
Se o caso de teste for algo pontual e específico de alguma versão do software e não se espera que seja testado em versões futuras, não é candidato à automação.
Se o caso de teste tiver características de uso de uma grande massa de dados, indica ser um data-driven test que precisará provavelmente ser automatizado. 
Não existe tempo hábil para automatizar o teste desejado devido ao cronograma, então ele não será momentaneamente um teste a ser automatizado. 
*
Quando usar a Automação de Teste?
*
Tem-se notado o crescente aumento do Teste de Software no mercado de TI, como também a presença de profissionais qualificados na área de testes em empresas de desenvolvimento de software.
 Cresce a consciência que esta parte do processo exige conhecimentos específicos, contribuindo decisivamente para o sucesso de um projeto.
*
CONCLUSÃO
*
Existem diferentes soluções e metodologias aplicáveis no mercado, que contribuem para a construção de uma boa estrutura na fase de teste de software, considerando que é uma das fases mais importantes no ciclo de desenvolvimento quando se fala em qualidade.
É necessário que os processos de TS sejam aplicados em todas as etapas do ciclo de vida do software, de acordo com a situação em que o software se encontre.
*
CONCLUSÃO
*
Para que o teste de software consiga manter a qualidade do sistema em um mercado em que o tempo é um dos principais fatores considerados, surge a necessidade de que o teste seja realizado de forma mais rápida, o que leva a grande procura por técnicas de automação.
A automação de testes é uma solução ágil, porém acarreta em custos e tempo de criação e manutenção.
*
CONCLUSÃO
*
Por este motivo, a necessidade de automação ainda
é muito discutida no mercado, o que leva a empresa a avaliar as vantagens, circunstâncias e o esforço necessário para criar a automação de teste, analisando se o custo-benefício será satisfatório.
Tem surgido cada vez mais vagas para profissionais experientes, demonstrando que o mercado se preocupa cada vez mais em entregar produtos de qualidade.
*
CONCLUSÃO
*
Os profissionais de teste de software têm por objetivo identificar o maior número possível de irregularidades no sistema, para que o software chegue ao cliente com o menor número possível de bugs, reduzindo significativamente os gastos das empresas com o re-trabalho e evitando o descontentamento do usuário final.
*
CONCLUSÃO
*
Diante da incessante competitividade do mercado atual, empresas procuram garantir a qualidade de seus produtos como fator que represente sua capacidade em desenvolver sistemas com qualidade.
No mercado existem varias técnicas de teste de software que auxiliam essa garantia, cabendo a cada empresa analisar quais realmente estão de acordo com suas políticas e possibilidades de investimentos.
Fonte:	 O Teste de Software no Mercado de Trabalho
	Filipe Bernardes Barbosa e Isabelle Vasconcelos Torres
*
CONCLUSÃO
*
Testes de Software/CCT0204 - Aula 2.ppt
*
TESTES DE SOFTWARE – AULA 2
Prof. Ulisses Sperle Graça
Revisão/2014
TESTE NO PROJETO DE SISTEMAS
E TESTE NO PROGRAMA 
DEPURAÇÃO
*
Compreender a necessidade de testes na especificação do projeto;
Aprender como planejar e aplicar testes no projeto de software;
Compreender e identificar a origem e a causa do erro;
Compreender e implementar técnicas e estratégias para identificação do erro.
*
OBJETIVOS DESTA AULA
*
 À medida que o trabalho da engenharia de software é desenvolvido, é normal que ocorram erros. É importante que estes erros sejam encontrados e corrigidos antes que sejam passados para os usuários finais.
Um dos métodos utilizados para a detecção destes erros logo no início do processo de desenvolvimento de software são as revisões de software. Elas são aplicadas em várias etapas durante o processo de engenharia de software e servem para revelar erros que podem ser eliminados. 
*
INTRODUÇÃO
*
Lembre-se: Errar é humano e, embora algumas pessoas captem bem alguns de seus erros, outros tantos escapam mais facilmente a quem lhe deu origem do que a outras pessoas.
Uma revisão – genericamente falando, é uma forma de usar a diversidade de um grupo de pessoas para: 
 
*
INTRODUÇÃO
*
Apontar aperfeiçoamentos necessários no produto de uma única pessoa ou de uma equipe.
Confirmar aquelas partes de um produto em que aperfeiçoamentos são indispensáveis ou desnecessários.
Obter trabalho técnico de qualidade mais uniforme, ou pelo menos mais previsível, que possa ser alcançada sem revisões, de modo a tornar o trabalho técnico mais gerenciável.
*
INTRODUÇÃO
*
Diferentemente da revisão de software, A depuração de software é comumente definida como a tarefa de localização e remoção de erros. Ela ocorre como consequência de um teste bem sucedido, ou seja, ela ocorre sempre que um erro é revelado. 
 
É importante observar que erros podem ser revelados em diferentes fases do ciclo de vida do software e a depuração possui características diferentes, dependendo da fase em que se encontra o software. 
*
INTRODUÇÃO
*
A depuração durante a codificação é um atividade complementar à de codificação.
Já a depuração depois do teste é ativada pelo teste bem-sucedido, isto é, revela a presença de defeitos.
A depuração durante a manutenção ocorre por necessidade de manutenção no software, que pode ter sido causada por um defeito revelado depois que o software foi liberado ou pela necessidade de acrescentar novas características.
*
INTRODUÇÃO
*
São utilizadas logo no início do processo de Gestão de Qualidade.
Por que são importantes?
 
 Ao se descobrir um erro logo no início do processo, fica menos caro corrigí-lo. Temos que levar em consideração também que os erros podem aumentar à medida que o processo continua. 
*
REVISÕES TÉCNICAS
*
Por que são importantes? (cont.)
 
 Um erro relativamente insignificante, sem tratamento no início do processo, pode ser ampliado e se transformar em um conjunto de erros graves para a sequência do projeto.
 
 Minimizam o tempo devido à redução do número de reformulações que serão necessárias ao longo do projeto.
*
REVISÕES TÉCNICAS
*
Impacto dos defeitos de software nos custos
Muitas vezes o termo erro é utilizado para indicar um problema de qualidade que é descoberto antes do software ser liberado ao usuário final. 
 Utilizamos a revisões técnicas para encontrar erros durante o processo de desenvolvimento, de modo a não se tornarem defeitos depois da liberação do software. A descoberta precoce de erros, evita que sejam propagados para a próxima etapa na gestão da qualidade.
*
REVISÕES TÉCNICAS
*
Impacto dos defeitos de software nos custos
Segundo Pressman, diversos estudos e análise sobre o tema indicam que a atividades de projeto introduzem de 50 a 60% de todos os erros, durante a gestão da qualidade. Entretanto, técnicas de revisão demonstraram ser até 75% eficazes na descoberta de falhas no projeto.
*
REVISÕES TÉCNICAS
*
Impacto dos defeitos de software nos custos
O benefício das revisões é a descoberta precoce dos defeitos de software, de forma que possam ser corrigidos antes do passo seguinte.
Ao detectar e suprimir estes erros, o processo de revisão reduz substancialmente o custo dos passos subsequentes.
*
REVISÕES TÉCNICAS
*
A formalidade do processo de revisão é relacionada a fatores como a maturidade do processo de desenvolvimento, requisitos legais e reguladores ou a necessidade de acompanhamento de auditoria. 
 
O modo como uma revisão é conduzida depende do seu objetivo (ex: encontrar defeitos, obter compreensão, auditoria, discussão ou decisões por um consenso).
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Uma RTF é uma atividade de garantia de qualidade de software executada por engenheiros de software e outros profissionais.
Cada RTF é realizada como um encontro e somente será bem sucedida se for adequadamente planejada, controlada e assessorada.
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Objetivos:
Descobrir erros na função, lógica ou implementação
Verificar se o software atende aos requisitos
Garantir que o software foi representado de acordo com os padrões
Obter um software que seja desenvolvido uniformemente
Tornar os projetos mais gerenciáveis
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Fases principais:
Planejamento  Selecionar a equipe, alocar as funções, definir os critérios de entrada e de saída para os diversos tipos de revisão formal (ex: inspeção), e selecionar quais as partes dos documentos serão vistos.
Kick-off  Distribuir os documentos, explicar os objetivos, processos e documentos para os participantes; e checar os critérios de entrada (para os diversos tipos de revisão).
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Fases principais (cont.):
Preparação individual  trabalho feito antecipadamente por cada participante da reunião de revisão, tomando nota dos defeitos em potenciais, questões e comentários.
Reunião de revisão
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Fases principais (cont.):
Retrabalho  Resolver defeitos encontrados. Atividade tipicamente realizada pelo autor. 
Acompanhamento  Checar se os defeitos foram encaminhados, obtendo métricas e checando o critério de saída (para certos tipos de revisões formais).
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Restrições:
 Entre 3 e 5 pessoas;
 Uma preparação antecipada deve ocorrer, mas ela não deve exigir mais de 2h de cada pessoa;
 A duração da reunião deve ser inferior a 2h.
Uma RTF concentra-se numa parte específica e pequena do software, pois ao estreitar o foco, tem-se a probabilidade maior de revelar erros.
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Tipicamente uma reunião é programada para o dia seguinte ao da preparação, e conta com o produtor e os revisores.
Durante a RTF, um revisor registra ativamente todos os problemas levantados. Estes são sintetizados no final da reunião de revisão e é produzida uma lista de problemas de revisão, além do relatório sintetizado da revisão técnica formal. Normalmente o relatório sintetizado é um formulário de uma página, cujo anexo é a lista de problemas de revisão.
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Ao final, os participantes devem decidir se:
 
Aceitam o produto sem modificações adicionais;
Rejeitam o produto devido a erros graves (uma vez corrigidos, outra revisão deve ser realizada);
Aceitam o produto provisoriamente (erros menores foram encontrados e devem ser corrigidos, sem revisão adicional).
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
*
TESTE NO PROGRAMA - DEPURAÇÃO
*
O processo de depuração frequentemente ocorre em consequência de um teste. Quando um caso de teste descobre um erro, a depuração será o processo que irá resultar na remoção deste erro.
 
O Processo de depuração tenta combinar o sintoma com a causa, levando assim à correção do erro. Normalmente apresentará um dentre dois resultados:
A causa será encontrada e corrigida;
A causa não será encontrada;
*
TESTE NO PROGRAMA - DEPURAÇÃO
*
Independente da abordagem adotada, a depuração tem um objetivo primordial, que é encontrar e corrigir a causa de erro ou defeito. 
 
Um dos modelos existentes é o modelo genérico de depuração chamado de Hipóteses-Validação. O modelo define a atividade de depuração como um processo interativo de síntese, verificação e refinamento de hipótese.
*
ABORDAGENS DA DEPURAÇÃO
*
*
Inicie conjunto de hipóteses
Modifique conjunto de hipóteses
Selecione hipótese
Verifique hipótese
Corrigido?
Não
Sim
ABORDAGENS DA DEPURAÇÃO
O responsável pela depuração estabelece hipóteses com relação à localização do defeito e à modificação para corrigi-lo. 
O processo de depuração é guiado pela certificação/refutação das hipóteses levantadas, bem como pela geração de novas hipóteses e refinamentos das já existentes. 
*
Segundo Pressman, o objetivo da depuração é alcançado por uma combinação de avaliação sistemática, intuição e sorte, sendo definido basicamente três estratégias (Myers):
 
Força bruta
Rastreamento (backtracking)
Eliminação da causa
*
ABORDAGENS DA DEPURAÇÃO
*
Força bruta
Método mais comum e menos eficiente;
Usado quando os outros métodos falham;
Faz-se imensa quantidade de teste, mas sem planejamento.
*
ABORDAGENS DA DEPURAÇÃO
*
Rastreamento (backtracking)
 
A partir do local do sintoma descoberto, rastreia-se para trás até encontrar a causa;
Bastante comum, porém restrita a programas pequenos, pois o número de caminhos retroativos potenciais pode ser muito alto;
Em sistemas/programas médios/grandes é ineficiente;
*
ABORDAGENS DA DEPURAÇÃO
*
Eliminação da causa
 
Os dados relacionados à ocorrência de erros são organizados para isolar causas em potencial;
Uma “hipótese de causa” é imaginada e dados acima são usados para provar ou reprovar a hipótese;
Uma lista de todas as causas possíveis é desenvolvida e testes são realizados para eliminar cada uma.
*
ABORDAGENS DA DEPURAÇÃO
*
Efetuar testes e depuração é um traço humano inato;
Certas pessoas são boas para fazer isso, outras não;
A depuração é uma das partes mais frustrantes da programação. Ela indica o reconhecimento de que erramos;
A elevada ansiedade, a pressão, o tempo curto, a pouca disposição para aceitar a possibilidade de erro, aumenta a dificuldade da tarefa;
Quando um erro é enfim corrigido, vem um grande suspiro de alívio e uma diminuição da tensão.
*
CONSIDERAÇÕES PSICOLÓGICAS
*
Segundo Pressman, uma vez encontrado o erro, ele precisa ser corrigido. A correção de um defeito pode introduzir outros erros e, portanto, causar mais danos do que trazer benefícios.
Segundo Van Vleck, três perguntas devem ser feitas antes de fazer a “correção” que remove a causa de um defeito:
*
CORREÇÃO DO ERRO
*
Questionamentos de Van Vlek:
 
 1. A causa do defeito é reproduzida em outra parte do programa?
 Em muitas situações, o defeito é provocado por um padrão de lógica errôneo que pode ser reproduzido em outro lugar.
*
CORREÇÃO DO ERRO
*
Questionamentos de Van Vlek:
 
 2. Qual o próximo defeito que poderia ser introduzido pelo reparo que estou prestes a fazer?
 Se a correção tiver de ser feita em um módulo com alto acoplamento, deve-se tomar um cuidado especial.
*
CORREÇÃO DO ERRO
*
Questionamentos de Van Vlek:
 
 3. O que poderíamos ter feito para eliminar este defeito já no início?
 Se corrigirmos o processo, bem como o produto, o defeito pode ser eliminado de todos os programa futuros. 
*
CORREÇÃO DO ERRO
*
O sintoma e a causa podem estar geograficamente distantes;
O sintoma pode desaparecer quando outro erro é corrigido;
O sintoma pode ser causado por não erro (ex: arredonda);
O sintoma pode ser causado por um erro humano;
O sintoma pode ser causado por problema de sincronização;
Pode ser difícil reproduzir com precisão as condições que originam o erro;
O sintoma poder ser intermitente.
O sintoma pode ocorrer devido as causas distribuídas por várias tarefas, executando em diferentes processadores.
*
PISTAS PARA A DEPURAÇÃO
*
Testes de Software/CCT0204 - Aula 3.ppt
*
TESTES DE SOFTWARE – AULA 3
Prof. Ulisses Sperle Graça
Rio de Janeiro, 21 de agosto de 2011
TESTE NO PROGRAMA
TESTE CAIXA BRANCA E
TESTE CAIXA PRETA 
*
Compreender os testes de interior do programa;
Definir testes para o interior do programa;
Implementar testes para o interior do programa;
Avaliar testes realizados no interior do programa.
*
OBJETIVOS DESTA AULA
*
 Uma vez gerado o código-fonte, o software deve ser testado para descobrir (e corrigir) tantos erros quanto possível antes de fornecê-lo ao cliente.
O objetivo do teste é encontrar erros, e um bom teste é aquele que tem alta probabilidade de encontrar um erro. 
Devem ter uma serie de características que permitam atingir o objetivo de encontrar o maior número de erros com o mínimo de esforços.
*
INTRODUÇÃO
*
Testes podem ser usados para descobrir a presença de erros, mas não para mostrar a sua ausência.
Testes de software é o processo de executar o software de uma maneira controlada com o objetivo de descobrir diferenças entre o comportamento previsto e o comportamento observado.
Um teste bem-sucedido é aquele que revela um erro ainda não descoberto.
*
INTRODUÇÃO
*
 Devemos projetar testes que tenham a mais alta probabilidade de descobrir a maioria dos erros com uma quantidade mínima de tempo e esforço;
Os métodos de projeto de casos de teste oferecem ao desenvolvedor uma abordagem sistemática ao teste.
Oferecem ainda um mecanismo que ajuda a garantir a integridade do teste e proporciona a mais alta probabilidade de revelar erros no software.
*
INTRODUÇÃO
*
Qualquer produto trabalhado por engenharia pode ser testado de duas maneiras:
1 - Conhecendo-se a função específica que um produto projetado deve executar, testes podem ser realizados
para demonstrar que cada função é totalmente operacional;
Abordagem: Teste de Caixa Preta
*
PROJETOS DE CASOS TESTE
*
2 - Conhecendo-se o funcionamento interno de um produto, testes podem ser realizados para garantir que a operação interna do mesmo tenha desempenho de acordo com as especificações e que os componentes internos foram postos à prova.
Abordagem: Teste de Caixa Branca
*
PROJETOS DE CASOS TESTE
*
Teste de caixa branca é uma abordagem de projeto de casos de teste que usa a estrutura de controle do projeto procedimental para derivar casos de teste.
Baseia-se num minucioso exame dos detalhes procedimentais.
*
TESTE CAIXA BRANCA
*
Os caminhos lógicos através do software são testados, fornecendo-se casos de teste que põem à prova conjuntos específicos de condições e/ou laços.
O status do programa pode ser examinado em vários pontos para determinar se o esperado corresponde ao real.
*
TESTE CAIXA BRANCA
*
Com este método nós podemos projetar casos de teste que:
Garantam que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez;
Exercitem todas as decisões lógicas para valores falsos ou verdadeiros;
Executem todos os laços em suas fronteiras e dentro de seus limites operacionais;
Exercitem as estruturas de dados internas para garantir a sua validade.
*
TESTE CAIXA BRANCA
*
Tipos de Teste Caixa Branca:
Teste de Caminho Básico
Teste de Condição
Teste de Fluxo de Dados
Teste de Ciclo
*
TESTE CAIXA BRANCA
*
*
TESTE DO CAMINHO BÁSICO
Técnica de teste de caixa branca inicialmente proposta por Tom McCabe.
Permite ao projetista do caso de teste derivar uma medida da complexidade lógica de um projeto procedimental e usá-la para definir um conjunto básico de caminhos de execução;
A Complexidade Ciclomática é uma métrica que proporciona uma medida quantitativa da complexidade lógica de um programa.
*
*
TESTE DO CAMINHO BÁSICO
Os casos de teste projetados para exercitarem este conjunto básico têm garantia de executar cada instrução do programa pelo menos uma vez durante a atividade de teste.
Os seguintes passos devem ser aplicados:
*
*
TESTE DO CAMINHO BÁSICO
Usando o projeto ou o código como base, desenhar o grafo de fluxo correspondente;
Determinar a complexidade ciclomática do diagrama de fluxo resultante.
Determinar um conjunto base de caminhos linearmente independentes. 
Preparar casos de teste que vão forçar a execução de cada caminho do conjunto base.
*
*
TESTE DO CAMINHO BÁSICO
Exemplo: Segmento de programa fonte e seu correspondente grafo de fluxo.
 procedure:sort
1: do while records remain
 read record;		
2: if record field1 = 0 
3: then process record;					 store in buffer;
	 increment counter;
4: else if record field2 = 0
5: then reset counter;
6: else process record;
 store in file;
7: endif
 endif
8: enddo
9: end 		 			
1
2
4
6
5
7
3
8
9
*
*
TESTE DO CAMINHO BÁSICO
 
 Caminho 1: 1-9
 Caminho 2: 1-2-3-8-1 ...
 Caminho 3: 1-2-4-5-7-8-1 ...
 Caminho 4: 1-2-4-6-7-8-1 ... 			
1
2
4
6
5
7
3
8
9
R3
R2
R1
R4
*
*
TESTE DE CONDIÇÃO
Método de Projeto de casos de teste que põe à prova as condições lógicas contidas em um módulo de programa.
 Condição Simples: variável booleana ou expressão relacional, precedida ou não por um operador NOT (‘)
 Condição Composta: duas ou mais condições simples, operadores booleanos e parênteses.
Tipos de Erros de uma Condição: erro de operador booleano, erro de variável booleana, erro de parênteses booleano, erro de operador relacional, erro de expressão aritmética.
*
Teste de Ramos: Para uma condição C composta, os ramos verdadeiro e falso de C e todas as condições simples em C precisam ser executadas pelo menos uma vez.
Teste de Domínio: requer 3 ou 4 testes sejam derivados para uma expressão relacional.
*
TESTE DE CONDIÇÃO
*
Para uma expressão E1 <operador relacional> E2
3 testes são exigidos para tornar o valor de E1 >, = ou < que o de E2.
Se <operador relacional> estiver incorreto e E1,E2 corretos, esses 3 testes garantem a detecção de erro de operador relacional.
Para detectar erros em E1 e E2, basta executar um teste que faça o valor de E1 > ou < que o de E2, com uma diferença menor possível.
*
TESTE DE DOMÍNIO
*
*
TESTE DE CICLO (LAÇOS)
*
Fundamental para a grande maioria de todos os algoritmos implementados no software. Técnica que concentra na validade das construções de laços.
Laços Simples: deve ser aplicado o seguinte conjunto de teste:
 	
Pule o laço inteiramente;
Somente uma passagem através do laço;
Duas passagens através do laço;
m passagens através do laço, onde m < n;
n-1, n, n+1 passagens através do laço.
*
*
TESTE DE CICLO (LAÇOS)
Laços Aninhados:
Inicie pelo laço mais interno. Fixe os outros laços para valores mínimos.
Realize testes de laços simples para o laço mais interno.
Trabalhe para fora, realizando testes para o laço seguinte, mas mantendo todos os ciclos externos nos valores mínimos
Continue até que todos os laços tenham sido testados. 
*
*
Laços Concatenados: 
1. Se laços independentes dos demais:
  usar abordagem de laços simples.
2. Se contador de laços para o laço 1 for usado como valor inicial para o laço 2:
  usar abordagem de laços aninhados. 
TESTE DE CICLO (LAÇOS)
*
*
Laços não estruturados:
Sempre que possível, esta classe deve ser reprojetada para refletir o uso das construções de programação estruturada. 
TESTE DE CICLO (LAÇOS)
*
*
TESTE CAIXA PRETA
 Foco: requisitos funcionais do software
Possibilita a derivação de conjuntos de condições de entrada que exercitem todos os requisitos funcionais para um programa.
O Teste de Caixa Preta desconsidera a estrutura de controle.
A atenção é voltada ao domínio da informação.
*
*
O Teste de Caixa Preta não é uma alternativa às técnicas Caixa Branca, mas ao contrário, é uma abordagem complementar, que mais provavelmente descobrirá uma classe diferente de erros.
TESTE CAIXA PRETA
*
São realizados para responder as seguintes perguntas:
Como a validade funcional é testada?
Como o comportamento e o desempenho é testado?
Que classes de entrada farão bons casos de teste?
O sistema é particularmente sensível a certos valores?
Como as fronteiras de uma classe de dados é isolada?
Que taxas e volumes de dados o sistema pode tolerar?
Que efeito combinações específicas de dados terão sobre a operação do sistema?
*
TESTE CAIXA PRETA
*
Desta forma o teste de caixa preta tenta encontrar erros nas seguintes categorias:
 
Funções incorretas ou faltando;
Erros de interface;
Erros em estruturas de dados ou acesso a bases de dados externas;
Erros de comportamento ou de desempenho;
Erros de inicialização e término.
*
TESTE CAIXA PRETA
*
Existem diferentes métodos de testes de caixa preta que podem ser subdivididos em:
 
Particionamento em Equivalência
Análise do Valor Limite
Teste de Matriz Ortogonal
Baseado em Grafo
*
TESTE CAIXA PRETA
*
*
TESTE CAIXA PRETA
Particionamento de Equivalência
Método de teste de caixa preta que divide o domínio de entrada de um programa em classes de dados a partir das quais os casos de testes podem ser derivados.
Um caso de teste ideal descobre sozinho uma classe de erros que, de outro modo,
poderia exigir que muitos casos fossem executados antes que o erro geral fosse observado.
*
*
TESTE CAIXA PRETA
Particionamento de Equivalência
As classes de equivalência podem ser definidas, conforme as seguintes diretrizes:
1. Se uma condição de entrada especificar um intervalo, uma classe de equivalência válida e duas classes de equivalência inválidas são definidas.
2. Se uma condição de entrada exigir um valor específico, uma classe de equivalência válida e duas inválidas são definidas.
*
*
TESTE CAIXA PRETA
Particionamento de Equivalência
As classes de equivalência podem ser definidas, conforme as seguintes diretrizes:
3. Se uma condição de entrada especificar um membro de um conjunto, uma classe de equivalência válida e uma inválida são definidas.
4. Se uma condição de entrada for booleana, uma classe de equivalência válida e uma inválida são definidas.
*
*
TESTE CAIXA PRETA
Análise do Valor Limite
 Percebe-se que um número maior de erros tende a ocorrer mais nas fronteiras do domínio de entrada do que no “centro”. A análise de valor de limite leva à escolha de casos de teste que põem à prova os valores fronteiriços.
É uma técnica que complementa o particionamento de equivalência: em vez de selecionar qualquer elemento de uma classe de equivalência, a BVA leva à seleção de casos de teste nas “extremidades”da classe.
*
*
A análise do valor limite leva a novos casos de teste referentes a valores adjacentes aos limites. A seleção de tais casos adicionais, aumentam a probabilidade de se detectar uma falha.
Qualquer número
(neste intervalo)
TESTE CAIXA PRETA
Análise do Valor Limite
*
 Teste de matriz ortogonal
 
O teste de matriz ortogonal pode ser aplicado a problemas nos quais o domínio de entrada é relativamente pequeno, mas muito grande para acomodar um teste exaustivo.
O objetivo do teste é a construção de caso de teste com uma visualização geométrica associada aos valores de entrada de uma aplicação.
*
TESTE CAIXA PRETA
*
Para ilustrar, vamos considerar a função envie para uma aplicação de fax. Neste exemplo, são passados quatro parâmetros: P1, P2, P3 e P4. Cada parâmetro assume três valores discretos. P1 assume, por exemplo, os valores:
P1=1, enviar agora;
P1=2, enviar após 1 hora;
P1=3, enviar depois da meia-noite;
P2, P3 e P4 também assumiriam valores, 1, 2 e 3, significando outras funções de envio.
*
TESTE CAIXA PRETA
*
Matriz ortogonal para a função envie da aplicação de fax:
*
TESTE CAIXA PRETA
*
Baseado em grafo
O teste baseado em grafos leva em consideração os objetos modelados no software e as relações que os unem.
A ideia é definir uma série de testes que verificam se os objetos têm a relação esperada uns com outros. 
Um grafo é uma coleção de nós que representam objetos, ligações que representam as relações entre objetos, peso de nó que descreve as propriedades de um nó e pesos de ligação que descrevem uma característica de uma ligação.
*
TESTE CAIXA PRETA
*
*
TESTE CAIXA PRETA
Baseado
em grafo
*
Testes de Software/CCT0204 - Aula 4.ppt
*
TESTES DE SOFTWARE – AULA 4
Prof. Ulisses Sperle Graça
Rio de Janeiro, 27 de agosto de 2011
TESTE NO PROGRAMA
TESTE DE APLICAÇÕES DA WEB
*
1. Compreender técnicas de teste de ambiente web;
2. Definir testes de software em ambiente web;
3. Implementar testes de software em ambiente web;
4. Avaliar testes de software em ambiente web.
*
OBJETIVOS DESTA AULA
*
 Com o crescimento da Internet e a evolução das tecnologias envolvidas, as aplicações na WEB também evoluíram. Hoje grande parte dos negócios da organizações também estão na WEB e consequentemente ocorreu um aumento nos números de aplicações desenvolvidas para este fim. 
*
INTRODUÇÃO
*
O teste de uma aplicação WebApp (aplicações para Web) é um conjunto de atividades relacionadas com um único objetivo:
Descobrir erros
Mas como?
*
INTRODUÇÃO
*
 Para atingir este objetivo deve ser utilizada uma estratégia de teste que abrange as revisões e o teste executável.
O processo de teste começa focando os aspectos visíveis da Aplicação ao usuário e abrange os aspectos de tecnologia e infraestrutura, neste caso em sete etapas de teste: 
*
INTRODUÇÃO
*
no conteúdo,
na função,
na usabilidade,
na navegabilidade,
no desempenho,
na capacidade,
na segurança das aplicações e etc.
*
INTRODUÇÃO
*
A qualidade, segundo Pressman (2011) é incorporada a uma aplicação Web como consequência de um bom projeto. 
“Não se pode testar a qualidade. Se ela não estiver lá antes de você começar a testar, não estará lá quando você tiver terminado de testar.” (Pressman).
A qualidade é incorporada ao software em todo o processo de engenharia de software.
*
INTRODUÇÃO
*
A aplicação adequada de métodos e ferramentas, RTFs e um gerenciamento e medição sólidos, todos levam à qualidade que é confirmada durante o teste.
 
A qualidade é avaliada aplicando-se uma série de revisões técnicas e de um processo de teste com o objetivo de examinar uma ou mais das seguintes dimensões de qualidade:
*
CONCEITO DE TESTE NA WEB
*
*
Qualidade
Conteúdo
Função
Segurança
Usabilidade
Navegabi-lidade
Desempenho
Compatibilidade
Interope-rabilidade
Estrutura
DIMENSÕES DE QUALIDADE
*
Conteúdo: é avaliado no nível semântico e sintático. No nível sintático examina-se a ortografia, pontuação e gramática. No nível semântico são verificadas a exatidão, consistência e ausência de ambiguidade das informações.
Função: é testada para descobrir erros que indicam falta de conformidade com os requisitos do cliente.
*
DIMENSÕES DE QUALIDADE
*
Estrutura: É avaliada para assegurar o fornecimento apropriado do conteúdo e função da aplicação. Que seja extensível e possa ser mantida à medida que novo conteúdo ou funcionalidade é adicionado
Usabilidade: é testada para garantir que cada categoria de usuário seja suportada pela interface.
*
DIMENSÕES DE QUALIDADE
*
Navegabilidade: é testada para assegurar que toda a sintaxe e semântica de navegação sejam experimentadas para descobrir quaisquer erros de navegação.
 
Desempenho: é testado sob uma variedade de condições de operação, configuração e carga para assegurar que o sistema responda à interação com o usuário e suporte cargas extremas sem degradação inaceitável de operação.
*
DIMENSÕES DE QUALIDADE
*
Compatibilidade: é testada executando-se a aplicação em uma variedade de diferentes configurações hospedeiras tanto no lado cliente quanto no lado servidor.
 
Interoperabilidade: é testada para garantir que a aplicação tenha uma interface adequada com outras aplicações e/ou bases de dados.
*
DIMENSÕES DE QUALIDADE
*
Segurança: é testada para investigar vulnerabilidades potenciais e tentar explorar cada uma delas. Qualquer tentativa bem-sucedida de invasão é considerada falha de segurança.
*
DIMENSÕES DE QUALIDADE
*
O processo de teste da aplicação Web começa com testes que verificam o conteúdo e a funcionalidade da interface, posteriormente são verificados aspectos da arquitetura do projeto e da navegação da aplicação e finalizando com os testes que examinam os recursos tecnológicos.
Diversos deste testes não são aparentes para o usuário final.
*
O PROCESSO DE TESTE NA WEB
*
Tarefas importantes:
Revise os requisitos dos interessados. Identifique metas e objetivos-chave do usuário. Revise os casos de uso para cada categoria de usuário.
Estabeleça prioridades para garantir que
cada meta e objetivo do usuário seja testado.
Defina a estratégia de teste da aplicação descrevendo os tipos de teste que serão conduzidos.
Desenvolva um plano de testes.
*
O PROCESSO DE TESTE NA WEB
*
Tarefas importantes (cont.):
Execute testes de unidade. Revise o conteúdo quanto à erros sintáticos e semânticos.
Realize testes de integração. Conduza testes de navegação.
Realize testes de configuração. Avalie a configuração do lado do cliente e do lado do servidor.
Conduza testes de desempenho.
Conduza testes de segurança.
*
O PROCESSO DE TESTE NA WEB
*
Podemos observar melhor o processo de teste na Web através da figura adiante, representado através de uma pirâmide, os elementos que são visíveis ao usuário, são testados em primeiro lugar.
O fluxo do nosso processo de teste começa da esquerda para direita e de cima para baixo, começando pelo teste de conteúdo, teste de interface, teste de navegação, de componente e finalizando com os testes de configuração, desempenho e segurança. 
*
O PROCESSO DE TESTE NA WEB
*
*
O PROCESSO DE TESTE NA WEB
*
O modelo de conteúdo é revisto para descobrir erros;
O modelo de interface é revisto para garantir que todos os casos de uso possam ser acomodados;
O modelo de projeto da aplicação é revisto para descobrir erros de navegação;
A interface com o usuário é testada para descobrir erros nos mecanismos de apresentação e/ou navegação;
Os componentes funcionais são submetidos a testes de unidade;
*
O PROCESSO DE TESTE NA WEB
*
É testada a navegação por toda a arquitetura;
A aplicação Web é implementada em uma variedade de configurações ambientais diferentes e testada quanto à compatibilidade com cada configuração;
São executados testes de segurança na tentativa de explorar vulnerabilidades na Aplicação ou em seu ambiente;
São realizados testes de desempenho;
*
O PROCESSO DE TESTE NA WEB
*
A aplicação é testada por uma população de usuários finais controlados e monitorados e os resultados de suas interações com o sistema são avaliados quanto a erros de conteúdo e navegação, usabilidade, compatibilidade, segurança, confiabilidade e desempenho.
*
O PROCESSO DE TESTE NA WEB
*
O teste de conteúdo tenta descobrir erros antes que sejam encontrados pelos usuários. Ele combina tanto as revisões, já estudadas nas aulas anteriores, quanto à geração de casos de teste executáveis.
Os testes de conteúdo têm três importantes objetivos:
Descobrir erros de sintaxe;
Descobrir erros de semântica
Encontrar erros na organização ou estrutura do conteúdo apresentado ao usuário final;
*
TESTE DE CONTEÚDO
*
O revisor deverá responder as seguintes perguntas:
As informações são precisas?
As informações são concisas e direcionadas ao assunto?
É fácil para o usuário entender o layout do conteúdo?
As informações apresentadas são consistentes internamente e consistentes com as apresentadas em outros objetos?
Foram fornecidas referências apropriadas para todas as informações derivadas de outras fontes?
*
TESTE DE CONTEÚDO
*
O revisor deverá responder as seguintes perguntas:
O conteúdo é ofensivo, confuso ou dá margem a litígio?
O conteúdo desrespeita os direitos autorais existentes ou de marcas registradas?
O conteúdo contém links que complementam o conteúdo existente? Os links estão corretos?
O estilo estético do conteúdo está em conflito com o estilo estético da interface?
*
TESTE DE CONTEÚDO
*
A verificação e validação de uma interface de usuário ocorre em três pontos distintos:
Durante a análise garantir que esteja de acordo com os requisitos do cliente;
Durante o projeto  garantir que critérios genéricos de qualidade e que tópicos específicos foram tratados;
Durante o teste  execução de tópicos específicos relativos à interação como usuário e fornece uma avaliação final da usabilidade.
*
TESTE DE INTERFACE COM O USUÁRIO
*
Tem como objetivo descobrir erros relacionados com os mecanismos específicos da interface e descobrir erros na maneira como a interface implementa as semânticas de navegação, as funcionalidades da aplicação ou ainda na exibição do conteúdo.
Desta forma podemos distinguir basicamente quatro tipos de testes:
*
TESTE DE INTERFACE COM O USUÁRIO
*
Testes de mecanismos de interface: Avalia a interação de cada mecanismos oferecido ao usuário através da interface: link, formulários, script executado pelo cliente, janelas pop up e etc.
Teste de semântica da interface: Avalia como o projeto se preocupa com os usuários.
*
TESTE DE INTERFACE COM O USUÁRIO
*
Teste de usabilidade: determina o grau com o qual a interface da aplicação facilita a vida do usuário. 
Teste de compatibilidade: Diferentes computadores, dispositivos de imagem, sistemas operacionais, navegadores e velocidades de conexão de rede pode ter influência significativa na operação da aplicação Web. 
*
TESTE DE INTERFACE COM O USUÁRIO
*
O teste de componente, também conhecido como teste de função, tem como objetivo tentar descobrir erros nas funções da aplicação Web.
Cada uma destas funções é um componente de software que pode ser implementados através de diferentes linguagens e testados através de teste de caixa-preta ou ainda de caixa-branca, ambos já estudados.
*
TESTE DE COMPONENTE
*
Cada caso de teste de componente especifica todos os valores de entrada e saída esperada a ser fornecida pelo componente.
Em muitas situações, a execução correta de uma função da aplicação está ligada ao interfaceamento correto com um banco de dados que pode ser externo a aplicação, desta forma, o teste de banco de dados torna-se parte importante do teste de componente.
*
TESTE DE COMPONENTE
*
Um usuário navega por uma aplicação WEB de modo muito semelhante ao que um visitante caminha por uma loja ou museu.
Há muitos caminhos que podem ser trilhados, muitas paradas que podem ser feitas, muitas coisas para aprender e observar, atividades a iniciar e decisões a tomar.
*
TESTE DE NAVEGAÇÃO
*
Seu objetivo é garantir que os mecanismos que permitem ao usuários navegar através da aplicação Web estejam todos em funcionamento e que cada unidade semântica de navegação possa ser alcançada pela categoria apropriada de usuário.
Desta forma este tipo de teste abrange:
Sintaxe
Semântica
*
TESTE DE NAVEGAÇÃO
*
Segundo Pressman, neste tipo de teste os mecanismos de navegação são verificados para garantir que cada um execute sua função planejada e garantir que os erros sejam encontrados antes que a aplicação entre no ar:
 
Links de navegação: Cada link deverá ser testado para assegurar que o conteúdo ou funcionalidade apropriada sejam alcançados quando o link é escolhido.
*
TESTE DE NAVEGAÇÃO - SINTAXE
*
Redirecionamentos: Quando um usuário solicita uma URL não existente ou seleciona um link cujo conteúdo foi removido, é exibida uma mensagem para o usuário e a navegação é redirecionada para outra página. 
 
Marcadores de páginas (Booksmarks): Apesar de ser uma função do navegador, deverá ser testado para assegurar que possa ser extraído um título de página com significado quando o marcador for criado.
*
TESTE DE NAVEGAÇÃO - SINTAXE
*
Mapas do site: Como o mapa do site fornece uma tabela completa de conteúdo para todas as páginas da web, cada entrada deverá ser testada.
 
Dispositivos de busca interna: Muitas aplicações, devido a quantidade de informações existentes, implementam mecanismos de busca. Deverá ser testado o teste destes mecanismos para validar a precisão e a totalidade da busca. 
*
TESTE DE NAVEGAÇÃO - SINTAXE
*
Molduras e conjunto de molduras: Cada moldura tem o conteúdo de uma página
web específica. Um conjunto de moldura permite que várias páginas sejam exibidas ao mesmo tempo. O conjunto de molduras deverá ser testado quanto ao correto conteúdo, layout, dimensionamento apropriados e quanto a compatibilidade com o navegador. 
*
TESTE DE NAVEGAÇÃO - SINTAXE
*
A unidade semântica de navegação (NSU) pode ser exemplificada por um conjunto de caminhos de navegação que conectam nós de navegação (por exemplo, páginas Web, objetos de conteúdo ou funcionalidade) que permite ao usuário satisfazer requisitos específico definidos por um ou mais casos de uso para uma categoria de usuário.
Neste caso o teste semântico deverá responder as seguintes perguntas:
*
TESTE DE NAVEGAÇÃO - SEMÂNTICA
*
A NSU é atendida sem erro?
Cada nó de navegação é acessível no contexto dos caminhos de navegação definidos para a NSU?
Todos os caminhos relevantes foram testados?
Se forem fornecidas instruções pela interface de usuário para ajudar na navegação as instruções são corretas e inteligíveis à medida que a navegação ocorre?
*
TESTE DE NAVEGAÇÃO - SEMÂNTICA
*
Existe algum mecanismo para voltar a um nó de navegação anterior e ao início do caminho de navegação?
Se uma função é executada em um nó e ocorre um erro no processamento da função, a NSU pode ser completada?
Todos os nós podem ser acessados do mapa do site? Os nomes dos nós têm significado para os usuários finais?
*
TESTE DE NAVEGAÇÃO - SEMÂNTICA
*
O teste de navegação, bem com o teste de interface e de usabilidade, devem ser feitos além dos testadores, também por diferentes clientes, sempre que possível!
*
TESTE DE NAVEGAÇÃO - SEMÂNTICA
*
O objetivo do teste de configuração (Pressman, 2011) é testar um conjunto de prováveis configurações do cliente e do servidor para assegurar que a experiência do usuário será a mesma em todos os casos e isolar erros que podem ser específico a uma determinada configuração.
*
TESTE DE CONFIGURAÇÃO
*
Lado Servidor  os casos de teste são projetados para verificar se a configuração do servidor pode suportar a aplicação sem erro. Perguntas a serem respondidas:
A aplicação é totalmente compatível com o sistema operacional do servidor?
Os arquivos de sistema, diretórios e dados de sistema relacionados são criados corretamente quando a aplicação está operacional?
*
TESTE DE CONFIGURAÇÃO
*
As medidas de segurança permitem que a aplicação seja executada sem a interferência ou degradação do desempenho?
A aplicação está adequadamente integrada com o software de banco de dados?
Os scripts utilizados pela aplicação executam corretamente?
*
TESTE DE CONFIGURAÇÃO
*
Lado Cliente  foca a compatibilidade da aplicação com configurações dos seguintes componentes:
Hardware: CPU, memória, armazenamento e dispositivo de impressão;
Sistemas operacionais: Linux, Macintosh OS, Microsoft, S.O. Móvel.
Software Navegador: Firefox, Safari, Internet Explorer, Opera, Chrome e outros.
*
TESTE DE CONFIGURAÇÃO
*
Componentes de interface de usuário: Active X, java Applets e outros.
Plug-ins: QuickTime, RealPlayer e outros.
Conectividade: Cabo, DSL, modem , WIFI.
Estes testes devem ser projetados onde cada categoria de usuário seja avaliada para determinar as prováveis configurações que serão encontradas, reduzindo assim o número de variáveis de configuração para um número gerenciável.
*
TESTE DE CONFIGURAÇÃO
*
As aplicações Web e os ambientes cliente e servidor nos quais as aplicações estão alojadas representam um alvo para invasores externos, funcionários insatisfeitos, concorrentes desonestos e qualquer outro que queira roubar informações sigilosas, modificar conteúdo maliciosamente, degradar o desempenho ou desabilitar funcionalidades.
 
Estes testes são projetados para investigar vulnerabilidades: 
*
TESTE DE SEGURANÇA
*
Vulnerabilidades:
no ambiente do lado do cliente, 
Na comunicação de rede que ocorrem quando os dados são passados do cliente para o servidor
Na comunicação de rede que ocorrem quando os dados são passados do servidor para o cliente 
no ambiente do lado servidor. 
 
*
TESTE DE SEGURANÇA
*
A medida que em que aumenta o número de usuários nas aplicações web, consequentemente ocorre um aumento do número de transações online ou na quantidade de dados através das operações de download ou upload.
É muito frustrante para um usuário quando uma aplicação leva muitos minutos para carregar o conteúdo ou quando ao recebe do servidor uma mensagem do tipo “servidor ocupado”. 
*
TESTE DE DESEMPENHO
*
O teste de desempenho é usado para descobrir problemas de desempenho que podem resultar, por exemplo, da falta de recursos no lado do servidor, da largura da banda ou recursos de banco de dados inadequados. 
A intenção é entender como os sistemas respondem quando a carga aumenta e ainda reunir métricas que conduzirão a modificações de projeto para melhorar o desempenho.
*
TESTE DE DESEMPENHO
*
Este tipo de teste ajudará a responder as seguintes questões: 
O tempo de resposta do servidor degrada de forma a tornar-se inaceitável?
Em que ponto, sob o ponto de vista dos usuários, transações ou cargas de dados, o desempenho se torna inaceitável? 
Quais componentes do sistema são responsáveis pela degradação do desempenho?
Qual o tempo médio de resposta para usuários sob diferentes condições de carga?
*
TESTE DE DESEMPENHO
*
Para obter respostas a essas perguntas são feios dois testes diferentes de desempenho: 
Teste de carga 
Teste de esforço (stress)
*
TESTE DE DESEMPENHO
*
Teste de Carga  A finalidade do teste de carga é determinar como a webApp e seu ambiente do lado do servidor responderá a várias condições de carga. São utilizadas como condições de teste as seguintes variáveis:
Número de usuários concorrentes (N)
Número de transações on-line por usuários por unidade de tempo (T)
Carga de dados processados pelo servidor por transação (D)
*
TESTE DE DESEMPENHO
*
À medida que o teste é feito, são realizadas permutações nas variáveis de acordo com os limites de operação normal do sistema e coletas uma ou mais das seguintes medidas:
Resposta média do usuário;
Tempo médio para o download de uma unidade padronizada de dados;
Tempo médio para processar uma transação;
*
TESTE DE DESEMPENHO
*
Teste de Esforço (stress)  é uma continuação do teste de carga, e desta forma utilizam as mesmas variáveis: T, N, D, porém com seus limites operacionais excedidos.
A finalidade deste teste é responder as seguintes questões:
O sistema degrada ou o servidor desliga quando é excedida a capacidade normal de operação?
*
TESTE DE DESEMPENHO
*
O software servidor gera mensagens “servidor não disponível”? De uma maneira geral os usuários ficam cientes de que não podem acessar o servidor?
O servidor coloca as requisições por recursos em fila e esvazia a fila quando a demanda de capacidade diminui?
São perdidas transações quando a capacidade é excedida?
A integridade dos dados é afetada quando a capacidade é excedida?
*
TESTE DE DESEMPENHO
*
Quais valores de N, T e D forçam o ambiente servidor a falhar? Como a falha se manifesta? São mandadas notificações automáticas para o pessoal de suporte técnico no local do servidor?
Se o sistema falha, quanto tempo demora até que volte a ficar on-line?
*
TESTE DE DESEMPENHO
*
Testes de Software/CCT0204 - Aula 5.ppt
*
TESTES DE SOFTWARE – AULA 5
Prof. Ulisses Sperle Graça
Rio de Janeiro, setembro de 2011
ESTRATÉGIA DE 
TESTE DE SOFTWARE
TESTE DE UNIDADE
*
1. Compreender e definir os testes de interior do programa;
2. Implementar