Liderança em Testes: Testes de Serviços

Nota do editor: Bem-vindo à série Liderança em Testes, do especialista e consultor em testes de software Paul Gerrard. A série foi concebida para ajudar testadores com alguns anos de experiência — especialmente os que integram equipas ágeis — a destacarem-se nas suas funções de liderança e gestão de testes.

No artigo anterior, analisámos a evolução do papel dos testadores e a forma de promover uma melhor colaboração com os seus colegas. Neste artigo, vamos abordar os pormenores dos testes de desempenho, fiabilidade e capacidade de gestão de uma aplicação Web. Ou seja, testes de serviços.

Subscreva a newsletter da The QA Lead para ser notificado quando forem publicados novos capítulos da série. Estes artigos são excertos do curso Liderança em Testes de Paul, que recomendamos vivamente para aprofundar este e outros temas. Se o fizer, utilize o nosso código de cupão exclusivo QALEADOFFER para obter um desconto de $60 no preço total do curso!

Olá e bem-vindo a mais um capítulo da série Liderança em Testes. Esta semana, vamos analisar os testes de serviços para aplicações Web. Abordaremos:

O que são testes de serviços?
O que são testes de desempenho?
Testes de fiabilidade/tolerância a falhas
Testes de gestão de serviços

Comecemos.

O que são testes de serviços?

A qualidade do serviço fornecido por uma aplicação Web pode ser definida como incluindo todos os seus atributos, tais como funcionalidade, desempenho, fiabilidade, usabilidade, segurança, entre outros.

No entanto, para os nossos objetivos, estamos a separar três objetivos específicos do serviço que são abrangidos pelo que designaremos por «testes de serviços». Estes objetivos são:

Desempenho: o serviço deve responder aos utilizadores, suportando simultaneamente as cargas que lhe são impostas.
Fiabilidade: se tiver sido concebido para ser resiliente a falhas, o serviço deve ser fiável e/ou continuar a fornecer um serviço mesmo quando ocorre uma falha.
Capacidade de gestão: o serviço deve poder ser gerido, configurado ou alterado sem que os utilizadores finais notem uma degradação do serviço. Os testes de capacidade de gestão, ou testes operacionais, têm como objetivo demonstrar que os procedimentos de administração, gestão, cópia de segurança e recuperação do sistema funcionam eficazmente.

Nos três casos, precisamos de simular a carga dos utilizadores para realizar os testes de forma eficaz. Os objetivos de desempenho, fiabilidade e capacidade de gestão existem no contexto de clientes reais que utilizam o site para fazer negócio.

A capacidade de resposta de um site (neste caso, o tempo que um nó do sistema demora a responder ao pedido de outro) está diretamente relacionada com os recursos disponíveis na arquitetura técnica.

À medida que mais clientes utilizam o serviço, ficam disponíveis menos recursos técnicos para responder aos pedidos de cada utilizador e os tempos de resposta degradam-se.

Obviamente, um serviço sujeito a uma carga reduzida tem menos probabilidades de falhar. Grande parte da complexidade do software e do hardware existe para acomodar as exigências de recursos da arquitetura técnica quando um site está sujeito a uma carga elevada.

Quando um site está sujeito a carga (ou sobrecarga), os pedidos concorrentes de recursos têm de ser geridos por vários componentes da infraestrutura, tais como sistemas operativos de servidores e redes, sistemas de gestão de bases de dados, produtos de servidores Web, intermediários de pedidos de objetos, middleware, entre outros.

Estes componentes da infraestrutura são normalmente mais fiáveis do que o código da aplicação desenvolvido à medida que exige o recurso, mas podem ocorrer falhas em qualquer um dos seguintes casos:

Os componentes da infraestrutura falham porque o código da aplicação (devido a uma conceção ou implementação deficientes) impõe exigências excessivas aos recursos.
Os componentes da aplicação podem falhar porque os recursos de que necessitam podem nem sempre estar disponíveis (a tempo).

Ao simular cargas de produção típicas e invulgares durante um período prolongado, os testadores podem revelar falhas na conceção ou implementação do sistema. Quando estas falhas são resolvidas, os mesmos testes demonstrarão que o sistema é resiliente. As equipas de QA podem tirar partido de ferramentas de testes de carga para executar muitos dos processos definidos abaixo.

Em todos os serviços, existem normalmente vários processos de gestão críticos que têm de ser executados para manter o serviço a funcionar sem problemas. Poderá ser possível encerrar um serviço para realizar a manutenção de rotina fora do horário normal de funcionamento, mas a maioria dos serviços online funciona 24 horas por dia.

O dia de trabalho do serviço nunca termina. Inevitavelmente, os procedimentos de gestão têm de ser realizados enquanto o serviço está ativo e os utilizadores estão no sistema. Estes procedimentos têm de ser testados enquanto existe carga no sistema, para garantir que não afetam negativamente o serviço ativo, ou seja, através de testes de desempenho.

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Have an account? Log In

O que são os testes de desempenho?

Os testes de desempenho são um componente essencial dos testes de serviços. Constituem uma forma de testar o desempenho de um sistema em termos de capacidade de resposta e estabilidade sob uma determinada carga de trabalho. Eis uma visão geral do seu funcionamento:

