O presente capítulo possui duas seções, a saber:

Os testes de unidade, comumente chamados de testes unitários, são responsáveis por verificar o funcionamento de elementos de software de maneira isolada. Ou seja, eles são testados individualmente. O teste de unidade focaliza o esforço de verificação na menor unidade do projeto de software — o componente ou módulo de software. Se estivermos escrevendo um código usando uma linguagem como o Java por exemplo, serão testados os métodos das classes, uma vez que eles normalmente são as menores unidades do projeto. O teste de unidade, na maioria das vezes, ocorre com acesso ao código fonte que está sendo testado e com o suporte de ferramentas de depuração. Os programadores que escreveram o código frequentemente, mas nem sempre, realizam testes unitários. O Test Driven Development (TDD) ou Desenvolvimento Guiado por Testes, um exemplo de teste unitário, é apresentado na seção a seguir.

O teste de integração, também conhecido como teste de componente, é o processo de verificar as interações entre os componentes de software. Ele fará com que duas ou mais classes, por exemplo, sejam postas em funcionamento juntas. Devemos pensar que se individualmente elas funcionaram, quando colocadas juntas, elas devem continuar funcionando. Estratégias clássicas de teste de integração, como top-down e bottom-up, são frequentemente usadas com software estruturado hierarquicamente. Estratégias de integração modernas e sistemáticas são tipicamente direcionadas à arquitetura, o que envolve a integração gradual dos componentes ou subsistemas de software, com base em segmentos funcionais identificados.

O teste de integração geralmente é uma atividade contínua em cada estágio do desenvolvimento, durante o qual os engenheiros de software abstraem as perspectivas de nível inferior e concentram-se nas perspectivas do nível em que estão integrando. Para outros, além do software pequeno e simples, as estratégias de teste de integração incremental geralmente são preferidas para reunir todos os componentes de uma só vez - o que geralmente é chamado de teste “big bang”.

O teste do sistema está preocupado em testar o comportamento de um sistema inteiro, definido pelo escopo de um projeto ou programa de desenvolvimento. De acordo com o ISTQB, no teste de sistema, o ambiente de teste deve corresponder o máximo possível ao objetivo final ou ao ambiente de produção. Isto visa minimizar os riscos de falhas específicas de ambiente não serem encontradas durante o teste. Ele pode ser baseado em descrições de alto nível do comportamento do sistema, tais como: (i) especificação de riscos e/ou de requisitos, (ii) processos de negócios ou (iii) casos de uso.

O teste do sistema é geralmente considerado apropriado para avaliar os requisitos não funcionais do sistema como segurança, velocidade, precisão e confiabilidade. Interfaces externas para outros aplicativos, utilitários, dispositivos de hardware ou os ambientes operacionais também são geralmente avaliados nesse nível. Uma equipe de teste independente é frequentemente responsável pelos testes de sistema.

O teste de aceitação / qualificação determina se um sistema satisfaz seus critérios de aceitação, geralmente verificando os comportamentos desejados do sistema em relação aos requisitos do cliente. O cliente ou representante de um cliente, portanto, especifica ou realiza atividades diretamente para verificar se seus requisitos foram atendidos. No caso de um produto de consumo,ele verifica se a organização atendeu aos requisitos estabelecidos para o mercado-alvo.

O objetivo desse teste é estabelecer a confiança no sistema, parte do sistema ou uma característica não específica do sistema. Procurar defeitos não é o principal foco. Ele pode avaliar a disponibilidade do sistema para entrar em produção. Este não é necessariamente o último nível de teste, uma vez que, por exemplo, um teste de integração em larga escala pode ser feito posteriormente.

Esse teste é realizado pelo cliente ou por usuários do sistema; os interessados (stakeholders) também podem ser envolvidos.

Muitas vezes, após a conclusão do sistema e teste de aceitação, o software é verificado no ambiente de destino. Os testes de instalação podem ser vistos como testes de sistema realizados no ambiente operacional, com configurações de hardware e outras restrições operacionais específicas. Os procedimentos de instalação também podem ser verificados.

