Teste de Aceitação

Também conhecido como teste funcional ou de história de usuário, são testes de correção e validação. Eles são idealmente especificados por clientes ou usuários finais do sistema para verificar se um módulo funciona como foi especificado [96, 87]. Por isso o termo “aceitação”, pois ele verifica se o cliente aceita as funcionalidades que foram implementadas. Os testes de aceitação devem utilizar uma linguagem próxima da natural para evitar problemas de interpretação e de ambiguidades, e também devem ser facilmente conectados ao código do sistema para que os comandos e verificações sejam executados no sistema em teste [104].

Nas diretrizes da Programação eXtrema, uma história do cliente não é finalizada enquanto os testes de aceitação não certificarem que o sistema atende aos requisitos especificados. Sendo assim, os testes de aceitação não só são utilizados para identificar erros de programação e interpretação dos requisitos como também para identificar quando uma história foi finalizada.

1_{CAPTCHA ou Completely Automated Public Turing test to tell Computers and Humans Apart, é um teste de desafio}

cognitivo utilizado como ferramenta anti-spam. Na Internet é comum um componente que fornece um pequeno desafio como uma imagem ou um som que é facilmente decifrado por um humano, mas muito difícil de ser avaliado por um computador, assim é possível evitar que scripts automatizados indesejados utilizem o sistema.

3.3.5 Teste de Desempenho

Testes de desempenho executam trechos do sistema em teste e armazenam os tempos de duração obtidos, como um cronômetro. Os testes de desempenho não avaliam a complexidade computacional dos algo- ritmos, por isso os tempos obtidos estão intimamente relacionados à infraestrutura sobre a qual o teste está sendo executado, podendo variar drasticamente dependendo do hardware, da rede etc. [129, 51].

Os resultados dos testes de desempenho ajudam a identificar os gargalos que precisam de otimização para diminuir o tempo de resposta para o usuário [90]. A otimização pode ser feita através de mudanças em algoritmos e também pela adição de caches em pontos específicos do sistema, caso os algoritmos já sejam suficientemente rápidos.

3.3.6 Teste de Carga

O teste de carga exercita o sistema sob condições de uso intenso para avaliar se a infraestrutura é ade- quada para a expectativa de uso real do sistema [9, 10]. São criadas simulações com muitos usuários e requisições ao software realizadas simultaneamente ou dentro de um intervalo pequeno de tempo para medição de informações de desempenho. Dependendo do sistema e do que o teste quer avaliar, pode ser verificado o tempo de resposta de cada requisição ou informações relativas ao uso de recursos, como uso da CPU, cache, memória, espaço em disco e banda de rede. Também podem ser observados os programas que se relacionam com o sistema, como gerenciadores de banco de dados, máquinas virtuais e servidores de aplicação.

Após o término da simulação, é realizada a tarefa de interpretação subjetiva das informações cole- tadas, que pode ser feita manualmente ou através de scripts que seguem alguma heurística especializada para um contexto. Essas informações são úteis para identificar módulos do sistema que apresentem mau desempenho sob uso intenso, como, por exemplo, queries que são executadas repetidamente e que pode- riam ser inseridas em um sistema de cache. As informações também podem indicar partes do hardware e da infraestrutura que são mais utilizadas pelo software, portanto quais são as mais importantes para a execução satisfatória do sistema.

Outra conclusão que pode ser obtida com os testes de carga é se o sistema e suas dependências são escaláveis. Se a vazão das requisições apresentar um aumento linear com o tempo, significa que o sistema é escalável, portanto, é possível melhorar o desempenho do sistema com o upgrade da infraestru- tura. Se a vazão tiver um crescimento exponencial, ou seja, um crescimento relativamente rápido para poucos usuários e requisições, então é uma indicação que alguma configuração ou algoritmo precisa ser melhorado.

Uma ferramenta popular de testes de carga é a JMeter, que possibilita testar aplicações Web, bancos de dados e outros tipos de aplicações2_{. Com ela ainda é possível criar testes de estresse e longevidade,}

que serão descritos a seguir, além de testes de desempenho. Um exemplo pode ser visto no Apêndice A. Teste de Estresse

Enquanto o teste de carga visa avaliar se a infraestrutura é adequada para as expectativas de uso do sistema, o teste de estresse, também conhecido como teste de carga máxima, visa descobrir os limites de uso da infraestrutura, isto é, qual a quantidade máxima de usuários e requisições que o sistema consegue atender corretamente e em um tempo aceitável. A análise dos resultados pode ser feita através de asserções, mas sempre é necessário uma última análise manual dos dados obtidos pelos testes.

Os valores limites obtidos da simulação de estresse são importantes para o gerenciamento e configu- ração do hardware e do software. Essa simulação aponta quais são os gargalos de hardware que precisam de upgrade e também orienta a configuração do hardware e do software para melhorar o desempenho

