O desembarque da R2 na linha de negócios omnicanal | Equipe técnica JD Cloud

Com o crescimento do negócio e a iteração de alta frequência do sistema, o trabalho de garantia de qualidade precisa introduzir urgentemente métodos de teste mais científicos e eficientes para ajudar na entrega de alta qualidade do negócio. Durante o teste da primeira fase do projeto Great Wall, a equipe de qualidade omnicanal introduziu a tecnologia R2 do departamento de plataforma de tecnologia, o que melhorou muito a qualidade da entrega do projeto. Portanto, este artigo se concentrará em como as equipes de qualidade omnicanal usam o R2 para garantir a qualidade dos negócios.

1. Por que introduzir o R2?

O projeto Omni-channel Great Wall afunda os recursos de transação omni-channel existentes para a plataforma de transação e realiza a profunda integração de sistemas online e offline no nível do sistema técnico. lojas omnicanal, merchandise, compras, promoções, cupões, encomendas em geral, pagamento ao pós-venda. O projeto envolve mais de 27 aplicativos, mais de 300 interfaces e uma ampla gama de negócios. Se você confiar completamente nos testes manuais tradicionais, não apenas precisará investir muita mão de obra em um tempo limitado, mas também será difícil garantir que cada iteração retorne para cobrir todos os cenários de negócios, o que acabará afetando a qualidade de entrega de projeto.

Portanto, para cobrir de forma mais abrangente e eficaz todos os cenários de negócios on-line, a Equipe de Qualidade Omni-Channel pesquisou ferramentas de plataforma adequadas para comparação de dados antes e depois da transformação do projeto Great Wall e, finalmente, escolheu a ferramenta R2 do Departamento de Plataforma Tecnológica entre várias ferramentas. O nome completo do R2 é Record and Replay, ou seja, gravação e reprodução. Depois que os colegas de teste se comunicaram com a equipe R2 e experimentaram, eles descobriram que é uma ferramenta de teste auxiliar muito adequada para comparação de projetos em grande escala de grandes quantidades de dados. Além disso, o acesso do R2 também é muito simples, basta acessar a versão do pfinder necessária no aplicativo, e o R2 encontra o aplicativo a ser testado e realiza testes auxiliares. Ao registrar o tráfego online real e reproduzi-lo online ou em um ambiente de teste, ele pode não apenas ajudar a testar e melhorar os casos de teste de negócios, mas também proteger a influência externa no código a ser testado, zombando da interface jsf upstream, banco de dados mysql, e jimdb cache. , concentram-se apenas nas alterações de código dentro do sistema.

Com base no posicionamento acima e nas características do R2, o R2 pode auxiliar totalmente o teste de melhoria técnica e o teste de regressão do sistema. O projeto da Grande Muralha apresentado neste artigo pertence ao teste de transformação técnica.

2. Como o R2 permite testes de negócios ecológicos omnicanal?

Primeiro, registre o tráfego online nas interfaces relevantes. Em seguida, reproduza de forma assíncrona para o aplicativo em teste. Por fim, de acordo com os resultados diferentes da interface online e do aplicativo em teste, bem como as solicitações relacionadas registradas, analise e avalie de forma abrangente se o sistema atingiu o padrão online. Tomando como exemplo o negócio de promoção do projeto da Grande Muralha, a introdução é a seguinte.

2.1 Gravação e reprodução

Como o negócio de promoção do projeto Great Wall tem altos requisitos de tempo real para casos de uso, o DIFF em tempo real é usado para facilitar o teste de regressão. A principal diferença entre o DIFF em tempo real e o DIFF offline é: offline é gravar primeiro o tráfego online, não reproduzi-lo temporariamente e, em seguida, reproduzi-lo quando precisar ser reproduzido. E o tempo real é iniciar a reprodução assíncrona imediatamente após a conclusão da gravação, reduzindo assim o impacto da pontualidade nos resultados do teste. As tarefas de gravação e reprodução correspondentes ao DIFF em tempo real precisam prestar atenção aos três pontos a seguir:

Configurações da tarefa: defina o nome da tarefa, selecione o ambiente de reprodução e selecione o aplicativo a ser testado. Conforme mostrado no canto superior esquerdo da Figura 2.1.

Configurações de link: Primeiro, você precisa selecionar a interface para ser DIFF em tempo real, e cada interface deve ativar a reprodução da interface e selecionar o alias da interface a ser reproduzida. Nota: Este alias é o alias para a interface solicitar novamente após a gravação de tráfego subsequente. Em seguida, defina as regras relacionadas à resposta da interface. Entre eles, existem três tipos de regras de comparação de impacto de interface, o primeiro e o segundo são comumente usados e o terceiro tipo precisa escrever um script de comparação por conta própria. O método equals da regra de comparação de solicitações refere-se à comparação de todo o método e todos os campos do método serão comparados. A configuração visual refere-se aos campos que precisam ser configurados para serem ignorados.Se houver um tipo de lista no resultado da resposta, a classificação dos campos na lista precisa ser definida para garantir a precisão da comparação dos dados. Alguns exemplos são mostrados na Figura 2.1.