Antes do lançamento, o software as vezes é fornecido a (i) um grupo pequeno e selecionado de usuários em potencial para uso experimental (teste alfa) e/ou (ii) para um conjunto maior de usuários representativos (teste beta). Esses usuários relatam problemas com o produto. Os testes alfa e beta geralmente não são controlados e nem sempre são mencionados em um plano de teste.

Este tipo de teste melhora a confiabilidade do sistema, identificando e corrigindo falhas. Além disso, medidas estatísticas de confiabilidade podem ser obtidas gerando aleatoriamente casos de teste de acordo com o perfil operacional do software (consulte Perfil Operacional na seção 3.5, Técnicas Baseadas em Uso). Esta última abordagem é chamada de teste operacional. Usando modelos de crescimento de confiabilidade, ambos os objetivos podem ser perseguidos juntos (ver Teste de Vida, Avaliação de Confiabilidade na seção 4.1, Avaliação do Programa em Teste).

Um teste de regressão mostra que o software ainda passa nos testes feitos ​​anteriormente (na verdade, às vezes também é chamado de teste de não-regressão). Para desenvolvimento incremental, o objetivo do teste de regressão é mostrar que o comportamento do software não é alterado por mudanças incrementais no software, exceto na medida em que deveria. Em alguns casos, uma compensação deve ser feita entre (i) a garantia dada pelo teste de regressão, toda vez que uma alteração é feita, e (ii) os recursos necessários para executar os testes de regressão. Esta compensação pode ser bastante demorada devido ao grande número de testes que podem ser executados.

O teste de regressão envolve selecionar, minimizar e/ou priorizar um subconjunto dos casos de teste em um conjunto de testes existente. O teste de regressão pode ser realizado em cada um dos níveis de teste descritos na seção 2.1, O Alvo do Teste, e pode ser aplicado a testes funcionais e não funcionais.

O teste de desempenho verifica se o software atende aos requisitos de desempenho especificados. Ele ainda avalia as características de desempenho - por exemplo, capacidade e tempo de resposta.

O teste de segurança é focado em verificar se o software está protegido contra ataques externos. Em particular, o teste de segurança verifica a confidencialidade, integridade e disponibilidade dos sistemas e seus dados. Geralmente, o teste de segurança inclui a verificação contra uso indevido e abuso do software ou sistema (teste negativo).

Exemplos de testes de segurança são os chamados Testes de Penetração (Penetration Test, PenTest).

O teste de estresse executa o software na carga máxima do projeto, com o objetivo de determinar os limites comportamentais e testar os mecanismos de defesa em sistemas críticos.

O padrão IEEE/ISO/IEC 24765 define o teste back-to-back como “teste em que duas ou mais variantes de um programa são executadas com as mesmas entradas, as saídas são comparadas e os erros são analisados ​​em caso de discrepâncias”.

O teste de recuperação visa verificar os recursos de reinicialização do software após uma falha do sistema ou outro "desastre". Isto visa medir a capacidade de resiliência do software, ou seja, de recuperação após uma falha. Normalmente neste tipo de teste, falhas são intencionalmente injetadas no ambiente em que o sistema está sendo testado, para avaliar o comportamento do software nestes casos.

Os defeitos da interface são comuns em sistemas complexos. O teste de interface visa verificar se os componentes fazem interface corretamente para fornecer a troca correta de dados e informações de controle. Normalmente, os casos de teste são gerados a partir da especificação da interface. Um objetivo específico do teste de interface é simular o uso de APIs por aplicativos de usuário final. Isso envolve a geração de parâmetros das chamadas da API, a configuração de condições externas do ambiente e a definição de dados internos que afetam a API.

Nos casos em que o software é criado para atender a diferentes usuários, o teste de configuração verifica o software em diferentes configurações especificadas.

A principal tarefa dos testes de usabilidade e interação entre o homem e computador é avaliar como é fácil para os usuários finais aprenderem a usar o software. Em geral, pode envolver o teste das funções do software que suportam as tarefas do usuário, a documentação para auxílio aos usuários e a capacidade do sistema de se recuperar de erros humanos (consulte Design da interface do usuário no Software Design KA).

=x=x=x=x=x=x=x