Melhore a qualidade do software & poupe tempo com testes de infraestrutura

Infraestrutura é o termo que utilizamos para descrever todo o hardware, os serviços na nuvem, as redes, o software de suporte e a nossa aplicação em teste necessários para desenvolver, testar, implementar e operar os nossos sistemas.

Embora faça sentido não limitar a nossa definição à tecnologia. Centros de dados, espaços de escritório, secretárias, computadores de secretária, computadores portáteis, tablets e telemóveis com as suas próprias pilhas de software instaladas fazem todos parte do ecossistema necessário para desenvolver, testar e implementar sistemas.

Se incluirmos ferramentas de desenvolvimento, ferramentas e procedimentos DevOps, ferramentas de teste e os processos empresariais e conhecimentos especializados necessários, há ainda mais elementos a considerar.

As coisas mais banais — os códigos de acesso ou cartões inteligentes utilizados para entrar nos edifícios — podem tornar-se críticas se não estiverem disponíveis.

A infraestrutura, em toda a sua variedade, existe para apoiar o desenvolvimento, os testes, a implementação e as operações dos seus sistemas. É crítica para os testes ou precisa de ser testada.

No próximo artigo, analisaremos ferramentas de desenvolvimento, teste e colaboração. Neste artigo, vamos considerar aquilo que a maioria das pessoas entende por ambientes de teste e analisar brevemente o que é frequentemente designado por testes de infraestrutura. Irei abordar:

• Ambientes de teste
• Ambientes de desenvolvimento
• Ambientes de teste ao nível do sistema
• Ambientes de dados
• Testes de infraestrutura

Vamos a isso.

Ambientes de teste

Todos os testes partem de um pressuposto implícito, crítico e simplificador: os nossos testes serão executados num ambiente conhecido.

O que é um ambiente?

Todos os sistemas precisam de ser testados num determinado contexto. Para que um teste seja significativo, o sistema tem de ser instalado, configurado, implementado ou criado num ambiente realista que simule o mundo real em que será utilizado. 

Podemos utilizar cenários de teste que levam a capacidade dos sistemas ao limite em termos de funcionalidade, desempenho ou segurança, por exemplo, mas estas são propriedades dos testes, não do ambiente.

Um ambiente realista reproduziria todos os ambientes empresariais, técnicos e organizacionais. Grande parte deste ambiente é constituída pelos dados utilizados para conduzir processos empresariais, configurar o sistema e fornecer dados de referência.

No entanto, os ambientes perfeitamente realistas são geralmente impraticáveis ou demasiado dispendiosos (mesmo os testadores de sistemas de elevada criticidade, como aviões, reatores nucleares ou scanners cerebrais, têm de fazer cedências a dada altura). Quase todos os testes decorrem em ambientes que simulam o mundo real com um nível aceitável de compromisso.

Os automóveis são testados em bancos de ensaio, túneis de vento, plataformas de vibração e pistas de teste privadas antes de serem testados na estrada aberta. Os sistemas informáticos são testados em laboratórios de software por programadores e testadores de software antes de os utilizadores finais serem convidados a experimentá-los num ambiente semelhante ao de produção.

Para garantir que os seus ambientes de teste cumprem as normas do setor, considere integrar uma destas plataformas de gestão de testes mais bem avaliadas.

Teste em ambientes realistas

Os ambientes simulados são falíveis, tal como os nossos requisitos e modelos de teste, mas temos de viver com isso.

Temos de preparar testes que sejam significativos nos ambientes de que dispomos, e os resultados dos testes significam aquilo que interpretamos que significam.

A fiabilidade dos resultados dos testes depende do ambiente em que os testes são executados. Se um teste for executado num ambiente configurado incorretamente:

• Um teste que falha pode dar a entender que o sistema tem defeitos quando, na realidade, está correto.
• Um teste que passa pode dar a entender que o sistema está correto quando, na realidade, tem defeitos.

É claro que ambas as situações são altamente indesejáveis.

Configurar e disponibilizar ambientes atempadamente

