Para Bastos et al. (2007) o objetivo principal dos testes estruturais é garantir que o produto seja estruturalmente sólido e que funcione corretamente.
As técnicas para esse tipo de teste são desenhadas, não para garantir que o sis- tema seja funcionalmente correto, e sim para que ele seja estruturalmente robusto. Sendo assim, os testes estruturais ou caixa-branca estabelecem os objetivos do teste com base em uma determinada implementação, analisando os detalhes do código fonte e elaborando casos de teste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as variações originadas por estruturas de condições/repetições são testadas. Conforme Bastos et al. (2007), as técnicas podem ser divididas de acordo com o tipo de teste:
■ Testes de carga: verifica o volume de dados que um sistema consegue pro- cessar. Ele permite monitorar o comportamento do sistema diante de uma situação onde há um grande número de acessos simultâneos.
■ Testes de conformidade: são realizados para garantir a conformidade com as metodologias e encorajar e auxiliar os profissionais de TI adotá- -las. Avalia-se a documentação do sistema de aplicação é racional e está
Técnicas de Teste de Software Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
completa, garante a conformidade aos padrões, procedimentos e guias de TI e verifica se as metodologias de desenvolvimento e de manuten- ção são seguidas.
■ Testes de desempenho (performance): verifica o desempenho do sistema em um cenário previsto de baixa ou média carga. Por meio dele é possí- vel mensurar o tempo de resposta ao acionar os comandos disponíveis e obter informações a respeito dos recursos físicos necessários num cená- rio comum de funcionamento.
■ Testes de estresse: seu objetivo é avaliar o comportamento do software sobre condições críticas, tais como restrições significativas de memória, de área de disco e de CPU. Transações, tabelas internas, espaço em disco, saídas, capacidade do computador e interação com pessoas são aspectos que devem passar pelo teste de estresse.
■ Testes de execução: são desenhados para avaliar o comportamento do sistema no ambiente de produção e verificar se são atendidas as premissas de desempenho estabelecidas. Os testes de execução verificam os tempos de resposta, os tempos de processamento e desempenho.
■ Testes de operação: são desenhados principalmente para estabelecer se o sistema é executável durante a operação normal. Ele determina se a docu- mentação da operação está completa, garante os mecanismos de suporte, avalia o treinamento dos operadores e testa se os operadores estão usando a documentação preparada, e se conseguem efetivamente operar o sistema. ■ Testes de recuperação (contingência): recuperação é a capacidade de rei-
niciar operações após a perda da integridade de uma aplicação. O teste de recuperação é responsável por garantir a continuidade das operações após um desastre, o teste de recuperação não só verifica o processo de recu- peração como também a eficácia das partes componentes do processo. ■ Testes de segurança: são desenhados com o intuito de avaliar a ade-
quação dos procedimentos de proteção e as contramedidas projetadas. Os defeitos de segurança não aparecem de maneira tão óbvia como os demais, assim os testes de segurança visam descobrir defeitos muito difí- ceis de identificar.
Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
TESTE FUNCIONAL
Para Bastos et al. (2007), “os testes funcionais são desenhados para garantir que os requisitos e as especificações do sistema tenham sido atendidos”. Os testes funcionais ou caixa-preta utilizam as especificações (de requisitos, análise e pro- jeto) para definir os objetivos do teste e, portanto, para guiar o projeto de casos de teste. No teste funcional, o componente de software a ser testado é abor- dado como se fosse uma caixa-preta sem considerar o comportamento interno do mesmo. Entre os tipos de técnicas na execução dos testes funcionais temos:
■ Teste de controle: ele garante que os dados estejam completos e corretos, as transações sejam autorizadas, a manutenção das informações da trilha de auditoria seja realizada, os processamentos sejam eficientes, eficazes e econômicos e que atendam às necessidades dos usuários.
■ Teste de interconexão: são desenhados para garantir que a intercone- xão entre os softwares de aplicação funcione corretamente. Determina se os parâmetros e dados são transferidos corretamente entre os softwa- res, garante o momento certo de execução e a existência de coordenação das funções entre os softwares e se a documentação pertinente é correta e completa.
■ Testes paralelos: serve para determinar se os resultados de um novo software de aplicação são consistentes com o processamento do antigo sistema ou da antiga versão do sistema. Ele ajuda a assegurar que a nova versão do software execute corretamente e que demonstre consistências e inconsistências entre as duas versões.
■ Testes de requisitos: verificam se o sistema executa corretamente as fun- cionalidades e se ele é capaz de sustentar essa correção após sua utilização por um período de tempo contínuo.
■ Testes de regressão: eles voltam a testar segmentos de códigos já testa- dos após a implementação de uma mudança em outra parte do software. Sempre que ocorrem mudanças em um segmento de código, problemas podem surgir em outros segmentos já testados.
Técnicas de Teste de Software Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
■ Testes de suporte manual: verificam se os procedimentos de suporte manual estão documentados e completos, determinam se as responsabi- lidades pelo suporte manual foram estabelecidas, se o pessoal que dará suporte manual está adequadamente treinado e se ele está interligado apropriadamente com o segmento automatizado.
■ Testes de tratamento de erros: eles determinam a capacidade do sistema de tratar apropriadamente transações incorretas, se todas as condições de erro esperadas são reconhecidas pelo sistema, se foi atribuída responsa- bilidade para processar os erros identificados e se é mantido um controle razoável sobre os erros durante o processo de correção.
Na tabela 1 podemos ver uma lista com alguns outros tipos de testes que podem ser utilizados:
Tabela 1: Alguns Tipos de Teste
TIPO DE TESTE DESCRIÇÃO
Teste de Unidade Teste em um nível de componente ou classe. É o teste cujo objetivo é um “pedaço do código”. Teste de Integração Garante que um ou mais componentes combinados (ou unida-des) funcionam. Podemos dizer que um teste de integração é
composto por diversos testes de unidade.
Teste Positivo-negativo Garante que a aplicação vai funcionar no “caminho feliz” de sua execução e vai funcionar no seu fluxo de exceção. Teste de caixa-preta Testar todas as entradas e saídas desejadas. Não se está preo-cupado com o código, cada saída indesejada é vista como um
erro.
Teste caixa-branca O objetivo é testar o código. Às vezes, existem partes do código que nunca foram testadas. Teste de Interface Verifica se a navegabilidade e os objetivos da tela funcionam como especificados e se atendem da melhor forma ao usuário. Teste de aceitação do
usuário
Testa se a solução será bem vista pelo usuário. Ex: caso exista um botão pequeno demais para executar uma função, isso deve ser criticado em fase de testes (aqui, cabem quesitos fora da interface também).
Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
Testes de Configuração Testar se a aplicação funciona corretamente em diferentes am-bientes de hardware ou de software. Testes de Instalação Testar se a instalação da aplicação foi OK.
Teste de sistemas Testar a execução do sistema como um todo para validar a exatidão e perfeição na execução de suas funções
Teste de Usabilidade
Testar e simular as condições de utilização do software sobre a perspectiva do usuário final. Esses testes focalizam a facilidade de navegação entre as telas, clareza dos textos e as mensagens que são apresentadas aos usuários, dentre outros aspectos da interface do sistema.
Testes de Progressão Testa apenas as funcionalidades (ou requisitos não funcionais) especificados para a versão. Teste de Fumaça Teste que consiste em um teste rápido, executando as prin-cipais funcionalidades do sistema, sem se preocupar com as
condições de erro. O mesmo que teste do Caminho Feliz. Fonte: Bastos et al. (2007)
Outras técnicas de teste podem e devem ser utilizadas de acordo com a necessi- dades da empresa. Conforme Pressman (2011), algumas técnicas se destacam, por exemplo: teste de desempenho, teste de usabilidade, teste de carga, teste de stress, teste de confiabilidade e teste de recuperação. Em alguns livros, alguns autores mostram a definição de uma técnica de teste chamada de “caixa cinza”, que mescla as técnicas de caixa preta e caixa branca.
Preparados para o próximo tópico? Vamos conhecer os papéis e cargos para quem participa nos projetos de teste de software. Boa leitura!
“Nos testes os riscos servirão de elemento de definição dos níveis de priori- dade do projeto.”
©shutterstock
Papéis e Cargos de Teste de Software
Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.