Download - Validação e Testes de software
About me
Rondinelli Mesquita Developer | Tester | Coffee | Rock
• Sistemas de Informação• Esp. Desenv. Aplicativos Móveis• Instituto Atlântico - Fortaleza
rondymesquita.com.br
Skills
• Java• Android• Javascript• Automated Tests
O que é realmente testar
“Testar é o processo de executar o programa com a intenção de
encontrar erros”(MYERS, BADGET e SANDLER, 2012)
Perfil de um Tester
Demonstrar que existem erros no software e auxiliar equipe na
resolução desse erro.
Regra 10 de Myers
Custo da correção de defeitos: Extraído de Bastos; Rios; Cristalli; Moreira (2007)
Redução de defeitos • Testes unitários podem remover entre 30%
e 50%• Testes sistêmicos podem remover 30% e
50%• Revisões de códigos podem reduzir entre
20% e 30%• Mesmo assim, os sistemas podem ir para a
produção ainda com aprox. 49% de defeitos
Extraído de Bastos; Rios; Cristalli; Moreira (2007)
Ciclo de Vida do Software Um software pode ainda estar rodando mesmo depois de ter sido construído (10 anos…)
Riscos?
• Falta de profissional especialista na tecnologia
• Custo de parar o sistema que está rodando para corrigir um erro
Mitos
“A equipe de testes pode ser montada com os
desenvolvedores menos qualificados, pois qualquer um pode testar sistemas”
Como priorizar? Quais testes são importantes? • Analisar os riscos e impactos– Requisito: tempo de resposta -> Teste de
performance
“É necessário ter uma metodologia estruturada de teste”
Verificação x Validação • Verificação: realizar inspeções sobre os
artefatos gerados nas etapas do processo
• Validação: Avaliar se o sistema atende aos requisitos
Definições de verificação e validação. Fonte: Extraído de Bastos, et al (2007)
Inspeção de código (verificação) O time inspeciona os artefatos produzidos à procura de possíveis erros. Importante existir um checklist.
Conduzindo por um desenvolvedor que não seja o autor do código
Ferramentas: PMD e FindBugs
(MYERS, BADGET e SANDLER, 2012)
Passo a passo (walkthrough) Geralmente informal, o autor do código apresenta o código para o time e o time faz sugestões.
(MYERS, BADGET e SANDLER, 2012)
Passos do Processo de Teste 1. Acesso ao Plano de Desenvolvimento2. Plano de Testes3. Avaliação dos Requisitos do Software4. Avaliação do Desenho5. Inspeção da Construção do Software6. Execução dos Testes
1. Abordagem2. Ferramentas3. Tipos de Teste
Passos do Processo de Teste 7. Teste de Aceitação
8. Informação dos Resultados1. Bugs
2. Melhorias
9. Teste de Instalação
10. Teste das Mudanças
11. Avaliação da Eficácia
Ciclo de vida de testes
1. Planejamento2. Preparação3. Procedimentos Iniciais4. Especificação5. Execução6. Entrega
Ciclo de vida de testes: Adaptado de Bastos, et al (2007)
Nível de Teste de Software • Representa a que fase do desenvolvimento
se aplica um determinado teste.
– Teste de Unidade
– Teste de Integração
– Teste de Sistema (ou sistêmico)
– Teste de Aceitação
Teste de Unidade Estágio mais baixo da escala de teste
Feito pelos desenvolvedores
Testa as classes, métodos, funções, componentes isolando/simulando suas dependências
Teste de Unidade //JUnit Example
Discipline discipline = new Discipline();discipline.setName("Prog 1");discipline.setWorkload(120);
Assert.assertEquals("Prog 1", discipline.getName());
Teste de Unidade //JUnit Example
Calculator calculator = new Calculator();calculator.add(1, 2); Assert.assertEquals(3, calculator.getResult());
Teste de Integração Teste do sistema ao término de cada iteração.
Teste da integração entre os componentes.
Teste de Integração //JUnit Example
Discipline discipline = new Discipline();discipline.setName("Prog 1");discipline.setWorkload(120);
Assert.assertTrue(disciplineApplication.save(discipline));
Teste de Sistema Teste do sistema como um todo depois da integração dos componentes.
Utiliza um ambiente parecido ou igual ao ambiente real
Teste de Aceitação Verificar se o software está pronto para ser usado.
Verificar o comportamento do software
Feito no ambiente de homologação
White box Se concentra do comportamento do software sem se deter a sua estrutura interna.
Verifica se o programa se comporta de acordo com suas especificações.
• Teste Sistêmico• Teste de Aceitação
(MYERS, BADGET e SANDLER, 2012)
Black Box Testa a estrutura interna, a lógica do software.O critério de busca é o Teste do Caminho, testando os possiveis caminhos que o software pode tomar.
• Teste unitário• Teste de Integração
(MYERS, BADGET e SANDLER, 2012)
Papeis do Processo de Teste Papel Responsabilidade
Gerente de Teste Responsável pela área de teste na empresa
Líder do Projeto de Teste Líder do time de testes
Arquiteto de Teste Montagem de Infra-estrutura e ambiente, ferramentas, preparação do time
Profissionais do processo de teste. Fonte: Adaptado de Bastos, et al (2007)
Papeis do Processo de Teste Papel Responsabilidade
Analista de Teste Elaboração dos casos e scripts de teste
Testador Execução dos casos de teste e scripts de teste
Profissionais do processo de teste. Fonte: Adaptado de Bastos, et al (2007)
Ambiente • Toda a estrutura onde os testes serão
executados– Ambiente físico
– Pessoal
– Hardware
– Software
– Suprimentos
– Rede
– Documentação
Ambiente Ao definirmos o ambiente de teste devemos considerar:• OS• Arquitetura do sistema• Identificação dos componentes• Meio de acesso ao sistema• Linguagem de programação• Conectividade entre ambientes
(RIOS e MOREIRA, 2003, apud BASTOS el al., 2007)
Documentação • Plano de Testes– Planejamento para a execução dos testes,
abrangência, abordagem, níveis, ambientes, recursos e técnicas.
• Especificação de Caso de Teste– Define os cenários com entradas, saídas,
resultados esperados e condições para a execução.
Plano de Testes • Descreve quais testes serão executados e
como será feita a execução
– Escopo
– Ambiente
– Abordagem
– Nível
– Técnicas
Plano de Testes – Artefatos liberados
– Responsabilidade
– Cronograma
– Critérios de completude
Requisitos do Projeto à Plano de Testes
Procedimentos de Teste “…os testes devem ser executados em todas as etapas do ciclo de vida do processo de desenvolvimento de software, desde os requisitos até o teste de aceitação, na fase de homologar e liberar o software para a produção.”
(BASTOS el al., 2007)
Procedimentos de Teste • Plano de teste sempre atualizado.• Responsabilidades
Teste UnitáriosFeito pelos desenvolvedores
Teste de IntegraçãoFeito quando os componentes a ser integrados já tiverem seus testes unitários feitos.
Procedimentos de Teste Teste de Sistema– Ambiente deve se aproximar do ambiente de
produção
– Definir quais casos de teste serão empregados nessa fase
– Avaliar os resultados dos testes e identificar problemas encontrados
– Registro de defeitos
– Garantir que usuários finais não encontrem erros grosseiros
Procedimentos de Teste Teste de Aceitação– Realizado pelos usuários do software para
garantir que tudo que foi definido tenha sido de fato implementado.
Procedimentos de Teste Quando parar de testar?
• Métricas– Tempo médio entre defeitos encontrados
– Porcentagem de cobertura alcançada
– Número de defeitos encontrados que não foram corrigidos dependendo do seu grau de severidade
Procedimentos de Teste Construir casos de
teste
Executar os testes
Registrar os resultados dos testes
Identificar a natureza dos problemas e
retrabalhar o teste
Foram encontra
dos defeitos
Os testes foram
executados corretame
nte?
Construir casos de
teste
Ambiente
Plano de Teste
Softwares de Teste
Documentação
Relatórios
Fluxo de execução dos testes. Fonte: Adaptado de Bastos, et al (2007)
Casos de Teste Detalhamento das interações com a aplicação. Estabelece quais as informações empregadas e os resultados.
– Cenários
– Pré-condição
– Pós-condição
– Critério de aceitação
Casos de Teste – Configuração de ambiente– Manual/Automatizada– Dependências
Características– Efetivo– Econômico– Reutilizável– Rastreável– Auto-explicativo
User Story • Representa uma funcionalidade/
caracteristica do produto narrada pelo cliente.
• São as necessidades do cliente, mostrando qual problema ele deseja resolver.
(COHN, 2004)
User Story - Exemplo [US_03] Realizar reserva
Como um usuário do sistema
Eu quero poder realizar a reserva de salas da minha instituição
Para facilitar o controle de reservas e evitar atrasos
!
BDD Behavior-driven development ou Desenvolvimento Orientado ao Comportamento.
Combina ideias do TDD e DDD e Projeto Orientado a Objeto que fornece ao time um processo compartilhado para o desenvolvimento do software
(YE, 2013)
BDD • Linguagem ubiqua– Linguagem natural– Linguagem compartilhada
• Foco no Minimum Markatable Feature• Valor verificável para o negócio• Requisitos aliado aos testes• Baseado naquilo que se espera da
aplicação• Documentação viva
BDD Dado que… (pré-condição)
E… (mais uma pré-condição)
Quando… (ação)
E… (mais uma ação)
Então… (pós-condição)
E… (mais uma pós-condição)
Cenário BDD - Exemplo [US_3] Realizar reserva
Como um usuário do sistema
Eu quero poder realizar a reserva de salas da minha instituição
Para facilitar o controle de reservas e evitar atrasos
!
Cenário BDD - Exemplo [TC_3.1] Realizar uma reserva com sucesso
Dado que eu estou na tela principalE seleciono a opção “Resevas”E preencho o campo “Responsável”E preencho o campo “Sala”E seleciono a dataE seleciono a horaQuando eu clico em “Finalizar”Então devo ver a mensagem “Reserva realizada com sucesso”
Técnicas de Teste • Estrutural– Garantir que o software é sólido. Relacionados
as características do software.
• Funcional– Garantir que o software atende aos requisitos.
Estrutural – Teste de Estresse Avalia o software sob condições críticas.
• Restrição de Memória
• Processamento
• Armazenamento
• Volume de Dados
• Tempo de Transação
Estrutural – Teste de Estresse Objetivos
• Determinar que a aplicacao suporta volume de transação normal ou acima do normal num periodo de tempo esperado
• Determinar que a aplicação suporta volume normal e continua a funcionar corretamente
Comuns em aplicações web
Estrutural – Teste de Execução Avalia o tempo de resposta, de processamento e desempenho.
• Tempo de resposta das transações
Estrutural – Teste de Execução Objetivos
• Determinar o tempo de resposta das transações
• Determinar se hardware e software fornecem capacidade adequada
• Código é executado com eficácia
Estrutural – Teste de Recuperação • Capacidade de reiniciar operacoes após a
perda de integridade.
• Garantir a continuidade das operações após um erro.– Fatores
• Volume de dados processados no momento do erro
Estrutural – Teste de Recuperação Objetivos– Verifica a eficácia e eficiência o processo de
recuperação
– Backup
– Documentar procedimentos de recuperação
Estrutural – Teste de Operação Objetivos– Estabelecer se o sistema é executável durante a
operação normal
– Se os utilizadores do sistema conseguem utilizar-lo, utilizando a documentação preparada.
– Os utilizadores devem testar sem ajuda nenhuma
Estrutural – Teste de Conformidade • Verifica se a aplicação foi desenvolvida de
acordo com os padrões de TI– Aumentar as chances de sucesso
– Transferência de conhecimento e curva de aprendizado
– Manutenibilidade
Estrutural – Teste de Conformidade Objetivos– Padrões de TI estão sendo seguidos e de forma
adequada
– Avalidar documentação
– Falta de conformidade foi falta de comunicação? Problema no processo? Padrões mal entendidos?
Estrutural – Teste de Segurança • Verificar a confidencialidade das
informações e proteção dos dados contra acesso indevido.– Segurança da Informação
– Defeitos difíceis de indentificar
Estrutural – Teste de Segurança Objetivos– Riscos?
• Determinar as regras de acesso e se foram implementadas de acordo com as definições• Verificar se as medidas de segurança foram
corretamente implementadas
– Riscos baixos, tecnicas de invasão usual: • Pode-se realizar os testes
– Riscos altos, técnicas de invasão sofisticadas:• Testes conduzidos por pessoal especializado
Funcional – Teste de Requisitos Objetivos– Verificar se o sistema faz o que está
especificado nos requisitos.
– Verificação do comportamento do sistema
– Checklist de funcionalidades
– Normalmente os testes são preparados na fase de requisitos
Funcional – Teste de Regressão • Voltar a testar componentes já testados
após implementação de uma mudança em outra parte do software
Objetivos
– Determinar se a funções previamente testadas continuam funcionando após a introdução de mudanças no sistema
Funcional – Teste de Regressão Riscos– Tempo e custo
• Automação de Testes
Quando usar?
Quando os riscos de mudança do software são altos
Funcional – Teste de Tratamento de Erros • Verificar a capadicade do sistema de tratar
transações incorretas
Objetivos– Determinar as condições de erro e tratá-los
– Testar o erro e o acerto
Funcional – Teste de Interconexão • Verificar a conectividade do software com
outros softwares– Sejam dados recebidos ou fornecidos
Objetivos– Verificar se os dados são recebidos e/ou
enviados corretamente
– Executar quando as entradas e saídas dos softwares relacionados mudarem
Funcional – Teste Paralelo • Teste de compatibilidade. Demonstrar
consistência e cincosistências entre versões do mesmo software
• Mesmos dados de entrada funcionem em software de diferentes versões
Gestão de defeitos • Prevenção de defeitos• Baselines• Identificação• Registro• Solução do defeitos• Melhoria do processo• Relatório de gestão
(BASTOS et al., 2007)
Teste de Unidade
@Testpublic void sumTwoNumbers() {
Calculator calculator = new Calculator();calculator.add(1, 2);Assert.assertEquals(calculator.getResult(), 3);
}
http://junit.org
Teste Funcional • Selenium: http://www.seleniumhq.org– Java
– C#
– Ruby
– Python
– JS(Node)
• Ruby– Capybara: http://jnicklas.github.io/capybara/
Teste Funcional @Testpublic void doBingSearch() {
WebDriver driver = new FirefoxDriver();
driver.get("http://www.bing.com");
WebElement searchField = driver.findElement(By.id("sb_form_q"));
searchField.sendKeys("Transformers");
driver.findElement(By.id("sb_form_go")).click();
driver.getPageSource().contains("Imagens de transformers");}
Teste Funcional • Calabash: http://calaba.sh – Android
– IOS
• Selendroid: http://selendroid.io – Android
Teste de Desempenho
• Realiza testes de desempenho em aplicações web, webservices e páginas dinâmicas
CBTS Certificação Brasileira de Teste de Software
Criada pela ALATS (Associação Latino Americana de Teste de Software), procura estabelecer um padrão de conformidade para avaliação da qualificação dos profissionais da área da qualidade do software.
CBTS Certificação Brasileira de Teste de Software
Criada pela ALATS (Associação Latino Americana de Teste de Software), procura estabelecer um padrão de conformidade para avaliação da qualificação dos profissionais da área da qualidade do software.
Links • http://behaviourdriven.org
• http://dannorth.net/introducing-bdd/
• http://tableless.com.br/introducao-ao-behavior-driven-development/
• http://junit.org
• http://www.seleniumhq.org
• https://www.atlassian.com/software/jira
• http://www.alats.org.br/portal/home.html
Links • http://aprendendotestar.webs.com
• http://qualidade-de-software.blogspot.com.br
• http://www.bstqb.org.br
• http://guts-rs.blogspot.com.br
• http://www.qualister.com.br
• https://www.youtube.com/user/guru99com
• https://github.com/rondymesquita
• http://rondymesquita.com.br
Bibliografia • BASTOS, Aderson, at al. Base de conhecimento em
teste de software. 2. ed. rev. São Paulo: Martins, 2007.
• MYERS, Glenford J.; BADGET, Tom; SANDLER, Corey. The art of software testing. 3. ed. Wiley, 2012.
• WATKINS, John. Agile testing: how to succeed an extreme testing environment. Cambridge, 2009.
• YE, Wayne. Cucumber BDD how-to: A short guide to mastering behavior-driven software development with cucumber. Packt Publishing, 2013.
Bibliografia • KEITH, Clinton. Agile game development with
scrum. Addison-Wesley, 2010.
• COHN, Mike. User stories applied: for agile software development. Addison-Wesley, 2004.