Aula 7 ESII Vladimir Camelo

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

*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
São Paulo, 2019
Universidade Paulista (UNIP)
Teste de Software
Prof. MSc. Vladimir Camelo
vladimir.professor@gmail.com 
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Introdução
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Introdução
Objetivos das engenharias: Construir certo da 1ª vez.
Defeitos ou falhas não podem ser admissíveis;
Desenvolvimento de software: desenvolvedores são omissos no sentido de terem como política de desenvolvimento:
Escrever-testar-modificar: Este procedimento é realizado até obter o resultado esperado.
Entretanto esta não é a melhor forma de se desenvolver um software.
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Validação e Verificação
Atividades de Verificação e Validação servem para assegurar que o software funcione de acordo com o que foi especificado e atenda aos requisitos dos stakeholders.
Essas atividades constituem um processo iniciado com as revisões dos requisitos, passando pelas revisões da análise e do projeto do software e as inspeções do código até chegar aos testes.
Verificar não é demonstrar que a saída de uma fase do desenvolvimento é correta, mas averiguar se o software está de acordo com as especificações preestabelecidas.
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Validação e Verificação
A validação é o processo de confirmar que a especificação de uma fase ou do sistema completo é apropriada e consiste com os requisitos dos stakeholders.
A diferença entre verificação e validação é explicitada de forma sucinta com as seguintes perguntas:
Verificação: estamos construindo certo o produto?
Validação: estamos construindo o produto certo?
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Validação e Verificação
A verificação consiste, então, em identificar defeitos e possíveis problemas de um componente pronto, enquanto a validação busca avaliar se a construção do componente segue os requisitos predefinidos.
Os testes utilizam a execução do software para obter informações e são assim considerados técnicas dinâmicas de verificação e validação.
As revisões de software analisam e verificam as diversas fases do processo de desenvolvimento.
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Alguns fatores relacionados a Testes de software que possibilitaram a evolução das ferramentas e técnicas empregadas:
Evolução da engenharia de software:
Estabelecimento de técnicas;
Critérios;
Métodos; e
Ferramentas para a produção de software de forma mais criteriosa;
Testes de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Alguns fatores relacionados a Testes de software que possibilitaram a evolução das ferramentas e técnicas empregadas:
Crescente utilização de sistemas baseados em computação em praticamente todas as áreas da atividade humana;
Demanda constante por qualidade e produtividade, tanto no processo de produção como nos produtos gerados.
Testes de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Nos testes um conjunto de informações oriundas da atividade deve ser utilizadas como: depuração, manutenção e estimativa de confiabilidade de software.
A atividade de teste tem sido apontada como uma das mais onerosas no desenvolvimento de software.
Myers observa que aparentemente conhece-se muito menos sobre teste de software do que sobre outros aspectos e/ou atividades do desenvolvimento de software.
G. J. Myers. The Art of Software Testing. Wiley, New York, 1979
Testes de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Classificação de defeitos
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
O padrão Institute of Electrical and Electronic Engineers (IEEE) número 610.12:1990 (Standard Glossary of Software Engineering Terminology) diferencia os seguintes termos:
defeito (fault) – passo, processo ou definição de dados realizado de forma incorreta, como por exemplo, uma instrução ou comando incorreto disponibilizado por um determinado programa;
engano (mistake) – produzido por meio de uma ação humana acarretando em um resultado incorreto como saída de um programa, com por exemplo, uma ação incorreta tomada pelo programador no desenvolvimento de um determinado software;
IEEE - http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html. 
Testes de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
O padrão Institute of Electrical and Electronic Engineers (IEEE) número 610.12:1990 (Standard Glossary of Software Engineering Terminology) diferencia os seguintes termos:
erro (error) – diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário incorreto ou resultado inesperado na execução de um programa pode ser constituído como um erro; e
falha (failure) – produção de uma saída incorreta com relação à especificação.
Testes de software
IEEE - http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html.
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Classificação de defeitos
Diferentes tipos de defeitos no desenvolvimento do software:
Conhecer e compreender as diferenças entre defeito, erro e falha possibilita escolher ferramentas e técnicas corretas para tratar cada caso.
Armazenar informações histórica sobre defeitos possibilita compreender melhor o processo de desenvolvimento e antecipar a repetição dos mesmos problemas em novos projetos.
O uso de dados históricos, sobretudo quantitativos, é recomendado no nível 4 do CMMI. A prevenção de defeitos é uma área-chave do nível 5.
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Classificação de defeitos
Exemplo de técnica para classificar e tratar defeitos é o DPP (Defect Prevenction Process – Processo de Prevenção de Defeitos), da IBM.
O processo engloba quatro tarefas-chave, que são:
Análise causal, realizada sistematicamente;
Equipe de ação apoiada pela gerência;
Reuniões de partida;
Ferramentas e bases de dados para registro de informações.
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Classificação de defeitos
A classificação de defeitos é feita considerando dimensões que são listadas a seguir:
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Um princípio adotado ao testar um software é o de Pareto: afirma que existe um forte desequilíbrio entre causas e efeitos, entre esforços e resultados e entre ações e objetivos alcançados.
O princípio de Pareto afirma que 80% dos resultados que obtemos estão relacionados com 20% dos nossos esforços.
Os recursos para testes são escassos, um teste bem-sucedido é aquele que é ao mesmo tempo econômico e encontra o máximo de defeitos.
Para atingir esse objetivo, devem-se testar situações pouco ou mesmo absurdas. A pouca frequência de ocorrência torna tais situações justamente inesperadas aos programadores.
Testes Visão geral
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Uma boa estratégia consiste em planejar os testes antes da codificação do software, exatamente como sugerido pela metodologia XP.
Existem ao menos duas vantagens neste planejamento:
Identificar o que será testado, documentado as entradas e saídas de procedimentos e servindo de informação histórica para auxiliar os testes seguintes;
Auxiliar na codificação do software, uma vez que o programador descreve antes de iniciar a implementação dos casos de teste, que podem ser guias de possibilidades de defeitos e exceções no software.
Testes Visão geral
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
A confiabilidade de software pode ser definida como a probabilidade de este operar sem apresentar falhas, em um dado contexto de uso e em um intervalo de tempo determinado.
Os testes devem ser mais rigorosos à medida que a confiabilidade se torne uma característica com maior peso num modelo de qualidade.
A informação de falhas obtidas por testes de execução é de natureza essencialmente estatística.
Confiabilidade e disponibilidade
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Uma atividade de testes bem organizada pressupõe planejamento.
O plano de testes facilita a comunicação entre os envolvidos no desenvolvimento do software ao propor um padrão de referência a ser seguido.
O padrão apresentado pelo IEEE 829-1998 abrange:
Planejamento;
Especificação; e
Documentação dos testes.
Plano de testes
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Padrão IEEE 829-1998 para plano de testes:
Propósito: descreve o escopo, os recursos, a abordagem e o tempo alocado para as atividades de teste. Identifica os itens e funcionalidades a serem testados, os responsáveis e os riscos.
Identificador: Associa um identificador único ao plano de testes específico.
Introdução: Resume os itens e funcionalidades a serem testados. Pode haver referências a outros documentos do processo de desenvolvimento.
Plano de testes
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Padrão IEEE 829-1998 para plano de testes:
Itens: identifica os itens a serem testados, incluindo versão.
Funcionalidades: identifica as funcionalidades que serão testadas ou não, assim como os motivos;
Abordagem: especifica as principais atividades, técnicas e ferramentas usadas para o testes das funcionalidades. O detalhamento deve ser suficiente para permitir identificação das principais tarefas de teste e a estimativa de tempo para cada uma. As restrições significativas, como recursos e prazos, devem ser identificadas.
Plano de testes
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Padrão IEEE 829-1998 para plano de testes:
Critérios de aceite: especifica os critérios de aceite para cada item.
Suspensão: especifica os critérios para suspender parte ou toda a atividade de teste. Especifica as atividades que devem ser repetidas quando o teste for retomado.
Produtos: identifica os documentos produzidos, como planos, procedimentos, logs e relatórios.
Tarefas de teste: identifica as atividades necessárias para preparar e executar os testes, bem como todas as dependências entre as tarefas.
Plano de testes
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Padrão IEEE 829-1998 para plano de testes:
Ambiente: identifica as necessidades do ambiente: hardware, software de comunicação, segurança e ferramentas de auxílio.
Responsabilidades: identifica os grupos responsáveis por gerenciar, projetar, executar, verificar e resolver os testes.
Treinamento: especifica as necessidades de treinamento e identifica as opções.
Cronograma: identifica as atividades e os prazos de conclusão. Para cada recurso, como pessoas e ferramentas, especifica os períodos de alocação.
Plano de testes
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Padrão IEEE 829-1998 para plano de testes:
Riscos: identifica os maiores riscos e os planos de contingência.
Aprovações: especifica os nomes e cargos dos responsáveis por aprovar o plano. Devem ser inclusos espaços para assinaturas e data.
Plano de testes
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Critérios utilizados para a realização de teste de software:
Técnica funcional: os critérios e requisitos de teste de software são estabelecidos a partir da função de especificação do software testado;
Técnica estrutural: os critérios e requisitos são derivados essencialmente a partir das características de uma particular implementação em teste;
Técnica baseada em erros: os critérios e requisitos de teste são oriundos do conhecimento sobre erros típicos cometidos no processo de desenvolvimento de software.
Critérios para a realização de testes de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Existe ainda critérios de geração de seqüências de teste baseados em Máquinas de Estados Finito, sendo estes aplicados no contexto de validação e teste de sistemas reativos e sistemas orientados a objetos.
Critérios para a realização de testes de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Ao tratar programas de computador, o número de possibilidades a serem verificadas pode atingir facilmente uma cifra astronômica.
Cada teste da função, contendo um conjunto de entrada diferente – neste caso, composto por um único valor -, é chamado caso de teste.
Idealmente, os testes devem abranger o maior número de situações possíveis.
Casos de teste
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Casos de teste
Entradas Possíveis
Entradas corretas
Software
Análise de
Resultados
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
DijKstra (1979) afirmou que testes podem mostrar a presença de erros, mas não sua ausência.
Casos de teste
Dijkstra AM. Programming Considered as a Human Activity. Classics in Software Engineering. New York: Yourdon Press, 1979. p. 5.
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Existem boas razões para que um programador não teste o próprio código, que são:
Vicio com o código construído;
O código é resultado do trabalho intelectual do programador, procurar erros é uma espécie de ataque a suas próprias convicções;
Um programador não consegue criar um caso de teste que rompa com a lógica de funcionamento de seu próprio código.
Fatores psicológicos
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Para que o resultado de um teste de software seja confiável, é preciso garantir que os casos de testes utilizados cubram o maior número de possibilidades de execução.
Um conjunto de casos de teste é adequado se puder distinguir um produto correto de um incorreto.
Uma técnica proposta para avaliar casos de testes é a análise de mutantes.
Medindo a cobertura dos testes
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Análise de Mutantes (Mutation Analysis):
O critério de Análise de Mutantes surgiu na década de 70 na Yale University e Georgia Institute of Technology, possuindo um forte relacionamento com um método clássico para detecção de erros lógicos em circuitos digitais – o modelo de teste de falha única.
Um dos primeiros artigos que descreve uma idéia de teste de mutantes foi publicado em 1978.
R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):34–43, April 1978
Análise de Mutantes
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Análise de Mutantes (Mutation Analysis):
Técnica apresentada por DeMillo: hipótese do programador competente (competent programmer hypothesis): programadores experientes escrevem programas corretos ou muito próximo do correto.
Erros são introduzidos nos programas por meio de pequenos desvios sintáticos que, embora não causem erros sintáticos, alteram a semântica do programa e, conseqüentemente, conduzem o programa a um comportamento incorreto.
Análise de Mutantes
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Análise de Mutantes (Mutation Analysis):
Para revelar tais erros, a Análise de Mutantes identifica os desvios sintáticos comuns e, por meio da aplicação de pequenas transformações sobre o programa em teste, encoraja o testador a construir casos de testes que mostrem que tais transformações levam a um programa incorreto.
Análise de Mutantes
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Análise de Mutantes (Mutation Analysis):
Uma outra hipótese explorada na aplicação do critério Análise de Mutantes é o efeito de acoplamento (coupling effect), a qual assume que erros complexos estão relacionados a erros simples.
Nesse sentido, aplica-se uma mutação de cada vez no programa em teste, ou seja, cada mutante contém apenas uma transformação sintática.
Análise de Mutantes
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Análise de Mutantes
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Testes de mutação:
Idéia básica:
Injeção de falhas no código original originam mutantes;
A cada mutante é aplicado os testes originais:
Se os testes passam -> testes devem ser melhorados;
Se os testes falham -> o mutante diz-se neutralizado;
Se os testes detectam as falhas artificiais podemos assumir que detectará falhas reais;
Falhas injetadas pela aplicação de operadores de mutação.
Análise de Mutantes
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Testes de mutação: (Problemas com a técnica)
Vasto número de mutantes:
Escolha criteriosa dos operadores de mutação.
Processo dispendioso em tempo:
Eliminação de mutantes equivalentes - mutantes com o mesmo comportamento que o original;
Processo Weak ou Firm.
Detecção de mutantes equivalentes.
Neutralização dos chamados stubborn mutants: mutantes não equivalentes mas difíceis de neutralizar.
Análise de Mutantes
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Testes de mutação: (Problemas com a técnica)
Testes de Mutação ajudam a melhorar a qualidade dos testes;
Podem guiar o processo de criação de testes;
Usados em complemento com outro tipo de testes, em especial testes de cobertura de código;
Técnica valiosa para sistemas confiáveis e tolerantes a falhas, em conjunto com injeção de falhas por hardware;
Mutação pode ser aplicada a outras áreas: ex.: geração de dados de teste complexos
Análise de Mutantes
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Tipos de teste de software
Caixa-Preta:
É também chamado de teste funcional.
Na técnica de teste funcional são verificadas as funções do sistema sem se preocupar com os detalhes de implementação.
O nome caixa-preta é utilizado também na engenharia, no problema da identificação de sistemas, e advém do fato de que ao analisar o comportamento de um objeto, ignora-se totalmente sua construção interna.
Se comparado a outros tipos de testes, este é relativamente mais simples.
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Tipos de teste de software
Técnica funcional:
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
O teste de caixa-preta ou teste funcional envolve dois passos considerados importantes:
Identificar as funções que o software deve realizar para que estas funções possam ser testadas; e
Criar casos de testes capazes de checar se essas funções estão sendo realizadas pelo software de forma correta, ou seja, se atendem ao requisito solicitado pelo usuário durante a especificação do sistema.
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
As funções que o software deve possuir são identificadas a partir de sua especificação ou dos requisitos funcionais do software.
Assim, uma especificação bem elaborada e de acordo com os requisitos do usuário é essencial para a identificação e realização deste tipo de teste.
Como não há conhecimento sobre a operação interna do programa, o avaliador se concentra nas funções que o software deve desempenhar.
A partir da especificação são determinadas as saídas esperadas para certos conjuntos de entrada de dados.
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
O teste de caixa-preta reflete a visão do usuário, já que este utiliza o sistema sem considerar os detalhes de sua construção.
O teste de caixa-preta é relativamente útil para revelar problemas, tais como:
Funções incorretas ou omitidas;
Erros de interface;
Erros de comportamento ou desempenho;
Erros de iniciação e término.
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Ao realizar um teste de caixa-preta o avaliador deve buscar simular erros que um usuário pode cometer e que fogem da especificação do programa, por exemplo:
Usar como data de nascimento a data atual ou uma data futura;
Preencher campos com um número insuficiente de caracteres – por exemplo, digitar 123 para CPF ou telefone.
Códigos de CPF ou de CEP incorretos;
Deixar campos de entrada vazios ou preenchê-los com espaços brancos ou zeros – sobretudo campos de preenchimento obrigatório.
Usar valores negativos para números, como valor a pagar.
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Além da interface, pode-se verificar a execução de funções ou tarefas inteiras. Alguns exemplos de testes são:
Duplicar informações – por exemplo, tentar cadastrar duas vezes exatamente os mesmos dados.
Imprimir relatório para bases de dados vazias;
Procurar registros inexistentes.
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Teste de caixa-branca:
Os testes de caixa-branca são projetados em função da estrutura do componente e podem possibilitar a verificação mais precisa de comportamento do produto.
Este teste possibilita ao avaliador concentrar a atenção nos pontos mais importantes ou “perigosos” do código, de uma maneira mais precisa do que no caso do teste de caixa-preta.
Tais pontos podem ser identificados durante o desenvolvimento e cobertos pelos testes.
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Teste de caixa-branca:
Os testes de caixa-branca também é conhecido como teste estrutural.
O teste estrutural baseia-se no conhecimento da estrutura interna da implementação.
utiliza uma representação de programa conhecida como grafo de fluxo de controle ou grafo de programa
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Teste de caixa-branca:
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Há, entretanto, um elemento comum entre os testes caixa-preta e caixa-branca:
Em ambos
os casos, o avaliador não sabe qual será o comportamento do produto em uma determinada situação.
O teste de caixa-branca torna-se mais difícil à medida que a complexidade do sistema aumenta.
Alguns testes de caixa-branca podem ser realizados efetuando-se modificações no programa, por exemplo:
Fun (r1 -> ptr, n, tst.count())
Fun(NULL, n, tst.count())
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Teste de estresse:
É realizado para submeter o software a situações extremas.
Este teste baseia-se em testar os limites do software e avaliar seu comportamento, ou seja, até quando o software pode ser exigido e quais as falhas (se existirem) podem decorrer deste tipo de teste.
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Teste de estresse:
Os testes de estresse são fundamentais em aplicações em que a eficiência seja uma característica importante, por exemplo:
Servidores de arquivos e servidores web, que devem atender a solicitações de um grande número de clientes;
Aplicações industriais, tais como o controle de uma refinaria de petróleo;
Jogos de computador, que precisam de um desempenho aceitável para serem viáveis comercialmente.
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Teste de estresse:
Uma grande dificuldade em se realizar testes de estresse é a configuração adequada da plataforma de execução.
Exemplos de ferramentas que podem ser utilizadas para testes de estresse:
WinStress da Ultra-X
DieselTest
OpenSTA
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Teste de integração:
Quando todos os componentes de um software foram testados, surge um pergunta:
Quando estiverem ou forem integrados, estes componentes continuarão funcionando corretamente?
Com relação à integração de componentes, existem duas vertentes principais para o desenvolvimento de software:
Botton-up
Top-down
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Teste de integração:
Abordagem Botton-up: o programa é desenvolvido a partir de rotinas básicas que prestam serviços a rotinas de nível mais alto. Por exemplo: uma verificação de validação de CPF pode ser chamada em vários pontos de um programa.
Abordagem Top-down: faz-se o inverso; o programador trabalha supondo que o código de baixo nível já esteja pronto. Assim pode-se codificar chamadas à verificação de CPF, mesmo sabendo que ela ainda não existe. Em seu lugar pode haver uma rotina “fantasma” (stub).
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Orientado a Objetos:
O teste orientado a objetos consiste em realizar seqüências de envios de mensagens.
Essas seqüências devem ser escolhidas de maneira a explorar o maior número possível de estados que um objeto possa assumir e as transições entre eles.
Para que esse tipo de verificação seja eficiente, é interessante reduzir ao mínimo o número de casos de testes aplicados.
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Orientado a Objetos:
Ferramentas utilizadas para casos de testes em Orientação a Objetos:
Jcrasher - gratuita;
Jtest
JC++ - da Parasoft
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Teste de aceitação:
É realizado com o propósito de avaliar a qualidade externa do produto e, na medida do possível, também a qualidade em uso.
Este tipo de teste somente é possível de realizar quando o software esta totalmente concluído e pronto para ser implantado no cliente.
Este teste tem forte relação com o cliente, que participa do planejamento e realização desta atividade de teste.
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Teste de aceitação:
O teste de aceitação é denominado de “alfa” quando realizado no ambiente de desenvolvimento (qualidade externa) e “beta” quando realizado no ambiente do cliente (qualidade em uso).
O teste de qualidade externa é com freqüência a única alternativa no caso de aplicações desenvolvidas para mainframes.
Um outro tipo de teste de aceitação possível é o teste em paralelo, quando um sistema é desenvolvido para substituir um outro já em funcionamento. O novo sistema pode funcionar em paralelo ao antigo e o comportamento de ambos é comparado.
Tipos de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Algumas ferramentas prestam auxílio diretamente à observação de comportamento do código, como os:
Depuradores;
Monitores (profilers);
Geradores de casos de teste;
Entre outros.
Ferramentas de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Depuradores:
As ferramentas de depuração estão integradas as ferramentas de desenvolvimento e oferecem facilidade na utilização.
O primeiro uso comum dos depuradores é realizar o rastreamento (tracing) ou execução passo a passo (step by step).
O recurso de depuração é utilizado com tanta freqüência que as CPU’s passaram a incorporar recursos específicos para sua implementação.
Ferramentas de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Ferramentas de Depuração:
CodeGuard da Borland;
DevPartnesr Studio da Compuware
Entre outras.
Ferramentas de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Profilers:
Em aplicações nas quais o desempenho é crítico, é importante conhecer os pontos de gargalo, ou seja, as porções do programa que são responsáveis pela maior parte do processamento ou que consomem muitos recursos.
Ao implementar uma grande aplicação, nem sempre os pontos críticos são evidentes.
As ferramentas de profiling possibilitam obter estatísticas sobre a execução de um programa, tais como as funções mais utilizadas e a quantidade de memória e de CPU alocada por tais funções.
Ferramentas de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Exemplo de ferramentas de Profilers:
Optimizeit Profiler da Borland;
SQL Profiler para otimização de querys SQL da microsoft;
EJP (Extensible Java Profiler) gratuita;
Intel Vtune para Linux e para Windows.
Ferramentas de teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
A automação da geração de casos de teste pode agilizar bastante essa tarefa, auxiliando, por exemplo, a garantir que o maior número de caminhos do programa seja coberto pelos testes.
Existem diferentes versões desse tipo de ferramenta.
Os geradores de caos de teste estruturais criam casos de teste com base na estrutura do código-fonte.
Ferramentas para teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Exemplos de ferramentas utilizadas no mercado:
Selenium
TestComplete
Telerik Test Studio
Robotium
Watir
Hpe Unified Functional Testing
Ranorex
Cucumber
Visual Studio Test Professional
TestingWhiz
Badboy
Ferramentas para teste de software
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Devem ser realizadas com o objetivo de observação a ocorrência de problemas no software.
Podem ser realizadas revisões
individuais e revisões em equipe.
Revisões
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
Um arquivo de log pode estar presente na versão final do software liberado ao usuário.
A utilidade de um arquivo de log se deve ao fato de ser difícil replicar determinadas situações em laboratório assim como são vistas no ambiente do usuário.
Um arquivo de log pode mostrar todas as ocorrências existentes no ambiente do usuário.
Arquivos de log
vladimir.professor@gmail.com
*
vladimir.professor@gmail.com
*
*
vladimir.professor@gmail.com
*
São Paulo, 2019
Universidade Paulista (UNIP)
Teste de Software
Prof. MSc. Vladimir Camelo
vladimir.professor@gmail.com 
vladimir.professor@gmail.com
*