Os testes de desempenho consistem num conjunto de testes com cargas variáveis, nos quais o sistema atinge um estado estacionário (cargas e tempos de resposta a níveis constantes).
Medimos a carga e os tempos de resposta para cada carga, simulada durante um período de 15-30 minutos, para obter um número estatisticamente significativo de medições.
Monitorizamos e registamos os indicadores essenciais de cada carga simulada. Estes correspondem aos vários recursos do nosso sistema, por exemplo, utilização do CPU e da memória, largura de banda da rede, taxas de E/S, entre outros.

Representamos num gráfico estas cargas variáveis em função dos tempos de resposta sentidos pelos nossos utilizadores “virtuais”. Quando representado, o nosso gráfico tem um aspeto semelhante ao da figura abaixo.

Com carga nula, quando existe apenas um utilizador no sistema, este dispõe de todos os recursos e os tempos de resposta são rápidos. À medida que introduzimos cargas maiores e medimos os tempos de resposta, estes pioram progressivamente até atingirmos um ponto em que o sistema está a funcionar à sua capacidade máxima.

Neste ponto, o tempo de resposta das nossas transações de teste é teoricamente infinito, porque um dos recursos essenciais do sistema está completamente ocupado e não podem ser processadas mais transações.

À medida que aumentamos as cargas desde zero até ao máximo, monitorizamos também a utilização dos vários tipos de recursos, por exemplo, a utilização do processador do servidor, a utilização da memória, a largura de banda da rede, os bloqueios da base de dados, entre outros.

Com a carga máxima, um destes recursos atinge 100% de utilização. Este recurso é o recurso limitador, porque é o primeiro a esgotar-se. Naturalmente, neste ponto, os tempos de resposta degradaram-se ao ponto de serem provavelmente muito mais lentos do que seria aceitável.

O gráfico abaixo mostra a utilização/disponibilidade de vários recursos representada em função da carga.

Para aumentar a capacidade de débito e/ou reduzir os tempos de resposta de um sistema, temos de fazer uma das seguintes coisas:

Reduzir a procura do recurso, normalmente tornando mais eficiente o software que utiliza o recurso (esta é, geralmente, uma responsabilidade da equipa de desenvolvimento).
Otimizar a utilização do recurso de hardware na arquitetura técnica, por exemplo, configurando o DBMS para colocar mais dados em cache na memória ou dando prioridade a alguns processos em detrimento de outros no servidor da aplicação.
Disponibilizar uma maior quantidade do recurso. Normalmente, adicionando processadores, memória ou largura de banda da rede, entre outros.

Como certamente já começa a perceber, os testes de desempenho precisam de uma equipa de pessoas para ajudar os testadores. Trata-se dos arquitetos técnicos, administradores de servidores, administradores de redes, programadores e responsáveis pelo desenho/ administração de bases de dados. Estes especialistas técnicos estão qualificados para analisar as estatísticas geradas pelas ferramentas de monitorização de recursos e avaliar qual é a melhor forma de ajustar a aplicação, ou de otimizar ou atualizar o sistema.

Se é o testador, a menos que seja um especialista nestas áreas, não se sinta tentado a fingir que consegue interpretar estas estatísticas e tomar decisões de otimização. Terá de envolver estes especialistas numa fase inicial do projeto para obter os seus conselhos e apoio e, mais tarde, durante os testes, para garantir que os estrangulamentos são identificados e resolvidos.

Esteja atento ao próximo artigo, no qual iremos aprofundar a forma de gerir os testes de desempenho.

Testes de fiabilidade/comutação de redundância

Garantir a disponibilidade contínua de um serviço é provavelmente um dos principais objetivos do seu projeto. Os testes de fiabilidade ajudam a revelar falhas obscuras que causam falhas inesperadas. Os testes de comutação de redundância ajudam a garantir que as medidas de comutação de redundância concebidas para falhas previstas funcionam efetivamente.

Testes de comutação de redundância

Quando é necessário que os sites sejam resilientes e/ou fiáveis, tendem a ser concebidos com componentes de sistema fiáveis, com redundância integrada e funcionalidades de comutação de redundância que entram em ação quando ocorrem falhas.

Estas funcionalidades podem incluir encaminhamento de rede diversificado, vários servidores configurados como clusters, tecnologia de middleware e de serviços distribuídos que gere o balanceamento de carga e o redirecionamento do tráfego em cenários de falha.

Os testes de comutação de redundância têm como objetivo explorar o comportamento do sistema em cenários de falha selecionados antes da implementação e envolvem normalmente o seguinte:

Identificação dos componentes que podem falhar e causar uma perda de serviço (analisando as falhas de dentro para fora).
Identificação dos perigos que podem causar uma falha e provocar uma perda de serviço (analisando as ameaças de fora para dentro).
Uma análise dos modos ou cenários de falha que podem ocorrer, quando é necessário ter confiança de que a medida de recuperação irá funcionar.
Um teste automatizado que pode ser utilizado para carregar o sistema e explorar o comportamento do sistema durante um período prolongado.
O mesmo teste automatizado também pode ser utilizado para carregar o sistema em teste e monitorizar o comportamento do sistema em condições de falha.

