🌶️ 🚉 🤦🏾 Software de teste de automação QIWI-terminais 🙎🏼 💆🏿 ⌛️

Olá Habr!

Hoje falaremos sobre um tópico específico: automação de teste de software para terminais de autoatendimento QIWI.

Existem áreas no tópico de automação de teste que são varridas para cima e para baixo várias vezes, por exemplo, testando serviços da web. Para essas áreas, existem ferramentas, padrões e melhores práticas separadas. Você não precisa inventar nada, os riscos são mínimos, você aceita e realiza.

Existem situações inversas. O assunto é específico, ninguém espia as soluções prontas, não há ferramentas, a pilha tecnológica do produto é peculiar. Você tem que mergulhar fundo na área de assunto, de paus e outros materiais improvisados para criar ferramentas para si mesmo e coletar simultaneamente muitos, muitos ancinhos de tamanhos diferentes e força letal.

Eu queria falar sobre algo assim hoje. O artigo é adequado para os envolvidos no desenvolvimento e teste de software para terminais bancários ou máquinas de autoatendimento. E também para aqueles que querem expandir seus horizontes técnicos com exemplos de "mas isso também acontece assim". Terminal QIWI em 2020. Em segundo plano, você pode ver o seu preenchimento.

Problema

O primeiro terminal QIWI apareceu em 2004 e foi capaz de reabastecer a conta de um telefone celular. Desde então, muita água correu e o ASO (máquinas de autoatendimento) mudou muito. Agora, com a ajuda deles, você pode reabastecer cartões bancários, fazer transferências, pagar por serviços de vários fornecedores (provedores) - serviços de habitação e comunais, multas da polícia de trânsito, organizações de crédito, nossos próprios produtos QIWI (carteira QIWI, carteira de pagamento sem juros, Conscience). Os terminais QIWI também podem operar no modo postamata (pontos de entrega automatizados para lojas online).

Como é um terminal?

O terminal ASO, do ponto de vista do ferro, é uma área de trabalho comum com periféricos específicos, como aceitadores de notas e moedas, impressoras de recibos, distribuidores, terminais POS (cartões plásticos), etc.

E aqui está o primeiro problema.

Esta fotografia famosa foi tirada em Sonoma County, Califórnia. Dizem que são cores naturais, sem qualquer processamento. A propósito, foi no território do condado de Sonoma que se localizou a colônia russa mais ao sul da América.

Sim, é ela. O sistema operacional, que foi descontinuado em 2014, é o Windows XP. A versão do POSReady foi lançada até 2019, mas ... Não é tão simples.

O fato é que os terminais não são de propriedade da QIWI. Eles pertencem a parceiros, os chamados Agentes, empreendedores individuais e pessoas jurídicas que concluem um contrato com os terminais de compras QIWI, alugam espaço em shopping centers e recebem renda quase passiva.

Consequentemente, 90% da frota de terminais QIWI (e existem mais de 100k na Rússia e em países estrangeiros) estão executando o Windows XP em uma variedade de hardware - de 512 MB a 4 GB de RAM, uma variedade de CPUs (desde Pentium 4 até zero anos - menos moderno do Core i5) e qualidade e velocidade diferentes da Internet. Terminais de diferentes idades, alguns deles são atualizados regularmente e alguns não são atualizados há muito tempo (funciona - não toque!). Nossa tarefa é fornecer regularmente as atualizações mais recentes do software do terminal (chamado MarATL) e manter a compatibilidade com toda essa variedade de coberturas e periféricos.

Sistema operacional de suporte expirado

Imagine um circuito simples de automação de teste. Temos um servidor de IC, por exemplo, TeamCity ou Jenkins. Nosso software de terminal é coletado de matérias primas por evento (confirmação ou heap), o arquivo binário coletado é disposto em algum lugar. O software é instalado automaticamente, os autotestes funcionais noturnos são lançados ... Uh, pare! Para onde está indo a instalação do software? E como?

Como eu disse acima, 90% dos terminais estão executando o Windows XP, que terminou em 2014. Isso significa que esse sistema operacional não cumpre mais as políticas de segurança por um longo tempo, não há atualizações para ele, não há software de trabalho novo para ele e até o Microsoft Visual Studio nativo compila o C ++ para ele somente depois de dançar com um pandeiro, ou melhor, com a versão da cadeia de ferramentas para o coletor do MSBuild.

