Meu nome é Dasha e sou engenheiro de testes há 4 anos. Isso significa que as tarefas interessantes que você cria com a emoção de “junho” em busca de novas soluções aparecem cada vez menos. Os mesmos projetos, produções e cases! Não, eu não jogo assim! Testar é sempre um desafio, e o desejo de mudar o mundo para melhor não deve morrer. E uma vez que me deparei com esse problema: você precisa testar um simples bot de bate-papo no Telegram.
Antecedentes: era inconveniente para o nosso cliente executar as ações de rotina, conforme acordado, uma vez que inicialmente ele recebia um link para os cálculos necessários, e cada vez que ele abria os indicadores necessários através do navegador para revisão, o que aumentava o tempo de operação. Propusemos transferir a lógica para o bot de bate-papo, a fim de reduzir o tempo de tomada de decisão e facilitar a vida dos funcionários do cliente.
Para comemorar, decidi abordar esse assunto com toda a responsabilidade, mostrar o máximo de engenho e apenas apreciar o trabalho.
O teste foi realizado pelo método da caixa preta e cinza. Portanto, você pode usar toda a sua imaginação para criar scripts personalizados.
Instrução: um serviço de terceiros envia uma solicitação SOAP, que devemos processar e salvar no banco de dados e, em seguida, criar uma imagem com os parâmetros em um formulário de tabela e enviá-la ao usuário para aprovação. Em resposta, o sistema recebe uma confirmação ou rejeição junto com um comentário sobre a decisão.
Há uma descrição, lápis afiado, listas de verificação preparadas, biscoitos todos comidos. Estou pronto para começar! A cada segundo novas perguntas surgiam ...
Pare, pare, pare! Mantenha a calma e comece a testar. Então, em ordem:
1. De que forma exibir a data? Sempre há um problema com a data: formato, fuso horário etc.Como não pudemos obter requisitos exatos de um sistema externo, decidimos exibir a data na forma em que ele foi recebido originalmente. É muito difícil prever em que formato a data será recebida (mesmo uma bola mágica não poderia ter feito isso).
2. Quanto a qualidade da imagem sofrerá se a mensagem contiver uma grande quantidade de informações?A qualidade da imagem depende da quantidade de informações recebidas do exterior. O próprio telegrama reduz a qualidade da imagem. Caso haja uma grande quantidade de informações, transmitindo com um documento, obteremos a tabela em um formato legível, mas o usuário precisará usar um aplicativo de terceiros para abrir o arquivo PDF gerado. Isso complicará a vida e ninguém gosta de dificuldades (mas todo mundo adora biscoitos!). Ao mesmo tempo, se você enviar uma imagem, ela será legível somente quando um pouco de dados tiver sido recebido, mas o usuário poderá usar a funcionalidade do próprio Telegram para visualizar a imagem. Decidimos que era melhor deixar a tela com uma imagem, pois é mais conveniente trabalhar com ela e é improvável que haja uma grande quantidade de informações.
3. Como o sistema deve responder se nenhum comentário foi recebido sobre a decisão?Tudo ficou bem simples aqui: salvamos o resultado da decisão que foi enviada. E quando a solicitação foi repetida, o usuário recebeu informações sobre a necessidade de preencher um comentário sobre a decisão.
4. Como o usuário deve entender para qual solução é necessário deixar um comentário se vários pedidos de aprovação consecutivos foram recebidos?Aqui, a funcionalidade foi implementada para que uma mensagem solicitando um comentário venha na forma de uma resposta a uma mensagem com informações básicas sobre a solução.
5. O que o sistema deve fazer se o usuário ainda não tomou uma decisão sobre mensagens antigas, mas já foram recebidas novas?Nesse caso, nosso sistema reenvia a mesma mensagem para aprovação (ninguém ousa nos ignorar!).
6. Quantas mensagens podemos aceitar?Para responder a essa pergunta, decidi criar um simples fato de teste na interface do usuário SOAP. A escolha recaiu sobre esse aplicativo, pois ele possui um escopo abrangente (abrange verificação de serviços da web, simulação, teste funcional, teste de carga etc.).
Não vou explicar como criar um simples fato de teste, uma vez que eles já escreveram o suficiente sobre isso, gostaria apenas de descrever o problema e minha solução.
O principal problema era que, para cada nova solicitação, um novo identificador precisava ser gerado e esse valor gerado era reutilizado no mesmo XML.
A solução foi encontrada:
Em um caso de teste, uma Propriedade é criada com o atributo ID_Calc.
Em seguida, na guia Script de instalação, cole o script:
testCase.setPropertyValue ("ID_Calc", novo java.util.Random (). nextInt (99999) .toString ())
Depois disso, na própria solicitação, nas tags em que o identificador é usado, é necessário escrever:
$ {# TestCase # ID}
Assim, cada solicitação tinha um identificador exclusivo, mas dentro da estrutura de uma mensagem separada, os identificadores eram os mesmos.
O trabalho de desenvolvimento e teste foi realizado com muita rapidez e harmonia, por isso conseguimos alcançar o resultado o mais rápido possível. A revisão foi imediatamente entregue ao cliente e ele ficou satisfeito.
Mesmo da tarefa mais simples e mundana, você pode fazer uma busca interessante, cuja passagem da qual você pode se orgulhar! Bem, se você está entediado, mas quer sentimentos vívidos, encontre problemas no seu projeto e resolva-os de uma maneira incomum :)
Boa sorte