Trabalho realizado pelo aluno Rafael Sanches sobre teste de software explicando os passos necessários para realização de testes no desenvolvimento de software.

1. Teste de Software
Rafael Sanches
2013

2. 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. 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. 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. 5
O que é teste de Software ?
• Os atributos qualitativos previstos na norma ISO 9126 são:
1. Funcionalidade
2. Confiabilidade
3. Usabilidade
4. Eficiência
5. Manutenibilidade
6. Portabilidade
• O bom funcionamento do software envolve compará-lo com :
1. Especificações(verificação do software)
2. Softwares de mesma linha
3. Versões anteriores do produto
4. Inferências pessoais
5. Expectativas do cliente(validação do software)
6. Normas relevantes
7. Leis aplicáveis

6. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 20
Papéis
1. 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. 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. 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. 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. 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 (em inglês). NIST. Página visitada em 17 de novembro de 2008.
MYERS, 2004, p. 9
MYERS, 2004, p. 10
Jiantao 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. 136
MYERS, 2004, p. 91
PRESSMAN, R. S., McGraw Hill, Engenharia de Software, 2002

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