Em geral, executar testes e algum tipo de software em um terminal ou máquina virtual com o Windows XP é uma péssima idéia. Você não pode criar o Buildagent TeamCity no XP, não pode configurar essa máquina no manual do Ansible, também não há contêineres. Modelos de virtualização para Windows XP também não são muito. Em qualquer empresa grande que pense em segurança da informação, uma máquina Windows XP será mantida afastada da rede corporativa, ou menos ainda do domínio. Ou seja, toda interação com o terminal (ou a máquina virtual que finge ser) deve ocorrer remotamente, o próprio terminal deve ter um mínimo de software de terceiros.

Decisão

Algumas pessoas ficam surpresas quando ouvem falar de um monte de OpenSSH e Windows XP. Em uma versão moderna da Microsoft, o suporte a SST é incluído diretamente no sistema. No não tão moderno (Windows 7), existem instaladores SSH usando o PowerShell. C Windows XP, a situação é um pouco pior, mas apenas um pouco. Existe uma versão antiga do instalador que é executada sem software adicional.

O SSH é uma maneira antiga, boa e confiável de controlar remotamente um host, uma tecnologia bem conhecida. Você precisa implementar classes de conectores SSH que podem fazer várias coisas em paralelo. Por exemplo, no modo online, carregue novos logs do terminal, execute alguns comandos (copiar arquivos, executar scripts, emitir direitos, obter uma lista de processos, monitorar a hora do sistema do terminal etc.)

Monitorar o tempo do sistema é especialmente interessante. Por ferramentas de linha de comando padrão, o Windows XP exibe o tempo apenas em um formato formatado horas-minutos-segundos, etc., sem horário UNIX para você. A emboscada, por exemplo, é que o XP não recebe atualizações de fuso horário há muito tempo, e nosso governo russo é conhecido por jogos constantes com o cancelamento do verão ou do inverno.

Por exemplo, o Windows XP SP3 padrão no fuso horário de Moscou mostra o horário uma hora antes do horário real de Moscou. Consequentemente, os registros de data e hora dos logs do terminal, em qualquer caso, não coincidem com o horário no circuito de teste.

Pagamentos-Pagamentos-Pagamentos ...

A interface do terminal QIWI é essencialmente uma web que roda em um mecanismo de navegador, que geralmente é bastante antigo. De acordo com o protocolo websocket, ele interage com o MarATL, na verdade um software de terminal. Ao escolher um pagamento no terminal (por exemplo, pagar por comunicações celulares) usando uma série de comandos, um provedor de pagamento é selecionado, a quantidade de comissões, as restrições de aceitação de contas são determinadas, um pagamento é criado para um provedor específico, que é enviado através do processamento do terminal de pagamento para pagamentos.

Interagir com a interface da Web remotamente é uma idéia mais ou menos, especialmente testes de interface - outra tarefa. Você pode criar uma página da web de teste com base no tempo de teste, e não no index.html padrão. A página executa um script JS que funciona com o software de terminal e, por outro lado, cria um cliente de soquete da web que olha para fora em direção ao host no qual os testes estão sendo executados.

No lado dos autotestes, você precisa implementar um servidor de soquete da Web que aguarda no início da conexão do cliente a partir do terminal e envia comandos que não são alterados pela página de teste para o software do terminal. As respostas do software também são enviadas para o servidor de soquete da web de teste.

Ou seja, é possível descrever o conjunto de comandos para o teste de pagamento na forma de JSON, que descreve sucessivamente quais comandos você precisa enviar e que tipo de resposta aguardar por eles.

Página de teste da interface. Exibe os comandos que passam por ele.

E onde está o dinheiro?

A tarefa técnica mais insidiosa é simular os dispositivos periféricos do terminal. A impressora de recibos é simulada trivialmente, uma impressora virtual é criada no sistema operacional que imprime os dados em um arquivo. Você pode obter essa verificação no terminal (ou sua cópia formada pelo próprio software do terminal) e decodificá-la, verificando simultaneamente, por exemplo, se todos os campos necessários estão presentes nessa verificação.

Mais complicado com dispositivos que aceitam dinheiro - aceitadores de notas e moedas. É claro que, se quisermos testar o cenário de pagamento, precisamos de alguma forma imitar a presença do aceitante da conta no terminal, suportar a funcionalidade de aceitar faturas, retornar, simulando vários problemas (por exemplo, devolver uma fatura amassada).