Mesmo com o surgimento da infraestrutura na nuvem, os ambientes de teste podem ser difíceis e dispendiosos de configurar e manter.

Quando as equipas de suporte trabalham no novo ambiente de produção, os testadores exigem ambientes de teste (e talvez vários). Mais tarde, durante os testes, as equipas de suporte têm frequentemente solicitações concorrentes.

Os ambientes de desenvolvimento ou qualquer atividade de teste posterior podem ser disponibilizados tarde ou não ser disponibilizados de todo, ou podem não estar configurados ou controlados conforme necessário. Inevitavelmente, isto atrasará os testes e/ou comprometerá a confiança em qualquer resultado dos testes.

Uma tarefa crítica consiste em estabelecer a necessidade e os requisitos de um ambiente a utilizar nos testes, incluindo um mecanismo para gerir alterações a esse ambiente—o mais cedo possível.

A infraestrutura como código é uma evolução recente na forma como os ambientes podem ser construídos, com ferramentas que seguem procedimentos e utilizam código declarativo para definir a configuração do ambiente. 

Embora as plataformas de sistemas operativos base (servidores) possam ser criadas facilmente na nuvem ou como máquinas virtuais no seu próprio ambiente, os servidores totalmente especificados e destinados a fins especiais, com todo o software, dados, configurações e interfaces necessários, exigem mais trabalho.

Ao configurar a sua infraestrutura de testes, é crucial integrar software fiável de gestão de bases de dados para obter um desempenho ideal

No entanto, depois de configurados, proporcionam um meio altamente eficiente de criar ambientes. O código da infraestrutura pode ser controlado por versões, tal como qualquer código de aplicação, e gerido através de alterações.

Um princípio fundamental da entrega contínua é que, assim que possível, algum software—mesmo que não seja útil—deve ser enviado através do processo de entrega para comprovar que os processos funcionam. 

É claro que isto requer ambientes viáveis para compilações, ferramentas de integração contínua, testes ao nível do sistema e implementação. O objetivo é implementar ambientes de teste e de produção sem restrições. Assim que as definições dos ambientes e os processos de implementação estiverem estabelecidos, a geração de ambientes torna-se uma tarefa automatizada e rotineira.

Em quaisquer circunstâncias, as definições destes ambientes constituem um dos primeiros resultados a disponibilizar pelo projeto.

Ambientes de desenvolvimento

Os testes realizados pelos programadores centram-se na construção de componentes de software que disponibilizam funcionalidades internamente à aplicação ou ao nível do utilizador ou da apresentação. 

Os testes tendem a ser orientados pelo conhecimento da estrutura interna do código e podem não utilizar nem exigir dados ‘realistas’ para serem executados. Os testes de componentes ou serviços de baixo nível são normalmente executados através de uma API, utilizando controladores ou ferramentas desenvolvidos à medida ou proprietários.

A variedade de ferramentas de desenvolvimento, plataformas e dos chamados Ambientes de Desenvolvimento Integrado (IDEs) é enorme. Neste artigo, podemos apenas abordar alguns dos principais requisitos e funcionalidades relacionados com os testes nos ambientes.

Para apoiar o desenvolvimento e os testes abrangidos pelos programadores, os ambientes precisam de suportar as seguintes atividades. Esta é apenas uma seleção—poderão existir atividades adicionais ou variações destas na sua situação:

