BLOG

Perfil da ferramenta de teste: Por que o Threat Stack usa o ThoughtWorks Gauge

Miniatura F5
F5
Atualizado em 16 de março de 2022

O Threat Stack agora é F5 Distributed Cloud App Infrastructure Protection (AIP). Comece a usar o Distributed Cloud AIP com sua equipe hoje mesmo .

O Threat Stack realiza vários testes diariamente, verificando se tudo está funcionando conforme o esperado em nossa Threat Stack Cloud Security Platform®. Para complementar os testes unitários e de integração dos engenheiros de software, nossa equipe de engenharia de testes criou o seguinte como parte de nosso conjunto de testes de regressão automatizados:

  • Testes baseados em navegador , escritos em Capybara, verificando se apenas usuários válidos podem efetuar login em nosso Painel, navegar em nosso site, visualizar o rastro de eventos criados por sua frota AWS e criar e atualizar regras com base nesses eventos que geram alertas que sua equipe de segurança pode selecionar, tudo por meio de nossa interface de usuário baseada na web: Mais de 150 testes.
  • Testes de API , usando a gem Net/HTTP Ruby para interagir com nossa API Threat Stack , verificando se você pode recuperar os últimos trinta dias de logs de auditoria, listar alertas individuais e grupos de alertas por gravidade e tipo, listar todos os ambientes virtuais monitorados e investigados pelo Threat Stack e visualizar os conjuntos de regras de conformidade básicos para HIPAA, ISO 27001, MPAA, PCI e SOC 2. Os testes também verificam se os alertas gerados por essas regras pré-configuradas e personalizadas podem ser visualizados, suprimidos ou descartados, tudo por meio da API Threat Stack: Mais de 130 testes.

Como podemos acompanhar quase trezentos testes de aceitação? Os engenheiros de teste aqui na Threat Stack configuram seus testes com o ThoughtWorks Gauge , uma estrutura de automação de testes gratuita, leve e multiplataforma. 

Há duas partes principais em um teste Gauge:

  • A especificação do teste, escrita em linguagem simples, é uma lista passo a passo de instruções em tópicos sobre como realizar o teste. A especificação deve ser lida como um plano de teste manual, claro e conciso, com descrição suficiente para que outros possam seguir.
  • A pasta step_implementation inclui o código que executa o teste, envolvendo cada etapa em um bloco de código que pode ser reutilizado sempre que e onde for chamado na especificação. 

Ao fazer com que o Gauge separe o plano de teste do código que executa o teste, ele torna nossos testes mais legíveis e fáceis de manter, permitindo que as etapas do teste sejam compartilhadas entre nossos testes.

No restante desta postagem, nos concentramos em dez dos principais recursos que amamos no Gauge: 

Instantâneo:

  • Site: Gauge.org , Github.com/getgauge
  • Data de lançamento: Julho de 2018
  • Idiomas suportados: Java, C#, Ruby, Javascript, Go, Python
  • Sistemas operacionais suportados: Linux, macOS, Windows
  • Plugues IDE: Visual Studio, Código Visual Studio, IntelliJ

1. Facilidade de configuração

O medidor é muito fácil de instalar. Acesse a página de instalação do Gauge e, ao selecionar seu sistema operacional, linguagem de programação e IDE, instruções personalizadas sobre como instalar tudo serão exibidas. As instalações do MacOS podem ser feitas no HomeBrew, as instalações do Linux usando o APT_GET e as do Windows usando o Windows Installer, se você não quiser instalar a partir do código-fonte

Depois que tudo for baixado, o executor de linguagem para uma linguagem de programação como Ruby pode ser instalado digitando gauge install ruby na linha de comando.

2. Projeto de amostra incluído

Com uma nova estrutura de automação de testes, pode ser difícil determinar quais arquivos precisam estar em quais pastas e como configurar e iniciar os testes. 

O Gauge contorna essa confusão incluindo um projeto de amostra, com alguns testes que novos usuários do framework podem testar. Digamos que você tenha uma determinada palavra, como “Gauge”, “Mingle” ou “Snap”. Como você poderia criar testes que contassem o número de vogais na palavra, assegurando que a contagem esperada e a real correspondem? 

Os testes de exemplo são orientados por dados, com a entrada capturada em uma tabela de dados com duas colunas, ‘Palavra’ e a esperada ‘Contagem de vogais’.

O projeto de amostra pode ser executado, logo após a instalação, a partir da linha de comando com gauge run spec .

Exemplo de saída, linha de comando: 

3. Separação entre o teste e como o teste é implementado

