Continuando uma série de resumos com o HL2018. Os caras do Badoo (Vladimir
Yants vyants e Nikolai Krapivny) me ajudaram a conferir este
compêndio , pelo qual muito obrigado a eles. Espero que isso tenha um efeito positivo na qualidade da mensagem do relatório.
Recursos do processo de desenvolvimento:
A responsabilidade do desenvolvedor não termina com o lançamento do back-end. Ele é responsável antes da implementação nas plataformas.
Há testes manuais, mas o cliente não está pronto no momento do lançamento e é lançado com um atraso (imprevisível). Geralmente, não sabemos quando os clientes começarão a implementá-lo. Às vezes (não frequentemente) os recursos começam a ser executados após um longo período de tempo. Portanto, testar com as mãos é difícil e nem tudo é possível. Portanto, são necessários autotestes.
Testes
Testes unitários
Escrito em phpunit.
Teste uma pequena unidade. Eles não vão ao banco de dados ou aos serviços (eles não devem interagir com nada).
O legado ainda tem e complica o processo de teste.
Eles desenvolveram a biblioteca softMocks - todos os ganchos incluem / exigem e a substituem pela que foi alterada.
Você pode encerrar qualquer método: estático, privado, final.
A biblioteca está disponível em código aberto.
Problema: os softmocks relaxam e permitem escrever código não testado (e cobri-lo com testes).
Aceitou as regras:
- O novo código deve ser fácil de testar o phpunit
- SoftMocks - caso extremo (código antigo / longo / caro / complicado)
Observamos a revisão do código para essas regras.
Qualidade de teste
Teste de mutação
- Pegue o código
- Obter cobertura de código
- Analisamos o código e aplicamos mutações (alteração + => -; true => false, etc.)
- Para cada mutação, executamos um conjunto (conjunto) de testes.
- Se os testes falharem, aprox. Caso contrário, eles não são eficazes o suficiente. Entendemos, alteramos / adicionamos testes.
Existem soluções prontas (Farsa, Infecção), mas elas não se encaixam (não são compatíveis com softmocks, há dificuldades com a cobertura do código). Portanto, eles escreveram os seus próprios.
O teste de mutação ainda não está disponível para teste manual. Disponível para execução manual, no console. Agora estamos implementando-o no pipeline de IC, estamos construindo o processo. O resultado será para Habr.
Testes de integração
Testando a operação de vários componentes em conjunto; Verificamos o trabalho com a base e / ou serviços.
Abordagem padrão para teste de banco de dados (DBUnit):
- Aumente o banco de dados de teste
- Preencha
- Execute o teste
- Limpamos o banco de dados
Os problemas:
- É necessário suportar tabelas de dados e conjunto de dados (relevância do conteúdo do banco de dados)
- Leva tempo para preparar o banco de dados
- Lançamentos paralelos tornam os testes instáveis e causam impasses
Solução: biblioteca DBMocks (solução própria)
Princípio de funcionamento:
- Métodos de driver de banco de dados interceptados usando SoftMocks no teste de configuração
- A partir da solicitação parsim db + table
- Tmpfs cria tabelas temporárias com o mesmo esquema
- Todas as consultas vão apenas para tabelas temporárias
- No TearDown, eles são excluídos
A biblioteca é pequena, mas ainda não está aberta em código aberto.
Resultados:
- Os testes não podem corromper dados nas tabelas originais
- Os testes são isolados um do outro (podem ser executados em paralelo)
- Testando a compatibilidade de consultas com a versão MySQL
Testes de API
- Imitar uma sessão do cliente
- Capaz de enviar solicitações de back-end
- O back-end responde quase como um cliente real
Normalmente, esses testes requerem um usuário autorizado. Ele deve ser criado antes do teste e excluído depois. Isso apresenta riscos adicionais (replicação, tarefas em segundo plano).
Solução: fizemos um pool de usuários de teste. Aprendeu como limpá-los.
Os usuários de teste estão no mesmo ambiente que os reais, porque desenvolvem! = Prod. É necessário isolar usuários ativos e de teste.
Para isolamento, o sinalizador is_test_user foi adicionado ao usuário. E esses usuários também são excluídos da análise e dos resultados do teste a / b.
Pode ser mais barato enviando usuários de teste "para a Antártica", onde ninguém os verá (exceto pinguins).
API de controle de qualidade
Uma ferramenta para preparar o ambiente em testes de API, de fato um backdoor no back-end para alterar rapidamente as configurações do usuário / ambiente.
- Métodos api bem documentados
- Gerencie dados de maneira rápida e fácil.
- Desenvolvedores escrevem back-end
- Só pode ser aplicado para testar usuários.
Permite ao usuário alterar dados imutáveis (por exemplo, data do registro).
Proteção necessária:
- No nível da rede (disponível apenas na rede do escritório)
- Um segredo é passado com cada solicitação, cuja validade é verificada
- Os métodos funcionam apenas com usuários de teste.
Existe um programa BugsBounty no HackerOne. Eles pagam pelas vulnerabilidades encontradas. Foi possível encontrar um problema com a API do controle de qualidade.
Zombarias remotas
Moki para o back-end remoto.
Trabalhe na base de zombarias macias. O teste solicita que o back-end seja inicializado para a sessão simulada. Após o recebimento da solicitação, o back-end verifica a lista de mox da sessão e as aplica usando o SoftMocks.
Exemplo de teste:
Os testes de API são muito convenientes. É tentador escrevê-los em vez de Unit. Mas os testes de API são muito mais lentos.
Adotou um conjunto de regras:
- O objetivo dos testes de API é testar o protocolo e a integração
- Fluxo complexo de verificação válido
- Pequena variabilidade não pode ser testada.
- Na revisão de código, também testamos os testes.
Testes de interface do usuário
O comando de back-end não escreve.
O recurso é coberto pelos testes de interface do usuário quando ele se estabiliza.
Usado pelo selênio para a web. Para cabaça móvel.
Execução de teste
100.000 testes de unidade. 6.000 integração, 14.000 testes de API.
Em um fluxo, o tempo é de 40 min / 90 min / 10 horas.
Feito TestCloud - uma nuvem para executar testes.
A distribuição do teste entre os threads:
- Você pode igualmente (mal, todos os testes são diferentes, resultam desiguais em partes do tempo)
- Execute vários threads e teste de phpunit de feed um de cada vez (sobrecarga de inicialização. Long!)
Solução:
- Coleção de estatísticas sobre o tempo de execução.
- Layout dos testes para que o bloco não execute mais de 30 segundos
O problema com os testes da API é muito tempo, muitos recursos e não permite a execução de outros.
Para resolver, dividimos a nuvem em 2 partes:
- Executa apenas testes rápidos.
- Executa os dois tipos de testes.
O resultado é uma aceleração do tempo para:
- Unidade - 1 min
- Integração - 5 min
- API - 15 minutos.
Execução de cobertura de código
Quais testes executar? Mostrará a cobertura do código.
- Temos diff diff
- Crie uma lista de arquivos modificados
- Obtenha uma lista de testes para esses arquivos.
- nós executamos a suíte apenas nesses testes.
A cobertura é formada uma vez por dia, à noite, para o ramo principal. Os resultados (diff) são adicionados ao banco de dados.
Prós:
- Executamos menos testes: menos carga de hardware e feedback de teste mais rápido
- Você pode executar testes para correções. Isso permite que você implante rapidamente o hotfix. Nos patches, a velocidade é mais importante.
Contras:
- Liberação de back-end 2 vezes ao dia. Após o almoço, a cobertura é menos relevante (mas ao lançar uma batida, sempre conduzimos um conjunto completo).
- Os testes de API geram uma cobertura abrangente. Para eles, essa abordagem não oferece muita economia.
Se o desenvolvedor precisar ver imediatamente a cobertura do código, ou seja, uma ferramenta que pode ser iniciada no console e obter imediatamente uma nova métrica para a cobertura de um arquivo / componente específico.
É considerado complicado: os dados no mestre de cobertura são coletados, todos os testes modificados são adicionados, resultando em um pequeno conjunto no qual a cobertura já é considerada.
Sumário
- Precisa de todos os níveis de teste
- Quantidade! = Qualidade. Revisão de código e teste de mutação
- Isole os usuários de teste dos reais.
- Os back-end no back-end simplificam e agilizam os testes de gravação
- Colete estatísticas sobre testes.
Referências