Teste de Software

Rafael Sanches

2013

2

Introdução

O que é Teste de Software(Visão Geral)? Princípios Técnicas Fases Ciclo de Vida Papéis Artefatos Conclusão Bibliografia

3

O que é teste de Software ?

• Investigação do Software.

• Feed Back da sua qualidade do seu produto.

• É um processo da Engenharia de Software.

• Está envolvido desde o levantamento de requisitos até o teste propriamente dito feito.

• inclui o processo de utilizar o produto para encontrar seus defeitos.

• TDD(desenvolvimento dirigido por teste) Metodologia Ágil.

• Refatoração.

4

O que é teste de Software ?

• É visto como uma parcela do processo de qualidade de software.

• Você já Imaginou se o avião não fosse testado antes de voar ?

• O problema de não testar antes

• Ser pró ativo (agir antes de acontecer a falha)

• Teste quantas vezes forem necessárias.

5

O que é teste de Software ?

• Os atributos qualitativos previstos na norma ISO 9126 são:1. Funcionalidade2. Confiabilidade3. Usabilidade4. Eficiência5. Manutenibilidade6. Portabilidade

• O bom funcionamento do software envolve compará-lo com :

1. Especificações(verificação do software)2. Softwares de mesma linha3. Versões anteriores do produto4. Inferências pessoais5. Expectativas do cliente(validação do software)6. Normas relevantes7. Leis aplicáveis

6

O que é teste de Software ?

• Para melhoria do processo de teste de software para ter qualidade é preciso:

• Seguir uma metodologia de trabalho.

• Curto prazo para entrega do produto atrapalha o produto.

• Independente da sua metodologia para se entregar um produto final com :• Um certo nível de Qualidade !!!

• É imprescindível a melhoria dos processos de engenharia de software.

• Para melhorar esses processos utilize de modelos tais como:

• exemplo os ISO/IEC 15504 • E o mais conhecido CMMI.

7

Princípios

• O caso de teste deve definir a saída esperada, de forma a reduzir a interpretação do critério de sucesso.

• A saída da execução do teste deve ser exaustivamente analisada.

• Os casos de teste devem verificar não somente as:

• Condições inválidas de execução, como também as condições válidas

• Utilizar pessoas diferentes para a implementação e para a verificação

• O Tester possui uma visão destrutiva do sistema, em busca de erros

•  O Desenvolvedor possui uma visão construtiva, em busca da implementação de uma especificação.

8

Técnicas

• Caixa Branca:1. Também chamada de teste estrutural ou orientado à lógica.

2. Avalia o comportamento interno do componente de software.

3. Essa técnica trabalha diretamente sobre o código fonte.