Figura 2.1

Configuração do aplicativo: refere-se às máquinas selecionadas para gravação, e o tráfego gravado nessas máquinas será reproduzido de forma assíncrona para o aplicativo em teste. Conforme mostrado no canto inferior direito da Figura 2.1, a máquina selecionada é o IP correspondente da máquina.

2.2 Análise dos resultados

Após a conclusão da reprodução da tarefa DIFF em tempo real, clique no resultado para ver as solicitações gravadas desta tarefa e o número de solicitações DIFF. Se houver uma tarefa DIFF, você poderá comparar os resultados para ver qual método tem resultados de solicitação diferentes. Como mostrado na Figura 2.2.

Figura 2.2

Tome como exemplo o resultado DIFF em tempo real de uma interface para promoção. As Figuras 2.3 e 2.4 consultam, respectivamente, os parâmetros de solicitação de interface e os resultados de resposta do sku correspondente em uma determinada sessão seckill. Os parâmetros de entrada da interface na Figura 2.3 incluem principalmente o ID da loja, sessão e locatário, e cada sku nos resultados da resposta contém o sku ID da promoção, preço da promoção e informações sobre o limite de compra, onde boundNumber representa o limite de compra do evento e excedenteRepertory representa o estoque do evento.

Figura 2.3

O lado esquerdo da Figura 2.4 é o resultado da solicitação atual e o lado direito é o resultado do registro histórico. Pode-se verificar que os valores correspondentes ao mesmo plusRepertory promocional do mesmo sku nos resultados esquerdo e direito são diferentes. A este respeito, as razões para as diferenças são analisadas da seguinte forma:

(1) Em primeiro lugar, considerando que haverá uma certa diferença de tempo na reprodução assíncrona, o inventário restante da consulta em tempo real pode ser inconsistente. No entanto, o estoque restante correspondente na versão histórica é 0 e a versão histórica é a primeira a solicitar on-line. Essa solicitação é anterior à solicitação à esquerda. Se for devido à diferença de horário, parecerá apenas que o O estoque restante à esquerda é menor que o da direita. Sim, então o motivo da diferença não é causado pela diferença de horário.

(2) A julgar pelos resultados do DIFF, o problema é que o estoque restante consultado pelo aplicativo em teste é diferente. Por meio da análise, verifica-se que o estoque restante correspondente a cada sku à esquerda é igual ao estoque ativo, não havendo alteração correspondente no estoque restante devido a pedidos. Então, através da simulação de posicionamento do mesmo cenário, verifica-se que a aplicação em teste não altera dinamicamente o estoque ativo restante para o cenário onde o estoque ativo é definido, o que fará com que o SKU seja vendido em excesso e afete as operações do negócio.

Figura 2.4

3. Quais são os benefícios da capacitação omnicanal do R2?

3.1 Acesso e uso do R2 em todos os canais

O omnichannel começou a acessar o R2 em dezembro de 2021. Sob a orientação da equipe R2, o acesso de 27 aplicativos principais e 320 interfaces foi concluído rapidamente em 1 dia e atualmente acessa cerca de 79+ aplicativos. O projeto Great Wall usará R2 para DIFF em tempo real e DIFF offline durante o período de seu lançamento em dezembro de 2021 a fevereiro de 2022. Ao mesmo tempo, a interface principal também usará testes de DIFF em tempo real durante o processo de comutação de fluxo subsequente e após a comutação de fluxo ser concluída, de modo que a estabilidade do sistema seja garantida.

Figura 3.1

A Figura 3.1 mostra o desenvolvimento de aplicativos omnicanal conectados ao R2. A abcissa representa o tempo e a ordenada representa o número de aplicativos que foram conectados ao R2 em cada mês. A Grande Muralha ficará online no final de dezembro de 2021. Para monitorar melhor a qualidade do projeto da Grande Muralha, o aplicativo principal omnicanal será conectado ao R2 um após o outro este mês, e o R2 será usado para gravar tráfego on-line e reproduzi-lo no aplicativo em teste para monitoramento antecipado e aplicativo de teste, descobrir inconsistências com antecedência e repará-las e otimizá-las antecipadamente. Como a maioria dos aplicativos no estágio inicial estava conectada ao R2, não há nenhuma alteração óbvia nos aplicativos recém-adicionados no período posterior. Depois que o fatiamento for concluído em fevereiro de 2022, alguns requisitos serão adicionados em março de 2022 e, em seguida, essa parte dos requisitos continuará conectada ao R2 para teste.

Figura 3.2