Tentar descobrir o que realmente está sendo testado em um conjunto de testes automatizados pode ser um exercício de frustração, especialmente se você precisar examinar vários blocos de código antes de decifrar o propósito do teste, as etapas que o teste realiza ou o código que executa cada etapa do teste. 

O Gauge contorna essa confusão separando o plano de teste e como o plano de teste é executado. O Gauge organiza etapas em um arquivo Markdown , a linguagem de formatação de texto criada por Josh Gruber e Aaron Swartz em 2004. As etapas do teste são salvas como marcadores em arquivos de especificação , que podem ser executados pelo step_implementations

Especificações: As especificações não são simplesmente listar as especificações de um recurso de um produto: Eles são uma maneira de organizar o código de teste e configurar os relatórios HTML ou XML. Cada elemento no arquivo *.spec corresponde a um elemento no Markdown. As especificações são um “caso de teste da camada de negócios que também pode atuar como sua documentação de recursos. Eles são escritos na linguagem empresarial. Normalmente, uma especificação descreve um recurso específico do aplicativo em teste”, de acordo com a documentação oficial do Gauge

Cada especificação tem um cabeçalho, descrevendo os vários cenários de teste que serão executados, com cenários de teste relacionados descritos como subcabeçalhos. Esses cabeçalhos e subcabeçalhos são incluídos ao visualizar os logs, para ver o que foi aprovado e o que falhou, e no relatório HTML. 

Definições de etapas: Cada etapa listada na especificação corresponde a um conceito ou a uma definição de etapa reutilizável que combina a linguagem simples da especificação com o código Java, C#, Javascript, Python ou Ruby que é executado. 

Ao separar o teste do código que o executa, ele permite que outros testadores, analistas de negócios e proprietários de produtos vejam claramente como o teste foi construído observando o arquivo de especificações, sem precisar mergulhar no código.

4. As especificações são formatadas para facilitar a leitura