A maioria dos dispositivos de recebimento de dinheiro opera usando o protocolo CashCode NET. Este protocolo define os cenários de interação entre o aceitante da conta e o controlador (no nosso caso, o controlador é o nosso software de terminal).

Um exemplo da interação do controlador e do validador de notas usando o protocolo CashCode. Com uma certa frequência, o controlador solicita o status do dispositivo.

O tamanho mínimo do comando CashCode é 6 bytes. Para obter uma descrição dos comandos, consulte a especificação do protocolo CashCode NET.

O aceitador de contas padrão está conectado ao terminal através da porta COM. Existem utilitários de terceiros que permitem criar uma porta serial virtual na máquina, por exemplo, VSPE . Até scripts para encaminhar esta porta através de uma conexão TCP são suportados.

Nosso caso é mais simples, precisamos de uma ferramenta que possa se apegar à porta usando o WinAPI e tenha uma interface conveniente arbitrária, por exemplo, o stdin / stdout mais simples, que pode ser conectado usando o SSH.

O Tula em um fluxo separado se comunica com o controlador por uma porta serial e, se necessário, imita situações de recebimento de "dinheiro" supostamente. Também é necessário ter algum tipo de pool de contas ou provedores de teste, cujos pagamentos não serão processados com real, mas serão repelidos em algum momento. Ou, para casos mais complexos, o dinheiro passa por processamento real, mas chega a contas especiais, das quais serão debitadas novamente para testes de pagamento.

Esse é o ciclo do dinheiro na natureza.

Impressora de recibos (acima) e aceitante da conta (abaixo).

24/7

O software para terminais e caixas eletrônicos deve ser extremamente resistente a várias situações de emergência - falta de Internet, problemas com um aceitador de contas, etc. Como esse software é executado em um terminal com uma prioridade e direitos muito altos, ele basicamente intercepta todo o controle do SO. Você não pode simplesmente recolhê-lo ou fechá-lo com o Alt-F4. O software pode se reinicializar e o terminal, incl. Em um loop. Também é necessário verificar esses cenários estressantes, por exemplo, a falta de comunicação com o processamento de pagamentos. O terminal responde a isso com reinicializações periódicas, você precisa verificar se o faz corretamente e corretamente sempre que carregar o software do terminal.

Instalação do zero e atualização

O software do terminal instalado é atualizado centralmente usando o processamento de pagamentos. O processamento planeja atualizar um terminal específico e determina o perfil de atualização para ele, ou seja, de quais arquivos e de onde carregar. Para atualizar, é necessário executar vários procedimentos no banco de dados de processamento e monitorar o terminal. Verifique pelos logs se o download dos arquivos necessários foi iniciado e se a atualização foi concluída com êxito e se o software do terminal aumentou.

Uma instalação limpa do zero é mais difícil. Geralmente, uma pessoa faz isso nos campos simplesmente copiando o arquivo de instalação para o terminal e inserindo as configurações e os dados de autorização nos formulários do instalador, que geralmente é um aplicativo WinAPI com controladores padrão do Windows (TextBox, CheckBox, etc.).

Em nossos testes automáticos para um script de instalação limpa, um script Python é anexado ao terminal, iniciado pelo instalador, interage com os controladores usando a biblioteca pywinauto e grava seu próprio log de instalação. Após a conclusão do primeiro estágio da instalação, o script termina e o software do terminal passa a autorização no processamento, recebe caminhos para o perfil de instalação e baixa todos os arquivos necessários. Aqui, em tempo real, você precisa monitorar os logs no terminal através do SSH. Todas as situações anormais durante a instalação (por exemplo, dados de autorização incorretos) são gravadas nele, você precisa ler esses logs online e, se necessário, considerar que o teste de instalação limpa falhou.

Instalação limpa do zero MarATL

Conclusão

Examinamos visões gerais sobre os principais aspectos técnicos da criação de autotestes para software de terminal. Sem nos aprofundarmos na tecnologia, resolvemos uma grande tarefa em aspectos separados. Faça perguntas nos comentários, se o tópico for interessante, você pode destacar alguns pontos em um artigo separado com mais detalhes. Obrigado pela atenção!

Software de teste de automação QIWI-terminais