4. Avaliar aspectos tais como (teste de condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos, códigos nunca executados.

5. Este tipo de teste é desenvolvido analisando o código fonte.

6. Elaborando casos de teste que cubram todas as possibilidades do componente de software.

7. Dessa maneira, todas as variações relevantes originadas por estruturas de condições são testadas.

9

Técnicas

• Caixa Preta:1. Também chamada de teste funcional.

2. Orientado a dado ou orientado a entrada e saída.

3. Avalia o comportamento externo do componente de software.

4. Sem se considerar o comportamento interno do mesmo.

5. Fornece dados, executa o teste e então se compara o resultado.

6. os casos de teste são todos derivados da especificação.

7. Quanto mais entradas são fornecidas, mais rico será o teste.

10

Técnicas

• Caixa-cinza:

1.  É um mesclado do uso das técnicas de caixa-preta e de caixa-branca.

2.  Inclui também o uso de engenharia reversa .

3. Para determinar por exemplo os limites superiores e inferiores das classes.

4. Além de mensagens de erro.

11

Técnicas

• Regressão

1. Essa é uma técnica de teste aplicável a uma nova versão de software.

2. Necessidade de se executar um novo ciclo de teste durante o processo de desenvolvimento.

3. Nesse contexto a observação de fases e técnicas de teste.

4. Executar os testes anteriores para fazer comparações de resultados.

12

Técnicas

• Técnicas não funcionais

1. Existem para testar aspectos não-funcionais do software.

2. Exemplo: a adequação a restrições de negócio, adequação a normas, ou restrições tecnológicas.

3. Técnicas não funcionais verificam atributos de um componente ou sistema que não se relacionam com a funcionalidade (por exemplo, confiabilidade, eficiência, usabilidade, manutenibilidade e portabilidade).

4. Exemplo: Teste de desempenho e carga : verifica se o software consegue processar grandes quantidades de dados/Tempo de Execuções.

13

Tipos de Teste(Fases)

• Teste de Unidade

1. Também conhecida como teste unitário ou teste de módulo.

2. E a fase em que se testam as menores unidades de software desenvolvidas.

3. O universo alvo desse tipo de teste são as subrotinas ou mesmo pequenos trechos de código.

4. o objetivo é o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo.

14

Tipos de Teste(Fases)

• Teste de integração

1. o objetivo é encontrar falhas provenientes da integração interna dos componentes de um sistema.

2. Geralmente os tipos de falhas encontradas são de transmissão de dados.

3. Por exemplo, um componente A pode estar aguardando o retorno de um valor X ao executar um método do componente B; porém, B pode retornar um valor Y, gerando uma falha.

15

Tipos de Teste(Fases)

• Teste de sistema

1. O objetivo é executar o sistema sob ponto de vista de seu usuário final.

2. Varrer as funcionalidades em busca de falhas em relação aos objetivos originais.

3. Os testes são executados em condições similares – de ambiente, interfaces sistêmicas e massas de dados.

4. Àquelas que um usuário utilizará no seu dia-a-dia de manipulação do sistema

16

Tipos de Teste(Fases)

• Teste de aceitação

1. Realizados por um grupo restrito de usuários finais do sistema.

2. Simulam operações de rotina do sistema.

3. Verificam se seu comportamento está de acordo com o solicitado.

4. Validação de um software pelo comprador, pelo usuário ou por terceira parte.

5. uso de dados ou cenários especificados ou reais.

6. Pode incluir testes funcionais, de configuração, de recuperação de falhas, de segurança e de desempenho.

17

Tipos de Teste(Fases)

• Teste de operação

1. é conduzido pelos administradores do ambiente final em que o sistema ou software entrará em ambiente produtivo.

2. Nessa fase de teste devem ser feitas simulações para garantir que a entrada em produção do sistema será bem sucedida.

3. Envolve testes de instalação, simulações com cópia de segurança dos bancos de dados, etc..

4. necessário garantir que o novo sistema continuará garantindo o suporte ao negócio.

18

Tipos de Teste(Fases)• Testes alfa e beta

1. O período entre o término do desenvolvimento e a entrega é conhecido como fase alfa.

2. O teste alfa é conduzido pelo cliente no ambiente do desenvolvedor, com este "olhando sobre o ombro" do usuário e registrando erros e problemas de uso.

3. Completada a fase alfa de testes, são lançadas a grupos restritos de usuários, versões de teste do sistema denominadas versões beta.

4. Diferente do teste alfa, o desenvolvedor geralmente não está presente.

5. O cliente registra todos os problemas (reais ou imaginários) que são encontrados durante o teste beta e os relata ao desenvolvedor em intervalos regulares.

19

O Ciclo de Vida dos Testes• O Ciclo de Vida dos Testes é composto de 5 fases: Planejamento,

Preparação, Especificação, Execução e Entrega.

1. Planejamento: Nesta fase é elaborada a Estratégia de Teste e o Plano de Teste.

2. Preparação: O objetivo desta fase é preparar o Ambiente de Teste (equipamentos, pessoal, ferramentas de automação, massa de testes) para que os testes sejam executados conforme planejados.

3. Especificação: Nesta fase temos as seguintes atividades: Elaborar/ Revisar casos de testes e Elaborar/ Revisar roteiros de testes.

4. Execução: Os testes são executados e registrado os resultados obtidos.

5. Entrega: Esta é a última fase do ciclo de vida de testes, onde o projeto é finalizado e toda documentação é finalizada e arquivada.

20

Papéis1. O líder (ou gerente) do projeto de testes:É a pessoa responsável pela liderança de um projeto de teste específico, normalmente relacionado a um sistema de desenvolvimento, seja um projeto novo ou uma manutenção

2. Engenheiro (ou arquiteto) de testes:É o técnico responsável pelo levantamento de necessidades relacionadas à montagem da infraestrutura de teste, incluindo-se o ambiente de teste, a arquitetura de solução, as restrições tecnológicas, as ferramentas de teste. É também responsável pela liderança técnica do trabalho de teste e pela comunicação entre a equipe de teste e a equipe de projeto (ou equipe de desenvolvimento).

3. O analista de teste:É o técnico responsável pela operacionalização do processo de teste.Segue os comandos do arquiteto.

21

Papéis

4. Analista de Ambiente:Técnico responsável pela configuração do ambiente de teste e pela aplicação das ferramentas necessárias para tal. Esse profissional deve ser especializado em arquiteturas de solução e nos sistemas operacionais e softwares de infraestrutura que regem o ambiente.

5. O Testador:É o técnico responsável pela execução de teste. Ele deve observar as condições de teste e respectivos passos de teste documentados pelo analista de teste e evidenciar os resultados de execução.

6. Automatizador de Teste:Responsável pela automação de situações de teste em ferramentas.Ele deve observar as condições de teste e respectivos passos de teste documentados pelo analista de teste e automatizar a execução desses testes na ferramenta utilizada.

22

Artefatos

O processo de teste de software pode produzir diversos artefatos !!!

O caso de teste geralmente consiste de uma referência a um identificador ou :

• requisito de uma especificação,• pré-condições,• eventos,• uma série de passos a se seguir,• uma entrada de dados,• uma saída de dados,• resultado esperado e resultado obtido.

A série de passos (ou parte dela) pode estar contida num procedimento separado, para que possa ser compartilhada por mais de um caso de teste.

23

Conclusão

Para se ter um produto de qualidade você deve :

1.Ter uma equipe que saiba se comunicar.

2.Manter o cliente próximo do projeto para se ter um melhor entendimento.

3.Utilizar dos recursos de engenharia de software.

4.Utilizar um padrão para que você não fique perdido.

5.Utilizar dos modelos de qualidade(ex:CMMI) existentes para se ter uma base de o que se fazer para se ter mais qualidade.

6.Por ultimo é muito importante sempre testar o que é feito para se ter um produto final com qualidade.

24

Referências

 MYERS, 2004, p. 8 MYERS, 2004, p. 5 Michael Newman (28 de junho de 2002). Software Errors Cost U.S. Economy $59.5 Billion Annually: NIST Assesses Technical Needs of Industry to Improve Software-Testing (em inglês). NIST. Página visitada em 17 de novembro de 2008.MYERS, 2004, p. 9MYERS, 2004, p. 10Jiantao Pan (1999). Software Testing (em inglês). Universidade Carnegie Mellon. Página visitada em 1 de dezembro de 2008.James Bach (Junho de 1999). Risk and Requirements-Based Testing (em inglês). IEEE. Página visitada em 17 de novembro de 2008.MYERS, 2004, p. 136MYERS, 2004, p. 91PRESSMAN, R. S., McGraw Hill, Engenharia de Software, 2002

25

Bibliografias

KOSCIANSKI, A., Soares, Novatec, M. S. Qualidade de Software, 2006PRESSMAN, R. S., McGraw Hill, Engenharia de Software, 2002MYERS, Glenford J., John Wiley & Sons, The Art of Software Testing, 2, Nova Jérsei: 2004. ISBN ISBN 0-471-46912-2