• Um ambiente isolado para experimentar software novo. Os ambientes isolados são frequentemente utilizados para testar novas bibliotecas, desenvolver código de protótipos descartáveis ou praticar técnicas de programação. Todas as linguagens de programação comuns têm centenas ou milhares de bibliotecas de software. Os ambientes isolados são utilizados para instalar e testar software que ainda não faz parte do fluxo principal de desenvolvimento, de modo a avaliá-lo e praticar a sua utilização. Estes ambientes podem ser tratados como ambientes descartáveis.
• Ambiente de desenvolvimento local. É aqui que os programadores mantêm uma cópia local de um subconjunto ou de todo o código-fonte da sua aplicação, proveniente de um repositório de código partilhado, e podem criar compilações do sistema para testes locais. Este ambiente permite aos programadores efetuar alterações ao código na sua cópia local e testar essas alterações. Alguns testes são ad hoc e talvez nunca sejam repetidos. Outros testes são automatizados. Os testes automatizados são normalmente conservados indefinidamente, sobretudo quando seguem uma abordagem orientada por testes.
• Ambiente de integração partilhado (Contínua). Quando os programadores confiam que o seu código está pronto, enviam as alterações para o repositório de código partilhado e controlado. O ambiente de CI realiza compilações automatizadas e executa testes automatizados utilizando o repositório. Nesta fase, o código novo ou alterado é integrado e testado. O sistema de CI executa testes automatizados a pedido, de hora a hora ou diariamente, e toda a equipa recebe notificações e pode consultar o estado dos testes da compilação integrada mais recente. As falhas são expostas rapidamente e tratadas com caráter urgente.

Um ambiente de desenvolvimento ou de CI permite os testes dos programadores, mas outros servidores de aplicações, serviços Web, servidores de mensagens ou servidores de bases de dados que completam o sistema podem não estar disponíveis. 

Se estes sistemas de interface não existirem por ainda não terem sido desenvolvidos, ou por pertencerem a uma empresa parceira que dispõe apenas de um sistema em produção e não de uma versão de teste, os programadores têm de criar componentes fictícios ou simulados para estas interfaces, de modo a poderem, pelo menos, testar o seu próprio código. 

As ferramentas de simulação podem ser sofisticadas, mas as interfaces simuladas normalmente não conseguem suportar testes que exijam dados integrados entre vários sistemas.

Se estiver disponível para os programadores uma interface para um servidor de bases de dados de teste, os seus dados de teste podem ser mínimos, não estar integrados ou ser consistentes, e não representar os dados de produção. 

As bases de dados de desenvolvimento partilhadas por uma equipa são normalmente insatisfatórias. Se não existir um bom regime de gestão deste recurso partilhado, os programadores podem reutilizar, corromper ou eliminar os dados uns dos outros.

Ambientes de Teste ao Nível do Sistema

Os testes ao nível do sistema concentram-se na integração de componentes e subsistemas em colaboração. 

Estes ambientes fornecem uma plataforma para suportar os objetivos da integração em maior escala, da validação da funcionalidade e das operações do sistema no contexto de processos de utilizadores ou de negócio. 

Os ambientes também podem ser dedicados aos aspetos não funcionais do sistema, como o desempenho, a segurança ou a gestão de serviços.

Um dos problemas mais comuns nos testes ocorre quando um testador de sistemas deteta algum tipo de falha no seu ambiente, mas, por mais que tentem, o programador ou testador não consegue reproduzir a falha no ambiente de desenvolvimento.

Quase certamente, isto é causado por uma falta de consistência entre os dois ambientes. A diferença de comportamento pode ser causada pela configuração, por diferenças entre versões de software ou pela diferença nos dados da base de dados.

As diferenças nos dados que causam problemas são a primeira coisa a verificar. Normalmente, são fáceis de identificar e podem muitas vezes ser resolvidas rapidamente.

Quando existe uma discrepância na versão do software ou na configuração, os testadores e programadores podem perder muito tempo a investigar a causa da diferença de comportamento. 

Quando estes problemas ocorrem, isso significa muitas vezes que existe uma falha de comunicação entre o programador e o teste. Também pode indicar uma perda de controlo da configuração na preparação do ambiente de desenvolvimento ou de teste, ou no processo de implementação.

A infraestrutura como código e o aprovisionamento automatizado de ambientes tornarão os problemas de consistência dos ambientes uma coisa do passado.

Tipos de Ambientes de Teste Dedicados

Para suportar testes ao nível do sistema, testes de aceitação e testes não funcionais, os ambientes têm de suportar as seguintes atividades (poderá haver mais na sua organização):