ou mesmo para criar barreiras que impeçam que a quantidade máxima de requisições extrapole um lim- ite seguro. Por exemplo, podemos configurar um servidor de aplicações Web para barrar quantidades exageradas de requisições para impedir ataques de negação de serviço3_.

3.3.7 Teste de Longevidade

O teste de longevidade tem por objetivo encontrar erros que só são visíveis após um longo tempo de execução do sistema. Esse teste é importante porque o sistema pode se comportar de maneira errônea ou ineficiente após dias ou semanas de execução ininterrupta, mesmo que ele funcione corretamente sob uso intenso de usuários e requisições em um curto intervalo de tempo. Esses problemas são geralmente de cache, replicação, da execução de serviços agendados e, principalmente, de vazamento de memória.

A execução de serviços agendados e de replicação são muito suscetíveis a erros do ambiente, como configuração incorreta do hardware e do sistema operacional e também problemas de bloqueio e per- missão em sistemas de arquivos. Além disso, é comum que uma infraestrutura de hardware seja com- partilhada entre outros usuários e sistemas de software, os quais possuem comportamento desconhecido que pode afetar o sistema em teste, por isso é importante o teste de longevidade para verificar se existe em algum momento um impacto direto no desempenho e correção da aplicação.

Erros em sistema de cache também são mais facilmente observados com o passar do tempo. Os sistemas de cache podem ser configurados para serem atualizados depois de um longo período de tempo, por exemplo, uma vez ao dia ou depois de uma semana; dessa forma, só conseguiremos verificar se essa tarefa está sendo executada corretamente após este período. No entanto, esses problemas ainda podem ser verificados com o auxílio de testes de unidade e Objetos Dublês (vide Seção 6.2), o que não é trivial para os problemas de vazamento de memória.

Vazamento de memória é um problema comum a muitos sistemas de software, não só os que são implementados com linguagens de programação que exigem a criação de destrutores e que não possuem coleta de lixo automática (como C++), como também em linguagens mais modernas, como Java [30] e JavaScript. Mesmo um vazamento de memória aparentemente insignificante pode trazer problemas com o decorrer do tempo, porque a quantidade de memória gasta pode ser multiplicada pela quantidade de usuários e requisições que pode ser muito grande.

3.3.8 Testes de Segurança

Os testes de segurança servem para verificar se os dados ou funcionalidades confidenciais de um sistema estão protegidos de fraude ou de usuários não autorizados. A segurança de um software pode envolver aspectos de confidencialidade, integridade, autenticação, autorização, privacidade, entre outros, todos sujeitos a ter vulnerabilidades por erros de software ou de infraestrutura [145].

Existem diversas ferramentas especializadas em testes de segurança que simulam os ataques mais comuns de pessoas mal intencionadas. Contudo, as vulnerabilidades também podem ser verificadas com auxílio de ferramentas de testes de interface ou de unidade, que permitem simular o comportamento de usuários e inserir informações maliciosas no sistema. Entre os ataques que é possível simular estão os que se beneficiam da falha de conversão ou da fraca validação dos dados de entrada do sistema, assim como os ataques que injetam código malicioso nos servidores e causam estouro de memória.

3.4 Técnicas de Teste

Na maioria das vezes os testes de software não provam que o sistema está livre de defeitos, justamente porque os testes não conseguem cobrir a enorme quantidade de possibilidades de entrada e combinações 3_{Ataques de negação de serviço (Denial of Service ou simplesmente DoS) são feitos com o envio intenso de requisições}

de resultados a que um software pode estar sujeito. Sendo assim, os testes são realizados até que o time, incluindo desenvolvedores e clientes, esteja satisfeito quanto à qualidade do sistema ou de um algoritmo. Após a realização dos testes, podem ser executadas outras tarefas para certificar que o software atende bem às necessidades, como análises formais e matemáticas ou mesmo a liberação do sistema em versões alfa e beta para testes em ambiente real com usuários reais.

A regra geral durante a criação dos testes automatizados é pensar em partições de domínio ou classes de equivalência de um algoritmo, isto é, tentar identificar tanto os casos rotineiros, como as situações especiais e excepcionais, e, então, criar um caso de teste para cada uma delas. No entanto, em alguns casos isso não basta para dar a confiança de que está tudo implementado corretamente, por isso existem outras técnicas de testes que podem ser utilizadas para complementá-los e reforçar a confiabilidade do sistema, aumentando as chances de encontrar erros durante a implementação do código, como através de testes aleatórios, fumaça e de sanidade.

Essas técnicas, as quais também são definidas como tipos de testes, não precisam possuir baterias exclusivas de casos de testes. Por exemplo, não é necessário organizar uma bateria com apenas casos de testes de sanidade. Se esses testes seguirem as padronizações e os princípios da bateria, tais como desempenho e uso de ferramentas específicas, então eles podem complementar as baterias de testes já existentes, como a de testes de unidade.