Testes Não Funcionais: Performance e Alta Disponibilidade no Mercado de Capitais
Agenda Institucional Riscos e Garantia da Qualidade (QA) Classificação de requisitos e testes não funcionais Serviços de QA aplicados Computação e Estatística aplicadas Tipos de análises realizadas Feedback de clientes Exemplos de casos de teste não funcionais
Sobre a PrimeUp Fundada em 2004 no Rio de Janeiro, incubada na PUC-Rio com sua origem no LES (Laboratório de Engenharia de Software). Quando de profissionais (Dsc e Msc) com mais de 20 anos de experiência em TI e Gerência de Projetos. Mais de 60 profissionais IBM Premier Business Partner (mais de 35 certificações IBM Rational) Forte experiência em ferramentas, definição de processo e implantação: PPM, ALM, Garantia da Qualidade/Performance, Capacidade e Governança em TI. Escritórios no Rio, São Paulo e em breve Belo Horizonte
Área de Negócio PLAN Garantir o alinhamento estratégicos entre as prioridades do negócio e os investimentos planejados através da medição, análise e avaliação objetiva dos cenários de investimento com uma visão centralizada de recursos, orçamento e riscos. Permite manter os projetos adaptados às mudanças no negócios e nas necessidades dos cliente mantendo o melhor portfólio possível a cada momento e maximizando o uso dos recursos da organização.
Área de Negócio BUILD Gerenciamento de Ciclo de Vida de Aplicativos (ALM) é o casamento entre gerência de negócio com engenharia de software, com ferramentas que facilitam e integram processos como análise de requisitos, modelagem de arquitetura, desenvolvimento de código, gerenciamento de mudanças, gerenciamento de testes e gerenciamento de versões de produtos realizados. O objetivo é tomar a melhor decisão entre desenvolver, adquirir ou modernizar as aplicações e acompanhar a execução do projeto até a realização dos benefícios planejados.
Área de Negócio RUN Dentre os objetivos dessa prática, destacam-se a manutenção de um ambiente ótimo para a performance das aplicações, minimização de incidentes em produção e contenção de custos. Engloba otimização da infraestrutura física, tempo de resposta e capacidade dos serviços de TI e do middleware e das aplicações. Utiliza testes funcionais, testes de carga e stress, modelos computacionais, tecnologias de monitoração e modelos estatísticos para a identificação de gargalos, riscos operacionais, oportunidades de melhoria e promoção segura de aplicações para a produção.
Clientes BANK INSURANCE MEDIA ENERGY SI & ISV PUBLIC FSS CSP RETAIL LOGISTIC DEFENSE
Parcerias
Contexto e Motivação Crescimento do mercado de High Frequency Trading (HFT) no mercado de derivativos HFT (participação por grupo de contratos) 21 participantes ativos em Set de 2010 62.5% 23.6% 7.5% Segmento BM&F (milhares de contratos) FX contracts Index-based contracts Mini contracts 3.3% 3.2% 3.2% 4.1% 2.6% 164 162 151 156 162 4.8% 203 1.4% 84 0 1 3 7 12 15 13 17 20 25 * Fonte: BVMF Investor Relations Jun-09 Jul-09 Aug-09 Sep-09 Oct-09 Nov-09 Dec-09 Jan-10 Feb-10 Mar-10 Apr-10 May-10 Jun-10 Jul-10 Aug-10 Sep-10 Oct-10 9
Garantia da Qualidade? Mais que testes, uma área de (QA) deve pensar na minimização de Riscos Operacionais de TI RESOLUCAO BCB N. 003380, DE 29 DE JUNHO DE 2006 = IMOBILIZAÇÃO DE CAPITAL RISCO: a probabilidade de uma ameaça explorar uma vulnerabilidade de um determinado ativo, provocando impactos nos negócios da organização. INTERESSE: Diminução de risco operacional possibilita diminuir o volume de capital imobilizado
Riscos operacionais 17/01/2012 UOL ECONOMIA: Problemas técnicos atrasam início de pregão na Bovespa
Como mitigar? Além de executar os testes, QA deve : Analisar requisitos não funcionais Sugerir recomendações para produção Propor alterações na especificação do sistema Fornecer guidelines para área de desenvolvimento
Classificação de teste não funcional
Classificação de testes não funcionais Desempenho Teste de Desempenho Benchmarking Capacidade Teste de Capacidade/Stress Escalabilidade Tolerância a falhas Confiabilidade Alta Disponibilidade (HA) Teste de recuperação de desastre (DR) Estabilidade
Tipo de requisitos não funcionais Qual o tempo de resposta? Desempenho Sistema/componente se recupera em caso de falha? (TaF) Sistema/componente possui Alta Disponibilidade? (HA) Qual o tempo de recuperação de desastre? (DR) Quantidade (ou tempo) de mensagens perdidas em caso de desastre? (DR) O sistema é escalável? (Escalabilidade) Quantos usuários simultâneos o sistema suporta? (Capacidade/Stress) O sistema de trading permanece estável durante o pregão? (8 horas)? (Estabilidade) Quantos usuários simultâneos com RTT 2 segundos o sistema suporta? Quantos úsuários simultânoes o sistema suporta, com RTT 2 segundos e utilização máxima de 45% de CPU?
Atividades desenvolvidas Manutenção evolutiva de aplicações em laboratório Gestão de riscos não funcionais associada à gestão de mudanças em ambiente produtivo Troubleshooting/Análise de erros não funcionais em produção (PSG) Capacity planning/sizing Recomendação de hardware por perfil de utilização
Capacity planning Caiu da moda, pois hardware ficou muito barato? Voltou a tona agora com TI nas nuvens TI verde precisa poupar energia Capacity planning/sizing Com testes Com dados de produção Com simulação Com entrevistas/poc
Computação e Estatística Aplicada Média, média ponderada, Desvio Padrão, regressão, correlação, histograma, curva normal: uso no dia a dia Teoria de filas, lei de Amdahl Conceitos avançados de sistema operacional Conceitos de arquitetura de sistemas, estrutura de dados, redes TCP/UDP over IP
Response Time Análise de Capacidade e Performance Análise de Capacidade e Performance A BASE PARA A ANÁLISE: TAXA DE CHEGADA VS TEMPO DE RESPOSTA Response Time vs Throughput 10.000 9.000 8.000 7.000 6.000 5.000 4.000 3.000 2.000 1.000 0.000 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 Throughput SLA / QOS Queue Time Response Time Service Time
Análise de Capacidade e Performance Análise de Vazão (throughput)
Response Time Metodologia MODELOS DE FILAS - Online Throughput ou Lambda 10.000 Response Time vs Throughput λ OLTP 9.000 8.000 7.000 6.000 5.000 Utilização CPU Servidor Tempo de Serviço 4.000 3.000 2.000 1.000 0.000 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 Throughput Queue Time Response Time Service Time LEI DE AMDAHL - Batch BATCH
Medida de Capacidade Transações (taxa de chegada) CPU (ou I/O) (hardware + setup) Tempo de Serviço (capacidade) (lambda / #CPUs) = % utilização / service_time Ordens/s Web pages/s KBytes/s User calls/s (Banco de dados) sar 300 1 > file & iostat xdk 300 2 > file & Ou perfmon. calculado
Capacity Planning Sinacor MODELO M/M/N LATÊNCIA EM FUNÇÃO DE TRANSAÇÕES
Capacity Planning Sinacor Malha Batch Fechamento BOL_Fechamento = 1315 + 0,0130 * Movimentos Atualizados + 162,3 ERRO = +/- 6%
Feedback dos clientes - I O resultado ficou excelente! Ficou bastante claro o breakdown das causas raiz e das limitações, e matematicamente o modelo está bastante correto. Por favor, transmita meus parabéns para a equipe. Baseado nessas informações, conseguiremos oferecer o insumo à área de negócios das reais limitações, e dar um guia para clientes que necessitarem calibrar seus algos para manter o desvio padrão otimizado. Ficamos pendentes somente a recomendação de TPS/sessão FIX. Muito obrigado pelo empenho, e mais uma vez, parabéns.
Feedback dos clientes - II Pessoal, Ontem tivemos uma apresentação do nosso diretor executivo Ciclano Beltrano falando sobre as metas, realizações e sobre alguns pontos que estão por vir. Fiquei muito feliz com alguns pontos abordado pelo Beltrano, onde ela ressalta a importância da área de QA para a empresa, inclusive o primeiro item foi um dado que QA forneceu. Por este motivo estou repassando este e-mail pra vocês para saberem que QA esta em evidência e a importância da nossa área para toda empresa.
Teste = Verificação de Risco Cada teste está relacionado a um único objetivo. Um teste pode ter um ou mais cenários de teste. Exemplo: Objetivo: Comparar desempenho das versões 6.1 e 6.2 (Benchmarking).
Cenário de teste Em geral, está relacionado com as configurações do teste e/ou de ambiente. Um cenário pode ter um ou mais casos de testes. Exemplo: Cenário 1: log em modo assíncrono Cenário 2: log em modo síncrono
Caso de teste Engloba as configurações completas de um cenário. Exemplo: 1000 usuários conectados com 10 listeners 2000 usuários conectados com 20 listeners 4000 usuários conectados com 40 listeners
Metodologia de teste Descreve o método utilizado. Exemplo: O teste é iniciado com carga mínima constante de 100 mensagens por segundo, e a cada 60 segundos de execução a carga é dobrada. A duração de cada bateria de execução será de 5 minutos, e entre cada bateria, o sistema será reinicializado e realizada limpeza no banco de dados. A carga utilizará proporção de negócios por oferta registrada será de 1 para 10, equivalente à proporção média (por instrumento) verificada em ambiente de produção.
Critério de sucesso/aceite O critério de aceite definido é um conjunto de requisitos foi atingido ou não (passed or failed). Exemplos: Requisito: Tempo de resposta médio + desvio-padrão menor ou igual a 17 milissegundos e CPU Utilizada < 45%. Resultado Obtido: média + desvio = 15,42 ms CPU Utilizada = 32% PASSED
Perguntas? mateus.santos@primeup.com.br