Qualidade e Pedro de Alcântara dos Santos Neto pasn@ufpi. @ufpi.edu.br Motivação Importância das Atividades de Qualidade Dependência por sistemas de software Testes e outras técnicas t são fundamentais para garantir a qualidade de tais sistemas No entanto, são caros e muitas vezes deixados de lado! Importância das Atividades de Qualidade Um dado impressionante do NIST: U$59.500.000.000,00 é o custo das falhas em software nos EUA, apenas em 2002. U$22.200.000.000,00 em economia, caso a infra- estrutura para testes fosse melhor. Importância das Atividades de Qualidade Mars Climate Orbiter Objetivo Enviar sinais a partir de marte, após s seu pouso no planeta Desastre Chocou-se com o planeta Motivo Bug no software responsável pela conversão de medidas Prejuízo» 165 milhões de dólaresd Importância das Atividades de Qualidade Airbus 320 Desastre USS Vicennes derrubou um airbus 320 em 1988 Motivo Bug no software de reconhecimento, confundindo o avião com um F-14F Prejuízo 290 mortes 1
Importância das Atividades de Qualidade Máquina de Terapia Radiotiva Desastre Overdose em pacientes sob tratamento Motivo Inabilidade em gerenciar certas condições de disputa Prejuízo Morte de 2 pessoas 6 outras lesionadas Importância das Atividades de Qualidade London Ambulance Service Desastre Serviço o auxiliado por computador falhou nos dias 26 e 27 de novembro de 1992, gerando várias v falhas, como o envio de 2 ambulâncias para o mesmo destino, envio de uma ambulância para um local estando outras mais próximas, etc. Motivo Tudo indica que o problema estava relacionado a alta carga de emergências durante o período. Prejuízo Morte de 20 pessoas Importância das Atividades de Qualidade Mais de uma centena de outras falhas... Como ficar livre disso? Importância das Atividades de Qualidade Expectativa Podemos esperar que o software funcione corretamente? Programas feitos com bastante cuidado 5 falhas / 1000 LOC Programa com 1 Milhão LOC 5000 falhas Windows P tem 45 Milhões de LOC 45 x 5000 = 225.000 Importância das Atividades de Qualidade Piada? Se a indústria automobilística tivesse se desenvolvido como a indústria do software, nós n s teríamos carros por U$25, fazendo 5000 milhas com um galão de combustível. Porém, esse carro iria quebrar duas vezes por dia, sem um motivo aparente, e quando você solicitasse assistência junto as concessionárias eles iriam dizer para você reinstalar o motor! 2
Importância das Atividades de Qualidade Carros são mais confiáveis que software? Importância das Atividades de Qualidade Como os carros são desenvolvidos? Requisitos Motor, rodas, ar-condicionado, som, espaço o para bagagem... Desenho detalhado Projeto arquitetônico, revisado várias v vezes Verificação do desenho Simulação, protótipo tipo Desenvolvimento de componentes Testa-se se cada componente Componentes são reusáveis Produzidos em massa Montagem do carro Testa-se se o carro (teste de batidas, teste de resistência, teste de estabilidade Teste de usabilidade Importância das Atividades de Qualidade Como os carros são desenvolvidos? Unidades Integração Integração Produto Concluído Importância das Atividades de Qualidade Características do LEGO Modularidade Reusabilidade Flexibilidade Compatibilidade No entanto, também m existem falhas! Tudo precisa ter sua qualidade aferida, seja por testes, seja por qualquer outra técnica! t Qualidade de Software O O que é Qualidade de Software? Totalidade de características de uma entidade que lhe confere a capacidade de satisfazer a necessidades explícitas e implícitas [NBR ISO 1994] Conformidade a: requisitos funcionais e de desempenho, padrões e convenções de desenvolvimento pré- estabelecidos, atributos implícitos que todo software desenvolvido profissionalmente deve possuir. [R.S.Pressman] 3
Modelo de Qualidade de McCall et al, 1977 Características Habilidade Operacionais: para ser correção alterado: manutenibilidade confiabilidade integridade flexibilidade eficiência testabilidade Adaptabilidade a novos ambientes: portabilidade reusabilidade interoperabilidade O O que é Qualidade de Software? Cada tipo de software tem seus próprios prios requisitos de qualidade A importância de cada característica de qualidade varia conforme o tipo de software Funcionalidade Confiabilidade Usabilidade Desempenho Manutenibilidade Portabilidade Sistema Sistema de de Controle Controle Sistema Sistema Embarcado Embarcado de de Mercearias Mercearias de de Satélite Satélite Por quê surgem falhas? Alterações: alterações degradam a estrutura do software, tornando-o o cada vez mais difícil de alterar Tempo: com o tempo os custos da implementação de alterações aumenta, e a capacidade do sistema em prestar os serviços esperados diminui Complexidade: difícil de desenvolver: um único desenvolvedor não é capaz de entender o sistema como um todo difícil de usar difícil de entender: código c incompreensível, falta de documentação Garantindo a Qualidade Aplicação de métodos m e ferramentas técnicast uso pelos desenvolvedores de métodos m e ferramentas que ajudem a conseguir especificações, projetos, etc, de maior qualidade Realização de revisões técnicas t e inspeções o objetivo é avaliar a qualidade do artefato de software (especificação, projeto,...) produzido ao longo do desenvolvimento Atividades de testes em complemento às s revisões e outras técnicast V&V Aplicação de padrões padrões podem ser usados: para documentos, documentação do código e estilo de codificação (como usar linguagem de programação) padrões podem ser determinados pelo cliente, por normas internacionais ou pela empresa de desenvolvimento. Garantindo a Qualidade Verificação e Validação (V&V) Verificação É o processo de se avaliar um software a cada fase para determinar se o produto dessa fase satisfaz ao que foi requerido no início da fase Objetivo: Assegurar consistência, completitude e corretude do produto em cada fase e entre fases consecutivas Estamos desenvolvendo certo o produto? Validação É o processo de se avaliar um software, durante ou após s o desenvolvimento, para determinar se o produto satisfaz aos requisitos Objetivo: Assegurar que o produto final corresponda aos requisitos do usuário Estamos desenvolvendo o produto certo? Garantindo a Qualidade Verificação ão Estamos desenvolvendo certo o produto? 4
Garantindo a Qualidade Validação ão Estamos desenvolvendo o produto certo? Garantindo a Qualidade V & V Fazer ou não? Garantindo a Qualidade V & V Fazer ou não? Garantindo a Qualidade V & V, fazer ou não? Permite encontrar falhas mais cedo Melhora a qualidade dos produtos Torna os requisitos mais estáveis Permite acompanhamento contínuo nuo da qualidade e da produtividade Facilita o gerenciamento Garantindo a Qualidade V & V, fazer ou não? Aumenta os custos do desenvolvimento análise custos benefícios iniciar V&V o mais cedo possível enfocar partes mais críticas do sistema (análise de riscos) Aumenta a interação entre equipes escolher equipe experiente para V&V envolver equipe de V&V desde cedo Aumenta a documentação melhora a qualidade Requer compartilhamento de recursos (e/ou dados) críticos prever no contrato com o cliente Garantindo a Qualidade Atividades de V & V Verificação estática tica não envolve a execução do produto visa determinar propriedades do produto válidas v para qualquer execução do produto final Revisões, inspeções Verificação dinâmica envolve a execução do produto (código ou modelo executável) visa encontrar falhas ou erros no produto Teste 5
Garantindo a Qualidade Porcentagem 80 70 60 50 40 30 20 10 0 Atividades de Garantia da Qualidade 17 10 20 16 19 16 16 Inspeções Formais PBQP Software - MCT Revisões Estruturadas 62 67 57 48 47 48 47 52 Testes de Aceitação Atividade Testes do Sistema Integrado 31 35 24 23 Testes de Unidade 1995 1997 1999 2001 Garantindo a Qualidade Teste é o processo de executar um programa com o intuito de encontrar erros Glenford J. Myers (1979) Pode mostrar a presença a de falhas, mas nunca a sua ausência - Dijkstra Processo de execução de um sistema ou componente sob condições especificas para detectar diferenças entre os resultados obtidos e os esperados (IEEE) Garantindo a Qualidade Custo da Qualidade Esforço por Atividade Command-control SAGE-NTDS Command-control TRW Sapceborne OS/360 Científico TRW Comercial Raytheon Análise Projeto Codificação e Auditoria Teste e Integraçao 35% 17% 48% 46% 20% 34% 34% 20% 46% 33% 17% 50% 44% 26% 30% 44% 28% 28% Quando os testes devem começar? As atividades de testes devem ser integradas às atividades de desenvolvimento As atividades de teste devem ser iniciadas cedo Procedimentos de teste podem ser descritos desde a fase de especificação Fases do Teste Ciclo dos Testes Especificação Planejamento Objetivos do Teste O quê testar? Oráculo Desenho Execução dos Casos de Teste Implementação Determinação de estratégias para delimitar os objetivos Execução Geração de Procedimentos e Casos de Teste Entradas Saídas Obtidas Passou Não passou Inconcludente Erro Veredicto Determinar se os objetivos foram atendidos Registrar lições aprendidas, gerando um relatório rio final Verificação Balanço Final Software 6
Dificuldades do Teste Detecção de falhas se dád através s da ocorrência de defeitos É necessária a existência de uma especificação Falhas nos requisitos podem não ser detectadas Especificação incompleta ou ambígua pode levar a resultados incorretos ou inadequados Dificuldades Testes não podem ser exaustivos não servem para demonstrar corre Certas tarefas de testes não podem ser automatizadas não servem para demonstrar correção de um sw problemas intratáveis e indecidíveis Veredictos de testes dependem das saídas esperadas mas elaborar mecanismo que produza as saídas esperadas (oráculo) é difícil ou mesmo impossível Testar Não é Tudo! Testar não é a única forma de encontrar falhas em um software testes devem complementar outras formas de V&V e não substituí-las Há falhas que dificilmente seriam reveladas através de testes As revisões e inspeções são mais efetivas na descoberta de erros! Como tornar a atividade de teste mais eficiente? Utilizar outras técnicas t de V&V combinadas ao teste Uso de ferramentas e metodologias Reuso de casos de teste sempre que possível Integração das atividades de testes com as atividades de desenvolvimento Uso de estratégias com base em riscos Garantindo a Qualidade Pequeno teste : Um programa lê 3 inteiros. Os três valores são interpretados como os comprimentos dos lados de um triângulo. O programa imprime uma mensagem que mostra que o triângulo é escaleno, isósceles sceles ou eqüil ilátero. Em uma folha de papel, escreva um conjunto de casos de testes (ex.: especifique conjunto de dados) que você acredita ser adequado para testar esse programa. Garantindo a Qualidade Pequeno teste : 1. Você tem um caso de teste que representa um triângulo escaleno válido? (Note que casos de testes como 1,2,3 e 2,5,10 não ganham um u sim nesta pergunta, pois não existem triângulos válidos v com esses lados.) 2. Você tem um caso de teste que representa um triângulo eqüil ilátero válido? 3. Você tem um caso de teste que representa um triângulo isósceles? sceles? (Um caso de teste com 2,2,4 não pode ser contado.) 4. Você tem no mínimo m 3 casos de testes que representam um triângulo isósceles sceles válido v e que você tenha tentado as três permutações possíveis (Ex.: 3,3,4; 3,4,3;4,3,3)? 5. Você tem um caso de teste no qual um dos lados é zero? 6. Você tem um caso de teste no qual um dos lados tem o valor negativo? 7
Garantindo a Qualidade Pequeno teste : 7. Você tem um caso de teste com 3 inteiros maiores que zero, onde a soma de dois lados é igual ao terceiro lado? (Se o programa disser que 1,2,3 representa um triângulo escaleno, ele contém m um erro.) 8. Você tem no mínimo m 3 casos de teste da categoria 7 para as quais você tentou as três permutações? (Ex.: 1,2,3; 1,3,2 e 3,1,2) 9. Você tem um caso de teste com 3 inteiros maiores que zero, onde a soma de dois lados é menor que o terceiro lado (1,2,4 ou 12,15,30)? 10. Você tem um caso de teste na categoria 9 para o qual você tentou as três permutações (Ex.: 1,2,4; 1,4,2 e 4,1,2)? 11. Você tem um caso de teste no qual todos os lados são 0 (Ex. 0,0,0)? 0)? 12. Você tem um caso de teste especificando valores não-inteiros? 13. Você tem um caso de teste especificando uma quantidade errada de valores (Ex.: dois em vez de 3, inteiros)? 14. Para cada teste, você especificou a saída esperada do programa além dos valores de entrada? Garantindo a Qualidade Pequeno teste : Obviamente, um conjunto de casos de testes que satisfaça as condições anteriores não garantem que todos os erros possíveis foram encontrados. Como ponto de referência: Programadores altamente experientes obtiveram, na média, somente 7.8 pontos no total de 14. Mesmo de um programa trivial como este não é uma tarefa fácil. f E, se isso é verdade, considere a dificuldade de testar um sistema de controle aéreo a com 100.000 linhas de códigoc Garantindo a Qualidade Princípios do Teste [Myers]: não planeje o teste assumindo que o programa está correto um bom caso de teste é aquele que tem alta probabilidade de encontrar erro ainda não descoberto caso de teste bem sucedido é aquele que detecta erro ainda não descoberto a a probabilidade de existência de mais erros numa parte do programa é proporcional ao número n de erros jáj descoberto na mesma Garantindo a Qualidade Princípios do Teste [Myers]: teste deve ser feito por outra pessoa que não o autor do programa dados de teste devem ser definidos para dados inválidos e não-esperados determinar SEMPRE os resultados esperados verificar cuidadosamente os resultados de cada teste nunca jogue fora casos de teste, a não ser que esteja jogando fora também m seu programa Conceitos BásicosB Conceitos BásicosB Teste consistes na verificação dinâmica do funcionamento de um programa em um conjunto finito de casos de teste, cuidadosamente selecionado dentro de um domínio infinito de entradas, contra seu funcionamento esperado. Dinâmico Execução Finito Existem muitos casos de teste Selecionado Técnicas diferem na seleção Esperado Funcionamento deve ser verificado 8
Conceitos BásicosB Terminologia Elementos do Teste Procedimento de Teste» Documentação especificando uma seqüência de ações a para execução de um teste. Caso de Teste» Documentação especificando entradas, resultados esperados, e um conjunto de condições de execução para um item de teste. Plano de Teste» Documento que descreve o escopo, abordagem, recursos e agenda para as atividades de teste, identificando os itens de teste, as construções a serem testadas, as tarefas envolvidas, executores e riscos associados. Níveis de Teste IEEE STD 829-1983 Níveis de Teste Alvo do Teste Módulo simples Um grupo de módulosm Agrupado por propósito, uso, ou estrutura O O sistema completo Níveis de Teste Teste de Unidade Teste de caixa branca (estrutural) Conduzido em paralelo para vários v módulosm Diversas Características avaliadas Interface Operações sobre variáveis veis Caminhos de execução importantes Caminhos de atendimento a erros Condições de contorno Níveis de Teste Teste de Unidade Características Avaliadas interface» dados entram e saem corretamente» número e tipo de parâmetros - compatibilidade operações sobre variáveis veis» cálculos incorretos» over/underflow underflow, índices, etc. caminhos de execução» caminhos importantes» caminhos de atendimento a erros Níveis de Teste Teste de Unidade Características Avaliadas atendimento a erros» rotina de erro corresponde ao erro encontrado» erro causa intervenção do sistema antes do atendimento» mensagem elucida causa do erro? condições de contorno» testes com valores máximo, mínimo, imediatamente abaixo e acima de itens de dados e de variáveis veis de controle de loops erros comuns» precedência de operadores incorreta» comparações de tipos de dados diferentes» terminação inexistente de ciclos» erros de precisão 9
Níveis de Teste Teste de Unidade Ambiente para Teste de Unidade Driver: chamador do módulo em teste» Inicialização das variáveis veis e dos parâmetros da chamada Stub: : módulos m chamado pelo módulos m testados stub driver módulo stub Níveis de Teste Teste de Unidade Planejamento do Teste de Unidade escolha de critério rio de cobertura lógical selecionar caminhos de teste determinar casos de teste caso de teste» dado de teste» resultado esperado Demonstração: Criando Testes de Unidade Teste de Unidade Práticas aconselhadas: Todo desenvolvedor deve criar teste de unidade para o código c produzido Tais testes devem passar por revisões, seja por membros da equipe e de teste, seja por um desenvolvedor com um pouco mais de experiência em testes Considerar a possibilidade de desenvolver geradores automáticos ticos de objetos É importante o suporte de transações para evitar problemas com a repetição dos testes Considerar a possibilidade de cada desenvolvedor ter seu próprio prio banco Considerar a possibilidade de separar a implementação dos seus testes, pois podem existir muitas classes, gerando confusão Importante o uso de analisadores estáticos ticos para garantia de certas propriedades Níveis de Teste Teste de Integração ão Processo de verificar a interação entre os componentes. Montagem do software com módulos m jáj testados Verificação da interface entre módulosm Funções parciais e global do sistema Estratégias de integração topdown bottom-up mista Níveis de Teste Teste de Integração Top-Down integração parte do módulo m principal para os módulos m que implementam funções primitivas tipos: vertical: segundo o fluxo principal de controle horizontal: incorpora todos os módulos diretamente subordinados a cada níveln M5 M8 M1 M2 M3 S4 M6 S7 10
Níveis de Teste Plano de Integração Práticas Aconselhadas Determine uma estratégia de integração Verifique com cuidado a ordem de acoplamento Isso pode ter um impacto direto na sua estratégia Determinar casos de teste Gerar drivers e stubs Uma boa prática Integração bottom-up facilita a integração das unidades, sem a necessidade de retrabalho Tempo para apresentação do produto final aumenta, mas a priorização dos casos de uso minimiza esse problema Demonstração: Teste de Integração Níveis de Teste Teste de Sistema Teste no sistema completamente integrado, para verificar o atendimento aos requisitos. Envolve o teste de todos os requisitos funcionais e não funcionais. Teste de recuperação» Força a falhas para verificar a recuperação do sistema Teste de segurança» Desenvolvedor assumindo o papel de hacker» Objetivo é tornar o custo da invasão maior que o valor dos dados Teste de estresse e desempenho Níveis de Teste Teste de Sistema Teste de segurança Existem diversas ferramentas que auxiliam esse tipo de teste Verificações realizadas:» Descoberta de servidores» Determinação da estrutura do sítio s web» Geração de mensagens muito grandes» Geração de mensagens com elementos excepcionais» Execução de port scans» Execução de DoS denial-of-service service» Execução de vulnerabilidades comuns a servidores Web Objetivos do Teste O teste de software geralmente é conduzido por objetivos, que podem ou não ser claros Diferentes propriedades podem ser verificadas 11
Teste de Aceitação Verifica se o software funciona de acordo com as necessidades do cliente Geralmente feito pela empresa contratante Pode envolver desenvolvedores Teste de Instalação Verifica se a instalação do software no ambiente alvo ocorre corretamente. Necessário para softwares que executam em diferentes plataformas de hardware e software Ex: Imposto de Renda Pode incluir a verificação de todo o procedimento de instalação, que envolve dentre outras coisas, as instruções de instalação Teste de Instalação Práticas Aconselhadas: Sistemas com diversos tipos de usuário, com diferentes configurações de hardware e software precisam desse tipo de teste Idealmente, pessoas sem conhecimento do software a ser instalado deveriam ser selecionadas para a verificação da documentação de instalação Testes Alfa e Beta Antes da liberação de uma versão do produto, pode ser realizado testes com usuários finais na organização desenvolvedora (alfa) ou fora da organização, preferencialmente nas instalações dos usuários finais (beta). Práticas Aconselhadas Teste alfa pode ser combinado com teste de usabilidade, reduzindo custos Mas isso deve ser feito em etapas iniciais, por isso, essa prática deve ser seguida por desenvolvimento baseado em iterações Testes de Regressão Testes realizados a cada vez que um sw é alterado Objetivo: validar modificações feitas mostrar que modificações realizadas não afetaram as partes que não foram modificadas Ou seja: mostrar que o software não regrediu Objetivos do Teste Testes de Regressão Linha básica b ( baseline( baseline ) versão de um componente (ou sistema) jáj testada Delta modificação feita a um componente (ou sistema) e que ainda não foi testada Configuração delta ( delta( build ) configuração executável do sistema contendo deltas e linhas básicas Caso de teste de regressão caso de teste aplicado à linha básica b com veredicto = passou se veredicto = não passou na configuração delta» falha de regressão 12
Objetivos do Teste Testes de Regressão Testar aplicações críticas que devem ser retestadas freqüentemente entemente Testar sw que é alterado constantemente durante o desenvolvimento (por exemplo, Processo Incremental) Testar componentes reutilizáveis para determinar se são adequados para o novo sistema Quando? Durante os testes de integração Durante os testes, após s correções Na fase de manutenção (corretiva, adaptativa, perfectiva ou preventiva) Quando háh mudanças as de plataforma Testes de Regressão Falhas de regressão ocorrem quando háh dependências entre D (delta) e B (linha básica): b de fluxo de controle de fluxo de dados restrições de ativação compartilhamento de dados tempo disputa por recursos Testes de Regressão Programa original = P Programa modificado = P P Abordagens: retesta tudo: T T = T seletiva: T T T qual abordagem usar? P P T T? Testes de Regressão Sejam: T e T cardinalidades de T e T T s custo médio m de seleção/caso de teste r custo médio m de execução/caso de teste se s T T < r ( T - T T ) regressão seletiva mas se potencial detecção falhas T T < T retesta tudo P P T T Testes de Regressão P T Problema: Segurança P T como obter T T contendo casos de teste t T T que exercitem código de P que foi modificado em P? P Problema Indecidível O O uso de uma seqüência de regressão segura todos os casos de teste que podem revelar a presença a de falhas foram aplicados ~ ausência de falhas de regressão ou de qualquer outro tipo de falha Testes de Regressão Retesta tudo Segura Caixa Branca reaplica todos os testes da linha básicab Retesta no firewall Segura seleciona casos de testes analisando dependências de códigoc Retesta casos de uso de maior risco Caixa Preta seleciona casos de testes com base em análise de riscos Retesta de acordo com o perfil seleciona casos de teste de acordo com o perfil operacional: retestar as parte mais usadas 13
Testes de Regressão Retesta no firewall Analisa conjunto de componentes (classes, programas, módulos,...) que devem ser incluídos nos testes de regressão Dependências entre A (delta) e B (inalterado):» B usa A (B é cliente de A)» B é servidor de A» B é subclasse de A» B sobrecarrega A (polimorfismo) Testes de Regressão Retesta no firewall Testes de Regressão Retesta no firewall Dependência entre componentes Testes de Regressão Retesta no firewall Seleção de testes Testes de Regressão Ferramentas Para testes de regressão existem muitas Para seleção de testes de regressão existem muitas, principalmente de caráter acadêmico» Muito pouco existe para uso comercial e em um ambiente de produção Testes de Regressão Práticas Aconselhadas Uma boa estratégia inicial é o uso dos testes de unidade e de integração como testes de regressão Mantenha todos, até que sua execução fique impraticável, por exemplo, por causa do tempo de execução Se isso ocorrer, use alguma técnica t de seleção 14
Testes de Regressão Práticas Aconselhadas Procure usar uma ferramenta de integração contínua! nua! Servidor de Builds Sempre busca por alterações Reporta erros aos interessados» E-mail, netsend, tryicon (messenger) Verifica padrões de codificação Cria rótulos r no ambiente de gestão de configuração Exemplo: CruiseControl.NET» SourceSafe Demonstração: Teste de Regressão Testes de Desempenho e Estresse 3 3 Cenários comuns: 1: não existe nenhuma ou quase nenhuma preocupação quanto ao desempenho e performance do sistema pois não existe nenhum gargalo aparente. 2: existe uma chocante necessidade de uso em escala extrema e toda a concentração da equipe fica voltada para a capacidade de processamento, prejudicando o andamento das funcionalidades de negócio. 3: existe um equilíbrio entre produzir o software e garantir que suas funcionalidades atendam a demanda esperada. Somente a metodologia, experiência e conhecimento de processos conseguem garantir tal equilíbrio. Testes de Estresse O O teste de estresse é realizado para confrontar os programas com situações anormais. Essencialmente, a pessoa que realiza esse teste pergunta: até que ponto podemos elevar isto até que falhe? O O teste de estresse executa o sistema de uma forma que exige recursos de quantidade, freqüência ou volume anormais. Testes de Estresse Exemplos: Entrada de dados podem ser aumentados em uma ordem de magnitude para determinar como as funções de entrada responderão. Os casos de teste que exigem o máximo m da memória ou outros recursos podem ser executados. Qualquer outro teste que tente, essencialmente, destruir o programa. Objetivos do Teste Testes de Desempenho O teste de desempenho é idealizado para testar o desempenho do software quando executado dentro do contexto de um sistema integrado. É importante definir o contexto, ou seja, descrever o ambiente, no qual o desempenho será medido. Exemplo: Número de usuários simultâneos Configuração da máquina m que está sendo utilizada Os atributos relacionados com o desempenho irão variar de sistema para sistema. 15
Testes de Desempenho Para executarmos um teste de desempenho devemos seguir os seguintes passos: Definir o contexto no qual o desempenho será medido; Definir, de acordo com os resultados esperados, o que constituirá uma performance aceitável; Executar os testes e avaliar os resultados. Testes de Desempenho e Estresse - Passos Entender melhor o problema Qual é a demanda prevista para usar a solução?» 200 acessos por dia em média. m Existe possibilidade de picos? Se sim, qual o pico previsto?» Sim. Podemos chegar a um pico de 100 usuários simultâneos. Qual é o tempo de resposta desejado?» O nível n ideal de trabalho é que o usuário não espere mais do que 2 segundos por cada resposta. Os acessos durante o dia vão se concentrar mais em um horário rio específico?» Sim, 80% devem ocorrer entre as 11:00 e 21:00. Demonstração: Testes de Desempenho e Estresse JMeter Usaremos uma aplicação exemplo com apenas 2 casos de uso: Login: autentica usuário no sistema Gestão de Usuários: gerencia dados de usuários Vamos simular o acesso concorrente de 10 usuários e gerar relatórios rios com os resultados Objetivo do Teste: Medir o tempo médio m de resposta de todas as requisições, identificar a página p que consome mais tempo. JMeter Configurar valores comuns entre as URLs; Criar componentes Config Elements No nosso exemplo, utilizaremos um HTTP Request Defaults Informar o servidor, porta, caminho e tudo que for padrão para os testes a serem criados Exemplo:» Server Name: localhost» Port Number: : 8080 JMeter Configurar as requisições HTTP Adicionar um Thread Group (responsável pela criação de threads) Cada thread representará 1 usuário Informar o número n de threads e o período usado para iniciar tais threads Exemplo:» Number of Threads: : 2» Ramp-Up Periodo: : 2 Pode-se agendar o teste para outros dias e horários rios 16
JMeter Configurar as requisições HTTP Adicionar elementos do grupo Logic Controller: Once Only Controller: : que irá conter requisições que sós devem ocorrer 1 vez em um loop por usuário» login Simple Controller: : requisições que ocorrem mais de 1 vez por usuário (ex: consultar valor, realizar pesquisa,...)» Exibir lista de usuários JMeter Configurar as requisições HTTP Adicionar requisições para cada um dos elementos selecionados JMeter Definir a forma de apresentação dos resultados Adicionando os Listeners ao plano de testes Testes de Desempenho Práticas Aconselhadas Procure sempre verificar o funcionamento do seu sistema sob circunstâncias anormais Isso pode revelar comportamentos indevidos que podem gerar prejuízos - Teste de Usabilidade Participantes representativos avaliam o grau que um produto se encontra em relação a critérios rios específicos O teste de usabilidade não é uma pesquisa. É uma avaliação do sistema feita por especialistas, através da observação e análise do comportamento do usuário enquanto ele navega e executa tarefas específicas. São mais eficientes quando implementados como parte do processo de desenvolvimento de um produto - Teste de Usabilidade Os testes podem ser feitos em cada uma das etapas do projeto. Problemas detectados precocemente são corrigidos a um custo muito menor em qualquer aspecto Fornecer um retorno mais rápido r para o cliente, que vê o seu pedido tomando forma antes do produto estar necessariamente pronto. 17
- Teste de Usabilidade Processo É feito utilizando uma amostragem dos próprios prios futuros usuários do sistema. São selecionados de 3 a 5 participantes representativos de um grupo de usuários do programa. Este grupo é colocado em contato com a interface criada e têm que executar algumas tarefas pré-definidas pela equipe de teste. Todos os passos dos participantes são monitorados e gravados. Em seguida, a equipe de teste faz uma minuciosa entrevista dos participantes - Teste de Usabilidade Ambiente FísicoF Melhor opção é utilizar 2 salas uma reservada aos testes outra reservada à observação Na sala de observação, os observadores assistem, mas não se comunicam diretamente com o avaliador. O O som e as imagens são captados pelas câmeras de vídeo v e transmitidos diretamente para o monitor de vídeo v da sala de observação. - Teste de Usabilidade Ambiente FísicoF - Teste de Usabilidade Ambiente FísicoF - Teste de Usabilidade Ambiente FísicoF Através s do segundo monitor, moderador observa o desempenho do participante e toma notas. Uma câmera estrategicamente posicionada filma tanto as reações do participante quanto seu caminho percorrido no site. Objetivos do Teste - Teste de Usabilidade Resultados As observações da equipe de teste, aliadas às s respostas das entrevistas com os participantes, são transformadas em um relatório rio detalhado, contendo: Descrição e Metodologia do Roteiro do Teste Uma breve descrição explicativas das metas propostas e de como se chegou nelas. Análise do Comportamento dos Participantes Como os participantes se comportaram durante o teste? Sorriam? Faziam cara de sofrimento? Coçavam a cabeça? a? Perguntavam muito?» Parece bobagem, mas isso é essencial para avaliar o sucesso da interface. Resumos das Entrevistas Pós-TesteP As principais opiniões, perguntas, dúvidas, d reclamações e sugestões dadas pelos participantes após s o teste. 18
Objetivos do Teste - Teste de Usabilidade Resultados Problemas de Usabilidade Lista dos problemas de usabilidade encontrados.» Cada problema é tratado detalhadamente, com descrição dos critérios rios heurísticos que ele viola, seu grau de severidade, o custo para o cliente de não consertar o problema versus o custo de resolvê-lo lo. Principais Paradas Críticas» Mais do que um simples problema, uma parada crítica é um beco sem saída do sistema. Seja físico f (o usuário não tem mais fisicamente aonde ir) ou psicológico (o usuário fica tão confuso e frustrado que simplesmente pára, p desiste), as paradas críticas, se existirem, têm que ser tratadas como prioridade absoluta. Plano de Correção» São propostas soluções eficientes e cost-effective para cada problema encontrado. Cada solução é sempre pensada em termos de custo-benef benefício para o cliente. - Teste de Usabilidade Práticas Aconselhadas A A Usabilidade de um sistema pode ser uma ótima estratégia de marketing A A Usabilidade exprime parte do contentamento do usuário com o trabalho realizado A A realização de testes de usabilidade em etapas iniciais do projeto possibilitam correções mais baratas Esse tipo de teste pode ser realizado em conjunto com testes alfa, reduzindo custos Para isso é necessário uma estratégia de priorização de casos de uso com entrega evolutiva Técnicas de Teste Técnicas de Teste Técnicas de Teste Têm como objetivo auxiliar a detecção do maior número n de falhas. Devem ser sistemáticas ticas para tentar identificar um conjunto representativo de comportamento do programa. É muito difícil classificar as técnicas t de forma homogênea. Utilizamos um classificação baseada em como testes são gerados: Intuição e experiência dos engenheiros de software Especificações Estrutura do códigoc Falhas a serem descobertas Campo de uso Natureza da aplicação Técnicas de Teste Técnicas de Teste Caixa Branca Testes são criados com base em como o software foi projetado ou codificado. Também m chamado de teste de caixa de vidro. Objetivo de derivar casos de teste que garantam:» Exercício cio de todos os caminhos independentes de um módulom» Exercício cio de todas as decisões lógicas l (verdadeiro e falso)» Exercício cio de todos os ciclos em seus limites e dentro de seus intervalos operacionais» Exercício cio das estrutura de dados internas Técnicas de Teste Técnicas de Teste Caixa Preta Casos de teste são criados usando apenas o comportamento de entrada e saída do SUT (Software Under Test). Não é uma alternativa aos testes de caixa branca, é uma abordagem complementar que deve descobrir uma classe diferentes de erros. Encontra erros nas seguintes categorias:» Funções incorretas ou omitidas» Erros de interface» Erros de estrutura de dados ou de acesso a base de dados externas» Erros de comportamento ou desempenho» Erros de iniciação e de términot 19
Técnicas de Teste Técnicas de Teste Caixa Preta Questões a serem verificadas:» As funções são realizadas?» As entradas produzem resultados esperados?» Integridade das informações externas é mantida Métodos para determinação de dados de teste» Particionamento em Classes de Equivalência» Análise de Valores Limites do Domínio» Grafos Causa-Efeito Técnicas de Teste Caixa Preta Particionamento de Equivalência Identificação de classes de equivalência sobre o domínio dos dados de entrada Domínio de entrada é subdividido em sub-dom domínios Selecionar dados para cada sub-dom domínio Exemplo: domínio: datas sub-dom domínios: dias úteis e feriados Técnicas de Teste Caixa Preta Particionamento de Equivalência Técnicas de Teste Caixa Preta Particionamento de Equivalência Listar condições de entrada descritas na especificação do programa Identificar para cada condição: domínios válidos, v enumerações válidas e valores não válidosv Decompor condições compostas em elementares Criar um conjunto de dados de teste, onde cada dado exercite pelo menos uma condição Técnicas de Teste Caixa Preta Particionamento de Equivalência Passos: Decompor o programa em funções Identificar as variáveis veis que determinam o comportamento de cada função Particionar os valores de cada variável vel em classes de equivalência (válidas e inválidas) Especificar os casos de teste:» eliminar as classes impossíveis ou os casos desinteressantes» selecionar casos de testes cobrindo as classes válidas v das diferentes variáveis veis» para cada classe inválida escolha um caso de teste que cubra 1 e somente 1 de cada vez Técnicas de Teste Caixa Preta Particionamento de Equivalência Classes de Equivalência podem ser definidas de acordo com as seguintes diretivas: Intervalo, uma válida v e duas inválidas Um valor, uma válida v e duas inválidas Membro de um conjunto, uma válida v e uma inválida Booleana,, uma válida v e uma inválida 20