• Ambiente de testes do sistema (funcional). Neste ambiente, o sistema é validado face aos requisitos documentados para o sistema como um todo. Os requisitos podem consistir em documentos de texto extensos, com casos de teste tabulados definidos para um teste do sistema. Em projetos ágeis, este ambiente pode ser necessário para permitir que os testadores explorem o sistema integrado sem se limitarem a funcionalidades específicas.
• Ambiente de testes de ponta a ponta. Enquanto o ambiente de integração contínua permite integrar componentes com subsistemas, os processos empresariais podem exigir que estejam disponíveis outros sistemas de interface (que não estão sob o controlo dos programadores). São necessários ambientes de âmbito completo para realizar testes de integração em grande escala, de processos empresariais ou de aceitação global. Normalmente, os dados são uma cópia dos dados de produção ou, pelo menos, têm uma escala adequada. Quando é necessário comprovar uma integração em grande escala, os fluxos de dados e de controlo são exercitados através de percursos de utilizador mais longos e de reconciliações independentes dos dados entre os sistemas integrados. A gestão de dados em ambientes de teste é crucial. Se já utiliza o Jira, considere melhorar as suas capacidades de gestão de dados com ferramentas avançadas de gestão de testes concebidas para o Jira.
• Ambiente de desempenho. Estes ambientes têm de disponibilizar uma plataforma significativa para avaliar o desempenho de um sistema (ou de determinados subsistemas). Podem ser possíveis compromissos na arquitetura quando existe redundância ou clonagem de servidores. No entanto, os volumes de dados têm de corresponder à escala de produção, mesmo que os dados sejam sintéticos. Evidentemente, o ambiente tem de ter uma escala capaz de suportar os volumes de transações de produção, de modo a permitir uma previsão útil do desempenho dos sistemas em produção.
• Ambientes de disponibilidade, resiliência e capacidade de gestão (ARM). Em alguns aspetos, estes ambientes são semelhantes aos ambientes de desempenho, mas, dependendo do objetivo do teste, podem ser inevitáveis algumas variações. Os testes de disponibilidade procuram verificar se o sistema consegue funcionar durante períodos prolongados sem falhar. Os testes de resiliência (frequentemente designados por testes de ativação de contingência) verificam se, quando os componentes do sistema falham, não provocam uma interrupção inaceitável do serviço prestado. Os testes de capacidade de gestão ou de operações procuram demonstrar que os procedimentos de administração, gestão e cópia de segurança e recuperação do sistema funcionam eficazmente.

Dados nos ambientes

Em alguns projetos de grande dimensão, podem existir até 20 ou mesmo 30 ambientes de grande escala dedicados a diferentes aspetos dos testes, da formação, da migração de dados e das transições experimentais. Nos projetos mais pequenos, haverá menos ambientes, talvez apenas um ambiente partilhado ou um regime de entrega contínua — e todos os testes poderão ser implementados automaticamente em ambientes instanciados para uma única utilização e, depois, desativados.

Todos os ambientes precisam de dados, mas a escala e o grau de realismo desses dados podem variar. Eis alguns padrões comuns na forma como os dados de teste são obtidos e geridos. Estes padrões centram-se na propriedade (local ou partilhada), nos meios de criação (manual, automatizada ou copiada da produção) e na escala:

• Dados locais, criados manualmente e de pequena escala — adequados para testes ad hoc realizados por programadores ou testadores.
• Dados locais, automatizados e sintéticos. Adequados para testes automatizados realizados por programadores ou para ambientes onde a funcionalidade de módulos ou funcionalidades específicas possa ser abrangida.
• Dados partilhados, criados manualmente. Utilizados em ambientes de testes de integração e do sistema, frequentemente quando os dados de teste evoluíram em paralelo com testes executados manualmente. Salvaguardados e restaurados quando necessário.
• Dados partilhados, criados automaticamente. Utilizados em ambientes de testes de integração e do sistema, quando os dados de teste evoluíram em paralelo com testes automatizados ou executados manualmente. Gerados e/ou restaurados a partir de cópias de segurança, quando necessário.
• Dados sintéticos/aleatórios partilhados e de grande escala. Os testes de desempenho e ARM exigem dados coerentes em grandes volumes. Normalmente, estes dados não precisam de ser significativos — os dados aleatórios funcionam perfeitamente e são gerados quando necessário, ou gerados inicialmente e restaurados a partir de cópias de segurança.
• Dados significativos partilhados e de grande escala. Os testes de ponta a ponta, de aceitação ou de utilizador normalmente precisam de dados significativos à escala necessária. Por vezes, são utilizadas cópias ou extrações de dados de produção. No entanto, tenha cuidado para não infringir os regulamentos relativos aos dados se não os baralhar/anonimizar.
• Novos testes e testes de regressão. Será necessário um conjunto de dados conhecido e controlado, num estado conhecido, pelo que é normalmente restaurado a partir de cópias de segurança. Isto aplica-se a qualquer um dos ambientes acima referidos, uma vez que estes testes têm de ser executados novamente com dados num estado conhecido para reproduzir as falhas de forma fiável.