As especificações são configuradas para serem muito legíveis. 

  • Os cabeçalhos são prefixados com uma hashtag (“#”) onde o autor pode descrever o que os cenários farão.
  • Os cenários de teste individuais são listados como subtítulos indicados com hashtags duplas (“##”). 
  • As etapas de teste que executam o cenário em teste são prefixadas com um asterisco, como um marcador (“*”). 

Precisa de um exemplo de um arquivo de especificação? Aqui está a especificação do projeto de demonstração que o Gauge instala ao inicializar um novo projeto do Gauge:

# Cabeçalho de especificação
Este é um arquivo de especificação executável. Este arquivo segue a sintaxe markdown. Cada título neste arquivo denota um cenário. Cada ponto com marcadores denota um passo.
* Vogais em inglês são "aeiou".
## Contagem de vogais em uma única palavra
* A palavra "gauge" tem "3" vogais.
## Contagem de vogais em várias palavras
Este é o segundo cenário nesta especificação. Aqui está um passo que leva uma tabela.
* Quase todas as palavras têm vogais
|Palavra |Contagem de vogais|
|------|-----------|
|Medidor |3 |
|Misturar|2 |
|Snap |1 |
|GoCD |1 |   

Cada ponto de marcador nesta especificação corresponde a uma etapa de teste listada na pasta step_implementations. 

Precisa de outro exemplo? Digamos que você tenha na pasta specs um teste chamado login.spec que faz login em um site:

# Teste de login
## Verifique se usuários válidos podem fazer login no site
* LOGIN: Insira o nome de usuário: “info@threatstack.com”
* LOGIN: Digite a senha: “1234”
* LOGIN: Selecione [ENTRAR]

Cada etapa colocada na pasta step_implementations pode ser localizada e executada automaticamente pelo teste.

login_spec.rb etapa 'LOGIN: Digite o nome de usuário: ' do | username | fill_in(EMAIL_TEXTBOX, with: username) end

Você percebe que está executando a mesma série de passos repetidamente? Você pode colocar essas três etapas de login em um arquivo de conceito , em Login.cpt

login.cpt # Faça login como e * LOGIN: Digite o nome de usuário: * LOGIN: Digite a senha: * LOGIN: Selecione [ENTRAR]

Se outros testes tiverem um componente Login, em vez de copiar e colar todas as três etapas, você pode inserir apenas uma linha no teste: Faça login como “info@threatstack.com” e “1234”

5. Boa documentação e suporte

Aprender uma nova estrutura de automação pode ser confuso. Às vezes, ler a documentação não é suficiente. Você tem alguma dúvida que não pode ser respondida lendo a documentação completa do Gauge.org? Os desenvolvedores são bastante receptivos no StackOverflow , Google Groups e Gitter Chat .

6. Relatórios HTML criados com base na especificação de teste

As especificações de teste, como abordamos, são escritas em Markdown . Esses testes listados na especificação podem ser aproveitados como a verdadeira documentação sobre como o produto de software em teste opera. Como estão listadas em Markdown, as especificações podem ser usadas para criar relatórios HTML fáceis de ler.

Vamos dar uma olhada no relatório HTML do projeto de demonstração, contando o número de vogais em uma palavra:

Podemos ver que o Relatório HTML contém:

  • A hora e a data em que os testes foram executados e quanto tempo levaram para serem executados
  • Quantas especificações e cenários foram executados
  • Quantas especificações e cenários foram aprovados e reprovados
  • Quais etapas foram executadas, com etapas aprovadas em verde e etapas reprovadas em vermelho. Mensagens de erro são incluídas no relatório. 

7. Medidor de suprimentos Ganchos de execução

Qualquer boa estrutura de automação inclui maneiras de configurar pré-condições para um teste e um método de desmontagem que é executado após a conclusão dos testes. 

Um exemplo seria um conjunto de automação focado em testes de navegador, que teria um método de configuração que inicializa o navegador quando o conjunto de testes é iniciado e um método de desmontagem que fecha o navegador quando os testes são concluídos. 

O Gauge fornece ganchos de execução que podem ser executados antes e depois de cada suíte, especificação, cenário ou etapa no seu conjunto de testes de automação.

Ao usar os códigos de execução, o Gauge remove a duplicação de código que precisa ser executado antes de cada suíte, especificação, cenário ou etapa. 

8. Funcionalidade da linha de comando

O Gauge tem o que eles chamam de “suporte de refatoração de primeira classe” tanto no IDE quanto na linha de comando. Por exemplo, para aqueles que gostam de ajustar continuamente o texto de um teste para que fique cada vez mais claro o que o teste está realmente fazendo, digite o seguinte na linha de comando: 

$ gauge --refactor "nome antigo da etapa" "nome novo da etapa"

Para mais informações sobre ferramentas de linha de comando para o Gauge, consulte manpage.gauge.org

9. Os testes podem ser orientados por dados

Os testes podem ser configurados para serem elaborados com base em dados, de modo que testes que são simplesmente variações de um tema possam ser alimentados com uma tabela de parâmetros de teste para uso. 

Digamos que você tenha uma série de webservices que precisam ser testados, atingindo um endpoint de API. Dado o nome do webservice, o esquema e a porta, você precisa verificar se a resposta HTTP será 200 OK

Como cada teste é semelhante ao outro, os dados podem ser formatados em uma tabela fácil de ler.

webservice_test.especificação

Cada linha de informação é alimentada na etapa de teste e executada pela implementação da etapa correspondente, poupando o autor de qualquer duplicação de trabalho. 

10. Os dados podem ser armazenados em tempo real

Às vezes, você precisa compartilhar dados entre etapas de teste, salvando-os e armazenando-os para mais tarde. Assim como no teste de API acima, depois de receber a resposta ao atingir o endpoint, você tem etapas de teste para garantir que ela esteja em um formato válido com o esquema JSON correto ou se quiser garantir que as mensagens de erro adequadas sejam listadas ao executar um teste negativo. 

O Gauge usa três tipos de DataStores: ScenarioStore, SpecStore e SuiteStore, salvando dados como pares chave/valor para o ciclo de vida do Cenário, Spec ou de todo o Conjunto de testes. 

Exemplo: Na seção de implementação de etapas, você pode adicionar IDs de elementos como este:

// Adicionando valor
scenario_store = DataStoreFactory.scenario_datastore;
scenario_store.put("element-id", "455678");
// Buscando valor
element_id = scenario_store.get("element-id");

Finalizando...

Como indicamos no início, quando você executa tantos testes como fazemos no Threat Stack diariamente, você precisa de uma estrutura de automação de testes multiplataforma que seja ao mesmo tempo robusta e ágil, e que tenha os recursos e capacidades para atender às suas necessidades específicas de teste, ao mesmo tempo em que fornece facilidade de uso e automação significativas para que você possa testar completamente, em um prazo razoável, com a quantidade certa de esforço e contribuição por parte do testador.

Fique atento: Em uma postagem futura, daremos uma olhada em algumas das outras ferramentas de teste que usamos no Threat Stack, incluindo o Capybara.

O Threat Stack agora é F5 Distributed Cloud App Infrastructure Protection (AIP). Comece a usar o Distributed Cloud AIP com sua equipe hoje mesmo .