Uma técnica denominada Análise de Árvore de Falhas (FTA) pode ajudá-lo a compreender as dependências do serviço relativamente aos seus componentes subjacentes. A análise de árvore de falhas e os diagramas de árvore de falhas são uma representação lógica de um sistema ou serviço e das formas como este pode falhar.

O esquema simples abaixo mostra a relação entre eventos básicos de falha de componentes, eventos intermédios de falha de subsistemas e o evento de falha do serviço no nível superior. Naturalmente, poderá ser possível identificar mais de três níveis de eventos de falha.

Estes testes têm de ser executados com uma carga automatizada para explorar o comportamento do sistema em situações de produção e obter confiança nas medidas de recuperação incorporadas no projeto. Em particular, pretende-se saber:

Como se comporta a arquitetura em situações de falha?
As instalações de balanceamento de carga funcionam corretamente?
As capacidades de comutação por falha absorvem a carga quando um componente falha?
A recuperação automática funciona? Os sistemas reiniciados conseguem “recuperar o atraso”?

Em última análise, os testes centram-se em determinar se o serviço é mantido para os utilizadores finais e se estes percebem efetivamente a ocorrência da falha.

Testes de fiabilidade (ou de imersão)

Os testes de fiabilidade têm como objetivo verificar se não ocorrem falhas sob carga.

A maioria dos componentes de hardware é fiável ao ponto de o seu tempo médio entre falhas poder ser medido em anos. Os testes de fiabilidade exigem a utilização (ou reutilização) de testes automatizados de duas formas para simular:

Cargas extremas em componentes ou recursos específicos da arquitetura técnica.
Períodos prolongados de cargas normais (ou extremas) em todo o sistema.

Ao concentrarmo-nos em componentes específicos, procuramos sujeitá-los a esforço, submetendo-os a um número excessivamente elevado de pedidos para executarem a função para a qual foram concebidos. É frequentemente mais simples testar componentes críticos isoladamente, com grandes quantidades de pedidos simples, antes de aplicar um teste muito mais complexo a toda a infraestrutura. Existem também ferramentas de teste de esforço concebidas especificamente para facilitar a execução do processo pelas equipas de garantia da qualidade.

Os testes de imersão são testes que submetem um sistema a uma carga durante um período prolongado, talvez 24, 48 horas ou mais, para detetar problemas (normalmente) obscuros. As falhas obscuras manifestam-se frequentemente apenas após um período prolongado de utilização.

O teste automatizado não tem necessariamente de ser aumentado até cargas extremas (os testes de esforço abrangem essa situação). No entanto, estamos particularmente interessados na capacidade do sistema para suportar a execução contínua de uma grande variedade de transações de teste, de modo a descobrir se existem fugas de memória obscuras, bloqueios ou condições de corrida.

Testes de gestão de serviços

Por último, uma palavra sobre os testes de gestão de serviços.

Quando o serviço é implementado em produção, tem de ser gerido. Manter um serviço operacional e em funcionamento exige que este seja monitorizado, atualizado, salvaguardado e rapidamente corrigido quando algo corre mal.

Os procedimentos utilizados pelos gestores de serviços para executar atualizações, cópias de segurança, lançamentos e restauros após falhas são fundamentais para fornecer um serviço fiável, pelo que necessitam de ser testados, especialmente se o serviço for sujeito a alterações rápidas após a implementação.

Os problemas específicos a resolver são:

Os procedimentos não produzem o efeito pretendido.
Os procedimentos são impraticáveis ou inutilizáveis.
Os procedimentos perturbam o serviço em funcionamento.

Os testes devem, tanto quanto possível, ser executados de uma forma tão realista quanto possível.

Algumas reflexões

Alguns sistemas são propensos a cargas extremas quando ocorre um determinado evento. Por exemplo, uma empresa em linha esperaria cargas máximas logo após anunciar ofertas na televisão, ou um sítio Web nacional de notícias poderia ficar sobrecarregado quando surge uma notícia de grande impacto.

Considere um sistema que conheça bem e que tenha sido afetado por incidentes não planeados na sua empresa ou nas notícias nacionais.

Que incidentes ou eventos poderiam desencadear cargas excessivas no seu sistema?

Consegue (ou poderia) capturar dados dos registos do sistema que indiquem o número de transações executadas? Consegue dimensionar este evento para prever um evento crítico que ocorra uma vez em 100 anos ou uma vez em 1000 anos?

Que medidas poderia aplicar (ou já aplicou) para reduzir a probabilidade de picos, a dimensão dos picos ou eliminá-los completamente?

Subscreva o boletim informativo do The QA Lead para receber uma notificação quando forem publicados novos conteúdos da série. Estas publicações são excertos do curso de Liderança em Testes do Paul, que recomendamos vivamente para aprofundar este e outros temas. Se o fizer, utilize o nosso código de cupão exclusivo QALEADOFFER para obter um desconto de $60 no preço total do curso!