Testes de infraestrutura

No início deste artigo, analisámos o que a infraestrutura inclui e, desde então, concentrámo-nos principalmente nos componentes técnicos, nomeadamente nos sistemas de software, partindo do princípio de que o hardware — real ou virtual — está disponível.

Quando construímos sistemas inicialmente, partimos do princípio de que a infraestrutura existe e funciona corretamente, tem um bom desempenho, é segura e resiliente, entre outros aspetos.

Podemos testar todos estes aspetos quando tivermos integrado a nossa aplicação e, sem dúvida, expor deficiências na infraestrutura numa fase relativamente avançada dos nossos projetos. Mas descobrir problemas na infraestrutura tão tarde num projeto é geralmente extremamente perturbador.

• As alterações para resolver falhas na infraestrutura podem exigir uma reformulação significativa e alterações na nossa aplicação.
• Será necessário repetir os resultados dos testes da nossa aplicação ou de todo o sistema.
• Se componentes de terceiros, como serviços de bases de dados, Web, redes ou mensagens, falharem, ficamos à mercê dos fornecedores (ou da comunidade de código aberto) que lhes dão suporte.

Para garantir que a nossa confiança nos componentes da infraestrutura é bem fundamentada, podemos basear-nos na nossa experiência (ou na experiência de outros) com a sua utilização no passado. Em alternativa, precisamos de avaliar — através de testes — a sua fiabilidade antes de nos comprometermos a utilizá-los na conceção e construção do nosso sistema.

Dependendo da infraestrutura em análise, o ambiente que utilizamos pode variar — desde um único servidor até uma plataforma de infraestrutura quase completa. 

Embora alguns testes sejam manuais, na maioria dos casos utilizaremos ferramentas, controladores ou robôs para simular a carga de transações que a nossa aplicação geraria. Teríamos de simular ou criar versões fictícias destas interfaces:

• Interfaces que ainda não estão disponíveis
• Interfaces para componentes em que confiamos e que são fáceis de simular
• Interfaces fora do âmbito que não afetam a infraestrutura em teste.

A infraestrutura, escusado será dizer, normalmente não funciona através de uma interface de utilizador ou GUI.

A integração da nossa aplicação com a infraestrutura assumirá sobretudo a forma de mensagens ou chamadas a serviços remotos. Frequentemente, o tráfego a simular exige chamadas de API a servidores Web ou de aplicações, servidores de mensagens ou de bases de dados, ou serviços fornecidos através da nuvem ou de localizações remotas.

Os objetivos de desempenho e de ARM podem ser conhecidos, caso em que é possível realizar testes para garantir que esses objetivos são cumpridos.

No entanto, a infraestrutura é frequentemente partilhada com outras aplicações além da nossa, pelo que conhecer a sua capacidade máxima ajuda a avaliar quanta capacidade permanecerá quando a nossa aplicação for implementada.

Neste caso, os testes à infraestrutura abordam o risco para as nossas próprias aplicações e, talvez, para outras aplicações que venham a basear-se nela no futuro. 

Subscreva o boletim informativo The QA Lead para receber uma notificação quando forem publicados novos artigos da série. Estes artigos 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!

Leitura sugerida: 10 MELHORES FERRAMENTAS DE CÓDIGO ABERTO PARA GESTÃO DE TESTES