Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a esta recomendação da lista de verificação do Azure Well-Architected Framework Operational Excellence:
| OE:09 | Aprimore a qualidade da carga de trabalho adotando práticas de teste que se alinham aos objetivos de negócios e mantêm os padrões de qualidade. |
|---|
Ao introduzir uma alteração na carga de trabalho, você precisa garantir que ela funcione conforme o esperado e não introduza novos problemas. O teste é como você avalia essas alterações. É uma prática essencial para manter a qualidade e criar confiança em sua carga de trabalho.
O teste eficaz fornece uma carga de trabalho confiável e de alta qualidade. Ele impede que os defeitos atinjam a produção, reduz o retrabalho custoso e atrasos, e mantém seu trabalho alinhado com os objetivos de negócios durante todo o ciclo de vida do desenvolvimento.
Este artigo fornece estratégias para ajudá-lo a fornecer uma carga de trabalho de alta qualidade por meio de práticas de teste eficazes. Ele serve como orientação fundamental para as diretrizes de teste especializadas em outros pilares, como desempenho, confiabilidade e segurança.
Para obter diretrizes de implementação sobre práticas de teste, consulte o artigo complementar: Crie confiança em cargas de trabalho Azure com práticas de teste eficazes.
Formalizar sua estratégia e plano de teste
Sua estratégia de teste e planos de teste são artefatos essenciais. Eles fornecem um roteiro claro para seus esforços de teste e garantem que todos estejam trabalhando em direção às mesmas metas de qualidade.
Definir sua estratégia de teste
Sua estratégia de teste é um blueprint de alto nível que orienta sua abordagem geral de teste. Ele define seus objetivos de teste, escopo, metodologias, ferramentas, funções e responsabilidades. Ele ajuda você a tomar decisões informadas sobre prioridades de teste, alocação de recursos e gerenciamento de riscos. Ele também captura como você se comunica com os stakeholders e reporta resultados.
Uma estratégia de teste bem definida obtém a aceitação das partes interessadas e garante que todos os membros da equipe sigam padrões de qualidade consistentes. Ele fornece direção e estrutura, alinha testes com objetivos de negócios e protege a qualidade de longo prazo.
Sua estratégia de teste geralmente permanece consistente entre as versões de uma determinada carga de trabalho. Mas sempre personalize-o para refletir as necessidades específicas e os objetivos de negócios dessa carga de trabalho.
Observação
Não aplique a mesma estratégia padronizada a cargas de trabalho diferentes. Eles têm considerações exclusivas que precisam de abordagens exclusivas.
Criar seu plano
Depois de concordar com a estratégia de teste com sua equipe, formalize-a em um plano de teste com casos de uso alinhados aos objetivos de negócios.
Seu plano de teste é um documento detalhado que orienta a execução de teste para uma versão específica. Ele descreve o escopo de testes, casos de teste específicos, relatórios de defeitos, linhas do tempo, atribuições de recursos e critérios de entrada e saída para atividades de teste.
Um plano de teste bem estruturado torna o teste eficiente e alinhado com as metas e linhas do tempo da versão. É seu ponto de referência para acompanhar o progresso e tomar decisões informadas durante o teste.
Exemplo: Para um sistema de check-out de comércio eletrônico, a estratégia de teste define que os fluxos de pagamento são sempre priorizados, especifica ferramentas de teste para o sistema, como o JMeter, para teste de carga. Ele esclarece as responsabilidades da equipe para diferentes tipos de teste.
O plano de teste para uma versão se concentra em adicionar suporte ao Apple Pay. Ele define exatamente o que testar para o Apple Pay nesta versão, aloca recursos (dois engenheiros e três dispositivos iOS), define um agendamento de quatro semanas e estabelece critérios de entrada claros (código completo e ambiente configurado) e critérios de saída (todos os testes passam e zero bugs críticos).
Observação
Não comece a testar antes de definir claramente sua estratégia e plano de teste geral. Um plano de teste sólido mantém seus esforços focados e alinhados com as metas de carga de trabalho.
Testar cedo, testar com frequência, testar o que importa
Inicie o teste nos estágios iniciais do ciclo de vida de desenvolvimento de software. Quando você descobre problemas críticos lentamente, enfrenta aumento no retrabalho e liberação de versões mais lentas. Muitas vezes, os arquitetos ignoram os requisitos de teste na fase de design, o que afeta negativamente a qualidade geral.
Os desenvolvedores devem adotar uma mentalidade de garantia de qualidade. Pense em testar mesmo durante o projeto. Use-o para esclarecer os requisitos e detectar possíveis limitações. Torne o teste parte integrante do processo de desenvolvimento. Assuma a responsabilidade de escrever e manter testes junto com seu código.
Ao detectar problemas mais cedo, você pode responder rapidamente. Por exemplo, você pode priorizar alterações de design essenciais que afetam a experiência do usuário em relação a correções de bugs rotineiras. Agir antecipadamente reduz surpresas e atrasos de última hora.
O teste não é um evento único. Continue testando após a inicialização como parte de uma mentalidade de teste contínua. Examine, atualize e expanda regularmente seu pacote de testes para cobrir novos recursos e solucionar bugs descobertos na produção para manter a qualidade a longo prazo.
Observação
Não adie o teste em lotes grandes até o final do ciclo de entrega. Atrasar testes leva a problemas não detectados, maior retrabalho e lançamentos mais lentos.
Compensação. Testes iniciais e contínuos podem aumentar os custos operacionais e podem inicialmente atrasar o desenvolvimento ou criar atritos de equipe. Faça um balanceamento, identifique quais testes e alterações são essenciais no início e que você pode adiar para fases posteriores. Isso garante a eficiência sem comprometer a qualidade.
Testar em produção com medidas de segurança
Mesmo com práticas de teste e validação fortes, alguns problemas só aparecem no tráfego de produção do mundo real. Para encontrar problemas que você não pode simular, execute testes controlados na produção com proteções que limitam a exposição do usuário e reduzem o risco.
Planeje, isole e monitore cada teste de produção. Quando você faz isso, você recebe comentários reais do usuário e dados de desempenho sem interromper todos os outros.
Considere estratégias de exposição progressiva, como versões canárias, somente depois que sua carga de trabalho atender aos critérios de saída e demonstrar forte qualidade. Essa abordagem libera atualizações para um grupo pequeno e direcionado de usuários primeiro, ajudando você a descobrir rapidamente problemas que podem não aparecer em ambientes de pré-lançamento. Com essa abordagem, você acelera o processo de teste e potencialmente reduz os custos associados.
Monitore os testes de produção continuamente para encontrar problemas antecipadamente. Implemente proteções automatizadas que interrompem os testes se eles afetarem negativamente os usuários, como mecanismos de reversão automatizados e alertas em tempo real. Essas técnicas garantem resposta rápida e minimizam interrupções.
Risco: Tenha cuidado ao testar em produção, pois isso afeta diretamente os clientes reais. Sempre implemente proteções e limite a exposição para minimizar possíveis impactos negativos em sua empresa.
Aplicar abordagem de camadas na cobertura de testes
Uma estratégia de cobertura de teste em camadas fornece feedback rápido, detecção precoce de defeitos e lançamentos mais rápidos. Ao estruturar testes em camadas, você pode isolar e depurar rapidamente defeitos, tornando mais fácil identificar e resolver problemas.
Use a pirâmide de teste como um guia
O modelo de pirâmide de teste ilustra essa abordagem em camadas para automação de teste. Ele distribui testes em diferentes camadas para maximizar a cobertura, minimizando o tempo de execução e os custos de manutenção.
- Camada base: os testes de unidade verificam componentes individuais isoladamente. Eles funcionam rapidamente e fornecem feedback imediato.
- Camada intermediária: os testes de integração verificam interações entre componentes e serviços. Eles são executados mais lentamente do que os testes de unidade, mas fornecem uma cobertura mais ampla do comportamento do sistema.
- Camada superior: testes de ponta a ponta validam os percursos do usuário por todo o sistema, simulando cenários do mundo real. Esses testes são executados mais lentos, mas dão a maior confiança na qualidade geral.
Você pode integrar mais facilmente testes de camada base e média em seus pipelines porque eles têm dependências mínimas. Essa integração permite comentários rápidos quando os testes falham e permite que o processo de build pare imediatamente, impedindo que o código defeituoso progrida ainda mais.
À medida que a cobertura de teste aumenta, o tempo de execução do pipeline pode aumentar significativamente. Mantenha um ciclo de feedback rápido usando estratégias de execução de testes em paralelo e distribuídas, mantendo os pipelines eficientes, mesmo com o aumento da cobertura.
Observação
Não inclua todos os testes possíveis no pipeline de build inicial que compila e valida seu código. Essa opção retarda os ciclos de versão e corre o risco de que testes importantes sejam ignorados. Concentre-se em testes que protegem diretamente fluxos de trabalho críticos e fornecem confiança significativa na qualidade do sistema.
Compensação. Há uma compensação entre a cobertura de teste e a eficiência do pipeline. Embora os conjuntos de testes maiores aumentem a cobertura, eles também aumentam o tempo e o custo de execução. Eles nem sempre fornecem um retorno significativo sobre o investimento.
Teste de aplicativo e infraestrutura separados
Crie uma segmentação clara entre testar o código do aplicativo e o código de infraestrutura.
Separe os testes pelo que eles validam e quem os possui e, em seguida, adicione testes de integração que confirmem que ambas as camadas funcionam juntas. Os testes de código do aplicativo devem se concentrar na validação do comportamento da carga de trabalho. Os testes de código de infraestrutura devem se concentrar em validar o provisionamento e a configuração de sua infraestrutura.
Adicione testes entre camadas que exercem o aplicativo e a infraestrutura juntos. Testes de infraestrutura por conta própria podem lhe dar falsa confiança. O módulo IaC pode provisionar todos os recursos corretamente, mas se o aplicativo não puder realmente usar esses recursos, a carga de trabalho ainda falhará. Valide sua infraestrutura observando o comportamento do aplicativo por meio da implantação do software e da execução de testes nele. Um simples teste de fumaça em relação a um ponto de extremidade de integridade captura essa lacuna rapidamente.
Incorporar diferentes tipos de testes
Use vários métodos de teste em toda a carga de trabalho. Concluir testes de unidade não significa que você terminou os testes. Cada aspecto da carga de trabalho precisa de uma abordagem distinta. Vários tipos de teste aprimoram a qualidade geral e criam confiança de que o sistema funciona conforme o esperado.
Use a ferramenta certa para o trabalho. Identifique as ferramentas necessárias para realizar vários tipos de teste. Se você não tiver uma ferramenta, compre a ferramenta. Não o compile, pois isso pode introduzir riscos. Pesquise as ferramentas e seus recursos, como custos de licenciamento e se as ferramentas se integram diretamente aos seus requisitos de carga de trabalho. Avalie a experiência da equipe com cada ferramenta e considere a compatibilidade e a integração fazendo uma prova de conceito. Aproveite o suporte e o treinamento disponíveis para as ferramentas se a equipe de carga de trabalho não tiver essa experiência.
Escolha o tipo de teste correto com base na maturidade da carga de trabalho e no perfil de risco. Comece com a validação funcional por meio das camadas de pirâmide de teste e adicione testes não funcionais, como desempenho, segurança e resiliência. Alinhe a seleção de tipo de teste com os cenários críticos e os riscos da carga de trabalho.
A tabela a seguir mostra quando aplicar diferentes tipos de teste ao longo do ciclo de teste. Cada um aborda riscos específicos. Embora esta tabela não seja uma lista completa de todos os tipos de teste possíveis, ela serve como um exemplo ilustrativo.
| Tipo de teste | Primária Finalidade | Quando usar | Custo & Considerações |
|---|---|---|---|
| Teste manual | Valide cenários que exigem julgamento humano, aprendizado exploratório, usabilidade e nuances de experiência de usuário. | Desenvolvimento antecipado, alterações de interface do usuário, fluxos ambíguos ou quando a automação não é viável. | Alto custo, baixa escalabilidade - Use com moderação e concentre-se em áreas onde a percepção humana adiciona valor insubstituível. |
| Teste de unidade | Verifique a lógica de função ou componente individual isoladamente. | Continuamente durante o desenvolvimento. | Menor custo e valor mais alto – rápido, confiável e crítico para evitar regressões. Almeje uma ampla cobertura. |
| Teste de integração | Valide interações entre componentes, APIs, contratos e serviços compartilhados. | Quando os componentes e serviços estiverem prontos para interagir ou ao integrar novas dependências. | Custo médio – essencial para capturar configurações incorretas e defeitos de interação antecipadamente. |
| Teste de contrato | Verifique se o serviço ainda atende às interações das quais seus consumidores dependem, sem a necessidade de testes de integração completos. | Quando você altera uma API da qual outras equipes ou serviços dependem, especialmente em ciclos de versão independentes. | Custo médio – existem estruturas que ajudam você a registrar as expectativas dos consumidores e reproduzi-las como testes em seu próprio pipeline. |
| Teste de "End-to-End" (E2E) | Confirme a correção completa do fluxo de trabalho em todo o sistema, desde a ação do usuário até os serviços de back-end. | Quando os percursos principais do usuário se estabilizarem e puderem ser automatizados. | Alto custo e frágil – use seletivamente para os fluxos mais críticos para os negócios. |
| Teste de interface do usuário | Detectar regressões visuais, de layout e de interação. | Depois que o design da interface do usuário se estabilizar ou quando a fidelidade visual for um requisito de versão. | Alto custo de manutenção – limite a caminhos críticos da interface do usuário e cenários críticos de acessibilidade. |
| Carregamento e teste de desempenho | Valide o desempenho, a latência, a taxa de transferência e a escalabilidade sob a carga de trabalho esperada. | Comece o mais cedo possível e repita à medida que a arquitetura evolui. | Alto custo, mas necessário para a preparação de produção, especialmente para cargas de trabalho voltadas para o cliente. |
| Teste de estresse | Determine os limites do sistema, os pontos de interrupção e os comportamentos de recuperação. | Antes da preparação para a produção ou das principais alterações arquitetônicas. | Alto custo, fornece insights de resiliência – executado seletivamente devido ao impacto no ambiente. |
| Teste de segurança | Identificar vulnerabilidades, configurações incorretas e vetores de ataque. | Aplicar em todo o ciclo de vida de desenvolvimento. | Custo médio-alto, mas valor extremamente alto – crítico para proteger dados, atender à conformidade e reduzir o risco de negócios. |
Combine diferentes tipos de teste para avaliar sua carga de trabalho de vários ângulos. Execute uma combinação para que você pegue problemas que qualquer teste perderia.
Priorize os tipos de teste com base no impacto e no risco dos negócios. Avalie cada recurso ou alteração com base em seu potencial impacto e riscos associados. Para cargas de trabalho voltadas para o cliente, enfatize os testes de ponta a ponta e de interface do usuário. Para cargas de trabalho controladas por API, concentre-se em testes de integração e contrato. Para sistemas de alta disponibilidade, invista em testes de resiliência e caos.
Compensação. Priorize os testes de segurança no início do processo de lançamento. Essa abordagem ajuda a evitar vulnerabilidades e garante implantações mais seguras. No entanto, essa prioridade pode diminuir o ritmo no qual você entrega novos recursos à produção.
Tratar seus ativos de teste como importantes como ativos de código
Os ativos de teste capturam regras de negócios essenciais, casos de borda, padrões de defeito histórico e conhecimento organizacional valioso. Quando a qualidade do teste é degradada, as equipes perdem tempo depurando testes não confiáveis em vez de encontrar defeitos reais. Essa situação cria frustração e os desenvolvedores perdem a confiança na estrutura de teste.
Trate os ativos de teste com o mesmo rigor que os ativos de código. Assumir total responsabilidade por seus ativos de teste aprimora a confiabilidade e a qualidade geral da estrutura de teste.
Estruturar e proteger seus testes
Código de teste de estrutura com os mesmos princípios arquitetônicos que o código do aplicativo.
Mantenha seus testes ao lado do código no mesmo repositório para simplificar a manutenção e promover a consistência.
Implemente controles de governança equivalentes , como revisões de código obrigatórias, políticas de solicitação de pull e pipelines de validação de build para manter os padrões de qualidade.
Versione seus dados de teste junto com seu código. Ao alterar esquemas de dados ou regras de negócios, atualize os dados de teste para corresponder ao estado atual da carga de trabalho.
Faça a validação de linha de base de seus próprios testes para garantir que eles funcionem conforme o esperado. Quaisquer falhas devem apontar para problemas reais do aplicativo, não para defeitos de teste. Verifique se os testes falham adequadamente e passam consistentemente quando o seu processamento estiver estável. Tratar testes não confiáveis prontamente e garantir que as assertivas de teste reforcem o propósito de cada teste.
Configure práticas que garantam a independência e a confiabilidade do teste, como isolar dados de teste, evitar o estado compartilhado e implementar processos automatizados de instalação e desativação.
Teste de design para execução paralela. Para se beneficiar da execução de teste paralela, crie seus testes para serem independentes para que possam ser executados em qualquer ordem sem afetar os resultados. Testes independentes devem sempre configurar e limpar seus próprios dados e dependências, para que estados não sejam propagados para a próxima execução de teste.
Se o aplicativo exigir sequenciamento em testes, use estruturas de teste que dão suporte à execução de teste ordenada.
- Implemente práticas de codificação seguras no código de teste para evitar vulnerabilidades. Os testes geralmente interagem com dados e sistemas de produção, o que pode introduzir riscos de bibliotecas importadas ou código de teste vulnerável. Trate os testes com os mesmos padrões de segurança que o código de produção.
Manter os ativos de teste alinhados com os padrões de uso atuais
Seus ativos de teste de desempenho contêm conhecimento crítico sobre o comportamento esperado da carga de trabalho, os limites de desempenho aceitáveis e os padrões de tráfego realistas.
Organizar pacotes de teste por tipo. Mantenha testes de carga, testes de estresse e testes de resistência em conjuntos separados. Não misture. Cada tipo tem requisitos de instalação diferentes, durações de execução e critérios de êxito. Os conjuntos organizados facilitam a execução de testes direcionados, comparam resultados entre execuções e mantêm cada pacote de forma independente.
Atualize os dados de teste regularmente. Dados de teste obsoletos levam a resultados irreais. Regenerar dados de teste para refletir as características atuais dos dados de produção sempre que o modelo de dados for alterado, os volumes de dados aumentarem ou a mudança demográfica do usuário.
Examine os cenários de teste à medida que sua carga de trabalho evolui. Agende revisões regulares para garantir que seus cenários ainda reflitam o uso real.
Seus dados de teste devem parecer dados reais de produção. Use dados sintéticos que têm características de dados de produção. Reserve conjuntos de dados de produção (devidamente anônimos) para determinados cenários, como realçar comportamentos de gerenciamento de dados, como consistência de transações, latência e manipulação de volume.
Manter e evoluir seus testes
Manter seus ativos de teste é crucial para preservar a qualidade da carga de trabalho. Esses ativos geralmente contêm um valioso conhecimento organizacional. Se você não mantê-los regularmente, eles rapidamente se tornam obsoletos, minando sua eficácia e sua capacidade de fornecer versões de alta qualidade.
À medida que sua carga de trabalho evolui, seus ativos de teste devem evoluir em paralelo para se manterem alinhados com os objetivos de negócios.
Comece pequeno e desenvolva sua suíte de regressão deliberadamente. Seu conjunto de testes de regressão deve conter seus testes mais valiosos e estáveis. Adicione testes quando ocorrerem incidentes de produção, quando você corrigir bugs críticos e quando introduzir alterações de alto risco.
Automatize seu pacote de regressão para que ele seja executado consistentemente sem intervenção humana. Crie smoke tests rápidos que são executados em cada confirmação e testes de regressão mais amplos que são executados todas as noites ou antes do lançamento.
Mantenha os scripts de automação de teste e os casos de teste sincronizados. Os casos de teste capturam a intenção, o escopo e os resultados esperados. Se os scripts de automação divergirem de seus casos de teste correspondentes, é difícil rastrear o que está sendo validado, levando a lacunas na cobertura e na responsabilidade.
Planeje proativamente atualizações regulares para seus casos de teste à medida que você introduz novos recursos e aprimoramentos em sua carga de trabalho. Ao automatizar um caso de teste, vincule a automação ao caso de teste original para que você possa rastrear a cobertura.
Gerenciar o débito técnico do teste
Agende sprints regulares de manutenção de testes para resolver a dívida acumulada antes que ela se torne esmagadora. Testes irregulares, cobertura duplicada, testes obsoletos e design de teste ruim contribuem para o débito de teste.
Priorize a correção ou a remoção de testes não confiáveis para manter a integridade do conjunto de testes. Um conjunto menor de testes confiáveis é mais valioso do que um grande conjunto de testes escamosos.
Tome decisões estratégicas sobre ignorar ou adiar testes. Considere ignorar testes para código trivial ou de baixo risco, como getters e setters simples sem lógica de negócios, casos extremos extremamente raros, bibliotecas de terceiros e código herdado agendado para remoção. Documente essas decisões para que sua equipe possa revisitá-las como alterações de contexto.
Avalie seu conjunto de testes e separe testes confiáveis e consistentes daqueles propensos a alterações externas. Testes que frequentemente são interrompidos devido a fatores fora do controle, como testes de interface do usuário afetados por atualizações frequentes da interface do usuário, podem não ser bons candidatos à automação. Essa separação ajuda você a decidir quais testes automatizar e quais manter manualmente.
Compensação. Ao remover testes frágeis, você reduz a cobertura de automação. Balancee essa redução concentrando a automação em interfaces estáveis e fluxos de trabalho críticos, aceitando testes manuais para alterar frequentemente os elementos da interface do usuário.
Nem todos os testes merecem manutenção contínua. Desativar testes para recursos removidos, testes que duplicam a cobertura e testes que não fornecem mais valor. Documente por que você está removendo testes para que a decisão fique clara para sua equipe.
Estender a observabilidade ao framework de teste
A observabilidade no teste oferece dois benefícios importantes. Primeiro, ele confirma que a estrutura de teste está funcionando. Em segundo lugar, ele fornece visibilidade contínua sobre a qualidade e a integridade de sua carga de trabalho.
Sem essa visibilidade, você enfrenta dificuldades consideráveis para diagnosticar problemas, capacidade limitada de monitorar sistemas em tempo real e não obtém insights claros e acionáveis sobre a eficácia da cobertura de automação.
Os conjuntos de testes se deterioram ao longo do tempo. Os testes tornam-se não confiáveis, perdem relevância ou não conseguem acompanhar as alterações de carga de trabalho. Ao incorporar a observabilidade, você pode monitorar efetivamente a integridade do conjunto de testes, identificar e resolver falhas rapidamente e tomar decisões informadas sobre prioridades e melhorias de manutenção.
Gere relatórios de cobertura para identificar lacunas na automação. Quando a cobertura de teste se alinha aos dados de observabilidade de incidentes de produção, as equipes obtêm informações sobre quais cenários não têm validação adequada.
Use as ferramentas de relatório e cobertura de teste padrão do setor em sua estrutura para:
- Fornecer visibilidade clara em caminhos de código testados
- Identificar testes com falha consistente
- Analisar tendências de longo prazo na confiabilidade do teste
- Rastrear as origens de falhas para melhorias direcionadas
Risco: Se os logs forem inconsistentes e excessivamente detalhados, eles poderão criar mais ruído do que valor, tornando a depuração mais difícil. Implemente o registro em log estruturado com mensagens claras e acionáveis e diferentes níveis de verbosidade para garantir que os logs forneçam insights significativos sem sobrecarregar sua equipe.
Simular condições realistas
Avalie seus fluxos de trabalho de uma perspectiva do usuário final para garantir que eles realmente atedam às necessidades e às expectativas do cliente. Defina critérios claros de aceitação para suas cargas de trabalho e testes de design que reflitam com precisão fluxos e experiências reais do usuário, não apenas comportamentos isolados do sistema.
Dimensionar a cobertura estrategicamente
Dimensione sua cobertura de teste com base no risco e no valor. Priorize a cobertura para percursos de usuário de alto valor e caminhos críticos que afetam diretamente a experiência do cliente. À medida que a complexidade da carga de trabalho aumenta, expanda sua cobertura de teste avaliando cenários que fornecem a maior confiança na qualidade e confiabilidade da carga de trabalho.
Risco: Não invista excessivamente em um único fluxo de usuário além do ponto em que os retornos diminuem. Depois de obter cobertura suficiente para caminhos críticos, mude o foco para outras áreas importantes. Procure alcançar uma cobertura equilibrada ao invés de focar na perfeição em apenas um fluxo.
Alinhar-se com objetivos de negócios e SLOs
Alinhe seus testes com objetivos de negócios e SLOs (Objetivos de Nível de Serviço).
Defina limites de qualidade mensuráveis que refletem os compromissos comerciais e as expectativas do usuário. Concorde com esses limites, pois eles fornecem um ponto de referência para detectar desvios e solucionar erros. Essa abordagem protege a experiência do usuário garantindo que os principais limites de qualidade do serviço não sejam comprometidos.
Examine e atualize regularmente suas métricas de linha de base para garantir que elas continuem a atender às necessidades e expectativas atuais do cliente.
Usar dados de teste representativos
Os dados de teste devem representar cenários do mundo real o mais próximo possível.
Os dados sintéticos podem simular cenários de usuários autênticos, evitando a complexidade do tratamento de dados de produção. Por exemplo, o teste sintético pode replicar cenários do mundo real gerando conjuntos de dados representativos para avaliar o desempenho da carga de trabalho em condições de dimensionamento planejadas.
Use dados sintéticos como sua opção padrão. Reserve dados de produção para cenários específicos em que os dados sintéticos não podem replicar a complexidade necessária, como testar scripts de migração de dados.
Se você precisar usar dados de produção para teste, certifique-se de anonimizar corretamente todas as informações para proteger informações confidenciais.
Simular seu ambiente de produção
O ambiente de produção é sua fonte de verdade para entender como sua carga de trabalho se comporta em condições reais. Crie um ambiente que espelha de perto as condições do mundo real para que você possa confiar que o sistema seja executado conforme o esperado na produção.
- Adapte sua abordagem para espelhar ambientes de produção para as necessidades específicas da carga de trabalho.
Para cargas de trabalho críticas que exigem alta disponibilidade, teste em um ambiente dedicado que se assemelha muito à produção. Para essas cargas de trabalho, balancee cuidadosamente a otimização de custos com a necessidade de validação robusta.
Use um ambiente dedicado, semelhante à produção, para teste de carga e desempenho para garantir que o comportamento do serviço seja avaliado com precisão em condições realistas.
Para outras cargas de trabalho, faça com que seu ambiente espelhar de perto a infraestrutura de produção para reduzir falsos positivos, como casos em que os testes têm êxito em ambientes mais baixos, mas falham na produção.
Busque consistência em todos os ambientes à medida que seu código avança pelo pipeline. Simule as condições de produção em vários aspectos da carga de trabalho, incluindo infraestrutura, dados e segurança, para garantir resultados de teste confiáveis.
Evitar desvio de configuração. Quando você espelha seus ambientes para o ambiente de produção, o desvio de configuração pode criar falsa confiança na qualidade. Implemente verificações de validação automatizadas para descompasso de configuração para garantir que seu ambiente permaneça alinhado com a produção. Quando apropriado, configure os portões de implantação para verificar se a versão correta foi implantada antes do início do teste.
Risco: Quando você espelha os ambientes de produção, isso pode aumentar significativamente os custos operacionais. Avalie se ambientes efêmeros ou ambientes de teste persistente oferecem o equilíbrio ideal entre eficiência de custo e qualidade para sua carga de trabalho.
Criar ambientes de teste controlados por finalidade
Ambientes de design com um foco claro na finalidade pretendida. Avalie os requisitos distintos de cada fase em seu ciclo de vida de teste e verifique se o ambiente está alinhado com os objetivos dessa fase.
Projete intencionalmente cada ambiente de teste para corresponder ao estágio específico e às metas de teste, seja para validação funcional, teste de integração ou outras finalidades. Se um ambiente simplificado atender efetivamente às suas necessidades de teste, priorize essa abordagem para maximizar a eficiência.
Usar serviços fictícios
A replicação completa de sistemas de produção para cada cenário de teste geralmente é impraticável. Avalie quais componentes da carga de trabalho você pode replicar com segurança para teste sem comprometer fluxos de trabalho de negócios críticos. Quando a replicação completa não for viável, use serviços fictícios que simulam com precisão os comportamentos do serviço de produção para validar cenários efetivamente sem arriscar operações dinâmicas.
Os ambientes de teste controlados por finalidade fornecem uma base ideal para implantar serviços fictícios em ambientes efêmeros. Ambientes efêmeros oferecem uma maneira econômica de simular condições de produção para teste. Você pode validar interações e comportamentos sem a sobrecarga de manter ambientes completos semelhantes à produção para cada cenário de teste. Esses ambientes sob demanda são criados para fins de teste específicos e destruídos após o uso, reduzindo os custos de infraestrutura, mantendo a qualidade do teste.
A criação de ambientes efêmeros exige que sua carga de trabalho atinja um nível de maturidade mais alto, em que a automação com IaC (Infraestrutura como Código) e pipelines de implantação está bem estabelecida.
Suporte ao Azure
Os Planos de Teste do Azure são uma solução de gerenciamento de teste baseada em navegador que fornece todos os recursos necessários para testes manuais planejados, testes de aceitação do usuário, testes exploratórios e coleta de comentários dos stakeholders. Ele inclui a Análise de Teste para acompanhar a qualidade do teste ao longo do tempo e identificar áreas de melhoria.
O Azure Pipelines possibilita que você integre o teste ao pipeline de CI/CD. Você também pode usar o GitHub Actions integrado ao Azure.
O Teste de Aplicativo do Azure é um serviço que dá suporte a testes funcionais e de desempenho. Ele permite que você execute testes funcionais com Workspaces do dramaturgo e testes de desempenho usando o Teste de Carga do Azure.
Os Ambientes de Implantação do Azure podem ajudar a criar a infraestrutura do aplicativo com modelos baseados em projeto que estabelecem consistência e práticas recomendadas, maximizando a segurança.
O Azure também fornece ferramentas nativas da plataforma que dão suporte a testes de confiabilidade, desempenho e segurança.
Links relacionados
- Recomendações para testes de desempenho
- Recomendações para testes de confiabilidade
- Recomendações para testes de segurança
Lista de verificação de Excelência Operacional
Consulte o conjunto completo de recomendações.