A Figura 3.2 mostra o número de tarefas para DIFF em tempo real e DIFF offline usando R2 em Omni-canal.As abcissas indicam o tempo e as ordenadas indicam o número de tarefas. Azul indica tarefas DIFF em tempo real e laranja indica tarefas DIFF offline. Dezembro de 2021 é o início do acesso de vários aplicativos ao R2, portanto, há muitas tarefas DIFF em tempo real e offline. Além disso, no início, alguns aplicativos criavam uma tarefa para uma interface, mas, na verdade, um aplicativo pode definir várias interfaces de forma independente de acordo com as regras de gravação e reprodução de cada interface, ou seja, apenas uma tarefa é necessária. Antes da conclusão do corte em fevereiro de 2022, a maior parte da pesquisa e desenvolvimento usa o R2 para comparar os dados do projeto da Grande Muralha. O teste de março de 2022 usa R2 para testes diários de projetos e requisitos. Entre eles, de acordo com a situação de cada linha de negócio, o DIFF em tempo real será selecionado primeiro para o negócio com fortes requisitos de eficácia, e o DIFF offline também pode ser selecionado para o negócio com baixa eficácia. Do ponto de vista dos dados, a maioria dos testes de demanda são realizados usando DIFF em tempo real.

3.2 Problemas de dados de negócios descobertos usando R2 no projeto Great Wall

Tomando como exemplo o DIFF em tempo real de linhas promocionais e de commodities conectadas ao R2, a Figura 3.3 mostra o número de bugs descobertos por meio do R2 antes que a Grande Muralha fique online. Entre eles, um total de mais de 140 problemas foram encontrados no produto e promoção, dos quais 76 problemas foram encontrados no lado B do produto e 37 problemas foram encontrados no lado C. Além disso, foram encontrados 27 problemas no lado B da promoção e 30 problemas no lado C da promoção. O terminal B na figura refere-se ao plano de fundo do gerenciamento de operações e o terminal C refere-se ao front-end do Qixian.

Figura 3.3

Além disso, com base nos resultados da comparação do R2, pode-se descobrir que existem relativamente muitos atributos envolvidos no produto, então o R2 irá comparar cada campo inconsistente antes e depois do corte de fluxo. Entre eles, os campos com comparações inconsistentes no lado B do produto incluem principalmente status do produto, fotos ausentes, descrição do produto, nome do produto e marca do produto. As principais razões para essas inconsistências de dados são: (1) problemas de sincronização de dados; (2) inconsistências de 0 e nulo para determinados campos; (3) campos não estão alinhados. A vantagem de usar o R2 é que essas inconsistências podem ser comparadas antecipadamente, reparadas e otimizadas, reduzindo o risco de lançamento do projeto.

O problema encontrado na comparação do final B da promoção mostrada na Figura 3.3 é que a promoção não pode ser encontrada depois que o fluxo é trocado, mas o final C pode ser atingido. O principal motivo é que a sincronização de dados é anormal e as funções do produto não estão alinhadas. Portanto, o reparo e desenvolvimento sistemático dos dados são necessários. Alinhar a função com o produto para garantir a qualidade do lançamento. O problema do lado C foca nos resultados da resposta após a solicitação em tempo real do usuário, desde que existam campos ou valores diferentes, eles serão comparados. O problema de promover o lado C também se concentra no problema de sincronização de dados. Portanto, R2 desempenha um papel muito importante na verificação da lógica de sincronização de dados.

4. Resumo e sugestões

Este artigo apresenta principalmente como a equipe de qualidade omnicanal usa o R2 para garantir a qualidade dos negócios. Começando com a introdução do R2, introduza passo a passo a introdução do R2 para implementação e receita omnicanal. Com base no negócio de promoção do projeto Great Wall, apresenta em detalhes a aplicação do acesso omnicanal ao R2 e o uso do R2, bem como um resumo dos problemas descobertos pelo R2. Por fim, com base na experiência de uso do teste R2 no projeto Great Wall, seguem algumas sugestões:

Para garantir a qualidade dos negócios.

(1) Ao usar R2 para configuração de tarefas, você pode criar uma tarefa relacionada a uma interface de aplicativo e tentar não criar uma tarefa para cada interface.

(2) Você pode usar o R2 para obter alguns parâmetros de entrada da interface, precipitar os parâmetros relacionados à interface e melhorar os casos de teste automatizados.

(3) Para respostas de interface com DIFF, testes de reprodução DIFF podem ser executados diretamente após P&D e reparo sem reexecutar a tarefa. Além disso, para aqueles com altos requisitos de tempo real, o DeepTest pode ser usado para simular manualmente solicitações DIFF para verificação. Se os requisitos em tempo real não forem altos, você pode usar a função de reprodução DIFF offline do R2.

(4) Para a estrutura complexa dos resultados retornados, você pode definir os campos a serem comparados ou os campos a serem filtrados e depositar um modelo de tarefa, que pode ser reutilizado após pequenas alterações no estágio posterior para melhorar a eficiência da criação tarefas.

Autor: JD Retail Yang Yaxiao

Fonte: Comunidade de desenvolvedores JD Cloud